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

[arch-dev-public] [signoff] nfs-utils-1.2.1-3
by Tobias Powalowski 12 Jan '10

12 Jan '10

Hi fixes 3 bugs: http://bugs.archlinux.org/task/15775 http://bugs.archlinux.org/task/17738 http://bugs.archlinux.org/task/15953 Please signoff both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4

[arch-dev-public] OS News interview
by Allan McRae 11 Jan '10

11 Jan '10

The OS News interview is up: http://www.osnews.com/story/22692/Arch_Linux_Team

2 1

Re: [arch-dev-public] [signoff] dcron 4.2
by Paul Mattal 11 Jan '10

11 Jan '10

[I'm reposting this to arch-dev-public on Jim's behalf. -P] I agree our general convention is not to put /etc/rc.d scripts in our backups arrays, but it seems that doing so has no effect if you don't modify them and has a potentially-work-saving effect in case you do and forget. If others feel strongly, I'll remove it from backup, but don't see much harm in having it there. - P On Mon, Jan 11, 2010 at 11:36:55AM -0500, Eric Bélanger wrote: > On Mon, Jan 11, 2010 at 8:06 AM, Paul Mattal <paul(a)mattal.com> wrote: > > On 01/06/2010 01:09 AM, Paul Mattal wrote: > > I've just placed dcron 4.2 into [testing]. This is a major update to dcron, > > under a new maintainer (who is an Arch user, and very responsive). With this > > release, I am also taking over maintaining dcron in [core]. > > Why did you put etc/rc.d/crond in the backup array? These daemon > scripts are not intended to be modified by the user. If you want them > to be able to pass different options, you should use a > /etc/conf.d/crond config file. Hi Eric, I did that in a proposed PKGBUILD I sent to Paul. It'll be up to him how to package this, but this prompts a more general question I have. Granted that daemon scripts are not supposed to be modified by the ordinary user; the /etc/conf.d mechanism is the usual way to supply arguments to the daemon scripts. However, it's one thing to say "not usually supposed to be user-modified" and slightly different to say "overwrites user mods without notice." I find myself tweaking a few /etc/rc.d scripts now and then. I know there's an existing mechanism to protect such changes: NoUpgrade in /etc/pacman.conf. But I wondered why more PKGBUILDs didn't just add the daemons to the backup array. So the question is: should we think of it as _policy_ that rc.d scripts don't go in backup array, and should instead always be explicitly protected by the user if user wants to mod? No problem if so, it's actually helpful to know there's an explicit policy to always do it the one way or always do it the other way. As to dcron 4.2, I've already gotten some feedback. Thanks. I'll release a new version shortly, but do keep feedback coming. -- Jim Pryor profjim(a)jimpryor.net

1 0

[arch-dev-public] iodbc Vs unixodbc, are they compatible?
by Andrea Scarpino 11 Jan '10

11 Jan '10

Hi DEVs, me and Pierre are building KDE 4.4 packages, but to provide the soprano virtuoso backend we need the iODBC driver that conflicts with unixODBC. The unixODBC in [extra] is required by 9 packages. We don't know if these two drivers are API compatible, so there is anyone that knows if we can replace unixodbc with iodbc? If they are, we could add provides=('odbc') or 'odbc-driver' to both PKGBUILDs. Thanks -- Andrea `bash` Scarpino Arch Linux Developer

2 4

[arch-dev-public] Cron Plan
by Paul Mattal 11 Jan '10

11 Jan '10

Having now learned more about cron and its many flavors than I probably ever wanted to know, I am prepared to suggest a course of action. I've picked up maintenance of dcron from tpowa, and am prepared to move forward. If we can reach agreement, I'll do the work. I understand there was a previous decision made to move to fcron. However, yacron (a slightly-less-minimal dcron fork) was known and considered at the time, so it makes sense to consider it now. In the last few days, the yacron author, Jim Pryor, has been blessed by Matt Dillon as the new dcron maintainer, thus unforking: http://apollo.backplane.com/FreeSrc/ http://www.jimpryor.net/linux/yacron.html This new yacron/dcron 4.0 option is pretty attractive. advantages: * simple, small, mature, designed with security in mind * maintained by an Arch user * familiar/standard crontab format * supports anacron-type behaviors * supports /etc/cron.d (more effectively than fcron) * can log to syslog disadvantages: * may not provide all the advanced/anacron-type behavior fcron does * not all of the newly-merged code changes are widely tested Proposal: We stay with dcron into the 4.0 series, with a longer-than-usual testing window so the transition is smooth, and see if it meets our collective needs. Jim may be willing to add functionality we find lacking. Please get your votes and comments in by the weekend, if possible. I'd like to move on this next week, if we have agreement. Thanks! - P

4 5

[arch-dev-public] [signoff] kernel26-lts-2.6.27.43-1 & kernel26-lts-headers-2.6.27.43-1
by Tobias Powalowski 10 Jan '10

10 Jan '10

Hi guys, latest bugfix release. Please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] rfkill package
by Thomas Bächler 10 Jan '10

10 Jan '10

I noticed that the rfkill package is in community now (very good). However, I have been asked if it was possible to make a few improvements: 1) Add a rfkill group (or use an existing group) and allow that group to write /dev/rfkill using udev (if we add a group, we should do that in the filesystem package, not the rfkill package). Apparently, some desktop applications would like to set the rfkill state, so this way we could allow that. 2) Add an init script that can optionally unblock wifi, bluetooth or anything else on boot. In the past, some devices were soft-blocked on boot by default (is this still an issue?), so this could be improved. Maybe we should even move this to extra or even core. Giovanni, this seems to be your package, what do you think?

3 2

Re: [arch-dev-public] [announcement] qemu/qemu-kvm announcement draft
by Tobias Powalowski 09 Jan '10

09 Jan '10

Hi, since qemu/qemu-kvm 0.12.x kqemu is no longer supported. kqemu package is removed from the repositories, if you still need kqemu support please compile 0.11 series and kqemu module yourself. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 6

[arch-dev-public] [signoff] kernel 2.6.32.3-1
by Tobias Powalowski 09 Jan '10

09 Jan '10

Hi guys, bump to latest bugfix version. Arch Linux bugfixes/feature requests: http://bugs.archlinux.org/task/17538 # added blktrace http://bugs.archlinux.org/task/17106 # finally added CONFIG_MMIOTRACE http://bugs.archlinux.org/task/17696 # fixed intel wireless http://bugs.archlinux.org/task/17687 # fixed rt61 wireless http://bugs.archlinux.org/task/17661 # remove created initramfs on deinstall Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 8

[arch-dev-public] x264/ffmpeg rebuilds
by Allan McRae 09 Jan '10

09 Jan '10

Hi, There has been a TODO list waiting for x264/ffmpeg rebuilds for quite some time now. How about we attack these after the boost builds move? Anyone want to prepare these builds so we can get the soname changes and make a complete rebuild list? Allan

6 15