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

[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

[arch-dev-public] lingering x86_64 mythtv bug
by Paul Mattal 05 May '07

05 May '07

Can the Arch64 folks compiling mythtv have a look at this bug? It seems only to be a problem in the Arch64 binary package. http://bugs.archlinux.org/task/5944 - P

1 0

[arch-dev-public] Linuxtag: Staff meeting Saturday 12th 4pm CEST
by Christoph Neuroth 05 May '07

05 May '07

Hi, anyone who wants to help making Linuxtag a nice event again, please try to make it to Freenode/#arch-lt on Saturday 4pm Berlin time so we can discuss remaining topics, as there are: * Arrival/Departure schedules (someone needs to set up and dismantle the booth) * Poster printing * Organizing some shirts with arch logos so vistors know who they can talk to * CD Burning, CD sleeves * other needed stuff Feel free to bring up any other topics you can think of. Also please make sure that I have your full name so I can order exhibitor passes for you. Currently, I ordered passes for Alex, Andreas, Tobias and Jan. And finally if you need some tickets for your friends to be able to visit the fair, I have been given 24 e-tickets that I can share. As in the last years, I will need the full name and a valid email address to send them to you. chris

3 2

[arch-dev-public] On vacation
by Varun Acharya 04 May '07

04 May '07

I'm taking a big long break from 5th-24th May, during which I probably wont have access to even an internet connection. 32bit TU's please help out with community64 if you can .. the difflist is here http://www.archlinux.org/~andyrtr/pkg_diff.html. Thanks, Bye, Varun

1 0

Re: [arch-dev-public] [arch-dev] [goals] i18n
by Jason Chu 04 May '07

04 May '07

On Thu, May 03, 2007 at 11:18:15PM +0200, Andreas Radke wrote: > i'm against offering any localization from the devs. it's a big amount > of packages we don't know how important they are or better how often > they are used*. Is there some way we can find this out instead of just guessing one way or the other? > arch is developed and documented primarly in english and so we should > concentrate to offer a good en_US.utf8 base. nothing more from the core. I don't see why we can't also have good i18n support. > i suggest to lay i18n packages back into the community's hand. those > packages are often easy to maintain but a hell of work for the > rebuilders. Don't the people who maintain these packages have scripts that will just build them all? Jason

1 0

[arch-dev-public] [goals] i18n
by Dan McGee 03 May '07

03 May '07

And why was this on arch-dev and not the public list? Forwarding it there. ---------- Forwarded message ---------- From: Dan McGee <dpmcgee(a)gmail.com> Date: May 3, 2007 6:03 PM Subject: Re: [arch-dev] [goals] i18n To: Development Discussion for Arch Linux <arch-dev(a)archlinux.org> On 5/3/07, Andreas Radke <a.radke(a)arcor.de> wrote: > i'm against offering any localization from the devs. it's a big amount > of packages we don't know how important they are or better how often > they are used*. > > arch is developed and documented primarly in english and so we should > concentrate to offer a good en_US.utf8 base. nothing more from the core. > > i suggest to lay i18n packages back into the community's hand. those > packages are often easy to maintain but a hell of work for the > rebuilders. > > Andy > > > > *we should improve archstat to show summarized output for the amount of > one pkgname. that could help a lot for our wanted repo cleanup. Quick thoughts on this, and not sure of the full implementation but it seems like a good idea in my head. Why don't we have an [i18n] repo, just as community and extra are repos? This should be administered under a separate set of permissions, so those that update these packages are not necessarily either TUs or Devs, but other users that have taken on the responsibility of maintaining localization packages. Key to this is some kind of permissions based thing- perhaps a certain user should only be able to modify FR localization packages, for instance. The system should support that, and it seems like pre-commit hooks in nearly all VCS systems should be able to enforce these permissions on a package or repo-level basis. This is another topic though. -Dan

1 0

[arch-dev-public] Linuxtag: Project Description German Translation needed
by Christoph Neuroth 03 May '07

03 May '07

Hi guys, I'm very short on time right now, so it would be good if some other native German speaker could translate our description into German. It will be published on the linuxtag website and in the official printed LT Journal. I used a slightly shortened version of the archlinux.org/about text: >Arch Linux is a general purpose linux distribution that can be molded to do just about anything. It is fast, lightweight, flexible, and most of the parts under the hood are quite simple to understand and tweak, which can make it a good distro to "learn the ropes" on. We do not provide any configuration helper utilities (ie, you won't find linuxconf in here) so you will quickly become very proficient at configuring your system from the shell commandline. > >Arch Linux uses the Pacman package manager, which couples a simple binary package format with an easy-to-use build system, allowing the users to easily manage and customize their packages, whether they be official Arch packages or the user's own homegrown ones. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution. > >Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community. > >Arch Linux uses a "rolling release" system which works like this: We have two versions of our core package set at any given time, Current and Release. The Current repository always contains the latest and greatest versions of packages. As soon as a package is updated it is part of the Current repository, so this is the one to follow if you want to stay very up to date. chris

1 0

[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