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

[arch-dev-public] new x264 and ffmpeg in testing
by Paul Mattal 05 Dec '07

05 Dec '07

I just put a x264 snapshot from 20071201 and an ffmpeg snapshot from 20071204 (built against the new x264) in testing. Please test/rebuild your dependent apps and let me know if there are any bugs. I'd rather choose stabler snapshots sooner rather than later if one of these is unhealthy. - P

3 3

[arch-dev-public] [signoff] madwifi/madwifi-utils svn version 2978
by Tobias Powalowski 05 Dec '07

05 Dec '07

Hi http://bbs.archlinux.org/viewtopic.php?id=40261 according to this thread the normal madwifi tarball has some issues. which is fixed with svn version, please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 3

[arch-dev-public] [signoff] netcfg2 to [core]
by James Rayner 04 Dec '07

04 Dec '07

Anyone got any problems with releasing netcfg2 from testing? The results of the testing thus far are here, and there's many people who've got it working on the forums. I've only had some minor changes in the last release, some of which were my own error committing an older source to the git repository originally: http://wiki.archlinux.org/index.php/Network_Scripts#Results http://projects.archlinux.org/git/?p=netcfg.git;a=summary I'm not too concerned about the remaining hardware, they're generally less common -- not that they're not important -- but they should work already, and probably don't work with the existing netcfg anyway. Thomas: That patch for initscripts I sent last time should still work, it's re-attached. James

4 6

[arch-dev-public] [signoff] bash 3.2.025-4
by Aaron Griffin 04 Dec '07

04 Dec '07

This is a quick one - please sign off as soon as possible. The current package does NOT contain /etc/profile This cripples newly installed systems. It will, right now, give you a "/etc/profile exists" error. I don't know a way around this... if anyone has a suggestion, that'd be great, but right now we have a big fat error on freshly installed systems. In testing for i686

5 10

[arch-dev-public] Disconnected for a while
by Simo Leone 03 Dec '07

03 Dec '07

Hey guys, I'm going to be offline for the next two weeks due to finals. After finals are over, I'll rifle through my mail and take care of anything I can in a day or two, then I'm off to Finland for a month, and I'm not taking a laptop (what's a vacation if you bring all your normal crap along?). I won't be back in full action until January 14th, hopefully with more enthusiasm as a bonus :) -S

3 2

[arch-dev-public] [signoff] shadow 4.0.18.2-1
by Tom K 03 Dec '07

03 Dec '07

New upstream shadow release, plus fixes for FS#8050/8051/8724/8742, and general PKGBUILD tidy-up. I would be grateful if someone could build and upload this for x86_64. Please note that this signoff request supercedes Dan's, posted a couple of days ago: http://archlinux.org/pipermail/arch-dev-public/2007-November/003430.html Regards T.

5 7

[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