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

[arch-dev-public] license for sqlite3
by Andreas Radke 03 Dec '07

03 Dec '07

http://www.sqlite.org/copyright.html so far we used "custom" and installed the included license file. now this file has been removed from the source. what should i do now(no file/use old file/create a txt file with a link to the license url)? -Andy

8 11

[arch-dev-public] Testing DB locked.
by Travis Willard 03 Dec '07

03 Dec '07

Does Kevin have a 3-day-long repo rebuild going on? :P I'm going to delete that lock file - just FYI. $ /arch/db-testing error: db generation is already in progress (started by kevin) $ ls -l /tmp/.repolck.i686.4 -rw-r--r-- 1 kevin users 0 2007-11-30 22:36 /tmp/.repolck.i686.4 -- Travis

2 3

[arch-dev-public] Questionable apps in core/support
by Aaron Griffin 03 Dec '07

03 Dec '07

I just came across a couple of things in core/support that seemed odd to me, and wanted to ask you guys what you thought: support was intended to be apps which "help out" or "support" the rest of core - like when installing and things like that. a) screen While this is an important app, sure, does it belong in core? b) hdparm and sdparm I don't see how these work in "support" - as the very least I'd put them at the same mental level as acpi and pm-utils c) openswan/openvpn/vpnc I'm on the fence here. I mean, I could see VPN connections being needed at some point during an install or something of the sort, but at the same time, why do we have 3 VPN apps there? Anyone want to clarify or give me your opinions here?

6 8

[arch-dev-public] Signoffs
by Aaron Griffin 03 Dec '07

03 Dec '07

On Dec 2, 2007 3:53 PM, Eric Belanger <belanger(a)astro.umontreal.ca> wrote: > On Sun, 2 Dec 2007, Travis Willard wrote: > > On Dec 2, 2007 4:30 PM, Eric Belanger <belanger(a)astro.umontreal.ca> wrote: > >> > >> On Sun, 2 Dec 2007, Travis Willard wrote: > >>> That's not the way signoffs work. You CAN'T just 'assume' they are fine. > >>> You have to wait. Sorry, but it breaks the whole system otherwise. > >> > >> Actually, these packages were already signed off by two devs: Dan for i686 > >> and me for x86_64. From an IRC discussion with Aaron, the devs who put the > >> packages in testing counts as one of the two signoff. That might seem > >> strange but it's the way it works unless the signoffs gets a better > >> definition. > > > > That doesn't seem sound to me. Recall the problem when the kernel > > package that was uploaded had something screwy in it due to a bad > > transfer. Under this situation, tpowa would have 'signed off' his own > > upload, whoever built it for x86_64 would have signed it off for their > > own upload, and then the buggy package i686 would have been pushed to > > core. > > > > If that's how we want our signoffs, then that's fine - I'm just > > pointing out a possible flaw. > > > > > I agree that the packager shouldn't count as a signoff. That how I > undertood it before the little discussion in IRC. > > IMO, the way signoff should be done to prevent any potential screw up is > that 2 devs other than the packagers should signoff and that each > architecture should at least be signed off > once. So as to not clutter up Dan's thread, can we move this talk here? To clarify. My intention was "at least 2 devs are responsible for the package" - the statement DOES include the original packager, however, let me point out that each cvs commit has 2 packages. I guess I assumed the statement was clear when it really wasn't. So let me clarify: Bill uploads package a-i686. Bill, in the act of uploading it, says "well this works for me". It's an implicit signoff and the way we have always worked - the act of uploading a package is an implicit agreement that it is in working order. No one tests a package, says "wow this is broken" and uploads it. Now, when John signs off for i686, that's two people who have said "hey this is working". However, a-x86_64 has not been signed off for. In fact, bill never uploaded that package so couldn't possibly sign off for it. Alternatively, Bill used my machine to build the package but does not have a box to test it on. As such, 2 people are needed to test/signoff for x86_64. So, in actuality, I intended a total of 4 signoffs, but including the original submitter. I don't really get where the idea that the original person who uploaded the package isn't responsible for it comes from? The whole point of the sign off thing is to say "we are the ones responsible for this". How about this: In the email sent out for having a package signed off, you explicitly list yourself as signed off on a given architecture that you actually tested the package on. Is there a problem with this?

2 1

[arch-dev-public] Source dirs in ftp/other
by Travis Willard 02 Dec '07

02 Dec '07

Hey guys, Can someone with appropriate rights create source dirs in /home/ftp/other for mythtv, mythplugins, and myththemes please? We're hosting them from paul's homedir at the moment. Thanks

3 5

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

02 Dec '07

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

4 7

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

02 Dec '07

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

3 2

[arch-dev-public] rebuild for pidgin
by Dan McGee 01 Dec '07

01 Dec '07

Can someone rebuild pidgin for i686? I made some changes, but my chroot is inoperable right now so I'd appreciate it if someone else could build it. It is already built and uploaded for x86_64. -Dan

2 1

[arch-dev-public] Perl & vacation
by K. Piche 01 Dec '07

01 Dec '07

Lads, I've put perl-5.8.8-10 into CVS and the pkg is in my staging dir - I think the db-testing script got hosed. Anyways this is the first crack at the new perl policy. I though I'd put it out there since I haven't worked on it for a while since things have been hectic at work. Don't have time to fix the db script since I'm leaving in 4 hours for a Caribbean cruise. Back on the 10th! k -- K. Piche <kpiche(a)rogers.com>

1 0

[arch-dev-public] Upcoming TLLTS Interview
by Aaron Griffin 01 Dec '07

01 Dec '07

I just thought I'd point this out... http://www.tllts.org/ On December 12th they want to have me on, so for those of you who haven't at least heard my voice, it might be fun to listen to the podcast I feel quite... overshadowed by the two people surrounding me on that list though 8) Cheer, Aaron

1 0