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

[arch-dev-public] Repository cleanup [current] and [base] --> [core], this weekend!
by Tobias Powalowski 15 Sep '07

15 Sep '07

Hi it's quite a long time ago we had a dev meeting, but i think there were quite some agreement what [core] should be and we should start doing this soon. Our next ISOs shouldn't have the big current anymore only ftp and [core]. [non-free] repository we should add a non-free repository with stuff that is not freely distributable, like acroread, sun java, firmware files, flash etc. this cleanup would affect [extra] and [current] that way we could finally have cds of [extra] too without getting into trouble. As Romashka said, these are the types we need to look at: 1) those that are not possible to distribute due to prohibition of original package modification, but it does not work without modifications to installation procedure - like vmware 2) those that are not allowed to be redistributed by EULA - like commercial edition of virtualbox 3) those that are not allowed to be sold on a CD, but can be distributed over internet 4) those that are just not Free Software - it's nice to have them splitted if someone wants to have FOSS-only mirror/CD/etc 1+2 should be probably moved out of the official repositories, if not already done. 3+4 should be ok [core] repository should be like [base] + some extra stuff the question is: what is extra stuff? imho, it should be everything that is needed for networking free kernel network modules free wlan stuff all supported main filesystems suggestion list of packages to add: ndiswrapper ndiswrapper-utils wlan-ng26 rt2500 madwifi madwifi-utils fuse ntfs-3g iptables bcm43xx-fwcutter dosfsutils ntfsprogs kexec-tools snarf dnsutils hdparm bridge-utils ifenslave xinetd portmap nfsidmap nfs-utils openssh netkit-telnet screen isdn4k-utils capi4k-utils vpnc openvpn everything else from [current] should be moved to [extra]. your opinions, lets get something done this weekend. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

17 42

[arch-dev-public] IMPORTANT: Repo DB scripts hacked!
by Thomas Bächler 14 Sep '07

14 Sep '07

As rewriting the repo db scripts is a time intensive process which involves cleaning up the web backend too, I did a few hacks to our current scripts to support both the pacman2 and pacman3 naming scheme. I changed the updatesync-many, pkgdb1, db-inc and genpkglist files. Please everyone who is familiar with the scripts (and everyone else, because noone is actually familiar with them) look over my changes and see if they make sense. If no errors are found, the scripts WILL be moved from CVS to /arch and WILL be used. So make sure I didn't screw up. For the lazy, I attached the diff. Index: db-inc =================================================================== RCS file: /home/cvs-arch/arch/scripts/db-inc,v retrieving revision 1.6 diff -u -r1.6 db-inc --- db-inc 7 May 2006 18:02:42 -0000 1.6 +++ db-inc 14 Sep 2007 16:38:14 -0000 @@ -16,6 +16,18 @@ exit 1 fi +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + cleanup() { rm -rf $TMPDIR # unlock @@ -134,7 +146,7 @@ cd $stagedir/del ( for i in *.pkg.tar.gz; do - pkgname=${i%-*-*} + pkgname=$(getpkgname $i) echo $pkgname done ) | $ARCHDIR/pkgdb2-del $repoid $stagedir/del @@ -147,7 +159,7 @@ if [ "$updatelists" ]; then echo "==> Generating Text Package List..." >&2 cd $TMPDIR/$cvsmod - $ARCHDIR/genpkglist $ftppath + $ARCHDIR/genpkglist $ftppath $arch # hack -- only Current's packages.txt goes in a "setup" subdir if [ "$reponame" = "current" ]; then Index: genpkglist =================================================================== RCS file: /home/cvs-arch/arch/scripts/genpkglist,v retrieving revision 1.14 diff -u -r1.14 genpkglist --- genpkglist 5 May 2006 01:38:33 -0000 1.14 +++ genpkglist 14 Sep 2007 16:38:14 -0000 @@ -8,8 +8,21 @@ # (also used to check for missing packages in the download directory) # +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + pkgfile="`pwd`/packages.txt" ftppath=$1 +dbarch=$2 rm -f $pkgfile for category in `find * -maxdepth 0 -type d | grep -v CVS`; do @@ -20,8 +33,10 @@ . PKGBUILD if [ -f $ftppath/$pkgname-$pkgver-$pkgrel.pkg.tar.gz ]; then echo "$category/$pkgname-$pkgver-$pkgrel.pkg.tar.gz" >>$pkgfile + elif [ -f $ftppath/$pkgname-$pkgver-$pkgrel-$dbarch.pkg.tar.gz ]; then + echo "$category/$pkgname-$pkgver-$pkgrel-$dbarch.pkg.tar.gz" >>$pkgfile else - echo "notice: Missing $pkgname-$pkgver-$pkgrel.pkg.tar.gz in ftp site" >&2 + echo "notice: Missing $pkgname-$pkgver-$pkgrel-$dbarch.pkg.tar.gz in ftp site" >&2 fi fi cd .. @@ -32,7 +47,7 @@ cd $ftppath unset DUPES DUPEFILES last for pkg in *.pkg.tar.gz; do - pkgname=${pkg%-*-*} + pkgname=$(getpkgname $pkg) if [ "$last" = "$pkgname" ]; then DUPES="$DUPES $pkgname" DUPEFILES="$DUPEFILES $pkg" Index: pkgdb1 =================================================================== RCS file: /home/cvs-arch/arch/scripts/pkgdb1,v retrieving revision 1.4 diff -u -r1.4 pkgdb1 --- pkgdb1 20 Feb 2006 06:33:40 -0000 1.4 +++ pkgdb1 14 Sep 2007 16:38:14 -0000 @@ -1,6 +1,18 @@ #!/bin/bash # $Id: pkgdb1,v 1.4 2006/02/20 06:33:40 judd Exp $ +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + STAGEDIR=`pwd` ABSDIR=$1 @@ -16,9 +28,8 @@ cd $STAGEDIR for pkgfile in `ls $STAGEDIR/*.pkg.tar.gz`; do - tmp=${pkgfile##*/} - pkgname=${tmp%-*-*}; - fullname=${tmp%.pkg.tar.gz} + pkgname=$(getpkgname $pkgfile); + fullname=$(basename $pkgfile) # find the matching PKGBUILD tmpf=$(mktemp /tmp/pkgdb1.XXXXXXXXXX) || exit 1 find $ABSDIR -type d -name "$pkgname" >$tmpf Index: updatesync-many =================================================================== RCS file: /home/cvs-arch/arch/scripts/updatesync-many,v retrieving revision 1.2 diff -u -r1.2 updatesync-many --- updatesync-many 5 May 2006 01:38:33 -0000 1.2 +++ updatesync-many 14 Sep 2007 16:38:14 -0000 @@ -1,4 +1,5 @@ #!/bin/bash +# $Id: $ # # updatesync-many # @@ -46,6 +47,18 @@ echo "updatesync-many: $*" >&2 } +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + check_option() { local i for i in ${options[@]}; do @@ -76,6 +89,9 @@ cd $pkgname-$pkgver-$pkgrel # desc : >desc + echo "%FILENAME%" >>desc + echo "$2" >>desc + echo "" >>desc echo "%NAME%" >>desc echo "$pkgname" >>desc echo "" >>desc @@ -138,10 +154,8 @@ delete_entry() { - # strip to the basename - tmp=${1##*/} # grab the pkgname - pkgname=${tmp%-*-*} + pkgname=$(getpkgname $1) for i in *; do if [ "${i%-*-*}" = "$pkgname" ]; then rm -rf $i @@ -152,9 +166,8 @@ update_entry() { pkgfile=$1 - tmp=${pkgfile##*/} - pkgname=${tmp%-*-*}; - fullname=${tmp%.pkg.tar.gz} + pkgname=$(getpkgname ${pkgfile}) + fullname=$(basename ${pkgfile}) # find the matching PKGBUILD tmpf=$(mktemp /tmp/updatesync-many.XXXXXXXXXX) || exit 1 @@ -185,7 +198,7 @@ pkgmd5sum=`get_md5checksum $pkgfile` [ -z $pkgmd5sum ] && die "error generating checksum for $pkgfile" - db_write_entry $pkgbuild || die "error writing entry for $pkgname" + db_write_entry ${pkgbuild} ${fullname} || die "error writing entry for $pkgname" cd - >/dev/null } @@ -237,9 +250,7 @@ lsof $pkgfile &>/dev/null [ $? -ne 1 ] && continue - tmp=${pkgfile##*/} - pkgname=${tmp%-*-*}; - fullname=${tmp%.pkg.tar.gz} + pkgname=$(getpkgname ${pkgfile}) if [ "$ACTION" = "del" ]; then msg "Deleting entry: $pkgname" delete_entry $pkgfile

2 2

[arch-dev-public] FYI: Split gcc/libgcc
by Thomas Bächler 14 Sep '07

14 Sep '07

Aaron is right about communication, so I am posting this here: While splitting the current/base category into core/base and core/devel, it has been decided to split the gcc package into gcc(tools) and libgcc(libs:libstdc++,libgcc_s,...), so that no package will have to depend on gcc in the future, but rather on libgcc. gcc will depend on libgcc, gcc will go to core/devel and libgcc will go to core/base. Jan hopes he can do the split tonight.

4 4

[arch-dev-public] [core] move oragnisation
by Tobias Powalowski 14 Sep '07

14 Sep '07

Hi this thread is intended to organise this move. I will create a dependency list that needs to move in tomorrow afternoon. Would it be possible to meet each other on IRC tomorrow evening, european time? aaron is 7 hours behind germany. Put your ideas here, how to do it smoothly. the easies way to move the stuff in would be to put all in base. including kernel + modules. will cause probably some issues on ftp installs in setup and kernel installation, which can then be solved with new isos eventually. well i think the rest will be clear tomorrow evening. thanks for participating, im too tired for more now. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 8

[arch-dev-public] Reactive development [was: Repository cleanup]
by Aaron Griffin 14 Sep '07

14 Sep '07

On 9/12/07, Simo Leone <simo(a)archlinux.org> wrote: > What I'm trying to get across here is that some parts of this dev team > have adopted a reactive development model. By this I mean that the > majority of your devel is driven by whatever issues come up, as they > come up. Do you realize why that's bad? > > Typically projects will go through some solid research and plannning to > avoid this situation. I've heard that when the developer has a solid > understanding of the problem, they often develop more generic tools that > have more unforseen uses in the future than when they develop > reactively. This is why, for instance, pacman is so versatile in that it > alone can be used to solve all these problems (like phil said). Gee, > what a great tool. > > Sorry for the slight OT, it's kind of related. Wow. Simo said exactly what I've been feeling for some time now, much more concisely that I even had formulated the thoughts. This is also a very CRITICAL point, and the root of every problem we've had recently. See, ok. Rant-ish time now. I know a lot of you don't do this for a living. You don't work in software. Me? I've been doing this for over 7 years now professionally. Companies large and small, new companies with new technology, old companies with giant 100MHz mainframes, writing code in over 10 different languages. I've written bugs that made people laugh, and bugs that cost a company thousands of dollars. I've been there and done every stupid bad thing you can imagine (update without a where clause on a production DB anyone?) I've been forced to learn how to go about the process here. That's our problem. We have a disparity here between people who don't know common software development practices, and those who do. Those who know these processes expect everyone to implicitly follow them, and those who don't know them think they're silly. Here's the long-and-short of it. When you have cost a company $10000 due to one bad line of code, you learn to appreciate what a one hour code review can do. You learn to appreciate proper communication channels when two people make "hotfixes" to a live DB that break each other. This is what we're lacking. And sadly, it's a word everyone hates. We're missing "process". It is a _fact_ that as groups grow, they need more control. A group of 5 of us could easily coordinate things, but we're well over 25 (Phil said 30? wow!) and at this point we CAN'T keep doing things without proper process. It's just silly. Communication channels must be kept in check. If you do anything that affects the rest of us, then we should know about it before the users do. This includes important module changes (oh crap guys, I broke your X!), changes to initscripts (isatty is missing, btw), new ISO releases (I burned 3 copies of "Don't Panic" 2 days before the new release, for the record), and just... well... anything. Seriously, communication isn't hard. Hell. I know english may be a barrier, but why don't you write in german or something with "Please Translate:" at the top just so we know something is happening. That said, we have always held that the mailing lists are our proper channel of communication. This is important. Hell, it's critical. Saying "hey guess what!" on IRC doesn't cut it. The mailing list not only informs everyone (not all devs are on IRC) but also has archival history. We need to communicate. We need to follow processes. If you find a bug or a user report, and you're unclear about it - **say something**. The great word being flung around these days is "unilateral" - we're not a group of 30 independent people doing their own things, we're a group of 30 people working together. We need to stop reacting and doing our own thing. If something seems questionable, say something. Say "hey guys what do you think about N?". Just bring it up. Not everyone will respond. That's expected. Sometimes you have no opinion, but at least we KNOW what's happening. Guys, seriously. We're floundering. Something needs to be done, and it's not up to one or two of us. It's up to all of us.

5 4

[arch-dev-public] READ ALL:Please hold commits, [core] repository will be setup soon.
by Tobias Powalowski 13 Sep '07

13 Sep '07

Hi as in the earlier thread stated we want to setup our new [core] repository this weekend, for making this possible please don't check in anything to extra/current the next days until we finished this. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] git cheat sheet.
by eliott 13 Sep '07

13 Sep '07

For all you devs out there. Kind of neat. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html A potentially very useful git cheat sheet. :)

2 2

[arch-dev-public] opencdk, gnutls and libtasn1 in testing
by Jan de Groot 12 Sep '07

12 Sep '07

A few minutes ago I pushed gnutls 2.0.0, OpenCDK 0.6.4 and libtasn 1.1 to testing. Though all of them have a new major version number, only OpenCDK has had a so-bump. It seems that GNUTLS is the only package that depends directly on opencdk, and running lddd.sh on my system shows no possible rebuilds for this upgrade. Please give these libraries some testing, as they're an important part of your system. Report bugs to flyspray so we can rebuild these broken applications.

1 0

[arch-dev-public] Away 9/9-9/15
by Paul Mattal 09 Sep '07

09 Sep '07

I will be on vacation and relatively offline 9/9 through 9/15. Feel free to feed and care for my packages in my absence. I plan to kick mythtv out of testing on my return, and tackle the new version of eclipse and eclipse-cdt. - P

1 0

[arch-dev-public] Xorg dummy package removal
by Travis Willard 07 Sep '07

07 Sep '07

Hi everyone, As recently pointed out in http://bbs.archlinux.org/viewtopic.php?id=37062&p=1 the xorg dummy package has been removed. While this could have been done a bit more elegantly and with warning, it's been done, and I'm post-emptively giving warning now I guess. Anyone maintaining packages with the dependency on 'xorg' please update your packages. Nothing should EVER depend on 'xorg' - use namcap to find out what the true deps to your package are and add them. Some packages in extra, community, and AUR-unsupported probably need fixes. To preserve convenience of installing Xorg, we're considering doing an xorg group between the packages previously pulled by the xorg metapackage. I'll follow up to this email when that's done. Thanks. -- Travis

4 3