headers
Richard Hughes | 4 Jul 2011 16:24
Picon

Zif 0.2.1 released!

Zif is a simple yum-compatible library that only provides read-write
access to the rpm database and the Fedora metadata for PackageKit.

Tarballs available here: http://www.packagekit.org/releases/

Version 0.2.1
~~~~~~~~~~~~~
Released: 2011-07-04

Notes:
 - Lots of nice speed and depsolver fixes.
 - New commands to the command line tool: distro-sync, upgrade-distro-live

New Features:
 - Add a distro-sync command to the zif command line tool
 - Add a section in the manual page about the environment variables we can use
 - Add a zif_package_array_find() convenience function
 - Add localpkg_gpgcheck to the config file as yum has split up the
policy for local and remote packages
 - Add methods to be able to add a single depend to a package
 - Add the ability to test getting the updates list in a manifest file
 - Add the command line action 'upgrade-distro-live' to perform a live
upgrade without using anaconda
 - Add zif_compare_evr_full() which takes an additional ZifPackageCompareMode
 - Add zif_depend_new_from_data() to be able to get a depend item from
a pair of key,value data arrays
 - Add zif_package_add_file() to be able to add a single file to a package
 - Add zif_package_array_filter_duplicates() for O(n) duplicate package removal
 - Add zif_package_compare_full() so we can pass in flags for name and
arch checking
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hughes | 4 Jul 2011 17:35
Picon

PackageKit 0.6.16 released!

Version 0.6.16
~~~~~~~~~~~~~~
Released: 2011-07-04

Libraries:
 - glib: Added element-type annotations for each function returning a
GPtrArray (Alex Eftimie)
 - glib: Ensure packages from the progress handler have the package_id
assigned (Richard Hughes)

Backends:
 - aptcc: Better put last fix in pk_backend_initialize (Daniel Nicoletti)
 - aptcc: Fix bug that resolved packages were emited as installed when
updates (Daniel Nicoletti)
 - aptcc: Fix getDetails to actually use the resolved version,
deb#606135 (Daniel Nicoletti)
 - aptcc: Initial support to conffile handling (Daniel Nicoletti)
 - aptcc: Set env var to disable apt-listbugs closes deb#628835
(Daniel Nicoletti)
 - conary: Don't show redirected packages (Jesse Zhang)
 - conary: Simplify _resolve_list (Jesse Zhang)
 - yum: Emit RepoDetail when refreshing a repository (Richard Hughes)
 - yum: Fix CVE-2011-2515 which only affects the YUM backend (Richard Hughes)
 - zif: Fix a critical warning when getting details about a package
(Richard Hughes)
 - zif: Implement UpdateSystem (Richard Hughes)

New Features:
 - Generate .tar.xz release tarballs (Richard Hughes)
 - Support looking up Plasma services (Kevin Kofler)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rodrigo Moya | 8 Jul 2011 12:32
Picon

installing languages

Hi

In the gnome-control-center we are adding a feature to install new
languages from it, and I've found there's not an easy way to do this
cross-distro with the current PK API.

The method to know the packages to be installed differs from distro to
distro. For instance, Ubuntu has a script:

$ check-language-support -l es
firefox-locale-es gimp-help-es libreoffice-help-es libreoffice-l10n-es
myspell-es openoffice.org-hyphenation wspanish
$ check-language-support -l en_GB
firefox-locale-en gimp-help-en hyphen-en-us mythes-en-au mythes-en-us
openoffice.org-hyphenation

Not sure how other distros do it, so I was thinking about having a:

InstallResource ("locale", "es")

call on the session bus interface, so that desktop apps can just call
that and have a UI be shown to do all the installation. Then, each PK
backend would have to retrieve the correct list of packages to be
installed

Comments?
Permalink | Reply | 4 comments |
headers
Richard Hughes | 8 Jul 2011 12:40
Picon

Re: installing languages

On 8 July 2011 11:32, Rodrigo Moya <rodrigo@...> wrote:
> The method to know the packages to be installed differs from distro to
> distro. For instance, Ubuntu has a script:
>
> $ check-language-support -l es
> firefox-locale-es gimp-help-es libreoffice-help-es libreoffice-l10n-es
> myspell-es openoffice.org-hyphenation wspanish
> $ check-language-support -l en_GB
> firefox-locale-en gimp-help-en hyphen-en-us mythes-en-au mythes-en-us
> openoffice.org-hyphenation

You you know how exactly check-language-support works? Does it do it
by looking in /usr/share/locale for subpackages of packages already
installed?

This also needs a little more work, as if we do:

InstallResource ("locale", "es")
- firefox-es gets installed
InstallPackage ("thunderbird")

Do we also install thunderbird-es? Logic would say yes, although that
would mean keeping a system wide "list of installed languages"
somewhere. This seems a little bit of feature creep for PK, although
I'd have no problem at all if PK was to gain support for a
newly-created /etc/xdg/installed-system-languages type file. I think
yum also has some kind of functionality to auto-install languages
using some hacky plugin but I'm not sure how they do it.

> Not sure how other distros do it, so I was thinking about having a:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Matthias Klumpp | 8 Jul 2011 15:39
Gravatar

Re: installing languages

Hi!

On Fri, 8 Jul 2011 11:40:30 +0100, Richard Hughes <hughsient@...>
wrote:
>> call on the session bus interface, so that desktop apps can just call
>> that and have a UI be shown to do all the installation. Then, each PK
>> backend would have to retrieve the correct list of packages to be
>> installed
>> Comments?
> 
> I think it makes a lot of sense to put this kind of distro logic in
> PK. We just have to work out all the details. :)
If we have an InstallResource() for e.g. Plasma Dataengines already,
implementing it for language packs too should be trivial.
The specific collection of language packages etc. will then be handled by
the backend itself, e.g. for Debian we could reuse the existing script and
Yum could implement it's own solution for fetching languages too.
Having this in PK would be valuable for sure!

Kind regards,
   Matthias

On Fri, 8 Jul 2011 11:40:30 +0100, Richard Hughes <hughsient@...>
wrote:
> On 8 July 2011 11:32, Rodrigo Moya <rodrigo@...> wrote:
>> The method to know the packages to be installed differs from distro to
>> distro. For instance, Ubuntu has a script:
>>
>> $ check-language-support -l es
>> firefox-locale-es gimp-help-es libreoffice-help-es libreoffice-l10n-es
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hughes | 12 Jul 2011 17:30
Picon

Depending on newer versions of Glib

I really want to raise our dependent version of GLib to 2.26 -- we
currently depend on 2.22. This would allow me to start using GDBus and
cut out some of our custom code like EggDbusMonitor and a lot of the
marshaling code for dbus-glib.

Is anyone apposed to doing this in master? If anyone has problems with
a raised dep I can branch for 0.7 and continue development in master,
leaving 0_6_X for bugfixes and no raised deps.

Thanks,

Richard.
Permalink | Reply | 2 comments |
headers
Alex Eftimie | 12 Jul 2011 17:45
Favicon
Gravatar

Re: Depending on newer versions of Glib

On Tue, Jul 12, 2011 at 6:30 PM, Richard Hughes <hughsient@...> wrote:
> I really want to raise our dependent version of GLib to 2.26 -- we
> currently depend on 2.22. This would allow me to start using GDBus and
> cut out some of our custom code like EggDbusMonitor and a lot of the
> marshaling code for dbus-glib.

It's worth noting in this thread that dynamic python bindings depend
on what will probably become pygobject 2.28.8 (to be released later
this week/earlier next week).

Alex
Permalink | Reply | 1 comment |
headers
Richard Hughes | 12 Jul 2011 17:53
Picon

Re: Depending on newer versions of Glib

On 12 July 2011 16:45, Alex Eftimie <alex@...> wrote:
> It's worth noting in this thread that dynamic python bindings depend
> on what will probably become pygobject 2.28.8 (to be released later
> this week/earlier next week).

Okay, that changes things a little then. How about I branch
PACKAGEKIT_0_6_X and then just raise the GLib dep to 2.28 in master?
We can drop packagekit-qt and the old python library in master also.

Richard.
Permalink | Reply | 0 comments |
headers
Matthias Klumpp | 18 Jul 2011 21:38
Gravatar

[PATCH] aptcc: Support for library provides

Hi!
The patch below enables searching for library names on aptcc. This means
you will be able
to run:
 $ pkcon what-provides libpackagekit.so.14
and get "libpackagekit-glib2-14" as result on Debian machines.
This already works well on Fedora with RPM.
Daniel, could you please take a look at the patch below and say if I can
commit it? It still has some very rough edges and I hope the regex handling
is okay (:P) - if someone knows how to do it better, please speak up.
Thanks!
Cheers,
   Matthias

diff --git a/backends/aptcc/apt.cpp b/backends/aptcc/apt.cpp
index 694b098..98506af 100644
--- a/backends/aptcc/apt.cpp
+++ b/backends/aptcc/apt.cpp
 <at>  <at>  -47,6 +47,7  <at>  <at> 
 #include <fstream>
 #include <dirent.h>
 #include <assert.h>
+#include <regex.h>

 aptcc::aptcc(PkBackend *backend, bool &cancel)
 	:
 <at>  <at>  -421,7 +422,8  <at>  <at>  void
aptcc::emitUpdates(vector<pair<pkgCache::PkgIterator, pkgCache::VerIterator
 	}
 }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hughes | 19 Jul 2011 10:59
Picon

Just a reminder: PACKAGEKIT_0_6_X

Hey backend dudes: If you push patches that fix bugs to master then
please also cherry-pick them to PACKAGEKIT_0_6_X as well. I'll do a
0.6.17 release like normal every month, as master is going to be quite
unstable for at least a month or so and 0.7.1 is going to be a bit of
a wait.

Thanks,

Richard.
Permalink | Reply | 0 comments |

Gmane