[03:15] <mwhudson> uh
[03:15] <mwhudson> what do i have to do to be able to edit the wiki?
[03:16] <tsimonq2> mwhudson: Ubuntu Wiki?
[03:16] <mwhudson> yeah
[03:16] <mwhudson> i have to join some team or other iirc?
[03:16] <tsimonq2> are you an Ubuntu Member?
[03:16] <mwhudson> yes
[03:16]  * tsimonq2 thought Canonical and Ubuntu Members had access
[03:16] <mwhudson> maybe i just need to log in again...
[03:17] <tsimonq2> oh that's right, you're Canonical too, right? :)
[03:17] <tsimonq2> probably
[03:17] <mwhudson> yes
[03:17] <mwhudson> it's asking me about ubuntumembers when i re-log in so that's a good start
[03:17] <tsimonq2> that should be it
[03:18]  * tsimonq2 assumed ~canonical was a private Launchpad team
[03:18] <tsimonq2> *shrug*
[03:19] <mwhudson> if the login ever completes, taht is
[03:21] <tsimonq2> yes, the wiki is really slow :/
[05:30] <pitti> Good morning
[05:41] <cpaelzer> good morning
[06:58] <dholbach> @pilot in
[07:07] <seb128> dholbach, enjoy the piloting ;-)
[07:09] <dholbach> thanks seb128
[07:13] <dholbach> can the release team take a look at https://bugs.launchpad.net/ubuntu/+source/underscore/+bug/1618904?
[07:15] <seb128> dholbach, they are their channel you might to ask there?
[07:15] <seb128> though I guess they are here as well for most part
[07:15] <seb128> but there is sometime more going on and backlog get lost
[07:17] <dholbach> ok
[07:24] <jamespage> doko_, annoyingly I can't get the cryptography py3 failure to fail on an actual armhf machine
[07:25] <doko_> jamespage: yeah, but porter-arm64 should work?
[07:25] <jamespage> doko_, testing that now
[07:30] <Saviq> pitti, morning, I've got good news about unity8 suite, with the upcoming landing we've halved the time it takes to run the tests on our CI, britney should get much better in that regard, too
[07:30] <Saviq> pitti, got a question, though, in CI we've been getting quite a bit of timeouts after the run's finished (scroll to the bottom of https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/1553/label=amd64,release=yakkety,testname=qmluitests.sh/console) - any idea what could cause that?
[07:31] <Saviq> how we could debug?
[07:41] <pitti> Saviq: hmm, schroot --end-session timed out (30 s); does  that happen often?
[07:41] <Saviq> pitti, I'd say 10-20% of the runs, started a few weeks ago
[07:41] <pitti> Saviq: maybe slow disks? I don't mind bumping the 30s timeout to 300s, maybe you can locally change it to try if that helps?
[07:42] <Saviq> pitti, ack, will do
[07:42] <pitti> Saviq: and nice work on halving the time!
[07:43] <Saviq> pitti, that would be --timeout-???
[07:43] <Saviq> man doesn't mention it, maybe I just --timeout-factor?
[07:44] <pitti> Saviq: not configurable, I'm afraid; change it in virt/autopkgtest-virt-schroot, in hook_downtmp()
[07:44] <pitti> sorry, hook_cleanup()
[07:44] <pitti>        if VirtSubproc.execute_timeout(
[07:44] <pitti>                 None, 30, ['schroot', '--quiet', '--end-session', '--chroot', sessid])[0] == 0:
[07:44] <Saviq> pitti, ack
[07:44] <pitti> change the 30 into a 300
[07:44] <pitti> Saviq: I'll do it in trunk now if you run from git
[07:45] <Saviq> I don't, relying on pkgs
[07:45] <jamespage> doko_, bus error comes from siphash24 in a armhf schroot on arm64 host
[07:45] <pitti> Saviq: https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=1cdc9df
[07:45] <Saviq> ack, thanks
[07:50] <Saviq> pitti, hmm good call, it looks like the slave on which that happens is having trouble, things take multiple times more on that one than others
[07:51]  * Saviq talks to IS
[07:52]  * pitti wonders on how many secret service watchlists we are by constantly saying "talk to IS" and even /join #is :)
[08:59] <jamespage> doko_, I think crypto is the symptom - you can reproduce this with "print(hash(datetime.datetime(2015, 1, 1, 1, 1)))"
[10:21] <LocutusOfBorg> is go* broken on yakkety/powerpc?
[10:21] <LocutusOfBorg>  sbuild-build-depends-heartbleeder-dummy : Depends: golang (>= 1.2) but it is not going to be installed
[10:21] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/heartbleeder/0.1.1-3/+build/10727160
[10:22] <LocutusOfBorg> mwhudson, ^^ :)
[10:57] <caribou> pitti: slangasek: I have updated LP: #1535898 with a proper SRU template & did my best to document. Please let me know if this is sufficient for the SRU to be accepted
[10:58] <dholbach> @pilot out
[11:34] <semiosis> Odd_Bloke: slangasek: either of your around?  i made progress on bug 1621393 last night and want to discuss a solution.
[11:35] <Odd_Bloke> semiosis: o/
[11:36] <semiosis> the resolv.conf file gets modified by mount_partition, then the original gets replaced in umount_partition, so I need to call umount_disk_image (which calls umount_partition) in the middle of my script, before I build the VMDK file
[11:36] <semiosis> that's how I originally had my script working, but in review slangasek had me move umount_disk_image into the trap.
[11:37] <semiosis> if umount_disk_image is in trap then the resolv.conf file is still modified when i build the VMDK, which is the cause of this bug
[11:38] <semiosis> so... i want to put my script back to the way I had it before... with just rm -rf <temp files> in trap, and umount_disk_image called in the middle of the script, after the apt-get and before building the vmdk
[11:39] <semiosis> looks to me like 4 other hook scripts do this, without their umount_* calls in trap.  so if it's OK for those, I think it should be OK for mine too :)
[11:42] <semiosis> you can see slangasek's feedback if you go to the merge request (https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305) and switch the diff viewer to show "r1419 into r1415 on 2016-07-07".  his comment is "If you're going to be mounting a disk image in a script that uses set -e, you also need the unmount to be part of the trap handling."
[12:26] <brendand> pitti, we keep hitting this issue in our ci - http://paste.ubuntu.com/23154341/. we're running autopkgtest from the git repo. is that something you've seen, or do you think upgrading might help?
[12:34] <Saviq> seb128, hey, looking at gsettings-qt, according to LP and rmadison it's in main already https://launchpad.net/ubuntu/+source/gsettings-qt with the exception of one binary - do we need a MIR for that, too?
[12:35] <seb128> Saviq, no, it's fine, sorry it seems the script had a small bugs and some source-in-main-but-binary-not cases showed on our updated list
[12:37] <Saviq> ack tx
[12:37] <pitti> brendand: that's an ancient bug already (bug 1384706); no known workaround so far :(
[12:38] <Odd_Bloke> semiosis: That seems reasonable to me, but I'd really want slangasek to weigh in. :)
[12:38] <semiosis> Odd_Bloke: thanks!  i'm open to other solutions as well, but that one seems the most reasonable to me
[12:45] <brendand> pitti, oh damn
[12:45] <ddstreet> hi all, i have a q...i need to patch the vlan pkg in ubuntu (version 1.9-3.2ubuntu1) and debian (version 1.9-3.2), is the best thing to do to get debian updated first (to version 1.9-3.3), and then update ubuntu to the full new version (to version 1.9-3.3ubuntu1), or to update ubuntu at the same time, e.g. to version 1.9-3.2ubuntu1.1 for xenial and 1.9-3.2ubuntu2 for yakkety?
[12:45] <brendand> pitti, interesting that my team reported it originally!
[12:45] <brendand> pitti, maybe it's our fault :P
[12:46] <pitti> brendand: a lot of people report it, but it's ridiculously hard to reproduce and investigate
[12:46] <pitti> I spent hours on that, with sleeps left and right, strace, etc.
[12:48] <brendand> i wonder can it be mitigated by copying less stuff
[12:54] <xnox> ddstreet, before you can upload SRU bug must be fixed in yakkety first.
[12:54] <xnox> ddstreet, a fix in yakkety will most likely land as 1.9-3.2ubuntu2
[12:54] <xnox> ddstreet, your xenial version number will be 1.9-3.2ubuntu1.1 (with the functional equivalent diff of what ....ubuntu3 fixes)
[12:55] <ddstreet> xnox cool thnx!
[12:55] <xnox> ddstreet, you shall not fix bugs in xenial-sru ahead of devel series, because versions don't work, and things regress on upgrade.
[12:55] <ddstreet> right definitely not, devel fix first
[12:55] <xnox> ddstreet, note you cannot upload 1.9-3.3 to ubuntu =) that's a debian NMU version number, such a fix needs to be sponsored into debian.
[12:55] <xnox> ddstreet, what's the bug, and what's the fix? I can sponsor things for you into debian, yakkety, xenial as needed.
[12:56] <ddstreet> bug 1224007
[12:56] <ddstreet> i put a patch in comments there but i've changed it, i'll attach a patch and debdiff for yakkety
[13:13] <ddstreet> xnox should i open a debian bug for ^?  I assume so yeah?
[13:13] <ddstreet> there was a debian bug open, 722496, but it was closed as config error, which it isn't
[13:16] <xnox> ddstreet, debian bug is against ifupdown package; ubuntu bug is aginst ifupdown & vlan package; if you have a patch against vlan package, opening a new bug in debian against vlan package makes sense
[13:16] <xnox> explain the problem and probably reference old ifupdown bug # too
[13:16] <xnox> or e.g. reopen 722496, and reassign 722496 to vlan package, and explain things
[13:17] <ddstreet> xnox ah ok, i'll repoen the old one thnx
[13:37] <LocutusOfBorg> pitti, hi, seems that a test disappeared
[13:37] <LocutusOfBorg> astrometry.net/0.67+dfsg-1build2 against libpng1.6
[13:37] <LocutusOfBorg> test in progress since some hours (i386)
[13:37] <LocutusOfBorg> but not in the queue, nor running
[14:16] <pitti> LocutusOfBorg: bumped
[14:22] <LocutusOfBorg> pitti, was it a bug?
[16:37] <slangasek> caribou: thanks, setting #1535898 back to v-done
[16:49] <nacc> smoser: have a moment?
[16:49] <smoser> sure
[16:50] <nacc> smoser: thinking about this apt bug -- i got further in the import by adding a parent override for 0.7.19ubuntu1 that just manually tells the importer what the parent relationships are. However, 0.7.20.2ubuntu1 also hits it. I'm guessing any published version with 0.7.14ubuntu1 in the changelog will hit it. But without manually going through each time and figuring out what versions are affected, I am
[16:50] <nacc> struggling to think of a generic solution to a malformed changelog
[16:54] <smoser> i'm guessing you can't upload a malformed changelog any more
[16:54] <smoser> right ?
[16:54] <smoser> i'm surprised that it ever got into archive
[16:54] <nacc> yeah, i'm guessing it isn't possible anymore too
[16:54] <nacc> there are more checks now than historically, it seems like :)
[16:55] <smoser> maybe its acceptable then to take the last good entry ?
[16:55] <smoser> but you probalby dont have an easy way to know what the last one was
[16:55] <smoser> as you're relying on parsechangelog to figure that out for you
[16:55] <smoser> right?
[16:56] <nacc> oh it's not about that, really
[16:56] <nacc> well, i mean, it's not about 'last' in this case
[16:56] <nacc> but i basically grab "all" entries at one point from the changelog
[16:56] <nacc> in order to figure out common ancestor
[17:06] <nacc> smoser: it might take another workaround file like the parent override to just say if you see this version in the changelog for a given package, we can't parse it, emit an error and ask for an override
[17:08] <tjaalton> jbicha: hi, is there no bug for the other change in ubuntu-gnome-wallpapers?
[17:10] <jbicha> tjaalton: no, I guess no one noticed or thought it important enough to file the bug; I found it while verifying there weren't any other typos breaking the slideshows
[17:17] <tjaalton> alright
[17:29] <smoser> nacc, i was just suggesting that you could just ignore invalid entries.
[17:30] <smoser> would that help things ? anything that isnt valid is just dropped
[17:30] <smoser> you could / maybe should require a flag to behave like that
[17:31] <nacc> smoser: well, i mean, there's not a way for me to detect that
[17:31] <nacc> smoser: i mean, i could assume dpkg-parsechangelog failing is that, but it's not always true
[17:32] <smoser> right. other than basically parsing more loosely.
[17:32] <jbicha> tjaalton: in case you didn't see, there's a trusty upload for u-g-wallpapers too
[17:33] <tjaalton> looking
[17:33] <nacc> smoser: yep, i wonder if i need to write another parser to do that, though -- more work :)
[17:33] <jbicha> thank you
[17:41] <Pharaoh_Atem> is there an API for retrieving the URLs of the source packages?
[17:41] <Pharaoh_Atem> like the URLs on http://packages.ubuntu.com/source/trusty/libmodule-cpants-analyse-perl ?
[17:41] <smoser> Pharaoh_Atem, pull-lp-source will let you pull them.
[17:42] <smoser> likely you can do what you want, but i'm not sure excactly.
[17:42] <nacc> Pharaoh_Atem: you mean the VCS urls?
[17:43] <ogra_> Pharaoh_Atem, if you like it more raw ... https://help.launchpad.net/API/ and https://launchpad.net/+apidoc/1.0.html ...
[17:45] <Pharaoh_Atem> nacc: no, I want the tarball and dsc file urls
[17:45] <Pharaoh_Atem> I want to be able to pull them from say universe and be able to download them
[17:46] <nacc> Pharaoh_Atem: oh, `pull-lp-source` is what you want
[17:46] <Pharaoh_Atem> or at least grab the URLs
[17:46] <nacc> Pharaoh_Atem: and `pull-debian-source` if you need it
[17:46] <Pharaoh_Atem> pull-lp-source pulls from archive.ubuntu.com?
[17:46] <ogra_> no, from launchpad
[17:47] <Pharaoh_Atem> I specifically want the ones from archive.ubuntu.com
[17:47] <ogra_> thats the same :)
[17:47] <nacc> Pharaoh_Atem: i think you're overanalyzing :)
[17:47] <nacc> Pharaoh_Atem: they are the same
[17:47] <Pharaoh_Atem> okay...
[17:47] <nacc> Pharaoh_Atem: maybe just try it and see? :)
[17:48] <Pharaoh_Atem> where do I get pull-lp-source?
[17:48] <nacc> Pharaoh_Atem: in your case, `pull-lp-source -d libmodule-cpants-analyse-perl trusty`
[17:48] <nacc> Pharaoh_Atem: ubuntu-dev-tools
[17:49] <ogra_> https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk
[17:51] <Pharaoh_Atem> nacc: I'm writing a script to pull selected components from universe into my private build environment
[17:51] <Pharaoh_Atem> so I just need the URLs to pass to the OBS system
[17:52] <nacc> Pharaoh_Atem:  i mean, do you really need the URL? just use `pull-lp-source -d`?
[17:52] <Pharaoh_Atem> yes
[17:53] <nacc> Pharaoh_Atem: i mean, it sounds like your script would end up just doing what `pull-lp-source -d` does with the same information
[17:53] <Pharaoh_Atem> I'm sending the URLs into the obs source service system
[17:53] <nacc> Pharaoh_Atem: i guess you could just make a copy of pull-lp-source and have it emit the URLs rather than d/l them?
[17:55] <semiosis> slangasek: if you're around, could you take a look at my chat about bug 1621393 from earlier today?
[17:56] <semiosis> see chat log here: https://irclogs.ubuntu.com/2016/09/09/%23ubuntu-devel.html#t11:34
[19:18] <slangasek> semiosis, Odd_Bloke: hi, so, my guidance wasn't "you can't call umount earlier", it was "you must include a call to umount in your trap"
[19:18] <slangasek> because if someone hits ^C at the terminal you don't want stray mount points left around
[19:18] <slangasek> but if you need to call cleanup functions earlier than this as part of an image build, then you should certainly do so
[21:01] <semiosis> slangasek: unfortunately the umount functions don't like being called twice.  in this case, the function moves a file, so if you call it a second time, the mv fails because the src no longer exists :(
[21:01] <semiosis> so my options are... only call umount_disk_image once, in the middle of my script (not in trap) or manually create the resolv.conf symlink
[21:02] <semiosis> slangasek: whats your take on the other four hook scripts that do call umount_* functions in the script, and not in trap?  as the kid in me wants to say... if they can do it why can't I? ;)
[21:03] <semiosis> slangasek: they call `trap - EXIT` -- and I can't even figure out what the hyphen there does.  maybe thats my answer, somehow?
[21:17] <slangasek> semiosis: the other option is to have the trap handling keep track of whether umount has previously been called or if it needs to be called again
[21:18] <semiosis> ooh that's interesting.  maybe set a veriable after the umount_disk_image call, then test for that variable in the trap.  does that sound reasonable?
[21:18] <slangasek> 'trap - EXIT' means 'clear the current EXIT trap'
[21:18] <slangasek> yes, it can be a variable check, or a check for a file or whatnot
[21:20] <semiosis> how about changing the trap... mount, set trap with umount, do stuff, call umount, remove umount from trap.  how's that sound to you?
[21:34] <semiosis> slangasek: thanks for the guidance.  i'm not too experienced with all this sophisticated BASH.  appreciate the help & knowledge.  i'll try out some solutions around what we talked about this weekend and hopefully open a merge request.
[21:47] <slangasek> semiosis: the challenge is that a trap can only have a single value for any given signal; so if you have various cleanup tasks, some of which may be required and some not depending on where in the sequence you are when interrupted, you have to leave the trap set to a common function that includes all the smarts for cleaning up
[21:50] <semiosis> slangasek: ok that makes sense.
[21:50] <slangasek> semiosis: strawman: http://paste.ubuntu.com/23156408/
[21:52] <semiosis> that's pretty simple
[21:54] <slangasek> semiosis: if you can test that this does what you want, I'm happy to push it
[21:56] <semiosis> i'll try it now
[22:24] <semiosis> slangasek: worked great.  thank you!
[22:25] <semiosis> slangasek: want me to prepare this in a branch & a merge request?
[22:29] <semiosis> i'm going afk but will check in later.  thanks again
[22:53] <slangasek> semiosis: I'll just push it now to yakkety+xenial