[arch-dev-public] Status Report 2007-10-08
Time for another one! Sorry if this one is later than the rest - I've been a tad busy today. ---------- ArchLinux Status Report, 2007-10-01 == Newsworthy Items == * Testing Policy In order to provide a working system to all users, we are going to ensure that all packages in [core] always go through testing first. The core repo is critical enough to where if anything breaks, it is a big deal. Far different than if we broke gnumeric. Core packages should go to testing, and at least one other developer should "sign off" when they've tested it. For simplicity, if you want to skip the [testing] step for non "base" group packages, and provide a direct link to a package for others to sign off, that is fine - as long as 2 developers are accountable for the working state of that package. This shortcut should not be taken for packages in the base group. == Completed Tasks == * Move all Arch related projects to gerolde Looks like we're only missing one project, which we should be able to get to today, so I'm going to say this is "done". Thanks a lot guys. http://bugs.archlinux.org/task/7789 * AUR 1.4.0 Release Special thanks to everyone involved (eliott, tardo, louipc, xilon, thralas, and more). * Bugfix ISO Release With the release of the 2007.08-2 ISOs, we have a functional installer again. Our previous ISOs broke when we moved to the [core] repo. Special thanks to tpowa for all his hard work, and to all the testers who made it possible. * Devtools updates This was an item from last time that Dan and I completed. We have not yet released a new devtools tarball, as I'd like to wait for the chroot build tools to be complete. Ref: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html == Pending Tasks, Short Term == * db and heimdal out of [testing] The rebuilds have been in testing for some time, and I haven't seen any issues. If there are no show stoppers, we should be able to move these out this week. Could someone confirm this is the case? * Package and Orphan Cleanup Our list has grown, so thanks for all who've adjusted things here. https://www.archlinux.org/wiki/Repo%20Cleanup/ I'm not a fan of these "all orphans in XYZ" items though. Umbrella clauses such as this usually don't work too well - I'd prefer full definitions. Could someone fill those items in appropriately? * DVD and Additional Package ISO Lists We still have yet to fully define the packages we'd like to distribute on additional ISOs. Here I have created a stub https://www.archlinux.org/wiki/ISO-Packages/ Please use this to _explicitly_ list things you want or don't want on these additional ISOs. * Unified chroot build tools I have two automated tools slated for commit to devtools soon. I have a few fixes still to push up there (such as auto-generating a locale, using sudo, etc), but in general, they are in a working state. http://code.phraktured.net/?p=devtools.git;a=summary * Perl policy This item was previously listed as "Use vendor_perl for pacman perl packages", but I'm expanding it. This policy here: http://wiki.archlinux.org/index.php/Perl_Policy Was written by some perl pros, cross referenced with the Debian perl policy, and I think I agree with most of it. So I want to officially implement this. If you care about perl, lets discuss this. I, however, am going to begin with the following bug reports: http://bugs.archlinux.org/task/8082 http://bugs.archlinux.org/task/8236 http://bugs.archlinux.org/task/7530 http://bugs.archlinux.org/task/7587 == Pending Tasks, Long Term == * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 We're creeping slowly in this direction. Special thanks to Chantry Xavier for actually submitting patches, heh. * DB Script Rewrite This one went by the wayside. It appears we're sitting in one of those "not broke" modes. I'd still love to actually do this, but I'm moving it to the "long term" items, as it's not all that critical, ans there are better things to do. * Official pacbuild usage Jason sent out a status thread last week with where http://archlinux.org/pipermail/arch-dev-public/2007-October/001944.html * 'Continuous Integration' setup / machine The state hasn't changed much since last time. This is still more of a pipe-dream. Dan pointed out the fact that git actually ships with CI tools ("cidaemon" and "post-recieve-cidaemon") that we could take advantage of. * Modernize our Dashboard Eliott and Simo have been helping me out here. I'm going to give us all a nice document on setting up a local instance for the arch web interface, so we can develop on our own. In addition, we need to move the git repo to projects.al.org but we currently have passwords in there that need to be sanitized. * Architecture Independent Repos Added to flyspray: http://bugs.archlinux.org/task/8153 It appears that we can implement noarch packages with very little changes. This combines, in a way with the Pacman 3.1 release, and db script rewrites above. * ArchCon 2009: Big Baaad Idea Any ideas for a venue? I wonder, if we had a little donation drive to help the developers all get together, would that be cheating? http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html == Bugs and Issues == I didn't notice anything critical this time around - could someone fill in the blanks here, I didn't have time to scrape major issues together. ---------- Thanks everyone, for your continued hard work. In the upcoming weeks, I have a few grand plans I want to implement, but I'm waiting for a bit of a lull in these important items here. Stay tuned! -- Aaron
On Mon, 8 Oct 2007, Aaron Griffin wrote:
* Package and Orphan Cleanup
Our list has grown, so thanks for all who've adjusted things here.
https://www.archlinux.org/wiki/Repo%20Cleanup/
I'm not a fan of these "all orphans in XYZ" items though. Umbrella clauses such as this usually don't work too well - I'd prefer full definitions.
Me too.
Could someone fill those items in appropriately?
I started to add a few items. I intend to go through the list of all orphaned packages in extra and make 2 lists out of it: one list with all the packages that are (make)depends of packages owned by a dev and that needs to be adopted, and the other list of packages that can potentially be removed. I believe it will help speeding up the adoption/assignment process and will make the cleanup process easier as we'll be able to focus on a smaller package set. It'll probably be done later this week or next week-end. I'll post the 2 lists on the wiki when I'll be done. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Tue, 9 Oct 2007, Eric Belanger wrote:
On Mon, 8 Oct 2007, Aaron Griffin wrote:
* Package and Orphan Cleanup
Our list has grown, so thanks for all who've adjusted things here.
https://www.archlinux.org/wiki/Repo%20Cleanup/
I'm not a fan of these "all orphans in XYZ" items though. Umbrella clauses such as this usually don't work too well - I'd prefer full definitions.
Me too.
Could someone fill those items in appropriately?
I started to add a few items.
I intend to go through the list of all orphaned packages in extra and make 2 lists out of it: one list with all the packages that are (make)depends of packages owned by a dev and that needs to be adopted, and the other list of packages that can potentially be removed. I believe it will help speeding up the adoption/assignment process and will make the cleanup process easier as we'll be able to focus on a smaller package set. It'll probably be done later this week or next week-end. I'll post the 2 lists on the wiki when I'll be done.
The 2 lists are done and are in the wiki. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Am Dienstag, 9. Oktober 2007 01:11:52 schrieb Aaron Griffin:
* db and heimdal out of [testing]
The rebuilds have been in testing for some time, and I haven't seen any issues. If there are no show stoppers, we should be able to move these out this week.
Could someone confirm this is the case?
afaik rebuilding is done so far. In addition to this we have gnome and xorg in testing. Xorg has some issues which will prevent it from being moved to [extra]. Are there any packages which are explicitly built against new xorg? Perhaps we should rebuild them and move everything except xorg to [extra]. -- archlinux.de
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Pierre Schmitz Verzonden: dinsdag 9 oktober 2007 10:51 Aan: arch-dev-public@archlinux.org Onderwerp: Re: [arch-dev-public] Status Report 2007-10-08
Am Dienstag, 9. Oktober 2007 01:11:52 schrieb Aaron Griffin:
* db and heimdal out of [testing]
The rebuilds have been in testing for some time, and I haven't seen any issues. If there are no show stoppers, we should be able to move these out this week.
Could someone confirm this is the case?
afaik rebuilding is done so far. In addition to this we have gnome and xorg in testing. Xorg has some issues which will prevent it from being moved to [extra]. Are there any packages which are explicitly built against new xorg? Perhaps we should rebuild them and move everything except xorg to [extra].
When I built GNOME and put it in testing, I was using extra. This was done to ensure GNOME would be running fine with extra. At this moment the status of GNOME is quite good. I haven't seen many bugs in applications, some applications have a minor upstream upgrade that fixes the last outstanding issues in them, so updating to the latest versions and moving them to extra would be the good thing to do. One drawback however is GTK2, which is a dependency of GNOME 2.20. I don't have any problems with it, but it seems many people have problems with applications like Firefox and OpenOffice and certain theme engines. There's a patch on ubuntu launchpad that fixes these issues and GTK SVN trunk contains a lot of post-release fixes. So the TODO for GNOME: - Update GNOME apps to latest versions. - Take needed patches from GTK+ SVN and apply it to 2.12.0, add firefox crash patch from Ubuntu launchpad. - Patch gnome-network-manager to work with the new gnome-keyring when no keyring is available, patches and bugreports available - Try to fix evolution-exchange, seems to be something with new heimdal All other bugs I've seen are coming from the fact that Alex moved xorg.sh from xproto to libx11 in testing and people have a mix of old and new versions installed of these packages (or they have custom libx11 versions).
Am Mon, 8 Oct 2007 18:11:52 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
* Devtools updates
This was an item from last time that Dan and I completed. We have not yet released a new devtools tarball, as I'd like to wait for the chroot build tools to be complete.
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html
Please don't wait anymore. new devtools help a lot and are ready to use. Right now i have to fix the 32/64 suffix for all chroots by hand and spread it over all chroots. Pending issues/tasks: - checkpkg should also make use of PKGDEST and check if the old pkg already extists there. - integrate a switch to revert the upload/commit/tag/order - force to use checkpkg and namcap in extrapkg - devs have to prompt to go further - later mkchroot scripts Can we bytecompile namcap to have it together with devtools in core/devel without having python there? It would be helpful to have it there as long as we have usual "always staying" chroots. Once we create a new empty chroot for each pkg i think we have to make sure all our tools are usable inside the chroot. Andy.
On 10/13/07, Andreas Radke <a.radke@arcor.de> wrote:
Am Mon, 8 Oct 2007 18:11:52 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
* Devtools updates
This was an item from last time that Dan and I completed. We have not yet released a new devtools tarball, as I'd like to wait for the chroot build tools to be complete.
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html
Please don't wait anymore. new devtools help a lot and are ready to use. Right now i have to fix the 32/64 suffix for all chroots by hand and spread it over all chroots.
Pending issues/tasks: - checkpkg should also make use of PKGDEST and check if the old pkg already extists there. - integrate a switch to revert the upload/commit/tag/order - force to use checkpkg and namcap in extrapkg - devs have to prompt to go further - later mkchroot scripts
Can we bytecompile namcap to have it together with devtools in core/devel without having python there? It would be helpful to have it there as long as we have usual "always staying" chroots. Once we create a new empty chroot for each pkg i think we have to make sure all our tools are usable inside the chroot.
You shouldn't need to use tools INSIDE the chroot. You should chroot, makepkg, exit chroot, and THEN do any tests you need on the package itself.
Am Sun, 14 Oct 2007 19:22:19 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
You shouldn't need to use tools INSIDE the chroot. You should chroot, makepkg, exit chroot, and THEN do any tests you need on the package itself.
How do you want to use {check,repo}pkg to use with PKGDEST from outside chroot? This can only work when you use one common package destination directory and mount it into every chroot like i do with SRCDEST. But this is not what i have setup with PKGDEST so far. But if it's not possible in any other way I will have to change that. Andy
On 10/15/07, Andreas Radke <a.radke@arcor.de> wrote:
Am Sun, 14 Oct 2007 19:22:19 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
You shouldn't need to use tools INSIDE the chroot. You should chroot, makepkg, exit chroot, and THEN do any tests you need on the package itself.
How do you want to use {check,repo}pkg to use with PKGDEST from outside chroot? This can only work when you use one common package destination directory and mount it into every chroot like i do with SRCDEST.
I could add something to the chroot tools to move the package to the PKGDEST folder after leaving the chroot. That'd be one or two lines of code.
On Sat, Oct 13, 2007 at 03:03:32PM +0200, Andreas Radke wrote:
Am Mon, 8 Oct 2007 18:11:52 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
* Devtools updates
This was an item from last time that Dan and I completed. We have not yet released a new devtools tarball, as I'd like to wait for the chroot build tools to be complete.
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html
Please don't wait anymore. new devtools help a lot and are ready to use. Right now i have to fix the 32/64 suffix for all chroots by hand and spread it over all chroots.
Pending issues/tasks: - checkpkg should also make use of PKGDEST and check if the old pkg already extists there. - integrate a switch to revert the upload/commit/tag/order - force to use checkpkg and namcap in extrapkg - devs have to prompt to go further - later mkchroot scripts
Can we bytecompile namcap to have it together with devtools in core/devel without having python there? It would be helpful to have it there as long as we have usual "always staying" chroots. Once we create a new empty chroot for each pkg i think we have to make sure all our tools are usable inside the chroot.
Trying to compile a python program generally isn't a good idea. You end up bundling the interpreter + dependent modules + your source. It's really not worth it. I agree with Aaron that package checking should be done outside the chroot if possible (though the depends rule won't necessarily work correctly...). I usually just install python and namcap inside my chroots. Most things don't link to python. Jason
On Sat, Oct 13, 2007 at 03:03:32PM +0200, Andreas Radke wrote:
Am Mon, 8 Oct 2007 18:11:52 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
* Devtools updates
This was an item from last time that Dan and I completed. We have not yet released a new devtools tarball, as I'd like to wait for the chroot build tools to be complete.
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html
Please don't wait anymore. new devtools help a lot and are ready to use. Right now i have to fix the 32/64 suffix for all chroots by hand and spread it over all chroots.
Pending issues/tasks: - checkpkg should also make use of PKGDEST and check if the old pkg already extists there. - integrate a switch to revert the upload/commit/tag/order - force to use checkpkg and namcap in extrapkg - devs have to prompt to go further - later mkchroot scripts
I think it's probably better to release without the chroot stuff than waiting for it. I'll have to figure out which things we should include in the release (from the list of pending issues). I suspect just the checkpkg PKGDEST check. Jason
On 10/15/07, Jason Chu <jason@archlinux.org> wrote:
On Sat, Oct 13, 2007 at 03:03:32PM +0200, Andreas Radke wrote:
Am Mon, 8 Oct 2007 18:11:52 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
* Devtools updates
This was an item from last time that Dan and I completed. We have not yet released a new devtools tarball, as I'd like to wait for the chroot build tools to be complete.
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html
Please don't wait anymore. new devtools help a lot and are ready to use. Right now i have to fix the 32/64 suffix for all chroots by hand and spread it over all chroots.
Pending issues/tasks: - checkpkg should also make use of PKGDEST and check if the old pkg already extists there. - integrate a switch to revert the upload/commit/tag/order - force to use checkpkg and namcap in extrapkg - devs have to prompt to go further - later mkchroot scripts
I think it's probably better to release without the chroot stuff than waiting for it. I'll have to figure out which things we should include in the release (from the list of pending issues). I suspect just the checkpkg PKGDEST check.
This is part of the reason why the chroot tools are all entirely on my own repo. If we release everything on gerolde right now, all bases are covered.
participants (6)
-
Aaron Griffin
-
Andreas Radke
-
Eric Belanger
-
Jan de Groot
-
Jason Chu
-
Pierre Schmitz