naccslangasek: 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:13
slangaseknacc: ack; please file a bug against the zend-framework source package for this and subscribe ubuntu-archive00:44
naccslangasek: will do, thanks!00:46
slangasekrharper: 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
ubottuLaunchpad bug 1636912 in resolvconf (Ubuntu Yakkety) "systemd-networkd runs too late for cloud-init.service (net)" [Undecided,In progress] https://launchpad.net/bugs/163691200:51
slangasekrharper: 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 changes00:53
rharperslangasek: 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:09
rharperslangasek: 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 wasn01:11
rharper't updated either ; snap installs failed as we could reach assertions.ubuntu.com etc.01:11
rharperslangasek: 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 networking01:12
=== JanC is now known as Guest9817
=== JanC_ is now known as JanC
cpaelzergood morning06:42
* alkisg just learned that pitti is no longer around here... :D Thanks for everything and wishing you all the best!07:33
=== shuduo-afk is now known as shuduo
smbIs 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.09:17
=== hikiko is now known as hikiko|off
xnoxsmb, use google chrome =)10:15
smbxnox, 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 chromium10:17
xnoxsmb, well we did better than that, and pushed out latest firefox v52 to all stable users.10:23
xnoxi use google chrome, as it has Adobe based pdf renderer and Adobe based flash plugin, proprietary, built in, and sandboxed.10:24
xnoxand from security point of view, i am naive to think that google chrome is "secure" and updated "faster".10:25
smbxnox, 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 config10:26
smbxnox, Mainly I user firefox because it was there before and I am too lazy to change10:27
xnoxsmb, oh, the killer feature of google chrome is that it can track multiple google accounts and easily switch between them.10:27
xnoxbecause one can have a user/profile, per google account ChromeOS style.10:28
smbxnox, 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 default10:28
xnoxsmb, huh, it is 50.1 everywhere. which is latest, no idea how i saw 52 given that it does not exist yet =)10:29
xnoxgoogle chrome picks last active window one. So if i had canonical calendar open, clicking a link will open things in that profile.10:29
smbxnox, 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 irc10:31
xnoxso 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
xnoxstill pain =/10:34
smbindeed, but to a certain degree we all love some pain... or we would not be working in open software... ;-P10:36
xnoxsmb, 50 shades of aubergine.... =)11:10
juliankxnox: 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:10
juliank(excluding the pdfium library itself, which is at https://pdfium.googlesource.com/)11:12
xnoxjuliank, 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.11:40
=== _salem is now known as salem_
mitya57Can 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:18
xnoxerror: ("/usr/lib/powerpc64le-linux-gnu/ada/adalib/aws/aws-exceptions.ali" is obsolete and read-only)12:21
xnoxlooks odd12:21
xnoxmitya57, does it need to be recompiled again for some reason due to arch skew or some such?12:21
xnoxe.g. it is likely that ppc64el/s390x builds finished before other arches.12:21
mitya57Maybe, should I try a new rebuild?12:22
xnoxmitya57, we can do that in a bileto silo, and it will run autopkgtest to verify that claim.12:24
xnoxhowever, maybe makes no difference to just use the archive direct. Upload no change rebuild of libaws again?12:25
mitya57xnox, If there is a chance that it will fix the failure, I can do a rebuild in the archive12:26
xnoxwith my limited knowledge, i would try to rebuild the source package which ships /usr/lib/powerpc64le-linux-gnu/ada/adalib/aws/aws-exceptions.ali12:27
mitya57(sorry, got distracted by other work)12:53
mitya57xnox, that file is from libaws3.3.2-dev, so the same source package12:54
slashdrbasak, 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 Xenial13:35
ubottuLaunchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Medium,In progress]13:35
rbasakslashd: I like that approach.13:36
rbasakI'll need to think about it some more though.13:36
slashdrbasak, sure me too, it's just a draft, but I think it worth evaluating it13:37
slashdcaribou FYI ^13:38
mterrytjaalton: 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 why13:48
tjaaltonmterry: haven't checked yet, will have a look13:49
mterryIt seems like mesa itself has been stuck in -proposed a while13:50
tjaaltonit should migrate but plasma-framework is holding it back13:50
tjaaltonmterry: what test is failing?13:51
xnoxtjaalton, unity8 adt tests segfault13:53
mterrytjaalton: several tests segfault, about ten total I think.  For example, xvfbtestPreviewExpandable.  They only segfault with xvfb, in my testing13:53
tjaaltonmterry: then that's again caused by libepoxy, which was fixed13:54
tjaaltonlast week13:54
mterryI don't know if we're the only package affected, but I just happened to notice it with us13:54
tjaaltonor, new mesa triggers the bug in libepoxy, which got fixed there13:54
tjaaltonso, rerun the test13:55
mterrytjaalton: unity8's upload was yesterday I believe13:55
xnoxtjaalton, we are rerunning the tests with all-proposed=113:56
xnoxwe should have fresh results soon.13:57
tjaaltonhttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/u/unity8/20161213_153305_7636d@/log.gz ?13:57
smbso... 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
tjaaltonmterry: do they segfault with latest libepoxy?13:59
smb*privacy badger (extension)14:00
xnoxtjaalton, 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-unity814:00
mterrytjaalton with version 1.3.1-1ubuntu1 in current zesty, yes they still segfault14:01
tjaaltonlooks like libepoxy is latest14:01
tjaaltondunno then what it is..14:01
tjaaltonget a bt?14:01
mterrytjaalton: that is the log above yeah14:02
mterrytjaalton: a bt?14:02
mterrytjaalton: oh I did manage to catch it but the stacktrace looked abreviated.  It was just one frame, inside libgcc14:02
mterrySo I figured it had been corrupted14:03
mterryMaybe I didn't have enough dbg packages either tho14:03
mterrytjaalton: I can help get you to the point where you can reproduce and catch in gdb if we go down that route14:04
tjaaltonmterry: other option is that I bisect mesa to find out what caused the original bug, and then revert it14:05
mterryI'll see if I can get a better stacktrace over here14:05
tjaaltonmterry: is there a (small) qt app to test with xvfb?14:13
tjaaltonon the default desktop14:13
mterrytjaalton: probably one of the qt example apps? qtbase5-examples14:14
mterrytjaalton: the segfault is seen when the test is finishing/closing14:15
tjaaltonrunning "openglwindow" on xvfb results in "could not initialize opengl"14:19
tjaaltonand then it aborts14:19
tjaaltonhm, that happens with older mesa too, so it's not that14:24
mterrytjaalton: 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 suspicious14:31
fossfreedomsil2100: Hi!  any news on the best way to recognise officially ~ubuntubudgie-dev ?14:31
mterrynope, just the one threa14:32
mterrymemory must just be trashed by this point14:32
=== giraffe is now known as Guest59158
mterrytjaalton: I guess I'll try to catch it just before it crashes -- any luck on your side getting a reproduction?14:42
tjaaltonmterry: not yet14:42
tjaaltonbut I'll just use the gtk case14:42
tjaaltonand revert libepoxy to an older release, then bisect mesa..14:43
tjaaltonreopened the upstream bug too14:43
mterrytjaalton: if it's easier, I could get you set up to run the unity8 test.  But sounds like you have a known gtk crasher14:43
tjaaltonone thing I noticed is that with mesa 12 I get a libgl error failing to load swrast, while it's there14:44
tjaaltonwith 13 I don't get that14:44
sil2100fossfreedom: there was some discussion regarding that, need to get back to it after - let me poke you laterish (or tomorrow at latest)14:47
fossfreedommuch appreciated.14:48
krytarikfossfreedom: 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.py14:51
fossfreedomkrytarik: hi - and damn - you are correct!  will fix tonight when I can get back to my computer.14:53
krytarikfossfreedom: Also, just noticed, regarding ~ubuntubudgie-dev, I think you want to invite ~ubuntu-core-dev as a member, rather than ~ubuntu-dev.14:58
fossfreedomlooking ...14:59
mterryLooks 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 probably15:00
tjaaltonhuh, ok :)15:00
mterrytjaalton: and in fact, it might still prevent a lot of stuff from migrating, because they'll trigger our u8 tests15:01
fossfreedomkrytarik: hmm - not obvious how to "uninvite" a team on launchpad.  Any ideas?15:01
mterryxnox: so unity8 landed, was that because of the  all-proposed=1 run?15:04
krytarikfossfreedom: LP bug #656782. >_>15:11
ubottuLaunchpad bug 656782 in Launchpad itself "No way to cancel (retract) pending team invitation" [Low,Triaged] https://launchpad.net/bugs/65678215:11
fossfreedomoh - outstanding since 2010 :(15:12
=== scottt is now known as Guest26786
xnoxmterry, 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/i38615:25
xnoxmterry, i'm not sure which rerun was good (e.g. with all-proposed or without)15:26
slangasekrharper: 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
ubottuLaunchpad bug 1636912 in resolvconf (Ubuntu Yakkety) "systemd-networkd runs too late for cloud-init.service (net)" [Undecided,In progress] https://launchpad.net/bugs/163691215:26
mterryxnox: 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 anyway15:27
rharperslangasek: sure;  I don't believe we're regressing anyone as nothing besides UC16 + cloud-init (using netword) is affected by the required changes to resolvconf15:27
xnoxmterry, 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
rharperslangasek: after I mark verification-done;  what's the next steps for queuing up the resolvconf SRU ?15:28
xnoxmterry, so e.g. mir, qtmir, mesa should still be stuck, and should still be reproducible.15:28
mterryxnox: yeah15:28
slangasekrharper: 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 SRU15:28
xnoxmterry, right. So the failed log has --apt-pocket=proposed15:28
slangasekrharper: the SRU bug will still need adjusting so that the test case addresses the DNS part15:29
rharperslangasek: ok, let me verify the latest systemd works as expected in UC16 image I'm testing cloud-init changes15:29
xnoxmterry, 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:29
xnoxtjaalton, 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:30
sil2100This is why Bileto has its merits15:31
mterryWe could drop mesa from proposed?15:32
mterry(/ re-upload old version with later version)15:33
rharperslangasek: 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
rharperin the second SRU we'll have a systemd change and an updated resolvconf  paired15:35
slangasekrharper: 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 SRU15:36
rharperslangasek: OK, marking done, filing new bug against systemd and resolvconf for DNS early with networkd15:37
tjaaltonxnox: never heard of that15:43
xnoxtjaalton, 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
xnoxtjaalton, aka ~= the kernel team workflow, as well as touch/phablet/personal.15:44
xnoxmost of it w.r.t. branch management and merging is irrelevant, if one knows how to prepare .dsc and dput things into ppa15:45
rharperslangasek: filed https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/164993115:47
ubottuLaunchpad bug 1649931 in systemd (Ubuntu) "systemd-networkd needs to ensure DNS is up before network-online.target" [Undecided,New]15:47
rharperslangasek: ok, verified15:58
slangasekrharper: ta!15:58
slangasekrharper: can you reupload resolvconf with the new bug # also?15:59
rharperI cannot reupload, but I can attach the debdiffs to the new bug15:59
slangasekrharper: ok, then I'll reupload15:59
=== pavlushka is now known as The_Doctorman
=== The_Doctorman is now known as pavlushka
slangasekrharper: would accept resolvconf now, but there's no testcase in the SRU bug16:19
rharperok, I'll write up something16:19
clivejoHi, 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=zesty17:23
xnoxclivejo, because those architectures use gles and krita is not compatible with it?17:45
mterry@pilot in17:49
mterryhmm no bot17:53
hjdHello, 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
mterryhjd: yeah probably -- I'll look at it18:37
hjdmterry: Thanks :)18:45
mterryhjd: just started sync18:46
juliankinfinity: 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:04
juliank(or anyone else)19:05
* juliank just tags persons more or less randomly19:07
infinityjuliank: I'll have a look at it in a bit.19:08
juliankThe postgresql thing is a bit weird. I wonder why autopkgtest tries against the unbuilt zesty-proposed version rather than the one in zesty19:09
juliankBut that's really a problem to solve sometime else19:10
sarnoldman pitti has great timing doesn't he? :)19:11
mterrycjwatson: no progress on bug 1648603 yet...  do you know the RT number?  Trying to find levers to put pressure on it19:15
ubottubug 1648603 in Canonical System Image "consistent timeouts of lp built snaps uploading to store" [High,Confirmed] https://launchpad.net/bugs/164860319:15
juliankmvo: 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 system19:16
ubottuDebian bug 841763 in apt "unattended-upgrades: Breaks hard when apt is upgraded" [Grave,Fixed]19:16
ubottubug 1649959 in apt (Ubuntu Yakkety) "unattended upgrade of apt kills running apt-daily job" [High,Confirmed] https://launchpad.net/bugs/164995919:16
juliankBasically can SRU that as 1.3.3 this week, and push the other less important fixes from 1.4 betas into 1.3.419:17
juliank(The other stuff is mostly fixes for the whole installation ordering stuff introduced in 1.3)19:19
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:21
juliankAh, let's just do this.19:33
juliankinfinity: 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
ubottubug 1649959 in apt (Ubuntu Yakkety) "unattended upgrade of apt kills running apt-daily job" [High,Confirmed] https://launchpad.net/bugs/164995919:40
juliank(because this depends on 1.4~beta2 being accepted to zesty first if we want to play nice)19:43
infinityjuliank: Ouch, that's an unfortunate bug.  xenial's unaffected?19:45
infinityOh, no, the report was on xenial.19:45
infinityOr, the reporter can't spell "yakkety". :)19:46
juliankinfinity: It really only effects yakkety and zesty19:46
juliank(zesty until 1.4~beta2 moves out of proposed :))19:46
infinityjuliank: Yeah.  The reporter said "my new xenial system", but the autogenerated bits of the bug report clearly said yakkety. :)19:46
juliankI messed that up when I rewrote the packaging after the move to cmake in 1.319:47
juliankIt might even be critical, not only high19:48
juliankBut I could not really decide19:48
infinityIt's critical, except also not, given it only happens on upgrade, so the damage is probably mostly done.19:48
juliankinfinity: In fact, it only ever happened once so far after release: For the security update.19:49
infinityjuliank: Right, because we configure unattended-upgrades to be on by default for security-only.19:49
infinityjuliank: So much wider exposure to u-a bugs in security than in updates. :/19:49
juliankYeah that, and because there was no other apt update yet anyway19:50
infinityIf 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:50
infinityThough, I guess the way u-a works, everyone who was going to be affected was affected in the first 24h.19:51
infinitySo meh.19:51
infinityjuliank: Congrats on using a new build system that still generates pointless noise in docs. ;)19:52
juliankinfinity: 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 files19:54
infinityjuliank: Yeah, that's silly, IMO.  But, to each their own.19:54
juliankOtherwise we'd have to manually update the timestamps when we change the files. We'd forget to do that.19:54
infinityjuliank: If the content hasn't changed, I see no reason to update the times.19:54
juliankRight. We could add a check to CI to enforce date changes  on content changes instead19:55
juliankOr even in the pre-build hook19:55
infinityjuliank: 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
infinityjuliank: 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:56
juliankThere are not really generated files anymore.19:57
infinityIf re-generating doesn't cause an actual change, no need to re-commit a new version.19:57
juliankIt just updates the existing files.19:57
infinityOh.  That's more problematic indeed.19:57
juliankAnd for doc/po it's po4a doing the stuff. I guess I could ask there.19:57
infinityjuliank: 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:58
infinityjuliank: It's a LOT less noise than apt updates used to generate, so overall you seem to be winning. :P19:59
juliankinfinity: 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
infinityjuliank: We don't copy from updates to security, because you might have binary deps that only exist in updates.19:59
juliankAh, right.20:00
infinityjuliank: But they could do a no-change rebuild into security (or, we could manually examine the deps to determine the copy is safe)20:00
infinityGiven apt's deps, it's a fair chance it's safe.20:01
infinityYou don't exactly pull in the world.20:01
juliankAnd there have not been many updates in yakkety anyway20:01
infinityI need sugar.20:03
infinityWell, food, which I will turn into sugar, because I'm a badass digesting MACHINE.20:04
mwhudsonwhat's the voodoo to run an autopkgtest with two packages from -proposed?20:38
mwhudsonon the production infra, i mean20:38
infinitymwhudson: Via the cgi?20:42
infinitymwhudson: multiple trigger= arguments.20:42
mwhudsoninfinity: yes20:42
mwhudsonah ok20:42
infinitymwhudson: 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
infinitysource_package/version, that is.  It sorts out the mapping.20:43
mwhudsoninfinity: also, i thought that if the package in proposed depended on a (package, version) that was only in proposed, britney would do this for me20:43
infinitymwhudson: If the deps are correct, yes, it'll Just Work.20:44
mwhudsoninfinity: but that doesn't seem to be the case, was that just wishful thinking on my part?20:44
infinitymwhudson: Example?20:44
mwhudsoninfinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#docker.io20:44
infinitymwhudson: Which test?  The docker one?20:44
mwhudsoninfinity: 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" thing20:45
mwhudsonconfirmed locally that taking both docker.io and runc from proposed passes20:46
infinityAhh.  Yes, that would be a bug in your tests. ;)20:46
infinityOr, a misfeature of the infra which causes your tests to be naively buggy.20:47
infinityYou copy our /etc/apt into the container, which has the pin which makes the installation fail.20:47
infinityWe have no way to detect that situation and try again.20:47
mwhudsonbut as above, the deps on docker.io in proposed should make britney make autopkgtest use runc from proposed too, right?20:48
infinityIt's not that smart, no.20:48
infinityWe could make it be that smart, since britney had that info.20:48
infinityie: because of "Depends: docker.io runc (not considered)", we could force the trigger to always be docker.io + runc20:49
mwhudsoni see20:49
infinityBut currently, that's not how it works.20:49
mwhudsonso what did you mean by "<infinity> mwhudson: If the deps are correct, yes, it'll Just Work." then? :)20:49
infinityWell, because of the auto-retry.20:49
mwhudsoni would offer to look into this, but unfortunately i've looked at the britney code before20:50
infinityWhich fails miserably for you because it's not autopkgtest doing your install. :P20:50
mwhudsonoh, right20:50
infinityThe test triggering bit that needs mangling here might not be super scary.20:50
mwhudsonhooray for non insane autopkgtest queues, i might find out if that worked today20:52
mwhudsonwhere is the britney2-ubuntu branch now?20:58
mwhudsonlots of things link to https://code.launchpad.net/~ubuntu-release/+git/britney2-ubuntu but that doesn't exist20:58
infinityI updated the link in the bzr branch just now. :P20:59
infinityBut, 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
infinityDoing so may prove painful.21:00
clivejoIs 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 too21:08
infinitymwhudson: Actually, might not be that bad.  Assuming this structure policy is fed is what I think it is.21:08
clivejoI had to configure everything manually, install the new driver and booted back into Plasma (Kubuntu) which had all my network connections available as before21:09
clivejoanother colleague has noticed this behaviour in Lubuntu and Kubuntu21:10
infinityclivejo: If all your networking has been delegated to network-manager, that's pretty much how it would work, yes.21:10
infinityclivejo: Which has been true for, well, ever.21:11
infinity(on desktop installs, anyway)21:11
clivejonever noticed this before :/21:11
infinityRecovery didn't "wipe out" anything, there just aren't interfaces entries on your machine.21:11
infinityBecause ifupdown isn't what's doing your networking.21:12
clivejothis is an upgrade from yakkety and yakkety didnt do that21:12
infinityIt sure did.21:12
infinityAnd so did xenial.21:12
infinityAnd trusty.21:12
infinityAnd precise. :P21:13
infinity(I could keep listing)21:13
clivejonope, always had networking in recovery21:13
infinityDo you configure with a static IP in the installer?21:13
infinityThat's the only case that might have changed.21:13
infinityDHCP in the GUI installers has been network-manager for ages.21:13
clivejono idea, I cant remember installing it!21:14
clivejojust upgrade from +1 to +121:14
infinityI 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:14
clivejoby recovery I mean via Grub and selecting the (Recovery) option21:15
infinityYeah, I know what you mean.21:15
bdmurrayflexiondotorg: What's the status of bug 1623856?21:28
ubottubug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/162385621:28
=== devfil is now known as dfiloni
=== dfiloni is now known as devfil
cjwatsonmterry: I see Bret has replied.22:10
mterrycjwatson: yes, looks like they are on it and listed the RT, thanks22:10
naccslangasek: 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
ubottuLaunchpad 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/159302422:15
mterry@pilot out22:17
slangaseknacc: adjust the bug title to mention that you want a thing deleted?22:17
slangaseknacc: fwiw the binary package is not why it needs manually deleted; it needs manually deleted because it's a source package and not from Debian22:18
tjaaltonis filing a bileto ticket a one-time thing per package, or per upload?22:18
slangasekand the binary package already got deleted to let things pass proposed-migration22:18
slangasektjaalton: per "landing"22:19
slangasekyou can iterate multiple uploads as part of a landing, but you only publish to the archive once for the ticket22:19
naccslangasek: good point, will do22:19
tjaaltonI'll go read the wiki next :)22:20
Bluefoxicyis #1641380 just a matter of bandwidth, or is there a problem getting a fixed package built?22:46
BluefoxicyI 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:47
naccBluefoxicy: what versino of ubuntu?22:51
Bluefoxicynacc:  it's 16.1022:53
BluefoxicyI'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 over22:54
Bluefoxicyit'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 days22:54
sarnoldit's usually better to open new bugs rather than comment on existing, closed, bugs, when issues re-appear22:59
naccthere 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 rmadison22:59
* 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 bug23:00
naccand 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 needed23:14
Bluefoxicywhat 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 reason23:14
Bluefoxicypeople will eventually perceive that they're being ignored23:14
Bluefoxicyhence the point of making pointless status updates like "We have no idea why it's not working, trying to fix"23:15
Bluefoxicylike 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 anime23:15
naccBluefoxicy: right, but i think you want to talk to cmiller about that, presumably23:16
naccnot 'devs' in general23:16
naccor ask explicitly in that bug23:16
Bluefoxicyfair enough23:16
BluefoxicyI'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
Bluefoxicyanyway I'll make a comment to that effect on the bug.23:17
naccas 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
nacci'm guessing cmiller was focusing on getting the LTS fixed23:18
Bluefoxicyyeah, it was only rolled out into LTS23:18
naccso could simply be oversight23:19
naccor as you said, overworked :)23:19
BluefoxicyI'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
BluefoxicyThough, as I said, people in general will rage and then develop an imaginative narrative of what's happening, then take it to heart.23:19
naccpeople will always rage :)23:21
BluefoxicyI find that the scope and depth of rage can indicate whether to negotiate or to simply ignore them23:21
naccrbasak: 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 should23:54
ubottuLaunchpad bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Fix released] https://launchpad.net/bugs/164442823:54
naccdrop these changes?23:54
nacccaribou: mdeslaur: --^ you also may have context here23:58
nacciiuc, 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
ubottuLaunchpad 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/158448523:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!