[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 110 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 9 fully signed off packages * 125 packages missing signoffs * 7 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 (110 total) == * ding-libs-0.4.0-3 (i686) * kmod-20-1 (i686) * ding-libs-0.4.0-3 (x86_64) * kmod-20-1 (x86_64) * exo-0.10.3-2 (i686) * garcon-0.4.0-1 (i686) * gtk-xfce-engine-2.10.0-1 (i686) * libxfce4ui-4.12.0-1 (i686) * libxfce4util-4.12.1-1 (i686) * libxfcegui4-4.10.0-4 (i686) * nvidia- (i686) * nvidia-304xx-304.125-11 (i686) * nvidia-340xx-340.76-4 (i686) * orage-4.10.0-2 (i686) * thunar-1.6.6-1 (i686) * thunar-archive-plugin-0.3.1-5 (i686) * thunar-media-tags-plugin-0.2.1-2 (i686) * thunar-volman-0.8.1-1 (i686) * xfburn-0.5.2-2 (i686) * xfce4-appfinder-4.12.0-1 (i686) * xfce4-battery-plugin-1.0.5-4 (i686) * xfce4-clipman-plugin-1.2.6-2 (i686) * xfce4-cpufreq-plugin-1.1.1-2 (i686) * xfce4-cpugraph-plugin-1.0.5-3 (i686) * xfce4-datetime-plugin-0.6.2-4 (i686) * xfce4-dev-tools-4.12.0-1 (i686) * xfce4-dict-0.7.0-2 (i686) * xfce4-diskperf-plugin-2.5.4-3 (i686) * xfce4-eyes-plugin-4.4.3-2 (i686) * xfce4-fsguard-plugin-1.0.1-4 (i686) * xfce4-genmon-plugin-3.4.0-3 (i686) * xfce4-mailwatch-plugin-1.2.0-5 (i686) * xfce4-mixer-4.11.0-2 (i686) * xfce4-mount-plugin-0.6.7-3 (i686) * xfce4-mpc-plugin-0.4.4-4 (i686) * xfce4-netload-plugin-1.2.4-2 (i686) * xfce4-notes-plugin-1.7.7-7 (i686) * xfce4-notifyd-0.2.4-2 (i686) * xfce4-panel-4.12.0-1 (i686) * xfce4-power-manager-1.4.3-1 (i686) * xfce4-quicklauncher-plugin-1.9.4-10 (i686) * xfce4-screenshooter-1.8.2-2 (i686) * xfce4-sensors-plugin-1.2.6-2 (i686) * xfce4-session-4.12.0-2 (i686) * xfce4-settings-4.12.0-1 (i686) * xfce4-smartbookmark-plugin-0.4.5-3 (i686) * xfce4-systemload-plugin-1.1.2-2 (i686) * xfce4-terminal-0.6.3-2 (i686) * xfce4-time-out-plugin-1.0.1-5 (i686) * xfce4-timer-plugin-1.6.0-2 (i686) * xfce4-verve-plugin-1.0.1-2 (i686) * xfce4-wavelan-plugin-0.5.11-3 (i686) * xfce4-weather-plugin-0.8.5-2 (i686) * xfce4-xkb-plugin-0.5.6-2 (i686) * xfconf-4.12.0-1 (i686) * xfdesktop-4.12.0-1 (i686) * xfwm4-4.12.0-1 (i686) * exo-0.10.3-2 (x86_64) * garcon-0.4.0-1 (x86_64) * gtk-xfce-engine-2.10.0-1 (x86_64) * libxfce4ui-4.12.0-1 (x86_64) * libxfce4util-4.12.1-1 (x86_64) * libxfcegui4-4.10.0-4 (x86_64) * nvidia- (x86_64) * nvidia-304xx-304.125-11 (x86_64) * nvidia-340xx-340.76-4 (x86_64) * orage-4.10.0-2 (x86_64) * thunar-1.6.6-1 (x86_64) * thunar-archive-plugin-0.3.1-5 (x86_64) * thunar-media-tags-plugin-0.2.1-2 (x86_64) * thunar-volman-0.8.1-1 (x86_64) * xfburn-0.5.2-2 (x86_64) * xfce4-appfinder-4.12.0-1 (x86_64) * xfce4-battery-plugin-1.0.5-4 (x86_64) * xfce4-clipman-plugin-1.2.6-2 (x86_64) * xfce4-cpufreq-plugin-1.1.1-2 (x86_64) * xfce4-cpugraph-plugin-1.0.5-3 (x86_64) * xfce4-datetime-plugin-0.6.2-4 (x86_64) * xfce4-dev-tools-4.12.0-1 (x86_64) * xfce4-dict-0.7.0-2 (x86_64) * xfce4-diskperf-plugin-2.5.4-3 (x86_64) * xfce4-eyes-plugin-4.4.3-2 (x86_64) * xfce4-fsguard-plugin-1.0.1-4 (x86_64) * xfce4-genmon-plugin-3.4.0-3 (x86_64) * xfce4-mailwatch-plugin-1.2.0-5 (x86_64) * xfce4-mixer-4.11.0-2 (x86_64) * xfce4-mount-plugin-0.6.7-3 (x86_64) * xfce4-mpc-plugin-0.4.4-4 (x86_64) * xfce4-netload-plugin-1.2.4-2 (x86_64) * xfce4-notes-plugin-1.7.7-7 (x86_64) * xfce4-notifyd-0.2.4-2 (x86_64) * xfce4-panel-4.12.0-1 (x86_64) * xfce4-power-manager-1.4.3-1 (x86_64) * xfce4-quicklauncher-plugin-1.9.4-10 (x86_64) * xfce4-screenshooter-1.8.2-2 (x86_64) * xfce4-sensors-plugin-1.2.6-2 (x86_64) * xfce4-session-4.12.0-2 (x86_64) * xfce4-settings-4.12.0-1 (x86_64) * xfce4-smartbookmark-plugin-0.4.5-3 (x86_64) * xfce4-systemload-plugin-1.1.2-2 (x86_64) * xfce4-terminal-0.6.3-2 (x86_64) * xfce4-time-out-plugin-1.0.1-5 (x86_64) * xfce4-timer-plugin-1.6.0-2 (x86_64) * xfce4-verve-plugin-1.0.1-2 (x86_64) * xfce4-wavelan-plugin-0.5.11-3 (x86_64) * xfce4-weather-plugin-0.8.5-2 (x86_64) * xfce4-xkb-plugin-0.5.6-2 (x86_64) * xfconf-4.12.0-1 (x86_64) * xfdesktop-4.12.0-1 (x86_64) * xfwm4-4.12.0-1 (x86_64) == Incomplete signoffs for [core] (15 total) == * dialog-1:1.2_20150225-1 (i686) 0/1 signoffs * ding-libs-0.4.0-3 (i686) 0/1 signoffs * glib2-2.42.2-1 (i686) 0/1 signoffs * kmod-20-1 (i686) 0/1 signoffs * libmpc-1.0.3-1 (i686) 0/1 signoffs * libtool-2.4.6-1 (i686) 0/1 signoffs * logrotate-3.8.9-1 (i686) 0/1 signoffs * systemd-219-2 (i686) 0/1 signoffs * util-linux-2.26-3 (i686) 0/1 signoffs * dialog-1:1.2_20150225-1 (x86_64) 1/2 signoffs * ding-libs-0.4.0-3 (x86_64) 0/2 signoffs * kmod-20-1 (x86_64) 0/2 signoffs * libmpc-1.0.3-1 (x86_64) 0/2 signoffs * logrotate-3.8.9-1 (x86_64) 1/2 signoffs * util-lin
[arch-dev-public] Bug tracker permissions
Hi all, I notice we have a backlog of requests (close or reopen) in both the "Arch Linux" and "Community Packages" sections. 33 and 29 requests respectively. To help fix this, I gave our bug wrangler (scimmia) permissions to see these in both projects, which actually makes him a "Project Manager". The TUs can not see these requests to act on them. All developers were given project manager permissions long time ago - should TUs also get this? Or should we wait to see how the bug wrangler goes at reducing the queue? Cheers, Allan
Re: [arch-dev-public] Bug tracker permissions
On 02/03/2015 14:10, Allan McRae wrote: > > The TUs can not see these requests to act on them. All developers were > given project manager permissions long time ago - should TUs also get > this? Or should we wait to see how the bug wrangler goes at reducing > the queue? Hi, Make sense to open bug wrangling to TUs. Moreover, is there some interest to not automatically reopen tasks ? That would spread the load of closing them again to all packagers instead to one bug wrangler. Regards, -- Sébastien "Seblu" Luttringer Archlinux Developer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
[2015-03-02 15:58:37 -] Arch Website Notification: > Todo list information: > Name: Fix source file names > URL: https://www.archlinux.org/todo/fix-source-file-names/ > Creator: Sergej Pupykin > Description: > Following packages have potential file name conflicts if you use SRCDEST in > makepkg.conf. > > Please add "$pkgname-$pkgver.tar.gz::" into beginning of URL. > > Urls like this > > https://github.com///archive/v0.4.1.tar.gz > > should be changed to > > $pkgname-$pkgver.tar.gz::https://github.com///archive/v0.4.1.tar.gz > > so source will be downloaded into unique named file. Should we really try to enforce unique tarball names? Then should we enforce unique patch names too (and anything else that might go in the source array)? If upstream's tarball is called v0.4.1.tar.gz then I'd rather not override that... -- Gaetan
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
On Mon, Mar 02, 2015 at 06:49:13AM -1000, Gaetan Bisson wrote: > [2015-03-02 15:58:37 -] Arch Website Notification: > > Todo list information: > > Name: Fix source file names > > URL: https://www.archlinux.org/todo/fix-source-file-names/ > > Creator: Sergej Pupykin > > Description: > > Following packages have potential file name conflicts if you use SRCDEST in > > makepkg.conf. > > > > Please add "$pkgname-$pkgver.tar.gz::" into beginning of URL. > > > > Urls like this > > > > https://github.com///archive/v0.4.1.tar.gz > > > > should be changed to > > > > $pkgname-$pkgver.tar.gz::https://github.com///archive/v0.4.1.tar.gz > > > > so source will be downloaded into unique named file. > > Should we really try to enforce unique tarball names? Yes. It's rare, but it's easy to fix and it's useful for humans trying to navigate their $SRCDEST directory. A tarball named v0.4.1.tar.gz isn't useful at a glance to a human. > Then should we enforce unique patch names too (and anything else that > might go in the source array)? I don't see why not. If you're giving patches generic names like bugfix.patch, then you're not doing anyone any favors. A sufficiently descriptive filename for a patch should not, in the general case, cause filename clashes. > If upstream's tarball is called v0.4.1.tar.gz then I'd rather not > override that... Not sure you've presented any reasoning here other than "I'm lazy". Don't worry, I'm with you on that, but I think we can do better here without increasing maintenance burden. Another option would be to teach makepkg to shard out SRCDEST by $pkgbase, allowing source contents to be "namespaced" to a degree. This would make the $SRCDEST dir easier to navigate, as everything is now split up by the package it belongs to (and by corollary, it's then easier to clean). A downside is that this strategy would potentially cause source file duplication in cases like "linux" and "linux-api-headers". It also, in extreme circumstances, will break on filesystems like ext3 which have subdirectory count limits. dR
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
[2015-03-02 12:28:46 -0500] Dave Reisner: > On Mon, Mar 02, 2015 at 06:49:13AM -1000, Gaetan Bisson wrote: > > > If upstream's tarball is called v0.4.1.tar.gz then I'd rather not > > override that... > > Not sure you've presented any reasoning here other than "I'm lazy". > Don't worry, I'm with you on that, but I think we can do better here > without increasing maintenance burden. My reasoning is that there's no reason to complicate our PKGBUILDs to fix something I don't consider a problem. We should really just be able to copy-paste an upstream URL; and if the filenames collide I'd rather have this fixed automatically rather than manually in every PKGBUILD. > Another option would be to teach makepkg to shard out SRCDEST by > $pkgbase, allowing source contents to be "namespaced" to a degree. We could also do what wget does: use the full URL as path. So the source file http://github.com/libfoo/v0.4.1.tar.gz would end up being downloaded as $SRCDEST/github.com/libfoo/v0.4.1.tar.gz . That's clean and generic. Are there any tools that rely on SCRDEST and that would be disturbed by a change like this? Cheers. -- Gaetan
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
On Mon, Mar 2, 2015 at 12:45 PM, Gaetan Bisson wrote: > [2015-03-02 12:28:46 -0500] Dave Reisner: >> On Mon, Mar 02, 2015 at 06:49:13AM -1000, Gaetan Bisson wrote: >> >> > If upstream's tarball is called v0.4.1.tar.gz then I'd rather not >> > override that... >> >> Not sure you've presented any reasoning here other than "I'm lazy". >> Don't worry, I'm with you on that, but I think we can do better here >> without increasing maintenance burden. > > My reasoning is that there's no reason to complicate our PKGBUILDs to > fix something I don't consider a problem. We should really just be able > to copy-paste an upstream URL; and if the filenames collide I'd rather > have this fixed automatically rather than manually in every PKGBUILD. > >> Another option would be to teach makepkg to shard out SRCDEST by >> $pkgbase, allowing source contents to be "namespaced" to a degree. > > We could also do what wget does: use the full URL as path. So the source > file http://github.com/libfoo/v0.4.1.tar.gz would end up being > downloaded as $SRCDEST/github.com/libfoo/v0.4.1.tar.gz . > > That's clean and generic. Are there any tools that rely on SCRDEST and > that would be disturbed by a change like this? Future plans aside, there are 19 packages involved here. We can spend time proposing alternate solutions without patches and complaining, or we could just fix these packages. I'm glad you don't consider it a problem, but someone cared enough to, and it doesn't really inconvenience anyone that much in the big picture. -Dan
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
[2015-03-02 12:54:56 -0600] Dan McGee: > Future plans aside, there are 19 packages involved here. We can spend > time proposing alternate solutions without patches and complaining, or > we could just fix these packages. I'd rather write a patch myself than see tiny workarounds pile up in our PKGBUILDs. Yes, that's more work, but that's how I prefer to spend my own free time. Now I was discussing whether such a patch is viable before actually working on it. Are you interested in this discussion? -- Gaetan
