[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 6 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 2 fully signed off packages * 42 packages missing signoffs * 2 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 (6 total) == * libixion-0.11.0-2 (i686) * liborcus-0.11.0-1 (i686) * libreoffice-fresh-5.1.1-2 (i686) * libixion-0.11.0-2 (x86_64) * liborcus-0.11.0-1 (x86_64) * libreoffice-fresh-5.1.1-2 (x86_64) == Incomplete signoffs for [core] (14 total) == * cracklib-2.9.6-1 (i686) 0/1 signoffs * dbus-1.10.8-1 (i686) 0/1 signoffs * iputils-20160308.0db72a4-1 (i686) 0/1 signoffs * lvm2-2.02.145-1 (i686) 0/1 signoffs * mpfr-3.1.4-1 (i686) 0/1 signoffs * nss-3.23-1 (i686) 0/1 signoffs * pkg-config-0.29.1-1 (i686) 0/1 signoffs * thin-provisioning-tools-0.6.1-2 (i686) 0/1 signoffs * cracklib-2.9.6-1 (x86_64) 0/2 signoffs * iputils-20160308.0db72a4-1 (x86_64) 0/2 signoffs * lvm2-2.02.145-1 (x86_64) 0/2 signoffs * mpfr-3.1.4-1 (x86_64) 1/2 signoffs * nss-3.23-1 (x86_64) 1/2 signoffs * thin-provisioning-tools-0.6.1-2 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (26 total) == * cmake-3.5.0-1 (i686) 0/1 signoffs * digikam-4.14.0-6 (i686) 0/1 signoffs * glib-networking-2.47.90-1 (i686) 0/1 signoffs * gst-plugins-bad-1.6.3-7 (i686) 0/1 signoffs * libixion-0.11.0-2 (i686) 0/1 signoffs * libkface-15.12.2-2 (i686) 0/1 signoffs * libkface4-15.08.3-3 (i686) 0/1 signoffs * liborcus-0.11.0-1 (i686) 0/1 signoffs * libreoffice-fresh-5.1.1-2 (i686) 0/1 signoffs * opencv-3.1.0-3 (i686) 0/1 signoffs * quazip-0.7.1-7 (i686) 0/1 signoffs * talloc-2.1.6-1 (i686) 0/1 signoffs * wget-1.17.1-1 (i686) 0/1 signoffs * cmake-3.5.0-1 (x86_64) 0/2 signoffs * digikam-4.14.0-6 (x86_64) 0/2 signoffs * glib-networking-2.47.90-1 (x86_64) 0/2 signoffs * gst-plugins-bad-1.6.3-7 (x86_64) 0/2 signoffs * libixion-0.11.0-2 (x86_64) 0/2 signoffs * libkface-15.12.2-2 (x86_64) 0/2 signoffs * libkface4-15.08.3-3 (x86_64) 0/2 signoffs * liborcus-0.11.0-1 (x86_64) 0/2 signoffs * libreoffice-fresh-5.1.1-2 (x86_64) 0/2 signoffs * opencv-3.1.0-3 (x86_64) 0/2 signoffs * quazip-0.7.1-7 (x86_64) 0/2 signoffs * talloc-2.1.6-1 (x86_64) 0/2 signoffs * wget-1.17.1-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (2 total) == * libcacard-2.5.2-1 (i686) 0/1 signoffs * libcacard-2.5.2-1 (x86_64) 0/2 signoffs == Completed signoffs (2 total) == * dbus-1.10.8-1 (x86_64) * pkg-config-0.29.1-1 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * libcacard-2.5.2-1 (i686), since 2016-02-13 * libcacard-2.5.2-1 (x86_64), since 2016-02-13 == Top five in signoffs in last 24 hours == 1. andyrtr - 3 signoffs 2. djgera - 1 signoffs
Re: [arch-dev-public] On pushing a standalone opencv 3.x
On 2016-03-11 21:06, Rashif Ray Rahman wrote: > On 22 December 2015 at 04:20, Bartłomiej Piotrowski > wrote: >> Looks like it doesn't overlap with our sandcastles made of Boost 1.16.0 >> rebuild, so I think it's fine to start it right away if you have >> prepared an upgrade of opencv and a new opencv2 package. > > Thanks for taking this forward and getting this rebuilt once and for all! > > Some of you may have received e-mails from a helping user Gabriel > regarding some fixes here and there, but otherwise note that 3.x was > also committed once before so look at that for any further context if > needed. [1] > > [1] > https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/opencv&id=38b720f2889e81359f236934d392bac708b10d97 > Everything has been rebuilt more or less fine thanks to Antonio's awesome help. One remaining bit is either fixing gst-plugins-bad with OpenCV 3.1 or packaging OpenCV 2 for the same reason. BP signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] DKMS modules for virtualbox
On ven., 2016-03-11 at 07:49 +0100, Bartłomiej Piotrowski wrote: > On 2016-03-09 02:44, Sébastien Luttringer wrote: > > > > Debian provides its vbox modules only via dkms and it's not a source > > distribution (as far I know). > Sure, and as far as I know, we are not Debian. > > No one doubts that. The point was we are not a source distribution because we offer to build o-o-t-m from sources. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] DKMS modules for virtualbox
On mer., 2016-03-09 at 12:10 +1000, Allan McRae wrote: > On 09/03/16 11:44, Sébastien Luttringer wrote: > > > > On mer., 2016-03-09 at 10:19 +1000, Allan McRae wrote: > > > > > > On 09/03/16 09:29, Sébastien Luttringer wrote: > > > > > > > > > > > > On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote: > > > > > > > > > > > > > > > 1) pre pacman-5.0 updates unsupported without any prior notification > > > > Interesting. This issue will also be present if we move other stuff > > > > like > > > > update-desktop-database to hooks, right? Do we have a way to detect > > > > pre- > > > > pacman > > > > 5 update to display a warning or handle it correctly? > > > There needs to be a public announcement made that we expected everyone > > > to have updated to pacman-5.0 by . Then we start > > > using hooks. > > There is no way without breaking people updating their Arch from pacman 4.x > > after that random date? > > > That is the only way. Joys of rolling release. If pacman was able to update itself first, as it does before, this would, rolling release or not, do the job? > > > > As we currently not have the infrastructure to build binaries modules > > > > each > > > > time > > > > a new kernel version (flavoured / versioned) is pushed, > > > Surely that is a five line script... > > Please provide it. We are building all our kernel modules manually for > > years. > > > > How this will work? When I push a new version of virtualbox on svn a > > builder > > will pick the current kernel and build the modules from my dkms version and > > push them to the repo? Which key will sign these packages? How this will be > > synced with db-update? > What has pushing a new version of virtualbox got to do with rebuilding > modules when the kernel is updated? Rebuilding modules on kernel update is: > > for pkg in ; do > archco > // awk/sed line to bump pkgrel > testing-x86_64-build && testing-i686-build > testingpkg "module rebuild" > done > > OK - I was wrong. That is six lines (or seven if you count the line > with && as two lines...). > > > We are definitely not talking of the same thing. I was talking of an automated way of building o-o-t modules when the dkms package is updated or the kernel is bumped. Was you are proposing, is what I referred as manually. == Before going further, keep in mind that I'm open to bring back pre-built modules for virtualbox. But currently there is no rules and no coherence between our way of doing. Let me summarise the situation with the following table: | package name | linux | linux-lts | dkms | | acpi_call | yes | yes | no | | bbswitch | yes | yes | no | | nvidia | yes | yes | yes | | nvidia-340xx | yes | yes | yes | | nvidia-304xx | yes | yes | yes | | ndiswrapper-dkms | no | no | yes | | r8168 | yes | yes | no | | rt3562sta | yes | no | no | | sysdig | no | no | yes | | vhba-module | yes | no | no | | virtualbox-host-modules | no | no | yes | | virtualbox-guest-modules | no | no | yes | So, each maintainer do what he wants. Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw. For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels. What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: This is a digitally signed message part
