- Arch-general - lists.archlinux.org

[arch-general] hwd & lshwd
by Grigorios Bouzakis 01 Dec '08

01 Dec '08

Does the latest version of hwd, make lshwd obsolete? lshwd returns no results conserning modules here while hwd works great. I dont remember exactly how it used to work in the past, hadnt used it much, but now it returns kernel modules too. Didnt lshwd take care of that part before? Greg

1 0

Re: [arch-general] [arch-dev-public] Can we trust our mirrors?
by Gerhard Brauer 30 Nov '08

30 Nov '08

Am Sat, 29 Nov 2008 15:00:20 +0100 schrieb Thomas Bächler <thomas(a)archlinux.org>: > Pierre Schmitz schrieb: > > The simplest solution would be if we sign the db files > > (automatically) on gerolde. Of course this is less secure than > > signing every single package by its packager; but on the other side > > it would be easy to implement and there would be no overhead for > > packagers. > > If this is to provide any security, we need to stop using md5! md5 is > okay when trying to detect corrupted downloads, however it is > possible to find collisions and thus build a "bad" package that has > the same md5 as the good package. For myself i don't accept the "md5sum is bad" argument as a "stopper" for each idea to provide a pacman secure concept ;-) Current situation is: Everyone who offers a mirror could provide a manipulated pacman or bash package. He could reduce the content of a binaray to a simple rm -rf, fdisk or something. He only has to tar "his" package and edit the core.db.tar,gz If we sign our db files as a minimum! security: This would make package manipulating more difficult. Content changes of pacman or bash packages (*.pkg.tar.gz) with getting the same md5sum or sha checksum is surely not impossible - but much more difficult as in our current situation. So let's mak a first step! Gerhard >

8 15

[arch-general] dmapi build failure
by Baho Utot 30 Nov '08

30 Nov '08

The abs build fails with the following: === build === make[2]: Nothing to be done for `install'. ./install-sh -o root -g root -m 755 -d /home/scrat/CORE/dmapi/pkg/usr//share/doc/dmapi ./install-sh -o root -g root -m 644 README /home/scrat/CORE/dmapi/pkg/usr//share/doc/dmapi make[1]: *** No rule to make target `install-lib'. Stop. make[1]: Leaving directory `/home/scrat/CORE/dmapi/src/dmapi-2.2.8' I have made a patch to fix this # #PKGBUILD.patch # --- PKGBUILD~ 2008-11-28 09:39:31.817672035 -0500 +++ PKGBUILD 2008-11-30 08:18:47.876723158 -0500 @@ -23,7 +23,7 @@ autoconf ./configure --prefix=$startdir/pkg/usr make || return 1 - make prefix=$startdir/pkg/usr/ install install-lib install-dev + make prefix=$startdir/pkg/usr/ install install-dev # the static lib install -D -m644 libdm/.libs/libdm.a $startdir/pkg/usr/lib/libdm.a # and the header file, please

1 0

Re: [arch-general] [arch-dev-public] RFC: crda PKBUILD
by Sujith 30 Nov '08

30 Nov '08

Thomas B,bd(Bchler wrote: > Aaron Griffin schrieb: > > Couldn't we set it as a dep of the wireless tools? That seems like it > > would install for the right people then. Considering you want to shut > > things off in the kernel, this will make some (most? no idea) wireless > > non-functional without this, right? It seems an optdepend of kernel26 > > would be easy to miss To set a new regulatory domain, 'iw' is required. 'iw' should be added to core too. > I think I remember that the wireless stack will fall back to a default > (minimal) set of channels if crda is missing (which is not too different > from the current behaviour). That's right, WORLD regulatory domain would be chosen if CRDA is missing. But it has a limited set of channels than what people were using so far, so expect a rash of 'wireless not working' bugs. :) The best method to accommodate the new regulatory infrastructure would be to set the country code on bootup, with the user's choice stored in /etc/rc.conf. Sujith -- http://sujith-m.blogspot.com

2 3

[arch-general] kDE 3.5.9
by Baho Utot 30 Nov '08

30 Nov '08

Is there a way to get the abs build files for kde 3.5.9? Is the svn repos tagged at 3.5.9 ? If so how? I would like to build them for a new computer of mine that has an old graphocs card and cpu.

4 4

[arch-general] [signoff] kernel26 2.6.27.7-1
by Tobias Powalowski 29 Nov '08

29 Nov '08

Hi guys, new kernel adresses the following things: - bump to latest version please signoff for both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

Re: [arch-general] [arch-dev-public] pkgstats and repo cleanup
by Grigorios Bouzakis 29 Nov '08

29 Nov '08

On Sat, Nov 29, 2008 at 8:16 AM, Allan McRae <allan.mcrae(a)qimr.edu.au> wrote: > Hi devs, > > I have created a table of candidates for removal from the extra repo based > on <1% usage in the pkgstats results. I have gone through and flagged for > keeping packages which are i18n, makedepends, or otherwise needed (in pacman > testsuite, using on gerolde). See the list here: > http://wiki.archlinux.org/index.php/User:Allan/Extra_Repo_and_Pkgstats > > There is probably other categories of packages we should keep (e.g drivers) > and there are some fonts which might be considered i18n related so can you > all go through the list a cross out the ones to be kept and giving the > reason. > > In a couple of weeks time I will remove all the orphaned packages remaining > on that list and contact the maintainers of the rest so they can decide what > to do with their packages. > > Cheers, > Allan Hi Alan, Can i give some other extend to this? I can understand why you limit the list to only packages with 0.xy usage, but i think theres much more to cleanup than just those packages. Orphan or not.. Just by looking at the statistics, for which we owe a huge thanks to Pierre, its obvious that more than 50% of the packages in extra have 10% or less usage. Most of which are below 5%. While at the same time there are many packages in community with >10%. Those should definately go in extra. Most of the developers use em too. Also , many packages in extra, some of which are long unmaintained upstream, many multimedia & games packages come to mind but not limited to these. Those could go to community and even be left unmaintained with a small portion of good will. Anyway, all i am saying is dont focus only on packages having 0.xy usage. Greg

2 1

[arch-general] Custom repository
by Baho Utot 29 Nov '08

29 Nov '08

I created a custom package repository to hold arch packages compiled locally. I compile a newer package from abs then I have on the current system and it is placed into my custom repos. I issue a pacman -Syu will pacman get the package from arch or will it install from my custom repository? Thanks

7 7

Re: [arch-general] Custom repository
by Loui Chang 28 Nov '08

28 Nov '08

On Sat, Nov 29, 2008 at 12:31:05AM +1000, Allan McRae wrote: > Loui Chang wrote: > > On Fri, Nov 28, 2008 at 09:13:55AM -0500, Baho Utot wrote: > > > >> I created a custom package repository to hold arch packages compiled > >> locally. I compile a newer package from abs then I have on the current > >> system and it is placed into my custom repos. > >> > >> I issue a pacman -Syu will pacman get the package from arch or will it > >> install from my custom repository? > > > > It will install from the repo with the newest version. > > Not really... it will install the package from the repo which comes first > in you pacman.conf. Ah that is right. Doh! That phenomenon is just a coincidence for me.

1 0

Re: [arch-general] [arch-dev-public] Away for Holidays
by Dieter Plaetinck 27 Nov '08

27 Nov '08

Aaron Griffin wrote: > Hey all, > It's Thanksgiving here in the US. I will be away at my parents' house > all day, and am going camping on Friday. I won't be at a computer > until Saturday. > > Cheers, > Aaron > Have fun and don't forget to mention the Arch community! :-) (At thanksgiving the tradition is to say what you're thankful for right, or is that only in the movies?) Dieter

1 0