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

[arch-dev-public] Don't Panic Release Isos
by Tobias Powalowski 04 Aug '07

04 Aug '07

Hi i generated new Don't panic isos, i'll test them tomorrow and if they work i'll put them to 686 ftp to let the servers sync. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-dev-public] projects.archlinux.org - "Official" projects only?
by Travis Willard 02 Aug '07

02 Aug '07

Hey all, In a recent forum thread[1] someone kept suggesting they move yaourt development to projects.archlinux.org -- I was under the impression that was for arch "official" projects only, and I replied as such, but I'd like to make sure I have my facts straight. Can people like the devs of yaourt add their projects to projects.archlinux.org? Or is it for stuff like pacman, pacbuild, namcap, etc... only? Thanks. Travis [1] http://bbs.archlinux.org/viewtopic.php?id=35772

4 5

[arch-dev-public] Absence
by Thomas Bächler 02 Aug '07

02 Aug '07

I will be gone 04. - 11.08. Have a nice week.

1 0

[arch-dev-public] new flac
by Paul Mattal 02 Aug '07

02 Aug '07

New flac is up in [current]. This is a major version update, so packages linked against may need to be bumped/rebuilt. - P

8 18

[arch-dev-public] x86_64 testing: missing pkg
by Andreas Radke 02 Aug '07

02 Aug '07

==> Generating Text Package List... notice: Missing xf86-video-sis-0.9.3-2.pkg.tar.gz in ftp site please fix it. and what about these packages? U extra/emulators/qemu/70-kqemu.rules U extra/emulators/qemu/PKGBUILD U extra/network/madwifi/kernel-2.6.22.patch U extra/network/madwifi-utils/kernel-2.6.22.patch U extra/system/pm-utils/PKGBUILD U extra/system/pm-utils/pm-utils.install madwifi has to be untagged from testing. can qemu and pm-utils move? Andy

1 0

[arch-dev-public] makedepends
by Paul Mattal 01 Aug '07

01 Aug '07

So flac (in [current]) has a makedepend on xmms (now in [community]). In this instance, this seems okay, since if xmms one day goes away, we remove that makedepend and the only bad effect is that there's no xmms plugin.. which is fine if there's no xmms! But couldn't this be a problem in general? Do we have any rules about makedepends across repositories? - P

4 3

[arch-dev-public] [projects@lists.froscon.de: [FrOSCon-Projects] Erste Infos bzgl. Projektraum auf der FrOSCon]
by Christoph Neuroth 01 Aug '07

01 Aug '07

Hi guys, so, exam time is over and so is my little vacation, so I can forward you a mail from the FrosCon team. summary of the important parts (too lazy to translate it all ;)): * we will have free wireless, but they are not sure if it will work all the time so they try to also provide a ethernet connection. however we will need to bring our own switch and cables * they would like to hear how many people will attend. Last thing I remember was alex, andi, jan, pierre and me. Please send me a mail if you definitely plan to come so I can order the free as in beer tickets for you ;) otherwise you'll have to pay (I think its like 5 bucks a day, so not that big a deal...) * we can sleep in the project room (don't forget a sleeping bag), but only the night saturday to sunday. alternatives here: http://wiki.froscon.de/wiki/Accommodation chris ----- Forwarded message from projects(a)lists.froscon.de ----- Date: Fri, 27 Jul 2007 10:12:29 +0200 To: projects(a)lists.froscon.de Cc: Mailingliste zur Organisation der FrOSCon <orga(a)lists.froscon.de> From: projects(a)lists.froscon.de Subject: [FrOSCon-Projects] Erste Infos bzgl. Projektraum auf der FrOSCon Liebe Projektraumverantwortlichen, Wir möchten Euch gerne darauf hinweisen, dass Eure Projektnamen auf unserer Konferenzhomepage http://www.froscon.de unter dem Menüpunkt Aussteller > Projekträume eingetragen wurden. Falls zu Eurem Projektnamen noch kein Logo vorhanden sein sollte oder dieses Euren Wünschen nicht entsprechen sollte, bitten wir Euch uns ein passendes Logo zuzuschicken, damit wir es auf unserer Homepage einfügen können. Was das Netz angeht, so steht Euch ein WLAN zur Verfügung. Ob dieses dem Besucheransturm standhält ist jedoch unklar. Wir bemühen uns daher, jeden Projektraum zusätzlich mit kabelgebundenem Netz auszustatten. In jedem Fall werden wir nur eine Netzdose zur Verfügung stellen können. Entsprechende Kabel und Unterverteilungen (Switch/Hub) sind daher selbst mitzubringen. Dankbar wären wir auch über eine Auskunft, mit wievielen Personen Ihr die Projekträume betreut. Die Namen der Teilnehmer bräuchten wir bis spätestens 2 Wochen vor der Konferenz. Falls Ihr uns diese Informationen nicht zukommen lasst, ist es uns nicht möglich, Eintrittskarten für Euch zu hinterlegen. Daher müsstet Ihr in diesem Fall leider Besucherkarten erwerben. Sollten einzelne von Euch bereits Speaker, Medienpartner, Helfer etc. sein benötigen wir diese Namen nicht mehr. Für die Verteilung der Projekträume benötigen wir noch eine Information von Euch: Möchtet Ihr ein eigenes Vortragsprogramm auf die Beine stellen? Wenn ja benötigen wir euer Programm bis spätestens zum 09.08.2007, wenn Ihr möchtet, dass es mit in das offizielle Programmheft kommt. Wir können es auch gerne mit in unser Online-Programm einbinden. In diesem Fall benötigen wir, neben Titel und einem kurzem Abstract, noch den Namen und die E-Mailadresse des Speakers. Ein Bild des Speakers wäre auch nett, ist aber kein Notwendigkeit. Des Weiteren benötigen wir 1-2 Ansprechpartner denen wir einen Schlüssel für den Raum aushändigen können. Bitte bringt dafür einen Personalausweis oder ähnliches mit. Ansonsten darf der Wachdienst die Schlüssel nicht aushändigen. Übernachtungsmöglichkeiten in der FH können wir nur von Samstag auf Sonntag anbieten. Für diese sind dann ein Schlafsack und eine Isomatte mitzubringen. Es wäre super, wenn Ihr als Schlafplatz euren Projektraum nutzen würdet. Teilt uns dann bitte nur mit, wieviele Leute übernachten, damit wir das Frühstück entsprechend planen können. Weitere Übernachtungsmöglichkeiten findet ihr unter http://wiki.froscon.de/wiki/Accommodation . Wir würden uns über eine baldige Antwort sehr freuen. Mit freundlichen Grüßen, Volker und das gesamte FrOSCon Organisationsteam _______________________________________________ Projects mailing list Projects(a)lists.froscon.de https://management.froscon.de/mailman/listinfo/projects ----- End forwarded message -----

5 4

[arch-dev-public] Useful scripts
by Travis Willard 01 Aug '07

01 Aug '07

Hey guys, Just threw together a couple of useful scripts, and I figured I may as well share. Note of warning!! Do not use these scripts on any PKGBUILDs you don't trust! They source every PKGBUILD to obtain the information - if a single PKGBUILD has rm -rf ~ you'd lose your home directory. You've been warned. ;) (of course you could run it in a sandbox as well, but yeah.) find-deps: This one finds all PKGBUILD files located in any subdirs of $(pwd), and finds any and all packages that depend on the command line argument. Very useful when searching for packages that might need a rebuild when you're updating a lib - just run it in your cvs directory and it'll go and find everything that lists your pkg as a dep. find-bad-licenses: This one also finds all PKGBUILD files located in any subdirs of $(pwd), and analyses all entries in the license array. If the license isn't one located in /usr/share/licenses/common, and it doesn't start with 'custom', then the package and its invalid license are output to stdout. Also, if no license is defined, it outputs this info to stdout as well. At the moment, it doesn't check the validity of custom licenses, but it does its job well; I've also attached the list it generates when run against extra/community/unstable. It's a long list - almost 2k invalid/non-existent licenses. I intend to go through what repos I have access to (extra, unstable, community) sometime in the near future (probably within the next couple of months) and clean up this license situation - we really need to get consistent with these things. Anyway, if you can get any use from my scripts, please do. ;) -- Travis

5 7

[arch-dev-public] Multiple Kernels in Repos
by James Rayner 01 Aug '07

01 Aug '07

Forking off the thread before... It's arrogant and hopelessly short sighted, to assume that one kernel will be enough. If we went that way, then that would provide *more* reason for DKMS anyway. As the amount of people compiling custom kernels would skyrocket, thus making DKMS even more useful. Arch has had more than one kernel for years. And there's no downside to having more than one, provided that they are sufficiently maintained. DKMS would make maintenance far far easier and tidier, while making the user's life a bit easier too. I'd be willing to pick up suspend2/tuxonice if we went to DKMS too. (didnt brain0 drop that, or am i making things up?) James

2 1