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

[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

[arch-dev-public] Updating the licenses package
by Aaron Griffin 30 Mar '07

30 Mar '07

Hey all, I actually just came across this page here: http://www.opensource.org/licenses/alphabetical I think we should go through and add some more common ones to the licenses packages (it's text, it'll compress well). This comes up because we probably need an update for the Python license anyway. Maybe we can even add all of them? Only problem is they don't seem to export plain text, so we can't really automate it... ewww. - Aaron

4 8

[arch-dev-public] 0.8 torrents
by Aaron Griffin 30 Mar '07

30 Mar '07

I created the torrents for the iso images, and put them on the ftp earlier today, so they should start hitting mirrors soon. I also placed them up on linuxtracker.org: I'm currently seeding all 6, though quite poorly - I need to open some more ports but my silly router doesn't accept ranges (one at a time is nasty). A few other people (Thomas, Dan, stonecrest maybe, etc) are also seeding some of them. Due to our recent bandwidth shenanigans, we should probably suggest the torrents over ftp download. Perhaps when neotuli updates the download page, we can move it around so the torrents appear to be the first choice? /me shrugs Enjoy the torrents - Aaron

5 6

[arch-dev-public] Final python 2.5 rebuild list set
by Jason Chu 29 Mar '07

29 Mar '07

I've finally finished creating the python 2.5 todo list. This is the list as of about 4 days ago, so some of these packages have already been rebuilt. If one of your packages has been rebuilt, feel free to just mark it as completed. http://archlinux.org/todo/40/ I've sent this email to arch-dev-public and arch-dev, just in case some developers aren't on arch-dev-public yet. If you're not on there, now's a good time to add yourself. Jason

1 0

[arch-dev-public] All setup
by Aaron Griffin 29 Mar '07

29 Mar '07

Ok, so I fixed a few mailman issues (bad img URLs, some urls having 'www.' and some without, mailman urls with and without 'www.' showing different MLs, etc) and switched this list to "anyone can subscribe" - users are moderated by default, which means they can't post to the list. I'll keep my eye on the admin queue for now, and make sure approve all our developers as they sign up - send me an email if I didn't get to you, and I'll do it asap. Is everything good? Would anyone mind if I announced this list to the public? - Aaron

3 3

[arch-dev-public] iputils & traceroute packaging
by Dan McGee 29 Mar '07

29 Mar '07

Quick question for whoever is responsible: Why on earth do we have a separate traceroute package that is not a part of base? This seems to fit much better being in the iputils package, although I am not familiar with the sources of these packages and why they are developed separately. $ pacman -Ql traceroute traceroute /usr/bin/traceroute traceroute /usr/man/man8/traceroute.8.gz $ pacman -Ql iputils iputils /bin/ping iputils /bin/ping6 iputils /etc/protocols iputils /etc/services iputils /usr/man/man8/arping.8.gz iputils /usr/man/man8/clockdiff.8.gz iputils /usr/man/man8/ping.8.gz iputils /usr/man/man8/rarpd.8.gz iputils /usr/man/man8/rdisc.8.gz iputils /usr/man/man8/tftpd.8.gz iputils /usr/man/man8/tracepath.8.gz iputils /usr/man/man8/traceroute6.8.gz iputils /usr/sbin/arping iputils /usr/sbin/clockdiff iputils /usr/sbin/rarpd iputils /usr/sbin/rdisc iputils /usr/sbin/tftpd iputils /usr/sbin/tracepath iputils /usr/sbin/tracepath6 iputils /usr/sbin/traceroute6 What I find really weird is the inclusion of traceroute6 in iputils. This all came up while going about "fixing" this bug: <http://bugs.archlinux.org/task/6725> I don't want to make mtr setuid unless we are going to make traceroute suid. mtr > traceroute > ping, so it should be at no higher of a level than the one below it. What should we be installing programs like this as? I think it makes sense to have ping and traceroute available to a user, so maybe they should all be SUID, currently traceroute6 is not. Comments and thoughts appreciated. -Dan

1 0