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

[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