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

[arch-dev-public] what about "ed" now?
by Andreas Radke 06 Feb '09

06 Feb '09

I have made a change to the patch package that "ed" is now an optional dependency. I've searched through our svn and all I've found is that no other package depends on ed. I think "ed" is still a widely used *nix editor and you would expect it to be there. What do you think? Should we just keep in in 1) core(-devel), 2) move it to extra or even 3) drop it at all (means community could pick it up again). I'm somewhat between 1) and 2). The package is still well maintained upstream though releases happen only rarely. Opinions? -Andy

5 4

[arch-dev-public] Integrity Check i686 06-02-2009
by repomaint＠archlinux.org 06 Feb '09

06 Feb '09

====================================== = Integrity Check i686 of core,extra = ====================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Missing Dependencies ---------------------- biopython --> 'python-numpy' archboot --> 'netkit-telnet>=0.17-8' archboot --> 'wlan-ng26>=0.2.9-2' archboot --> 'atl2>=2.0.5-2' kdebluetooth --> 'bluez' Missing Makedepends --------------------- crda --> 'python-m2crypto' wpa_supplicant --> 'kernel26<2.6.28' martian-utils --> 'kernel26<2.6.27' gnome-speech --> 'espeak' Repo Hierarchy for Makedepends -------------------------------- core/sqlite3 depends on extra/tcl core/iputils depends on extra/opensp core/iputils depends on extra/libxslt core/iputils depends on extra/docbook-xsl core/madwifi-utils depends on extra/sharutils core/e2fsprogs depends on extra/bc core/ca-certificates depends on extra/ruby core/madwifi depends on extra/sharutils Circular Dependencies ----------------------- gcc-gcj>eclipse-ecj>gcc-gcj Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 9 Repo hierarchy problems: 8 Circular dependencies: 1

1 0

[arch-dev-public] catalyst state
by Andreas Radke 06 Feb '09

06 Feb '09

just to inform you what I have sent to the closed AMD/Ati Beta mailing list: I'm just building the packages for the final 9-1 driver for ArchLinux and run into this issue: (EE) AIGLX error: dlopen of /usr/lib64/dri/fglrx_dri.so failed (/usr/lib64/dri/fglrx_dri.so: cannot open shared object file: No such file or directory) (EE) AIGLX: reverting to software rendering Our 64bit port is built like CLFS as a pure 64bit without multilib support and puts all libs into /lib and /usr/lib instead of /lib64 and /usr/lib64. Is there any workaround other than creating an unwanted symlink or the weird sed on libglx.so (see http://www.phoronix.com/forums/showthread.php?p=59685) that I expect to be a license breaker. -Andy So far as expected no response. The mailing list is of poor state and low traffic. Most times SuSE, Ubuntu and Fedora packagers report what games don't work. We are a small distribution and and don't use their(AMD/Ati) "service" of an own build script. And I'm one of the OSS people that don't like to support closed stuff more than really needed. I once stepped into Travis foot steps without really wanting it and every month I have to spend more time on it than I want. I only have a notebook with a X300m card and don't play games at all. So I cannot confirm any bug. The only thing I check is glxinfo/glxgears and Xorg.x.log What do you all think? Is there another Developer wanting to maintain it in a good way or should we think about moving this pkg into community where it seems there's more interest. -Andy

2 1

[arch-dev-public] Maintainer wanted for ruby
by Allan McRae 04 Feb '09

04 Feb '09

Hi Devs, I don't really know enough about ruby to deal with major version updates such as the 1.9.1 release with which the 1.9 branch is declared stable. So is there another dev who would like to take the maintenance away from me? Allan

3 3

[arch-dev-public] [signoff] kernel26 2.6.28.3-1
by Tobias Powalowski 04 Feb '09

04 Feb '09

Hi guys, new kernel adresses the following things: - bump to latest version - changed to new btusb - removed buggy-acpi-patch please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

7 8

[arch-dev-public] install scripts in core
by Allan McRae 03 Feb '09

03 Feb '09

Hi, After the recent issues with install scriplets failing depending on the order packages were installed, I decided to do a complete review of the install files for every package in [core]. Here is a list of packages and commands they use which are not in their dependency tree: dbus-core: passwd (shadow) e2fsprogs: install-info (texinfo) fakeroot echo (coreutils) filesystem: chmod (coreutils) grep heimdal install-info (texinfo) inetutils install-info (texinfo) ipw2100-fw cat (coreutils) ipw2200-fw cat (coreutils) libsasl cat (coreutils) mlocate: echo (coreutils) ndiswrapper perl - /usr/sbin/ndiswrapper: /usr/bin/perl: bad interpreter: No such file or directory tiacx-firmware cat (coreutils) udev: filesystem - warning: can't open /etc/fstab: No such file or directory The install-info ones can be fixed without adding an additional dep in the same way as readline, bash and glibc now do. All the cat and echo calls can probably be replaced with a bash builtin (printf) although I have not tested. The others should have dependencies added to stop install script failures but I have not check if that would create loops (I think most are fine). The install scripts for lilo and vi also fail if bash is not installed (for some unknown reason). Lilo is just and old style "/bin/true" script so is easily fixed but I do not understand these two issues... Allan

5 14

[arch-dev-public] [PATCH] check_packages: fix stupid assumption on script location.
by Xavier Chantry 03 Feb '09

03 Feb '09

The parse_pkgbuilds.sh script was assumed to be in the current working directory, which is quite stupid since check_packages.py can be called from anywhere. Now it only assumes that check_packages.py and parse_pkgbuilds.sh are in the same directory. This should fix the empty integrity checks on arch-dev :) Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> --- cron-jobs/check_archlinux/check_packages.py | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/cron-jobs/check_archlinux/check_packages.py b/cron-jobs/check_archlinux/check_packages.py index f0fd4a5..0392368 100755 --- a/cron-jobs/check_archlinux/check_packages.py +++ b/cron-jobs/check_archlinux/check_packages.py @@ -50,12 +50,10 @@ class Depend: self.mod = mod def parse_pkgbuilds(repos,arch): - oldcwd = os.getcwd() - os.chdir(absroot) for repo in repos: - data = commands.getoutput(oldcwd + '/parse_pkgbuilds.sh ' + arch + ' ' + repo) + data = commands.getoutput(os.path.dirname(sys.argv[0]) + '/parse_pkgbuilds.sh ' + + arch + ' ' + absroot + '/' + repo) parse_data(repo,data) - os.chdir(oldcwd) def parse_data(repo,data): attrname = None -- 1.6.1.2

4 4

[arch-dev-public] Away for the weekend
by Aaron Griffin 31 Jan '09

31 Jan '09

Hey all, I'm hopping on a plane tonight and flying out to Portland for the weekend. I will bring my laptop, but will probably not spend a significant amount of time on it. Cheers, Aaron

3 3

[arch-dev-public] [signoff] fakeroot 1.12.1-1
by Andreas Radke 30 Jan '09

30 Jan '09

new upstream release. two minor fixes. please signoff. -Andy fakeroot (1.12.1) unstable; urgency=low * Remove broken alpha stat version hack from fts_read. -- Clint Adams <schizo(a)debian.org> Sun, 04 Jan 2009 13:28:00 -0500 fakeroot (1.12) unstable; urgency=low * Wrap fts_read. closes: #493681. -- Clint Adams <schizo(a)debian.org> Sun, 04 Jan 2009 00:56:25 -0500

5 5

[arch-dev-public] [signoff] bash 3.2.048-3, texinfo 4.13a-3, glibc 2.9-4, readline 5.2.013-2
by Aaron Griffin 30 Jan '09

30 Jan '09

Ok, now, thanks to Allan and Thomas, we should have these dep-cycles under control. The listed packages are in testing now, and they simply fix scriptlet install errors when installing to a clean chroot. Please test them out as I'd like to get them in core as soon as possible for the final ISO build. Cheers, Aaron

3 3