- Arch-dev-public - lists.archlinux.org

[arch-dev-public] test
by Aaron Griffin 15 May '07

15 May '07

gerolde reboot, testing the ml

1 0

[arch-dev-public] FTP (re)organization
by Thomas Bächler 15 May '07

15 May '07

While discussing with Dale about where to put the new isos, the issue of the ftp organization came up: Right now, we have subdirectories, 0.1, ..., 0.8 and current is a symlink to 0.8. This is bad for several reasons. It suggests that we have a "release", which we don't. And everytime we release a new version, we move 0.X to 0.Y, and re-set the current symlink, that means the mirrors will re-pull all the current packages (which they already have, but download anyway). I suggest doing this for cleanup: - rm current; mv 0.8 current (I know this will cause the same problem as described above, but at least it will be the last time) - rm release - remove all isos from current/iso/* and replace them with the new ones (this means we won't keep the old isos, but do we need them?) - ln -s current/iso iso-download so that people can find the isos more easily on the mirror. Any objections/suggestions?

10 23

[arch-dev-public] duke isos i686 ready for testing
by Tobias Powalowski 14 May '07

14 May '07

Hi guys just to inform you new duke isos are hosted here meanwhile: http://www.archlinux.org/~tpowa/duke-isos/ they are not tested yet at all, will do some tests tomorrow, if you have time try to break them here is the changelog: Hi Arch community, Arch Linux Duke Changelog to last Voodoo installation ISO: - pacman3 usage - kernel 2.6.21.1 usage Setup changes: - soundcards are now also ordered by hwdetect - rsync has been added to installation environment - proxy support during ftp installation - selection to copy installation network setup to final system - selection about keeping package cache during cd/ftp installation - selection of primary pacman sync server added greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 13

[arch-dev-public] bugtracker vs package cleanup
by Roman Kyrylych 13 May '07

13 May '07

Because many packages will be moved to Community I'd like to point few things regarding our bugtracker: 1) there is some amount of open bugreports for packages that are moving to Community/Unsupported. 2) there will be more packages in Community which means there will be larger amount of bugs in them (summarized). Maybe it's a time now to create a new project in Flyspray for Community packages, and give all TUs permissions to assign/edit/close bugs in that project? Besides of a bit better tracking of bugs in Community packages this will allow to move those open bugreports for Community packages to new Flyspray's project. Or should Community packages continue to use AUR comments for reporting and discussing bugs? Opinions? -- Roman Kyrylych (Роман Кирилич)

5 7

[arch-dev-public] we want to give x86_64 a new direction
by Andreas Radke 13 May '07

13 May '07

after beeing an official port as a 100% i686 clone with a common cvs we have seen that we can handle the workload with only 2 man in not a bad way but with tons of hours of rebuilding and uploading the packages. but we don't want that anymore. it's simply too much workload and a task we are tired to do. bringing on new packagers is harder than expected. repo cleanups and a possible not to far away start of pacbuild/repoman will not drop down the workload we would need. i686 devs are not able to handle 32bit stuff very well so i don't count on crossbuilds anymore. that's one reason. the other one is beeing an i686 clone depending on its (not well defined) goals makes me sick. i miss any freedom in my work. at least the poor i686 testing procedure is something i don't want to follow anymore. i got more and more afraid how chaotic the developement is going on whithout the possebility to change it. now i see things start changing what is very good. but it seems most devs want to keep i686 the compromise of beeing bleading edge + at least some stability. i haved proved to build a system almost from scratch to the quality we now have. we are no more behind i686. a big part of that goes to the i686 devs and their most times simple and working packages and the easiness to port them. the Arch tools are great. but my personal goals have changed. together with Daniel we have found a few people that would support us if can go our own way. We have worked out some initial goals: - we want Arch x86_64 the more conservative sister distribution of Arch - less bleading edge - still a rolling system with up to date packages - strict rules how packages go through a testing cycle - we expect a significant lower workload due to longer update cycles and less post-release-fixing of broken stuff - only provide a basic core repo by the devs - setup some basic addon repos - open the addon repos to be maintained by the community and reviewed/released by the developers untill community members have proved to do it the same way. that's something where we are not sure where i686 wants to go and if we will adopt it. - it would not be prepared to have an x86 port. but only one x86(i586?) dev would be enough to rebuild that distro with some help by an automated build system. All in all it would be nothing significant different from the port we now have but packages would be more selected and hit the repos later to ensure the improved stability. we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers. the first step that would need to be done is to splitout our scm. i cannot image to keep working with a common scm. that's what now makes it the clone we don't want to have any longer. if you agree to give us that freedom back, i already have one good candidate for becoming a new x86_64 developer and several community members promised to help out. they all like our goals. at least that we will have some. AndyRTR

5 9

[arch-dev-public] -ARCH package extension
by Paul Mattal 13 May '07

13 May '07

Since pacman 3, makepkg builds: foo-2.9-1-i686.pkg.tar.gz instead of the old foo-2.9-1.pkg.tar.gz What is our migration path for using that in all the repos? More specifically: * How do we tell pacman to start using the new syntax when looking for packages? Do we need to, or do the repo db files take care of that? * How do we synchronize the update of devtools and aurtools? * How do we control/manage the propagating all that via mirrors, since all the filenames will change and each mirror will essentially want to do a full re-download? * Do we announce some time for a flashover and tell devs not to update packages during that time? Maybe someone's already figure this all out, but it would be nice to know how this is going to be handled so we can decide what to do to plan ahead. - P

6 12

[arch-dev-public] thoughts about next release
by Roman Kyrylych 13 May '07

13 May '07

Hi! As Tobias said: "kernel 2.6.21 series is now in testing, it will be the kernel series for next release". According to the schedule published by Paul repositories reorganization will be finished not earlier than in the middle of Summer. And in this announcement http://www.archlinux.org/news/308/ we said that "When the next kernel 2.6.22 is released, we will push out a new ISO image". So, here's how I see variants for next release: 1) release new ISOs based on 2.6.21, using the current scheme (ftp+base+current) additional possible changes: * provide snapshot of extra (and community?) for download via BitTorrent * FTP reorder as described here: http://www.archlinux.org/mailman/private/arch-dev/2007-March/005087.html 2) wait until 2.6.22 (hopefully it will be released after repositories reorganization) or even a bit longer and release new ISO set: core & ftp as CDs and main(extra) + community snapshots as DVDs. Changes that should be done in any case: * remove release version and codename from /etc/issue * remove /etc/arch-release * call new release as "ISO release" or "snapshot" instead of "Arch release" * make users understand that there's no such thing as "release" in Arch Linux. :-) -- Roman Kyrylych (Роман Кирилич)

6 12

[arch-dev-public] pr0n on flyspray!
by Roman Kyrylych 13 May '07

13 May '07

Please ban this user: http://bugs.archlinux.org/user/1906 He just posted a comment with attached pr0n file here: http://bugs.archlinux.org/task/6757#comment16273 (already deleted by me) -- Roman Kyrylych (Роман Кирилич)

2 2

[arch-dev-public] Package cleanup - implementation
by Aaron Griffin 12 May '07

12 May '07

This is a note for the developers. If you haven't seen the busy thread on the general list regarding package cleanup, this wiki page should cover everything: http://wiki.archlinux.org/index.php/Package_Cleanup Before the end of the weekend, I'm going to move most of these packages based on what is there. There are a few that are questionable, however, so please voice you opinions if you don't want things touched. Thanks Aaron

6 11

[arch-dev-public] mkinitcpio 0.5.14
by Thomas Bächler 12 May '07

12 May '07

I released mkinitcpio 0.5.14 today. Here is a short, incomplete changelog: - drops you into a fallback shell if the root device couldn't be found - modprobe is now in /sbin instead of /bin. As this is consistent with the main system, we do not have to change it back before calling kinit. Therefore kernel module autoloading can still be done while kinit is running, may fix some rare issues. I also updated klibc-udev, mdadm, cryptsetup and lvm2 to use the new path and added a symlink in /bin just to be sure - a small bugfix to allow shared objects to be used in BINARIES (came up when archboot tried to add portmap, which according to file is not an executable, but a shared object, wtf?). - more bug fixes (and bugfixes to fox bugfixes) This should be on the Duke iso, too. Have fun Thomas

1 0