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

[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] new gcc compiler in testing, better java support now
by Jan de Groot 01 May '07

01 May '07

A new compiler snapshot has been uploaded to testing. Lots of new things, many bugfixes, etc. The most important thing here is that gcc-gcj uses eclipse-ecj to compile itself and all programs compiled with gcj. This makes gcc-gcj completely java 5.0 compatible. This package also includes a web plugin, which is far from completed though. This is important for AMD64 users, as Sun doesn't provide one in the official jre package. As a downsides of all these patches, libgcc_s.so now exports a GCC_4.2.0 symbol that wasn't in older releases. Be very careful with this one when building packages for extra/current or community with these compilers, as binaries that link in this versioned symbol will fail to run on older libgcc_s.so libraries. If all is fine with these new compilers, I'll move them into current and extra in a short while. Happy compiling!

2 2

[arch-dev-public] kernel 2.6.21 series hits testing
by Tobias Powalowski 30 Apr '07

30 Apr '07

Hi kernel 2.6.21 series is now in testing, it will be the kernel series for next release so please test this stuff well before it can go into current repository. Changes: - latest alsa hg stuff added - updated patches to fit for .21 kernel - Recent Changes: http://kernelnewbies.org/Linux_2_6_21 have fun and report Showstoppers: http://bugs.archlinux.org/task/6875 thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 8

[arch-dev-public] Getting to New Arch SCM Layout and Repo Management
by Paul Mattal 30 Apr '07

30 Apr '07

All, Arch needs to move forward. The question: how? Moving forward at high speed is desirable, but we need first make sure we're not pointed towards a cliff and that our safety cables are attached and in good working order. I am setting my sights on exactly one aspect of this problem: SCM and repo management and getting us from where we are into the new system we all want to have. BACKGROUND For the purists, there is a sentiment I would like to acknowledge, because it's one that's been bugging me. I believe that the most often overlooked and underrated "Arch Way" design choice was to support i686 only. A single common denominator makes everything a lot simpler-- we just solve one problem and we solve it very well. Development resources are not spread thin and are highly focused on the same end. I am not the purist I once was. There's a vital and important segment of the community that needs 64-bit support, we can't just drop i686 support, and anyone has to acknowledge that i686 won't be around forever. To survive in the long haul, Arch will need to support more than just the i686 architecture. With some weight then, knowing we're setting out *against* the Arch Way, but along a trail that *must* be blazed, we consider the landscape. GOAL Using an open design and implementation process, we will implement a new system for managing Arch repositories and PKGBUILD materials. I will provide a box with Internet access for this project we can use as our home. It will be completely separate from the main Arch servers. If our system proves itself, it will be presented to the main Arch development team as the new standard for repo management. Main design choices I am making (to be amended as we go along): 1) The system will be able to manage an arbitrary number of repositories for multiple architectures efficiently. 2) Use of the system will not require a shell account on the server. 3) Multiple instances of the system will be easily deployable on a single server. 4) It will be trivially easy to create and destroy repositories, to copy or move packages between repositories, or to place a package in more than one repository. 5) It will be easy for developers with SCM access to efficiently incorporate patches and input from community members. 6) The system will allow anyone with SCM access to register as a maintainer for a package. 7) All functions of the system will be primarily accessible from a simple commandline interface. 8) The system will be itself deployed as an Arch package and be easy to set up. 9) The system will be sufficiently documented in a functional, if not beautiful, fashion. SCHEDULE By May 15: Anyone with another SCM system or layout to suggest should do so in the Arch-repos group. Your goal is to persuade Jason your system is the best one. Discussion of all those systems will then take place over the following two weeks. By May 7: I will bring 7 key people on board to work on this project. Drop me an email if you're interested in joining the team! Initially, I know we will need: SYSADMIN - An existing Arch developer who will manage the Linux box I provide and the accounts for the SCM system. This person should have at least a small amount of time each day to handle management tasks related to the project. PUBLICIST - I am committed to organizing this project, and will continue to post status to the arch-dev-public list for all to see. However, not everyone looks here. We need someone who will deliver the news about this project and the status as it progresses to the forums, the IRC channel, and the other mailing lists. This won't be a time-consuming job, but will require someone who has knowledge and facility with all the communications channels used in the Arch community and who can focus on getting the word out. DEVELOPERS - There will be some straight-up development work needed to get us from the SCM system and layout to an actual management system for repos. We may benefit from some work already done by others (pacman3, AUR, main site repo management tools) but we will need to do some original coding here. I will be somewhat involved in the design and coding, but will choose three (3) people to help with development. ANYONE is a potential candidate.. send me and email and tell me why you'd make a good candidate. Focus on good ideas you have for the system, languages you're comfortable in, how much of Getting Things Done (GTD) you've implemented for yourself, and amount of time you'll have to give to the project in June and July. COMMUNITY MEMBERS - I will choose two (2) members of the community who specifically are NOT developers or TUs (yet!) but who are interested in helping maintain the packages in our new system. These people will NOT be given SCM access, so as to help us evaluate how easy it is for community members to contribute and for developers to incorporate their contributions. Please contact me directly if you're interested in this job. These two people will specifically be identified as having the time to spend time helping us design our system in May and test our system during the month of July. On May 20: I will ask Jason to choose the best SCM system and layout he's seen. If at that point it does not meet this project's goals, we will minimally modify it to meet them. May 20-31: The developers and I will figure out the number, kind, and properties of the tools we will develop and divide up the work. This is the real remaining design step. JUNE: During June, the developers and I will build the system and get it ready for initial deployment. The source will be open to for anyone to observe and contribute, but we 4 will have commit access. JULY: On July 1, we will launch the system and put some real packages in it. At that time, we will need MAINTAINERS to join the project. We will deploy the system with REAL packages and REAL maintainers, just a small number of them. Any developer or TU wishing to participate will be allowed to contribute *AT MOST 4 PACKAGES OF RELATIVELY SMALL SIZE* to the test system and they will begin to be maintained in our system. It will be up to the individual developer or TU to decide if they will propagate the PKGBUILD changes from our system back into the official repos. AUGUST: In August, we will evaluate how we have done. If all has gone well, we will hand our system to the Arch development community with a recommendation to enhance and deploy it for main site and AUR repo management. I hope you will all consider joining me for this potentially exciting project! Let's get something done. - P

5 8

[arch-dev-public] License array format
by Dan McGee 29 Apr '07

29 Apr '07

I don't know if this is a rehash of an old topic, but it hasn't come up in a while so I want to stir the pot. We need some standardization when it comes to licenses, which are still not in all of the official packages. (OpenSSH is missing one!) Roman and I were discussing on IRC how the license array should look, and this example came up: license=('custom:BSD' 'custom:MIT' 'GPL') A few issues to discuss with regard to this example: 1. A license like the GPL does not change its text depending on the package, while ones such as BSD and MIT do. Thus we definitely need to be including these customized licenses when we package these. 2. For packages that have their own license (no other package will use it), do we use 'custom' or 'custom:packagename'? 3. For packages that use a BSD style license (and all other licenses like MIT), do we use the custom:prefix? Roman and I have differing opinions here. I think we should use the custom: prefix to indicate in pacman -Qi output that a license has been installed by the package and is not a common license already on the system. Roman thought that the custom: was unnecessary and looks ugly. Thoughts? I'd like to standardize this and get it on the wiki licenses page. <http://wiki.archlinux.org/index.php/Licenses> -Dan

3 3

Re: [arch-dev-public] [arch-dev] Getting to New Arch SCM Layout and Repo Management
by Paul Mattal 29 Apr '07

29 Apr '07

Dan McGee wrote: >> 6) The system will allow anyone with SCM access to register as a >> maintainer for a package. > > So if I read this right (or at least the way I was thinking), there > can be multiple maintainers for a package? I think this is the right > route to take- strict ownership of a package seems unnecessary. This is correct, though when I re-read this goal I realized I need to make that clearer! The idea is that anyone with SCM access can register as a maintainer (really a "regular contributor") on this package, so that when group thinking or decision making needs to happen for the package, you know who to coordinate with. This encourages more people to become involved in more packages that interest them. It also discourages people from holding onto ones they have grown tired of, which I believe is an equally important effect. > One of the things I noticed after being "inducted" as a dev was the > sparsely documented and slightly cobbled together toolchain. I think > if we are switching to a new system and layout, we should do it right > from the beginning and make the tools easy to understand, documented, > and able to work anywhere- not just on gerolde. In addition, pacman, > developer, and server side tools should work in harmony. Exactly my intent. You are a perfect fit for a developer on this project. The goal is, indeed, to make this the seamless equivalent of pacman for doing the other half. In fact, I was thinking we might want to call the most visable commandline tool "repoman". Very glad to have someone active on pacman development aboard, since the two really are halves of the same puzzle. My goal for next week is to get the box up and running, and to continue to flesh out some thoughts. My sandbox for this so far for this is at: https://subzero.elys.com/svn/repoman/trunk/ If you would like commit access, send me (privately) an htpasswd -n line. Welcome aboard! - P

1 0

Re: [arch-dev-public] [tur-users] Ion3 trademark infringement
by Thomas Bächler 29 Apr '07

29 Apr '07

Tuomo Valkonen schrieb: > The package "ion3-darcs" [1] on AUR is infringing on the Ion3 > trademark. It is not Ion3 anymore, as it modifies the installed > program in such a manner (by applying the Xft patch), that it > can not be considered the original product anymore, but a > competing one. The package must be renamed so that it can not > be confused with Ion3(tm), or the Ion project. If this is not > done, there may be legal repercurssions. > > [1]: http://aur.archlinux.org/packages.php?do_Details=1&ID=10622 This thread has just been brought to my attention and I am posting this to the tur and arch development mailing list. I suggest that we drop the modified ion version from AUR. I also strongly suggest that we remove ALL ion-related packages from AUR and official repos, as well as all other packages that have been released by the author. Arch always tries to provide the best and latest for its users. In doing so, we cannot afford getting sued. So if a package author THREATENS us, then there is no place for his/her software in our distribution and the only possible response is to not provide it any more, no matter how good it is. I am really disappointed that people have to resort to these kinds of actions, and I am sorry that I feel obligated to the proper reactions.

1 0

[arch-dev-public] Building and uploading with pacman 3
by Dan McGee 28 Apr '07

28 Apr '07

This is just a quick note for devs regarding pacman 3 (specifically makepkg) package naming. We eventually are switching to a scheme where the arch is tacked on to the package name, and makepkg 3 names packages this by default. However, this breaks backwards compatibility with pacman 2.9.8 and down, so we cannot do this in the official repos yet. Here is one way to quickly fix this (as a bash function): makeoldname() { mv $1 "${1%-*.pkg.tar.gz}.pkg.tar.gz" } JGC also suggested that you can just edit makepkg for now and have it output the old-style name. Finally, what is a good timetable for changing the uploaded package names? If we treat pacman a bit special and always name it without an arch, people will always be able to upgrade to it, and from there do a full sysupgrade. -Dan

1 0

[arch-dev-public] Sizes of repos and maintainers
by Dan McGee 25 Apr '07

25 Apr '07

First, let's get a few numbers out there. Sizes of official repos: current: 563 extra: 2019 community: 1196 Number of "maintainers": Devs: 27 TUs: 25 The second set of numbers is harder to pin down. For devs, I took the number from the devs page; someone who has been here longer could better state the breakdown between architectures or between active and passive. For TU's, I grabbed it from the AUR front page, once again not knowing how many are active. Given the above numbers, and this repeats what has been stated elsewhere by Alexander, devs have roughly 95 packages each ((563+2019)/27) to maintain if the load was distributed evently. Because we know it is not, Alexander came up with a figure of 16 active maintainers, giving each dev 156 packages. Thats a lot, and it leaves very little room or time for devs to do anything besides package maintenance. Compare this to the TUs workload. Each TU should have roughly 48 packages to maintain, a much more reasonable number and either 1/2 or 1/3 of what a dev is expected to do. This also gives them some time to patrol the AUR and check packages that haven't made it into community. Two proposals to let sit in the pot: 1. Downsize extra to a more reasonable size, and move some of the maintenance to TU's by shifting packages to community. This would likely require a few more TUs being "hired on". 2. Redefine what it means to be a dev. Have a three-tiered system of sorts, with increases in permissions to change things as you move up the ladder. This would basically stick another group between Devs and TUs that could help maintain the huge number of packages we have in extra. This would likely require a few more TUs being hired and some TUs shifted to higher levels of responsibility. Yes, radical ideas, but don't shoot me for them. Comments appreciated. -Dan

4 5

Re: [arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Tom K 25 Apr '07

25 Apr '07

David Rosenstrauch wrote: > Tom K wrote: >> David Rosenstrauch wrote: >>> Tom, >>> >>> I use EncFS pretty extensively, so I can assist you with testing if >>> you need. >>> >>> DR >>> >> >> Thanks David. >> >> Get it here for now: >> http://www.archlinux.org/~tom/packages/openssl-0.9.8e-3.pkg.tar.gz >> PKGBUILD and patch here: >> http://www.archlinux.org/~tom/packages/openssl/ >> >> I've asked the original reporter for details on the known >> OpenSSL/Blowfish problem, for inclusion in Arch News etc. >> >> T. > > Hi Tom. I just upgraded and tested. > > It's basically like Valient's mail said - the encrypted directory that I > made with the broken version of openssl-0.9.8e was now unreadable with > the new fixed version: > > [darose@davidrlin pr]$ encfssh .d2 d2 > EncFS Password: > Error decoding volume key, password incorrect > encfs failed > > But, like I did when we upgraded to the broken version in the first > place (http://archlinux.org/pipermail/arch/2007-March/013925.html) I > just deleted the bad encrypted directory and then recreated it. (I keep > the contents in a RCS, so it's easy for me to just pull them from there > again.) In retrospect, hat wasn't necessarily the correct thing for me > to do. Other people commented that they just remained downgraded on > openssl-0.9.8d. That avoided the bug, and let them keep using their > existing encrypted directories. But since recreating the directory was > no big deal, that worked for me. > > Anyway, after I whacked and recreated the directory, encfs seems to be > working fine. I'm able to unmount the encrypted directory and then > mount it again without a problem. > > So I think the fix is fine. Only caveat is that, like Valient said, > anyone who's created any encrypted directories using the broken version > will need to whack them and start again. You might want to reference > Valient's email and/or this Arch email thread > (http://archlinux.org/pipermail/arch/2007-March/013924.html) in whatever > communication you send about the issue. > > Hope this helps. Any further questions, or need me to do any more > testing, please feel free to write back. > > DR > > Many thanks for the comprehensive reply, David. I'm still waiting to hear from Valient regarding his tests, but I'll put the fixed package into testing anyway, with appropriate accompanying messages. T.

1 1