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

[arch-dev-public] [signoff] shell rebuilds
by Dan McGee 02 Dec '07

02 Dec '07

Looking for a signoff for i686 for the following packages in testing: bash dash (new) hwdetect shadow filesystem Most of the updates deal with adding a new shell and a new provide (sh), and the update to shadow is to remove its dependency on coreutils which was one of our remaining circular dependencies. I'd appreciate it if someone wanted to rebuild these for x86_64- I wouldn't feel comfortable building a core package outside a chroot, which I currently do not have access to. -Dan

4 7

[arch-dev-public] noarch packages vs FTP & DB
by Roman Kyrylych 02 Dec '07

02 Dec '07

2007/11/28, Aaron Griffin <aaronmgriffin(a)gmail.com>: > On Nov 27, 2007 4:56 PM, Jason Chu <jason(a)archlinux.org> wrote: > > > > * Architecture Independent Repos > > > > > > More correct: Architecture Independent Packages > > > They were intended to be placed in the same repos as i686/x86_64 > > > packages, and in the same db.tar.gz > > > They can be placed in $repo/os/any/ dir on FTP servers though (to save > > > the space and traffic for mirrors) > > > with $repo/os/{i686,x86_64}/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz > > > being a symlink to ../any/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz > > > (this is because packages should be in the same dir as .db.tar.gz for > > > pacman to download them). > > > > Are you sure about that? I thought they were going to be separate repos > > that would be usable in x86_64 and i686. That way we'd save bandwidth > > (upload and download) and storage space *and* save time building packages. > > I could go either way here - I don't have a strong opinion, but jason > has a point about size (bandwidth, disk space, etc). > They cannot be separate _repos_, because the only way to get this clearly would be to create [core-any], [extra-any] etc, which is bad. They can/should/will be in _separate_FTP_dir_ though (which is not the same as a separate repo) - in $ftpurl/$repo/os/any, but here are some issues (one of which I didn't notice when I first proposed noarch packages): How pacman downloads packages from a repo: for example, on i686 system this is in pacman.conf: [somerepo] Server=ftp://someurl/somerepo/os/i686/ Pacman searches for somerepo.db.tar.gz there and for every package listed in that db it tries to download a package _from_the_same_dir_. Solution #1: 1) noarch packages are mentioned in both i686 & x86_64 .db.tar.gz 2) just create a symlink from $repo/os/{i686,x86_64}/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz to ../any/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz so noarch packages will be stored only in one place on ftp - $repo/os/any, but will be downloaded in the same way as other (arch-specific) packages for user's architecture. Note that there is no $repo.db.tar.gz in $ftpurl/os/any. 3) mirrors should sync with symlinks (I believe most of them already do this after the current->core move). 4) if someone wants to create a mirror for i686 packages only (for example) - he/she can simplyfy it by using rsync's option to store symlinked file in the place of symlink. So user will get *-{any,i686}.pkg.tar.gz files mixed in a single ~/mirror-for-my-i686-box/$repo dir. This doesn't require any change to pacman or pacman.conf, just ensuring that mirror is getting the $repo/os/any dir too (which is not a problem since most mirrors do a full FTP rsync). Solution #2: 1) Pacman 3.1 already has only one /etc/pacman.d/mirrorlist file for all repos with contents like: Server = ftp://ftp.archlinux.org/$repo/os/i686 and in pacman.conf there is: [core] Include=/etc/pacman.d/mirrorlist Pacman replaces '$repo' with 'core' automatically during a sync operation. 2) Add a similar support for $arch: Server = ftp://ftp.archlinux.org/$repo/os/$arch On i686 machine pacman should replace '$arch' with 'i686' and then with 'any'. This way we will have 3 different .db.tar.gz for ftp dir, including $repo/os/any/$repo.db.tar.gz And we there will be no symlinks in $repo/os/{i686,x86_64} dir. 3) For cross-distro usage it's better not to hardcode $arch=($CARCH 'any') but make it cofigurable (at least at build time). 4) Modify pacman's output so it produces a single progress meter for a repo, not 2 for each 'i686' and 'any' db file. 5) extract 'i686' and 'any' dbs to a single /var/lib/pacman/sync/$repo but then it should guess from which ftp dir to download package (taking -prefix into account again? or store arch info in db?) The difference between 2 solutions is: #1 - still one db per repo per arch, still simple repo-syncing and package downloading (no modifications in pacman & pacman.conf needed) FTP structure: $ftpurl/$repo/os/i686/ : $repo.db.tar.gz $pkgname-$pkgver-$pkgrel-i686.pkg.tar.gz $pkgname-$pkgver-$pkgrel-any.pkg.tar.gz -> ../any/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz $ftpurl/$repo/os/x86_64/ : $repo.db.tar.gz $pkgname-$pkgver-$pkgrel-x86_64.pkg.tar.gz $pkgname-$pkgver-$pkgrel-any.pkg.tar.gz -> ../any/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz $ftpurl/$repo/os/any/ : $pkgname-$pkgver-$pkgrel-any.pkg.tar.gz #2 - 2 dbs per repo per arch, pacman has to download/unpack/merge 2 dbs and download packages from 2 dirs. FTP structure: $ftpurl/$repo/os/i686/ : $repo.db.tar.gz $pkgname-$pkgver-$pkgrel-i686.pkg.tar.gz $ftpurl/$repo/os/x86_64/ : $repo.db.tar.gz $pkgname-$pkgver-$pkgrel-x86_64.pkg.tar.gz $ftpurl/$repo/os/any/ : $repo.db.tar.gz $pkgname-$pkgver-$pkgrel-any.pkg.tar.gz While FTP structure in #2 seems cleaner - the implementation is complex and brings more pain than goodness. So I strongly prefer #1 and am going implement it in our db scripts and devtools/aurtools as soon as time permits. -- Roman Kyrylych (Роман Кирилич)

3 2

[arch-dev-public] Firefox install issue
by Aaron Griffin 30 Nov '07

30 Nov '07

Hey guys, I'm bringing this up here: http://bugs.archlinux.org/task/8780 There was an oops in our none-too-smart DB scripts. The scripts say firefox 2.0.0.10-2 but the FILENAME points to the 2.0.0.10-1 file. There actually WASN'T a -2 version but the PKGBUILD had -2 While this is actually NOT critical, and causes no real issues, it causes _apparent_ issues Users actually notice, and think there is an error. Simply downgrading the DB to -1 doesn't work because pacman thinks everyone has -2 installed. I've closed like 5 bug reports about this and there are forum threads and ML threads about it. Would someone mind simply rebuilding a -3 version to get rid of the belief that this is an error and make everything a bit more sane? I'd do it but I won't have time to test for maybe 6 hours or so. Thanks, Aaron

2 2

[arch-dev-public] Fwd: Your message to aur-general awaits moderator approval
by Roman Kyrylych 30 Nov '07

30 Nov '07

Hey, WTF? I was able to send a messagee to aur-general yesterday, but have just got this a minute ago: ---------- Forwarded message ---------- From: aur-general-bounces(a)archlinux.org <aur-general-bounces(a)archlinux.org> Date: 30 Лис 2007 13:10 Subject: Your message to aur-general awaits moderator approval To: roman.kyrylych(a)gmail.com Your mail to 'aur-general' with the subject Re: [arch-dev-public] Why do we still have compatibility rename for community? Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://archlinux.org/mailman/confirm/aur-general/c87479fd5b004a01398a8b77c9… -- Roman Kyrylych (Роман Кирилич)

3 8

[arch-dev-public] [signoff] openssh 4.7p1-6
by Aaron Griffin 30 Nov '07

30 Nov '07

This is a repeat of the last email. -6 Fixes the xauth issue for good. The following changes have been made: FS#8729, Fix bad 'xauth' path when the binary isn't present (wasn't built in a chroot on i686 :oops:) FS#7996, Add /etc/conf.d/sshd for SSHD_ARGS params passed to sshd on startup FS#8505, disable strip as a configure flag so makepkg can decide whether or not to strip FS#8373, enable kerberos authentication (configure flag) Will be in testing for both arches in a few minutes Thanks, Aaron

4 4

[arch-dev-public] Third list of removal candidates
by Eric Belanger 30 Nov '07

30 Nov '07

Hi, Here is the third sublist. It contains the packages from the second list that for which no decision has been made plus the remaining orphans in the wiki list. There might be a fourth sublist if there are still some stray orphans remaining. If you think a package should be kept or disagree about the comments, say it so. If you think all these packages can be removed, also say it so. If you want to adopt one of these packages, please adopt it through the dashboard and let me know. ====================================== adns Description: adns is an asyncronous replacement resolver library aide Description: AIDE (Advanced Intrusion Detection Environment) is a file integrity checker akode it seems like it will be dependency of kde4. Any takers? apmd replaced by acpi (incorrect. needed for older machines) aria Different from aria2. Do we keep? Is the maintainer of aria2 interested? aumix works with oss, do we keep? bchunk Description: A Tool to Convert .raw .bin files to an ISO file dctc Description: A Direct Connect clone dmcradio Description: A ncurses-based console program for radio tuner cards. efax utilities to send and receive faxes, I guess we should keep it unless another package provides fax support evms Description: Enterprise Volume Management System font-bitstream-speedo who uses speedo fonts? font-misc-ethiopic i18n support, should be kept font-misc-meltho i18n support, should be kept genius Roman: it's a gnome app. Description: Advanced calculator including a mathematical programming language giftoxic Description: A GTK frontend for the giFT daemon gimp-perl low usage: perl plugin and modules for gimp gnome-audio audio files for gnome. Part of gnome-extra group. Any takers? Jan? Roman? gpart Description: Gpart is a tool which tries to guess the primary partition table of a PC-type hard disk in case the primary partition table in sector 0 is damaged gpgme03 obsoleted by gpgme??? gprolog Can be removed, I guess. There is another prolog compiler (swi-prolog) in repo. hashalot Description: A tool to hash stuff hnb Description: hierarchical notebook (hnb) is a curses program to structure many kinds of data in one place httptunnel Description: httptunnel creates a bidirectional virtual data connection tunnelled in HTTP requests httrack Description: HTTrack is an easy-to-use offline browser utility. hypermail Description: Hypermail is a program that takes a file of mail messages in UNIX mailbox format and generates a set of cross-referenced HTML documents idesk Description: idesk plops icons down on your root window (desktop). ijb Description: The Internet Junkbuster Proxy (TM) blocks unwanted banner ads and protects your privacy from cookies and other threats ippl Description: IP Protocols Logger ipvsadm Description: The IP Virtual Server administration utility ircd Description: Internet Relay Chat Daemon irda-utils Utilities for infrared communication between devices: should be kept isapnptools ISA Plug-And-Play devices support: shopuld be kept jetty Description: A full-fledged production-grade lightweight Java Servlet Container jpilot Description: A desktop organizer application for the palm pilot km (in testing) Only present in i686 testing. Contains 2 kernel modules (km_drv and km_api_drv) built for 2.6.20 libgnomesu gksu and kdesu provide same functionality libidl unused lib libsvg unused lib masqmail home page disappeared, another MTA mikmod Description: MikMod is an open source curses module player based on libmikmod mod_python used on Archlinux.org for django? mod_security Description: An open source intrusion detection and prevention engine for web applications mpcut Description: This program allows you to visualise the power levels in each frame of an MP3 file, select a number of frames, cut out frames you don't want, and then save the selected frames (excluding the cuts) to a separate MP3 file. mrtg Description: Multi Router Traffic Grapher. netdude w libnetdude & libpcapnav used to inspect/manipulate tcpdump trace files. Should we keep it? netgo a tool for changing network settings quickly and easily: Is it still useful/usable with the latest network scripts? netkit-bootparamd Do we keep? netkit-ntalk Isn't talk obsoleted by Instant Messaging and IRC? netpipes Description: The netpipes package makes TCP/IP streams usable in shell scripts ngrep Description: A grep-like utility that allows you to search for network packets on an interface nss_ldap Description: The nss_ldap module provides the means for Linux and Solaris workstations to resolve the entities defined in RFC 2307 from LDAP directories. oidentd ident server like pidentd (orphaned). Which one should we keep or should we remove both? openchrome graphics drivers, should be kept unless it can be replaced by xf86-video-unichrome. Jürgen: you updated it recently, do you want to adopt it? pam_ldap Description: The pam_ldap module provides the means for Solaris and Linux workstations to authenticate against LDAP directories, and to change their passwords in the directory. pam_mysql Description: A PAM module to authenticate users against mysql. pan Description: A powerful Newsgroup Article reader based on GTK2 pdns-ldap unused lib, might be included in pdns (currently orphaned) pdns-mysql unused lib, might be included in pdns (currently orphaned) pdns-pgsql unused lib, might be included in pdns (currently orphaned) pdns-recursor Description: PowerDNS recursor pdq Description: pdq is a direct replacement of lpr perl-email-date unused perl module. To Jan: You added it to the repo 2 months ago with several other perl packages. Did you forgot to adopt them or are they future dependencies? pidentd ident server like oidentd (orphaned). Which one should we keep or should we remove both? powernowd Do we need it? We already have cpudyn and cpufreq. As a decision been made? pppconfig Description: A text menu based utility for configuring ppp. revelation Description: Password manager for the GNOME 2 desktop sclient Description: A small GTK-based MUD client for X sendfile Description: The sendfile client transfers files to the sendfile daemon of the recipient's host sharpconstruct Description: A real-time modeller for 3D sculpt models shorten Description: Shorten is an established low complexity waveform coder which uses a lossless compression scheme, superior to that of mp3 sloth Description: Sloth allows you to slow down a specified application by specifying (in milliseconds) the delay on the process speedtouch modem drivers, should be kept splitvt splitvt takes any VT100 terminal window and splits it vertically into two shell windows: screen does that ssldump Description: an SSLv3/TLS network protocol analyzer tiacx (in unstable) wireless drivers, should be kept tiacx-mm (in unstable) wireless drivers, should be kept tmda Description: Tagged Message Delivery Agent. urlview Description: A curses URL parser for text files valknut Description: Direct Connect 4 Linux File Sharing program. vbetool Description: vbetool uses lrmi in order to run code from the video BIOS vconfig Description: VLAN configuration utility weex Description: With weex, the maintainer of a web site or archive that must be administered through FTP interaction can largely ignore that process wxpython Description: A wxWidgets GUI toolkit for Python. x2vnc Description: Lets you use two monitors on two different computers one one computer x2x Description: Control one X display from another xautolock Description: An automatic X screen-locker/screen-saver xf86-input-* Xorg maintainer should adopt those xf86-video-intel Xorg maintainer should adopt it xf86-video-unichrome graphics drivers, should be kept, somebody with that hardware or the Xorg maintainer should take it xpdf-arabic i18n support, should be kept. Is xpdf maintainer interested? xpdf-chinese-simplified xpdf-chinese-traditional xpdf-cyrillic xpdf-greek xpdf-hebrew xpdf-japanese xpdf-korean xpdf-latin2 xpdf-thai xpdf-turkish xprobe Description: tool for remote OS fingerprinting based on ICMP responses received from the host yp-tools Description: yp-tools is an implementation of the NIS client tools for Linux ytalk Description: A client of the talk/ntalk inet daemon zebra Description: Manages IPv4 and IPv6 routing protocols zsh very popular. iphitus will adopt if nobody else will ============================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

13 25

[arch-dev-public] Why do we still have compatibility rename for community?
by Varun Acharya 30 Nov '07

30 Nov '07

Hi Devs/TU's, Why do we still have the renaming of packages in community so that packages are uploaded without the '-arch' in the filename? Official repo's were converted a while back, any reason were not editing communitypkg to do the same? Varun

4 4

[arch-dev-public] giFT (was: Third list of removal candidates)
by Dan McGee 29 Nov '07

29 Nov '07

On Nov 29, 2007 2:30 PM, K. Piche <kpiche(a)rogers.com> wrote: > > On Thu, 2007-11-29 at 14:09 +0200, Roman Kyrylych wrote: > > 2007/11/27, Eric Belanger <belanger(a)astro.umontreal.ca>: > > > > > > [skipping gnome packages that Jan answered about] > > > > > evms Description: Enterprise Volume Management System > > I don't know who uses it but it's kinda important package. > > > > > giftoxic Description: A GTK frontend for the giFT daemon > > It's from 2003. giFT and OpenFT are from 2004 and 2005. Oldies... :-) > > > I won't cry if we drop the gift set of packages. No updates in years. Does anyone know why this project stopped development? I installed it the other day, gave it a try, and was astounded to see it hasn't been updated in forever. Seems like a good concept but maybe bittorrent just grew too strong. -Dan

1 0

[arch-dev-public] Best practice for consecutive signoffs?
by Tom K 29 Nov '07

29 Nov '07

Dan has shadow 4.0.18.1-8 in testing, pending signoff. Meanwhile, I have shadow 4.0.18.2-1 ready to upload - new upstream ver + bugfixes/requests. Do I wait for 4.0.18.1-8 to go to core, or will I replace Dan's package with mine in testing? T.

3 2

[arch-dev-public] qt>=4 release schedule
by Damir Perisa 29 Nov '07

29 Nov '07

hi devs, qtiplot 0.9 is now in testing and cannot be backported to work. (0.8.9 needs old qt>=3 but has also quite some problems for building) therefore the only actually working qtiplot is now in testing. it depends on qt>=4 and pyqt>=4 (and newest qwt and qwtplot3d) details here: http://bugs.archlinux.org/task/6673 so i'm wondering if there is some news or a schedule of the release of new qt pkgs now in testing. what needs to be tested/rebuild so that we can move qt and all other pkgs related to it to extra? for me everything qt4 related works so far for me (x86_64). - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

5 8