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

[arch-dev-public] wireless modules up for grabs
by Phil Dillon-Thiselton 20 Jul '07

20 Jul '07

I've got a madwifi card I can use with i686 and x86_64, so i can take that unless anyone has any objections? kth5?

3 3

[arch-dev-public] missing packages [current] 686
by Tobias Powalowski 20 Jul '07

20 Jul '07

Hi notice: Missing fetchmail-6.3.8-3.pkg.tar.gz in ftp site notice: Missing xf86-input-joystick-1.2.2-1.pkg.tar.gz in ftp site notice: Missing xf86-video-nv-1.0.1.4-1.pkg.tar.gz in ftp site please fix this immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-dev-public] The core of Arch Linux - repo reorganization
by Pierre Schmitz 19 Jul '07

19 Jul '07

Hi all, reading the last dev meeting log I realized that we need a clean concept to organize our package repositories. The problem: We have two official repositories: [current] and [extra]. Historically [current] should fit on a cd-r and includes packages preferred by Judd (and maybe some other "early" devs). [extra] should include everything else. Today nobody really know why a package is in current or extra. In addition to this we have some dependencies from current into extra and some non-free packages in current. This makes distribution on a cd/dvd quite difficult. Any last but not least: There is no easy way to install packages from a cd after the system is set up. So I do not think we need to worry about cd-r size. The solution: Imho the only solution is to drop those repos and set up new ones with a clear definition what should be included. This is only a fist proposal. A concrete package list has to be worked out later. [core] This repo will include those packages which have to be installed on every arch system regardless if its a server, workstation or notebook. This category will be similar (but not the same) as the current base category. It should contain all packages that are needed for a basic installation and it should be able to connect to the internet. (including all networking modules, ssh etc.) Furthermore it must include all tools and libs that are needed to rebuild and maintain the repo. So we need gcc, abs, csup, devtools etc. in [core] [core] should have some stricter policy when someone wants to update, add or delete packages. Major updates should pass a set of tests first. Minor and security updates could pass immediately. Addition or Deleting of packages should be discussed on ml before. And of course this repo should not depend on anything else (including makedepends) [extra] Everything else (like xorg, KDE etc.) will go into a "new" [extra] repo. This will be like the extra repo we currently have. But I would recommend the following policies: * only include "stable" software (meaning no alpha, beta, svn, git etc. branches). We should use [unstable] for those. * packages which are only used by very few users might be moved to [community] (see package cleanup) [non-free] As mentioned above it would be a good idea to move all non-free packages to a separate repo. This way we wouldn`t have any problems with distributing core+extra on a dvd. Of course no other package from any other repo should depend on one from non-free. [testing] and [unstable] are special and imho they don`t need further discussion. ;-) Step by step: 1) decide which packages should be in the [core] repo (check dependencies etc.) 2) move everything else into extra 3) cleanup extra; move packages into non-free, community or even aur 4) make sure there are no broken dependencies (including makedepends). It should look like this: [core] <- [extra] ^----------^----[non-free] ^----------^----[unstable] ^----------^----[community] Ok this is only a first proof of concept and a lot of work has to be done; bu what do you think of this idea? Pierre -- archlinux.de

7 7

[arch-dev-public] i will be back
by Damir Perisa 18 Jul '07

18 Jul '07

Dear all, long it is since i was really active here and this was mainly because of my master thesis and other duties. as my i686 is dying, i will replace it with a C2D tablet soon (as soon as lenovo ships it *smile*). lets see who is faster: me finishing my master thesis or lenovo shipping my laptop. so or so, when both events happen, i will first have to figure out how to run arch on a thinkpad x61t and then i hope i will join the arch64 team as well. of course only if you 64bit guys let me :) thanx to you all for seeing after my pkgs + have a nice weekend, Damir -- Damir Perisa Master Student Biozentrum, University of Basel Department Biochemistry / Focal Area Infection Biology Klingelbergstrasse 50-70 CH-4056 Basel, Switzerland

2 1

[arch-dev-public] kernel 2.6.22 showstoppers
by Tobias Powalowski 18 Jul '07

18 Jul '07

Hi is it right that only ndiswrapper needs to be fixed? could someone please confirm this, thanks here bug for reference: http://bugs.archlinux.org/task/7598 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] Please build and test testing/madwifi on i686
by Alexander Baldeck 17 Jul '07

17 Jul '07

Could somebody please take care of that? Thanks a bunch, -U

2 3

[arch-dev-public] Definition of non-free for repo-reorg
by James Rayner 14 Jul '07

14 Jul '07

If we do separate "non-free" and "free" in the new repo layout, what will be the definition of "non-free"? Will anything closed source be non-free (acroread, nvidia)? or only things that have license/patent/distribution issues, like codecs? Will we just follow debian's definition and tests? James

10 20

[arch-dev-public] i686: missing packages
by Andreas Radke 13 Jul '07

13 Jul '07

==> Generating Text Package List... notice: Missing bluez-libs-3.12-1.pkg.tar.gz in ftp site notice: Missing fetchmail-6.3.8-3.pkg.tar.gz in ftp site notice: Missing xf86-input-joystick-1.2.2-1.pkg.tar.gz in ftp site notice: Missing xf86-video-nv-1.0.1.4-1.pkg.tar.gz in ftp site ANdyRTR

2 1

[arch-dev-public] kvm-modules package
by Thomas Bächler 13 Jul '07

13 Jul '07

With 2.6.22, we have had numerous reports that kvm locks up or doesn't load. On the other hand, according to Attila (http://bugs.archlinux.org/task/7598) we can use the kvm version shipped with 2.6.22. This would be easier and it is better tested than the one we build externally. Are there any reasons for keeping kvm-modules separately?

3 2

[arch-dev-public] GPL v3
by Dan McGee 12 Jul '07

12 Jul '07

Since some software we are going to package soon will be released under GPL v3 instead of GPL v2 or later, should we add this license as a separate one named "GPLv3" in the licenses package and begin using this in the license field? This seems like the easiest solution to me, rather than go back and change every occurrence of GPL to GPLv2. Thoughts? This isn't a very extreme change, but something that we need to consider and I didn't want to make the change without a bit of feedback first. -Dan

5 9