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

[arch-dev-public] Beginning: arch projects
by Aaron Griffin 11 May '07

11 May '07

So I've been trying to get together this "arch projects" interface for some time now. In essence, the "interface" is is a chunk of python modules to help with creation of projects in a similar vein as code.google.com and repo.or.cz. I have made a *ahem i-suck-at-css ahem* python cgi overlay, but that's still incomplete. For now, however, I've begun the backend setup. This will live here: http://projects.archlinux.org/ For now, this is all kinda manual - but if you want a repo or project setup, I can do that. In the future, developers will be able to create this stuff themselves and add other users from the community to the access list (without needing a shell account on gerolde). I've been trying to finish this up in between everything else, and it's slow going, but almost there. The initial release won't have any sort of bug tracking support, because I'd rather not write my own - I'd much rather integrate an external bug tracker into the mix... but that gets complicated. I know I keep saying "soon" and I said "1 week" about 3 weeks ago... but a lot of other things keep getting in my way. This is more a "heads up" mail, and to point out that if you want some crap on gerolde, I'm beginning to setup the infrastructure. Aaron

1 1

[arch-dev-public] Core Issue in Multiple Architecture
by Paul Mattal 10 May '07

10 May '07

So here's what I see as the most important counterfactor to Arch growing comfortably into a multi-architecture distro: HOW do we make it easy for OLD devs to TEST easily on MULTIPLE platforms? Building we have covered, at least in the long term. But time has shown that deploying packages without proper testing is not smart. This means (I think) at LEAST installing the package and running at least one program that is part of the package; for some packages, I know I put them up on one of my servers and let them run for a few days before pushing them to [extra]. So the next time I build the next release of dovecot, how can we make it easy for me to test it? So far, I see no good solution. What doesn't seem fair is to expect the devs who signed on with x hours of time to give per week to maintaining i686 packages to maintain packages on other architectures if it will require: 1) more hardware purchases 2) significantly more time Remember, we're all here scratching our own itches. I agree that the idea of multiple architectures is a nice one, but if I have to put in 2x hours per week maintaining packages when I already can barely find the x hours per week I need to maintain the ones I have, it's just not possible for me to take this on. So I see two solutions: 1) See if more developers come along for other architectures. This isn't something we can "make" happen, unless someone's got a rich uncle who's willing to pay them! We should make it clear we're looking for help, and if people want to help, they'll come. 2) Reduce that 2x to something smaller. This *is* something within our control.. we can try to solve the technical problems which currently make it hard to develop for multiple architectures. This is meant as a starting point for further discussion, and also a means of conveying, for instance, why I haven't started building for x86_64. I'm not even running an x86_64 box, even though most of my computers are Athlon64s. Since I have to choose between developing and testing on one or the other, the barrier is very high. Let's try to make it lower. - P

3 3

[arch-dev-public] Repoman Update: 5/9/07
by Paul Mattal 10 May '07

10 May '07

I wanted to update everyone on current progress on the Repoman project! You can review the project manifest from my April post: http://archlinux.org/pipermail/arch-dev-public/2007-April/000524.html The big objectives for the past week were: * getting 7 people on board for the project: sysadmin, publicist, 3 developers, 2 community members * getting the development box up and working * spread the word about the project PEOPLE So far we have 3 people on board! Better than I expected, actually-- good people are the hardest thing to find. Tom Killian - PUBLICIST Dan McGee - DEVELOPER Alexander Baldeck - DEVELOPER For now, I will act as sysadmin, but we're still looking for another developer and some community members to agree to be part of the project! Please read the project manifest from above and let me know if you are interested. DEVELOPMENT BOX After a small fight with the 0.8 installer and RAID, we now have a development box home for repoman. It's at repoman.mattal.com for now unless/until we decide to make it repoman.archlinux.org. TomK, Dan, and Alexander, send me your preferred username and a temporary password privately, and I'll set you up shell accounts. We also have a source code repository. It currently lives on another box, which has an SSL certificate, so it may stay there for at least a while: https://subzero.elys.com/svn/repoman/ This is world readable. Right now it only contains some notes and musings, but later it will hold our source code. Alexander and TomK, send me an htpasswd -n line and I'll give you commit access. Feel free to add things as you see fit. I hereby ask Aaron, King of Mailman, to create a repoman(a)archlinux.org mailing list for our group, using me as owner. Let's start with one list until we should happen to need more. Once that's in place, I'll stop doing updates on this list and start doing them there. SPREAD THE WORD We should all continue to spread the word about the project. I'd especially still like to find one more developer and a sysadmin immediately. We may involve some of the other devs informally and give them svn commit access as it makes sense, but I think having a core team of three developers PLUS me will put us in a good situation for starting. TomK, can you spread the word in the forums and the IRC and elsewhere where we may not have covered? We should probably also have a webpage for the project.. if you can tool up some simple HTML, I'll install apache on the server and you can drop it in. Finally, we should all continue to think about the SCM system, as it will be the underpinnings for repoman. It's been a busy week for me, so I need to go catch up on the google group exchanges. It seems like svn is winning, and it's mostly about the details of how to arrange things. Thanks! - P

2 1

[arch-dev-public] pacman upgrade issue (was: ArchLinux [current] status)
by Aaron Griffin 09 May '07

09 May '07

On 5/9/07, Jason Chu <jason(a)archlinux.org> wrote: > On Wed, May 09, 2007 at 12:52:31PM -0500, Aaron Griffin wrote: > > Jason, can you take this task on? I want to > > a) figure out a solution to the pacman upgrade issue > > b) deal with the package cleanup > > So I don't have huge amounts of time to spare at the moment. > > I am also lacking in time. Can you explain the pacman upgrade issue a > little better (there was a bug report about it at one point, right?)? > > I will make sure something gets done, but I doubt I'll be the one to do it. Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path. The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved. So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing. This is not a critical issue, as one can easilly -S those two, but it is not clean. When this moves to current, there will be many people with problems, and not everyone checks the news items / reads the forums. The use case will go as follows: pacman -Syu "New pacman is available, upgrade? [Y/n]" Y ...download pacman 3... Whoops, cannot find dependencies "libdownload" or "libarchive", failing "Hmmm, wtf?" pacman -S libdownload libarchive pacman -Syu Again, this is not critical, not fatal, and not a big deal, it is just messy. I want to figure out if there is some good way to do this, but I do not think so.

8 20

[arch-dev-public] going to start a new ArchLinux?
by Andreas Radke 09 May '07

09 May '07

congratulation. we have won! our gcc-gcj is broken due to a major feature addon the developer made right before he orphaned it. we (Hussam who does i686 rc packages and me) are no more able to build OpenOffice.org standing a few days before the 2.2.1 release candidate. this is not to blaim that developer but for any other developer and all users not using the testing repo. but this is only the peak of all the chaotic "development" as we call it. untill now we used have one ArchLinux tree now having two architectures officially supported (i686+x86_64) based on simplicity and pacman repo manager as its basic parts. Having the latest stable package version was the goal. we have put more and more packages into the current+extra repos. important packages we want to test for a while in our "testing" repos. sadly it's not worth the name. almost nobody uses it. even not all developers as highly recommended. continously we put packages with major issues into the stable repos. we from the x86_64 port are only 2 guys rebuilding and maintaining ~2500 packages. we have not the power and possebility to change anything important. from my point of view we have passed a point where this concept won't work anymore. we have a poor developement infrastructure compared to other distributions. we slow down our package release process due to many developers beeing busy with other things (real life and more). but then we force us to push things very quickly into the repos to satisfy our own old goals. well. not more with me beeing responsible for the Arch x86_64 port. some ways are possible: 1) improve the infrastructure and increase the manpower of developers and packagers for all supported dramatically. we are trying that for over a year now without any noticable real success. 2) dramatically lower the work(=less binary packages) for the devs to give them time for making packages of a better quality. doubt came up as Arch should remain a supported binary distribution in most parts. 3) new goals for ArchLinux: accept to have not well tested packages when we want to keep the update speed or accept a lower speed on update to get new packages better tested. 4) split the goals we have! let's have one more conservative stable rolling rellease tree for higher quality and one on the bleading edge front accepting it might break sometime. I've brought it up several times: i'm no more willing to be the dump rebuild monkey. wha i suggest is a mix of 3) and 4). there is only one working other distribution based on pacman out claiming having a stable tree. I've talked to several devs and users and they can imagine that a stable distribution by ArchLinux can become a successor. I'm going to start a new project based on what we now call ArchLinux for a new more stable but easy to maintain distribution. I would like to do this for ArchLinux. But I have also no problem if you totally dislike that and say it's a NoGo under the name of ArchLinux. Everybody who wants to help out or has something to say may post here or contact me on one of my instant messenger accounts you find in the forum. AndyRTR

2 1

Re: [arch-dev-public] [arch] Archlinux [current] status
by Dan McGee 08 May '07

08 May '07

Kludging a few emails together here. > Am Dienstag, 8. Mai 2007 22:30:59 schrieb Tobias Powalowski: > > Hi > > something is really going wrong at the moment. > > People claim for having other interests or not time for doing the packaging > > work. > > I start here only with [current] first. > > Jan quit doing maintenance of important parts of our distro and probably > > also of doing quite some update tirades through current. > > > > Let me stress this, from my point of view Jan and me did the most [current] > > updates the last weeks, even if we didn't use the software for our own > > stuff, correct me if im wrong. I for one do not have access to [current]. I would be plenty willing to help out with maintenance there, although I am not as keen on adopting packages. More on this below. > > We have inactive package maintainers, no doubt. > > Judd, Dorphell, Aurelien, Gregor, Woody, Arjan > > > > It's time to cleanup [current]. > > Orphan all packages of Judd, Dorphell, Aurelien, Gregor > > 1 week of time to grab what packages you wanna have. > > Keep in mind it's your job then to test and ensure that the package works! > > Please one of the enablers do this, or give me the permission to orphan > > them. This could make sense, however I would like to state that a single maintainer of a package may be the wrong way to think about this, even before we do any kind of repository reorganization. If two people want to maintain a package, that should not be an issue as long as people don't have problems when people touch "their" packages. By the way, a lot of Judd's packages are marked out of date- someone should take a look at some of these and update if necessary. > > After that period, look whats left if noone feels responsable for a package > > make a list of possible drops or try to find one on ML who wants to > > maintain it. It's better to have 1 maintainer for just 1 package who is > > active and knows the package well, then 1 who just cross updates because he > > saw the version bump. I might disagree with part of this- a roving maintainer that knows and can test the packages he is updating is still a good thing. On 5/8/07, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Well, I see the point. Perhaps there too much packages in [current] and > [extra] for too few devs. (compare: there are less packages in [community] > but we have more active TUs than Devs) I brought up this exact point a while back and it died on the ML: <http://archlinux.org/pipermail/arch-dev-public/2007-April/000517.html> > I don`t see any problem in stripping down [current] and [extra] to only those > packages which are really used. E.g. there are some experimntal ones like > beryl, several unstable kernels like ck, beyond, mm etc. which will do well > in [community]. I agree with this- extra is gigantic right now. Anything that we no longer feel belongs in extra should get announced to the TU list, where anyone can claim it if they use it. If not, drop it down to unsupported. > Perhaps there should be a guideline which package has to be part of the core > distribution. For example: if a TU becomes a DEV he often moves all his > packages to extra. Esspecially for Arch64 this causes some problems because > we TUs wont be able to help by porting those packages. I don't think that this should be the norm. On 5/8/07, Andreas Radke <a.radke(a)arcor.de> wrote: > Am Tue, 8 May 2007 14:33:04 -0700 schrieb Tobias Kieslich <tobias(a)justdreams.de>: > > 4. Arch64 is a 2 man show, Andy and ise. There should be some more > > support for them. I really think we should add some people here. ISE, > > write a mail to Jason to get access to current. Andy, Ise, how many > > people do you want and do you have suggestions? > > we both already have cvs access to all repos. we are still not allowed > to maintain packages. we are not listed in the dashboard. but if this > would change we would have to decide how to make i686 devs rebuild the > packages that are maintained by x86_64 devs. I tacked this on as a postscript in one of my other emails and no one responded. I feel like we should not exclude our x86_64 devs from maintaining packages. This requires a few changes in thought: 1. When you are the maintainer of a package, you are in charge of the package as a whole in addition to your own architecture. This means seeking out patches if necessary, etc. 2. People need to release a little control sometimes and not treat a package as their own. It is the community's package, any capable dev should be able to decide what is best for the package. If there is disagreement, then bring it up on the ML. > also i got dissapointed by some fresh x86_64 users we brought up here > that left us quicker than we thought. This should be a big role in deciding future dev/TU consideration, hopefully, especially for those brought on as package maintainers. -Dan

1 0

[arch-dev-public] [opening] Koffice maintainership
by Alexander Baldeck 08 May '07

08 May '07

Hey all, I took over many packages including X.org and thus my number of maintained packages went up to 280. So, I have a few packages to give away that are basicly the Koffice environment. I don't do the office kind of thing all that often anymore. Then again, I don't want to orphan them, nor do I want them to be moved to the AUR. Also, it would be nice if there was somebody new to maintain them. Send me a mail and we can talk about it. List of Packages: koffice koffice-doc koffice-l10n-ca koffice-l10n-cs koffice-l10n-cy koffice-l10n-da koffice-l10n-de koffice-l10n-el koffice-l10n-en_gb koffice-l10n-es koffice-l10n-et koffice-l10n-eu koffice-l10n-fi koffice-l10n-fr koffice-l10n-hu koffice-l10n-it koffice-l10n-ja koffice-l10n-lv koffice-l10n-ms koffice-l10n-nb koffice-l10n-nl koffice-l10n-pl koffice-l10n-pt koffice-l10n-pt_br koffice-l10n-ru koffice-l10n-sk koffice-l10n-sl koffice-l10n-sr koffice-l10n-sv koffice-l10n-tr koffice-l10n-uk koffice-l10n-zh_cn koffice-l10n-zh_tw

1 0

[arch-dev-public] pacman 3 to current
by Dan McGee 08 May '07

08 May '07

If there are no objections in the next half-day or so, we (Aaron and I) would like to push pacman 3 to current. This is the only possible showstopper I know of that is not fixed in 3.0.3: <http://bugs.archlinux.org/task/7063> It is easily patched on the package building end, rather than release a 3.0.4 release. Let us know ASAP if this shouldn't happen tonight. -Dan

2 1

[arch-dev-public] Beyond is discontinued.
by James 07 May '07

07 May '07

It was fun while it lasted, but it's come down to this. I simply no longer have the time, or motivation to develop beyond. Uni and life are taking up more of my time, and I'd rather spend what time i have at the computer pursuing things of interest. I no longer see the point in beyond, and have not used for any extended period for months. I'm sick of the kernel. It's crap. Every release breaks something new, and every release is as poorly tested as the last. (not you tpowa, I mean upstream -- you do a good job with what you're given by them) The stable tree, isn't stable. I want something that works and won't break. This email was not sent on a whim, I've thought about this for a while, and have realised, that there's not going to be a decent release in the near future and i'd prefer to not lead people on any further. Honestly, I don't think I've put out a good release in over 6 months. It's hard to drop a successful 2 year old project. I didn't want this to happen, but unless someone steps up to maintain beyond, it's now discontinued. Sorry guys. James Addendum: z4ziggy & dtw: kernel26 now has unionfs and squashfs. It's also somewhat more stable and reliable than beyond ever was. Consider it the successor. I know it doesn't have fbsplash... but you could build a patched version, and if you only add fbsplash, it should retain compatibility with the modules. Beyond name & maintainership: I still hold these, please email me personally if you're interested in taking over. I don't want some stupid ricer full of omgoptimised using the beyond name. Users: sorry guys. Maybe someone else will step up? I don't plan to put any of the other patch sets in the repository in place of beyond. If someone else maintains beyond to an acceptable standard, maybe i'll update it. -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

2 1

[arch-dev-public] [objectives] Package triage on current + extra (archstats)
by Dan McGee 07 May '07

07 May '07

I know we weren't supposed to rush into the objectives here before settling on the goals, but I think this is an important one to examine, especially with a change in the repository structure happening in the coming months. How many of the devs are using archstats, let alone users? After looking at it a bit more today, I realized this could be a great asset to finding areas where devs should be spending their time with regard to package maintenance. It would also help us out greatly when it comes to determining which packages should no longer be maintained by us and dropped back to the TU level and/or unsupported. However, a few things need work: 1. The current website <http://www.archlinux.org/~simo/archstats/index.php> is in dire need of an overhaul. Using the old website theme is the least of our worries- things like the package listing are at this point rather unusable and only suck 223 MB of memory in Firefox once fully loaded. I have a lot of ideas for this here- enable breakdown by pkgname only (so it actually looks like people are running kernel26), limit number of results on the page unless someone actually selects to see them all, etc. 2. The archstats database. It contains several one-time system updates, and several systems that haven't updated since 2005 or earlier. This is clearly junk data, and to make archstats useful we should probably just start fresh, and find a way to cut down on spurious commits, which leads into... 3. The archstats program itself. In the last week, I've had no problems with it, but have had problems before (some of the spurious commits above were definitely my fault). Configuration should probably be editable in a conf file (the current /etc file has a big fat warning saying do not edit by hand- this seems not the Arch Way). Setting it up as a cron job is straightforward, but if we want people to use it we should probably think of a way to make it even easier. Comments on any of this? I know its yet another project idea to be thrown out there, but this one could prove very helpful and in the long run vastly reduce dev maintenance of package when we realize very few users are actually using a package and it should be maintained elsewhere. -Dan

5 9