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

[arch-dev-public] Rebuild of core repo will start in few (1-2) hours
by Daniel Isenmann 19 Nov '07

19 Nov '07

Hi, after the PKGBUILD were fixed (big thanks to tpowa and Roman), I will start the rebuild of core repo in 1-2 hours. Packages which are in testing right now from core, wouldn't be affected of the rebuild. They are build with the new toolchain already. Please don't commit anything (no testing stuff, too) to the core repo until I finished and send an email as reply to this one. After finishing with rebuild, I will tag and commit the new PKGBUILDs to the core repo. I will put the packages to testing first. Be patient, because I will do the rebuild for both architectures (i686 and x86_64). If anyone doesn't agree with the rebuild, please send a reply to this email. Daniel

11 22

[arch-dev-public] [signoff] kernel26 2.6.23.8-1
by Tobias Powalowski 19 Nov '07

19 Nov '07

Hi kernel 2.6.23.1 for both arches in testing, please signoff this one adresses these bugs: http://bugs.archlinux.org/task/7135 http://bugs.archlinux.org/task/8449 http://bugs.archlinux.org/task/8500 http://bugs.archlinux.org/task/8549 - updated mactel patch 2.6.23 - updated squashfs 3.3 - added TIMER_STATS option -> all binary modules rebuilt against that - added undervolting patch - cleaned up configs - cleaned up patches - cleaned up PKGBUILD - updated unionfs to 2.1.9 - alsa status 20071117 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] Getting rid of the ABS <-> CVS link
by Aaron Griffin 19 Nov '07

19 Nov '07

Hey guys, I wanted to bring this up here to see if anyone had any input. For the longest time I have hated that ABS is dependent on our version control system. Not only that but we have this whole csup/cvsup thing which is annoying, and _now_ we hit yet another snag: csup doesn't have cvsupd, which means we can't get rid of the cvsup package on gerolde. So yeah, CVS == headache. I wanted to try to get rid of this, and Dan had a brilliant idea: * Some cron job (or even cvs hook) that does a simple export of the repo when it needs to. * rsyncd supplying that exports that dir * Modify 'abs' to use rsync * Boom, done Does anyone have any issues with something like that? Or any better ideas?

5 7

[arch-dev-public] [signoff] less 415-1
by Andreas Radke 19 Nov '07

19 Nov '07

in testing for both archs. Andy

3 2

[arch-dev-public] Simo taking over the AUR
by Paul Mattal 18 Nov '07

18 Nov '07

All, Simo has graciously volunteered to take over maintenance and releases of the AUR, effective immediately. I will continue to aid the effort, and make my work available in a git repo, location to be named when it comes into existence. Thanks to all of you for making the AUR come alive over the last few years! It's been exciting to watch our creation really brought to life by this vibrant community. I'm excited about beginning a new chapter with Simo at the helm! Best, - P

1 0

[arch-dev-public] Migration to QT4
by Pierre Schmitz 18 Nov '07

18 Nov '07

Hi all, as I mentioned some time ago I want to move qt4 to [extra] soon. I am quite busy right now; so there is some delay but I am still working on this. Before committing my changes to [testing] I want to discuss the upgrade path again. (because it will be some work to revert this changes if it was a bad idea after all) qt and qt-docs will be updated to version 4. They will replace the packages from community and provide qt4 as well. Like the community package they will be installed into /usr instead of /opt. We do not need any script in /etc/profile.d then. Version 3 of qt will be packaged as qt3 and qt3-docs. It will stay in /opt and still will have a profile script; but it will be disabled per default. All packages directly depending on qt version 3 will be repackaged to depend on qt3. The PKGBUILD have to source the profile. Packages like KDE and others depending on kdelibs do not need to be rebuilt. Pierre -- archlinux.de

6 17

[arch-dev-public] [review] News Item: Core Rebuild
by Aaron Griffin 16 Nov '07

16 Nov '07

Please review: Core Rebuild --------------------- Due to recent glibc and gcc upgrades, we figured it'd be best to rebuild the whole core repo off the new toolchain, to take advantage of the latest-and-greatest changes. Daniel has taken up this task and rebuild all packages for both architectures, and move them to [testing]. If you run into any problems, please report them on the bug tracker.

4 5

Re: [arch-dev-public] [arch] dependency cycle in core
by Roman Kyrylych 16 Nov '07

16 Nov '07

2007/11/16, Xavier <shiningxc(a)gmail.com>: > On Thu, Nov 01, 2007 at 06:15:09PM +0200, Roman Kyrylych wrote: > > 2007/11/1, Aaron Griffin <aaronmgriffin(a)gmail.com>: > > > Forwarding to the dev list in case people don't read the arch list. > > > > > > ---------- Forwarded message ---------- > > > From: Mister Dobalina <reebydobalina(a)yahoo.ca> > > > Date: Nov 1, 2007 10:27 AM > > > Subject: [arch] circular dependence in core > > > To: General Discusson about Arch Linux <arch(a)archlinux.org> > > > > > > > > > coreutils 6.9-3 -> depends on bash > > > > > > bash 3.2.025-1 -> depends on readline>=5.2 > > > > > > readline 5.2-4 -> depends on ncurses > > > > > > ncurses 5.6-4 -> depends on coreutils -> oops! > > > > > > > This was caused by this commit: > > http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/ncurses/PKGBUILD.diff?r1=… > > I think we should revert it (because dependencies of other packages > > are fine and make more sense). > > > > With the recent big rebuild in testing, pacman 3.1 detected a dependency > cycle again, which reminded me of this mail. > The cycle wasn't only caused by the commit above, because there was already > another cycle there before. > > bash 3.2.025-2 -> depends on readline>=5.2 > readline 5.2-5 -> depends on ncurses > ncurses 5.6-6 -> depends on glibc > glibc 2.7-7 -> depends on bash -> oops! > > But it looks like there are other ones as well. > I'd say we remove glibc dependency from ncurses or bash dependency from glibc. :-/ /me scratches his head -- Roman Kyrylych (Роман Кирилич)

1 0

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

16 Nov '07

Hi, Here is the second list of removal candidates. Please go through it to make sure we don't remove a package that, for some reason, should remain in extra. Some of the reason are actually questions or discussion topics so it would be nice to get some feedback on them. As said before, some of these packages can be depends of community packages. Please just dicuss them for now. I would prefer to do the actual removal myself. I will do so when the discussions will be over. ======================================================================================= Package Reason to remove it or Reason to keep it. Any comments, concerns, etc. ======================================================================================= akode will be dependency of kde4, right? (dp) apmd replaced by acpi (incorrect. needed for older machines) aria Superceded by aria2? aumix what console audio mixers do we provide? bidwatcher broken: bidding in bidwatcher is indefinitely broken because eBay has forced all bidding to occur only through signed-in clients bind DNS server. Should stay in repo. blam yet another RSS reader cccp dead project, could (maybe?) be replaced by dctc cdw project (ncurse cd-writer) has been revived, is there another console cd-writer in repo? chgres old, low usage? cplay yet another curses audio player cvsfs Discontinued. Developement has stopped in favor of cvsfs-fuse. dcd yet another command-line CD player divx4linux unused lib/codec dump tapedrive utility. it it worthy to keep? edb enlightenment db, unused efax utilities to send and receive faxes, I guess we should keep it unless another package provides fax support epic4 yet another console irc client exim what mta will we keep? font-bh-ttf should we keep it? font-bitstream-speedo who uses speedo fonts? font-misc-ethiopic i18n support, should be kept font-misc-meltho i18n support, should be kept freetype1 unused lib galeon yet another web browser gentoo yet another file manager gimp-perl low usage: perl plugin and modules for gimp gnet1 unused lib gnome-audio audio files for gnome. Are they still useful? gpgme03 obsoleted by gpgme??? gprolog Can be removed, I guess. There is another prolog compiler (swi-prolog) in repo. gpsdrive new dependencies in community, should be in community or unsupported ==> to be moved to community for Damir grcm dead project. no release since 2003 gstreamer0.10-alsaspdif gstreamer0.10-cdaudio gstreamer0.10-jack should not be removed (drastic loss of function for any gstreamer using app) - if nobody takes the gstreamer pkgs, i will (damir) gstreamer0.10-mpeg2enc gstreamer0.10-musicbrainz gstreamer0.10-pitfdll gstreamer0.10-sndfile gstreamer0.10-wavpack gstreamer0.10-x264 ircii-pana yet another console irc client irda-utils Utilities for infrared communication between devices: should be kept isapnptools ISA Plug-And-Play devices support: shopuld be kept lam MPI programming environment: low usage lib3ds free alternative to Autodesk's 3DS File Toolkit for handling 3DS files: low usage libast unused lib libflashsupport (in unstable) unused lib libgnomesu gksu and kdesu provide same functionality libping Anyone use ding in their scripts? Otherwise, unused lib/package libtrash unused lib lineak_defaultplugin The lineak packages could be substituted by my (Eric) keytouch pkg in community. It has more dependencies (gtk2) but has much or more functionality. lineak_xosdplugin same comment as above lprng we have cups standard now madplay yet another curses audio player mail-notification mail notification icon for gnome: low usage masqmail home page disappeared, another MTA mod_python used on Archlinux.org for django? nautilus-sendto nautilus extension, can be removed from extra netdude with 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-ntalk Isn't talk obsoleted by Instant Messaging and IRC? 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 pdns Do we keep it? 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) 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. prozilla multi-threaded download accelerator: low usage/usefulness ptabtools low usage: utilities to read files created by PowerTab Guitar Tablature editor (a Windows app) pure-ftpd yet another ftp server quick-lounge-applet gnome applet: low usage/usefulness samplicator home page has disappeared, looks like dead project service-discovery-applet gnome applet: low usage/usefulness setserial support for serial device, should be kept unless it's no longer needed speedtouch modem drivers, should be kept splitvt splitvt takes any VT100 terminal window and splits it vertically into two shell windows: screen does that ssmtp what mta will we keep? tiacx (in unstable) wireless drivers, should be kept tiacx-mm (in unstable) wireless drivers, should be kept tpop3d yet another pop3 server xf86-video-unichrome graphics drivers, should be kept, somebody with that hardware or the Xorg maintainer should take it xforms old, low usage xpdf-arabic i18n support, should be kept xpdf-chinese-simplified i18n support, should be kept xpdf-chinese-traditional i18n support, should be kept xpdf-cyrillic i18n support, should be kept xpdf-greek i18n support, should be kept xpdf-hebrew i18n support, should be kept xpdf-japanese i18n support, should be kept xpdf-korean i18n support, should be kept xpdf-latin2 i18n support, should be kept xpdf-thai i18n support, should be kept xpdf-turkish i18n support, should be kept 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.

6 19

[arch-dev-public] Update flashplugin to 9.0.64.0?
by Thomas Bächler 16 Nov '07

16 Nov '07

I have been using flashplugin 9.0.64.0 (which is the latest beta for the next flash 9 update) for some time. I didn't have more stability problems than with our current version (rather less) and it has support for fullscreen mode (which is awesome for youtube). I am proposing to update it in testing (or extra) and use that beta instead of the latest stable. Opinions?

5 7