[01:38] <KurousagiMK2> Hi to all. I have a problem when updating dbus https://paste.ubuntu.com/24895832/ it should be?
[01:44] <jbicha> KurousagiMK2: you probably should not have proposed updates enabled during the development cycle
[01:51] <jbicha> but thanks for mentioning the issue, it should be fixed soon
[01:52] <jbicha> https://launchpad.net/ubuntu/+source/dbus/1.10.18-1ubuntu2
[01:53] <KurousagiMK2> no problem
[06:12] <pitti> jbicha: argh, again? I just fixed it for 1.6
[06:14] <pitti> jbicha: ah, seems to be simple enough, but a bit awkward as the type is version specific
[07:08] <infinity> jbicha: They don't have both installed...
[07:08] <infinity> jbicha: Unless you mean gcc-7-base, which isn't gcc-7 at all.
[07:09] <infinity> jbicha: And gcc-7-base is there because gcc-7 builds libcc1, libstdc++6, etc.
[07:37] <pitti> jbicha: fixed in https://github.com/martinpitt/python-dbusmock/commit/763d0b3 and I also added a G_DEBUG=fatal-warnings,fatal-criticals
[09:50] <rbalint>  jamespage: thanks!, merged
=== NCommander is now known as mcasadevall
=== grumble is now known as Guest38774
=== rumble is now known as grumble
[12:15] <cpaelzer> pitti: does the cockpit i386 test timing out after Barney Bär ring a bell ? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/i386/c/cockpit/20170619_084158_c430e@/log.gz
[12:15] <cpaelzer> I don't think I could have affected this particular test, but at least 2/2 retries now blocked on that
[12:16] <cpaelzer> pitti: starting local repro now, but if something seems to be a known issue to you let me know
[12:34] <sil2100> smoser: hey!
[12:35] <sil2100> smoser: I'm reviewing curting right now for xenial and I see it has a change to the new-upstream-snapshot script that's not in any other series - was wondering why is that so?
[12:36] <sil2100> smoser: is the tarball only removed on file cleaning on xenial?
[12:41] <pitti> cpaelzer: hm no, I haven't seen this before
[12:44] <cpaelzer> pitti: thanks for the reply, I'll let you know what I find debugging this
[12:44] <pitti> cpaelzer: consistently only on 32 bit?
[12:45] <cpaelzer> I didn't rerun the others that worked
[12:45] <cpaelzer> but I had it locally with adt on 64 bit
[12:45] <pitti> cpaelzer: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/c/cockpit/20170615_142334_6e4d7@/log.gz looks similar, so smells like a race, not a regressino
[12:45] <cpaelzer> I'm currently trying to identify if it is 100% repro locally and if so what change it could have been
[12:47] <cpaelzer> yeah that looks the same, that was network manager  ... hmm
[13:02] <sil2100> chrisccoulson_: hey! Just a quick question - the firefox armhf FTBFS is a known issue I guess, right? Is there a bug for that one?
[13:03] <sil2100> chrisccoulson_: I see all the SRUs were released with the build failure so I assume it's known and identified, just wanted to get some context
[13:18] <pitti> jbicha: 0.16.9 now released and uploaded to debian, so it should clear itself up from here on
[13:18] <cpaelzer> pitti: it was a transient issue after all, but with a >50% hit rate at the moment as it seems
[13:18] <pitti> cpaelzer: http://autopkgtest.ubuntu.com/packages/c/cockpit/artful/amd64 looks much better than 50%, but indeed as I said this isn't new
[13:19] <pitti> so retry button short-term for unblocking
[13:19] <cpaelzer> yeah that is what i have chosen for now
[13:19] <pitti> I'll try to reproduce it and see what's wrong
[13:19] <cpaelzer> pitti: maybe scalingstack is busy atm and this increases the chance
[13:19] <cpaelzer> locally I'm pretty much swapping 2-3G already - so when I say reproducable locally it is under constrained conditions
[13:20] <jbicha> pitti: thank you! btw, autosync from sid seems a bit delayed, probably because of the stretch release and so on
[13:21] <pitti> jbicha: at least dbusmock isn't the final/only blocker of NM :)
[13:22] <jbicha> pitti: are you partially responsible for nplan's flaky tests too? ;)
[13:22] <pitti> not any more :)
[13:22] <pitti> they were quite robust when I handed stuff over
[13:23] <jbicha> http://autopkgtest.ubuntu.com/packages/n/nplan/zesty/amd64
[13:23] <jbicha> I think they've always been flaky, at least on a.u.com
[13:25] <jbicha> it does look like they were less flaky in December, convenient! ;)
[13:28] <seb128> wgrant, hey, when do you think we can get artful open for translation on launchpad?
[13:28] <seb128> jbicha, ^
[13:40] <cjwatson> jbicha: Should start in a few hours.  It was delayed because of needing to upgrade debian-archive-keyring before it could verify the signature on dists/stretch
[13:41] <cjwatson> stgraber: Is there some way to ask lxd to abort an image download in progress, or do I have to restart the daemon?
[13:42] <jbicha> cjwatson: thanks!
[13:43] <cpaelzer> jamespage: would you mind looking at http://paste.ubuntu.com/24899381 for a short review before I upload?
[13:43] <cpaelzer> jamespage: the openvswitch-testcontroller dependency is still needed in the test, it really is about stopping the default service to avoid conflicts
[13:55] <xnox> juliank, reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863859 does this mean unattended-upgrade needs to grow more options?
[13:55] <ubottu> Debian bug 863859 in apt "apt: runs unattended-upgrades in debug mode" [Normal,Fixed]
[13:55] <xnox> and we need to sru them?
[13:56] <juliank> xnox: Yes, one additional option, but it's a tiny change. If we don't apt downloads upgrades in the install service, rather the download service
[13:57] <juliank> xnox: We could have used the apt dist-upgrade -d code path, but that might have downloaded updates that were not going to be installed with unattended-upgrades anyway.
[13:57] <juliank> xnox: There's a patch somewhere
[13:57] <xnox> hm.
[13:57] <xnox> imho dist-upgrade -d would have been fine.
[13:58] <juliank> xnox: It's a tiny diff: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=863911;filename=unattended-upgrade.diff;msg=5 - in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863911
[13:58] <ubottu> Debian bug 863911 in unattended-upgrades "unattended-upgrades: Needs a --download-only mode" [Important,Open]
[13:58] <juliank> xnox: The diff contains the change twice, because symlinks...
[13:59] <juliank> That said, the changes are independent, so we can go ahead with one without the other
[13:59] <xnox> yes and no.
[13:59] <xnox> we want an sru of everythings to solve everything =)
[14:00] <jamespage> cpaelzer: +1
[14:02] <juliank> xnox: Well, at least the change is just three logical lines long :)
[14:03] <juliank> It's literally just an early exit
[14:06] <juliank> xnox: I wasn't not sure if we want to split the unattended-upgrade part into its own bug RE bug verification, I think I asked that a few weeks ago
[14:08] <xnox> juliank, i'm ok with a massive bug, then again i'm not ~ubuntu-sru team member.
[14:08] <xnox> juliank, bdmurray can advise as to how to keep him sane =)
[14:09] <juliank> I think we left sane territory a long time ago
[15:20] <nacc> slangasek: looks like we should have synced on python-django's merge :) LP: #1605278
[15:20] <ubottu> Launchpad bug 1605278 in python-django (Ubuntu Artful) "Merge python-django 1:1.11-1 from Debian unstable" [Wishlist,In progress] https://launchpad.net/bugs/1605278
[15:24] <doko> jbicha: they don't, unless you b-d on gcc-7 explicitly
[15:24] <jbicha> ok, it's just confusing right now, looking at the build logs
[15:30] <slangasek> nacc: ah hmm. I picked it off because it was blocking other packages in proposed-migration; 1.11 has been pushed to unstable now and should be an easy sync.  But why are django syncs blocked by maas? I see no failing autopkgtests
[15:30] <elopio> infinity, sil2100: can one of you let snapcraft and click into -updates please?
[15:30] <nacc> slangasek: functionality not reflected in a dep8 test :/
[15:30] <sil2100> elopio: which series?
[15:30] <nacc> slangasek: they use it and when django updates, their UI breaks :)
[15:30] <elopio> sil2100: xenial, yakkety and zesty.
[15:31] <sil2100> hm, I don't remember seeing it as ready when I was scanning pending today
[15:31] <slangasek> nacc: so... when are they adding dep8 tests for this?  roaksoax
[15:31] <sil2100> elopio: was it recently verified?
[15:31] <elopio> sil2100: I marked snapcraft verified yesterday. I've just marked click.
[15:32] <slangasek> nacc, roaksoax: because the last delta that was still there when I did the merge is unexplained and serves no purpose I can discern, so this *almost* became a sync, and then what would we do?
[15:32] <sil2100> elopio: is there any exception for snapcraft? Since it's not aged for 7 days yet
[15:32] <sil2100> Same for click
[15:32] <nacc> slangasek: :) right, that's why i haven't merged it since I started :)
[15:32] <sil2100> elopio: for almost all packages there's a usual 7-day aging period in -proposed after which we release the update to users
[15:33] <nacc> slangasek: openstack also has dependencies not reflected in dep8 tests, i believe, and jamespage already tested 1.10 (still waiting on testing on 1.11)
[15:33] <sil2100> I never released snapcraft or click before so I don't know if there's some special case here? Was it usually released earlier?
[15:33] <elopio> sil2100: we have an exception for snapcraft: https://wiki.ubuntu.com/StableReleaseUpdates#Snapcraft
[15:33] <sil2100> elopio: ok, see it being mentioned that it can be released earlier
[15:34] <elopio> sil2100: we don't have one for click, but the change is only a rename on the python package, and I've tested both for more than 7 days now. It would be great if we could land it soon.
[15:34] <sil2100> elopio: I'll release the snapcraft one and look at click, but considering the lack or real consumers of that package I might just release it as well
[15:35] <slangasek> sil2100: nack, click has to be released *first*
[15:35] <sil2100> slangasek: snapcraft depends on it?
[15:35] <slangasek> the click rename is done so that the snapcraft upgrade doesn't go pear shaped
[15:36] <slangasek> the snapcraft SRU introduces a dep on the /other/ click; the move of the python module in click is so we can lift the conflicts, so that upgrades will work for people who have click installed
[15:37] <sil2100> Ah, ok, so there's a dep change in snapcraft too, makes sense
[15:37] <sil2100> elopio: btw. the zesty autopkgtest snapcraft regressions are known?
[15:39] <elopio> sil2100: all the failures I looked at were because the proxy was not working nicely. Which one are you looking at?
[15:40] <sil2100> elopio: the zesty ones, there's a lot of failures, indeed from the logs I see those are network errors - please make sure to re-run them in this case so that we make sure they're passing
[15:41] <sil2100> Like, in the future I mean
[15:42] <elopio> sil2100: we run them in the pull request, and don't proposed until we are sure there are no test regressions in x, y, z and a.
[15:42] <elopio> last week it was hard, but we got all greens.
[15:43] <sil2100> Ok, hm, I also see ubuntu-image autopkgtests in zesty failed with the new snapcraft, looks like some of our unittests failed, looking into that
[15:43] <elopio> Not all at the same time, because the proxy was not happy. But all good there.
[15:43] <sil2100> Those could be because of networking, but hm, not entirely straightforward from the logs as those are our unittests failing
[15:44] <sil2100> Looks unrelated to snapcraft anyway
[15:45] <sil2100> elopio: for click, could you also verify/find someone to verify https://bugs.launchpad.net/ubuntu/+source/click/+bug/1696402 ?
[15:45] <ubottu> Launchpad bug 1696402 in click (Ubuntu Zesty) "chroot configuration strictly depends on overlayfs" [Undecided,Fix committed]
[15:46] <sil2100> elopio: looks like the yakkety and zesty click updates also had this fix in them
[15:46] <sil2100> I don't want to release something without any testing
[15:46] <sil2100> elopio: actually, since the autopkgtests passed, I'll just mark it as verified myself
[15:47] <elopio> sil2100: ah, right. I keep forgetting about that one. I already verified everything last week. I was just waiting for today, in case somebody else wanted to give it a try. That one in particular is just a test fix, so we checked that the tests are green.
[15:48] <elopio> sil2100: I don't see how those unit tests of ubuntu-image are related to snapcraft.
[15:50] <sil2100> elopio: yeah, true, just be sure to poke people to re-run or investigate any test failures and document them on the SRU bugs
[15:50] <elopio> sil2100: do you know who is in charge of ubuntu-image now?
[15:51] <sil2100> elopio: me and slangasek basically
[15:51] <sil2100> elopio: now that I know about this I'll investigate tomorrow
[15:51] <sil2100> ;)
[15:51] <slangasek> I've just retried that failed ubuntu-image test; the errors don't make sense, it could be test runner flakiness
[15:51] <sil2100> Yeah, most probably, although I've never seen those to be flaky, which made me a bit worried
[15:52] <sil2100> Still, not related to snapcraft
[15:53] <sil2100> elopio: anyway, done
[15:54] <elopio> sil2100: :D thank you!
[15:55] <elopio> thanks everybody who helped here. It was a long journey.
[15:56] <sil2100> yw! :)
[16:15] <stgraber> cjwatson: you have to restart the daemon. We have a pull request currently in flight which adds the ability to cancel background operations, so LXD 2.15 or 2.16 should finally let you cancel those with a good old ctrl+c.
[16:15] <cjwatson> brilliant, thanks
[16:15] <cjwatson> yeah, I restarted lxd in the end and it recovered
[17:31] <jbicha> yay, autosync from sid :|
=== powersj_ is now known as powersj
=== Tribaal_ is now known as Tribaal
=== ulkesh_ is now known as ulkesh
[18:58] <jackpot51> How would this be rolled out? It appears that gnome-control-center depends on it
[19:00] <rbasak> !dmb-ping
[19:00] <ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
[19:36] <jbicha> slangasek: I'm going to do a libepc upload today, is "Ubuntu Developers" ok for the maintainer?
[19:44] <jackpot51> How does this look - GNOME initial setup with encrypted home: http://imgur.com/a/Bbzp2
[19:44] <jackpot51> It has been themed, but that is not part of the change ;)
[19:48] <slangasek> jbicha: glom is Ubuntu Desktop Team; is that appropriate for libepc as well?  Because I don't think saying 'ubuntu-devel' is the maintainer is in practice much of a committment
[19:49] <jbicha> jackpot51: It may be a little more complex, but what about moving the Encrypt Home switch to the Privacy page?
[19:50] <jbicha> slangasek: thanks, I'll ask the Desktop Team tomorrow if they're ok with that then
[19:50] <jackpot51> No, I can't really do that simply.
[19:51] <jbicha> ok
=== herb_ is now known as herb
[19:52] <jackpot51> The issue is that the setting is utilized when adduser is called, or immediately after. I could move it to the password page, or leave it on the account page
[19:53] <jbicha> I think the Privacy page comes first so it might still be doable, just more complicated
[19:53] <jbicha> I believe the order is at https://git.gnome.org/browse/gnome-initial-setup/tree/gnome-initial-setup/gnome-initial-setup.c#n67
[19:54] <jbicha> (some pages are skipped in some modes)
[19:55] <jackpot51> I need to work on the implementation as well - so maybe come back to where it should be?
[20:14] <acheronuk> mapreri: you about?
[20:14] <acheronuk> https://launchpad.net/ubuntu/+source/libkf5kface/16.12.3-0ubuntu2
[20:16] <acheronuk> changes like that, could you maybe let kubuntu know when such uploads happen on our packages?
[20:16] <Laney> I don't think glom should be maintained by the desktop team
[20:17] <acheronuk> we keep our packaging in git, and use automation tools to do application uploads, so unless we know of and incorpoate such changes, they might get lost in our next apps release upload
[20:19] <acheronuk> think there is some scripting in the pipeline to check consistency against the archive to catch stuff like that, but not implemented quite yet
[20:37] <acheronuk> clivejo: read up ^^^ ;)
[20:57] <jbicha> slangasek: what if the Desktop Team doesn't want to be listed as the glom maintainer either?
[21:10] <slangasek> jbicha: well, then why would glom be kept in the archive either if they're not willing to maintain its dependency?
[21:10] <slangasek> jbicha: perhaps listing ubuntu-desktop as maintainer of glom is also a bug; if there is some other team that is going to maintain both glom and libepc, that's fine too
[21:12] <jbicha> glom is probably maintained about as well as anything else in universe
[21:16] <jbicha> meaning the packaging itself is pretty good but nobody reads the bug reports (but upstream is subscribed :) )
=== JanC_ is now known as JanC
[21:30] <mapreri> acheronuk: yap
[21:30] <mapreri> sorry, missed the highlight
[22:04] <nacc> cyphermox: fyi, i'm very close to having isns upstream dep8 tests
[22:06] <cyphermox> nacc: cool, thanks for the update
[22:06] <cyphermox> I'm trying to figure out why ubiquity isn't removed from the desktop image after install, and kinda stumped
[22:09] <nacc> cyphermox: in all releases?
[22:09] <cyphermox> just in the artful desktop images
[22:09] <cyphermox> it's a side-effect of some of the changes in livecd-rootfs, but not sure yet how to fix it, things looks like they "should" work
[22:17] <jackpot51> jbicha: I have a patch for gnome-control-center and gnome-initial-setup to add encrypted home, but it requires a breaking API change for accountsservice
[22:17] <jackpot51> What should I do?
[22:19] <jackpot51> ls
[22:35] <mapreri> Unit193: care to send https://bugs.launchpad.net/bzr-fastimport/+bug/1014291 debian's way at least?
[22:35] <ubottu> Launchpad bug 1014291 in bzr-fastimport (Ubuntu) "Export from bzr / Import to git results in a deleted file re-appearing" [Undecided,New]
[22:37] <mapreri> acheronuk: ah, and now I read that you actually wrote something after a ping…
[22:37] <Unit193> mapreri: That's to say, I looked for it and didn't see the Ubuntu one, just where I went upstream and had also poked bzr/Debian maintainers, so thanks for asking.  I mean I suppose I could look into it, not had the best of luck with him in the past...
[22:37] <jbicha> jackpot51: open an Ubuntu bug with the attached patches and then you can ping the Desktop Team during Europe work hours
[22:38] <mapreri> acheronuk: ack, I'll notify you next time.  FWIW, I also uploaded digikam, you might want to sync that too.
[22:38] <mapreri> acheronuk: even if "you"… where should I go write, even…
[22:39] <jbicha> jackpot51: there's a bzr branch https://code.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/ but I don't think Initial Setup or accountsservice are currently in a VCS
[22:39] <mapreri> acheronuk: I can dump a line #debian-qt-kde @ oftc, dunno whether that's what you mean
[22:41] <mapreri> Unit193: I know what you mean…  but still, I'd try to file a bug with the patch, could also happen you catch him in a moment he is bored and he just upload it…
[22:49] <mapreri> acheronuk: actually, I'm happy to work on git myself, if you can point me at those git repos (for the next time I'll have upload something like that).  Also, are you interesting in having those commits for no-change rebuilds?
[23:01] <bdmurray> sarnold: I heard you had some questions about some openssl apport-package bug reports. Could we look at one together?
[23:03] <sarnold> bdmurray: sure
[23:03] <bdmurray> Do you have one at hand?
[23:04] <sarnold> bdmurray: here have thirty :) https://bugs.launchpad.net/ubuntu/+source/openssl/+bugs?orderby=-date_last_updated&start=0
[23:04]  * bdmurray drowns
[23:04] <sarnold> this one's in english https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1698113
[23:04] <ubottu> Launchpad bug 1698113 in openssl (Ubuntu) "package libssl1.0.0:i386 1.0.2g-1ubuntu4.6 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Undecided,New]
[23:05] <bdmurray> so the DpkgTerminalLog.txt shows it being a follow up error
[23:06] <bdmurray> and DpkgHistoryLog.txt shows openssl first being upgraded on 2017-06-13
[23:06] <sarnold> I think the ones I inspected looked similar
[23:06] <bdmurray> apport trims DpkgTerminalLog.txt to the most recent package activity so we don't have a log of what happened on 2017-06-13
[23:07] <bdmurray> You could ask the reporter for their log dpkg log file which covers that period.
[23:08] <bdmurray> Or search to see if the reporter reported other reports. Roger?
[23:09] <sarnold> bdmurray: is this one a 'live' bug? https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1696799
[23:09] <ubottu> Launchpad bug 1696799 in openssl (Ubuntu) "package libssl1.0.0:i386 1.0.2g-1ubuntu4.8 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Undecided,Confirmed]
[23:10] <sarnold> that one's got some unfortunate bleachbit nonsense that makes me want to disregard the bug entirely, but its log does include "Preparing to unpack ..."
[23:13] <bdmurray> sarnold: the dpkghistorylog.txt shows an upgrade of openssl and then later "apt-get -f install ..." so no "not live"
[23:13] <sarnold> :(
[23:13] <bdmurray> I'd expect some dpkg bug reports given "Error: Sub-process /usr/bin/dpkg exited unexpectedly"
[23:15] <sarnold> the dpkg bug list is overwhelmed with the "is already installed and configured" bugs; 1692322 is a half-installed bug but that's for dpkg itself. hehe.
[23:18] <bdmurray> sarnold: I think just asking for people's full /var/log/apt/term.log file is the best idea. I'll have a look to see if the dpkg deaths are getting surpressed somehow.
[23:18] <sarnold> bdmurray: will do. thanks.