Archive for the ‘en’ Category

How to fix picture’s Date Taken

Ever downloaded your vacation pictures from your digital camera, just to discover that the Date Taken tag is wrong? There is a solution for that! You just need python, shell script and probably Linux skills, and ten minutes to spare.

The following lines will do the magic for you:

import pyexiv2
from datetime import timedelta
import sys

metadata = pyexiv2.ImageMetadata(sys.argv[1])
metadata.read()
tag = metadata['Exif.Image.DateTime']
if tag.value.year == 2011:
   tag.value += timedelta(days=366)
   metadata.write()

To keep things simple, I just assumed that you will run this script with the jpeg image as a parameter, and the pictures appear to be taken last year (happened to me).

To fix all the pictures in a folder, simply run this oneline:

for i in *.JPG; do python fix.py $i; done

There you go!

Later Edit: you would probably also want to change Exif.Photo.DateTimeOriginal and Exif.Photo.DateTimeDigitized tags.




AppStream Software Center on Fedora

Watching software-center code changes, this one came into my attention: an effort from Giovanni Campagna into bringing Software Center to Fedora, using the PackageKit backend I’ve been working on this summer.

It’s nice to see someone showing interest, and also picking up the code :) .

I must definitely get the time to fix my experimental OBS build, and see the openSUSE version running again. For the record, there is room for improvement on the performance part (especially starting up speed).




PackageKit backend for Software Center: pencils down report

Software Center in openSUSE

Software Center with PackageKit backend in openSUSE Factory

Today the official coding period of GSoC 2011 ends. It’s been a four months journey, with challenges, failures and achievements, but nevertheless fun :-) .

You may be wondering what is the status of my project; here it goes: current version of Software Center can be tested in openSUSE Factory; it can populate its database with data from an AppStream XML; it shows application information (fetched from the package manager); it installs and removes software, in the same friendly manner the ubuntu does (showing progress, handling dependencies).

Moreover, my patches to gobject-introspection, PackageKit and obviously software-center, are all upstream and released; kudos to the project managers and the community for helping me get them there.

There are still parts that need work; some of then have been intentionally left with lower priority from my initial plan, in order to get a functional version up by the end of the program; others weren’t covered by the planed feature set. These are: performance (current version is rather slow on first load, and also on showing list, due to many resolve calls), transaction history (it can be implemented using the almighty PackageKit), reviews (currently these are fetched from ubuntu servers), screenshots (same as reviews). Software Center itself passes a period of active development and changes, once its fancy Gtk+3 interface stabilizes, more work can be done into polishing the <other-distro> experience.

Although I’m generally happy with the result of the project, since this is a report, I want to outline what differed from my expectations and slowed me down from bringing a full feature set cross-distro Software Center:

  • fast development – when I started hacking on software-center’s GUI, it was pygtk Gtk+2 based; a Gtk+3 branch existed, but was far from being usable; under the last few weeks, it was merged, and actively developed into a newly designed interface (which will become software-center 5.0);
  • Gio, GLib, GMenu, GObject, usually libs starting with a capital G, which introspection bindings are about to stabilize; having to get them from trunk, and dealing with API breakage;
  • waiting for the pygobject release; when it came, it broke my pygtk mixed work (since static vs GI are no longer permitted in the same program – which is the right choice. btw), and left me with no working GUI; luckily, I took the best advices on IRC, and also software-center devs fixed things along, so that the new UI isn’t affected by the underlying changes.

Something worth mentioning in this finale post is that OBS totally rocks.

Overall, I hope this effort won’t stop here, and with a bit of luck, it will be shipped by your favorite distribution :D

PS: for more implementation/testing/plan details, I have created this page on openSUSE wiki, please check it out.




PackageKit backend for Software Center: week 11 status report

This week in three short achievements:

- personal OBS project (playing around, tutored by DimStar), work in progress

- code tide-up, ready for merging into master

- features, usage and testing documentation, work in progress

I’m now focusing on the gtk3 part, and also documenting things around. Packaging has decreased priority, waiting for the pygobject release.

And done ;-)




PackageKit backend for Software Center: short week 9 report

Hi all,

It’s nice to write to you again. I’ve been having a 10 days vacation (that’s why there was no week 8 report), enjoyed it and now I’m back with fresh forces.

This short (started slowly on Tuesday) week’s activity regards:
- almost fixing a bug that prevents my PackageKit software-center from prime time: package information isn’t correctly refreshed after an installation/removal
- starting work on the openSUSE integration (the corresponding Distro class, removal of forgotten apt related imports, dependency identification and testing).

I will continue work on this side and hope that by the end of the next week, will have everything working and up for testing in openSUSE.

Cya :-)

NB: I will have to provide for testing a trunk version of pygobject since a release is delayed by another awaited merge;




PackageKit backend for Software Center: short week 7 report

Short weekly report is short, this week’s achievements:

- fixed the install/remove simulation bits (it can now tell what packages will be removed after applying changes)

- improved PackageInfo testing (works with both AptCache and PackageKit)

- found the problem with dynamic/static libs conflict: it is gio statically loaded from gtk and then Gio dynamically loaded from PackageKitGlib; loading Gio before everything seems to fix the conflict for now;

- got another round of refactor changes into trunk, thanks to mvo; this way my PK branch is one step closer to merging into software-center

ktnxbye :-)




PackageKit backend for Software Center: week 6 report

Hi everyone, for this week report I would like to show you a screencast with the packagekit-backend branch of software-center:

As you can see in the video above, I’m using PackageKit in Software Center for the install/remove operations and also for fetching package information, such as summary, description and version.

The install backend lacks updates and addon management; also the dependency simulation is missing. For package information, work is still needed into getting license, installed_size and other custom fields, but all these seam doable.

Before you jump into running it by yourself, please note that to get PackageKit introspection working, you need the invoke-rewrite branch of pygobject, which will hopefully be merged into main and released next week.

This milestone being set, my work continues by completing the backend and then moving forward to other things such as optimizing or distro integration, packaging and testing :-)




PackageKit backend for Software Center: short week 5 report

This week I continued work on the install backend, especially connecting the PackageKit transaction signals to the software-center’s TransactionWatcher (also abstracted by me some time ago).

The challenge stands in differences from PackageKit and AptDaemon, such as in AD, after preparing a transaction and manually commiting it,  one has access to the transaction object, and can watch for progress changes; in PK, after a transaction is launched, there are two ways of getting access to it: first by listening to a TransactionListChanged signal in D-Bus and second by watching the objects returned by the progress_callback callback.

The current approach, helped closely by hue-see (hughsie) on #PackageKit is to get the transactions from the callback and listen to the gobject notify::<property> signals.

More to come next week, stay tuned!