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

[arch-dev-public] [signoff] mkinitcpio 0.5.17-1
by Thomas Bächler 14 Nov '07

14 Nov '07

I fixed one old bug and updated the manpage. Tested and running on x86_64.

3 2

[arch-dev-public] [signoff] kernel26 2.6.23.1-8 and binary modules rebuilt
by Tobias Powalowski 14 Nov '07

14 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 - updated alsa - updated unionfs - updated squashfs - added TIMER_STATS option -> all binary modules rebuilt against that - added undervolting patch - added more stable-tree patches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-dev-public] Plan for third removal candidates list
by Eric Belanger 14 Nov '07

14 Nov '07

Hi, I just posted the second list of removal candidates. There will be a third and possibly final removal candidates list. Please check https://www.archlinux.org/wiki/Repo%20Cleanup/ to add comments to packages that haven't been commented yet. As I'm unfamiliar to the remaing stuff and there isn't much interest in checking the wiki list, I plan to submit them to the list (after discussion and removal of the second list) for removal even if they have no comments. If you think it would be useful for discussion, I could add in the package description to replace the reason. How does that sound? Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

[arch-dev-public] Improving/Simplifying Kernel PKGBUILD
by James Rayner 13 Nov '07

13 Nov '07

Some people liked this idea... http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/kernel26/PKGBUILD?rev=1.2… - We could put the patches into a patchset. tpowa has expressed dislike for this idea before, though it actually makes it easier to maintain. It'd allow the documentation to be moved out of the PKGBUILD, make the patches more accessible and the PKGBUILD cleaner. The only other things I can think of have alarm bells and are covered in red paint. Any other ideas? James

4 4

[arch-dev-public] Kernel - vanilla vs patched?
by Tom K 13 Nov '07

13 Nov '07

Well, this kicked itself off in IRC this morning (timezone GMT+1), and as it seems most people didn't see it and/or didn't participate, we should probably do it here. Here's the question, as I see it - what do we patch kernel26 for? Bugfixes? Stability? Enhancements? New features? Other? Specific case under discussion: http://bugs.archlinux.org/task/8500 - a request, from a single user so far, for a new feature in the kernel. We also have, or had, a request for fbsplash (closed, of course) and there are probably others - Romashka? My understanding of The Arch Way, as it applies here, is that we patch for bugfixes e.g. ipw2x00, and for enhancements to existing functionality e.g. alsa. In the referenced bug report, there are differing dev views expressed - as I'm posting this, I'll include my view, which is that we should not add new features to kernel26. I'll also include a possible compromise: /me grabs big can of worms, opens it, pours it out onto DevLand :) Two kernels - a strictly as-vanilla-as-possible kernel26 in Core, and a more let's-try-new-features-here kernel26extra in Extra. It could be in Community either, but I would see it as an official Arch package, supported by the dev team. I would be happy to maintain it if necessary, along with the usual array of external module packages - in cooperation, of course, with the current kernel maintainers. Right now, anyone who has read the IRC log knows how Tobias P and Aaron feel about it, but I expect others have views on this topic too, so let's hear them. Regards Tom.

14 34

[arch-dev-public] Status Report Reminder
by Aaron Griffin 12 Nov '07

12 Nov '07

Just a poke for everyone - I'm switching the status reports to every 2 weeks, as it gives us more time to do things. So if you need something to do, take a look there. Thanks to Daniel for doing the legwork for the core rebuild, and Dan for all the pacman bug closing (Special thanks to Nathan Jones here too for all his work). Feel free to email me personally with any issues or whatnot if they come up.

1 0

[arch-dev-public] cleanup testing i686
by Andreas Radke 12 Nov '07

12 Nov '07

please check what can be removed or moved to core/extra from the ftp/testing/os/i686 folder! i686 aufs-20071017-1-i686.pkg.tar.gz avahi-0.6.19-1.pkg.tar.gz boost-1.34.0-2.pkg.tar.gz celestia-1.4.1-4.pkg.tar.gz codecs-20071007-1-i686.pkg.tar.gz csup-20060318-3-i686.pkg.tar.gz emacs-22.1-1.pkg.tar.gz ffmpeg-20071009-1-i686.pkg.tar.gz fglrx-8.42.3-1-i686.pkg.tar.gz fglrx-utils-8.42.3-1-i686.pkg.tar.gz initscripts-2007.11-1-i686.pkg.tar.gz ivtv-utils-1.0.2-1-i686.pkg.tar.gz jre-6-3.pkg.tar.gz klibc-1.5-3-i686.pkg.tar.gz klibc-extras-2.3-1-i686.pkg.tar.gz klibc-module-init-tools-3.2.2-1-i686...> klibc-udev-116-2-i686.pkg.tar.gz km-0.6.1-1.pkg.tar.gz libgl-7.0.1-1-i686.pkg.tar.gz mdadm-2.6.4-1-i686.pkg.tar.gz mesa-7.0.1-1.pkg.tar.gz mkinitcpio-0.5.16-1-i686.pkg.tar.gz mlocate-0.18-1-i686.pkg.tar.gz mplayer-1.0rc2-1-i686.pkg.tar.gz nss-mdns-0.10-1.pkg.tar.gz ntop-3.3-3.1-i686.pkg.tar.gz openchrome-20070903-1.pkg.tar.gz packages.txt pixman-0.9.5-3-i686.pkg.tar.gz renderproto-0.9.3-1-i686.pkg.tar.gz screen-4.0.3-4.pkg.tar.gz synaptics-0.14.6.99-1-i686.pkg.tar.gz testing.db.tar.gz unichrome-dri-7.0.1-1-i686.pkg.tar.gz xf86-input-acecad-1.2.1-1-i686.pkg.ta..> xf86-input-aiptek-1.0.1-4-i686.pkg.ta..> xf86-input-calcomp-1.1.1-1-i686.pkg.t..> xf86-input-citron-2.2.1-1-i686.pkg.ta..> xf86-input-digitaledge-1.1.0-4-i686.p..> xf86-input-dmc-1.1.1-1-i686.pkg.tar.gz xf86-input-dynapro-1.1.1-1-i686.pkg.t..> xf86-input-elo2300-1.1.1-1-i686.pkg.t..> xf86-input-elographics-1.1.0-4-i686.p..> xf86-input-evdev-1.1.5-4-i686.pkg.tar.gz xf86-input-fpit-1.1.0-4-i686.pkg.tar.gz xf86-input-hyperpen-1.1.0-4-i686.pkg...> xf86-input-jamstudio-1.1.0-4-i686.pkg..> xf86-input-joystick-1.2.3-2-i686.pkg...> xf86-input-keyboard-1.2.2-2-i686.pkg...> xf86-input-magellan-1.1.1-1-i686.pkg...> xf86-input-magictouch-1.0.0.5-5-i686...> xf86-input-microtouch-1.1.1-1-i686.pk..> xf86-input-mouse-1.2.3-1-i686.pkg.tar.gz xf86-input-mutouch-1.1.0-4-i686.pkg.t..> xf86-input-palmax-1.1.0-4-i686.pkg.ta..> xf86-input-penmount-1.2.1-1-i686.pkg...> xf86-input-spaceorb-1.1.1-1-i686.pkg...> xf86-input-summa-1.1.0-4-i686.pkg.tar.gz xf86-input-tek4957-1.1.0-4-i686.pkg.t..> xf86-input-ur98-1.1.0-4-i686.pkg.tar.gz xf86-input-vmmouse-12.4.3-1-i686.pkg...> xf86-input-void-1.1.0-2.pkg.tar.gz xf86-video-amd-2.7.7.3-1-i686.pkg.tar.gz xf86-video-apm-1.1.1-4-i686.pkg.tar.gz xf86-video-ark-0.6.0-4-i686.pkg.tar.gz xf86-video-ati-6.7.195-1-i686.pkg.tar.gz xf86-video-chips-1.1.1-4-i686.pkg.tar.gz xf86-video-cirrus-1.1.0-4-i686.pkg.ta..> xf86-video-dummy-0.2.0-4-i686.pkg.tar.gz xf86-video-fbdev-0.3.1-4-i686.pkg.tar.gz xf86-video-glint-1.1.1-5-i686.pkg.tar.gz xf86-video-i128-1.2.1-4-i686.pkg.tar.gz xf86-video-i740-1.1.0-4-i686.pkg.tar.gz xf86-video-i810-1.7.4-6-i686.pkg.tar.gz xf86-video-imstt-1.1.0-4-i686.pkg.tar.gz xf86-video-intel-2.1.1-2-i686.pkg.tar.gz xf86-video-mga-1.9.100-1-i686.pkg.tar.gz xf86-video-neomagic-1.1.1-4-i686.pkg...> xf86-video-nv-2.1.6-1-i686.pkg.tar.gz xf86-video-rendition-4.1.3-4-i686.pkg..> xf86-video-s3-0.5.0-4-i686.pkg.tar.gz xf86-video-s3virge-1.9.1-8-i686.pkg.t..> xf86-video-savage-2.1.3-1-i686.pkg.ta..> xf86-video-siliconmotion-1.5.1-4-i686..> xf86-video-sis-0.9.3-5-i686.pkg.tar.gz xf86-video-sisusb-0.8.1-4-i686.pkg.ta..> xf86-video-tdfx-1.3.0-6-i686.pkg.tar.gz xf86-video-trident-1.2.3-5-i686.pkg.t..> xf86-video-tseng-1.1.1-4-i686.pkg.tar.gz xf86-video-unichrome-0.2.6-6-i686.pkg..> xf86-video-v4l-0.1.1-4-i686.pkg.tar.gz xf86-video-vesa-1.3.0-5-i686.pkg.tar.gz xf86-video-vga-4.1.0-4-i686.pkg.tar.gz xf86-video-via-0.2.2-4-i686.pkg.tar.gz xf86-video-vmware-10.15.2-1-i686.pkg...> xf86-video-voodoo-1.1.1-4-i686.pkg.ta..> xorg-server-1.4-4-i686.pkg.tar.gz

8 12

[arch-dev-public] Please fixing and core rebuild (was: rebuilding the whole core repo)
by Daniel Isenmann 12 Nov '07

12 Nov '07

Hi, this is a summary of the previous mails. The following list should be fixed by the corresponding package maintainer. Try to add license as well to those packages. If some packages not fixed since Saturday, I will do it on my own. After fixing I can rebuild the whole [core] on my own. It's not really much work, runs mostly alone. Ok, here comes the list: core/base packages: ------------------- e2fsprogs: makedepends on 'bc', which is in [extra] gcc-libs: ==> Starting build()... You need the de_DE locale to build gcc. ==> ERROR: Build Failed. Aborting... Jan mentioned it in another mail, so this is ok. glibc: failure on getting source, wrong: ftp://ftp.archlinux.org/other/glibc-patches-2.7-3.tar.bz2 right: ftp://ftp.archlinux.org/other/glibc/glibc-patches-2.7-3.tar.bz2 iputils: makedepends on 'jade', which is in [extra] kernel26: wrong md5sum for file config klibc-extras: failure on getting source, wrong: http://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 right: ftp://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 pacman: makedepend on 'doxygen', which is in [extra] reiserfsprogs: failure on getting source, connection timed out on server syslog-ng: makedepend on 'glib2', which is in [extra] vi: ----snip--- having patch file:7.1.147 having patch file:7.1.148 Number of patches does not match the patchlevel! Edit the PKGBUILD accordingly! ==> ERROR: Build Failed. Aborting... Jan mentioned it in the other email, too. core/lib packages: ------------------ everything builds fine core/devel pacakges: -------------------- fakeroot: source doesn't exists anymore on server gcc: libstdc++-man-4.2.0.tar.bz2 doesn't exists anymore on server core/support packages: ---------------------- bcm43xx-fwcutter: missing arch-tag in PKGBUILD capi4k-utils: compiling fails with errors, maybe of the new gcc/glibc gpm: compiling fails with errors, maybe of the new gcc/glibc madwifi-utils: depends on 'sharutils', which is in [extra] rt2x00-cvs: depends on command 'cvs', which is in [extra] wlan-ng26-utils: compiling fails with errors wlan-ng26: fails, because of missing -util package, see error above That is the list, could every maintainer of the package please have a look at those packages and add missing licenses if needed? On Saturday evening, I'm going to fix those PKGBUILDs on my own and start the first attempt for a complete [core] repo. Because of those dependencies of the packages which are in extra (and we don't want them in core), maybe I can build the dependencies with -b option in makeworld (I have tested it, it works). Any words against the whole process? Daniel

6 10

[arch-dev-public] [signoff] glib2 2.12.3-1
by Jan de Groot 12 Nov '07

12 Nov '07

As brought up during discussions several times, glib2 has been moved to core as it is a makedepend for syslog-ng. Together with the move I updated this one to 2.12.3, which fixes some warnings, updates some documentation which we delete anyways, updates some translations and fixes a memleak. Please signoff for both architectures.

4 4

Re: [arch-dev-public] Migration to QT4
by Pierre Schmitz 11 Nov '07

11 Nov '07

Am Sonntag, 11. November 2007 20:34:20 schrieb Vinay Shastry: > I have read only access to the list. Hence the personal message. > > On Nov 11, 2007 4:14 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > > Hi, > > > > I just finished uploading all qt related packages into [testing] (x86_64 > > and i686). > > Oh my qt4 packages!!! all gone! ;-) > > > <snip> > > Next steps: > > * review the qt-4 package: > > * should we add/remove congigure options? > > IMO, don't think so. I've tried to keep all reasonable options turned on. Well I have disabled the nas support. I don't see any reason for an additional sound server. > > > * What are those kde-copy patches? > > ... patches for Qt that haven't been accepted by TrollTech > yet. All patches in this directory itself shouldn't make qt-copy > incompatible to official Qt, patches adding new API etc. belong to the > notsafe/ subdirectory. > http://websvn.kde.org/trunk/qt-copy/patches/README?revision=734649&view=mar >kup > > Please note that these will need constant updating, as we can expect > bugs in qt to be fixed now and then. Thanks for the hint. I should drop a line about this in the next PKGBUILD. > > > * do we need to split it into qt, qt-core and > > qt-qt3support? * currently there is no non-gui package which requires qt, > > so I decided we can do this later > > Yes, I don't know any either, but it's a good thing to split into > core, gui and qt3 support. But since pacman/makepkg doesn't have even > the simplest of splitting functionality, I stopped banging my head on > this. Would be nice to see if someone solves this "elegantly" ;-) Currently there is no elegant solution. If QT does not support the splitting by providing different configure options (at least for qt3support it does) one has to compile the whole stuff three times and remove the garbage. But as I said. This can be done when needed. > > > * Do we need to introduce "legacy" packages for libs like > > pyqt, poppler-qt, qscintilla, qca-tls, qca? > > If we only need them for KDE there should be no problem; > > at least after the switch to KDE4 > > I think it's a good idea to provide "pkgname-qt3" for qt3 stuff, and > just "pkgname" for qt4. > > > Regarding qt3 package, it can be easily fixed so that the usual > ./configure scripts work without any need of sourcing the qt3 profile > from /etc/profile.d, and also calling qmake by full path will work for > qt3 apps. I can help with that if you are interested. Well I figured out that some packages compile fine without the profile but others don't. I would be happy for any suggestions. > > Also, just 1 week in testing seems too less for this... wanna extend a > bit just to be safe? :) Yes, at least one week. I have tested this stuff locally several days or even weeks without any problems. The only problems I currently expect are compile time issues. > > > One more question i have for you is.. why the renaming and trouble of > rebuilding everything? Why not let Qt 3.X be the "qt" package, and we > use "qt4" and "kdefoo4" for Qt 4.x and KDE 4.x series packages? Because it's fun. :-) We normally do not provide several versions of the same package. A lot of projects will switch to qt-4 soon anyway. QT3 will be only for legacy apps and perhaps we even do not need it anymore in future. Of course this is has no strong technical motivation. Pierre -- archlinux.de

1 0