FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 07-16-2008, 01:05 AM
"Dan McGee"
 
Default String freeze for 3.2 release

Allan has finally bugged me enough that its time for our pacman
codebase to see the light and a new 3.2 release. So here is the call
for the string freeze.

I've CC-ed this to the Arch General list to see if anyone there is
interested in helping out. PLEASE reply to the pacman-dev mailing list
if you have questions or want to help out but are not sure how.

Our pacman translation policy is outlined here. The important sections
for translators are the introduction and up to (and including)
pre-release updates.
http://www.archlinux.org/pacman/translation-help.html

As stated in the above document, PO files have been made available to translate:
http://code.toofishes.net/pacman/po_files/

I would like to get the release out in 7 days or so, so the sooner the
better for the translations.

Languages we currently have:
cs:Vojtěch Gondžala <vojtech.gondzala@gmail.com>
de: Matthias Gorissen <matthias@archlinux.de>
en_GB: Jeff Bailes <thepizzaking@gmail.com>
es: Juan Pablo Gonzalez <jotapesan@gmail.com>, Imanol Celaya
<ilcra1989@gmail.com>
fr: Xavier Chantry <shiningxc@gmail.com>
hu: Nagy Gabor <ngaba@bibl.u-szeged.hu>
it: Giovanni Scafora <linuxmania@gmail.com>
pl: Jaroslaw Swierczynski <swiergot@gmail.com>
pt_BR: João Felipe Santos <jfsantos@archlinux-br.org>
ru: Sergey Tereschenko <serg.partizan@gmail.com>
tr: Samed Beyribey <beyribey@gmail.com>
zh_CN: 甘露(Lu.Gan) <rhythm.gan@gmail.com>

If you wish to help translate, but your language is already listed as
handled by someone, please contact them at the above addresses. If the
language is listed as "no current translator", then please reply to
ALL on this message stating you are doing the translation so we do not
have duplicated effort (although you are more than welcome to work in
teams).

Once you have updated or completed a translation, simply tar and gzip
the files up and send them back to pacman-dev@archlinux.org with a
[translation] prefix in the message.

For those that are used to the old method of updating translations
(GIT patches), those are still acceptable as well. Please prefix the
patch with "translation:" so it can be picked out easily.

Any questions should be answered if you reply to this email on the list.

-Dan
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-16-2008, 01:05 AM
"Dan McGee"
 
Default String freeze for 3.2 release

Allan has finally bugged me enough that its time for our pacman
codebase to see the light and a new 3.2 release. So here is the call
for the string freeze.

I've CC-ed this to the Arch General list to see if anyone there is
interested in helping out. PLEASE reply to the pacman-dev mailing list
if you have questions or want to help out but are not sure how.

Our pacman translation policy is outlined here. The important sections
for translators are the introduction and up to (and including)
pre-release updates.
http://www.archlinux.org/pacman/translation-help.html

As stated in the above document, PO files have been made available to translate:
http://code.toofishes.net/pacman/po_files/

I would like to get the release out in 7 days or so, so the sooner the
better for the translations.

Languages we currently have:
cs:Vojtěch Gondžala <vojtech.gondzala@gmail.com>
de: Matthias Gorissen <matthias@archlinux.de>
en_GB: Jeff Bailes <thepizzaking@gmail.com>
es: Juan Pablo Gonzalez <jotapesan@gmail.com>, Imanol Celaya
<ilcra1989@gmail.com>
fr: Xavier Chantry <shiningxc@gmail.com>
hu: Nagy Gabor <ngaba@bibl.u-szeged.hu>
it: Giovanni Scafora <linuxmania@gmail.com>
pl: Jaroslaw Swierczynski <swiergot@gmail.com>
pt_BR: João Felipe Santos <jfsantos@archlinux-br.org>
ru: Sergey Tereschenko <serg.partizan@gmail.com>
tr: Samed Beyribey <beyribey@gmail.com>
zh_CN: 甘露(Lu.Gan) <rhythm.gan@gmail.com>

If you wish to help translate, but your language is already listed as
handled by someone, please contact them at the above addresses. If the
language is listed as "no current translator", then please reply to
ALL on this message stating you are doing the translation so we do not
have duplicated effort (although you are more than welcome to work in
teams).

Once you have updated or completed a translation, simply tar and gzip
the files up and send them back to pacman-dev@archlinux.org with a
[translation] prefix in the message.

For those that are used to the old method of updating translations
(GIT patches), those are still acceptable as well. Please prefix the
patch with "translation:" so it can be picked out easily.

Any questions should be answered if you reply to this email on the list.

-Dan
 
Old 07-16-2008, 11:11 AM
Nagy Gabor
 
Default String freeze for 3.2 release

I sent my reply to Dan, but I wanted to send here (Dan: new 4. point;-).

> I would like to get the release out in 7 days or so, so the sooner the
> better for the translations.

Wow. I bring up some thoughts here:
1. Some NEWS ideas. A. We should document API changes
separated from other changes to help front-end writers. From my side I
can recall 3 API changes: 8856146d71cb4cc512b0cf3414fbc231635822d3,
d060e31be3586ce27382f80eaed7a9edf2c86aeb,
1fc83f4af6d827bf2e69c7a10e3d2010c9211974 (without deep investigation,
alpm.h-diff should show almost everything). B. As user I would like to
see new features separated from "memleak fixes" ;-). For example, new
options: -Ru, --asexplicit, -S 'dep>=2.0' etc.
2. Xav said, that deltas are broken. Couldn't we move this out from
alpm code, and using it XferCommand or whatever (or implement new
"external helper", if needed)?
3. Front-ends should be able to free our new dynamic structs, e.g.
pmdepmissing_t.
4. <flame> Revert vercmp code to 3.1 </flame>

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-16-2008, 11:39 AM
Allan McRae
 
Default String freeze for 3.2 release

Nagy Gabor wrote:
>
> 2. Xav said, that deltas are broken. Couldn't we move this out from
> alpm code, and using it XferCommand or whatever (or implement new
> "external helper", if needed)?
>

How broken are they? More specifically, does this code need some minor
fixes or a complete overhaul?

BTW, this is on my big changes to get into Arch list, right behind
getting a testing repo for community. I even maintain xdelta as a reminder.

Allan



_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-16-2008, 11:52 AM
"Dan McGee"
 
Default String freeze for 3.2 release

On Wed, Jul 16, 2008 at 6:39 AM, Allan McRae <allan@archlinux.org> wrote:
> Nagy Gabor wrote:
>>
>> 2. Xav said, that deltas are broken. Couldn't we move this out from
>> alpm code, and using it XferCommand or whatever (or implement new
>> "external helper", if needed)?
>>
>
> How broken are they? More specifically, does this code need some minor
> fixes or a complete overhaul?
>
> BTW, this is on my big changes to get into Arch list, right behind
> getting a testing repo for community. I even maintain xdelta as a reminder.

The libalpm code isn't broken at all, actually- it is just missing the
scripting side of things in makepkg or repo-add. These scripts need
the components to generate "delta 2.0" format, and we came across some
problems with that, including compression, timestamps, and checksum
mismatches.

Xavier, do you remember where this all was? I thought this stuff was
on the ML but I'm not sure.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-16-2008, 12:06 PM
Nagy Gabor
 
Default String freeze for 3.2 release

> On Wed, Jul 16, 2008 at 6:39 AM, Allan McRae <allan@archlinux.org>
> wrote:
> > Nagy Gabor wrote:
> >>
> >> 2. Xav said, that deltas are broken. Couldn't we move this out from
> >> alpm code, and using it XferCommand or whatever (or implement new
> >> "external helper", if needed)?
> >>
> >
> > How broken are they? More specifically, does this code need some
> > minor fixes or a complete overhaul?
> >
> > BTW, this is on my big changes to get into Arch list, right behind
> > getting a testing repo for community. I even maintain xdelta as a
> > reminder.
>
> The libalpm code isn't broken at all, actually- it is just missing the
> scripting side of things in makepkg or repo-add. These scripts need
> the components to generate "delta 2.0" format, and we came across some
> problems with that, including compression, timestamps, and checksum
> mismatches.
>
> Xavier, do you remember where this all was? I thought this stuff was
> on the ML but I'm not sure.
>
> -Dan
>

Oh, good to hear. Then I'm sorry about misleading info. (I don't follow
this delta stuff at all, that's why I referred to Xavier).

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-16-2008, 01:51 PM
Xavier
 
Default String freeze for 3.2 release

On Wed, Jul 16, 2008 at 2:06 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
>> > How broken are they? More specifically, does this code need some
>> > minor fixes or a complete overhaul?
>> >
>> > BTW, this is on my big changes to get into Arch list, right behind
>> > getting a testing repo for community. I even maintain xdelta as a
>> > reminder.
>>
>> The libalpm code isn't broken at all, actually- it is just missing the
>> scripting side of things in makepkg or repo-add. These scripts need
>> the components to generate "delta 2.0" format, and we came across some
>> problems with that, including compression, timestamps, and checksum
>> mismatches.
>>
>> Xavier, do you remember where this all was? I thought this stuff was
>> on the ML but I'm not sure.
>>
>> -Dan
>>
>
> Oh, good to hear. Then I'm sorry about misleading info. (I don't follow
> this delta stuff at all, that's why I referred to Xavier).
>

The gzip / md5sum issue was discussed here between Nathan and I :
http://www.nabble.com/Add-delta-creation-to-repo-add.-td15513733.html#a15838665

To quote Nathan :
> For the first patch, I added the -n flag to gzip in order to prevent the
> md5sum problem. The apply-delta script is not as efficient as it could
> be. There is an extra gunzip+gzip step that could be avoided if we
> create a delta on the .tar rather than the .tar.gz. Doing so would
> complicate makepkg a bit, so I stuck with the extra step.

This extra gunzip+gzip step is quite disappointing indeed, since the
purpose of delta is efficiency.
Working directly on tar would solve this problem but would cause
another : increased disk usage, because the old and new packages would
need to be both uncompressed at some point (and this affects both
delta creation and application).
Maybe we need new delta benchmarks taking this into account now,
before spending more time?

The second biggest problem is lack of motivation and interest from everyone.
What is the point of having delta support if no one is going to use them?
But if people are going to use them, then we need feedback about how
it should work.
I don't know whether it would be better to have delta being generated
at makepkg step, or repo-add step, or both.
We have to take into account both the simplicity of usage but also of
implementation, and try to avoid duplication if we need delta support
in both.
In the end of the above thread, I proposed a quick summary of an
implementation only at repo-add level, but I don't know if it is a
good idea or if it is too limited or what.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-16-2008, 05:37 PM
Xavier
 
Default String freeze for 3.2 release

Nagy Gabor wrote:
> I sent my reply to Dan, but I wanted to send here (Dan: new 4. point;-).
>
>> I would like to get the release out in 7 days or so, so the sooner the
>> better for the translations.
>
> Wow. I bring up some thoughts here:
> 1. Some NEWS ideas. A. We should document API changes
> separated from other changes to help front-end writers. From my side I
> can recall 3 API changes: 8856146d71cb4cc512b0cf3414fbc231635822d3,
> d060e31be3586ce27382f80eaed7a9edf2c86aeb,
> 1fc83f4af6d827bf2e69c7a10e3d2010c9211974 (without deep investigation,
> alpm.h-diff should show almost everything). B. As user I would like to
> see new features separated from "memleak fixes" ;-). For example, new
> options: -Ru, --asexplicit, -S 'dep>=2.0' etc.

I am sure Dan would highly appreciate help on this
The NEWS file is tracked by git too, so you can submit patches for that
as well. You can provide the API changes and new features that you
consider important, and it could be completed later by others.

> 3. Front-ends should be able to free our new dynamic structs, e.g.
> pmdepmissing_t.

We should definitively solve this problem. Even if these memleaks only
happen on error cases, and they are relatively small.
The question is how. Dan does not want to make these free functions public.
Maybe we want to store these error lists in libalpm, and allow the
frontend to get it. And then it would be freed when the transaction is
freed?
Otherwise, maybe this is where it would help to have a free function
attached to the list structure.

> 4. <flame> Revert vercmp code to 3.1 </flame>
>

It would be nice to figure out what changed and why it doesn't work
anymore rather than simply reverting.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-16-2008, 06:18 PM
Nagy Gabor
 
Default String freeze for 3.2 release

> only happen on error cases, and they are relatively small.
> The question is how. Dan does not want to make these free functions
> public.

Why? I can't see too much difference between alpm_miss_get_causingpkg
(wow, new API change ;-) and alpm_miss_free.

> ... Maybe we want to store these error lists in libalpm, and
> allow the frontend to get it. And then it would be freed when the
> transaction is freed?

I don't like this. We should somehow differentiate pmdepmissing_t and
pmconflict_t ... lists, and we have more chance to do memleaks here.

> Otherwise, maybe this is where it would help to have a free function
> attached to the list structure.
>
> > 4. <flame> Revert vercmp code to 3.1 </flame>
> >
>
> It would be nice to figure out what changed and why it doesn't work
> anymore rather than simply reverting.
>

nicer, but harder ;-)
See 84283672853350a84d2a71b72dc06e180cad1587, search for 'type
mismatch'.

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 04:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org