[00:13] <nacc> slangasek: so i think i'll also need an AA to manually delete src:zend-framework. As that sole binary package will continue to be built from zend-framework (so it iwll never show up as a binaryless source?)
[00:44] <slangasek> nacc: ack; please file a bug against the zend-framework source package for this and subscribe ubuntu-archive
[00:46] <nacc> slangasek: will do, thanks!
[00:51] <slangasek> rharper: the SRU in LP: #1636912 seems somewhat muddled to me; AIUI the test case as written did pass for systemd, but there is a new bug task open now on resolvconf related to DNS timing, but no test case for the DNS part of this?
[00:51] <ubottu> Launchpad bug 1636912 in resolvconf (Ubuntu Yakkety) "systemd-networkd runs too late for cloud-init.service (net)" [Undecided,In progress] https://launchpad.net/bugs/1636912
[00:53] <slangasek> rharper: if the problem you describe is a regression with the new systemd package, then there should be a versioned Breaks: from the new systemd to the old resolvconf; if it's not a regression, then this ought to be a separate SRU to not block the systemd SRU on the resolvconf changes
[01:09] <rharper> slangasek: it's only exposed in the case of UC16  + cloud-init; which doesn't exist anywhere AFAIK;  the case is that you're using networkd instead of ifupdown and you're using cloud-init with changes to allow networkd to run early ( the changes in the SRU)
[01:11] <rharper> slangasek: the test-case is basically building cloud-init with an update to cloud-init.service which includes an After=systemd-networkd-wait-online.service (which it doesn't have now); this allows a UC16 image with cloud-init enabled to use networkd to bring up networking for cloud-init.service;  DNS was an issue as resolvconf wasn't running before networkd was; so the DNS update wasn't found and /etc/resolv.conf wasn
[01:11] <rharper> 't updated either ; snap installs failed as we could reach assertions.ubuntu.com etc.
[01:12] <rharper> slangasek: w.r.t separate, pitti thought they were all the same change, ie, allow networkd to run early enough for cloud-init.service to use it to bring up networking
=== JanC is now known as Guest9817
=== JanC_ is now known as JanC
[06:42] <cpaelzer> good morning
[07:33]  * alkisg just learned that pitti is no longer around here... :D Thanks for everything and wishing you all the best!
=== shuduo-afk is now known as shuduo
[09:17] <smb> Is anybody else having problems with google spreadsheets in firefox (xenial and trusty) since recently? I am quite sure it was working last week and at least since yesterday I always get error/try reload messages. In Chromium it works.
=== hikiko is now known as hikiko|off
[10:15] <xnox> smb, use google chrome =)
[10:17] <smb> xnox, well, I do that now as a work-around of course. :-P just wondering whether it is a generic problem with the backport path in old releases which we maybe cannot tell all users to just use chromium
[10:23] <xnox> smb, well we did better than that, and pushed out latest firefox v52 to all stable users.
[10:24] <xnox> i use google chrome, as it has Adobe based pdf renderer and Adobe based flash plugin, proprietary, built in, and sandboxed.
[10:25] <xnox> and from security point of view, i am naive to think that google chrome is "secure" and updated "faster".
[10:26] <smb> xnox, and there I thought this was 50.1 about a few hours ago :) So yeah, I just wait and meanwhile try to do a fresh xenial VM install to see whether it maybe is related to updating with older browser config
[10:27] <smb> xnox, Mainly I user firefox because it was there before and I am too lazy to change
[10:27] <smb> ;)
[10:27] <xnox> smb, oh, the killer feature of google chrome is that it can track multiple google accounts and easily switch between them.
[10:28] <xnox> because one can have a user/profile, per google account ChromeOS style.
[10:28] <smb> xnox, yeah thats a bigger pain in ff. there is multiple active users but of course the feature of almost always picking the wrong one by default
[10:29] <xnox> smb, huh, it is 50.1 everywhere. which is latest, no idea how i saw 52 given that it does not exist yet =)
[10:29] <xnox> google chrome picks last active window one. So if i had canonical calendar open, clicking a link will open things in that profile.
[10:31] <smb> xnox, heh, ok. It uses the right one when clicking links from anything related to a certain user. More of a problem using links from email or irc
[10:34] <xnox> so yeah, if last active browser was of matching account things are good, otherwise there is popup to switch accounts but i usually switch to the right browser account, go back to email/irc, re-click the link.
[10:34] <xnox> still pain =/
[10:36] <smb> indeed, but to a certain degree we all love some pain... or we would not be working in open software... ;-P
[11:10] <xnox> smb, 50 shades of aubergine.... =)
[11:10] <juliank> xnox: The Chrome PDF plugin is not Adobe based, and not even proprietary anymore. PDFium is based on Foxit technology, and was open sourced in summer 2014. Here's the code: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/pdf/
[11:12] <juliank> (excluding the pdfium library itself, which is at https://pdfium.googlesource.com/)
[11:40] <xnox> juliank, i did not know that! used to be proprietary, and i recall seeing "contains code from adobe" but maybe it was a generic EULA and maybe that bit referred just to flash.
=== _salem is now known as salem_
[12:18] <mitya57> Can someone please mark libaws (ppc64el, s390x) as ignored failure? It blocks many packages from migrating, and for some of them it's the only blocker.
[12:21] <xnox> error: ("/usr/lib/powerpc64le-linux-gnu/ada/adalib/aws/aws-exceptions.ali" is obsolete and read-only)
[12:21] <xnox> looks odd
[12:21] <xnox> mitya57, does it need to be recompiled again for some reason due to arch skew or some such?
[12:21] <xnox> e.g. it is likely that ppc64el/s390x builds finished before other arches.
[12:22] <mitya57> Maybe, should I try a new rebuild?
[12:24] <xnox> mitya57, we can do that in a bileto silo, and it will run autopkgtest to verify that claim.
[12:25] <xnox> however, maybe makes no difference to just use the archive direct. Upload no change rebuild of libaws again?
[12:26] <mitya57> xnox, If there is a chance that it will fix the failure, I can do a rebuild in the archive
[12:27] <xnox> with my limited knowledge, i would try to rebuild the source package which ships /usr/lib/powerpc64le-linux-gnu/ada/adalib/aws/aws-exceptions.ali
[12:53] <mitya57> (sorry, got distracted by other work)
[12:54] <mitya57> xnox, that file is from libaws3.3.2-dev, so the same source package
[13:35] <slashd> rbasak, so since Proposal A won't work, I thought about this proposal : https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/comments/36  still missing if the upgrade from Trusty and Xenial will work as noddns will only exist in Trusty and no longer be there in Xenial
[13:35] <ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Medium,In progress]
[13:36] <rbasak> slashd: I like that approach.
[13:36] <rbasak> I'll need to think about it some more though.
[13:37] <slashd> rbasak, sure me too, it's just a draft, but I think it worth evaluating it
[13:38] <slashd> caribou FYI ^
[13:48] <mterry> tjaalton: hello!  Yesterday I noticed that the version of mesa in -proposed seems to be causing unity8's autopkg tests to fail, preventing it from migrating.  I see you uploaded mesa, wondered if you had any ideas on debugging it or guesses as to why
[13:49] <tjaalton> mterry: haven't checked yet, will have a look
[13:50] <mterry> It seems like mesa itself has been stuck in -proposed a while
[13:50] <tjaalton> yes
[13:50] <tjaalton> it should migrate but plasma-framework is holding it back
[13:51] <tjaalton> mterry: what test is failing?
[13:53] <xnox> tjaalton, unity8 adt tests segfault
[13:53] <mterry> tjaalton: several tests segfault, about ten total I think.  For example, xvfbtestPreviewExpandable.  They only segfault with xvfb, in my testing
[13:54] <tjaalton> mterry: then that's again caused by libepoxy, which was fixed
[13:54] <tjaalton> last week
[13:54] <mterry> I don't know if we're the only package affected, but I just happened to notice it with us
[13:54] <tjaalton> or, new mesa triggers the bug in libepoxy, which got fixed there
[13:55] <tjaalton> so, rerun the test
[13:55] <mterry> tjaalton: unity8's upload was yesterday I believe
[13:56] <xnox> tjaalton, we are rerunning the tests with all-proposed=1
[13:57] <xnox> we should have fresh results soon.
[13:57] <tjaalton> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/u/unity8/20161213_153305_7636d@/log.gz ?
[13:59] <smb> so... just for reference, since I complained here... firefox 50.x + privacy badge + google spreadsheets == sad face (at least for me, had to disable it completely, just disable for docs.google.com did not help)
[13:59] <tjaalton> mterry: do they segfault with latest libepoxy?
[14:00] <smb> *privacy badger (extension)
[14:00] <xnox> tjaalton, at http://autopkgtest.ubuntu.com/packages/unity8/zesty/amd64 there should be two more results from today. They are still running at http://autopkgtest.ubuntu.com/running#pkg-unity8
[14:01] <mterry> tjaalton with version 1.3.1-1ubuntu1 in current zesty, yes they still segfault
[14:01] <tjaalton> looks like libepoxy is latest
[14:01] <tjaalton> dunno then what it is..
[14:01] <tjaalton> get a bt?
[14:02] <mterry> tjaalton: that is the log above yeah
[14:02] <mterry> tjaalton: a bt?
[14:02] <tjaalton> backtrace
[14:02] <mterry> tjaalton: oh I did manage to catch it but the stacktrace looked abreviated.  It was just one frame, inside libgcc
[14:03] <mterry> So I figured it had been corrupted
[14:03] <mterry> Maybe I didn't have enough dbg packages either tho
[14:04] <mterry> tjaalton: I can help get you to the point where you can reproduce and catch in gdb if we go down that route
[14:05] <tjaalton> mterry: other option is that I bisect mesa to find out what caused the original bug, and then revert it
[14:05] <mterry> I'll see if I can get a better stacktrace over here
[14:06] <tjaalton> cool
[14:13] <tjaalton> mterry: is there a (small) qt app to test with xvfb?
[14:13] <tjaalton> on the default desktop
[14:14] <mterry> tjaalton: probably one of the qt example apps? qtbase5-examples
[14:15] <mterry> tjaalton: the segfault is seen when the test is finishing/closing
[14:15] <tjaalton> thanks
[14:19] <tjaalton> running "openglwindow" on xvfb results in "could not initialize opengl"
[14:19] <tjaalton> and then it aborts
[14:24] <tjaalton> hm, that happens with older mesa too, so it's not that
[14:31] <mterry> tjaalton: with all the debug symbols I could think to install, I still just see one frame -- libgcc1's "classify_object_over_fdes" -- will see if other threads have anything suspicious
[14:31] <fossfreedom> sil2100: Hi!  any news on the best way to recognise officially ~ubuntubudgie-dev ?
[14:32] <mterry> nope, just the one threa
[14:32] <mterry> d
[14:32] <tjaalton> weird
[14:32] <mterry> memory must just be trashed by this point
=== giraffe is now known as Guest59158
[14:42] <mterry> tjaalton: I guess I'll try to catch it just before it crashes -- any luck on your side getting a reproduction?
[14:42] <tjaalton> mterry: not yet
[14:42] <tjaalton> but I'll just use the gtk case
[14:43] <tjaalton> and revert libepoxy to an older release, then bisect mesa..
[14:43] <tjaalton> reopened the upstream bug too
[14:43] <mterry> tjaalton: if it's easier, I could get you set up to run the unity8 test.  But sounds like you have a known gtk crasher
[14:44] <tjaalton> one thing I noticed is that with mesa 12 I get a libgl error failing to load swrast, while it's there
[14:44] <tjaalton> with 13 I don't get that
[14:47] <sil2100> fossfreedom: there was some discussion regarding that, need to get back to it after - let me poke you laterish (or tomorrow at latest)
[14:48] <fossfreedom> much appreciated.
[14:51] <krytarik> fossfreedom: Hi.  Not to interfere much, but I noticed earlier that you made an "ubuntubudgie" → "*-dev" typo here: http://bazaar.launchpad.net/~ubuntubudgie-dev/ubuntu-cdimage/ubuntu-cdimage/revision/1637#lib/cdimage/tests/test_germinate.py
[14:53] <fossfreedom> krytarik: hi - and damn - you are correct!  will fix tonight when I can get back to my computer.
[14:54] <krytarik> :)
[14:58] <krytarik> fossfreedom: Also, just noticed, regarding ~ubuntubudgie-dev, I think you want to invite ~ubuntu-core-dev as a member, rather than ~ubuntu-dev.
[14:59] <fossfreedom> looking ...
[15:00] <mterry> Looks like someone pushed u8 into main anyway, despite the failing tests.  So tjaalton my immediate pressure for this problem is gone, but it will bite us again probably
[15:00] <tjaalton> huh, ok :)
[15:01] <mterry> tjaalton: and in fact, it might still prevent a lot of stuff from migrating, because they'll trigger our u8 tests
[15:01] <fossfreedom> krytarik: hmm - not obvious how to "uninvite" a team on launchpad.  Any ideas?
[15:04] <mterry> xnox: so unity8 landed, was that because of the  all-proposed=1 run?
[15:11] <krytarik> fossfreedom: LP bug #656782. >_>
[15:11] <ubottu> Launchpad bug 656782 in Launchpad itself "No way to cancel (retract) pending team invitation" [Low,Triaged] https://launchpad.net/bugs/656782
[15:12] <fossfreedom> oh - outstanding since 2010 :(
=== scottt is now known as Guest26786
[15:25] <xnox> mterry, possibly. I see that one of the reruns did succeed -> http://autopkgtest.ubuntu.com/packages/unity8/zesty/amd64 & http://autopkgtest.ubuntu.com/packages/unity8/zesty/i386
[15:26] <xnox> mterry, i'm not sure which rerun was good (e.g. with all-proposed or without)
[15:26] <slangasek> rharper: at the moment, LP: #1636912 is blocking other SRU changes for systemd.  If the behavior with this SRU is not a regression, could you mark it verification-done, and we'll treat resolvconf separately (shortly)?
[15:26] <ubottu> Launchpad bug 1636912 in resolvconf (Ubuntu Yakkety) "systemd-networkd runs too late for cloud-init.service (net)" [Undecided,In progress] https://launchpad.net/bugs/1636912
[15:27] <mterry> xnox: I'm not sure I understand why that would fix it.  I was able to reproduce locally on a machine that had all of proposed installed.  But glad it went through anyway
[15:27] <rharper> slangasek: sure;  I don't believe we're regressing anyone as nothing besides UC16 + cloud-init (using netword) is affected by the required changes to resolvconf
[15:28] <xnox> mterry, i think other retriggers of unity8 will still continue to fail. looking at the log it seems unity8 tests passed with everything from release pocket, and just unity8 from proposed.
[15:28] <rharper> slangasek: after I mark verification-done;  what's the next steps for queuing up the resolvconf SRU ?
[15:28] <xnox> mterry, so e.g. mir, qtmir, mesa should still be stuck, and should still be reproducible.
[15:28] <mterry> xnox: yeah
[15:28] <slangasek> rharper: I'm going to chase the last remaining SRU bug in that systemd upload this morning, then publish it, then I'll approve the resolvconf SRU
[15:28] <xnox> mterry, right. So the failed log has --apt-pocket=proposed
[15:29] <slangasek> rharper: the SRU bug will still need adjusting so that the test case addresses the DNS part
[15:29] <rharper> slangasek: ok, let me verify the latest systemd works as expected in UC16 image I'm testing cloud-init changes
[15:29] <xnox> mterry, and passed one has --apt-pocket=proposed=src:unity8 -> so we know that unity8 itself is not broken, but other things break it (e.g. new mesa)
[15:30] <xnox> tjaalton, i really wish to use bileto silos for mesa landings -> one can build all packages in a single silo, and it will run all autopkgtests from release pocket against that ppa, such that we can see what fails because of new mesa alone in isolation from the rest of stuff. Too late now =)
[15:31] <sil2100> This is why Bileto has its merits
[15:32] <mterry> We could drop mesa from proposed?
[15:33] <mterry> (/ re-upload old version with later version)
[15:35] <rharper> slangasek: so, to confirm, we want to release systemd 	229-4ubuntu13 which is currently in -proposed;    we'll then perform another SRU with an update to systemd to address running resolvconf earlier and having systemd-networkd-wait-online.service update with an change to ensure that resolvconf service completes before we reach network-online.target ?
[15:35] <rharper> in the second SRU we'll have a systemd change and an updated resolvconf  paired
[15:36] <slangasek> rharper: ah, it wasn't clear to me that a further update to systemd was needed.  Then yes to all of the above, but in that case please create a separate bug for the follow-on SRU
[15:37] <rharper> slangasek: OK, marking done, filing new bug against systemd and resolvconf for DNS early with networkd
[15:43] <tjaalton> xnox: never heard of that
[15:44] <xnox> tjaalton, https://bileto.ubuntu.com/ -> create a ticket which creates a devirt ppa, which builds things, runs britney proposed migration, and all autopkgtests before doing a copy from ppa to release.
[15:44] <xnox> tjaalton, aka ~= the kernel team workflow, as well as touch/phablet/personal.
[15:45] <xnox> https://wiki.ubuntu.com/Bileto
[15:45] <xnox> most of it w.r.t. branch management and merging is irrelevant, if one knows how to prepare .dsc and dput things into ppa
[15:45] <tjaalton> ok
[15:47] <rharper> slangasek: filed https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649931
[15:47] <ubottu> Launchpad bug 1649931 in systemd (Ubuntu) "systemd-networkd needs to ensure DNS is up before network-online.target" [Undecided,New]
[15:58] <rharper> slangasek: ok, verified
[15:58] <slangasek> rharper: ta!
[15:59] <slangasek> rharper: can you reupload resolvconf with the new bug # also?
[15:59] <rharper> I cannot reupload, but I can attach the debdiffs to the new bug
[15:59] <slangasek> rharper: ok, then I'll reupload
=== pavlushka is now known as The_Doctorman
=== The_Doctorman is now known as pavlushka
[16:19] <slangasek> rharper: would accept resolvconf now, but there's no testcase in the SRU bug
[16:19] <rharper> ok, I'll write up something
[16:25] <xnox> [Testcase]
[16:25] <xnox> something
[16:25] <xnox> EOF
[17:23] <clivejo> Hi, any experts be able to shed some light on why krita 3.1.0 fails on arm64 and armhf in zesty - https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-misc/+packages?field.name_filter=krita&field.status_filter=published&field.series_filter=zesty
[17:45] <xnox> clivejo, because those architectures use gles and krita is not compatible with it?
[17:49] <mterry> @pilot in
[17:53] <mterry> hmm no bot
[18:37] <hjd> Hello, looking at https://launchpad.net/ubuntu/+source/batik I see that it has an Ubuntu-delta to keep one of its dependencies in universe instead of main. However, it looks like batik has since been moved to universe as well. Am I right in assuming this means that the Ubuntu delta could be dropped and a newer version of the package synced from Debian?
[18:37] <mterry> hjd: yeah probably -- I'll look at it
[18:45] <hjd> mterry: Thanks :)
[18:46] <mterry> hjd: just started sync
[18:46] <hjd> \o/
[19:04] <juliank> infinity: Can we manually accept apt 1.4~beta2 to zesty? The regressions in postgresql-debversion/1.0.8-2 tests can be ignored (-2 is not built, so it can't be installed), and the regression of apt on i386 is some weird timing issue (it's the test checking that download progress has a step between 0 and 100) - I retried it once, but it seems a bit pointless to try again.
[19:05] <juliank> (or anyone else)
[19:07]  * juliank just tags persons more or less randomly
[19:08] <infinity> juliank: I'll have a look at it in a bit.
[19:08] <juliank> :)
[19:09] <juliank> The postgresql thing is a bit weird. I wonder why autopkgtest tries against the unbuilt zesty-proposed version rather than the one in zesty
[19:10] <juliank> But that's really a problem to solve sometime else
[19:11] <sarnold> man pitti has great timing doesn't he? :)
[19:15] <mterry> cjwatson: no progress on bug 1648603 yet...  do you know the RT number?  Trying to find levers to put pressure on it
[19:15] <ubottu> bug 1648603 in Canonical System Image "consistent timeouts of lp built snaps uploading to store" [High,Confirmed] https://launchpad.net/bugs/1648603
[19:16] <juliank> mvo: Sort of thinking about prioritizing the fix for bug 1649959 - despite what https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841763 says, I think that's actually a regression in 1.3.y only, as I broke that when simplifying the build system
[19:16] <ubottu> Debian bug 841763 in apt "unattended-upgrades: Breaks hard when apt is upgraded" [Grave,Fixed]
[19:16] <ubottu> bug 1649959 in apt (Ubuntu Yakkety) "unattended upgrade of apt kills running apt-daily job" [High,Confirmed] https://launchpad.net/bugs/1649959
[19:17] <juliank> Basically can SRU that as 1.3.3 this week, and push the other less important fixes from 1.4 betas into 1.3.4
[19:19] <juliank> (The other stuff is mostly fixes for the whole installation ordering stuff introduced in 1.3)
[19:21] <juliank> (For 1.3.4 I also want to pull in new translations from master, I'll figure out the workflow for that soon...)
[19:33] <juliank> Ah, let's just do this.
[19:40] <juliank> infinity: If it's not to much to ask, I just uploaded that 1.3.3 SRU to yakkety-proposed fixing bug 1649959, so if you accept the zesty one, it would be nice to get this approved for -proposed (it contains a tiny fix from 1.4~beta1)
[19:40] <ubottu> bug 1649959 in apt (Ubuntu Yakkety) "unattended upgrade of apt kills running apt-daily job" [High,Confirmed] https://launchpad.net/bugs/1649959
[19:43] <juliank> (because this depends on 1.4~beta2 being accepted to zesty first if we want to play nice)
[19:45] <infinity> juliank: Ouch, that's an unfortunate bug.  xenial's unaffected?
[19:45] <infinity> Oh, no, the report was on xenial.
[19:46] <infinity> Or, the reporter can't spell "yakkety". :)
[19:46] <juliank> infinity: It really only effects yakkety and zesty
[19:46] <juliank> (zesty until 1.4~beta2 moves out of proposed :))
[19:46] <infinity> juliank: Yeah.  The reporter said "my new xenial system", but the autogenerated bits of the bug report clearly said yakkety. :)
[19:47] <juliank> I messed that up when I rewrote the packaging after the move to cmake in 1.3
[19:48] <juliank> It might even be critical, not only high
[19:48] <juliank> But I could not really decide
[19:48] <infinity> It's critical, except also not, given it only happens on upgrade, so the damage is probably mostly done.
[19:49] <juliank> infinity: In fact, it only ever happened once so far after release: For the security update.
[19:49] <infinity> juliank: Right, because we configure unattended-upgrades to be on by default for security-only.
[19:49] <infinity> juliank: So much wider exposure to u-a bugs in security than in updates. :/
[19:50] <juliank> Yeah that, and because there was no other apt update yet anyway
[19:50] <infinity> If the only fix in this is that, I might suggest we do it in the security pocket as a fixup for the previous upload, to mitigate the impact for people who haven't yet upgraded.
[19:51] <infinity> Though, I guess the way u-a works, everyone who was going to be affected was affected in the first 24h.
[19:51] <infinity> So meh.
[19:52] <infinity> juliank: Congrats on using a new build system that still generates pointless noise in docs. ;)
[19:54] <juliank> infinity: Actually, we update the timestamps in the manpages so it matches the day the update is released. and po4a updates the timestamp in the doc/po files
[19:54] <infinity> juliank: Yeah, that's silly, IMO.  But, to each their own.
[19:54] <juliank> Otherwise we'd have to manually update the timestamps when we change the files. We'd forget to do that.
[19:54] <infinity> juliank: If the content hasn't changed, I see no reason to update the times.
[19:55] <juliank> Right. We could add a check to CI to enforce date changes  on content changes instead
[19:55] <juliank> Or even in the pre-build hook
[19:56] <infinity> juliank: If you kept the generated files in your VCS, your generation script could just do "generate > file.new && diff old new && update-times" or whatever.
[19:56] <infinity> juliank: Not that glibc is an example of the world's best git usage (it so isn't), but we keep generated files checked in for that (and other) reason.
[19:57] <juliank> There are not really generated files anymore.
[19:57] <infinity> If re-generating doesn't cause an actual change, no need to re-commit a new version.
[19:57] <juliank> It just updates the existing files.
[19:57] <infinity> Oh.  That's more problematic indeed.
[19:57] <juliank> And for doc/po it's po4a doing the stuff. I guess I could ask there.
[19:58] <infinity> juliank: Yeah.  There are two types of the bug/misfeature represented here.  doc/po updating POT-Creation-Date and Project-Id-Version pointlessly, and then doc/*xml having <date> bits updated.
[19:59] <infinity> juliank: It's a LOT less noise than apt updates used to generate, so overall you seem to be winning. :P
[19:59] <juliank> infinity: I guess if we see more unattended-upgrade issues in the next update, it would still be possible (for security team) to just copy 1.3.3 from -proposed to -security?
[19:59] <infinity> juliank: We don't copy from updates to security, because you might have binary deps that only exist in updates.
[20:00] <juliank> Ah, right.
[20:00] <infinity> juliank: But they could do a no-change rebuild into security (or, we could manually examine the deps to determine the copy is safe)
[20:01] <infinity> Given apt's deps, it's a fair chance it's safe.
[20:01] <infinity> You don't exactly pull in the world.
[20:01] <juliank> And there have not been many updates in yakkety anyway
[20:03] <infinity> I need sugar.
[20:04] <infinity> Well, food, which I will turn into sugar, because I'm a badass digesting MACHINE.
[20:04] <sarnold> high-five!
[20:06] <mwhudson> morning
[20:38] <mwhudson> what's the voodoo to run an autopkgtest with two packages from -proposed?
[20:38] <mwhudson> on the production infra, i mean
[20:42] <infinity> mwhudson: Via the cgi?
[20:42] <infinity> mwhudson: multiple trigger= arguments.
[20:42] <mwhudson> infinity: yes
[20:42] <mwhudson> ah ok
[20:43] <mwhudson> thanks
[20:43] <infinity> mwhudson: Triggers are given as package/version pairs, so if you give a few triggers, all those sets will be upgraded to said version before running the test.
[20:43] <infinity> source_package/version, that is.  It sorts out the mapping.
[20:43] <mwhudson> infinity: also, i thought that if the package in proposed depended on a (package, version) that was only in proposed, britney would do this for me
[20:44] <infinity> mwhudson: If the deps are correct, yes, it'll Just Work.
[20:44] <mwhudson> infinity: but that doesn't seem to be the case, was that just wishful thinking on my part?
[20:44] <infinity> mwhudson: Example?
[20:44] <mwhudson> infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#docker.io
[20:44] <infinity> mwhudson: Which test?  The docker one?
[20:45] <mwhudson> infinity: docker-in-lxd fails, but basic-smoke only passes because of the "autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed" thing
[20:46] <mwhudson> confirmed locally that taking both docker.io and runc from proposed passes
[20:46] <infinity> Ahh.  Yes, that would be a bug in your tests. ;)
[20:47] <infinity> Or, a misfeature of the infra which causes your tests to be naively buggy.
[20:47] <mwhudson> ?
[20:47] <infinity> You copy our /etc/apt into the container, which has the pin which makes the installation fail.
[20:47] <infinity> We have no way to detect that situation and try again.
[20:47] <mwhudson> sure
[20:48] <mwhudson> but as above, the deps on docker.io in proposed should make britney make autopkgtest use runc from proposed too, right?
[20:48] <infinity> It's not that smart, no.
[20:48] <infinity> We could make it be that smart, since britney had that info.
[20:49] <infinity> s/had/has/
[20:49] <infinity> ie: because of "Depends: docker.io runc (not considered)", we could force the trigger to always be docker.io + runc
[20:49] <mwhudson> i see
[20:49] <infinity> But currently, that's not how it works.
[20:49] <mwhudson> so what did you mean by "<infinity> mwhudson: If the deps are correct, yes, it'll Just Work." then? :)
[20:49] <infinity> Well, because of the auto-retry.
[20:50] <mwhudson> i would offer to look into this, but unfortunately i've looked at the britney code before
[20:50] <infinity> Which fails miserably for you because it's not autopkgtest doing your install. :P
[20:50] <mwhudson> oh, right
[20:50] <mwhudson> yeah
[20:50] <infinity> The test triggering bit that needs mangling here might not be super scary.
[20:52] <mwhudson> hooray for non insane autopkgtest queues, i might find out if that worked today
[20:58] <mwhudson> uh
[20:58] <mwhudson> where is the britney2-ubuntu branch now?
[20:58] <mwhudson> lots of things link to https://code.launchpad.net/~ubuntu-release/+git/britney2-ubuntu but that doesn't exist
[20:59] <infinity> I updated the link in the bzr branch just now. :P
[20:59] <mwhudson> haha
[20:59] <infinity> https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu
[20:59] <mwhudson> thanks
[21:00] <infinity> But, basically, if one greps for "not considered" in britney2/excuses.py, one sees the bits that need to be massaged down to the autopkgtest triggering bits.
[21:00] <infinity> Doing so may prove painful.
[21:08] <clivejo> Is anyone having network problems in zesty?  I had to boot into recovery to reinstall a nvidia driver for kernel 4.9 and there was no network connections.  It wiped out all the entries in /etc/network/interfaces except for lo0 and also resolv.config was wiped too
[21:08] <infinity> mwhudson: Actually, might not be that bad.  Assuming this structure policy is fed is what I think it is.
[21:09] <clivejo> I had to configure everything manually, install the new driver and booted back into Plasma (Kubuntu) which had all my network connections available as before
[21:10] <clivejo> another colleague has noticed this behaviour in Lubuntu and Kubuntu
[21:10] <infinity> clivejo: If all your networking has been delegated to network-manager, that's pretty much how it would work, yes.
[21:11] <infinity> clivejo: Which has been true for, well, ever.
[21:11] <infinity> (on desktop installs, anyway)
[21:11] <clivejo> never noticed this before :/
[21:11] <infinity> Recovery didn't "wipe out" anything, there just aren't interfaces entries on your machine.
[21:12] <infinity> Because ifupdown isn't what's doing your networking.
[21:12] <clivejo> this is an upgrade from yakkety and yakkety didnt do that
[21:12] <infinity> It sure did.
[21:12] <infinity> And so did xenial.
[21:12] <infinity> And trusty.
[21:13] <infinity> And precise. :P
[21:13] <infinity> (I could keep listing)
[21:13] <clivejo> nope, always had networking in recovery
[21:13] <infinity> Do you configure with a static IP in the installer?
[21:13] <infinity> That's the only case that might have changed.
[21:13] <infinity> DHCP in the GUI installers has been network-manager for ages.
[21:14] <clivejo> no idea, I cant remember installing it!
[21:14] <clivejo> just upgrade from +1 to +1
[21:14] <infinity> I could indeed see it as a bug that network-manager isn't invoked on entering recovery, but I don't think it ever was.
[21:15] <clivejo> by recovery I mean via Grub and selecting the (Recovery) option
[21:15] <infinity> Yeah, I know what you mean.
[21:28] <bdmurray> flexiondotorg: What's the status of bug 1623856?
[21:28] <ubottu> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
=== devfil is now known as dfiloni
=== dfiloni is now known as devfil
[22:10] <cjwatson> mterry: I see Bret has replied.
[22:10] <mterry> cjwatson: yes, looks like they are on it and listed the RT, thanks
[22:15] <nacc> slangasek: i just noted that ubuntu-archive is already subscribed to LP: #1593024; I just put in a comment asking for the deletion of src:zend-framework. Do you think a new bug is necessary?
[22:15] <ubottu> Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1593024
[22:17] <mterry> @pilot out
[22:17] <slangasek> nacc: adjust the bug title to mention that you want a thing deleted?
[22:18] <slangasek> nacc: fwiw the binary package is not why it needs manually deleted; it needs manually deleted because it's a source package and not from Debian
[22:18] <tjaalton> is filing a bileto ticket a one-time thing per package, or per upload?
[22:18] <slangasek> and the binary package already got deleted to let things pass proposed-migration
[22:19] <slangasek> tjaalton: per "landing"
[22:19] <slangasek> you can iterate multiple uploads as part of a landing, but you only publish to the archive once for the ticket
[22:19] <tjaalton> right
[22:19] <nacc> slangasek: good point, will do
[22:19] <tjaalton> ok
[22:20] <tjaalton> I'll go read the wiki next :)
[22:46] <Bluefoxicy> is #1641380 just a matter of bandwidth, or is there a problem getting a fixed package built?
[22:47] <Bluefoxicy> I mean building a package for a web browser isn't rocket science, but when you have 16,000 packages to maintain in a distribution that's supposed to work as a whole I imagine things can queue up a little.
[22:51] <nacc> Bluefoxicy: what versino of ubuntu?
[22:53] <Bluefoxicy> nacc:  it's 16.10
[22:54] <Bluefoxicy> I'm just curious whether the devs have 6000 other things to get to (like a 6-month release cycle distro to build) or if there's some sort of failure that everybody is scratching their heads over
[22:54] <Bluefoxicy> it's kind of odd to see something fixed in the last release's package, then re-opened when it turns out broken in current, then no activity or explanation for 2 days
[22:59] <sarnold> it's usually better to open new bugs rather than comment on existing, closed, bugs, when issues re-appear
[22:59] <nacc> there seem to be two problems in this bug (my opinion): 1) people using the ppa mentioned by someone (not the uploader) and complaining -- when the ppa specifically says 'You shouldn't use this'; 2) it seems like the fix possibly never went out to 16.10? c#67 refers to an upload to the PPA, but that's past the version in yakkety acc'g to rmadison
[23:00]  * nacc doesn't know how the chromium developers do things, but notices there are no per-release tasks, so it's hard to say where what has been fixed in that one bug
[23:13] <Bluefoxicy> yeah
[23:14] <nacc> and as sarnold mentioned, it's possible some things have been fixed in the context of that bug, but there are other fixes that are now needed
[23:14] <Bluefoxicy> what I can see so far is that cmiller re-opened the bug after a bunch of user reports, but nobody posted anything referencing a new bug or mentioning e.g. that a package failed to build for an unknown reason
[23:14] <Bluefoxicy> people will eventually perceive that they're being ignored
[23:15] <Bluefoxicy> hence the point of making pointless status updates like "We have no idea why it's not working, trying to fix"
[23:15] <Bluefoxicy> like okay, that doesn't get us any closer, but at least people don't wonder if you marked it as re-open and then went to watch anime
[23:15] <Bluefoxicy> ...
[23:16] <nacc> Bluefoxicy: right, but i think you want to talk to cmiller about that, presumably
[23:16] <nacc> not 'devs' in general
[23:16] <nacc> or ask explicitly in that bug
[23:16] <Bluefoxicy> fair enough
[23:17] <Bluefoxicy> I'm just taking a moment to reflect on how ... unpleasant ... it is that a large part of human communication is simply trying to prevent people from making shit up and assuming it's true.  :|
[23:17] <Bluefoxicy> anyway I'll make a comment to that effect on the bug.
[23:18] <nacc> as i said, i don't think a fix was *ever* rolled out for yakkety, based upon the changelog in yakkety (there's only been one version published in yakkety (well the released version, afaict))
[23:18] <nacc> i'm guessing cmiller was focusing on getting the LTS fixed
[23:18] <Bluefoxicy> yeah, it was only rolled out into LTS
[23:19] <nacc> so could simply be oversight
[23:19] <nacc> or as you said, overworked :)
[23:19] <Bluefoxicy> I'm mostly being a pest trying to gather information and understand what's happening.  I don't get as distressed over stuff like that anymore, but I still like to have a full narrative.
[23:19] <Bluefoxicy> Though, as I said, people in general will rage and then develop an imaginative narrative of what's happening, then take it to heart.
[23:21] <nacc> people will always rage :)
[23:21] <Bluefoxicy> I find that the scope and depth of rage can indicate whether to negotiate or to simply ignore them
[23:54] <nacc> rbasak: so i found one gap in our 'process' -- at least afaict. In LP: #1644428 you helped foster through a revert of a SRU regression. However, the patch is still applied in yakkety-proposed (which was devel at the time, I think) and zesty (release). So we should revert it in both places, afaict? That is, 2:4.4.5+dfsg-2ubuntu5.2 should be uploaded for 16.10 and in the process of the merge, I should
[23:54] <ubottu> Launchpad bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Fix released] https://launchpad.net/bugs/1644428
[23:54] <nacc> drop these changes?
[23:58] <nacc> caribou: mdeslaur: --^ you also may have context here
[23:59] <nacc> iiuc, the conclusion is the uploaded fix was incorrect as it broke functional winbind configurations. So it has since been reverted and should also be reverted in zesty (and y-p). But then there is no actual fix for the original problem in LP: #1584485 ?
[23:59] <ubottu> Launchpad 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