Richard Hughes | 1 Feb 12:23 2010
Picon

PackageKit 0.6.1 released!

Today I released PackageKit 0.6.1.

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

Version 0.6.1
~~~~~~~~~~~~~
Released: 2010-02-01

Translations:
 - Updated translation for Chinese (Simplified) (gml520)
 - Updated translation for Dutch (warrink)
 - Updated translation for Polish (raven)
 - Updated translation for Spanish (elsupergomez)

Backends:
 - alpm: Added autoremove and HoldPkg functionality (PirateJonno)
 - alpm: Changed search functions to allow multiple search values
(Valeriy Lyasotskiy)
 - alpm: Handle ILoveCandy config option (PirateJonno)
 - alpm: More formatting (PirateJonno)
 - alpm: Understand more config options (PirateJonno)
 - aptcc: Impoved search file (Daniel Nicoletti)
 - portage: Fix compilation and port code to new API (Fabio Erculiani)
 - ports: Convert search params to array values (Anders F Bjorklund)
 - urpmi: Fix backend api (Aurelien Lefebvre)
 - yum: Emit a warning when a developer tries to use autoremove (Richard Hughes)
 - yum: Ensure we look in all update notices for a security update.
Fixes rh#526279 (Richard Hughes)
 - yum: Include PackageKit in the list of essential packages (Richard Hughes)
 - yum: Show a message to the user if the repo could not be reached.
(Continue reading)

Fabio Erculiani | 4 Feb 12:20 2010

Missing eula-required signal in Python backend API

There are no public (nor protected) methods in PackageKitBaseBackend
to emit "eula-required" signals. Could anybody confirm this? I
actually need it.

Regards,
--

-- 
Fabio Erculiani
http://www.sabayon.org
http://www.gentoo.org
Richard Hughes | 4 Feb 12:47 2010
Picon

Re: Missing eula-required signal in Python backend API

On 4 February 2010 11:20, Fabio Erculiani <lxnay@...> wrote:
> There are no public (nor protected) methods in PackageKitBaseBackend
> to emit "eula-required" signals. Could anybody confirm this? I
> actually need it.

Looks like it was never added:

commit 9641b42e38c5f642cc7d52645bdbc3d91302e0b0
Author: Richard Hughes <richard@...>
Date:   Thu Feb 4 11:46:18 2010 +0000

    Add the eula-required python method helper

Richard.
Richard Hughes | 6 Feb 17:06 2010
Picon

Re: Debconf and PackageKit Was Re: Packagekit and Ubuntu

On 5 February 2010 23:15, Colin Watson <cjwatson@...> wrote:
> proposing an addition, or is there already a transaction ID of some kind
> in the environment that we could use in debconf?  If you could point me
> at the environment variable I'm missing, I'd be grateful.

I can add the transaction-id to the spawned backend if you like -- if
this is enough for you. Yell if you want something more.

Richard
Naba kumar | 7 Feb 16:38 2010
Picon

Supporting plugins search and installation

Hi,

In Anjuta, we are hoping to make things easy for users to find and install plugins, something akin to how firefox addons are managed. Clearly, it's best to be done with packagekit. This is something many other applications with plugin/extensions support will benefit without reinventing wheels.

In typical setup, these plugins are referenced using some kind of metafile. For example in Anjuta we have /usr/lib/anjuta/*.plugin files. They can come from any arbitrary sources and are supposedly already available in distro repository.

What would be nice is to have wild card search capability in packagekit API for provides and supported by all the backends. In Anjuta for example, user can select "Get more plugins" and it can then find/list all packages providing "*/anjuta/*.plugin" files.

Is there any possibility it can be done (or already done :))? We are looking forward to giving a really smooth and elaborate plugin management through this.

Thanks.

Regards,
-Naba

<div>
<p>Hi,
<br><br>In Anjuta, we are hoping to make things easy for users to find and install plugins, something akin to how firefox addons are managed. Clearly, it's best to be done with packagekit. This is something many other applications with plugin/extensions support will benefit without reinventing wheels.
<br><br>In typical setup, these plugins are referenced using some kind of metafile. For example in Anjuta we have /usr/lib/anjuta/*.plugin files. They can come from any arbitrary sources and are supposedly already available in distro repository.
<br><br>What would be nice is to have wild card search capability in packagekit API for provides and supported by all the backends. In Anjuta for example, user can select "Get more plugins" and it can then find/list all packages providing "*/anjuta/*.plugin" files.
<br><br>Is there any possibility it can be done (or already done :))? We are looking forward to giving a really smooth and elaborate plugin management through this.
<br><br>Thanks.
<br><br>Regards,
<br>-Naba<br></p>
</div>
Duncan Mac-Vicar Prett | 8 Feb 15:21 2010
Picon

Re: Supporting plugins search and installation

On Sunday 07 February 2010 16:38:01 Naba kumar wrote:
> Hi,
> 
> In Anjuta, we are hoping to make things easy for users to find and install
>  plugins, something akin to how firefox addons are managed. Clearly, it's
>  best to be done with packagekit. This is something many other applications
>  with plugin/extensions support will benefit without reinventing wheels.

I don't think the goal of PackageKit is to bring users to the problem of 
plugin management. Distros are supposed to set backend at compile time and it 
should be completely transparent to the user.

--

-- 
Duncan Mac-Vicar P. - Novell® Making IT Work As One™
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

_______________________________________________
PackageKit mailing list
PackageKit <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/packagekit
Richard Hughes | 1 Feb 12:42 2010
Picon

GNOME PackageKit 2.29.3 released

GNOME PackageKit is the name of the collection of PackageKit GUI tools
for use in the GNOME desktop.

Version 2.29.3
~~~~~~~~~~~~~~
Released: 2010-02-01

* Translations
 - Updated Traditional Chinese translation (Cheng-Chia Tseng)
 - Updated French translation (Claude Paroz)
 - Updated Spanish translation (Daniel Mustieles)
 - Updated Swedish translation (Daniel Nylander)
 - Added Bengali translation (Jamil Ahmed)
 - Updated Norwegian bokmål translation (Kjartan Maraas)
 - Updated Slovenian translation (Matej Urbančič)
 - Update Ukrainian translation (Maxim V. Dziumanenko)
 - Update simplified Chinese translation (Whistler)
 - Updated Telugu Translation (krishnababu k)

* New Features:
 - Remove the 'Install only security updates' button from the security
updates popup and open the update viewer instead (Richard Hughes)
 - Show transaction messages in gpk-repo (Richard Hughes)
 - Show the size of the extra packages that need to be downloaded as
deps (Richard Hughes)
 - Raise the gtk+ dep to 2.19.3 as we're using
gtk_cell_renderer_spinner_new() (Richard Hughes)
 - Filter by the timespec in gpk-log, not the localised date. Fixes
rh#544667 (Richard Hughes)
 - Show internal errors with modal dialogs, rather than just failing
quietly with an error on stderr (Richard Hughes)
 - Nest child updates in the update viewer so we don't show the same
update description multiple times (Richard Hughes)

* Bugfix:
 - Fix menu entry capitalisation in gpk-application (Philip Withnall)
 - Make the security update notification dialog timeout after 15
seconds (Richard Hughes)
 - Ensure we detect and use x11 to fix the compile when linking with
--as-needed (Richard Hughes)
 - Actually cancel the transaction when the GpkWatch cancel button is
pressed (Richard Hughes)
 - Process every transaction finish, even if we're not watching it
(Richard Hughes)
 - Only wait 3 seconds (not 60) when we get the updates changed signal
(Richard Hughes)
 - Re-get the update list in the update viewer if the network state
changes. Fixes rh#543871 (Richard Hughes)
 - Fix two potential crashers when gpk-update-viewer has finished
applying updates (Richard Hughes)
 - Don't hide the restart status icon just because the daemon exited.
Fixes rh#553966 (Richard Hughes)
 - Fix some i18n bugs. Fixes #606629 (Richard Hughes)
_______________________________________________
PackageKit mailing list
PackageKit <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/packagekit
Colin Watson | 6 Feb 00:15 2010

Re: Debconf and PackageKit Was Re: Packagekit and Ubuntu

[Sorry for the delay, I'm coming back to this now]

On Mon, Nov 23, 2009 at 04:17:37PM +0000, Richard Hughes wrote:
> 2009/11/23 James Westby <jw+debian@...>:
> > That may be the case, could you propose an alternative arrangement
> > that avoids it? How else does the backend know which client to send
> > the requests to?
> 
> Well, the aptBackend.py gets set an environment variable -- surely use that?

James and I were looking for this and couldn't find it.  Are you
proposing an addition, or is there already a transaction ID of some kind
in the environment that we could use in debconf?  If you could point me
at the environment variable I'm missing, I'd be grateful.

Thanks,

--

-- 
Colin Watson                                       [cjwatson@...]
Matthias Klumpp | 8 Feb 17:37 2010

Re: Supporting plugins search and installation

> On Sunday 07 February 2010 16:38:01 Naba kumar wrote:
> Hi,
> 
> In Anjuta, we are hoping to make things easy for users to find and
> install
>  plugins, something akin to how firefox addons are managed. Clearly, it's
>  best to be done with packagekit. This is something many other
>  applications
>  with plugin/extensions support will benefit without reinventing wheels.
If you just want to offer addons which are present in the distribution's
repositories, you can use the SearchFiles() function to get package names
which fit those requirements BUT searching files in non-installed packages
behaves a bit strange in PackageKit.
For example on Debian, apt-file is needed to access this functionality. And
on Fedora you have to insert the full file path to get results. (Tested
some months ago with PackageKit dev version)
You can try it out and see if it satisfies your requirements.
Regards
   Matthias Klumpp

Daniel Nicoletti | 8 Feb 18:53 2010
Picon

Re: Debconf and PackageKit Was Re: Packagekit and Ubuntu

Hey Colin,
I'm pinging you on IRC but I think you are off,
I really think you don't need any unique data from
PK, I have a very simple solution that i think you might
like, and we could put an end to this matter,
ping me on IRC when you can.

Best.

----- Mensagem original ----
> De: Colin Watson <cjwatson@...>
> Para: Richard Hughes <hughsient@...>
> Cc: PackageKit users and developers list <packagekit@...g>
> Enviadas: Sexta-feira, 5 de Fevereiro de 2010 21:15:42
> Assunto: Re: [packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu
> 
> [Sorry for the delay, I'm coming back to this now]
> 
> On Mon, Nov 23, 2009 at 04:17:37PM +0000, Richard Hughes wrote:
> > 2009/11/23 James Westby :
> > > That may be the case, could you propose an alternative arrangement
> > > that avoids it? How else does the backend know which client to send
> > > the requests to?
> > 
> > Well, the aptBackend.py gets set an environment variable -- surely use that?
> 
> James and I were looking for this and couldn't find it.  Are you
> proposing an addition, or is there already a transaction ID of some kind
> in the environment that we could use in debconf?  If you could point me
> at the environment variable I'm missing, I'd be grateful.
> 
> Thanks,
> 
> -- 
> Colin Watson                                       [cjwatson@...]
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
> http://lists.freedesktop.org/mailman/listinfo/packagekit

      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Gmane