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

[arch-dev-public] GPL Compliance: A beginning
by Aaron Griffin 15 Aug '08

15 Aug '08

So, yeah people are blowing smoke about this hosting the sources thing. That's fine, it's a legit violation... I made a little script which should generate some of these things... I'm testing it now, as it's not fully "live" just yet: http://dev.archlinux.org/~aaron/sources/ Here's something neat which is an added bonus: any one of these things can be used to build the entire package when offline. Download the src.tar.gz, extract, and makepkg. One big lingering issue: do we need different source tarballs for each arch? My instincts tell me yes, for a few reasons: * I recall some PKGBUILDs having CARCH based 'if's around the sources * Some packages are only in one arch or another Does anyone know of a way to solve this... I don't want to bloat the disk usage for a few special cases? mayeb md5sum and symlink?

10 16

[arch-dev-public] Drop the unstable repository
by Thomas Bächler 22 Jul '08

22 Jul '08

I had this thought during the above discussion about compat-wireless: Do we really need unstable? Almost nobody uses it and let's see which packages are in there: opera-devel firefox3 kernel26mm fvwm-devel gimp-devel reiser4progs + dependencies. openoffice-devel mplayer-svn Most of the rest is so out of date and old that it should be dropped anyway (including the external modules for kernel26mm). The packages that are actually being maintained can IMO be moved to extra. Everybody who installs a -svn or -devel package probably knows it is unstable (firefox3 should be renamed to firefox-devel then). So I'm asking you: What is the point of having a repository with <30 packages, half of which are neither used nor maintained? Except maybe confusion among users (wait? enable unstable? isn't that dangerous?).

9 29

[arch-dev-public] filelists for packages
by Pierre Schmitz 21 Jun '08

21 Jun '08

Hi all, I have created a script which generates an archive containg filelists of every pacakge in our repos. This makes it possible to show a list of files on the webpage or implement some tool to search for a package by giving a filename. I have set up a cronjob (see createFileList in my home dir) for doing this once per day. It is implemented somehow incremental, so serverload is quite low. At the moment I save the output at http://dev.archlinux.org/~pierre/test-repo/. What do you think about moving those files to /home/ftp and make them available on every mirror? Filesize is not a real problem; even with using gz instead of bz2: 208K ./core/os/i686 208K ./core/os/x86_64 420K ./core/os 424K ./core 3,0M ./extra/os/i686 3,0M ./extra/os/x86_64 5,9M ./extra/os 5,9M ./extra 120K ./unstable/os/i686 116K ./unstable/os/x86_64 240K ./unstable/os 244K ./unstable 188K ./testing/os/i686 168K ./testing/os/x86_64 360K ./testing/os 364K ./testing 2,5M ./community/os/i686 2,5M ./community/os/x86_64 4,9M ./community/os 4,9M ./community 12M The file format is the same as the one used for the repo-db files for pacman. Currently I use this data to feed my webbased package browser, but make those files available to the public some users might implement some cool command line tools etc.. Pierre

3 3

[arch-dev-public] [signoff] mlocate 0.20-2
by James Rayner 20 Jun '08

20 Jun '08

Version 0.18 -> 0.20 Closed: FS#9977 FS#10224 Signoff x86_64 and x86 from me.

5 5

[arch-dev-public] On the road to KDE 4.1
by Pierre Schmitz 12 Jun '08

12 Jun '08

Hey guys, I have made some packages of the first beta release of KDE 4.1. I had to update some dependencies and put them into [testing]. I also cleaned up the QT package. Due to a file conflict with kdelibs-4 I disabled phonon. The PKGBUILDs are built from scratch and I tried to keep it as simple as possible. This is more a test on how to package this stuff rather then testing the next kde itself. My suggestion would be: Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3. I have setup such a repo as an example: [kde-testing] http://users.archlinux.de/~pierre/kde-testing/x86_64/ There are the most important parts of KDE and in addition to this an example of how we could handle old packages which depend on KDE3: kaffeine. I would like to see some comments about this and some help would be nice, too. :-) Before putting this into you pacman.conf, please read this: This repo is just for testing packaging. It's incomplete and will break things. You should uninstall all kde3-stuff before: pacman -Rcsn kde Last but not least: especially to all "adventurous users" out there: please don't use this repo if you just want to have a look at the next kde; use one of the live-cds instead. Pierre -- http://www.archlinux.de

6 12

[arch-dev-public] Repo cleanup / Package adoption
by Eric Belanger 10 Jun '08

10 Jun '08

Hi, This is yet another repo cleanup package adoption thread. There hasn't been much feedback when I last brought up the subject so let's try to fix this once for all. This is an important issue. The cleanup is mostly done. The current issue is orphaned (make)depends. I'll repeat the process. Go to https://dev.archlinux.org/wiki/Repo%20Cleanup/ There is the list of orphans and the packages that depends on them. The name of the maintainer of the package depending on orphans is also listed so just search for your name. It's as simple as that so it only takes a few minutes. Keep in mind that these orphanes are in the repo because YOUR package depends on them so they need to be maintained as well. There are still orphaned core packages. Of course, anyone is free to adopt any orphans that they wish. Once you adopted some packages, remove them from the list to keep the list up-to-date. You can also post the list of packages you have adopted in this thread and I'll take care of removing them from the wiki list. Either way, please reply in this thread to confirm that you went through the list. That will give me an idea on how many devs have checked the list. However, it is possible that some of you already have the maximum workload that they can handle so they can't really adopt any or all of their packages' orphaned depends. At least, check the list to see if your packages depends on orphaned packages and let us know. Perhaps someone else, who can add to their current workload, would be willing to adopt some of these orphans especially if they use the package that depends on them. I'm sure we'll be able to split the present orphans workload somehow between us. Currently, we just need an idea on the current workload state. In summary, we should ideally get a reply in this thread from every active dev confirming that they went though the wiki list and: a) have adopted all or some of their "assigned" orphans and have modified the list accordingly or b) have adopted all or some of their "assigned" orphans and posted a list here so I can update the wiki and/or c) have adopted none or only some of their "assigned" orphans because of too high workload or other reason. Two other points: I would like to remind everyone that after adding a package in the repo or moving it to another repo, don't forget to adopt it afterwards in the dashboard. I believe that's one reason explaining why several packages are currently orphaned. I haven't updated the wiki list since the last time except a when I happen to stumble on a new orphan so it might be slightly out-of-date compared to the dashboard orphans. When it'll be significantly smaller, I'll update it. Thanks for your cooperation, Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

12 25

[arch-dev-public] going to be offline for an unsertain time
by Andreas Radke 09 Jun '08

09 Jun '08

I'm going to move out of my own house again into a flat and will leave my former girlfriend and son here. The move will happen on 1st of June. To get a phone/dsl line in my new flat will take some time. So I'll be lost in the offline world for an uncertain time. Everybody feel free to update important packages or fix my bugs. Hope 2 c u soon. -Andy

3 4

[arch-dev-public] New DBs and the force flag
by Aaron Griffin 06 Jun '08

06 Jun '08

So, thanks to Xavier for noticing there is a bit of an issue with the force flag. Older packages do not have the FORCE flag set in the actual package file itself, so regenerating the DBs means that those kinda went poof. Additionally, the repo-add version that respects the FORCE flag in the packages was not on gerolde (it was still running pacman 3.1.0) at the time of generation. I'd like to suggest all of you who use the FORCE flag, or have PKGBUILDs with the force flag do the following: * reevaluate if it's still needed. I would guess if it hasn't needed a 'force' since before the last ISO, then we should be fine. * rebuild old packages that still need it, and resubmit * if it is a newer package, re-submit it to the db by copying to your staging dir. I will do some of this work, when I get home tonight. Would anyone be willing to throw together a quick list of packages that need checking?

2 5

[arch-dev-public] [signoff] ntfs-3g 1.0.2531-1
by Thomas Bächler 05 Jun '08

05 Jun '08

I forgot to send this message, please sign off. Just an upstream update, nothing exciting on our end.

4 3

[arch-dev-public] [signoff] syslog-ng 2.0.9-1
by Eric Belanger 05 Jun '08

05 Jun '08

In testing for both arches. Please signoff. minor upstream update from 2.0.6 to 2.0.9 Upstream changelog: 2.0.9 Sun, 23 Mar 2008 21:36:47 +0100 Bugfixes: * Fixed handling more than 256 destinations by changing the reference counter type of LogMessages to a 16 bit value. * Fixed a possible SIGABRT crash if the hosts file passed to dns-cache-hosts() had multiple entries with the same IP address. * Fixed a possible crash during startup if "-g" was specified without using "-u". 2.0.8 Thu, 31 Jan 2008 12:38:21 +0100 Bugfixes: * Fixed a regression in 2.0.7 that caused destination files not to be reopened when syslog-ng was reopened. This causes potential problems with log rotation. * Fixed DNS cache size checking, persistent DNS cache entries were also counted against dns_cache_size() which might decrease cache space significantly when a large /etc/hosts file is in use. * Fixed a bug that caused the persistent DNS cache (e.g. /etc/hosts) to be reloaded for all name resolution requests. Other changes: * Fixed sample configuration file for RedHat. * Some portability changes in loggen. * Added cygwin packaging files to contrib/cygwin-packaging. 2.0.7 Thu, 03 Jan 2008 07:01:59 +0100 Bugfixes: * Fixed UNIX domain socket destinations on Solaris. * Fixed flow-control behaviour for follow-mode source files. * Added the "mark" keyword to be an alias of "mark_freq" for compatibility with syslog-ng 1.6. * Fixed message loss in destination files during configuration reloads if syslog-ng is heavily loaded. * Fixed a possible segmentation fault in the dns-cache-host() file parsing code for improperly formatted host files. * Fixed possible "Insufficient buffer space" errors in the STREAMS driver. * Fixed the starvation of the timer used to reap unused destination files, which could cause some files never to be closed under heavy load. * Fixed ISO timestamp parsing for timestamps that have no timezone information or have a too long fraction of a second portion. * Added a workaround for possible deadlocks on /proc/kmsg and user terminals. * Fixed program name parsing that caused problems for TAG values that include the '/' character. This problem was introduced by 2.0.6. Other changes: * The fsync() option was implemented. * Added support for file sources that do not exist at startup. * Added support the "--persist-file" configuration option. * Added support for timestamps used by some LinkSys routers. * Added loggen tool to generate syslog messages at the specified rate. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 2