[00:45] <mwhudson> heh the autopkgtest queue for zesty/amd64 looks a bit crazy
[01:16] <tyhicks> @pilot out
[01:18] <tyhicks> sponsored virt-manager (LP: #1634304) and will be security-sponsoring mariadb-{5.5,10.0} (LP: #1638125) and proftpd-dfsg (LP: #1462311) after they finish building in the security PPA
[01:18] <ubottu> Launchpad bug 1634304 in virt-manager (Ubuntu Zesty) "Unable to complete install: 'Couldn't find hvm kernel for Ubuntu tree" [Undecided,Fix committed] https://launchpad.net/bugs/1634304
[01:18] <ubottu> Launchpad bug 1638125 in mariadb-10.0 (Ubuntu Xenial) "USN-3109-1: MySQL vulnerabilities partially applies to MariaDB too" [High,Confirmed] https://launchpad.net/bugs/1638125
[01:18] <ubottu> Launchpad bug 1462311 in proftpd-dfsg (Ubuntu Trusty) "proftpd mod_copy issue (CVE-2015-3306)" [Medium,In progress] https://launchpad.net/bugs/1462311
=== salem_ is now known as _salem
[03:12] <tsimonq2> Hey guys, how would I go about having a comment added here? https://merges.ubuntu.com/universe.html
[03:12] <tsimonq2> As in a comment on a package
[03:12] <tumbleweed> type and press enter
[03:13] <tsimonq2> ...?
[03:13] <tsimonq2> I can't do that...
[03:13] <tumbleweed> yes you can
[03:13] <tsimonq2> How?
[03:14] <tumbleweed> click in a comment field, type, e...
[03:14] <tsimonq2> OH
[03:14] <tsimonq2> HAH
[03:14] <tsimonq2> Thank you
[03:14] <tumbleweed> :)
[03:18] <sarnold> cool :)
[08:05] <pitti> Good morning
[08:32] <nacc> doko: fyi, upstream libwebp is going to have the full fix for the neon detection bits in 0.5.2, we can drop the delta once it's packaged: https://bugs.chromium.org/p/webp/issues/detail?id=313
[08:41] <bdmurray> seb128: This crash seems to only affect the SRU'ed version of libreoffice - https://errors.ubuntu.com/problem/3f5546617f0b197529d734bee9ae770fb485b92d
[08:46] <doko> nacc: looks ok if it's arm64 only. we can't assume neon on armhf
[08:49] <nacc> doko: ack, I'll make sure to test that (0.5.2 isn't packaged yet in debian, not sure it's actually released upstream yet, that patch is just queued for it)
[08:57] <smoser> pitti, systemctl status home.mount
[08:57] <smoser>    Loaded: loaded (/etc/fstab; bad; vendor preset: enabled)
[08:57] <smoser> why 'bad' ?
[08:57] <pitti> smoser: not sure, my laptop says "loaded (/etc/fstab; generated"
[08:58] <pitti> smoser: any journal errors about that?
[08:58] <smoser> interesting. do you have a home.mount ?
[08:58] <pitti> smoser: not on disk, just from the fstab generator in /run
[08:58] <pitti> UUID=deadbeef /home           btrfs   defaults,subvol=@home 0       2
[08:58] <pitti> i. e. nothing surprising
[08:59] <pitti> smoser: do you have a drop-in for this or an on-disk unit?
[08:59] <stgraber>    Loaded: loaded (/proc/self/mountinfo)
[08:59] <stgraber>    Active: active (mounted) since Wed 2016-12-07 14:43:31 CET; 19h ago
[09:01] <smoser> pitti, i've not done anything.
[09:01] <seb128> bdmurray, hum, thanks, let's see what Bjoern has to say about it but I expect that he's going to say that the number of reports is too low and it's in statistical errors not relevant
[09:01] <smoser> on zesty another sytsem, i see http://paste.ubuntu.com/23597482/
[09:01] <pitti> smoser: so, anything about home.mount in journal?
[09:01] <smoser> seemingly more normal
[09:01] <smoser> not much
[09:01] <pitti> smoser: yep, that's how it looks like here too
[09:02] <smoser> http://paste.ubuntu.com/23597483/
[09:03] <bdmurray> seb128: okay, than that I'm happy with fully phasing it
[09:03] <seb128> bdmurray, ok, great, thanks for reviewing those and for unblock the snapd-glib one!
[09:03] <seb128> unblocking
[09:03] <pitti> smoser: any errors in systemd-analyze verify /run/systemd/generator/home.mount other than the "unit is bound to inactive..."?
[09:05] <smoser> pitti, systemd-analyze verify shows nothing at all
[09:05] <smoser> http://paste.ubuntu.com/23597499/
[09:05] <smoser> pitti, if you want to come and look i can let you
[09:05] <pitti> smoser: which room?
[09:05] <smoser> but i'm not terribly fussed on it at this point
[09:05] <smoser> server room.
[09:22] <pitti> rharper: resolvconf updated in x/y/z
[09:22] <rharper> pitti: thanks!
[09:25] <nacc> rbasak: https://en.wikipedia.org/wiki/Chemical_file_format
[09:26] <nacc> slangasek: is it correct to assert that a 'patches-applied' version of a srcpkg only makes sense for 3.0 (quilt)
[09:39] <petn-randall> Hi, were would I find the VCS used for packaging for rng-tools? I plan on introducing rng-tools5 to Debian again, and I'd like to inherit the VCS history to retain the contributions of the Ubuntu maintainers.
[09:52] <nacc> petn-randall: afaict, no vcs was used; it might have been bzr, but the last update was in vivid (15.04)
[09:52] <nacc> petn-randall: or at least, i'm not sure there's a gurantee there was
=== henrix_ is now known as henrix
[09:56] <petn-randall> nacc: Is there some implicit scheme where I could expect to find the bzr repo?
[09:59] <nacc> petn-randall: this seems to be 'current': https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/rng-tools/vivid
[10:00] <nacc> petn-randall: or more accurately (historical branches): https://code.launchpad.net/ubuntu/+source/rng-tools
[10:01] <nacc> petn-randall: if you want to look at the same sort of thing, but from git, I could import it for you on the side (or you could run that import locally), to at least keep the history. It won't match the VCS exactly (in that it doesn't know about bzr), but will have the fully history of the srcpkg in ubuntu
[10:04] <petn-randall> nacc: I'd only import the master/current branch, not all branches, since I only want to retain the contributions of Ubuntu devs, and not retain all releases of all Ubuntu releases (this is of limited use for Debian). The bzr repo already helped me out a lot, thanks.
[10:14] <slangasek> nacc: if you mean "does patches-applied make sense for a package with debian/patches that's format 1.0?", yes it's correct that this does not make sense
[10:16] <nacc> slangasek: ack, thanks!
[10:16] <nacc> petn-randall: np!
[10:17] <nacc> slangasek: and one step further, is '3.0 (quilt)' the only format for which it makes sense to have a difference between patches-unapplied and patches-applied
[10:27] <slangasek> nacc: yes, because it's the only format for which dpkg-source applies packages
[10:27] <slangasek> patches
[10:27] <slangasek> nacc: a 1.0 package may have bits in the diff.gz that are unpacked to locations outside of debian/; but there is no equivalent "patches-unapplied" in that case
[10:57] <smoser> pitti, so i think yesterday you were saying i could dropin to be After=cloudinit-local.service
[10:57] <smoser> for systemd-fsck@dev.service
[10:57] <smoser> that is what looks right.
[10:57] <smoser> can you do a 'Before=systemd-fsck@dev.service' ? or is that not possible or desireable due to the @
[10:59] <pitti> smoser: that's possible; if you have a template unit already, you have %I, so you can do Before=systemd-fsck@%I.service
[10:59] <pitti> and otherwise, if you know the device already, put that in
[11:00] <smoser> well, ic an't know the device until i run
[11:00] <smoser> and at that point its too late.
[11:00] <smoser> so i think dropin seems maybe the only thing i can do
[11:01] <pitti> smoser: that seems fine
[11:05] <smoser> pitti, so the path then is:
[11:05] <smoser>  /lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
[11:05] <pitti> *nod*
[11:06] <smoser> the @ i ddin't know for sure. thanks
[11:07] <pitti> smoser: I'm not sure if you can literally do "Before=bar@.service" and it would automatically apply to the same instance as the unit it came from
[11:07] <pitti> I think that won't work, but feel free to give it a try of course
=== _salem is now known as salem_
[11:13] <smoser> i think it wont work also
[11:22] <pitti> rharper: ah, Thomas already responded (I think you did test in sid, right?)
[11:22] <rharper> pitti: yes
[11:22] <rharper> but ifupdown/networking  only
[11:22] <rharper> I'll reply
[11:23] <rharper> I've not tested networkd in debian
[11:23] <pitti> that should be enough to ensure it doesn't regress
[11:23] <rharper> I think so too
[11:23] <rharper> but I want to double check
[11:23] <rharper> before I say yes
=== PaulW2U_ is now known as PaulW2U
[13:14] <pitti> smb: /proc/sys/net/core/rmem_default
[13:22] <pitti> smb: udevadm info --export-db|grep -c ^P:
=== hikiko is now known as hikiko|ln
[13:53] <nacc> cpaelzer: LP: #1593024
[13:53] <ubottu> Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593024
[13:53] <nacc> cpaelzer: c#16 (some bullets in c#14 for context)
[14:17] <nacc> cpaelzer: https://wiki.canonical.com/ServerTeam/ServerReleaseHandling
[15:30] <caribou> rbasak: looks like the 'broken' samba package we rolled back is still present in xenial-proposed :
[15:30] <caribou> samba | 2:4.3.11+dfsg-0ubuntu0.16.04.2 | xenial-proposed
[15:31] <caribou> rbasak: shoudn't it be removed from there also ?
[15:31] <Laney> apw: doko: do you know what's up with linux/amd64 and linux/ppc64el autopkgtests on zesty?
[15:32] <Laney> are they being skipped?
[15:33] <doko> Laney: no idea, and apw is on paternity leave
[15:33] <Laney> hmm
[15:33] <Laney> doko: it's blocking your gcc-6 and binutils :-)
[15:33] <doko> sure, I know that
[15:34] <infinity> Eh.  Why was that run with --all-proposed?
[15:34] <Laney> that?
[15:34] <infinity> 4.9.0 isn't in release yet.
[15:35] <Laney> Don't know, but 4.8 wasn't any better
[15:35] <infinity> So, someone from the kernel team should look at them and tell us if it looks like the toolchain broke them or if their tests just suck.
[15:35] <infinity> bjf: ^
[15:39] <bjf> infinity, can you tell rtg what the issue is and what you need him to look into?
[15:40] <infinity> rtg: Your autopkgtests are failing in zesty for the new gcc and binutils uploads, can you look into the logs and decide who to blame?
[15:41] <rtg> infinity, can do
[15:41] <Laney> There's already a badtest for linux
[15:42] <infinity> Oh, is there a current one?
[15:42] <infinity> Well, maybe that's just the way to go for now, but that's getting really old.
[15:42] <Laney> Nope
[15:42] <infinity> A testsuite that almost never passes is pretty useless.
[15:42] <Laney> Maybe there's some history there though
[15:45] <rbasak> caribou: yes, but I'm told it needs an AA to do a v-f removal.
[15:45] <rbasak> We should get better at this though. If people are volunteering to test -proposed for us, the least we could do is remove known broken stuff, IMHO.
[15:45] <caribou> ah, ok. Someone just reported the issue on the Trusty bug
[15:46] <rbasak> slangasek: bug 1644428: please could you delete samba from xenial-proposed? ^
[15:46] <ubottu> bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Fix released] https://launchpad.net/bugs/1644428
[15:47] <doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845690 was kernel related, but that one is fixed
[15:47] <ubottu> Debian bug 845690 in binutils "binutils: creates unbootable kernel on x86-64" [Important,Fixed]
[15:47] <rbasak> Strictly speaking it's bug 1584485 I think actually. That's where the v-f is.
[15:47] <ubottu> bug 1584485 in samba (Ubuntu Trusty) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
[15:48] <rbasak> slangasek: and, to add to our discussion the other day, perhaps v-f removals should be a routine AA task to add to the list?
=== hikiko|ln is now known as hikiko
=== marga_ is now known as marga
=== JanC is now known as Guest38161
=== JanC_ is now known as JanC
[18:22] <mwhudson> are autopkgtests actually running?
[18:23] <nacc> mwhudson: i think the queue lengths are still huge at least for amd64/i386
[18:24] <mwhudson> nacc: yeah, they are suspiciously similar to the queue lengths when i went to bed
[18:25] <nacc> mwhudson: iiuc, there might be some issues with one of the infra pieces, but i'm honestly not sure
[18:36] <ginggs> the amd64 is moving, earlier it was on the libs, now it's  down to open-vm-tools, openafs, etc.
[18:36] <ginggs> ^ queue
[18:37] <ginggs> that's still on the tests triggered by glibc
[19:07] <mwhudson> ginggs: oh ok, i guess i'll just be patient then :)
=== loladiro_ is now known as loladiro
=== wendar_ is now known as wendar