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

[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