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

[arch-dev-public] JaDa - Scale organization (LA Linux con)
by Travis Willard 08 Jan '08

08 Jan '08

Hey guys - JaDa just sent me an email wanting to help set us up for Scale - an LA Linux convention. AFAIK we don't currently have a presence there - does anyone live in/near LA and is interested on working with him to get us going with this con? ---------- Forwarded message ---------- From: JaDa <jada(a)usalug.net> Date: Dec 20, 2007 9:27 PM Subject: Question from JaDa To: travis(a)archlinux.org JaDa from Arch Linux Forums has sent you a message. You can reply to JaDa by replying to this e-mail. The message reads as follows: ----------------------------------------------------------------------- http://www.socallinuxexpo.org/scale6x/ 2007, I helped Gael Duval with his Ulteo at the Scale5x in Los Angeles In 2008, I like to help Archlinux :) Maybe you can tell me how I can contact to organize it or forward this email to the right person! http://my.opera.com/Jada0007/blog/2007/03/21/ulteo-scale-5x http://my.opera.com/Jada0007/blog/2007/03/24/linux-astronomy JaDa ----------------------------------------------------------------------- -- Arch Linux Forums Mailer

3 4

[arch-dev-public] [signoff] fuse 2.7.2-1
by Thomas Bächler 08 Jan '08

08 Jan '08

Rebuilt new version, moved more stuff to /bin to satisfy ntfs-3g's configure script and their warnings.

3 2

[arch-dev-public] New package group in extra: fprint
by Thomas Bächler 08 Jan '08

08 Jan '08

The fprint project (http://www.reactivated.net/fprint/wiki/Main_Page) has been around for about 3 months now and produced quite usable results. Right now, there are three packages: - libfprint A library that abstracts the tasks of enrolling and verifying fingerprints and includes hardware drivers. Currently only USB readers are supported and are accessed using libusb. There is no stable API yet, however the library is in a usable and stable state. Note that many common USB fingerprint readers and laptop builtin readers are supported, including the ones supported by the thinkfinger project! - fprint_demo This application demonstrates what libfprint can currently do. You can enroll fingerprints, verify your fingers or identify fingers from a set of enrolles prints. - pam_fprint This pam plugin allows authenticating with your fingerprint. It currently only checks your finger against the first enrolled print it can find in your $HOME and is not configurable. I am adding these packages to extra now.

3 3

[arch-dev-public] Removing 'dog' from extra
by Aaron Griffin 08 Jan '08

08 Jan '08

What is 'dog', you ask? I asked the same question. http://archlinux.org/packages/1933/ I can't seem to find the source anywhere. And it looks pretty lame. Any objections to removing it?

3 4

[arch-dev-public] libpano12 libpano13 move
by Tobias Kieslich 07 Jan '08

07 Jan '08

Hi, I just thought I would announce that, libpano12 which currently lives in /extra/multimedia found a successor called libpano13. Note, that the 12 and 13 is more like mpg123 rather than a version number. It is not like moving a new package into extra, but replacing an older one. Also I wanna move it to extra/lib since that seems better fitting. Objections? -T

2 1

Re: [arch-dev-public] [arch-commits] CVS update of core/support/netcfg (PKGBUILD)
by Dan McGee 06 Jan '08

06 Jan '08

On Jan 6, 2008 2:52 AM, James Rayner <james(a)archlinux.org> wrote: > Date: Sunday, January 6, 2008 @ 03:52:21 > Author: james > Path: /home/cvs-core/core/support/netcfg > > Modified: PKGBUILD (1.3 -> 1.4) > > upgpkg: netcfg 2.0.3-1 > > > ----------+ > PKGBUILD | 21 ++++++++++++++------- > 1 file changed, 14 insertions(+), 7 deletions(-) > > > Index: core/support/netcfg/PKGBUILD > diff -u core/support/netcfg/PKGBUILD:1.3 core/support/netcfg/PKGBUILD:1.4 > --- core/support/netcfg/PKGBUILD:1.3 Mon Nov 19 06:53:56 2007 > +++ core/support/netcfg/PKGBUILD Sun Jan 6 03:52:20 2008 > @@ -1,15 +1,15 @@ > -# $Id: PKGBUILD,v 1.3 2007/11/19 11:53:56 james Exp $ > +# $Id: PKGBUILD,v 1.4 2008/01/06 08:52:20 james Exp $ > # Maintainer: James Rayner <james(a)archlinux.org> > pkgname=netcfg > -pkgver=2.0.1 > +pkgver=2.0.3 > pkgrel=1 > -pkgdesc="New network configuration scripts" > +pkgdesc="Network configuration and profile scripts" > url="http://archlinux.org" > license=("BSD") > backup=(etc/iftab) > -depends=(wireless_tools wpa_supplicant net-tools) > -source=(http://archlinux.org/~james/netcfg/netcfg-$pkgver.tar.gz) > - > +depends=(wireless_tools wpa_supplicant net-tools mktemp) > +source=(http://dev.archlinux.org/~james/netcfg/netcfg-$pkgver.tar.gz) Can we get an FTP directory for this source (other/netcfg)? -Dan

2 1

[arch-dev-public] [signoff] fakeroot 1.8.10-2
by Thomas Bächler 06 Jan '08

06 Jan '08

This version fixes the fakeroot/acl/makepkg bug when using cp -a on directories. For details, see http://bugs.archlinux.org/task/8214#comment22826

3 6

Re: [arch-dev-public] [aur-general] Inactive for unspecified period of time
by Roman Kyrylych 05 Jan '08

05 Jan '08

2007/12/31, Roman Kyrylych <roman.kyrylych(a)gmail.com>: > 2007/12/18, JJDaNiMoTh <jjdanimoth(a)gmail.com>: > > On Tue, 18 Dec 2007 20:15:03 +0200 > > "Roman Kyrylych" <roman.kyrylych(a)gmail.com> wrote: > > > > > Hi all! > > > > > > I have <1 minute to write this email, so I'll be quick. > > > > > > I'm very sorry about my disappearance. > > > My connection at job got down during Bug Day this Saturday and I got cable > > > breakage somewhere on my street so I got no Internet at home as well. > > > :-( > > > The worst thing is that I am unable to follow Arch development until > > > New Year (at least) because I've changed my job this Monday, and I > > > don't even have a PC there yet (but I should in near future). > > > Today is the first day I've got internet for a hour or so (I'm sitting > > > at my ex-job now). > > > > > > If someone could update my packages in Extra/Community and keep an eye > > > on bugtracker - that would be awesome and very appreciated. > > > > > > Bye all and Merry Christmas! > > > > > > -- > > > Roman Kyrylych (Роман Кирилич) > > > > Good luck, I will see you soon. > > > > Don't worry about packages and [community] section of flyspray. > > > > Merry Christmas and happy new year, Roman! > > > > P.S. I can't imagine a Bug Day without you :D > > > I've got a couple hours of internet today, so I thought I should write > a quick update. > > First, thank you all! I don't imagine what would I do without the > support from Arch community. > I'm waiting for time when I can come back to work (on Arch, obviously > :-)), I miss that so much. > > Next, a status update: > * still no laptop at job (should get it next month, I think) and still > very busy there > * still no internet at home (long to explain why), hope to get it > somewhere next week > > I wish you all Happy New Year (in advance because I won't be able to > do so when it comes) and hope to see you soon. :-) And another update before Christmas. (yes, you've read it right - we have it on 7th of January here, read http://en.wikipedia.org/wiki/Christmas_worldwide#Ukraine for more) 1) I've quit my new job yesterday. :-D (after working only 2 weeks there :-P) 2) I've got the internet connection at home yesterday! :-) Yay, a good start of the new year! Now I have no money/job and plenty of time. :-) So I'll be back to activity on 9-10th this month. -- Roman Kyrylych (Роман Кирилич)

2 1

[arch-dev-public] dependency rebuilds
by Paul Mattal 05 Jan '08

05 Jan '08

When package y depends on package x and package x is updated, there are essentially two clean ways to divide up responsibility for rebuilding dependent package(s) y: 1) the package y maintainer(s) notices package x in testing and rebuilds package y 2) the package x maintainer(s) is responsible to find all packages y and rebuilds all such packages y against the new package x I've seen many variations on how this gets handled over the last three or four years as a a developer, and we usually just try to do what makes things best for most people, but it's good to have some idea what to expect in general. We all want to do what's best for the most people, but it's not always clear what that is. A merit of #1 is that the actual maintainers of the dependent packages, who can sanity check and test the new dependency, are involved in making sure the packages get built and function correctly against the new version of dependent software. A downside is that this is likely to take some time-- the dependent package maintainers need to notice the dependency update, have time, and do the update properly. A merit of #2 is that the updates get done quickly. A disadvantage is that they may not be done correctly, possibly even introducing uncaught security holes or result in data loss. Another disadvantage is that for really core low-level packages (like glibc or even something like sqlite), the number of rebuilds is potentially huge and the likelihood of getting things wrong is even larger, and it will be increasingly hard to get people to agree to maintain those low-level packages because of the amount of work involved. How have people generally been approaching this issue and with what rationale? As a starting point, in absence of other communication, I generally expect developers to rebuild and test their own packages when their dependencies are upgraded, but perhaps I'm in the minority. I think we should be sensitive to the general number and kind of dependencies we have on packages we maintain, and make sure to put those things into testing to give other developers lots of time to rebuild and test against them, but not assume we each have sufficient knowledge and experience to rebuild any of the potentially vast spectrum of dependent packages with any reasonable certainty they will work. - P

7 11

[arch-dev-public] netfs daemon script failing on shutdown
by Dan McGee 05 Jan '08

05 Jan '08

I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue. -Dan

5 7