On Jan 6, 2008 9:18 PM, Travis Willard wrote:

On Jan 5, 2008 7:30 PM, Dan McGee wrote:

...

Travis- I'll send you more details soon so we can get a corresponding abs package release together.

Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.

Fine with me. The whole idea here was to decouple first, and then develop later. Might as well keep what works, even if not perfectly ideal.

I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.

Cool. Feel free to push it off to testing whenever you want. Can someone create a ftp directory called other/abs perhaps? That might make more sense than grouping it under pacman/. -Dan

On 1/7/08, Travis Willard wrote:

On Jan 6, 2008 10:24 PM, Dan McGee wrote:

...

On Jan 6, 2008 9:18 PM, Travis Willard wrote:

...

On Jan 5, 2008 7:30 PM, Dan McGee wrote:

...

Travis- I'll send you more details soon so we can get a corresponding abs package release together.

Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.

Fine with me. The whole idea here was to decouple first, and then develop later. Might as well keep what works, even if not perfectly ideal.

...

I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.

Cool. Feel free to push it off to testing whenever you want. Can someone create a ftp directory called other/abs perhaps? That might make more sense than grouping it under pacman/.

Writable by the abs-git group? :)

oh. I forgot to reply. Dan caught me on jabber last night and prodded me to get this done. So you should now find the /ftp/other/abs/ directory, and it should have appropriate user/group permissions.

On Jan 6, 2008 9:18 PM, Travis Willard wrote:

On Jan 5, 2008 7:30 PM, Dan McGee wrote:

...

Travis- I'll send you more details soon so we can get a corresponding abs package release together.

Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.

I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.

Final update of pacman-git tonight so it can be installed side-by-side with testing/abs. PLEASE report anything, otherwise source tarball release happens tomorrow. Slight updates to the webpage too: http://www.archlinux.org/pacman/, and notably to the translation-help file. I'll be looking for a translation lieutenant/coordinator for the next release (described in the document), so if anyone is interested, please send me an email. I'd like this to be someone who knows enough about GIT that they will be able to manage the inflow of a mix of patches and PO files, publish a git repository somewhere (if need be, I can provide space), and allow me to merge translations from their tree when necessary (just before a release). -Dan

On Jan 8, 2008 9:15 AM, Roman Kyrylych wrote:

2008/1/8, Dan McGee :

...

On Jan 6, 2008 9:18 PM, Travis Willard wrote:

...

On Jan 5, 2008 7:30 PM, Dan McGee wrote:

...

Travis- I'll send you more details soon so we can get a corresponding abs package release together.

Just an FYI - I'll be releasing this ABS as the old 'cvsup' version - I haven't had time to really play with the rsync implementation yet, and since the cvsup version works at current, we'll just run with it so we can get the new pacman out the door.

I've got the proto files in my local branch for ABS, and I'll be pushing them to projects.archlinux.org soon. After that, it's ready for release in its current form.

Final update of pacman-git tonight so it can be installed side-by-side with testing/abs. PLEASE report anything, otherwise source tarball release happens tomorrow.

Slight updates to the webpage too: http://www.archlinux.org/pacman/, and notably to the translation-help file. I'll be looking for a translation lieutenant/coordinator for the next release (described in the document), so if anyone is interested, please send me an email. I'd like this to be someone who knows enough about GIT that they will be able to manage the inflow of a mix of patches and PO files, publish a git repository somewhere (if need be, I can provide space), and allow me to merge translations from their tree when necessary (just before a release).

just a very small notice: since abs is not a part of Pacman anymore, this line can be removed from NEWS: - allow abs to not be included (FS#7319)

Good call. I'll change it to "ABS removed from pacman package" or something. Any other NEWS updates while we are at it? Speak up today, please. -Dan

Good call. I'll change it to "ABS removed from pacman package" or something.

Any other NEWS updates while we are at it? Speak up today, please.

-Dan

http://www.archlinux.org/pipermail/pacman-dev/2007-December/010585.html Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

Idézés Aaron Griffin :

On Jan 8, 2008 10:45 AM, Nagy Gabor wrote:

...

...

Good call. I'll change it to "ABS removed from pacman package" or

something.

...

Any other NEWS updates while we are at it? Speak up today, please.

-Dan

http://www.archlinux.org/pipermail/pacman-dev/2007-December/010585.html

Um, the point 1 there says "we implemented new features"... isn't that what we're trying to assess? WHICH new features?

Maybe I was wrong, and only one, I dunno. I referred here to the fact that we did some git commits after the last NEWS modification. But I cannot say more than 'git log' ;-) [I mentioned "my" new feature, and a hidden new feature.] Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

Good call. I'll change it to "ABS removed from pacman package" or something.

Any other NEWS updates while we are at it? Speak up today, please.

-Dan

1. I did a quick compare between _parseconfig and pacman.conf manual, I found the following undocumented keys: -ILoveCandy (what's this ?;-) -UseColor -UpgradeDelay 2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

Idézés Dan McGee :

On Jan 8, 2008 10:55 AM, Nagy Gabor wrote:

...

...

Good call. I'll change it to "ABS removed from pacman package" or

something.

...

Any other NEWS updates while we are at it? Speak up today, please.

-Dan

1. I did a quick compare between _parseconfig and pacman.conf manual, I found the following undocumented keys: -ILoveCandy (what's this ?;-) -UseColor -UpgradeDelay

Anyone is free to write documentation, I feel like I've about done my share...

...

2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing

Same as above...

Even if it isn't perfect English, it saves me time. Just write it to the style of already-documented options, I'll fix up the grammar.

Sorry, I cannot do this today (<- I announce this to avoid waiting for me -- pacman is released soon), because I'm writing from a windows terminal of a library... Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

On Jan 8, 2008 11:48 AM, Nathan Jones wrote:

On Tue, Jan 08, 2008 at 05:55:30PM +0100, Nagy Gabor wrote:

...

1. I did a quick compare between _parseconfig and pacman.conf manual, I found

...

-UseColor

Currently doesn't do anything; no need to document it either.

...

-UpgradeDelay

Never noticed that one before, had to look through the code to see what it did. It's actually a pretty neat feature.

Not sure if this actually works, thats my only concern. I've never tested it.

...

2. Some notes for pacman manual: -S documentation is not complete (groups!, providers) -R group is also missing

I'll try to add these plus the UpgradeDelay within the hour.

Thanks a bunch. Release in about 12 hours more than likely so you have plenty of time. :) -Dan

Nathan Jones wrote:

Looks like it doesn't work :) The problem seems to be that pkg->date is never set anywhere (this is actually the only function that references it). I think changing it to pkg->builddate will work.

int _alpm_pkg_istoonew(pmpkg_t *pkg) { time_t t;

ALPM_LOG_FUNC;

if (!handle->upgradedelay) return 0; time(&t); return((pkg->date + handle->upgradedelay)> t); }

That's a funny feature indeed. People who always complain about stability could get upgrades always a few days later so that other people test them first :) Indeed, pkg->date isn't set and used anywhere. It could probably be removed. builddate is set, but it isn't in the sync db, so it wouldn't work either. But the only way for this feature to work would be to add the builddate to the db, right? Hmm, now that I'm thinking about it, I'm not sure build date is the correct value. Shouldn't it rather be the date when the package is moved to the stable repos rather? (I'm thinking about packages that stay a period in testing first, and never the same delay). But more generally, just the date when the package is added to the repo would do.

Dan McGee wrote:

This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.

Any reason not to just kill it completely?

No, as Nathan said, it's broken. And I think it's not possible to fix it with the current sync dbs, so we might as well remove it. And the implementation is rather simple anyway.

Nathan Jones wrote:

On Tue, Jan 08, 2008 at 09:16:52PM +0100, Xavier wrote:

...

Dan McGee wrote:

...

This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.

Any reason not to just kill it completely?

No, as Nathan said, it's broken. And I think it's not possible to fix it with the current sync dbs, so we might as well remove it. And the implementation is rather simple anyway.

My test repo and community has the BUILDDATE field in it, but core and extra do not.

Oops, yes you're right, I'm just blind. I just saw it wasn't there in core / extra. Then I checked the repo-add script, and I didn't find the BUILDDATE field... But yes, it's there indeed. And community does have that field. So it works alright with community repo (after the date -> builddate change). But anyway, I think I agree with Dan finally, this feature might be a bit wrong.

On 1/10/08, Jason Chu wrote:

On Tue, Jan 08, 2008 at 02:13:53PM -0600, Dan McGee wrote:

...

On Jan 8, 2008 1:48 PM, Xavier wrote:

...

Nathan Jones wrote:

...

Looks like it doesn't work :) The problem seems to be that pkg->date is never set anywhere (this is actually the only function that references it). I think changing it to pkg->builddate will work.

int _alpm_pkg_istoonew(pmpkg_t *pkg) { time_t t;

ALPM_LOG_FUNC;

if (!handle->upgradedelay) return 0; time(&t); return((pkg->date + handle->upgradedelay)> t); }

That's a funny feature indeed. People who always complain about stability could get upgrades always a few days later so that other people test them first :)

Indeed, pkg->date isn't set and used anywhere. It could probably be removed. builddate is set, but it isn't in the sync db, so it wouldn't work either. But the only way for this feature to work would be to add the builddate to the db, right?

Hmm, now that I'm thinking about it, I'm not sure build date is the correct value. Shouldn't it rather be the date when the package is moved to the stable repos rather? (I'm thinking about packages that stay a period in testing first, and never the same delay). But more generally, just the date when the package is added to the repo would do.

This seems like a feature introduced to solve a problem the wrong way. If people didn't release broken packages, this really wouldn't be necessary.

Any reason not to just kill it completely?

-Dan

If I recall correctly it came into being after I talked with Judd or Aaron...

I didn't think it was really necessary, but it was a stop gap between having a stable/better tested repo and what we had before Aaron came in with the testing policy (which hasn't been a silver bullet).

I think it's probably too late to weigh in on whether it should stay or not, but this is where it came from. I'm nothing if not a living history of Arch Linux development ;)

Just so long as you don't turn into Eric Raymond.... ;)

Dan McGee wrote:

On Jan 8, 2008 3:21 PM, Allan McRae wrote:

...

Nathan Jones wrote:

...

++ +In addition to packages, groups can be specified as well. For +example, `pacman -S gnome` will install every package in the gnome +group, as well as the dependencies of those packages.

Minor point, but since pacman has moved to being distribution agnostic, do we want to mention specific package names or stick to "foo"? This would look strange on a distro that didn't provide GNOME.

Valid point though, although I think real package names help people out.

"For example, if gnome is a defined package group, pacman -S gnome will..."

sound ok? Yes. That is probably a better way to get around the issue.