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

[arch-dev-public] [signoff] libarchive
by Dan McGee 14 Nov '07

14 Nov '07

I version bumped libarchive from 2.2.X to 2.4.0 today, and would appreciate a bit of testing before I move it to core. Best test cases are: * use bsdtar to extract and create some archives * use pacman Can someone also rebuild this for x86_64 and then we can get signoffs for both architectures? -Dan

4 3

[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

[arch-dev-public] [signoff] fakeroot 1.8.4-1
by Andreas Radke 11 Nov '07

11 Nov '07

please test it a bit more intensiv. those who can please test also if this bug is solved: http://bugs.archlinux.org/task/8214 see changelog: http://packages.debian.org/changelogs/pool/main/f/fakeroot/fakeroot_1.8.4/c… sign it off if all is fine for you. Andy

7 8

[arch-dev-public] [signoff] glibc 2.7-6
by Andreas Radke 10 Nov '07

10 Nov '07

another day, another glibc... the two broken locales have been fixed. and the weekday patch has been disabled to fix #8530. please signoff Andy

5 6

[arch-dev-public] [Package cleanup] beryl gone
by Thomas Bächler 09 Nov '07

09 Nov '07

Thanks to Danimoth, we now have a stable compiz-fusion release in community, which packages that actually seem to work. He is putting lots of work in maintaining those AFAICS, so the best course of action is to keep the stuff in community under his watch. As it hasn't been maintained for months and there has been a conflict between beryl's and fusion's emerald, I have just dropped beryl from the extra repository. However, the package files are still available at http://www.archlinux.org/~thomas/beryl/i686/ http://www.archlinux.org/~thomas/beryl/x86_64/ They won't be maintained or anything, they will simply sit there for everyone who may still need them.

1 0

[arch-dev-public] [signoff] kernel26 2.6.23.1-7
by Tobias Powalowski 09 Nov '07

09 Nov '07

Hi kernel 2.6.23 for both arches in testing, please signoff this one adresses these bugs: http://bugs.archlinux.org/task/8549 http://bugs.archlinux.org/task/8449 http://bugs.archlinux.org/task/8500 - updated mactel patch - updated alsa - updated unionfs - 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

2 1

[arch-dev-public] Status Report: 2007-11-05
by Aaron Griffin 09 Nov '07

09 Nov '07

ArchLinux Status Report, 2007-11-05 =================================== Aaron Griffin (Reviewed by Travis Willard) So, some of you may have noticed there was no Status Report last week. Well, see, I got busy. No one to blame but myself. I _was_ going to get it out on Tuesday, but decided to "roll with it", as it were. So, before we get started, I wanted to get some honest opinions - does doing this every 2 weeks make you guys feel less pestered? One important thing to note: for anyone looking for "something to do", the reason I list a lot of thing here is that I feel we should get them done. If you're looking for things to do, I'd appreciate it if you took a look at this list to see if there's something you can tackle. == Newsworthy Items == * New Logo Competition has begun! The competition for the new Arch logo, spearheaded by Travis, has begun. Full details can be found in this news item: http://archlinux.org/news/359/ * New Newsletter Format Eduardo Romero (kensai) has taken over doing our newsletter, and has changed the format and content. Take a look, and let him know what you think - I, for one, think it's great. Thanks a lot for all the effort Eduardo, and congrats on making a great new new style and layout! == Completed Tasks == * Latest ISO Testing The upcoming 2007.11 ISOs have been in testing for some time now. ftp://ftp.archlinux.org/other/rc-iso/2007.11/ No new show-stoppers have been reported, so I believe we should have new ISOs when Tobias returns from his exams. Yay! * New devtools release This is for all the developers and TUs. We've included a few new features, and two new scripts, in the latest devtools release. Please report any problems or feature requests on the bug tracker. * Xorg 7.3 out of testing Xorg 7.3 has been in testing for about a month now. It's time to move it out there. http://archlinux.org/news/363/ Thanks go out, of course, to Alex for making this happen. * Code projects moved to git All our code projects have officially been moved to our git repos, located at http://projects.archlinux.org/git/ Special thanks to Dan, Simo, and Eliott for carving up CVS and SVN repos to create nice little subsets for specific projects. * cvsup is dead. Long live csup. We've officially replaced cvsup (used by ABS) with csup. There are a handful of reasons, but the biggest one is that cvsup does not compile on x86_64. Thanks to Dan for actually making the move and testing it. * slocate has been replaced by mlocate This has been a long time coming. mlocate is a locate/updatedb implementation that uses a different method of updating the locate database, making it much faster on successive runs. This means your machine isn't going to grind to a halt every night at around midnight, heh. Thanks goes out to James for pushing this one through here, good job. == Pending Tasks, Short Term == * QT4 Move Pierre has proposed a migration plan for moving to QT4. http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html This appears to be straightforward, so we should get to this soon! Hooray for progress! * Killing off of /opt According to Jan, the last remaining apps we have in /opt (KDE, OpenOffice, and Mozilla/Firefox) can be safely moved out of /opt and into the /usr tree like everything else. Moving binaries and things out of /opt is going to remove a lot of headache we've had in the past. So for anyone who maintains a package that installs to /opt, see if you can get it to install in /usr instead. * Core rebuild Our core rebuild, due to toolchain changes, is currently waiting for testing to empty. For those developers that have packages sitting in testing, please either try to push them up to the real repo, or remove them from testing if they are old. Andy has started cleanup threads for most of these packages. Please check here to see if you own any of these packages: http://archlinux.org/pipermail/arch-dev-public/2007-November/002855.html http://archlinux.org/pipermail/arch-dev-public/2007-November/002856.html * License Updates Travis has created us a _HUGE_ todolist of packages with broken licenses. Please take a look at it and see if you can close out any packages you currently own. http://archlinux.org/todo/43/ Keep in mind that this list contains ONLY packages in the [extra] repo. This means it will not affect the core repo rebuild, but may be affected by the Package Cleanup. * The dividing line: extra and community Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea. The question: when does a package belong in extra? We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question: a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain. b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community. So, what do you guys think? Should we vote on these two to get things moving? * Package and Orphan Cleanup Eric has done an amazing job of cleaning up a big wave of packages from extra. All things considered, this is fairly important task, as is affects the "Dividing line" question above, as well as lightening our workload. Eric, what is the next step here - how can we help? * DVD and Additional Package ISO Lists Still not even a peep from people. This is the last time I'm going to include this item on the list. If we don't get any sort of activity or discussion on this, I am going to consider the matter closed. The question: do we want to distribute additional DVDs/CDs full of packages? If so, how do we define what packages are on these things? * Unified chroot build tools The new devtools release has pushed two of these tools out there: mkarchroot, for creating ArchLinux based chroots, and makechrootpkg, for running makepkg inside one of these chroots. Currently, there are a few little bugs floating around, but feel free to report more. The next step is to move to official usage here, so for you developers out there, PLEASE contact me if you have any problems - we should all be building packages in clean chroots to make sure hidden dependencies do not sneak into the packages, and I want to make these tools as easy to use as possible. * DB Scripts Code to git With our SCM backend changing, the DB Scripts rewrite task is no longer a big deal. What we _do need_, however, is our existing code moved out of CVS (and into git, in an ideal world). This way we can use these as examples as we create new scripts for working with our new SCM layout. == Pending Tasks, Long Term == * Perl policy I've moved this one to the long-term section http://bugs.archlinux.org/task/8374 Apparently, perl isn't very widely cared about, so this is mostly all up to me, and we all know my freetime is hard to find these days. So, this is on the "hey this is important" list, but there is no rush. * Getting rid of CVS Last time we visted this, we had two potential implementations. The complexity here has to do with representing one package in many repos at the same time. _This_ is the problem that is solved by CVS tags that we need to redefine elsewhere. Jason gave us an example svn implementation that used the following structure: package-name/ PKGBUILD repos/ core/ testing/ blahblah/ Where each directory under repos/ is a new repository that contains a PKGBUILD and all supplemental files that are routinely "synced" with the master files (in the top level directory). Dan gave us a git implementation that uses a similar structure, but uses git's "lightweight branches" in place of the repos/ directory. This also allows us to create rebuild branches and the like very easily. Here is a usage example: git checkout -b foo_rebuild $EDITOR foo/PKGBUILD $EDITOR pkg1/PKGBUILD $EDITOR pkg2/PKGBUILD git commit -a or git checkout -b testing $EDITOR foobar/PKGBUILD git commit -a The branch names above indicate a new repo, which contain only packages that are changed in the new branch. So, I leave the floor open here - what do you guys think? Which is a better solution? I want to open this up to opinion and vote _real_ soon, as this is something we've talked about for so long it's becoming near mythical. * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 Ah, another stagnating task. We've gotten some great patch contributions from the community, and Dan has been rocking with the pacman changes. We'd love to see more testers out there testing the version from git, and possibly confirming some of the "Requires Testing" bugs on the above, so we can close them out. * Official pacbuild usage We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary The news here is small, again. Last I heard, Jason is planning on incorporating the new 'mkarchroot' tool from devtools into pacbuild. Anything else, I am unsure of. Jason, would you mind informing us on what needs to be done to get pacbuild running somewhere? I'd like to do _something_ here before this becomes vaporware. * Modernize our Dashboard Ok, we've made some steps. We now have our web code up here: http://projects.archlinux.org/git/?p=archweb.git;a=summary I plan on filling out the README as far as running your own instance goes. >From there, I'd like people to add any and all dashboard related requests to the "Internal Dev" bug tracker, so we can begin closing them out. * Architecture Independent Repos Roman has provided us patches for makepkg on the pacman-dev list. That's step one. The next step is to modify our DB scripts to check for the proper suffix, and run itself for both the i686 and x86_64 repos. This one is a rather small change, is anyone interested in doing this? Thomas? * ArchCon 2009: Big Baaad Idea http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html ArchCon is still floating here at the bottom of the list...but it looks like no one is interested anymore. That's sad. No one wants to come visit lil ol' me?

6 9

[arch-dev-public] mutt 1.5.17 with smpt support [signoff]
by Tobias Kieslich 09 Nov '07

09 Nov '07

plaese test mutt's smtp support

3 2

[arch-dev-public] eviv2 in testing
by Tobias Kieslich 08 Nov '07

08 Nov '07

I put exiv2 into testing. I didn't run the dependency script. gimp-ufraw is done, but I remember a couple of kde related libs use it as well. It seems exiv2 makes an so bump with every frigging update. *sigh* Thanks, -T

1 0

[arch-dev-public] GPL2 -> GPL3 license changes in packages
by Roman Kyrylych 08 Nov '07

08 Nov '07

2007/11/8, Travis Willard <travis(a)archlinux.org>: > Date: Wednesday, November 7, 2007 @ 20:23:48 > Author: travis > Path: /home/cvs-extra/extra/multimedia/audacious-player > > Modified: PKGBUILD (1.13 -> 1.14) > > upgpkg: audacious-player 1.4.0-1 > Upstream update > > +pkgver=1.4.0 > +pkgrel=1 > pkgdesc="A media player forked from BMP 0.9.7.1 - player component (no plugins)." > arch=('i686' 'x86_64') > url="http://audacious-media-player.org/" > license=('GPL') > -depends=('libmcs' 'libglade' 'unzip' 'libsamplerate') # Unzip for theme changing > +depends=('libmcs' 'dbus-glib' 'libglade' 'unzip' 'libsamplerate') # Unzip for theme changing The license has changed to GPL3. I'm posting this to public list to make a notice that we should now look at GPL2->GPL3 relicensing process that more and more FOSS projects are doing. Also it could be nice to have GPL changed to GPL2 when updating other packages to clearly state the version. -- Roman Kyrylych (Роман Кирилич)

5 11

[arch-dev-public] [signoff] glibc-2.7-5
by Andreas Radke 08 Nov '07

08 Nov '07

fixes memory issues when using gcc-gcj. please sign off both architectures. Andy

3 2

[arch-dev-public] UID/GID db sync
by Roman Kyrylych 08 Nov '07

08 Nov '07

Hi! Just FYI - I've synced both databases on our devwiki and public wiki. Please everyone adding new UID/GID to database - do this as well. Users maintaining packages in AUR should check the db on wiki [1] to make sure there are no conflicts with already existing UIDs/GIDs. It is adviced to post a request first before adding UID/GID. Do not add them without a need. [1] http://wiki.archlinux.org/index.php/UID_and_GID_List P.S.: I'm watching this page so I'll do syncs when needed. -- Roman Kyrylych (Роман Кирилич)

4 5

Re: [arch-dev-public] [tur-users] Mailing list name change/modifications
by eliott 08 Nov '07

08 Nov '07

Any more thoughts on this thread? As a recap for those who haven't been following.. We are discussion the removal of arch-projects mailing list. The addition of an aur-dev mailing list to handle the development of the aur. Renaming tur-users mailing list to aur (or aur-general) for increased clarity and to bring the name inline with the actual project name.

3 2

Re: [arch-dev-public] [tur-users] UID/GID db sync
by Roman Kyrylych 08 Nov '07

08 Nov '07

2007/11/8, Firmicus <Firmicus(a)gmx.net>: > Roman Kyrylych a écrit : > > Hi! > > > > Just FYI - I've synced both databases on our devwiki and public wiki. > > Please everyone adding new UID/GID to database - do this as well. > > > > Users maintaining packages in AUR should check the db on wiki [1] > > to make sure there are no conflicts with already existing UIDs/GIDs. > > It is adviced to post a request first before adding UID/GID. Do not > > add them without a need. > > > > [1] http://wiki.archlinux.org/index.php/UID_and_GID_List > > P.S.: I'm watching this page so I'll do syncs when needed. > > > > > I notice one omission: > > * davfs2 from extra creates user/group davfs2 with UID/GID = 88 (! > conflicts with postgres !) That's bad. davfs2 should change UID/GID. > > Some observations (probably irrelevant): > > * texlive-core creates group tex (no particular GID). > > * vmware-workstation creates group vmware (no particular GID) -- but > this is in unsupported, so you probably won't put it in the db. Yep, I don't know if it's worth to assign a defined GID to it. About changing UID/GID for davfs2, texlive-core & vmware-*: This could break already existing user setups (in some cases even leading to files/dirs with old GID unexistent in new /etc/groups). An example how to handle such situations can be seen in mlocate's .install file, but in case of VMware it would be hard (or impossible?) to search for files/dirs with vmware group. For texlive-core and davfs2 it should be done, I think. > > * On my machine I also have group "testing" with GID 105, but I don't > know where that comes from. Should I remove it? I don't think such GID exists in Core&Extra, probably it's some crap. You can use find to search for files with that GID to be sure. -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] rebuilding the whole core repo
by Andreas Radke 08 Nov '07

08 Nov '07

A new glibc 2.7 is out and it's time to build a new toolchain. After each major glibc and gcc update it's recommended to rebuild every pkg. Only that way you can make sure to get latest (speed) improvements and fixes. This is no problem for all non-rolling release distros. So far we haven't done this before. But now we should try. ArchLinux community strongly depends on good internet connections. So for most parts of the users this will be no problem. My suggestion: 1) We rebuild the core repo. It's small enough to start there. We run a script increasing the pkgrel, run makeworld and upload everything to testing. I'm not sure if makeworld {core,lib,devel,support} will run through. We should test it. We could still hack a simple script doing the makepkg calls one by one in the order we like. After some testing this whole bunch of packages would move to core. Both needs to be done for i686 and x86_64. 2) The extra cleanup should be done meanwhile. 3) Rebuild extra repo and fix or kick broken packages. I could offer some systems to do the rebuilds. I only have slow upload bandwidth. Thoughts? How could help out? -Andy

11 18

[arch-dev-public] GHC 6.8.1 in testing
by Simo Leone 08 Nov '07

08 Nov '07

Hey guys, I moved ghc 6.8.1 into testing a few days ago. It won't stay there long, however, as my haskell gurus seem to agree that it breaks little or nothing. So please test if you can. I'll probably move it out this weekend if nothing terrible comes up. -S

1 0

[arch-dev-public] Forgot signoff for openvpn..
by Tom K 07 Nov '07

07 Nov '07

Morning all. Apologies for this, but I adopted and updated openvpn, and forgot to send it to testing for signoff. I adopted it because I am now using it, and the update is not a new upstream release. Dale asked for the easy-rsa key management scripts, which are distributed in the openvpn source tarball, to be included in our package, so I obliged. There are no changes to the core functionality of the package, and the use of easy-rsa is entirely optional. Apologies again, and my thanks to Eric for picking this up. Regards Tom.

3 4

[arch-dev-public] fcpci needs a C and/or gcc specialist to get it going again
by Tobias Powalowski 07 Nov '07

07 Nov '07

http://bugs.archlinux.org/task/8511 i did the whole research on that issue now i need someone who knows C or gcc to get it working without reverting the patch i mentioned in the bugreport. thanks for your help guys roman wanted to look at it. packages to fix are fcpci and fcpcmcia, they share a lot of code. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 1

[arch-dev-public] Moving mozilla packages to /usr
by Alexander Baldeck 07 Nov '07

07 Nov '07

Hey all, I just begun rebuilding mozilla packages to reside below /usr instead of /opt/mozilla. You can find them here: [mozilla] Server = http://archlinux.org/~alexander/mozilla I'm also in the middle of finding packages that need to be rebuilt against xulrunner etc. Please send me lists of packages we need to rebuild to get a proper howto up. :) Cheers, -X

5 11

[arch-dev-public] [draft] an announcement of Community Packages project on Flyspray
by Roman Kyrylych 06 Nov '07

06 Nov '07

Hi! English is not my native language and we don't want our news items to look unprofessional, so here's a draft. Bugtracker is open for Community packages Due to a high demand we created a separate project on our bugtracker named "Community Packages" [1]. All bug reports and feature requests for Community packages should now be reported there. Please do not report them to "Arch Linux" or "Arch User Repository (AUR)" projects - use the Switch button at the top left corner of Flyspray's page to choose a correct project. Also do not report bugs for packages which are in Unsupported, put a comment on a package's page on AUR instead. [1] http://bugs.archlinux.org/index.php?project=5 P.S.: I'm not a skilled news writer so don't beat me too much. :-P Any suggestions are welcome. -- Roman Kyrylych (Роман Кирилич)

3 3

[arch-dev-public] The Arch-ization of packages
by Roman Kyrylych 06 Nov '07

06 Nov '07

Hi! This is the latest report on the topic I like to discuss: http://bugs.archlinux.org/task/8384\ Other similar reports can be found on flyspray (I gave few links in comments to that report already) and forums. I honestly don't care much of having custom Arch-style splash screens, wallpapers, themes, OS identification in browsers etc. in our packages. I just want it to be *consistent*. There are few possibilities: 1) do not add customize packages to wear Arch name on them (as in Gnome packages now) 2) provide splashs/wallpapers/themes/etc. in packages but do not enable them by default (as in Xfce packages now) 3) provide splashs/wallpapers/themes/etc. in packages and hardcode or enable them by default (as in KDE packages and OOo now). Note that we already force arch-menus installed on every of those DEs. Also should decide if we want to patch Firefox, Seamonkey, Epiphany, Konqueror, Dillo (is it possible to patch Opera's default config files too?). Thoughts? -- Roman Kyrylych (Роман Кирилич)

10 10

[arch-dev-public] X.org 7.3 move to extra [was: cleanup testing {i686, x86_86}]
by Alexander Baldeck 06 Nov '07

06 Nov '07

Hey all, I also would like to move X.org 7.3 from [testing] and put it into our stable repos asap. I don't see any fixable issues at the moment, upstream changes are coming in only very slowly and I would say, we can add them to packages in [extra] just as well. Do you see any really show stoppers still? The latest fglrx works alright afaik. Thoughts? Cheers, -O

6 9

[arch-dev-public] netcfg2 in [testing]
by James Rayner 05 Nov '07

05 Nov '07

Just a heads up that I've put netcfg2 into [testing]... They work for me and others, and have proven to be solid for the last few months without many bugs -- they're well overdue for wider testing. Also... I'd like to move it into svn on projects.archlinux.org as there's no scm currently, who do I speak to about that? I'll post announcements tomorrow morning when I wake if nobody has any complaints. They'll follow as below. Cheers! James ---- netcfg2 is now in [testing]. netcfg2 aims to be a refined network profile system for Arch Linux, replacing the current implementation. Through this, it has also gained various features and improvements which are listed on the development wiki page (http://wiki.archlinux.org/index.php/Network_Scripts) Before it can replace the current profiles, netcfg2 needs testers of various wireless hardware and configuration to try the scripts and report back on the wiki page testing section (http://wiki.archlinux.org/index.php/Network_Scripts#Testing) Bugs can be filed at the bug tracker. Documentation for netcfg2 is located in the netcfg manpage, detailed examples in /etc/network.d/examples, and the wiki: http://wiki.archlinux.org/index.php/Network_Profiles

3 6

[arch-dev-public] /opt vs. /usr
by Varun Acharya 05 Nov '07

05 Nov '07

I remember there was a thread on the ML some time ago about packages still hanging about in /opt and not being moved to /usr. What's the final word on this? I ask because I want to move wicd into extra, and the source package contains binaries and a few scripts, defaulting to /opt. Shall I leave this as is, or move the /opt/wicd to /usr/lib/wicd ? Varun

5 4

[arch-dev-public] In what repo eventlog should be readded?
by Eric Belanger 05 Nov '07

05 Nov '07

Hi, >From Scott's email in the pacman-dev ML, I realized that the eventlog package, a makedepends for syslog-ng, has been moved to unsupported by mistake. So it should be readded to the repo. I wonder if it should be readded in extra or placed in core instead? Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

5 4

[arch-dev-public] sudo in base-devel group?
by Jason Chu 05 Nov '07

05 Nov '07

If I use the mkarchroot and makechrootpkg scripts to build packages, I need to have sudo installed. Using the current mkarchroot options I have to specify "base base-devel sudo". I just need to know if we're planning on putting sudo into base-devel or if I should update the mkarchroot and makechrootpkg scripts to reflect this. Jason

4 6

[arch-dev-public] km script missing with history in installer.git
by Tobias Powalowski 05 Nov '07

05 Nov '07

Hi subject says it all please add the km script too to this repository, thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4

[arch-dev-public] wicd in testing
by Varun Acharya 05 Nov '07

05 Nov '07

Hi all, I've uploaded wicd to testing for both x86_64 and i686. Though its an extra package, I'd like some thorough testing especially on wpa/wpa2 networks. Please signoff. Varun

1 0

[arch-dev-public] [testing] mlocate replacing slocate
by James Rayner 05 Nov '07

05 Nov '07

mlocate has replaced slocate as the default locate implementation, this is currently in [testing]. This was requested on the bug tracker a while back[1]. mlocate is used by Fedora at least and unlike slocate, no longer has the well known midnight updatedb crawl. In all other aspects it's compatible with and identical to slocate. James [1] http://bugs.archlinux.org/task/4490 As described by the README: mlocate is a locate/updatedb implementation. The 'm' stands for "merging": updatedb reuses the existing database to avoid rereading most of the file system, which makes updatedb faster and does not trash the system caches as much. The locate(1) utility is intended to be completely compatible to slocate. It also attempts to be compatible to GNU locate, when it does not conflict with slocate compatibility.

8 10

[arch-dev-public] slocate Replaced by mlocate
by James Rayner 05 Nov '07

05 Nov '07

mlocate has replaced slocate as the default locate implementation after a short period in [testing], and an even longer one in [extra]. This was requested on the bug tracker a while back[1]. mlocate is used by Fedora at least and unlike slocate, no longer has the well known midnight updatedb crawl. In all other aspects it's compatible with and identical to slocate. AndyRTR posted some performance measurements on the mailing list [2]. [1] http://bugs.archlinux.org/task/4490 [2] http://archlinux.org/pipermail/arch-dev-public/2007-November/002870.html As described by the README: mlocate is a locate/updatedb implementation. The 'm' stands for "merging": updatedb reuses the existing database to avoid rereading most of the file system, which makes updatedb faster and does not trash the system caches as much. The locate(1) utility is intended to be completely compatible to slocate. It also attempts to be compatible to GNU locate, when it does not conflict with slocate compatibility.

1 0

[arch-dev-public] Fwd: [tur-users] flyspray category for supp./unsupp. community packages?
by Roman Kyrylych 05 Nov '07

05 Nov '07

In case our flyspray admins don't read tur-users ML frequently. ---------- Forwarded message ---------- From: Roman Kyrylych <roman.kyrylych(a)gmail.com> Date: 1 Лис 2007 20:25 Subject: Re: [tur-users] [arch-dev-public] flyspray category for supp./unsupp. community packages? To: "Discussion about the Arch User Repository (AUR)" <tur-users(a)archlinux.org> 2007/10/25, Roman Kyrylych <roman.kyrylych(a)gmail.com>: > 2007/10/25, Thomas Bächler <thomas(a)archlinux.org>: > > Roman Kyrylych schrieb: > > > See http://archlinux.org/pipermail/arch-dev-public/2007-May/000718.html > > > Could we setup Flyspray so all community packages will reside in > > > "Packages: Community" category? > > > My concern is privilege separation between different categories of the > > > same project. > > > > What about creating a separate project? ArchLinux and Community are in a > > sense separate projects, so we could simply add a new one (with a good > > name, we already have an AUR project). > > > > As long as we can move bugs between projects (can we?), this shouldn't > > be a problem. It may confuse users though. > > > > Yes, the only problem with separate project is user confusion. > We are receiving ~10 reports per week in wrong project now, because > Flyspray remembers active project in a cookie. > > But it seems that we cannot do any privilege separation in one > project, so separate project appears to be the only good variant. > > Could our Flyspray admins give me the "Project Manager" status on > Community packages? ping There are already 2 bugreports in "Community Packages" project (one of which should be assigned to me) but I cannot do anything with them. Just give me the Project Manager status and then I'll setup everything else. -- Roman Kyrylych (Роман Кирилич)

2 2

[arch-dev-public] [PATCH] initscripts: Add a splash support
by Roman Kyrylych 05 Nov '07

05 Nov '07

Hi! This patch finishes the work done by dtw and iphitus for bringing an optional splash support to default initscripts. It eliminates the need for separate initscripts-splash package which provides/conflicts=('initscripts'). User has to install splashy or fbsplash which provide required mikinitcpio hooks and ${SPLASH}_wrapper script, and then use e.g. SPLASH="splashy" in rc.conf to enable it. -- Roman Kyrylych (Роман Кирилич)

14 31

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

05 Nov '07

Hi, As promised, here is a first 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 (cvsup, gnome-system-tools, ksymoops, makedev, nail, rxvt_ja, rxvt) so it would be nice if someone can answer them. As said before, some of these packages are depends of community packages. Please just dicuss them for now. I would prefer to do the actual removal myself. I will do so in a few days after the discussion. ===================================== Package Reason to remove it. ===================================== asteroids3d orphaned games atomix orphaned games cgoban2 orphaned games cl-ppcre unused lib cl-ppmx unused lib cl-sdraw unused lib connmon sources not found/dead project cvsup Can be replaced by csup which builds on both architecture. dmalloc orphaned/low usage easysock dead project (or merged with libggz) eterm only one that still depends on freetype1 eventlog unused lib fnlib unused lib fortunelock orphaned games gdsl unused lib gimp-freetype old, gimp plugin gimp-panorama-tools can't be installed because one of its depends (panorama-tools) was removed as it was obsolete gkx86info depends on gkrellm which has been moved to community glchess orphaned games glitz unused lib gltron orphaned games gnome-system-tools (in unstable) replace with new package from AUR and move to Extra? gramofile dead project gtetrinet orphaned games gtk+extra unused lib gtk-thinice-theme theme for gtk, low usage, this type of pkg can be moved to AUR gtk2+extra unused lib gtodo AUR candidate, low usage hermes unused lib javax-usb orphaned/low usage ksymoops Does it still work? It's a 2 yrs old kernel util. From the version number, it seems that it was for kernel 2.4 libdivxdecore orphaned/depreceated libesmtp unused lib libgdamm unused lib libggz unused lib libghttp unused lib libnss-mysql unused lib libpixman unused lib libproplist unused lib libsafe unused lib libsvg-cairo unused lib libunicode unused lib lighthouseblue-gtk1 theme for gtk, low usage, this type of pkg can be moved to AUR lopster No more development based on this release is planned. makedev Do we need this anymore? What do we gain over mknod? metakit unused lib mgm updated 2004, dead project mm unused lib mowitz unused lib mt-st low usage: it's for Linux SCSI tape driver mtx low usage: it's for tape drives nail has been integrated into the Heirloom project as mailx. We already have another mailx package so we might as well remove nail napshare last version dates from Jan. 2006, doesn't build neverball orphaned game nurbs++ unused lib pclock WM dockapp pdns-ldap unused lib pdns-mysql unused lib pdns-pgsql unused lib peacock orphaned/low usage phpmyadmin orphaned web package pwm low usage: lightweight window manager rcs obsoleted by more modern/popular SCM ringtonetools old, low usage rxtx orphaned/low usage rxvt_ja can be replaced by rxvt-unicode (I guess) rxvt can be replaced by rxvt-unicode (I guess) sdlmm orphaned/low usage shapelib unused lib skyutils unused lib spectemu orphaned/low usage trackballs orphaned game ucl unused lib vcr one of it's depends (avifile) has been moved to community wwl low usage: ham-radio x264-svn (in unstable) orphaned, stable version is in extra ======================================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

14 27

[arch-dev-public] Brief absense.
by Travis Willard 05 Nov '07

05 Nov '07

Hey guys, Just got my wife a brand-new laptop, and I'm 'inheriting' her 'old' desktop PC, which was overall better than mine. As a result, I'll be pseudo-absent for the next little bit, as I go nuts formatting partitions and re-installing Arch from scratch. This will be interesting - last full install, which I'm still working on now, was in 2005. I'll still be checking emails from work if it takes longer than expected to set stuff up, and so I should still be able to reply to pertinent things and handle logo contest submissions and stuff like that, so that's why it's only a pseudo-absense. I'll let you all know how it goes. :) -- Travis

2 3

[arch-dev-public] moving glchess
by Varun Acharya 04 Nov '07

04 Nov '07

glchess is an out of date orphan in extra, and I would like to move it to unsupported. Also, I'm pretty sure glchess is provided by gnome-games. Any objections? Varun

2 1

[arch-dev-public] [signoff] tzdata-2007i-1
by Andreas Radke 04 Nov '07

04 Nov '07

in testing for both archs Andy

3 2

[arch-dev-public] Core Orphans!
by Andreas Radke 04 Nov '07

04 Nov '07

Please make sure we adopt them all very soon! mailx 8.1.1-4 A commandline utility for sending email 2007-09-19 net-tools 1.60-12 Configuration tools for Linux networking 2007-09-19 perl 5.8.8-8 Practical Extraction and Report Language 2007-10-23 shadow 4.0.18.1-6 Shadow password file utilities 2007-09-19 sysvinit 2.86-3 Linux System V Init 2007-09-19 bison 2.3-3 The GNU general-purpose parser generator 2007-09-19 bcm43xx-fwcutter 006-1 firmware extractor for the bcm43xx kernel module 2007-09-16 bridge-utils 1.2-1 Layer2 ethernet bridging for Linux 2007-09-16 dnsutils 9.4.1_P1-2 Various DNS utilities - dig host nslookup nsupdate 2007-09-16 ifenslave 1.1.0-2 Utility for bonding ethernet interfaces 2007-09-16 netkit-telnet 0.17-6 A telnet client (and server) 2007-09-16 pptpclient 1.7.1-2 Client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. 2007-09-16 rp-pppoe 3.8-1 Roaring Penguin's Point-to-Point Protocol over Ethernet client 2007-09-16 -Andy

2 1

[arch-dev-public] [signoff] mplayer / codecs
by Thomas Bächler 04 Nov '07

04 Nov '07

These are [extra] packages, so the signoff is not mandatory for me. But mplayer often breaks, their build system is pain in the ass. I removed the gnome screensaver patch, as it broke for some people. I also removed the /usr/lib/win32 symlink from codecs, because I have no idea why we would need it. Please test and sign off.

3 2

[arch-dev-public] cleanup testing x86_64
by Andreas Radke 03 Nov '07

03 Nov '07

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

1 0

[arch-dev-public] [signoff] sudo moved to core/support
by Dan McGee 03 Nov '07

03 Nov '07

sudo patchlevel bumped and moved to core/support, please signoff for i686. Can someone with an x86_64 machine rebuild it as well? -Dan

4 3

[arch-dev-public] [signoff] util-linux-ng
by Tobias Powalowski 03 Nov '07

03 Nov '07

Hi update to new version, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] netcfg-2
by James Rayner 03 Nov '07

03 Nov '07

Pending some minor changes I'll upload tonight and signoff here, I'll put netcfg2 into [testing] this thursday/friday. I've been operating the scripts pretty heavily on a massive range of networks & configurations (coffee shops, universities, home networks, libraries) for the last 3 months without issue and am confident they are stable enough for the repos. They have fairly strong user support, and the documentation will develop quickly (already more than stock netcfg). After sufficient time in testing, I intend to move them to [core] and have the current netcfg removed from initscripts as it will effectively be superceded. http://bbs.archlinux.org/viewtopic.php?id=36384 http://wiki.archlinux.org/index.php/Network_Scripts James

2 3

[arch-dev-public] Fwd: [signoff] glibc, tzdata, binutils, gcc, gcc-libs
by Dan McGee 03 Nov '07

03 Nov '07

Gah, the original got cut off, too big. ---------- Forwarded message ---------- From: Dan McGee <dpmcgee(a)gmail.com> Date: Oct 31, 2007 8:32 AM Subject: Re: [arch-dev-public] [signoff] glibc,tzdata,binutils,gcc,gcc-libs To: Public mailing list for ArchLinux development <arch-dev-public(a)archlinux.org> On 10/31/07, Andreas Radke <a.radke(a)arcor.de> wrote: > not one issue so far related to the glibc bump. luckily this thread > http://bbs.archlinux.org/viewtopic.php?id=39084 kept unused. > > please sign off glibc, tzdata, binutils, gcc, gcc-libs. > > Andy I've seen no problems on i686 for any of the packages. EXCEPT I just installed glibc -2, and got this on locale-gen in the install script. It did not do this for version 1 (before you patched the locales). Generating locales... de_DE.UTF-8... done en_GB.UTF-8... done en_IE.UTF-8... done en_US.UTF-8... done en_US.ISO-8859-1... done es_ES.UTF-8... done es_MX.UTF-8... done es_US.UTF-8... done fr_FR.UTF-8... done it_IT.UTF-8... done pt_BR.UTF-8... done ru_RU.UTF-8... done /usr/share/i18n/locales/iso14651_t1_common:492: LC_COLLATE: nested conditionals not supported /usr/share/i18n/locales/iso14651_t1_common:499: LC_COLLATE: more then one 'else' /usr/share/i18n/locales/iso14651_t1_common:1135: LC_COLLATE: nested conditionals not supported /usr/share/i18n/locales/iso14651_t1_common:1137: LC_COLLATE: more then one 'else' /usr/share/i18n/locales/iso14651_t1_common:1141: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1143: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1144: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1145: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1146: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1147: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1148: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1149: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1150: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1151: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1152: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1154: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1155: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1156: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1157: symbol `(null)' not defined /usr/share/i18n/locales/iso14651_t1_common:1158: symbol `(null)' not defined (a lot of this until...) /usr/share/i18n/locales/iso14651_t1_common:2606: symbol `(null)' not defined tr_TR.UTF-8... -Dan

3 5

[arch-dev-public] [signoff] ntfsprogs
by Tobias Powalowski 03 Nov '07

03 Nov '07

Hi update to new version, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 10

[arch-dev-public] [signoff] ncurses
by Roman Kyrylych 03 Nov '07

03 Nov '07

Hi! This is my first commit to Core, so don't beat me hard. :-P The new ncurses package fixes circular dependencies problem reported here: http://archlinux.org/pipermail/arch/2007-November/016000.html which was introduced by previous version. Please signoff. -- Roman Kyrylych (Роман Кирилич)

4 6

[arch-dev-public] x86_64 maintainer for smc/cegui
by Andreas Radke 02 Nov '07

02 Nov '07

Who is responsible for the 64bit packages of smc/cegui? Please assign yourself to http://bugs.archlinux.org/task/8469 and remove me. Probably we need to patch cegui or update it to the development branch. I won't spend any time on game packages! Andy

1 0

[arch-dev-public] Moving gammu from [extra] to [community] (fwd)
by Eric Belanger 02 Nov '07

02 Nov '07

Hi, I just got this email from Corrado. Gammu is currently orphaned and is not a dependency of any packages in extra. Does anyone object in moving gammu to the community repo? Eric ---------- Forwarded message ---------- Date: Fri, 2 Nov 2007 10:45:00 +0100 From: bardo <ilbardo(a)gmail.com> To: eric(a)archlinux.org Subject: Moving gammu from [extra] to [community] Hi Eric. I'm the maintainer of wammu and python-gammu in [community]. They both depend on gammu, which is in [extra] and should be maintained by Aurelien. He doesn't even answer to e-mails, though, and since you're the last one that updated the package I'm writing to you. gammu has been out of date for more than three months now, and the three packages are always updated together by their author, so they all need a new version. My proposal was to move gammu in [community] and let me maintain it, since I can take care of it and as a user I need it to be updated. I don't know if you're the right person to ask this, if you don't think so I'll forward this mail to the tur-users ML and hear what other devs and TUs think. Thanks Corrado -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 2

[arch-dev-public] [signoff] openssl and openssh
by Pierre Schmitz 02 Nov '07

02 Nov '07

Hi, I have updated openssl to 0.9.8g. This fixes the api change introduced by 0.9.8f. I have rebuilt openssh, ruby and ntp. Please test if your openssl-apps still work. Pierre -- archlinux.de

5 4

[arch-dev-public] [signoff] csup in testing, now replaces cvsup
by Dan McGee 02 Nov '07

02 Nov '07

Need a signoff for i686 to move to current. PLEASE let me know if you are running core/glibc or testing/glibc, as I built it with testing and want to see if it is safe to push. x86_64 signoffs welcome too, I believe Eric is rebuilding as we speak. I will remove the CVS files from extra once this moves out of testing. -Dan

6 10

[arch-dev-public] Fwd: [arch] circular dependence in core
by Aaron Griffin 02 Nov '07

02 Nov '07

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! Cheers, Jeremy

5 6

[arch-dev-public] [signoff] klibc 1.5-3, klibc-extras 2.3-1, klibc-udev 116-2, klibc-module-init-tools 3.2.2-1, mkinitcpio 0.5.16-1
by Thomas Bächler 31 Oct '07

31 Oct '07

Changes in these versions: klibc: - compile shared binaries by default (somehow this defaults to static in klibc 1.5) - patch klibc to be able to build klibc-module-init-tools - don't build insmod - rebuild against 2.6.23 headers klibc-extras: - update to 2.3, removed modprobe klibc-udev: - rebuild for new klibc, enable shared linking again klibc-module-init-tools: - initial commit to the repository (replaces insmod from klibc and modprobe from klibc-extras) mkinitcpio: - Fix #8448 - Change the base hook to work with klibc-m-i-t For reference, see these git repositories: http://projects.archlinux.org/git/?p=mkinitcpio.git;a=summary http://projects.archlinux.org/git/?p=klibc-extras.git;a=summary The proper way for signoff is: - Build an mkinitcpio image with a different filname than the default, but the same options - Boot - Signoff Tested and booting on x86_64.

3 3

[arch-dev-public] klibc static or shared building
by Dan McGee 31 Oct '07

31 Oct '07

On 10/31/07, Thomas Bächler <thomas(a)archlinux.org> wrote: > Changes in these versions: > > klibc: > - compile shared binaries by default (somehow this defaults to static in > klibc 1.5) > - patch klibc to be able to build klibc-module-init-tools > - don't build insmod > - rebuild against 2.6.23 headers > > klibc-extras: > - update to 2.3, removed modprobe > > klibc-udev: > - rebuild for new klibc, enable shared linking again > > klibc-module-init-tools: > - initial commit to the repository (replaces insmod from klibc and > modprobe from klibc-extras) > > mkinitcpio: > - Fix #8448 > - Change the base hook to work with klibc-m-i-t Just curious- what is the downside of building statically? It seems like it could be a plus in some ways, because you eliminate one more chance of breakage in early userspace. Of course, this also increases the size of your built binaries and increases the size of your initrd. -Dan

3 2

[arch-dev-public] New devtools in testing
by Dan McGee 31 Oct '07

31 Oct '07

I pushed a 0.4 release of devtools to the testing repository tonight. Please install them and let Aaron, Jason, or I know if you find any problems. Highlights: * Two new scripts to assist with chroot creation and builds * extrapkg now takes an -l argument to limit the scp upload bandwidth (Andy, please test) -Dan

4 7

[arch-dev-public] [signoff] usbutils -4
by Tobias Powalowski 31 Oct '07

31 Oct '07

Hi http://bugs.archlinux.org/task/8464 , please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] [signoff] glibc,tzdata,binutils,gcc,gcc-libs
by Andreas Radke 31 Oct '07

31 Oct '07

not one issue so far related to the glibc bump. luckily this thread http://bbs.archlinux.org/viewtopic.php?id=39084 kept unused. please sign off glibc, tzdata, binutils, gcc, gcc-libs. Andy

3 4

[arch-dev-public] request: move sudo to base-devel
by Roman Kyrylych 31 Oct '07

31 Oct '07

Right now sudo is in Extra. I request to move it to Core/base-devel because it is needed by makepkg to be used by user (which is the right way). -- Roman Kyrylych (Роман Кирилич)

6 10

[arch-dev-public] Logo -- Concerns over developer entries.
by James Rayner 31 Oct '07

31 Oct '07

Forwarding on some concerns over entries by developers in the logo competition. I havn't made an official entry, but I have been taking ideas on some designs, with the intention of an official entry after development. http://src.iphitus.org/arch-logo/conceptAB.png http://src.iphitus.org/arch-logo/conceptC.png http://src.iphitus.org/arch-logo/conceptD.png To quote: http://bbs.archlinux.org/viewtopic.php?pid=294343#p294343 " Finally, I have a more logistical concern about your potential submission. Rules have been laid out that devs will be the ones doing the initial vote on the logo, and the community only votes in the case of a tie. You submitting as a developer flags as an overt conflict of interest. Regardless of whether you vote or not on your design, you have no way to assure the community that nepotism won't come into play in the logo decision, if you submit. This will discourage others from submitting as they will all be starting at a SIGNIFICANT disadvantage as a decision maker will be creating a design of their own. If the developers wanted to create their own logo, they should not have ordained a community contest to have a logo created. I'm hoping all developers can appreciate this point of view. " So two points: - Conflict of interest, easily solved - Favouritism. Thoughts? James

8 8

[arch-dev-public] [signoff] gawk
by Tobias Powalowski 30 Oct '07

30 Oct '07

Hi update to new version, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 4

[arch-dev-public] [signoff] syslog-ng -5
by Tobias Powalowski 30 Oct '07

30 Oct '07

Hi http://bugs.archlinux.org/task/8436 , please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] Arch Linux mirror list has typo
by Damir Perisa 30 Oct '07

30 Oct '07

http://www.archlinux.org/download/ ftp.tu-chemnitz.de Germanty ftp.hosteurope.de Germanty ftp.pangora.org Germany is this intentional? :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

3 4

[arch-dev-public] Belnet mirror, ftp now requires login
by Tom K 30 Oct '07

30 Oct '07

FYI everyone: the Belnet mirror is now looking for a username and password, which nobody has (of course). Forum thread here: http://bbs.archlinux.org/viewtopic.php?id=39223 As noted, I have sent them a mail requesting details - I'll update here if/when I hear anything. T.

1 1

[arch-dev-public] 2007.11-0.3 TEST ISO, 1 week signoff
by Tobias Powalowski 30 Oct '07

30 Oct '07

Hi i just placed the new "Core Dump" TEST ISO to the mirrors: ftp://ftp.archlinux.org/other/rc-iso/2007.11/ 1 week testing should be enough, I tested them in kvm-qemu and didn't find an issue. http://bugs.archlinux.org/task/8435 http://bugs.archlinux.org/task/8431 http://bugs.archlinux.org/task/8422 - added some genpatches from gentoo - added fix for 2 ide modules in pair mode - added fix for zd1211rw oops greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

Re: [arch-dev-public] [arch-commits] CVS update of core/base/glibc (11 files)
by Dan McGee 29 Oct '07

29 Oct '07

On 10/29/07, andyrtr(a)archlinux.org <andyrtr(a)archlinux.org> wrote: > Date: Monday, October 29, 2007 @ 17:26:29 > Author: andyrtr > Path: /home/cvs-core/core/base/glibc > > Added: locale.patch (1.1) weekday.patch (1.1) > Modified: PKGBUILD (1.72 -> 1.73) locale.gen (1.4 -> 1.5) > Removed: first_weekday.diff (1.3) fix-C-first_weekday.diff (1.1) > glibc-2.5-branch_update-2.patch (1.1) > glibc-2.6-malloc-fixes.patch (1.1) locales-fr.diff (1.2) > locales_GB.diff (1.1) pl_PL-miesiace.patch (1.1) > > upgpkg: glibc 2.7-2 > update weekday/locale patching to current Debian state; update list of supported locales.gen; clean unneeded patches > > > ---------------------------------+ > PKGBUILD | 26 > first_weekday.diff | 1948 - > fix-C-first_weekday.diff | 27 > glibc-2.5-branch_update-2.patch |48089 -------------------------------------- > glibc-2.6-malloc-fixes.patch | 952 > locale.gen | 809 > locale.patch |21965 +++++++++++++++++ > locales-fr.diff | 282 > locales_GB.diff | 42 > pl_PL-miesiace.patch | 33 > weekday.patch | 1865 + > 11 files changed, 24255 insertions(+), 51783 deletions(-) > > > The diff is longer than the limit of 39KB. Can we please run patches through gzip for anything over like 1000 lines? This really kills the people that use abs. -Dan

2 2

[arch-dev-public] Killing CVS [was: Status Report 2007-10-15]
by Aaron Griffin 29 Oct '07

29 Oct '07

On 10/15/07, Andreas Radke <a.radke(a)arcor.de> wrote: > >From what I read and talk around it seems most European devs are more > comfortable with svn and American devs prefer git. Heh, you forgot Canadian! Either way, I think the distinction is more like so: The coders tend to prefer git, while the non-coders prefer svn. I'm glad you brought this up as it's something that has gone by the wayside for far too long. I have basically been waiting to see how other discussions have gone. So let me make a few salient points here: * The SCM doesn't matter. It doesn't. We're not doing anything complicated that we need advanced features for. The *ONLY* reason we use an SCM at all for PKGBUILDs is to track history. We keep discussing all this stuff as if we need super advanced features for PKGBUILDs and local branches, complex N-way merges, etc etc. We don't. We need to commit, and update. That's it. * There will always be a discomfort when we switch these things. However, if all developers use devtools except in extreme circumstances, there's no reason this discomfort should actually cause any problems. * Pros and cons are useless here. As I said in the first point, we have no need for the advanced features based on our usage patterns. Sure, we can make use of them later, but right now it shouldn't be weighting any decision. * Changing SCMs is fairly easy. If we fuck up, we change to something else - I could do all the grunt work here if people see this as any sort of issue (it's a 5-10 line config file for tailor) ------------------------------ So, here's what I'd like to do. This decision is fairly arbitrary, so let's try and throw out FACTUAL points FOR each SCM. I don't want to see any "X is better than Y because of Z" drivel. I want to see "X supports Z". Everyone has their "baby" SCM. That's not the issue. We need to make a decision, and opinions should have no place here. So. Bring up your points as they apply to our usage patterns. We'll discuss this until this weekend, and come next monday, I'd like to start a vote and see if we can get anywhere. Thanks guys, Aaron

8 31

[arch-dev-public] kernel module guidelines
by Paul Mattal 28 Oct '07

28 Oct '07

Should we add some material to the Arch Packaging Guidelines in the wiki describing the preferred structure of kernel module packages? That is, thing + thing-utils, where thing depends on thing-utils, and allows thing-otherkernel to provide thing and depend on thing-utils? I'm happy to take a crack at adding that language, just wanted to sanity check if there's some reason we don't have that in there. - P

4 4

[arch-dev-public] Kernel 2.6.24-rc1
by Alexander Baldeck 28 Oct '07

28 Oct '07

Hey all, I thought it would be worthwile to mention my experiences with 2.6.24-rc1 on my x86_64 laptop. Compiling ========= It seems that i386 and x86_64 get merged into only one architecture called x86. That brings a few issues with the current PKGBUILD, such as files not being there to copy anymore. When every x86_64 tag gets changed into just x86 though, everything is fine. I was able to cleanly build and use madwifi, nvidia on the other hand failed to even just build. Pretty much to be expected, huh? Anyway, I don't know how much changed for our i686 side. Running ======= One out of 4 boots my machine hung right after detecting its discs. At first I though it had to do with the new "tickless kernel" option but in the end I wasn't able to solve it. I'm using sata-nv on a all nvidia board. Anyway, just a little heads up for all of you in case you wondered what's so special about .24. ;) Cheers, -G

2 1

[arch-dev-public] [signoff] pciutils, usbutils (x86_64 only at this moment)
by Jan de Groot 28 Oct '07

28 Oct '07

During my update for hal, I noticed someone moved pci.ids and usb.ids from pciutils and usbutils to a place where many packages don't expect them. I moved them to /usr/share/hwdata, which is the same location used by Fedora/Redhat. Please signoff.

2 2

[arch-dev-public] missing packages in i686/extra
by Andreas Radke 28 Oct '07

28 Oct '07

==> Generating Text Package List... notice: Missing madplay-0.15.2b-2-i686.pkg.tar.gz in ftp site notice: Missing wine-0.9.47-1-i686.pkg.tar.gz in ftp site notice: Missing notification-daemon-xfce-0.3.6-1-i686.pkg.tar.gz in ftp site Please fix it. Andy

1 0

[arch-dev-public] [signoff] libldap 2.3.39-1
by Andreas Radke 28 Oct '07

28 Oct '07

in testing for both archs. nothing special. removed the no more working but unneeded bd detection. Andy

2 1

[arch-dev-public] libldap forces us to add db4.5 to core
by Andreas Radke 28 Oct '07

28 Oct '07

OpenLDAP cannot work together with recent db4.6. Last well supported db release is the db4.5 tree. db4.1 is to buggy and outdated to work well with recent ldap versions. I'm going to add db4.5 to core/lib. libldap/nfsidmap/nfs-utils depend on it. I will put it into testing to get some signoffs. OpenLDAP related packages from extra will also be rebuilt. This will save us also some rebuilds for the next db so.bump. Any concerns? Andy

1 1

[arch-dev-public] Super Quick Git Guide
by Roman Kyrylych 28 Oct '07

28 Oct '07

Hi! Bacause many of our projects use git now I thought that this quick git tutorial writen by Dan [1] may be useful for those who are new to git but want to contribute. It was my first introduction to git and I found it very useful. So here it is on our wiki: http://wiki.archlinux.org/index.php/Super_Quick_Git_Guide [1] ihttp://archlinux.org/pipermail/pacman-dev/2007-March/007850.html -- Roman Kyrylych (Роман Кирилич)

3 2

[arch-dev-public] [signoff] kernel26 2.6.23.1-6
by Tobias Powalowski 27 Oct '07

27 Oct '07

Hi kernel 2.6.23 for both arches in testing, please signoff this one adresses these bugs: http://bugs.archlinux.org/task/8435 http://bugs.archlinux.org/task/8431 http://bugs.archlinux.org/task/8422 - added some genpatches from gentoo - added fix for 2 ide modules in pair mode - added fix for zd1211rw oops greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] starting the repo cleanup
by Andreas Radke 27 Oct '07

27 Oct '07

I will start removing packages now. It seems nobody else has the time or interest to do it. I will use Eric's list in our dev wiki. step 1: orphaned packages that are no (make)depends for any other pkg. I wonder about Eric's comment "Package | Reason to remove it. No reason implies we keep it" I think it should be the opposite. If any developer wants to keep it he should adopt it before it will be removed. If we won't do it that way we will stay for months for comments what the reasons are why we want to remove them. The reason is the poor (non existing) maintainership and low usage according the public wiki list. Is it ok to rm the whole cvs files including history and the package itself? I see no important reason why we should put the cvs history and pkg somewhere else. If any user or TU wants to pick it up again they would have to do it from scratch again. But we can also hold the cvs entries somewhere for backup for a while. I would need permission on that directory. Your choice. I hope there won't be hidden dependencies behind those packages :-/ step 2: find maintainer for other orphaned packages that are a (make)dependency. I will find out who the maintainer is and ask him directly or on the dev-public ml if he wants to adopt it. Of not it would intend to me we should remove also his still maintained package that depend on it. Hopefully we will find maintainer in most of these cases that way. If not we should decide what to do with those broken unmaintained dependencies. Any comments? I want to start very soon as I have some free time these days. Andy

3 3

[arch-dev-public] Gerolde update / reboot
by Aaron Griffin 26 Oct '07

26 Oct '07

Hey all, Just an informational email. Earlier today (~ 3 hours ago), Dale did an -Syu and reboot on gerolde. It was fairly flawless except for the php.ini merge. Special thanks to Pierre here for taking that up. Also, thanks go out to all you guys who maintain all these packages. I actually expected more breakage due to config file changes and the like, but it "Just Worked". Yay! - Aaron

2 1

[arch-dev-public] busy devs / offer to help on updates
by Andreas Radke 26 Oct '07

26 Oct '07

Some developer seem to be so busy to have no time for updates for several months. Users start to complain about it. I've seen it for eclipse and glade. I can help out when I will find some free minutes. Please tell me if there's a certain reason to not update a package! Andy

4 5

[arch-dev-public] [signoff] ncurses
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi ncurses for both arches in testing, to fit to new initscripts, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

[arch-dev-public] initscripts change: daemon shutdown
by Thomas Bächler 26 Oct '07

26 Oct '07

initscripts have been changed to only shut down daemons which use add_daemon and are thus in /var/run/daemons. Please fix daemon scripts which both need a shutdown AND don't have add_daemon. On my end, I will fix bluetooth. Please check your system for others.

4 5

[arch-dev-public] [signoff] rt2x00-cvs
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi fixed depmod call #8386, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] [signoff] syslog-ng
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi fixed 3 bugs, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] [signoff] kernel26 2.6.23.1-5
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi kernel 2.6.23 for both arches in testing, please signoff added missing sk98lin module for strange nics that are not supported by sky2 and skge network driver greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] [signoff] iputils
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi fixed #8407, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] usbutils
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi update to new version, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] dhcpcd
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi update to new version, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] pciutils
by Tobias Powalowski 26 Oct '07

26 Oct '07

Hi update to new version, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] away for a couple of days (Ukrainian Arch users meeting)
by Roman Kyrylych 26 Oct '07

26 Oct '07

Hi! Today I'm going to the capital to attend to the Sixth OSDN.Org.UA Conference [1] which will be a part of the first "Free/Opensource software for all!" trade show. [2] We expect there will be 3-5 Arch users in total, so we might have beer party for us. :-P [1] http://conference.osdn.org.ua/en/about/ [2] http://www.fossexpo.org.ua/en/home/ I'll be back online in Monday (a trip from my city to the capital is one night long) P.S.: I think it would be nice to know about other local communities events as well. ;-) -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] [signoff] man-pages 2.67
by Andreas Radke 26 Oct '07

26 Oct '07

in testing for both architectures. nothing special. Andy

3 2

[arch-dev-public] Status Report 2007-10-22
by Aaron Griffin 26 Oct '07

26 Oct '07

ArchLinux Status Report, 2007-10-22 And another week goes by. Hectic for me, and I'm sure others too. Sadly, I got very little of what I hoped accomplished. So I'll be sure to revisit those items this time. Just to be clear here, because I don't think I expressed this properly: The tasks listed here are things I'd _like_ to see done. I'm 100% positive there are other things that need doing, but if you let _me_ worry about that, it will lift some weight off of all of us. What I'm saying is this: if you see some sort of larger task that we should all be a part of, let me know, and I will deal with delegation and all that fun stuff so you don't have to. And if you have some free time, check the list I have here. == Newsworthy Items == * New Announcement Mailing List In a bit of irony, this will be the first email to this new list, I believe. Please try and use this list for all official announcements, until I sit down and setup rss2email on gerolde for the front page news. == Completed Tasks == * New initscripts in testing Looks like we closed out 4 or 5 bugs with this initscripts package, so congrats guys. In addition, we've moved the initscripts code out of our package tree: http://projects.archlinux.org/git/?p=initscripts.git;a=summary * git project owners I've setup all our code projects with real owners and groups, so we can more effectively manage this stuff. So now we have real people to point fingers at, yay! You can see the list here: http://projects.archlinux.org/git/ * AUFS support patch added to kernel26 A small patch was added to our kernel to support building AUFS out-of-tree from the kernel. This means that we'll also see aufs packages in extra soon. * New release named Our next ISO release, codenamed "Hardcore", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week. == Pending Tasks, Short Term == * Core rebuild With the release of the new glibc, we want to, at the very least, rebuild all of the core repo to take advantage of the latest changes. Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002441.html Extra will be much harder to do, so we should attack the core repo first. Lets focus on that for now, and complete a rebuild of extra as the next step. * License Updates Travis has provided us a list of packages that have broken or improper licenses. This stuff is becoming more and more important, so I'd like to get some supervision here as soon as possible. This looks like it's a task that pairs well with the core rebuild and extra cleanup. So, anyone participating in those tasks should keep this list in mind. Travis, would it be possible to get this list on the dev wiki? Or possibly setup as a todo list? Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002505.html * New logo competition Travis is spearheading this competition for our new logo. Sometime this week, we should get things started, as we have all the rules down. There is, however, a question of legality raised by Simo. http://archlinux.org/pipermail/arch-dev-public/2007-October/002494.html If anyone has some insight here, it'd be helpful. We need to address this before we move forward with this competition. * The dividing line: extra and community Last time, we had this discussion, and it didn't go all that much farther. The question is this: What defines 'extra'? We seemed to talk a big game, but no decision was really reached. So, let us revisit this thread if possible: http://archlinux.org/pipermail/arch-dev-public/2007-October/002263.html Do we want to go with Damir's suggestion and make "mantle" and "crust", or would we rather stick with the current layout and make extra the "mantle" and community the "crust" ? * Package and Orphan Cleanup And again, I've dropped the ball here. We have a list of packages here: https://www.archlinux.org/wiki/Repo%20Cleanup/ If anyone has some freetime, could you help me figure out what needs to go where, perhaps with another column on that page? Could we annotate the list with what should move to community and what should move to unsupported? In addition, is there any way someone would want to export this list to the public wiki for review by the TUs? * DVD and Additional Package ISO Lists This item has been pending for some time. Discussion was heavy when this was first brought up, but now no one seems concerned about additional ISOs for packages. https://www.archlinux.org/wiki/ISO-Packages/ So, here's the ultimatum: either we at least add a few packages here, or we decide against doing this at all. Should we be distributing additional CDs/DVDs like this? * Unified chroot build tools I have some minor modifications still pending, but this should be ready to go this week. Andy's already done some testing and reported some errors. If you guys could try and go through here and test, that'd be great. Any criticism is appreciated. http://code.phraktured.net/?p=devtools.git;a=summary * Perl policy I've created a bug collector for Perl policy changes: http://bugs.archlinux.org/task/8374 It would be nice if anyone vested in perl on Arch would help out here. Patches for PKGBUILDs are always appretiated. == Pending Tasks, Long Term == * Getting rid of CVS This is a LONG time coming. We've been sitting on CVS for some time, and many of us (including myself) feel that it's time to move on. We've tried to discuss how to do this numerous times, but hit a brick wall that seems to be made of lack-of-work and I-don't-want-to-change. Thankfully, Jason stepped up to the plate and provided us with a working SVN implementation of a new PKGBUILD repo setup: http://archlinux.org/pipermail/arch-dev-public/2007-October/002308.html If anyone else has something to show for this, don't be shy, let us see it. For some reason apathy overtakes this topic whenever it's discussed, and Id love to prevent that from happening again. * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 Ah, another stagnating task. Dan's been pushing some interesting patches into git, but haven't got many of these big bugs closed. Dan, could you let me know when you're free this week? We could sit down and 'sprint' a few of these bugs away. * DB Script Rewrite This item is going to become more and more important if we change repo layouts (see above). I'd like to split this task up into a few actionable portions: a) Get the DB scripts setup in a git repo like everything else b) Find an "owner" who wants to read through the code and address what would need to change if we changed SCMs. c) Try * Official pacbuild usage http://archlinux.org/pipermail/arch-dev-public/2007-October/001944.html We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary I don't think we've had any news on this front. We only have a small contingent of developers actually writing code, so this is a difficult one. I'd love to get someone in place actually working on pacbuild fulltime, as it's a very important tool for us. Do we have any python coders among us that want to show their mettle? * 'Continuous Integration' setup / machine Still an item on here. I think we're going to wait and see how we move our repo SCM in order to do this, as it'd really be just a hook to that SCM. * Modernize our Dashboard I have some documentation on doing this, I want to finalize it and possibly setup a test instance on one of my machines at home for us to play with. Eliott, Simo: I'd still like to get a sanitized git repo up for the web code, so the public can play with it as well. Is either of you available to do this sometime this week? * Architecture Independent Repos This one also seems to have gone by the wayside. What happened to the flare we had for this, or are we all waiting for someone else to do the work? http://bugs.archlinux.org/task/8153 Action Items: a) Update devtools to support arch=(all) by tagging for BOTH CURRENT and CURRENT64 b) Update DB scripts to support arch=(all) by running DB scripts for BOTH architectures. c) Test. Test. Test. * ArchCon 2009: Big Baaad Idea http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html Ah ArchCon. There was a burst of enthusiasm at first, but it died down. I wonder what country would be best? Is the rest of the world still scared to come here to the US? Or should we go to Canada?

10 14

[arch-dev-public] ArchISO Testing
by Simo Leone 25 Oct '07

25 Oct '07

Hey everyone, Those of you that follow projects.archlinux.org have probably already noticed a little project called archiso. Dan and I have been hacking at them quite a bit lately, and I think it's time to share :) Basically it's a set of scripts that can be used to generate Arch liveCD's. They're very, very, (did I say very?) simple. Both by design and to use. They are also very powerful. Pretty much any liveCD system you could imagine can be molded out of them with little effort. They're lightweight, and they're designed to use plain old arch packages to form the system. Anyhow, we've beat the crap out of them as best we know how, and we ran out of ways to break them. Now we're asking you to do the same. If you want to give the scripts a whirl, grab them out of the git repo[1] and take a look. It's pretty straightforward. If you don't really care about the scripts, but are curious about what you can make with them, I've generated a few sample ISOs [2] that may interest you. (actually these isos may appear in a little bit, i'm still generating them) Let me know what you think, and of course, patches welcome ;) -S [1] http://projects.archlinux.org/git/?p=archiso.git;a=summary [2] http://www.archlinux.org/~simo/archiso_tests/

2 2

[arch-dev-public] Fglrx and xorg-server 1.4
by Travis Willard 25 Oct '07

25 Oct '07

Just so everybody knows, The new fglrx package currently in testing, version 8.42.3, has xorg-server 1.4 support. Apparently it's not amazing at a lot of things it does (I'm personally stuck on 8.40 due to graphical corruption bugs) but while it breaks for many, it also does work for many people, and I'll be pushing it to [extra] in due time. In any case, fglrx should likely not hold up xorg-server 1.4 anymore, if it still was in the first place. -- Travis

2 1

[arch-dev-public] flyspray category for supp./unsupp. community packages?
by Andreas Radke 25 Oct '07

25 Oct '07

You all know we don't have a special category for community packages in our bug tracker. But why? I haven't seen any request for it until now. So far we point every request where to file bugs for community packages to the AUR comment fields. I see no good reason why we do that. We should have a dedicated bug tracking system with RSS feeds and maintainer assignment also for the community packages. Then everybody reading the feeds could help out fixing them. I expect a good improvement of the packaging quality. I don't know if it would be useful to also have it for the unsupported AUR packages. Maybe we should just start only with the supported community packages. What do TUs and other Devs think about it? And Roman? Andy

6 5

[arch-dev-public] [draft] - Arch Linux Logo Competition Announcement
by Travis Willard 24 Oct '07

24 Oct '07

Hey everyone, Damn, I dropped the ball here - I wanted to have this draft ready Saturday morning so you'd have all weekend to look it over and correct all my horrid mistakes, but things came up and I got busy. :( In any case, I'll still give a couple of days to review the draft - I'll post it Thursday of this week. Anyway, here's the announcement I wish to put up for the Logo Competition. This will go on the homepage, in the announcements forum section, and to the arch-announce mailing list. One additional thread will be created, stickied and locked, to collect submissions; I will be filtering through my email daily and posting submissions to this thread. I figure this would be the cleanest way to accept submissions without the submission thread possibly getting spammed with non-submissions. Anyway, here's the text: --------------------------------------------------------- Arch Linux Logo Competition Hello everyone! As you may have heard, the Arch logo as we know it is going the way of the dodo! We are refreshing our graphical identity, and in that spirit we're having a logo competition, open to the entire Arch community! We want to know what you think of when you think Arch Linux - what logo do you think would best suit the distribution we've all come to love? Submission guidelines are as follows: . Anyone can submit as many logo concepts as they wish . Entry is freeform, with no need to base it on current logo. Be creative! . All entries will become property of Arch Linux. Once the winning entry has been chosen, we will return rights of all other logos to their original authors, however the winning logo will remain property of Arch. Per submission, you will need: . SVG sources for logo preferred. If you don't know how to make SVG logos, but have a great idea, visit this[1] thread; foxbunny has graciously stepped up to help with logo concepts. . Fill out the following on this submission sheet[2] (courtesy of foxbunny) .. Name (or alias) .. Main logo areas (white/black/neutral BG) .. 2-colour or Black version .. 128x128px and 16x16px icon version .. Colour palette used All other fields are optional - you do not need them to create a submission, and omission of those options will not count negatively against you. Submit completed submission sheet attached in an email to travis AT archlinux.org. They will be posted in this[3] thread; two weeks after the date of this post, we will collect all submissions in that thread and judge. Judging will be the job of the Developers, and will proceed as follows: All submissions will be posted to the [arch-dev] private mailing list, and developers will give their +1 to those logos they like. They may add a +1 to more than one submission - once all developers are accounted for, the logo with the most +1 votes will win. Should multiple logo submissions tie for first place, those entries will be announced to the community, and we will have a community vote on the forums. The logo voted highest in this case will be the winner. Arch will retain all the rights of the winning logo, and will properly credit the winning author in all appropriate ways. We will want to use the logo for additional media - CD labels or wallpapers, for example. The winning author, should they so desire, may create this additional media at this point for Arch's use. Should they decline to create this additional media, the developers will have it created by another willing volunteer. Please note: there are also threads for logo concept discussion[4] and for showing off possible concepts, without entering them into the competition[5]. Feel free to make use of them. Good luck to all participants, and have fun! [1] http://bbs.archlinux.org/viewtopic.php?id=38666 [2] http://www.archlinux.org/~travis/logo-contest/submission-blank.png [2] (URL to go here once the thread is created) [3] http://bbs.archlinux.org/viewtopic.php?id=38051 [4] http://bbs.archlinux.org/viewtopic.php?pid=290216 -------------------------------------------------------- Please look over the announcement for anything you'd like to fix. Thanks! -- Travis

3 8

Re: [arch-dev-public] [tur-users] Mailing list name change/modifications
by Paul Mattal 24 Oct '07

24 Oct '07

eliott wrote: > I think it would be a good idea to make a few mailing list changes, in > particular for the aur community. > > Preconditions (What we have right now): > > tur-users -- end user aur user discussions, tu discussions, etc. > arch-projects -- aur development, and other random stuff. > > Problem: > > The arch-projects list is a bit low use, and seems random. Probably > too much of a catchall to be useful. > > The tur-users mailing list has a name that, to me, doesn't properly > coincide with the mailing list. If a more relevant name is needed than > aur-general, then please suggest it. Lets not get *too* bikesheddy > though. > > Proposal: > > 1. Rename tur-users list to aur-general, for tu chat, and end user > discussions. Same as current tur-users, just with a more relevant > name. > 2. Remove arch-projects mailing list. Too general. Only used for aur > development talk. > 3. Create an aur-dev mailing list, for aur backend coding/development. I like this proposal. How about just aur instead of aur-general? It doesn't really matter, though. - P

1 0

[arch-dev-public] archboot in the git tree
by Aaron Griffin 24 Oct '07

24 Oct '07

Hey all, Quick note. Dan got archboot converted from CVS and I moved it up to git... I think there are one or two mime-type issues, as some of the .sh files are read oddly by firefox, but it's not a huge deal. Right now tpowa is the owner and only one with access. Feel free to request access if you want to work on this. Thanks, Aaron

2 3

Re: [arch-dev-public] status of csup
by Roman Kyrylych 24 Oct '07

24 Oct '07

2007/10/23, Aaron Griffin <aaronmgriffin(a)gmail.com>: > On 10/23/07, Paul Mattal <paul(a)mattal.com> wrote: > > Dan McGee wrote: > > > On 10/23/07, Roman Kyrylych <roman.kyrylych(a)gmail.com> wrote: > > >> Right now sudo is in Extra. > > >> I request to move it to Core/base-devel because it is needed by > > >> makepkg to be used by user (which is the right way). > > > > > > Seems reasonable to me, +1 as long as it doesn't pull in other deps > > > and has maintainer(s). > > > > I will continue to maintain sudo in whatever location y'all deem > > fit. At the moment, it sounds like [core] but maybe not base-devel. > > > > It only depends on pam and glibc. > > I vote it moves to core. Whether in base or base-devel is not a huge > deal to me, though it fits better in base. > Hm, csup is like another candidate for base-devel - required by abs. abs can also work with cvsup but we're going to dump it anyway because it's non-portable. It's only 49,6K, dependencies are gcc, zlib and openssl (all in Core). gcc dependency should be changed to gcc-libs, of course. What do you think? -- Roman Kyrylych (Роман Кирилич)

3 2

[arch-dev-public] 2007.11-0.2 TEST ISO, 1 week signoff
by Tobias Powalowski 24 Oct '07

24 Oct '07

Hi i just placed the new "Core Dump" TEST ISO to the mirrors: ftp://ftp.archlinux.org/other/rc-iso/2007.11/ 1 week testing should be enough, I tested them in kvm-qemu and didn't find an issue. last change readded sk98lin network module, it seems still needed for some nics. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] discussions to death, rules - no innovations?
by Andreas Radke 24 Oct '07

24 Oct '07

In the last few weeks I've seen so many threads about rules and votings we want to give ourself(e.g repo destinctions and repo dividing lines, pkg signoff, iso naming, package movements, license issues, cvs move,...). Wasn't it the big advantage to trust the ArchLinux developers that made it fast growing and bleading edge with an acceptable level of instability? I still like to decide myself what and when to move packages into the repos or when to remove them. Now I have to ask and wait for other devs to signoff packages even for minor bugfixes. And that for two architectures. Didn't we elect Mr. T to become the release manager to let him decide what to do? Now with all the discussions to death and often no actions following - see orphans and cleanup - I loose some of the Arch feeling. All these coming rules seem to slow us down more and more without finding new skilled manpower. I'm sure we all only want the best for ArchLinux but is that the right way? Some rules are always ok. But I have the feeling we are on the way to become somewhat of an overcontrolled and superduper planned Debian. Don't you feel the same? Andy

5 6

[arch-dev-public] SCM branch plans [was: Killing CVS]
by Aaron Griffin 23 Oct '07

23 Oct '07

On 10/23/07, Andreas Radke <a.radke(a)arcor.de> wrote: > Please make sure we will have an easy way to add more "branches" (so i > would call them in svn) from trunk. Right now we have the various repos > for two architectures. But a few devs have (serious?) plans or better > certain ideas to add more branches in the future. Right now our > infrastructure and manpower is the limit that prevents playing with > more stuff. I'm a little curious about what plans you speak of. I've never heard of of these plans like this, and it'd be nice to share thoughts and ideas here.

3 10

[arch-dev-public] 2007.11-0.1 TEST ISO, 1 week signoff
by Tobias Powalowski 23 Oct '07

23 Oct '07

Hi i just placed the new "Core Dump" TEST ISO to the mirrors: ftp://ftp.archlinux.org/other/rc-iso/2007.11/ 1 week testing should be enough, I tested them in kvm-qemu and didn't find an issue. Announcement draft, if you think the ISOs are working and don't have showstoppers: --- Announcement draft begin Hi Arch community, Arch Linux 2007.11-1, "Core Dump" has been released. This is the second release to use our new repo layout. There are two ISOs, ftp and core. Changelog: GENERAL: - kernel 2.6.23.1 usage - RAM usage has been revisited, these are the new recommendations: * FTP ISO, CORE ISO: arch boot image 160 MB RAM x86_64/i686 (all packages selected) * CORE ISO: lowmem boot image 96 MB RAM x86_64 (all packages selected) 85 MB RAM i686 (all packages selected) 64 MB RAM i686 (only base packages selected) FIXES: - fixed intel wireless automatic module loading (arch boot image) - fixed auto prepare of harddisk (lowmem boot image) As usual check md5sum before using the images and also be aware of the new RAM recommendations the images have. Have fun greetings tpowa --- Announcement draft end im away now for 4-6 weeks due to exams. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 10

[arch-dev-public] [signoff] filesystem 2007.11
by Tobias Powalowski 23 Oct '07

23 Oct '07

Hi filesystem 2007.11, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] initscripts 2007.11-2
by Tobias Powalowski 23 Oct '07

23 Oct '07

Hi initscripts 2007.11-2, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

[arch-dev-public] [signoff] perl -8
by Tobias Powalowski 23 Oct '07

23 Oct '07

Hi fixed site-perl error messages during first installation, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 3

[arch-dev-public] Addendum SR 2007-10-22
by Aaron Griffin 23 Oct '07

23 Oct '07

There was a mistake in the previous status report. Our release is NOT "Hardcore" but "Core Dump". My mistake. The entry should read: ------------------------------------------------------------------------ * New release named Our next ISO release, codenamed "Core Dump", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week. ------------------------------------------------------------------------

1 0

[arch-dev-public] [signoff] kernel26 2.6.23.1-4
by Tobias Powalowski 23 Oct '07

23 Oct '07

Hi kernel 2.6.23 for both arches in testing, please signoff fixes vercmp error messages during installation greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] Fwd: Killing CVS [was: Status Report 2007-10-15]
by Dan McGee 23 Oct '07

23 Oct '07

Figured I'd forward this on to the list- it could strike up a discussion. I've looked at git-submodules, but it is quite new, and not all that lightweight as each submodule has its own .git directory. -Dan ---------- Forwarded message ---------- From: Loui <louipc.ist(a)gmail.com> Date: Oct 22, 2007 9:06 PM Subject: Re: [arch-dev-public] Killing CVS [was: Status Report 2007-10-15] To: dpmcgee(a)gmail.com Do you think git submodules could be useful or relevant considering the 'Killing CVS' topic? In terms of checking out individual packages. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules "Large projects are often composed of smaller, self-contained modules. For example, an embedded Linux distribution's source tree would include every piece of software in the distribution with some local modifications; a movie player might need to build against a specific, known-working version of a decompression library; several independent programs might all share the same build scripts."

2 1

[arch-dev-public] fetchmail update
by Aaron Griffin 23 Oct '07

23 Oct '07

On 10/21/07, Kevin Piche <kevin(a)archlinux.org> wrote: > Date: Sunday, October 21, 2007 @ 22:51:15 > Author: kevin > Path: /home/cvs-arch/arch/build/network/fetchmail > > Added: fetchmail-6.8.3-secfix.patch (1.1) > Modified: PKGBUILD (1.37 -> 1.38) > > upgpkg: fetchmail 6.3.8-4 > FS#8126: vulnerability CVE-2007-4565 On 10/21/07, Aaron Griffin <aaron(a)archlinux.org> wrote: > Date: Sunday, October 21, 2007 @ 23:56:28 > Author: aaron > Path: /home/cvs-extra/extra/network/fetchmail > > Modified: PKGBUILD (1.37 -> 1.38) > > upgpkg: fetchmail 6.3.8-4 > Apply SA 2007-02 bugfix Hah, we did the same thing here about an hour apart, except I used the remote patch.

2 1

[arch-dev-public] Fwd: License for new logo
by James Rayner 22 Oct '07

22 Oct '07

Havn't read arch-dev-public for more than a month, so sorry if forwarding this causes any trouble. IMHO: There's gotta be some way we can license it but allow derivative works pertaining to Arch? Anyway, foxbunny suggested I forward his message below and it seems relevant. ---------------------------- Original Message ---------------------------- Subject: cc'ing the forum post From: "foxbunny" <snip> Date: Mon, October 22, 2007 22:53 To: <snip> -------------------------------------------------------------------------- foxbunny from Arch Linux Forums has sent you a message. You can reply to foxbunny by replying to this e-mail. The message reads as follows: ----------------------------------------------------------------------- Just in case you miss it or something, could you please post this on dev-public? "Okay, so I had a quick look at the Competition announcement draft. I think the part about Arch Linux owning the logo, it can't be done without making an Arch Linux foundation or sumsuch legal entity. OTOH, we can properly license the logo to all developers, or at least one of them who will be in charge of the logo (Phracture). It will not be free art as in freedom, but it will still be licensed to the dev for him to do whatever he pleases with it. IOW, no public license, so that no one can use the artwork but the dev. Just a proper private exclusive license targeted at a specific individual. The license should include the exclusive right to relicense the artwork to any 3rd party under conditions similar to the original license, or maybe a more open license. During the voting period, there could be a limited license with a definite deadline. License is, AFAIK, a simple contract between the author and the licensee so I don't think there should be any legal trouble as long as the licensee is an individual (or a group of individuals). As for completely giving up possession of the artwork by the original author, I don't think that is necessary. EDIT: Maybe devs could come up with such a license that we are obliged to agree on before we can submit the artwork? Like 'By submitting the artwork, you agree to the following terms... yada yada'" Best regards, -- Branko

1 0

[arch-dev-public] pending 2007.11 iso tasks
by Tobias Powalowski 22 Oct '07

22 Oct '07

Hi signoff for perl,ncurses, kernel-2.6.23.1-4 needed filesystem and initscripts (small update) and signoff needed thomas an roman wanted to catch the last initscript things. after this i'll recreate my test isos. --- Announcement begin Hi Arch community, Arch Linux 2007.11-1, "Core Dump" has been released. This is the second release to use our new repo layout. There are two ISOs, ftp and core. Changelog: GENERAL: - kernel 2.6.23.1 usage - RAM usage has been revisited, these are the new recommendations: * FTP ISO, CORE ISO: arch boot image 160 MB RAM x86_64/i686 (all packages selected) * CORE ISO: lowmem boot image 96 MB RAM x86_64 (all packages selected) 85 MB RAM i686 (all packages selected) 64 MB RAM i686 (only base packages selected) FIXES: - fixed intel wireless automatic module loading As usual check md5sum before using the images and also be aware of the new RAM recommendations the images have. Have fun greetings tpowa --- Announcement end after this task im away for 4-6 weeks due to exams. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 4

[arch-dev-public] License updates (was: rebuilding the whole core repo)
by Dan McGee 22 Oct '07

22 Oct '07

On 10/22/07, Travis Willard <travisw(a)wmpub.ca> wrote: > On Mon, 22 Oct 2007 15:00:59 +0200, Damir Perisa wrote > > Sunday 21 October 2007, Travis Willard wrote: > > | If we're feeling REALLY ambitious, this would be a great time to > > | fix all the licenses in our packages - we still have over 1000 bad > > | licenses in extra - attached file shows packages that need work. > > > > good idea... regarding your list i have some items: > > > > * we should have the MIT licence in our common licences folder > > > > * we should add all possible CC licences in our common licences > > folder ... maybe informing creative commons that we support their > > full scheme of licencing in our licence handling (public relations, > > networking *g*) > > Regarding the above two, I'm all for adding common licenses (MIT, CC) to the > licenses package, provided we can - I remember some licenses that are pretty > common actually differ in their text from package to package (ie. the devs of > the software need to add their own info for copyrights or something) - we can't > really provide a common license for those. For BSD, MIT, etc. the difference is that the license text changes based on the package, unlike the GPL which has the same text always. I know for BSD we are supposed to (according to the wiki page) list the license as 'BSD' but still include the text of the license. I would think the same applies for MIT and anything else where the text differs. I've kind of taken ownership of the licenses package, so feel free to shoot me suggestions as to what should be included and I'll gladly update it. > > * LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the > > 2.1 version > > How significant are the differences between 2.0 and 2.1? Isn't our GPL2 license > 2.1 as well? I would say yes, they are in fact equivalent. > > * some pkgs have licence-formatting issues (Apache instead of APACHE > > or gpl instead of GPL ... we change the formating? licences are > > all-caps always?) It seems the precident is for common licenses, list them as all caps- of course, this makes sense for things that are abbreviations such as the GPL but not so much for APACHE. I'd be up for change, but we *really* need to document this. Our wiki article should have hard and fast guidelines for things like this. > The script I used to generate that list checked, for each license in licenses, > is it "custom"? If not, then does a folder structure exist at > /usr/share/licenses/common/${license}? If no, then it's invalid. Since the > folders in /usr/share/licenses/common are capitalized, I think the entries in > the license array should be as well. Looking at it this way, caps seems stupid for licenses unless it is intended to be that way (e.g. GPL, BSD). There are a few other sticky issues, such as whether BSD/MIT should be listed as 'BSD' or 'custom:BSD' (I know I've read somewhere that we should use the former, which I agree with- it is a standard license, but the text differs between packages). -Dan

4 4

[arch-dev-public] Kerberos support for OpenSSH
by Aaron Griffin 22 Oct '07

22 Oct '07

Hey guys, I'm not all that versed in this stuff, so I want to open the floor here: http://bugs.archlinux.org/task/8373 Please give me your insight. Thanks, Aaron

1 0

Re: [arch-dev-public] [arch-commits] CVS update of extra/system/archboot (3 files)
by Jan de Groot 22 Oct '07

22 Oct '07

> -----Oorspronkelijk bericht----- > Van: arch-commits-bounces(a)archlinux.org [mailto:arch-commits- > bounces(a)archlinux.org] Namens Tobias Powalowski > Verzonden: maandag 22 oktober 2007 13:25 > Aan: arch-commits(a)archlinux.org > Onderwerp: [arch-commits] CVS update of extra/system/archboot (3 files) > > Date: Monday, October 22, 2007 @ 07:24:43 > Author: tpowa > Path: /home/cvs-extra/extra/system/archboot > > Added: archboot-2007.11-1.tar.bz2 (1.1) > Modified: PKGBUILD (1.54 -> 1.55) > Removed: archboot-0.4.27.tar.bz2 (1.1) > > 'upgpkg: update to new Core Dump release' > > >... > > Index: extra/system/archboot/archboot-0.4.27.tar.bz2 > <<Binary file>> > Index: extra/system/archboot/archboot-2007.11-1.tar.bz2 > <<Binary file>> > Why do we still store these big binaries in CVS? There's no sane version tracking for binary files and these things make checkouts very big (users who run abs get all this shit downloaded). I've enabled write access to /other/ for the ftp-arch group yesterday, please use that directory for such things. IMHO this directory should also replace the ~tpowa/, ~alexander/ and ~jgc/ things we're using at this moment to store unofficial source tarballs for packages (xulrunner comes to my mind).

3 2

[arch-dev-public] [signoff] filesystem/initscripts 2007.11-1
by Thomas Bächler 22 Oct '07

22 Oct '07

For initscripts, we need a new ncurses package: tput needs to be moved from /usr/bin to /bin, and thus libncursesw.so.5 needs to be moved from /usr/lib to /lib. This has to be done before we move this to core, but I don't have time now, so anyone feel free to do it.

3 4

[arch-dev-public] [signoff] madwifi / madwifi-utils
by Tobias Powalowski 22 Oct '07

22 Oct '07

Hi madwifi / madwifi-utils for both arches in testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4

[arch-dev-public] [signoff] ndiswrapper / ndiswrapper-utils
by Tobias Powalowski 22 Oct '07

22 Oct '07

Hi ndiswrapper /ndiswrapper-utils for both arches in testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] Git Projects
by Aaron Griffin 22 Oct '07

22 Oct '07

Just a few things here. I'm setting up owners and all that fun stuff for our code projects, but I have a few important things. a) Let's not do personal repos up here - gitweb is a single cgi file, it should run fine in your ~/public_html if you want personal stuff. This means I removed the 2 symlinks in there and moved the AUR repo up to /srv/projects. Please update your checkouts appropriately. b) I've assigned owners to everything as I saw appropriate. Please let me know if I botched any of this, or if you don't want ownership of the project. c) Each project will have a set of committers. I'm not trying to say that everyone here isn't qualified to commit to these projects, but I just want to ensure we have SOME quality control. Please talk to me if you want to be part of the groups with commit rights to a give project. Thanks Aaron

3 3

[arch-dev-public] [signoff] kbd
by Tobias Powalowski 22 Oct '07

22 Oct '07

Hi i put new kbd for both arches to testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] [signoff] fuse 2.7.1
by Thomas Bächler 21 Oct '07

21 Oct '07

fuse is in testing. I moved the libfuse to /lib, due to a warning from ntfs-3g, which puts its binaries in /{sbin,bin,lib} as well so it is available before /usr is mounted. Particularly, this ensures that you can use a fuse-based filesystem for /usr.

2 1

[arch-dev-public] pending initscripts tasks
by Tobias Powalowski 21 Oct '07

21 Oct '07

Hi those 2 bugs would be great if thomas(brain0) would test till sunday: http://bugs.archlinux.org/task/7714 http://bugs.archlinux.org/task/7267 the utf bug would be cool if roman(romashka) could take care of till sunday: http://bugs.archlinux.org/task/7641 this feature request at least a comment from aaron or anyone else on this: http://bugs.archlinux.org/task/7369 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 7

[arch-dev-public] initscripts in testing
by Tobias Powalowski 21 Oct '07

21 Oct '07

Hi i put new initscripts for both arches to testing. they should fix those bugs: http://bugs.archlinux.org/task/5740 http://bugs.archlinux.org/task/6237 http://bugs.archlinux.org/task/7165 http://bugs.archlinux.org/task/7554 http://bugs.archlinux.org/task/7641 there are some feature requests which i didn't implemented yet comments from your side please: http://bugs.archlinux.org/task/7369 http://bugs.archlinux.org/task/7714 http://bugs.archlinux.org/task/7267 probably not implement / closing requests: http://bugs.archlinux.org/task/5324 finally next step bump to next release name: we need a new release name :) suggestions please, i think the last name suggestion was "Hardcore". greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

7 19

[arch-dev-public] initscripts versioning
by Thomas Bächler 21 Oct '07

21 Oct '07

In the past, we used the release name (in this case 2007.11) for the initscripts versioning and bumped the pkgrel on bugfixes/changes. Now that we use a tarball on the ftp, what do we do? - Include the pkgrel in the tarball name (initscripts-2007.11-1.tar.bz2) - Add a postfix to the version number like with the isos (initscripts-2007.11.1.tar.bz2)

4 6

[arch-dev-public] GIT projects on gerolde: owners and groups
by Thomas Bächler 21 Oct '07

21 Oct '07

Aaron mentioned he would take care of this, but I wanted to bring this up so it isn't forgotten: For the git projects, we need: - A separate group for each project, instead of "projects" - An owner assigned to each project (not root) I am volunteering as the owner for the initscripts, klibc-extras and mkinitcpio projects.

2 1

[arch-dev-public] move of 2.6.23.1 in 8 hours
by Tobias Powalowski 21 Oct '07

21 Oct '07

Hi i'll move in 2.6.23.1 in 8 hours to core with all modules, if you have issues shout out now ;) greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] [signoff] madwifi-{utils}-0.9.3.3
by Alexander Baldeck 21 Oct '07

21 Oct '07

Like the subject says. Tested on x86_64 with .23.1 on my end.

2 1

[arch-dev-public] Announce list?
by Aaron Griffin 20 Oct '07

20 Oct '07

Hey guys, I was approached by someone who was interested in keeping an eye on important things, but had to unsubscribe from this list due to high volume - too much that doesn't matter to a standard user. He brought up the idea of making a separate announce list for users to subscribe to for important happenings. None of us would NEED to be subscribed, as we could just send mails to BOTH lists when something is important. The specific items in question are the status report, and other things. What do you guys think? Aaron

6 12

[arch-dev-public] 2007.10 or 2007.11 release version?
by Tobias Powalowski 20 Oct '07

20 Oct '07

Hi, the question: Will the next release number be 2007.10 or 2007.11? i'm for 2007.11, test isos will be available next week until you find them stable it's probably the 1st november. An other interesting thing, i tested the ram usage in kvm-qemu today, results: core/ftp arch boot image: 160MB RAM (x86_64 WORKS setup: all packages selected) -> the i686 needs less RAM so it would work core lowmem boot image: 85MB RAM x86_64 (setup: all packages selected) -> the i686 needs less RAM so it would work core lowmem boot image: 64MB RAM (quickinst: cd install i686 WORKS, only base category installed!) (setup: cd install i686 WORKS, only base category installed!) Failures: (quickinst: cd install x86_64 FAILED, only base category installed!) (setup: cd install x86_64 FAILED, only base category installed!) x86_64 needs more memory thats normal and x86_64 have at least 256mb ram installed, else it would make me wonder. i'll correct this in documentation for next release. still pretty much but it's the pacman bug: http://bugs.archlinux.org/task/8155 ~ 50MB RAM takes pacman during full package installation which causes a OOM_KILL updating to libarchive 2.3.4 doesn't help either. new initscripts and filesystem will go to testing on sunday or monday morning. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

Re: [arch-dev-public] [arch-commits] CVS update of core/base/openssl (PKGBUILD)
by Jan de Groot 20 Oct '07

20 Oct '07

Be aware that OpenSSL 0.9.8g breaks ABI with 0.9.8f because it reverts the ABI incompatibility that was introduced with 0.9.8f. This means that anything that has been recompiled for 0.9.8f is broken again with 0.9.8g, the things that haven't been recompiled but that are broken at this moment do not need fixing. On Sat, 2007-10-20 at 16:02 -0400, Pierre Schmitz wrote: > Date: Saturday, October 20, 2007 @ 16:02:19 > Author: pierre > Path: /home/cvs-core/core/base/openssl > > Modified: PKGBUILD (1.38 -> 1.39) > > just commit to cvs; we can update this when rebuilding core etc. > > > ----------+ > PKGBUILD | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > > Index: core/base/openssl/PKGBUILD > diff -u core/base/openssl/PKGBUILD:1.38 core/base/openssl/PKGBUILD:1.39 > --- core/base/openssl/PKGBUILD:1.38 Fri Oct 12 04:09:16 2007 > +++ core/base/openssl/PKGBUILD Sat Oct 20 16:02:19 2007 > @@ -1,7 +1,7 @@ > -# $Id: PKGBUILD,v 1.38 2007/10/12 08:09:16 pierre Exp $ > +# $Id: PKGBUILD,v 1.39 2007/10/20 20:02:19 pierre Exp $ > # Maintainer: Pierre Schmitz <pierre(a)archlinux.de> > pkgname=openssl > -pkgver=0.9.8f > +pkgver=0.9.8g > pkgrel=1 > pkgdesc='The Open Source toolkit for Secure Sockets Layer and Transport Layer Security' > arch=('i686' 'x86_64') > @@ -12,7 +12,7 @@ > options=('!makeflags') > source=("http://www.openssl.org/source/${pkgname}-${pkgver}.tar.gz" \ > 'http://www.linuxfromscratch.org/patches/blfs/svn/openssl-0.9.8e-fix_manpage…') > -md5sums=('114bf908eb1b293d11d3e6b18a09269f' '04a6a88c2ee4badd4f8649792b73eaf3') > +md5sums=('acf70a16359bf3658bdfb74bda1c4419' '04a6a88c2ee4badd4f8649792b73eaf3') > > build() { > cd $startdir/src/$pkgname-$pkgver > @@ -24,4 +24,4 @@ > make INSTALL_PREFIX=$startdir/pkg MANDIR=/usr/man install > > install -D -m644 LICENSE $startdir/pkg/usr/share/licenses/$pkgname/LICENSE > -} > \ No newline at end of file > +} > > _______________________________________________ > arch-commits mailing list > arch-commits(a)archlinux.org > http://archlinux.org/mailman/listinfo/arch-commits >

2 1

[arch-dev-public] [signoff] kernel26 2.6.23.1-3
by Tobias Powalowski 20 Oct '07

20 Oct '07

Hi kernel 2.6.23 for both arches in testing, please signoff latest changes from paul and alsa bumped to latest stable version. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 4

[arch-dev-public] [signoff] ipw3945
by Tobias Powalowski 20 Oct '07

20 Oct '07

Hi ipw3945 for both arches in testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] [signoff] rt2x00-cvs
by Tobias Powalowski 19 Oct '07

19 Oct '07

Hi rt2x00-cvs for both arches in testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] [signoff] rt2500
by Tobias Powalowski 19 Oct '07

19 Oct '07

Hi kernel 2.6.23 for both arches in testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] AUFS Patches in Kernel
by Paul Mattal 19 Oct '07

19 Oct '07

All, I would like to request the addition of the attached patch to the kernel PKGBUILD, to allow maintenance of an aufs package. Aufs is a rewrite of unionfs, with different strengths and weaknesses. The particular strength that makes it compelling is that it handles NFS filesystems as branches of a merged filesystem both correctly and with stability. This allows you to efficiently create diskless workstations where each client sees his own writeable root filesystem based off of a single filesystem image. The impact is two small patches which need to be added to the kernel, each of which exposes a small number of kernel function calls which are needed by aufs. I would appreciate if others would consider this and sign off. Having these patches in the kernel would make us fully aufs-friendly. I have attached the PKGBUILD patch against the current testing 2.6.13.1 kernel, as well as the two patches for your easy perusal. Best, Paul

6 11

[arch-dev-public] NEW RELEASE NAME SUMMARY/VOTING:
by Tobias Powalowski 19 Oct '07

19 Oct '07

NEW RELEASE NAME: - Hardcore (Roman - All you can Wuerstchen (Alex - Pizza (Thomas - Slice (Damir - Proton - Magma - Core Dump (Aaron, Tpowa I think that are enough, Voting till sunday evening european time should be fine. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

8 8

[arch-dev-public] [signoff] iwlwifi
by Tobias Powalowski 19 Oct '07

19 Oct '07

Hi iwlwifi for both arches in testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] sudo in testing
by Paul Mattal 19 Oct '07

19 Oct '07

I have adopted sudo, and placed the newest version in testing. This version returns to the upstream default of not insulting you when you get your password wrong, except if you actually enable this in /etc/sudoers. Given that Arch is a multi-purpose distro that is used in many settings (e.g. my office), this seems more appropriate. Those wishing the verbal abuse can still set the insults option in /etc/sudoers. Because this is a significant package, I would appreciate it if at least one dev would sign off before I move it to [extra]. Thanks! - P

4 3

[arch-dev-public] Repo Distinctions
by Paul Mattal 19 Oct '07

19 Oct '07

So I've been listening to the discussion about what should and shouldn't be in extra so far, and I've come to the following conclusions: 1) Niche is subjective. 2) Even if it weren't, whether a package is "niche" or "mainstream" is not a good criterion for classifying it in one repo or another. 3) Some good criteria for classifying packages in one repo or another are: a) Desire to maintain a package long-term. b) Association with a particular group of people you trust. 4) There are many who actually do trust developers more than TUs. This is not intended as a judgement, rather as an observation. My feeling is that we should have under the developer umbrella a split of the existing [extra] into two repos: [main] - to be in the main repo, a package must be voted in by a majority of the developers; we commit to maintaining these packages over a long period of time, and announce 6-12 months in advance if we're going to remove them (and again, this removal requires a majority vote); there should never be any orphans in here, and we should be extremely stingy about putting packages in here in the first place [extra] - developers can maintain any packages in here they wish; if they decide to orphan them, they must announce that to the developers and TUs and see if anyone wants to take them on; if nobody wants them, they get demoted and orphaned in unsupported so that the community can still benefit from the work they once did This is just a proposal intended as a starting point for discussion. But I think some notion of a supported group of [main] packages that we collectively commit to maintaining will make us feel less bad about a more in-flux [extra]. Also, a clear process about what you do when you orphan a package helps get those packages picked up by those with time or inclination to deal with them. For those who would say: why not just use [community] as the [extra] you're proposing above? The answer: so you can tell which group of individuals is standing behind these packages-- the developers. With that information, you can then decide for yourself who to trust. - P

8 32

[arch-dev-public] [signoff] kernel26 2.6.23.1
by Tobias Powalowski 19 Oct '07

19 Oct '07

Hi kernel 2.6.23 for both arches in testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

11 10

[arch-dev-public] new release name?
by Tobias Powalowski 18 Oct '07

18 Oct '07

Ok seems this was overseeen in my previous mail: NEW RELEASE NAME: - Hardcore - All you can wuerstchen throw in new suggestions or vote +1 fot the name you like. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

10 10

[arch-dev-public] Unbotched PKGBUILD patch
by Paul Mattal 18 Oct '07

18 Oct '07

The first PKGBUILD patch was slightly botched (in the process of minimizing the diff). New version attached. - P

1 0

[arch-dev-public] [signoff] or remove wlan-ng26 from core?
by Tobias Powalowski 18 Oct '07

18 Oct '07

Hi wlan-ng26 for both arches in testing, please signoff noone uses it anymore on dev crew nor a users was found. decide what to do with it, it compiled at least. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 8

[arch-dev-public] Status of QT4
by Pierre Schmitz 18 Oct '07

18 Oct '07

Hi, I just wanted to ask what the status of QT4 is. There are some packages which cannot be updated due to dependency on the new version of QT. It wouldn't be that bad idea to update qt before KDE4 is ready. I wonder if the following upgrade path works: * introduce a qt3 package (just rename the current qt; files should stay in /opt/qt) * repackage those packages which directly depend on qt3. (there are not that many) * update the qt package to version 4 and install all files to /usr * packages like kdebase should still work because they do not directly depend on qt (from pacmans point of view) and search fore qt files in /opt/qt. What do you think? Is it really that simple? Pierre -- archlinux.de

5 5

[arch-dev-public] [signoff] udev 116-2
by Tobias Powalowski 18 Oct '07

18 Oct '07

Hi i put new udev-116-2 for both arches to testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] wireless_tools
by Tobias Powalowski 18 Oct '07

18 Oct '07

Hi i put new wireless_tools for both arches to testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] kernel 2.6.23 move to core on weekend?
by Tobias Powalowski 18 Oct '07

18 Oct '07

Hi there are no real showstoppers on bugtracker, i add now the packages for signoff, for wlan-ng we have no dev that can test and no user for reporting the functionality. should it be removed form core to extra? the extra modules noone responded to the last thread is this a problem? (especially the fglrx driver) greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] [signoff] sdparm
by Tobias Powalowski 18 Oct '07

18 Oct '07

Hi i put new sdparm for both arches to testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] [signoff] pam
by Tobias Powalowski 18 Oct '07

18 Oct '07

Hi i put new pam for both arches to testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] Arch Linux Logo Contest - RULES
by Travis Willard 17 Oct '07

17 Oct '07

Hey again! Okay, the consensus seems to be that having a logo competition is a good idea, so we're having a competition! The forum thread I linked in the other ML thread[1] has been teeming with activity, and many proposals have already been submitted before we've even done anything[2]! I have a feeling this will turn out quite nicely. I'm starting a new thread to keep things organized. This thread is now for discussion of the rules of the logo contest. I propose simple rules: . Anyone can submit as many concepts as they wish . Entry is freeform, no need to base it on current logo . All submitted entries must be under a freely-modifiable license, or be willing to transfer rights of the logo to Arch. Per submission, we want: . SVG or PNG logo at 128x128 . Palette used (16 colours max) . Simplified 2-colour version (b&w, for instance) . Scaled version(s) (16x16 required, anything between 128x128 and 16x16 also cool) Foxbunny, from the forums, made a proposed submission sheet[3] and gave an example submission[4] - do we want to make use of these? As they currently are, or with some modification? Please comment on these rules - I'd like to pounce on the energy in the forums while it's still there. :) [1] http://bbs.archlinux.org/viewtopic.php?id=38051 [2] http://bbs.archlinux.org/viewtopic.php?pid=290216 [3] http://img292.imageshack.us/my.php?image=submissionformjl2.png [4] http://img148.imageshack.us/my.php?image=submissionsampleul1.png -- Travis

2 5

[arch-dev-public] TU autonomy
by Paul Mattal 17 Oct '07

17 Oct '07

One other thing to remember in this whole repo debate is that, while the TUs derive some authority from the dev structure (primarily by means of our hosting the AUR), they are intended as a generally autonomous group. Deciding for them what should and shouldn't go in community will have repercussions. We should remember well our history lessons about how difficult it is to set up a stable and productive TU ecosystem before we rock that boat. We should not consider it obviously in our jurisdiction to use [community] as part of our own official repository plan. - P

3 3

[arch-dev-public] Missing MD5 sums (was: [arch-commits] CVS update of extra/science/gnuplot (PKGBUILD))
by Dan McGee 17 Oct '07

17 Oct '07

Roman- some people might not see "real" email on that list, so its usually best to forward it here. ---------- Forwarded message ---------- From: Roman Kyrylych <roman.kyrylych(a)gmail.com> Date: Oct 17, 2007 7:10 AM Subject: Re: [arch-commits] CVS update of extra/science/gnuplot (PKGBUILD) To: ArchLinux packaging commits <arch-commits(a)archlinux.org> 2007/10/17, Damir Perisa <damir(a)archlinux.org>: > Date: Wednesday, October 17, 2007 @ 07:32:20 > Author: damir > Path: /home/cvs-extra/extra/science/gnuplot > > Modified: PKGBUILD (1.12 -> 1.13) > > upgpkg: gnuplot 4.2.2-1 > ... > -md5sums=('f688a578ddb4c376fd7d91ce444a0745') Huh? Why didn't you put updated md5sums here? -- Roman Kyrylych (Роман Кирилич) _______________________________________________ arch-commits mailing list arch-commits(a)archlinux.org http://archlinux.org/mailman/listinfo/arch-commits

2 1

[arch-dev-public] Where [erxtra] ends and [community] begins
by Pierre Schmitz 17 Oct '07

17 Oct '07

Hi, after the creation of the [core] repository and the cleanup of old [current] it should be clear which packages should be in [core] and which don't. But the border between [extra] and [community] does not seem to be that sharp. Does [extra] only include the most important and essential packages? Is [community] only a playground and a repo full of alpha releases? Defining [extra] in a clear way should make it easier to cleanup this repo, too. We still have a lot of unmaintained or outdated packages. Pierre -- archlinux.de

8 12

Re: [arch-dev-public] Freshen Arch's Graphical Identity (Logo)
by Paul Mattal 17 Oct '07

17 Oct '07

Jason Chu wrote: > On Sun, Oct 14, 2007 at 07:43:40PM -0700, eliott wrote: >> I am all for a competition, but I don't know about community vote. >> >> How about community submissions, and voted on by the Arch devs, and TUs? >> >> I don't want to be represented by a piece of talking poop or anything.. >> though..i might vote for that. >> >> I mean...hey... talking poop. >> >> Did this post of mine even make sense? >> *head scratching* > > I'd like to hear what the community thought, but not necessarily go with > what they choose. If we switch the logo, I think we should consider having a trademark search run on our final design(s) and getting our trademark registered. As we grow, I think we'd like to have some protection against people telling us we can't use our logo. - P

2 1

[arch-dev-public] Freshen Arch's Graphical Identity (Logo)
by Travis Willard 16 Oct '07

16 Oct '07

Hey all! A few threads have started up in the last little while on the forums with "new" logo concepts for Arch - having read them, the most recent[1] made me start thinking that maybe we should put some thought into updating the logo and making it look a bit more professional. I personally would like to see a bit of an update there, something a bit snappier than our current logo[2] which, to me, is looking a bit dated and unprofessional. Suggestions have been made to allow the community to participate, in both the creation of logos for the purpose of being the "new official front-page Arch logo" and also for voting which of the submissions should be used. I like the idea of a community-designed logo, and the activity in the thread linked below would indicate that the community is also pretty enthused at the thought, but we could always just do a Dev-vote to decide which of the submissions we'd prefer if we didn't want to make it a community vote. In any case, I think this is worth investing time in, and I'm prepared to spearhead any initiative on this front. What I'm looking for now is your opinions - do you agree or disagree that maybe it's time to give the logo a sprucing-up? Any comments from the dev team? What's your opinion, Aaron, o benevolant overlord who is currently away on a great trip of sorts but will shortly return? Looking forward to your responses. :) [1] http://bbs.archlinux.org/viewtopic.php?id=38051 [2] http://bbs.archlinux.org/img/header.png -- Travis

10 25

[arch-dev-public] Perl policy [was: Status Report 2007-10-15]
by Aaron Griffin 16 Oct '07

16 Oct '07

On 10/15/07, Jeff 'codemac' Mickey <jeff(a)archlinux.org> wrote: > * On Monday, October 15 2007, Aaron Griffin wrote: > > >* Perl policy > > > >This week I am going to coordinate with François (Firmicus) and anyone > >else interested in our perl packages and clean up what we have. > > You should _really_ talk to xterminus/charles about this. He's quite the > perl man as well, and I think you know that. Though I haven't seen him > around in a while, I can send you his IM info so you can ping him. Let me know if you can get a hold of him. According to Francois, he has been unable to get ahold of Charles in a few months.

1 0

[arch-dev-public] [signoff] udev/klibc-udev
by Tobias Powalowski 16 Oct '07

16 Oct '07

Hi i put new udev/klibc-udev for both arches to testing, please signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] Status Report 2007-10-08
by Aaron Griffin 16 Oct '07

16 Oct '07

Time for another one! Sorry if this one is later than the rest - I've been a tad busy today. ---------- ArchLinux Status Report, 2007-10-01 == Newsworthy Items == * Testing Policy In order to provide a working system to all users, we are going to ensure that all packages in [core] always go through testing first. The core repo is critical enough to where if anything breaks, it is a big deal. Far different than if we broke gnumeric. Core packages should go to testing, and at least one other developer should "sign off" when they've tested it. For simplicity, if you want to skip the [testing] step for non "base" group packages, and provide a direct link to a package for others to sign off, that is fine - as long as 2 developers are accountable for the working state of that package. This shortcut should not be taken for packages in the base group. == Completed Tasks == * Move all Arch related projects to gerolde Looks like we're only missing one project, which we should be able to get to today, so I'm going to say this is "done". Thanks a lot guys. http://bugs.archlinux.org/task/7789 * AUR 1.4.0 Release Special thanks to everyone involved (eliott, tardo, louipc, xilon, thralas, and more). * Bugfix ISO Release With the release of the 2007.08-2 ISOs, we have a functional installer again. Our previous ISOs broke when we moved to the [core] repo. Special thanks to tpowa for all his hard work, and to all the testers who made it possible. * Devtools updates This was an item from last time that Dan and I completed. We have not yet released a new devtools tarball, as I'd like to wait for the chroot build tools to be complete. Ref: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html == Pending Tasks, Short Term == * db and heimdal out of [testing] The rebuilds have been in testing for some time, and I haven't seen any issues. If there are no show stoppers, we should be able to move these out this week. Could someone confirm this is the case? * Package and Orphan Cleanup Our list has grown, so thanks for all who've adjusted things here. https://www.archlinux.org/wiki/Repo%20Cleanup/ I'm not a fan of these "all orphans in XYZ" items though. Umbrella clauses such as this usually don't work too well - I'd prefer full definitions. Could someone fill those items in appropriately? * DVD and Additional Package ISO Lists We still have yet to fully define the packages we'd like to distribute on additional ISOs. Here I have created a stub https://www.archlinux.org/wiki/ISO-Packages/ Please use this to _explicitly_ list things you want or don't want on these additional ISOs. * Unified chroot build tools I have two automated tools slated for commit to devtools soon. I have a few fixes still to push up there (such as auto-generating a locale, using sudo, etc), but in general, they are in a working state. http://code.phraktured.net/?p=devtools.git;a=summary * Perl policy This item was previously listed as "Use vendor_perl for pacman perl packages", but I'm expanding it. This policy here: http://wiki.archlinux.org/index.php/Perl_Policy Was written by some perl pros, cross referenced with the Debian perl policy, and I think I agree with most of it. So I want to officially implement this. If you care about perl, lets discuss this. I, however, am going to begin with the following bug reports: http://bugs.archlinux.org/task/8082 http://bugs.archlinux.org/task/8236 http://bugs.archlinux.org/task/7530 http://bugs.archlinux.org/task/7587 == Pending Tasks, Long Term == * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 We're creeping slowly in this direction. Special thanks to Chantry Xavier for actually submitting patches, heh. * DB Script Rewrite This one went by the wayside. It appears we're sitting in one of those "not broke" modes. I'd still love to actually do this, but I'm moving it to the "long term" items, as it's not all that critical, ans there are better things to do. * Official pacbuild usage Jason sent out a status thread last week with where http://archlinux.org/pipermail/arch-dev-public/2007-October/001944.html * 'Continuous Integration' setup / machine The state hasn't changed much since last time. This is still more of a pipe-dream. Dan pointed out the fact that git actually ships with CI tools ("cidaemon" and "post-recieve-cidaemon") that we could take advantage of. * Modernize our Dashboard Eliott and Simo have been helping me out here. I'm going to give us all a nice document on setting up a local instance for the arch web interface, so we can develop on our own. In addition, we need to move the git repo to projects.al.org but we currently have passwords in there that need to be sanitized. * Architecture Independent Repos Added to flyspray: http://bugs.archlinux.org/task/8153 It appears that we can implement noarch packages with very little changes. This combines, in a way with the Pacman 3.1 release, and db script rewrites above. * ArchCon 2009: Big Baaad Idea Any ideas for a venue? I wonder, if we had a little donation drive to help the developers all get together, would that be cheating? http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html == Bugs and Issues == I didn't notice anything critical this time around - could someone fill in the blanks here, I didn't have time to scrape major issues together. ---------- Thanks everyone, for your continued hard work. In the upcoming weeks, I have a few grand plans I want to implement, but I'm waiting for a bit of a lull in these important items here. Stay tuned! -- Aaron

6 11

[arch-dev-public] Status Report 2007-10-15
by Aaron Griffin 16 Oct '07

16 Oct '07

ArchLinux Status Report, 2007-10-15 Yeah, OK. This one is a little lacking. I was gone most of the week (Wed - Sun) so much of this is hearsay. Sorry for the long delay in getting this out, I had a lot of information to parse. Let me know if I report anything falsely, or I forgot a major milestone. == Newsworthy Items == * Losing some kernels It looks like, due to external issues, and maintainer workloads, we're going to be losing two of our additional kernels - ck and suspend2. This leaves us with one official kernel in the repos. Ref: http://archlinux.org/news/354/ http://archlinux.org/news/355/ == Completed Tasks == * Successful testing policy implementation Looks like all the core updates have been using the sign-off policy, which is great. For filtering purposes, try to use the [signoff] tag. Thanks to everyone doing this. It also helps the rest of use know what's going on in [core]. * texinfo moved to core/devel While this is minor in the grand scheme of things, it's worth a mention here. * unionfs patch updated Our unionfs patch in our stock kernel was a bit outdated and has been updated to the newer branch, which should fix any issues that may have cropped up. * The "Big Move" from testing This weekend db, heimdal, gtk, gnome, gcc and probably others were moved from testing to core/extra. Special thanks to Andy, Jan, and everyone else involved in making this happen. == Pending Tasks, Short Term == * New logo The concept of creating a new logo for Arch has been brought up often enough. I'd like to see this happen. New repo, new leader, new... well, lots of stuff. It's only fitting that we modify the logo slightly. This ML thread has a few references: http://archlinux.org/pipermail/arch-dev-public/2007-October/002158.html The plan, it seems, is to open things up for submissions, then have the developers and TUs vote on the best logo. Before this week is up, I'd like to decide on a submission range and how we want to handle voting. * The dividing line: extra and community Now that we cleaned up the blurry line between current and extra with the core repo, we come across another case of this. Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002188.html The line between extra and community is not all that clear, so we need to flesh it out. Is it defined by developer time? Is it defined by necessity? Popularity? How should we best clarify this? * Package and Orphan Cleanup Eric did some amazing work here fleshing out our lists in the dev wiki for this. https://www.archlinux.org/wiki/Repo%20Cleanup/ I would like to set aside some time this week to actually clean these up, but we don't need anything fully organized - if anyone has the time, perhaps we could do this Thursday night (my time, heh)? * DVD and Additional Package ISO Lists I generated a stub page last report, but had no time to fill in data. https://www.archlinux.org/wiki/ISO-Packages/ Please use this to _explicitly_ list things you want or don't want on these additional ISOs. When I get the time, I will fill in based on my thoughts. * Unified chroot build tools These are still sitting in my personal branch. I was on vacation last week, so nothing got done. http://code.phraktured.net/?p=devtools.git;a=summary * Perl policy I'd like to move to official implementation of this policy listed here: http://wiki.archlinux.org/index.php/Perl_Policy This week I am going to coordinate with François (Firmicus) and anyone else interested in our perl packages and clean up what we have. See the following bug reports: http://bugs.archlinux.org/task/8082 http://bugs.archlinux.org/task/8236 http://bugs.archlinux.org/task/7530 http://bugs.archlinux.org/task/7587 == Pending Tasks, Long Term == * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 Again, I was away most of last week, so little got completed. I want to meet up with Dan again this week so we can crack out some of these bugs. * DB Script Rewrite This one went by the wayside. It appears we're sitting in one of those "not broke" modes. I'd still love to actually do this, but I'm moving it to the "long term" items, as it's not all that critical, and there are better things to do. * Official pacbuild usage Still looking at this report from Jason. http://archlinux.org/pipermail/arch-dev-public/2007-October/001944.html We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary This is pretty important. I'd like to move us away from this separation by architecture that we have right now - it shouldn't matter which architecture a given developer runs when it comes to building packages. * 'Continuous Integration' setup / machine The state hasn't changed much since last time, however, Dan pointed out that git actually includes hooks for a CI setup, which is a decent point in git's favor. * Modernize our Dashboard I should be able to pump out some documentation on how to setup a local instance of our site soon. I'd like to coordinate with Eliott and Simo about getting a public (sanitized) git repo up on the projects site so we can begin developing more readily. * Architecture Independent Repos Added to flyspray: http://bugs.archlinux.org/task/8153 It appears that we can implement noarch packages with very little changes. This combines, in a way with the Pacman 3.1 release, and db script rewrites above. * ArchCon 2009: Big Baaad Idea Last time I brought up the idea of a donation drive with regards to sending the developers to a given venue. No one responded to it, so I'm not sure if it was good or bad. I wonder... were I not in the position I'm in, would I donate? What about you guys? http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html

3 2

[arch-dev-public] [signoff] gcc{,-libs}
by Andreas Radke 15 Oct '07

15 Oct '07

available for both archs in testing * please sign off before the big move! Andy

3 2

[arch-dev-public] Absence - sort of
by Thomas Bächler 15 Oct '07

15 Oct '07

Real life has hit me hard this week: My girlfriend got a job not too far away and we found a bigger flat pretty quickly. There is MUCH work ahead of us until we can move and we both have to work starting next week. That means there will be no time at all for arch for at least two weeks, at most four weeks. I will try to follow the mailing lists as good as I can, but won't be active. Have fun guys, I will report back when things change. Thomas

3 2

[arch-dev-public] please don't run db scripts/move is in progress
by Andreas Radke 15 Oct '07

15 Oct '07

^^^ Andy

4 4

[arch-dev-public] Away Oct 10 - 14
by Aaron Griffin 15 Oct '07

15 Oct '07

Hey all, I'm going to be camping and doing wilderness-y things during the time period above. This means no computer. I'm not even bringing it with me. Hopefully, nothing goes haywire while I'm gone. I'm attempting to get a few things complete before I go. If anyone would like some special tasks during this period, let me know - we have quite a lot of code that needs to be written, if you're bored. I'll give you an update before I leave. Thanks guys, Aaron

1 2

[arch-dev-public] Moving texinfo to core/devel?
by Daniel Isenmann 14 Oct '07

14 Oct '07

Hi, I find out, that grep needs makeinfo (which is in extra/texinfo-package) as makedepends. It's a makedepends from binutils, too. So, it is necessary anyway in core/devel, what do you think? Daniel

3 4

[arch-dev-public] kernel 2.6.23 status update
by Tobias Powalowski 14 Oct '07

14 Oct '07

Hi open bugs: http://bugs.archlinux.org/task/8289 http://bugs.archlinux.org/task/8292 first one is quite bad i hope thomas can try to figure out why it crashes. second one a typical alsa hda issue, which is difficult to track down. all modules are now compiled against the latest .23 kernel, functionality needs to be tested. here is the list [core]: ipw3945 madwifi rt2x00-cvs iwlwifi ndiswrapper rt2500 wlan-ng26 here is the list [extra]: fcpci intel-536ep intel-537 martian (confirmed to work on german irc) nvidia-96xx (works for me) fcpcmcia kqemu nvidia (works for me and dan) slmodem fglrx intel-537 lirc nvidia-71xx truecrypt (confirmed to work on german irc channel) most interesting is fglrx driver. thanks for your help greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] [signoff] less
by Andreas Radke 14 Oct '07

14 Oct '07

available for both archs in testing * please sign off before the big move! Andy

2 2

[arch-dev-public] [signoff] which
by Andreas Radke 13 Oct '07

13 Oct '07

available for both archs in testing * please sign off before the big move! Andy

2 1

[arch-dev-public] [signoff] tar
by Andreas Radke 13 Oct '07

13 Oct '07

available for both archs in testing * please sign off before the big move! Andy

2 1

[arch-dev-public] [big move] db/heimdal/gtk/gnome/gcc
by Andreas Radke 13 Oct '07

13 Oct '07

What bugs or rebuilds are pending? Any move stoppers left? I only know the gtk2 package, Jan wants to fix the X crashes. If he won't be around I'll try myself later tonight. The plan: - Many packages depend on x11-libs. Jan told me it's safe to move the x11-libs expect libgl to extra. everything else from Xorg will stay in testing. - All other packages will move right after gtk2 got fixed. Andy

1 0

[arch-dev-public] [signoff] openssl
by Pierre Schmitz 13 Oct '07

13 Oct '07

Hi, I have updated openssl from 0.9.8e to 0.9.8f and put it into [testing]. Because this is a [core]-package please test and tell me. Pierre -- archlinux.de

3 4

Re: [arch-dev-public] [arch-commits] CVS update of extra/science/plotutils (PKGBUILD)
by Dan McGee 13 Oct '07

13 Oct '07

On 10/12/07, Damir Perisa <damir(a)archlinux.org> wrote: > Date: Friday, October 12, 2007 @ 21:29:35 > Author: damir > Path: /home/cvs-extra/extra/science/plotutils > > Added: PKGBUILD (1.1) > > upgpkg: plotutils 2.5-1 > > > ----------+ > PKGBUILD | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > > Index: extra/science/plotutils/PKGBUILD > diff -u /dev/null extra/science/plotutils/PKGBUILD:1.1 > --- /dev/null Fri Oct 12 21:29:35 2007 > +++ extra/science/plotutils/PKGBUILD Fri Oct 12 21:29:35 2007 > @@ -0,0 +1,33 @@ > +# $Id: PKGBUILD,v 1.1 2007/10/13 01:29:35 damir Exp $ > +# Maintainer: damir <damir(a)archlinux.org> > +# Packager: Maksim Sipos (maxsipos at gmail dot com) > + > +pkgname=plotutils > +pkgver=2.5 > +pkgrel=1 > +arch=('x86_64' 'i686') > +pkgdesc="Set of utilities and libraries for plotting." > +url="http://directory.fsf.org/graphics/plotutils.html" > +license=("GPL") > +depends=("libpng" "gcc-libs" "libxaw") > +makedepends=("flex") > +# _patches="" > +source=("http://ftp.gnu.org/pub/gnu/plotutils/$pkgname-$pkgver.tar.gz" \ > + ${_patches}) > +options=('!libtool') > + > +build() { > + cd $startdir/src/$pkgname-$pkgver > +# for patch in ${_patches} > +# do > +# patch -Np1 -i $startdir/src/$patch > +# done > + ./configure --prefix=/usr \ > + --with-gnu-ld \ > + --with-x \ > + --enable-libplotter \ > + --enable-libxmi > + make || return 1 > + make DESTDIR=$startdir/pkg install > +} > +md5sums=('0d6855cce17832afe2ff75c26a57be49') > > _______________________________________________ > arch-commits mailing list > arch-commits(a)archlinux.org > http://archlinux.org/mailman/listinfo/arch-commits > OK, I don't want to start a flame war here, just a healthy discussion. Obviously Damir uses all these science packages and is willing to maintain them, so that is why they end up in the extra repository. But I'd like to pose a question to the developers- do these pacakges truely belong in extra? Considering we already have enough issues with orphaned packages and such, I feel like we should be a bit more strict when adding packages to our developer repositories. Even if we have a maintainer now for a package, as soon as a dev decides to depart our ranks we could be left with well over 100 packages no one wants to maintain. I feel like this is the reason there are still several packages in extra that have been orphaned and un-updated for over 2 years. The above was mostly opinion-free, so my last paragraph will be my opinion. I feel like packages like this belong in community or unsupported, not extra. We no longer look at community of less of a repo than extra- the only difference is who can place packages there. The community has always filled a great role as having some of the more niche packages, and most science stuff belongs in this category. And guess what the best part is? Even if you are a dev, you can build and upload packages to community. To Damir- this isn't directed at you as much as our general policy, which I believe we should work on setting so that all developers know what is acceptable and not acceptable. I'm sure other developers have added packages mostly for their personal use as well. -Dan

3 3

[arch-dev-public] kernel 2.6.23 status
by Tobias Powalowski 12 Oct '07

12 Oct '07

Hi 2.6.23 packages built + modules issues: fglrx is not working and lirc needs probably to change to cvs again to compile. The rest was compilable, when should i checkin to testing? breaking ati cards in testing is it worth the trouble or delay it? thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

9 13

[arch-dev-public] [signoff] libelf 0.8.10
by Andreas Radke 12 Oct '07

12 Oct '07

in testing for both architectures.

2 2

[arch-dev-public] [to sign off] grep, man-pages
by Andreas Radke 10 Oct '07

10 Oct '07

I've built grep and man-pages for x86_64 and ise has both for i686. They are now in testing. Please sign them off and move then to core. -Andy

4 3

[arch-dev-public] Plans for renaming kernel26suspend2 to kernel26tuxonice
by Daniel Isenmann 10 Oct '07

10 Oct '07

Hi, I plan to rename the kernel26suspend2 package to kernel26tuxonice and the corresponding modules are getting the suffix tuxonice instead of suspend2. Since the suspend2 developers change their name to tuxonice, this is the logical decision to avoid confusion. The next reason for changing the package name is the fact, that the tuxonice developers changed all refernces in their code to tuxonice. I think it's logical to name the package like the original one. I know, that there are other packages which would be affected by these changes. But I'm going to find those packages and rebuild/fix them or inform the maintainer of it. But no panic, I don't do it now...This is just an information to start discussion about this step. tuxonice doesn't released a stable version which build fine with kernel 2.6.23, so there is some time to think about it. But my plan is, that the next version of kernel26suspend2 becomes kernel26tuxonice. Daniel

1 0

[arch-dev-public] where to put unstable/testing packages?
by Andreas Radke 09 Oct '07

09 Oct '07

I've built my first pkg for unstable repo. It is built against testing packages. So do I put it into testing first and move it later to unstable or directly to unstable? Andy

5 5

[arch-dev-public] Replacing slocate?
by Aaron Griffin 09 Oct '07

09 Oct '07

Hey guys, I wanted to get some opinions on this bug here. http://bugs.archlinux.org/task/4490 I'm entirely neutral on it, but if one is technically superior, we should probably switch to it. So I'm going to put this out there so someone with more of an opinion can chime in. (Please comment on the bug tracker itself)

1 0

[arch-dev-public] kernel26 unionfs patch
by Simo Leone 09 Oct '07

09 Oct '07

The unionfs patch being used on our kernel was old and unstable (like... they're already on a new stable branch... old), so I went ahead and updated the PKGBUILD in CVS, after making sure the kernel built with the new patch. Anywho, just shootin ya'll a message so I don't step on anyone's toes. -S

1 0

[arch-dev-public] kmplayer 0.10.0 in [testing]
by Damir Perisa 08 Oct '07

08 Oct '07

kmplayer depends on gtk2 for its npplayer - because my i86_64 machine is on testing, i built it against testing and put it there. (i686 follows tomorrow) please anybody in charge of gtk2 update move kmplayer to [extra] together with gtk2 rebuild-group. by the way: who ever moved xorg out of testing seemed to have forgoten to remove the pkgs from it after putting them to extra: http://archlinux.org/packages/search/?q=libx11 : 13579 Extra x11-libs libx11 1.1.3-1 X11 client-side library 2007-09-16 13230 Testing x11-libs libx11 1.1.3-4 X11 client-side library 2007-09-05 thanx + greetings, Damir ---------- Message transmis ---------- Betreff: [arch-commits] CVS update of extra/multimedia/kmplayer (PKGBUILD) Datum: Monday 08 October 2007 Von: Damir Perisa <damir(a)archlinux.org> An: arch-commits(a)archlinux.org Date: Sunday, October 7, 2007 @ 21:17:32 Author: damir Path: /home/cvs-extra/extra/multimedia/kmplayer Modified: PKGBUILD (1.28 -> 1.29) upgpkg: kmplayer 0.10.0-1 ----------+ PKGBUILD | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) Index: extra/multimedia/kmplayer/PKGBUILD diff -u extra/multimedia/kmplayer/PKGBUILD:1.28 extra/multimedia/kmplayer/PKGBUILD:1.29 --- extra/multimedia/kmplayer/PKGBUILD:1.28 Sat Apr 7 08:22:33 2007 +++ extra/multimedia/kmplayer/PKGBUILD Sun Oct 7 21:17:32 2007 @@ -1,20 +1,27 @@ -# $Id: PKGBUILD,v 1.28 2007/04/07 12:22:33 damir Exp $ +# $Id: PKGBUILD,v 1.29 2007/10/08 01:17:32 damir Exp $ # Maintainer: damir <damir(a)archlinux.org> # Contributor: Damir Perisa <damir.perisa(a)bluewin.ch> + pkgname=kmplayer -pkgver=0.9.4.a -origver=0.9.4a +pkgver=0.10.0 +origver=0.10.0 force=y pkgrel=1 pkgdesc="Video player plugin for Konqueror and basic MPlayer/Xine/ffmpeg/ffserver/VDR frontend for KDE" arch=("i686" "x86_64") +license=('GPL2') url="http://kmplayer.kde.org" -depends=('libx11' 'libxv' 'cairo' 'kdelibs>=3.5.6' 'gstreamer0.10-base' 'xine-lib') +depends=('libx11' 'libxv' 'cairo' 'kdelibs>=3.5.7' 'gstreamer0.10-base' 'xine-lib' 'dbus-glib' 'dbus-qt3' 'gtk2') +# gtk2 and dbus-glib is needed only by opt/kde/bin/knpplayer so it probably may be also made optional if needed source=($url/pkgs/$pkgname-$origver.tar.bz2) build() { export MAKEFLAGS="-j1" cd $startdir/src/$pkgname-$origver + + # fix include path of some headers (0.10.0): + sed -i "s|\"prtypes.h\"|<nspr/prtypes.h>|g" src/moz-sdk/jni_md.h src/moz-sdk/jri_md.h src/moz-sdk/npapi.h || return 1 + ./configure --prefix=/opt/kde make || return 1 make prefix=$startdir/pkg/opt/kde install @@ -22,3 +29,4 @@ rm -f ${startdir}/pkg/opt/kde/share/mimelnk/application/x-mplayer2.desktop } +md5sums=('8e8d3df2cdebc4c08fd6f8ab6bf1bda4') _______________________________________________ arch-commits mailing list arch-commits(a)archlinux.org http://archlinux.org/mailman/listinfo/arch-commits ------------------------------------------------------- -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

5 10

[arch-dev-public] New ISO release thread, please all read!
by Tobias Powalowski 08 Oct '07

08 Oct '07

Ok, according to the last thread about releasing on saturday i summarize: - most agree with releasing a new iso that just works - New codename? A new iso will be released in november which contains a new major kernel, which we all agreed earlier this year should trigger a new codename and release/filename. At the moment it would mean much work to regenerate the ISOs with only to include a new code name. With entering kernel .23 series we should bump initscripts to a new code name, suggestions are welcome :) one mentioned was Hardcore - Release/File name of ISOs? ok here started the confusion, these ISOs will still contain the same major kernel series as in 2007.08 ISOs. There was also a thread about name scheme and we wanted to use -0.x as developer ISOs and [1-9] as release/bugfix versions. According to this it would be logical to use here 2007.08-2 as release/filename we could still use the iso/2007.08 directory on ftp and remove the others directories, see section below. - Remove of old ISOs and addons? All old ISOs ftp routines are broken. Also every ISO had some kind of itches which now are all fixed, it would make sense to remove all old ISOs and addons from ftp/iso. Addons are not necessary anymore with latest ISOs because most fast enough drivers are now included on the media itself. comments, thoughts and simple agrees/denies are welcome thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

11 23

[arch-dev-public] adopted more packages
by Varun Acharya 08 Oct '07

08 Oct '07

I just adopted foobillard,bluez-gnome,xcdroast,nicotine. one question, which I asked on IRC too, is libdivxdecore actually used by anyone for anything? does it still need to be in extra? The package hasn't been updated in three years (I assume thats how long ago projectmayo.com shifted to divx.com) Varun

2 1

[arch-dev-public] hidden dependencies
by Andreas Radke 08 Oct '07

08 Oct '07

I want to ask something about our own packaging rules. Right now we don't add any dependencies that are already covered by another. Namcap usually tells you that right. But this makes it hard to do all the .so rebuilds or if you simply want to check over all packages where a pkg foo is a dependency. This is what I use for checking the deps: [andyrtr@workstation64 cvs]$ grep -l libpcap `find . -name PKGBUILD` ./arch/build/base/ppp/PKGBUILD ./arch/build/base/libpcap/PKGBUILD ./arch/build/network/nmap/PKGBUILD ./arch/build/network/ngrep/PKGBUILD ./arch/build/network/tcpdump/PKGBUILD ./arch/build/network/wireshark/PKGBUILD ./core/base/ppp/PKGBUILD ./core/base/libpcap/PKGBUILD ./core/support/ppp/PKGBUILD ./extra/lib/libnetdude/PKGBUILD ./extra/lib/libnids/PKGBUILD ./extra/lib/libpcapnav/PKGBUILD ./extra/emulators/user-mode-linux/PKGBUILD ./extra/network/lft/PKGBUILD ./extra/network/nmap/PKGBUILD ./extra/network/ntop/PKGBUILD ./extra/network/ngrep/PKGBUILD ./extra/network/ulogd/PKGBUILD ./extra/network/etherape/PKGBUILD ./extra/network/tcpdump/PKGBUILD ./extra/network/ssldump/PKGBUILD ./extra/network/ettercap/PKGBUILD ./extra/network/kismet/PKGBUILD ./extra/network/wireshark/PKGBUILD ./extra/network/xprobe/PKGBUILD ./extra/network/tcptraceroute/PKGBUILD ./extra/system/snort/PKGBUILD ./extra/daemons/knockd/PKGBUILD Do you know any way to write some code for namcap or checkpkg to show those hidden "already covered by another dep" dependencies? To run lddd.sh is only a poor solution as it only detects packages that are installed on your system. If not I'd vote to change the old packaging rule and switch to fully shown deps. Andy

5 7

[arch-dev-public] Tool tarball location
by Aaron Griffin 08 Oct '07

08 Oct '07

On 10/2/07, Jason Chu <jason(a)archlinux.org> wrote: > Since namcap is hosted on projects now, where should the tarballs go? > ftp/other or somewhere else? I don't think anyone's thought about this > yet... Yeah, let's use ftp/other/<toolname>/ for all our official stuff like pacman, devtools, etc etc.

10 18

[arch-dev-public] Find-deps script (was: hidden dependencies)
by Travis Willard 07 Oct '07

07 Oct '07

> This is what I use for checking the deps: > > [andyrtr@workstation64 cvs]$ grep -l libpcap `find . -name PKGBUILD` A while ago I posted a script to this ML that does this, but gives more concise output, finding _only_ deps and makedeps, and not random comments and such. Jurgen reworked it a bit for speed and because his bash is leet. I've reattached it here - I suggest you use it. -- Travis

4 6

[arch-dev-public] Testing policy
by Aaron Griffin 07 Oct '07

07 Oct '07

Time for the "big hat" We had some oopses today. Problems that were brought up less than 3 months ago, which reoccurred. In the past, Judd had a problem with saying that every package needs to go to testing. I don't. Going forward, every single [core] package MUST go to testing, and MUST be OKed by at least one other developer. The term here is "independent verification" - we want someone else, that is not you, to tell you this works. While we have no formal tools in place for this, eventually I'd like to have a way to "sign off" that a package in testing works. Just to clarify: This is not a request. This is not a discussion. The core repository is critical to ArchLinux systems and should never be broken like this. All core packages MUST go to testing and MUST be verified by another developer. Feel free to do this on the ML, or on IRC - just somewhere where we can look back on the logs if there are issues. -- Aaron

2 2

Re: [arch-dev-public] [arch-commits] CVS update of core/base/libpcap (PKGBUILD)
by Jan de Groot 07 Oct '07

07 Oct '07

On Sun, 2007-10-07 at 07:42 -0400, Thomas Baechler wrote: > Date: Sunday, October 7, 2007 @ 07:42:13 > Author: thomas > Path: /home/cvs-core/core/base/libpcap > > +# This package has a strict SONAME that changes in EVERY MINOR > +# release. Whenever you feel like updating this package, DON'T, > +# it will break a number of essential system tools. > +# Again, for dummies: IF YOU UPDATE THIS PACKAGE DIRECTLY TO CORE, > +# I WILL PERSONALLY CHOP YOUR HEAD OFF! Morning Mr Head Chopper... I looked at this package yesterday, it seems something is plain wrong with the soname versioning. I took a look at the debian package, where we retrieved the shared library patch from 2 years ago (yes, libpcap was one of the first packages I changed when I had current access). It seems they keep track whether a release is API/ABI stable and keep the soname the same. FYI: They have libpcap.so.0.9.8 and libpcap.so.0.8, as the 0.9.x versions share the same ABI as the 0.8 versions. They update their patches to keep things working. I'm thinking about two solutions here: - Make sure apps stop linking against the .so.0.9.x library, apps should link to the normal soname that doesn't change on minor version bumps - remove the patch completely and continue to use the static library as the libpcap project does upstream Solution 1 looks hard, but all it takes is updating the shared lib patch and adjust it to not look at the debian changelog to generate its sonames.

2 1

[arch-dev-public] Corrupted DBs
by Aaron Griffin 07 Oct '07

07 Oct '07

http://bugs.archlinux.org/task/8241 It appears some packages built for x86_64 were pushed to the i686 repos. I've manually fixed what I could. Please let me know if any more crop up, and please be more careful in the future. This is the exact reason I'd prefer automated tools for this process - to prevent human error. The following packages were affected: ngrep ntop ssldump tcptraceroute

2 2

[arch-dev-public] AUR New Package Notify -- unsubscribe
by James Rayner 07 Oct '07

07 Oct '07

Hey, Unsubscribed from the AUR New Package notification yesterday, but I still got it today. Double checked, and it's unsubscribed on the aur frontend, anyone able to fix this? Address is the one on this mail. Thanks, James

3 4

[arch-dev-public] Cleanup / Orphans - the list
by Andreas Radke 07 Oct '07

07 Oct '07

I've started to workout our internal list for possible cleanups. https://www.archlinux.org/wiki/Repo%20Cleanup/ I've taken packages form the public wiki cleanup list and then many not that important packages from our dashboard marked with "orphaned". We still have to expand the list to have each pkg listed we want to remove. If you want to keep a pkg in our repos hurry up to adopt it. On the other side we have packages nobody wants for various reasons but we essentially need, e.g. apache and all packages from core repo. Make sure you adopt also some of these *unwanted* packages. We can still work all together maintaining/improving/updating them. We have to review the remaining packages in the cleanup list for packages beeing a dependency or beeing essential for some reason. Everything else will soon be removed completly from the extra repo. TUs and users might pick them up later again for community repo/AUR. I think one week should be enough from now on to sort things out. We will see if we need more time. Keep in mind that our goal is to _clean up_ the extra repo now! So better orphan more packages that are not very important(games, science, multimedia, packages where we have alternatives, ...) and adopt some essential packages! Andy

5 5

[arch-dev-public] adopted more stuff
by Varun Acharya 06 Oct '07

06 Oct '07

also adopted 'd4x' & 'firestarter' Varun

1 0

[arch-dev-public] firestarter
by Varun Acharya 06 Oct '07

06 Oct '07

I've adopted firestarter, let me know if you have objections. Also, I build only for x86_64, so I presume I have to alert a dev to update for i686 correct? Thanks, Varun

1 0

[arch-dev-public] Cleanup/Orphans - a BIG warning!
by Andreas Radke 06 Oct '07

06 Oct '07

Am Mon, 1 Oct 2007 17:17:17 -0500 schrieb "Aaron Griffin" <aaronmgriffin(a)gmail.com>: > == Pending Tasks, Short Term == > > * New Round of Package Cleanup > > Let's try and get this "complete" this week. I'd like to get at least > 2 or 3 of us together with Eric to go through these packages and start > moving them to community or unsupported. > > We have an internal list for this here: > https://www.archlinux.org/wiki/Repo%20Cleanup/ > > Please add candidates if you find them. > > Eric, when is a good time for you? I will help out with the cleanup. We had asked all developers to readopt their packages after the repo shuffle. We have a very bad situation right now! Still 916 packages orphaned. 6 developers listed on the dev website have 0 packages. Some other maintain only a few packages. Look what is orphaned: apache, bind, cvs, mono, python, freetype1/2, nspr/nss, pango, gimp, mutt, cdrkit, several desktops, bash, bzip2, gcc-libs, kernel26 and many more! We were talking about our intention to have more than one maintainer per package. But we do not act like that. Having so important packages unmaintained means nobody follows the projects mailing lists. No quick updates, bug fixes, no security fixes... So get your ass up and adopt packages you want to keep in our distribution! DEADLINE for adopting packages should be this coming weekend. Then the cleanup will start. 2 all devs: Isn't that more important than telling something about how much alcohol we drink? -Andy

6 9

[arch-dev-public] back after long break
by Varun Acharya 05 Oct '07

05 Oct '07

Hi devs, The mammoth event which I was busy with is finally over, and it turned out to be a huge success. Will get back to arch work in a few days. I've been following the ML regularly, but forgive me if I ask a stupid question once in a while. Its good to be back :) Varun

3 3

[arch-dev-public] pending devtools issues
by Andreas Radke 04 Oct '07

04 Oct '07

Whenever I had tried out the devtools I had these issues: - I always set a certain pkgdest in makepkg.conf. So (old and) new packages are stored centralized. This breaks checkpkg and {foo-repo}pkg as they expect old and new pkg in the current directory. Correct me if I missed any option to solve that. - As I only have poor bandwidth and like to keep working while down-/uploading I want to have a bandwidth-limit option for filetransfer. At least for uploading. Afaik the scripts use scp. Man scp tells me there's -l limit - Limits the used bandwidth, specified in Kbit/s. Yes I like the idea to "force" all devs using devtools to reduce unneeded mistakes and issues. Forcing us with an integrated namcap run is something I would like to see. But we should still be able to do everything by hand. There always might appear some reason why the tools get broken and we need to fix something manually. Andy

7 31

[arch-dev-public] archlinux water
by Damir Perisa 04 Oct '07

04 Oct '07

just got a nice picture remembering me on archlinux: http://lux.perisa.ch/tmp/ img_6366_uxga.jpg enjoy! if i'm running over similar pictures and have enough, i'm considering making a arch gallery :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

3 4

[arch-dev-public] critical: fakeroot broken again, breaks makepkg
by Thomas Bächler 04 Oct '07

04 Oct '07

Oops, this should have gone to the public list directly, so I'll repost it here: I saw this problem a while ago already, but didn't really investigate it. When building a package, you would often end up with non-world-readable /usr/man/manX directories. This happens whenever this code in makepkg is executed: # move /usr/share/man files to /usr/man if [ -d $startdir/pkg/usr/share/man ]; then cd "$startdir" mkdir -p pkg/usr/man cp -a pkg/usr/share/man/* pkg/usr/man/ rm -rf pkg/usr/share/man fi This can be reproduced easily: [09:29:39][thomas@artin shm]$ fakeroot bash-3.2# mkdir -p foo/ab bar bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 2 root root 40 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2# cp -a foo/* bar/ bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwx------ 2 root root 40 Jul 12 09:29 ab foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2# I can't find out exactly what's causing this, so if anyone has an idea, feel free to share it. This should definitely be fixed quickly, as it prevents me from updating several packages.

4 6