[pacman-dev] Release Schedule for 3.0
Pacman 3.0 Release Schedule =========================== 2007-01-31 For those of you used to these sorts of schedules, this may seem a big aggressive, for those of you NOT used to it, it may seem slow. I think this is a decent middle ground. I would not want either testing cycle to go LESS than one week, but they could go longer. We should also setup a bug tracker category (temporarily) for pacman 3.0 testing, to get a concise category for bugs and the like. This was suggested by Dan. The following schedule should give us enough time to iron out any and all issues remaining. It is not set in stone, but gives us something to strive for. * 01-31 to 02-07 (one week): RC Testing. Remaining bug fixes This is our current setup where it seems to be only devs and people on pacman-dev doing testing * 02-07 to 02-14 (one week): Public testing - NOT in repos yet Provide a URL in a news item or forum announcement * 02-14 / 02-15: Release to [testing] repo At this point we will also remove the "side-by-side" scheme (pacman-rc -> pacman) currently used * 02-15 to 02-22 (one week): Public testing This is aggressive and will require us to actually prod people to test / report things * 02-22 / 02-23: Release to [current] * 02-23 - 03-01: Watch and wait for some time. There will be problems at this point and we should address them ASAP. * 03-01 +: Begin pacman 3.1 feature additions and other fun stuff
On 1/31/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Pacman 3.0 bugcatcher: http://bugs.archlinux.org/task/6316 If you have anything to add to it, write it in the comments. We are trying to keep this realistic- so feature requests should wait, we are just talking bugs here. -Dan
On 1/31/07, Aaron Griffin <aaronmgriffin@gmail.com> 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?
On 2/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
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
Just a quick update: The bugcatcher is here - http://bugs.archlinux.org/task/6316 I would like to close the following as soon as possible: * http://bugs.archlinux.org/task/4514 undocumented makepkg options * http://bugs.archlinux.org/task/5887 removing a package on a readonly filesystem * http://bugs.archlinux.org/task/5775 dependency issues * http://bugs.archlinux.org/task/5388 -S and -Su respecting option=(force) The other two feature requests on there: * http://bugs.archlinux.org/task/5909 redownload on corrupt package * http://bugs.archlinux.org/task/5571 the contentious -A/-U to -I request These will most likely be deferred for the moment. 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). Annnnyway. Here's the rundown. I want to close out the 4 bugs about ASAP and push out a new RC for you all to test with. I would love it if someone could test both 5887 and 5775, and let me know the results. I will see what i can do about the -S/-Su check AND makepkg documentation in the next few hours. If there are any pending issues not mentioned here, not mentioned here, now is the time to bring them up. Thanks!
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 <aaronmgriffin@gmail.com> wrote:
The bugcatcher is here - http://bugs.archlinux.org/task/6316
Em Qua 07 Fev 2007, Aaron Griffin escreveu:
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.
2007/2/7, Douglas Soares de Andrade <dsandrade@gmail.com>:
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:
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 ?
2007/2/7, Douglas Soares de Andrade <dsandrade@gmail.com>:
I agree. It must be required. -- Roman Kyrylych (Роман Кирилич)
On 2/7/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
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?)
2007/2/7, Aaron Griffin <aaronmgriffin@gmail.com>:
Well, it could not be required by pacman and gensync, but must be required by makepkg, I think. 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). -- Roman Kyrylych (Роман Кирилич)
On 2/7/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
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.
2007/2/7, Aaron Griffin <aaronmgriffin@gmail.com>:
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 (Роман Кирилич)
On 2/7/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
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.
2007/2/7, Aaron Griffin <aaronmgriffin@gmail.com>:
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 (Роман Кирилич)
While on the whole license issue, I'll make a key point- since makepkg 2 did not even present a warning with a missing license, I think it would be a big change to make it required. At least now there is a warning, and in the future we can upgrade the warning to an error quite easily. -Dan
On 2/7/07, Roman Kyrylych <roman.kyrylych@gmail.com> 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 Wed, 7 Feb 2007 01:26:17 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
New (and hopefully final) RC: http://archlinux.org/~aaron/pacman/pacman-rc-3.0.0-9.pkg.tar.gz
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) Running pacman -U on the local file, after downloaded, worked fine though. :/ I can reproduce it consistently with pacman rc8, but not with rc9 - fixed between rcs? -- Travis
On 2/7/07, Travis Willard <travisw@wmpub.ca> wrote:
Looks like this isn't isolated. Jason had the exact same problem ('itch' and all). Stomping on memory is always fun. I'll make a note to look at the -U download code tonight.
2007/2/7, Aaron Griffin <aaronmgriffin@gmail.com>:
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
On 2/7/07, Alessio 'mOLOk' Bolognino <themolok.ml@gmail.com> wrote:
This operation uses the undocumented -D argument to pacman. I'm not that familiar with it, and I'm not a fan of undocumented arguments, but I am guessing it was never updated to perform a transaction to the likes of -Ss where it does not need to lock the DB. -Dan
Well... yet another poor and boring bug report (look at the attachment) -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User
On 2/7/07, Alessio 'mOLOk' Bolognino <themolok.ml@gmail.com> wrote:
Well... yet another poor and boring bug report (look at the attachment)
This is a bug in the file program, as far as I know. Try running `file -biz` on the downloaded archive, it will likely return application/empty. If you run it enough, it usually switches to the correct type. I was in contact with the author of the file program and it will be fixed in the 4.20 release. -Dan
participants (6)
-
Aaron Griffin
-
Alessio 'mOLOk' Bolognino
-
Dan McGee
-
Douglas Soares de Andrade
-
Roman Kyrylych
-
Travis Willard