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

[arch-dev-public] Problems in 0.8
by James 08 Apr '07

08 Apr '07

Just posting this here, seeing if anyone has any other big problems noticed in 0.8 I caught this one on the forums, http://bbs.archlinux.org/viewtopic.php?id=31244 For a particular modern chipset, 2.6.20.4 doesnt even boot, making the 0.8 install CD useless for many. Given that 2.6.21 is at rc6, are we going to make a release at 2.6.21 as planned? Otherwise... it might be nice to just rebuild 0.8 as 0.8.1 with the newer kernel for these users. -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

1 0

[arch-dev-public] Move from /opt to /usr
by Tobias Kieslich 06 Apr '07

06 Apr '07

Hi, this is an old issue and I just talked to Jan about that. We both are all for that and will move gnome and xfce. Jan said kde needs some more investigation. It'll save us a whole lot of trouble in the long run. As far as xfce4 is concerned, 4.4.1 is expected to be there around the 9th of April. And I plan on using this to move over the whole repository. Just one more guess, when moving on to a newer repos layout, can we rename xfce4 to xfce, it's somewhat less limiting :P -T

4 5

[arch-dev-public] coreutils 6.9 + fakeroot + makepkg serious bug
by Thomas Bächler 05 Apr '07

05 Apr '07

While rebuilding some packages, namcap issued some warnings: beryl-core W: File (usr/man/man1/) does not have the world readable bit set. beryl-core W: File (usr/man/man3/) does not have the world readable bit set. When I look at the $startdir/pkg, everything is fine though. I narrowed it down to the following simple test case: [01:54:30][thomas@gollum shm]$ fakeroot bash-3.2# ls -lF insgesamt 0 bash-3.2# mkdir foo bash-3.2# ls -lF insgesamt 0 drwxr-xr-x 2 root root 40 2. Apr 01:54 foo/ bash-3.2# chmod 700 foo/ bash-3.2# ls -lF insgesamt 0 drwxr-xr-x 2 root root 40 2. Apr 01:54 foo/ bash-3.2# exit [01:55:02][thomas@gollum shm]$ ls -lF insgesamt 0 drwx------ 2 thomas users 40 2. Apr 01:54 foo/ [01:55:03][thomas@gollum shm]$ As you can see, the chmod has no effect inside the fakeroot environment, which causes a 'cp -a' in makepkg to behave incorrectly and may cause other similar bugs during makepkg. Downgrading coreutils from 6.9-1 to 6.7-1 solves this problem. I have no idea where to start, but this should be adressed quickly as it may break many packages. For everyone who is going to test, I found the old package here: ftp://ftp.tu-chemnitz.de/pub/linux/sunsite.unc-mirror/distributions/archlinux/current/os/i686/coreutils-6.7-1.pkg.tar.gz @Romashka: If you read this, I think your exaile build bug is also related to this, please confirm.

2 2

[arch-dev-public] New wireless and network scripts.
by James 05 Apr '07

05 Apr '07

Hey The network profile's that i've been working on for far too long, have now been uploaded and put into a git repository on archlinux.org. To get it, git clone http://archlinux.org/~james/projects/network.git To make a package, run package.sh for the meantime. There will be a proper PKGBUILD and a custom repository for it shortly. There's a few known bugs, and not enough documentation, however I've put enough basic information to get you going on the wiki: http://wiki.archlinux.org/index.php/Network_Scripts There's undoubtedly other bugs and hiccups, and i'm calling on you to test. If you find a bug, let me know. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

5 14

[arch-dev-public] status of xfce-svn
by Roman Kyrylych 04 Apr '07

04 Apr '07

Hi! We have xfce-svn group in Unstable repo, that was maintained by Shadowhand until he resigned as a maintainer. Because packages are not maintained now users fill bugreports about non-working packages. Is there a need in xfce-svn now? If noone is interested in maintaining them then I propose to remove them. -- Roman Kyrylych (Роман Кирилич)

3 6

[arch-dev-public] Bug Day
by Roman Kyrylych 04 Apr '07

04 Apr '07

Hi! I would like for the next Bug Day to happen on 14th of April. The reason for this is to reduce the amount of old reports and feature requests. We should clear outdated reports, fix/implement those that already have patches provided or are trivial to fix/implement, discuss the pros & cons of implementing some feature requests, look at reports assigned to inactive/resigned devs. If you cannot take part in the Bug Day, then choose any day when you'll have free time to do this work and plase notify other devs so they would know to take a closer look at your reports too. Please all users help us too. There are bugrepors that are probably already fixed but developers may not be aware of this because of lack of user feedback. Please review all bugs that were reported by you if they still are valid. If report are old enought and no further information from reporter is provided then developers will most likely close such bugs assuming they are fixed. We cannot fix bugs without your feedback. Join us at #archlinux-bugs channel on irc.freenode.net during 14th of April. As we leave in different timezones not all devs will be available at the same time, but feel free to report your issues to any dev available on-line. Also please check your mailboxes that may contain notifications about comments made by devs and other users. I would like to hear any proposals about possible improvements to the Bug Day effectiveness. P.S.: this is my first official announcement so don't beat me hard if something is wrong. :-P -- Roman Kyrylych (Роман Кирилич)

3 4

[arch-dev-public] Fixing docbook for iputils
by Aaron Griffin 02 Apr '07

02 Apr '07

Just a call for comments. I think our docbook package is broken - either that or we need much more DTDs. The reason being is that we're using a wickedly outdated iputils (newest one here: http://www.skbuff.net/iputils/) and the newer packages generate their man pages from docbook - which flat out fails. Also, according to neri, gimp-help also fails to build for similar reasons. I guess I'm writing this for two reasons: 1) As a 'heads-up' that a new iputils package is in the works, which will cover 3 other changes in addition to the version upgrade. 2) maybe some docbook pro will help me out here, as it seems like a real headache to mess with. Thanks, Aaron

1 0

[arch-dev-public] moving to pacbuild
by Aaron Griffin 01 Apr '07

01 Apr '07

This is one of those things that's not gonna get done until someone does it. For a trial (until we determine if it hurts us), I want to try and install pacbuild on gerolde. I think, however, it needs a good ol' -Syu, which I'll probably leave in more capable hands (though we need to make sure we don't break django with python2.5, heh). It should be easy to setup and apple daemon on there, then we need to get some build machines together. I have one here I can use, and can probably be sneaky about it and use one of the arch machines at work. We'd still need some x86_64 build machines, but that can't be all that hard. If there's a problem with putting this on gerolde at this stage, I _could_ open up my home machine for a while. Jason, is there anything blocking us from using pacbuild right now? - Aaron

4 5

[arch-dev-public] Berkeley DB change proposal
by Jan de Groot 01 Apr '07

01 Apr '07

Hi all, I'm about to make a slight change to evolution-data-server: build with system DB. Advantages: instead of having 4 copies of DB linked into a running evolution-data-server process (takes 4x600KB of memory), have only 1 copy of it running, which takes 1x600KB, saves 1800KB memory for having your gnome clock applet reading information from your evolution calendar Downside: Building with system-db breaks all datafiles, because they would need to get upgraded Workaround: Install a copy of DB 4.1.25, which is shipped internally in evolution, build with that Current workaround: - build a copy of DB 4.1.25 - install it in ${startdir}/src/build-db41 - make EDS configure script detect it there - make LDFLAGS+="-R/opt/gnome/lib/evolution-data-server-1.2" - install EDS as usual - install the libdb-4.1.so file in the location provided in LDFLAGS Very very very hacky, and we'll end up with quite some libdb-4.1.so files in the future if this goes on. Given the trouble we have with major upgrades of DB all the time, I would suggest a different approach to the DB package. Currently, DB contains some utilities, a versioned library and some generic include files. IMHO we should change that and put each DB package in a versioned pkgname: db4.1: /usr/bin/db4.1_* /usr/lib/libdb-4.1.so /usr/lib/libdb-4.1.a /usr/include/db4.1/*.h db4.5: /usr/bin/db4.5_* /usr/lib/libdb-4.5.* /usr/include/db4.5/*.h db: /usr/bin/db_* as symlinks to most recent DB package /usr/lib/libdb.* as symlinks to most recent DB package /usr/include/*.h as symlinks to most recent DB package This would: - throw away all bug reports we get on DB upgrades, old DB pkg stays installed, all new pkgs get compiled against the new DB version - make it very easy to compile packages with specific DB versions - Allow users to actually do something with on-disk DB files when it belongs to an older version. _______________________________________________ arch-dev mailing list arch-dev(a)archlinux.org http://www.archlinux.org/mailman/listinfo/arch-dev

1 0

[arch-dev-public] Uniform handling of webservers
by Aaron Griffin 31 Mar '07

31 Mar '07

Moving this discussion off of the private list, mainly because it wasn't resolved - I think Tobais' points here should be addressed. ---------- Forwarded message ---------- From: tobias(a)justdreams.de <tobias(a)justdreams.de> Date: Mar 25, 2007 1:11 PM Subject: Re: [arch-dev] Uniform handling of webservers To: Development Discussion for Arch Linux <arch-dev(a)archlinux.org> > Since this discussion kinda went away... I'm gonna bring it back up > (hooray gmail stars keeping me on task!). Hi, most people agree on /srv/www , but we have different opinions on how we wanna lay out the basic structure. Let's try to summary the ideas and concerns. I use apache and lighttpd to illustrate the issues: 1. shall we continuing using nobody as primary www user(group) or now when we unify things go and create a dedicated wwwuser with a reasonable set of permissions? 2. shall we create subdirs /srv/www/{httpd,lighttpd} per webserver as some people suggested? Web administration is an administrators job - not a package managers. 3. If we create subdirs, shall we have some magic that routes localhost automatically $wwwhome of the latest installed webserver? Do we wanna have magic at all? 4. Subdirs per webserver leave us with the issue, that we do not have a distinct directory, where we can install apps like phpMyAdmin per default to work out of the box. This is bad IMHO. The issue can be partially resolved by aliases or vhosts, but this requires both user interaction and some config tweaking, as lighttpd does not support easy *.conf handling with the vhost handling as apache does. There might be a way, but I have to investigate that. Also, this might mean that we will have to create special handlings per possibly installed webserver in the phpmyadmin.install post_insall(), I would like to get away without it! -T

4 4