On 2/2/07, Aaron Griffin wrote:

Just wanted to poke you all about the RC. wizzo sent a nice BUG email (see the list), but so far, that's all I've seen.

Does anyone else have any issues with the current RC?

Shadowhand mentioned this bug on IRC: the PKGDEST variable seems to not be respected. Not sure if this holds for SRCDEST as well. I would guess our recent changes in this area messed something up, some further testing may be needed. This may wait, but we still have the undocumented flags in pacman of -D, -T, and -Y. Are all these really necessary, and can we remove some of them? Another option would be to consolidate them all to -M (for --makepkg), since I believe that is where they are all used, and then have suboptions to select the correct feature. At the very least, is there a reason they are documented nowhere? -Dan

New (and hopefully final) RC: http://archlinux.org/~aaron/pacman/pacman-rc-3.0.0-9.pkg.tar.gz There's a bunch of changes here, that I can't really list at the moment. You can see them in the CVS commits on this list. As always, please report anything and everything. Even if it's all working as it should, please let me know (I'm trying to gauge how many people we have testing, as well). There are still 3 pending bugs, listed below. If you have the capacity to test any of them (well, 2 of them), please try it out, as they are blocking us right now. Thanks guys! On 2/6/07, Aaron Griffin wrote:

The bugcatcher is here - http://bugs.archlinux.org/task/6316

* http://bugs.archlinux.org/task/4514 undocumented makepkg options Pending still - documentation can hold for a little bit longer

* http://bugs.archlinux.org/task/5887 removing a package on a readonly filesystem This requires a proper setup, which no one seems to have - does anyone have /usr on a separate partition and wants to help out testing?

* http://bugs.archlinux.org/task/5775 dependency issues This is an odd one, see the bug report comments.

* http://bugs.archlinux.org/task/5388 -S and -Su respecting option=(force) Fixed, closed.

* http://bugs.archlinux.org/task/5909 redownload on corrupt package * http://bugs.archlinux.org/task/5571 the contentious -A/-U to -I request Both of these are defered until 3.1 as non critical.

There are a few other backend things which need to be done before an official release (devtools, arch/scripts/ changes, gensync and updatesync), but we can still push along the release schedule without those changes (well, gensync and updatesync are important). These script changes are still pending, but altogether they shouldn't be more than an hours worth of work. pacman is most important here.

2007/2/7, Douglas Soares de Andrade :

Hi Aaron,

I tried to update pacman3 with pacman3:

[douglas@ressonance bin]$ pacman3 -U pacman-rc-3.0.0-9.pkg.tar.gz loading package data... done.checking dependencies... done. cleaning up... done. (1/1) checking for file conflicts [###################################################################] 100% error: failed to prepare transaction (conflicting files) pacman-rc: /usr/man/man8/makepkg.8.gz exists in filesystempacman-rc: /usr/man/man8/pacman.8.gz exists in filesystem errors occurred, no packages were upgraded.

I know i can use -f, but i guess we can avoid this kind of error.

That's because both pacman and pacman-rc have this file. Aaron, can we rename it while pacman3 is not final? Or just suggest all testers to install pacman with -f? -- Roman Kyrylych (Роман Кирилич)

Em Quarta 07 Fevereiro 2007, Roman Kyrylych escreveu:

2007/2/7, Roman Kyrylych :

...

2007/2/7, Douglas Soares de Andrade :

...

Hi Aaron,

I tried to update pacman3 with pacman3:

[douglas@ressonance bin]$ pacman3 -U pacman-rc-3.0.0-9.pkg.tar.gz loading package data... done.checking dependencies... done. cleaning up... done. (1/1) checking for file conflicts [###################################################################] 100% error: failed to prepare transaction (conflicting files) pacman-rc: /usr/man/man8/makepkg.8.gz exists in filesystempacman-rc: /usr/man/man8/pacman.8.gz exists in filesystem

There was no space between filesystem and pacman-rc on your terminal?

No, this is as it was in my terminal.

Then we have another small newline bug not fixed.

I agree. There is another issue i want to discuss. The License field shoud not be required ? Today it is just a warning and i guess we should make it required, so we can keep track of what is opensource, what is proprietary and so on. People usually will tend to just ignore the warning and situation will be as it is today. What do you guys think ?

On 2/7/07, Roman Kyrylych wrote:

2007/2/7, Douglas Soares de Andrade :

...

There is another issue i want to discuss. The License field shoud not be required ? Today it is just a warning and i guess we should make it required, so we can keep track of what is opensource, what is proprietary and so on. People usually will tend to just ignore the warning and situation will be as it is today.

What do you guys think ?

I agree. It must be required.

I think it should be required EVENTUALLY, but for right now, so we don't break 95% of the official packages and AUR packages, we leave it as a warning and move it as "required" later on (3.1 release?)

Em Quarta 07 Fevereiro 2007, Roman Kyrylych escreveu:

2007/2/7, Aaron Griffin :

...

On 2/7/07, Roman Kyrylych wrote:

...

2007/2/7, Douglas Soares de Andrade :

...

There is another issue i want to discuss. The License field shoud not be required ? Today it is just a warning and i guess we should make it required, so we can keep track of what is opensource, what is proprietary and so on. People usually will tend to just ignore the warning and situation will be as it is today.

What do you guys think ?

I agree. It must be required.

I think it should be required EVENTUALLY, but for right now, so we don't break 95% of the official packages and AUR packages, we leave it as a warning and move it as "required" later on (3.1 release?)

Well, it could not be required by pacman and gensync, but must be required by makepkg, I think.

Yes, i was talking about makepkg.

So if user makes or upgrades a package, he/she must fill license field. If user want's just to upgrade or rebuild official package using ABS then he/she must update PKGBUILD to use proper license field (if user doesn't want to bother with this - it can be worked around as license="unknown" - for the laziest users).

2007/2/7, Aaron Griffin :

On 2/7/07, Roman Kyrylych wrote:

...

If user want's just to upgrade or rebuild official package using ABS then he/she must update PKGBUILD to use proper license field (if user doesn't want to bother with this - it can be worked around as license="unknown" - for the laziest users).

But this, however, is the problem. All of the sudden, users can't build packages from ABS or with aurbuild because of the missing field. Not everyone will know what to do. "Add the license field? What does that mean" etc etc. The arch=() tag is a safeguard, and easy to add for i686 (I think the TUs know about this by now, I stickied a post about it). The problem is that the license field is more difficult to add across the board. This is why I suggest an interim period (3.0 to 3.1) where it is not required, but warned severely (we can switch 'warning' to 'error' to indicate as such), but we should still allow those packages to be built for now.

OK, there's no problem in not requiring license field until 3.1. But my thought is that when user uses aurbuild then he/she built it once, then he/she knows how to build packages!, so it won't be hard for him/her to add license field and notify package maintainer about this (and bug mantainer until he fixes his package), so user won't have to do this next time when autoupdating packages with aurbuild/qpkg/yaourt/whatever. :-P But I agree that we live in non-ideal world. :-) -- Roman Kyrylych (Роман Кирилич)

2007/2/7, Aaron Griffin :

On 2/7/07, Roman Kyrylych wrote:

...

so it won't be hard for him/her to add license field and notify package maintainer about this (and bug mantainer until he fixes his package)

Just for the record, though, what I'm trying to say is that adding a license to an AUR package is *non-trivial*. What about dual licensed packages? Is it 'GPL' or 'GPL2' or 'GPLv2' ? Where do I find that info? What about custom licenses. What if it has 3 custom licenses. What if it has a common(ish) license that's just not there yet, do I add that as a custom license or not? It's complex. It's not as simple as just adding a line to the PKGBUILD. And if we force people to add "license=unknown" then we're not really forcing much except some extra typing.

OK, I agree with your point. We have some guidelines on wiki about using license field. But I think it should be extended. GPL = GPL v2 "or (at your opinion) any later version" GPL2 = GPL v2 _only_ GPL3 = GPL v3 "or (at your opinion) any later version" BSD/ZLIB/etc = same as custom (BTW should we should add Artistic? I saw few packages licensed with it, IIUC it should be treated in the same way as BSD/ZLIB/etc.) custom = /usr/share/licenses/package-foo-bar/* - there can be different licenses. something like license=('GPL' 'BSD' 'custom') should be treated as GPL + all licenses in /usr/share/licenses/package-foo-bar/ -- Roman Kyrylych (Роман Кирилич)

On 2/7/07, Roman Kyrylych wrote:

There was no space between filesystem and pacman-rc on your terminal? Then we have another small newline bug not fixed.

Actually, that is fixed. It was a bug in rc8, but this was installed with rc8.

On 2/7/07, Travis Willard wrote:

Well that was odd:

$ pacman -U http://archlinux.org/~aaron/pacman/pacman-rc-3.0.0-9.pkg.tar.gz

pacman-rc-3.0.0-9 1174K 458.1K/s 00:00:02 [##############] 100% loading package data... error: failed to add target 'itch.' (could not find or read file)

itch? what the hell?

2007/2/7, Aaron Griffin :

New (and hopefully final) RC: http://archlinux.org/~aaron/pacman/pacman-rc-3.0.0-9.pkg.tar.gz

While installing kdebase (pacman was still downloading the deps) I tried to make the pkg of enemy-territory, is this (see the attachment) what you aspect makepkg3 to do? (I don't think so :) -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User

Well... yet another poor and boring bug report (look at the attachment) -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User