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

[arch-dev-public] [signoff] dmraid-1.0.0rc16-3
by Tobias Powalowski 18 Mar '10

18 Mar '10

HI, readded static dmraid again to fix: http://bugs.archlinux.org/task/18348 please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] keep config file on system when upgrading to package without the config file
by Ronald van Haren 17 Mar '10

17 Mar '10

Hey guys, Yesterday I upgraded grub2 and changed some config file handling. Previously an example file /boot/grub/grub.cfg was installed by the PKGBUILD, which should not happen anymore as it can be created by some included config script autmotically (there are some patches on the bug tracker posted today which should allow for an even better streamlined autogenerated config). Obviously we can only run this script post-install or let the user take care of it. So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ? Ronald

5 13

[arch-dev-public] Fwd: lirc patch
by Tobias Powalowski 16 Mar '10

16 Mar '10

---------- Weitergeleitete Nachricht ---------- Betreff: lirc patch Datum: Dienstag 16 März 2010, 16:49:28 Von: Andrew Brouwers <abrouwers(a)gmail.com> An: tpowa(a)archlinux.org Greetings, Just browsing the mailing list at work (sorry, can't test at the moment), but the lirc patch for 2.6.33 seems to be available upstream, since the RC period for 2.6.33: http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/drivers/lirc_dev/lirc_dev.… Gentoo has a bug about this, which reports some success: http://bugs.gentoo.org/301321 Perhaps this can help get lirc ready for 2.6.33. Hope this helps - sorry to spam if not :) Andrew ------------------------------------------------------------- -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] [signoff] kernel26 2.6.32.10-1
by Thomas Bächler 16 Mar '10

16 Mar '10

Packages are NOT in testing (as 2.6.33 is there), but available from http://dev.archlinux.org/~thomas/kernel26/ Please sign off.

4 9

[arch-dev-public] [signoff] libarchive 2.8.3-1
by Dan McGee 15 Mar '10

15 Mar '10

Upstream update, minor fixes. Signoff both arches. -Dan

3 2

[arch-dev-public] Fwd: Amarok 2.3 packages
by Tobias Powalowski 15 Mar '10

15 Mar '10

---------- Weitergeleitete Nachricht ---------- Betreff: Amarok 2.3 packages Datum: Sonntag 14 März 2010, 21:58:48 Von: Lydia Pintscher <lydia(a)kde.org> An: tpowa(a)archlinux.org Hi, I've just seen that Arch already has packages for Amarok 2.3 since yesterday. That's not really cool :( Please wait until the day I announced on the packagers list (tomorrow this time) unless you're really not able to do it that date. Cheers Lydia -- Lydia Pintscher Amarok community manager kde.org - amarok.kde.org - kubuntu.org claimid.com/nightrose ------------------------------------------------------------- -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] bugs: measuring progress
by Paul Mattal 15 Mar '10

15 Mar '10

Now many months into our regular bug squashing cycle, it occurred to me today to evaluate our progress. Summary: We're making excellent progress! Here's the number of open bugs in Arch Linux (packages) on bug day, November through March (as determined from the Bug Day TODO page in the wiki): Nov 2009 - 536 Dec 2009 - 495 Jan 2010 - 540 Feb 2010 - 504 Mar 2010 - 381 I wanted to thank everyone who's doing hard work to make this possible. This includes not just all the devs who have stepped up to the plate, but so many community members who have contributed time and useful information that have led to the resolving of issues. Anecdotally, I can also say that in the process, we've closed several bugs that I've recalled having experienced for years (but usually could not explain). The result is a better Arch experience for us all. So a thank you for all your work, and we'll see you next month! - P

2 1

[arch-dev-public] improving signoffs
by Paul Mattal 14 Mar '10

14 Mar '10

There's a confluence of circumstances that occurs regularly now that is wasting lots of time for those trying to squash bugs: 1) It's really hard to get signoffs for core packages. It usually takes at least a week, and an extra bump, and coaxing. The process isn't fire-and-forget, so I have to spend time each day thinking about packages I currently have awaiting signoffs and what has happened to them and whether or not I need to take some action. 2) Signoff threads are hijacked for a general discussion about the package. This is annoying because it happens AFTER the developer has done all the work teeing up the new package, testing it himself on both environments, writing up the signoff, doing the coaxing, watching the signoff thread. Once the thread is hijacked, it becomes even more difficult for those who would sign off to figure out the state of the signoff. All this has the effect of filibustering progress in core and discouraging people from doing work on core packages. There are a number of potential solutions to this problem-- perhaps some of you will think of others. Here are two that come to mind: 1) Get a web signoff mechanism to really work for us. We'd have to evaluate why the previous web mechanism wasn't embraced and solve the problems with it. This would require some more work in archweb, which I could probably do if we thought it was the right approach. 2) A pre-signoff thread for each signoff. You run this thread before you do any packaging work, so that if someone wants to discuss other things about the package and suggest other modifications, they do it without causing you a whole lot of extra work. We then agree not to hijack signoff threads for unrelated aspects of the package-- rather, we start other threads or open new bug reports. What do others think? Any other ideas for how to handle this? - P

3 3

[arch-dev-public] [signoff] vi-050325-3 (1 for each arch)
by Paul Mattal 13 Mar '10

13 Mar '10

Please signoff 1 for each arch. This is just packaging cleanup, and should have no subtantive impact on the functioning of vi. Mostly just looking for an extra sanity check here, nothing specific to test. See FS#18215 for details. Highlights: * removed obsolete gcc bug workaround portion of du.patch, renamed to navkeys.patch * used make options rather than manual means of configuration wherever possible - P

5 7

[arch-dev-public] Allow comments on closed bugs?
by Aaron Griffin 13 Mar '10

13 Mar '10

Does anyone have an opinion on this? In my eyes, I imagine the kind of people who want this feature simply wish to argue about the closing. I've had to deal with enough PM requests in the past to know that this _does_ happen. Opinions?

10 10