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

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

14 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 14 Mar '10

14 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 13 Mar '10

13 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

[arch-dev-public] [signoff] openssh 5.4p1-2
by Pierre Schmitz 13 Mar '10

13 Mar '10

So, it's me again. This time we should have an openssh package which fixes both of these bugs: http://bugs.archlinux.org/task/18611 http://bugs.archlinux.org/task/17138 Please sign-off, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

4 11

[arch-dev-public] [signoff] tzdata 2010e-1
by Andreas Radke 13 Mar '10

13 Mar '10

Time to change our timezones again... I skipped a few minor updates but now it's time for a new timezone pkg. Please signoff. -Andy The file... ftp://elsie.nci.nih.gov/pub/tzcode2010a.tar.gz ...is now available; this reflects the changes circulated last week on the time zone mailing list. Expect tzcode2010b.tar.gz in a week or two (to address the issues identified by kre last week). The files... ftp://elsie.nci.nih.gov/pub/tzcode2010c.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2010c.tar.gz ...are now available; these reflect the changes circulated last week on the time zone mailing list (including KRE's suggestion for earlier initialization of "goahead" and "goback" structure elements). I plan to do Samoa and Bangaladesh research this week. The file... ftp://elsie.nci.nih.gov/pub/tzdata2010d.tar.gz ...is now available; this reflects the changes circulated last week on the time zone mailing list. The file... ftp://elsie.nci.nih.gov/pub/tzdata2010e.tar.gz ...is now available; this corrects the Dhaka bug found by Danvin Ruangchan and reported on the time zone mailing list.

3 2

[arch-dev-public] [signoff] man-pages 3.24-1 (any)
by Andreas Radke 13 Mar '10

13 Mar '10

Minor update. Please signoff. -Andy http://linux-man-pages.blogspot.com/2010/02/man-pages-324-is-released.html * The addition of three pages by David Howells describing the kernel key management facility: add_key(2), request_key(2), and keyctl(2). (These pages were formerly part of the keyutils package.) * The fcntl(2) manual pages adds documention of F_SETOWN_EX and F_GETOWN_EX, which are new in Linux 2.6.32. * Minor changes to many other pages.

3 2

[arch-dev-public] [signoff] man-db 2.5.7-1
by Andreas Radke 13 Mar '10

13 Mar '10

- upstream update, see changes below - add nice/ionice support following the mlocate layout, #16518 - upstream changes should fix #17622 Please test and signoff. -Andy man-db 2.5.7 (16 February 2010) =============================== Major changes since man-db 2.5.6: Fixes: ------ o If a subprocess exits before man manages to read all the output from it, it now drains the output file descriptor rather than immediately discarding it. o If /usr/share/i18n/SUPPORTED is available, man attempts to use it to ensure that LC_CTYPE is set to an appropriate locale for the selected character set when invoking col. This fixes 'LANG=C man -E UTF-8', as used by lintian. o Don't run tests if cross-compiling. o Fix possible mandb crash when MAN_MUST_CREATE is unset. Improvements: ------------- o man can now tell nroff to disable justification if the --no-justification option is used. o If the full path to an executable is given as an argument, man will try looking up the corresponding manual page in the appropriate part of the manpath, rather than just trying to format the text of the executable as a manual page. o In the GNU manual hierarchy layout, search man<sec><ext> directories as well as just man<sec> (e.g. /usr/share/man/man3p as well as /usr/share/man/man3). o By request, man now prefers getting a page from the best manual section over getting a page in the correct language. o All programs now support a MAN_DEBUG environment variable which can be used in place of the -d/--debug option. This is useful in some situations where a program is being called deep in a process tree. o man-db now builds with heirloom-doctools, thanks to Diego Pettenò of Gentoo. o Add support for emulating pipe() with socketpair(), which is faster on some systems; thanks to Werner Fink of SUSE. o Cat pages are now always saved in UTF-8, and converted to the proper encoding at display time, which means that cat pages can now be saved regardless of locale. Note that a consequence of this is that cat pages now include formatting information (e.g. overstriking) and need to be run through col(1) before display.

3 2

[arch-dev-public] Integrity Check x86_64: core, extra, community 12-03-2010
by repomaint＠archlinux.org 12 Mar '10

12 Mar '10

================================================== = Integrity Check x86_64 of core,extra,community = ================================================== Performing integrity checks... ==> parsing pkgbuilds ==> parsing db files ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking hierarchy ==> checking for circular dependencies ==> checking for differences between db files and pkgbuilds Duplicate PKGBUILDs --------------------- /srv/abs/rsync/any/extra/namcap vs. /srv/abs/rsync/x86_64/extra/namcap Missing Dependencies ---------------------- community/airsnort --> 'wlan-ng26-utils' community/sysprof-module --> 'kernel26<2.6.' Missing Makedepends --------------------- core/dash --> 'klibc>=1.5' Repo Hierarchy for Dependencies --------------------------------- extra/pan depends on community/gmime22 (0 extra (make)deps to pull) Repo Hierarchy for Makedepends -------------------------------- core/ca-certificates depends on extra/ruby (25 extra (make)deps to pull) core/crda depends on extra/python-m2crypto (26 extra (make)deps to pull) core/e2fsprogs depends on extra/bc (0 extra (make)deps to pull) core/groff depends on extra/ghostscript (137 extra (make)deps to pull) core/groff depends on extra/netpbm (45 extra (make)deps to pull) core/groff depends on extra/psutils (138 extra (make)deps to pull) core/iputils depends on extra/docbook-xsl (26 extra (make)deps to pull) core/iputils depends on extra/libxslt (25 extra (make)deps to pull) core/iputils depends on extra/opensp (30 extra (make)deps to pull) core/sqlite3 depends on extra/tcl (0 extra (make)deps to pull) core/udev depends on extra/gobject-introspection (26 extra (make)deps to pull) core/udev depends on extra/gperf (0 extra (make)deps to pull) core/udev depends on extra/libxslt (25 extra (make)deps to pull) core/udev-compat depends on extra/gobject-introspection (26 extra (make)deps to pull) core/udev-compat depends on extra/gperf (0 extra (make)deps to pull) core/udev-compat depends on extra/libxslt (25 extra (make)deps to pull) extra/bigloo depends on community/jdk (1 extra (make)deps to pull : jre) extra/dbus-python depends on community/docutils (0 extra (make)deps to pull) extra/gnome-speech depends on community/espeak (2 extra (make)deps to pull : portaudio docutils) extra/grml-zsh-config depends on community/txt2tags (0 extra (make)deps to pull) extra/opengtl depends on community/llvm (0 extra (make)deps to pull) extra/xqf depends on community/chrpath (0 extra (make)deps to pull) Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 1 Invalid archs: 0 Missing (make)dependencies: 3 Repo hierarchy problems: 23 Circular dependencies: 0 In db, but not in tree: 0 In tree, but not in db: 0

1 0