[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 8 fully signed off packages * 18 packages missing signoffs * 8 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (2 total) == * s-nail-14.5.2-4 (i686) * s-nail-14.5.2-4 (x86_64) == Incomplete signoffs for [core] (1 total) == * s-nail-14.5.2-4 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (17 total) == * ardour-3.5.308-2 (i686) 0/1 signoffs * dssi-1.1.1-7 (i686) 0/1 signoffs * ecasound-2.9.1-2 (i686) 0/1 signoffs * elfutils-0.158-1 (i686) 0/1 signoffs * liblo-1:0.28-1 (i686) 0/1 signoffs * lirc-1:0.9.0-70 (i686) 0/1 signoffs * nvidia-331.38-3 (i686) 0/1 signoffs * nvidia-304xx-304.117-5 (i686) 0/1 signoffs * rosegarden-13.10-2 (i686) 0/1 signoffs * ardour-3.5.308-2 (x86_64) 0/2 signoffs * dssi-1.1.1-7 (x86_64) 0/2 signoffs * ecasound-2.9.1-2 (x86_64) 0/2 signoffs * elfutils-0.158-1 (x86_64) 0/2 signoffs * liblo-1:0.28-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-70 (x86_64) 0/2 signoffs * nvidia-304xx-304.117-5 (x86_64) 0/2 signoffs * rosegarden-13.10-2 (x86_64) 0/2 signoffs == Completed signoffs (8 total) == * libtirpc-0.2.4-1 (i686) * linux-3.13.2-1 (i686) * s-nail-14.5.2-4 (i686) * systemd-208-11 (i686) * libtirpc-0.2.4-1 (x86_64) * linux-3.13.2-1 (x86_64) * systemd-208-11 (x86_64) * nvidia-331.38-3 (x86_64) == All packages in [testing] for more than 14 days (8 total) == * libtirpc-0.2.4-1 (i686), since 2013-12-28 * libtirpc-0.2.4-1 (x86_64), since 2013-12-28 * lirc-1:0.9.0-70 (i686), since 2014-01-26 * lirc-1:0.9.0-70 (x86_64), since 2014-01-26 * nvidia-331.38-3 (i686), since 2014-01-26 * nvidia-331.38-3 (x86_64), since 2014-01-26 * nvidia-304xx-304.117-5 (i686), since 2014-01-26 * nvidia-304xx-304.117-5 (x86_64), since 2014-01-26 == Top five in signoffs in last 24 hours == 1. allan - 3 signoffs 2. heftig - 2 signoffs 3. bisson - 2 signoffs 4. pierre - 1 signoffs
Re: [arch-dev-public] Moving packages into community
On 02/11/2014 02:37 AM, Sébastien Luttringer wrote: - Send a message on aur-gene...@al.org - Write some lines in the AUR package comments I usually write a message directly to package maintainer, asking if he see any problems deterring the package from inclusion. I really don't see why I should forward/CC it to aur-general, especially when requirements listed on the wiki are met. - Open a BR for inclusion Unnecessary procedure bringing only noise to the bugtracker and overcomplicating simple task. - Test his modification I guess this is what most TUs do anyway before they push packages to repositories. - Start his communication with upstream Makes sense only if software is problematic or upstream provides own PKGBUILD. - Request some feedback. You can subscribe to arch-commits and forward your feedback to arch-dev-public or request it directly here. So, fellow TU, could you verify, before moving a package from AUR to community, that it is not already in *and* not already in process of being included. Address your issues to TU who modified your package. I can only speak for myself, but it's clear to me that I'm late to the party if PKGBUILD is already in svn. -- Bartłomiej Piotrowski http://bpiotrowski.pl/ signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Moving packages into community
On 11/02/2014 14:39, Bartłomiej Piotrowski wrote: On 02/11/2014 02:37 AM, Sébastien Luttringer wrote: - Send a message on aur-gene...@al.org - Write some lines in the AUR package comments - Open a BR for inclusion - Push his new package to community This is a short list of well known places where you can find hints that someone is already working on moving your package. I did *not* suggest that you should do one of the previous examples. I'm not telling you to open a BR before moving a package. I'm too lazy. But if you move a package, it's a good idea to check if there is bug report opened (or closed) about it. Like a feature request[1]. - Test his modification - Start his communication with upstream - Request some feedback. All these bullets was to justify, that sometimes, you need more time than usual before pushing the binary package. That why we should check the previous places before inclusion. Address your issues to TU who modified your package. Be sure that was the first thing I have done. However that's not the first time I see this happening during the inclusion process, that motivated me to share this point on the list and add this obvious recommendation in our guidelines. Cheers, [1] https://bugs.archlinux.org/task/38698 -- Sébastien Seblu Luttringer https://seblu.net GPG: 0x2072D77A
[arch-dev-public] Upgrading to ntp-dev
Hi all, The ntp-stable branch last saw a release in 2011. If there are no objections, I'll switch our ntp package to the ntp-dev branch, where all development effort (new features, bug fixes) has happened since. Upstream considers ntp-dev semi-stable (with unstable being the daily snapshots). What prompted me to do this is the recent ntp-based DoS [1]; it's currently only fixed in ntp-dev [2] although we are currently fine with the default ntp.conf shipped in our package because of the noquery option. [1] http://www.bbc.co.uk/news/technology-26136774 [2] http://support.ntp.org/bin/view/Main/SecurityNotice#DRDoS_Amplification_Attack_usin Comments welcome. -- Gaetan
[arch-dev-public] clearing the [testing] repo
I was looking at what needed signed off in [testing] and noticed it was fairly empty. It is always good to do a complete clear out of the [testing] repo from time to time and now seemed reasonable... So here is a summary of what is currently in [testing]. lone package updates: elfutils (why?) libtirpc (been in [testing] a long time...) python (why?) liblo rebuild (been there a while - is there an issue?): ardour dssi ecasound liblo rosegarden linux update: linux linux-docs linux-headers lirc lirc-utils nvidia nvidia-304xx I care little about the [community-testing] repo, so a TU might want to look to see if there is any package rotting away in there. Allan
Re: [arch-dev-public] clearing the [testing] repo
On Wednesday, February 12, 2014 16:34:46 Allan McRae wrote: python (why?) I guess Ángel updated it last night but didn't have time to test it. Anyway it works for me, signed off x86_64. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Moving packages into community
On 12 February 2014 03:57, Sébastien Luttringer se...@seblu.net wrote: On 11/02/2014 14:39, Bartłomiej Piotrowski wrote: On 02/11/2014 02:37 AM, Sébastien Luttringer wrote: - Send a message on aur-gene...@al.org - Write some lines in the AUR package comments - Open a BR for inclusion - Push his new package to community This is a short list of well known places where you can find hints that someone is already working on moving your package. I did *not* suggest that you should do one of the previous examples. I'm not telling you to open a BR before moving a package. I'm too lazy. But if you move a package, it's a good idea to check if there is bug report opened (or closed) about it. Like a feature request[1]. - Test his modification - Start his communication with upstream - Request some feedback. All these bullets was to justify, that sometimes, you need more time than usual before pushing the binary package. That why we should check the previous places before inclusion. Address your issues to TU who modified your package. Be sure that was the first thing I have done. However that's not the first time I see this happening during the inclusion process, that motivated me to share this point on the list and add this obvious recommendation in our guidelines. Agree on all points, and have updated the wiki edit to make the suggestions clearer: https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelinesdiff=296958oldid=296802 -- GPG/PGP ID: C0711BF1
Re: [arch-dev-public] clearing the [testing] repo
On 12 February 2014 14:34, Allan McRae al...@archlinux.org wrote: liblo rebuild (been there a while - is there an issue?): ardour dssi ecasound liblo rosegarden I rarely receive any signoffs for such niche packages so I allow them some time in [testing]. Moved now. -- GPG/PGP ID: C0711BF1
Re: [arch-dev-public] clearing the [testing] repo
[2014-02-12 15:17:16 +0800] Ray Rashif: On 12 February 2014 14:34, Allan McRae al...@archlinux.org wrote: liblo rebuild (been there a while - is there an issue?): ardour dssi ecasound liblo rosegarden I rarely receive any signoffs for such niche packages I always filter out anything not destined to [core] from the signoff page (so I won't signoff on [extra]/[community] packages even if I did try the new version) and believe other devs do the same. -- Gaetan
