[00:00] <nacc> slangasek: would you have a moment for a question about image (cloud-images specifically, but I think generic) generation?
[00:15] <slangasek> nacc: sure, maybe I can answer wrt cloud images :)
[00:16] <sarnold> better hurry though with this wind who knows how much longer our internet cables will hold up
[00:18] <nacc> slangasek: :) -- so I'm working on curtin iscsi support and at the same time hoping to resolve LP: #1444992. I *think* the underlying issue is that we (well, the open-iscsi package) generates the initiator name at pkg install time (due to LP: #1057635). But for the cloud image, since open-iscsi is seeded in server (I think this is why?) it's configured at image creation time (effectively).
[00:19] <slangasek> nacc: yes, that sounds accurate to me
[00:20] <nacc> slangasek: and what i'm trying to understand, given i don't know much about the image creation process, is what are possible fixes? My initial thought is to change the image creation tooling to undo the change from the second bug and set the intiatior name back to Generated=yes
[00:22] <nacc> slangasek: but, given that the package is present always, do we need to worry about churning through all the random strings that are used (aiui, generated has a fixed prefix (from Debian) and then a suffix of some number of characters)
[00:27] <slangasek> nacc: the image build process can have post-processing of the image contents to do things like removing or editing the config file; if you look at the init script you'll see that it will auto-generate the initiator name on first run if it doesn't already exist
[00:28] <slangasek> (he says, having for some reason looked at this package recently)
[00:28] <slangasek> nacc: so basically, adjust the rules in livecd-rootfs to rm /etc/iscsi/initiatorname.iscsi
[00:29] <nacc> slangasek: hrm, on my reading of startup-checks.sh, though, if that file doesn't exist, it just errors out? (this is a ExecStartPre for iscsid.service)
[00:32] <nacc> slangasek: maybe i'm looking at the wrong init script?
[00:46] <slangasek> nacc: hmm double-checking
[00:46] <slangasek> nacc: ah right, you need to actually set GenerateName=yes in that file
[00:52] <nacc> slangasek: ack, that is my read of it as well
[00:53] <nacc> slangasek: i'll take a look at livecd-rootfs
[01:00] <nacc> slangasek: is it just me or is live-build/ubuntu-cpc/060-ipv6.chroot about to break for z+1 (and technically is already wrong but unaffected probably by warty < trusty?) Just getting my head around the src pkg :)
[01:01] <slangasek> nacc: hngh
[01:02] <slangasek> nacc: you are not incorrect
[01:05] <mwhudson> ah haha
[01:05] <mwhudson> i wonder how much of the 17.10 cycle is going to be finding all of those
[01:06] <nacc> mwhudson: :)
[01:08] <nacc> slangasek: iiuc, then, would it be so straightforward as adding an iscsi hook? which basically does `echo GenerateName=yes > /etc/iscsi/initiatorname.iscsi`?
[01:09] <slangasek> nacc: should check for existence before overwriting, but yes
[01:09] <slangasek> mwhudson: well, cdimage was future-proofed quite some time ago :P
[01:09] <mwhudson> slangasek: because warty > breezy?
[01:10] <nacc> slangasek: ack
[01:10] <mwhudson> slangasek: i'm sure no code with new assumptions has been added in the last 12 years or so
[01:27] <bswartz> hey ubuntu guys, I'm trying to upload a package to a PPA I just created, and it said "Successfully uploaded packages." but there's still nothing on my PPA
[01:30] <jgrimm> bswartz, did you check your email as possibly got rejected while actually processing the upload
[01:31] <bswartz> jgrimm: ty! I just checked my email and it was rejected
[01:31] <jgrimm> bswartz, you should get a rejection/success email
[01:31] <jgrimm> bswartz, cool
[01:31] <bswartz> didn't know it sent email responses
[01:39] <bswartz> jgrimm: I was able to upload my package but when I try to apt-add-repository on my own PPA it fails with "Error: signing key fingerprint does not exist"
[01:39] <bswartz> oh maybe that's because the build of the package is pending still
[01:40] <bswartz> I'll try again after this build completes
[01:44] <sarnold> indeed that's possible, if this is the first package build in your ppa; I think launchpad creates the keys -after- a package has successfully built
[01:56] <bswartz> darn the package built successfully but I'm still getting the "Error: signing key fingerprint does not exist" error when trying to add the PPA
[02:05] <bswartz> google saves me again -- I had to run "sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ...."
[02:07] <sarnold> ewwww
[02:07] <sarnold> probably waiting ten minutes was the real solution
[02:08] <tsimonq2> (either way, DuckDuckGo FTW :P)
[09:55] <cjwatson> mwhudson: warty/breezy was still in the era of special-casing for everything; the serious future-proofing was much later
[09:56] <cjwatson> mwhudson: (I did most of it when rewriting the whole thing in Python)
[13:47] <fossfreedom_> andyrock: quick question - did you manage to discuss our (Ubuntu Budgie) gnome-menus merge-proposal with seb128 ? TIA  https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1631745
[13:52] <GunnarHj> rbasak: I just uploaded to xenial successfully, so the fix of my packageset seems to be fine. Thanks!
[13:53] <rbasak> GunnarHj: great! Sorry it took so long.
[13:53] <rbasak> I think my DMB queue is now clear \o/
[14:22] <mitya57> Can someone please mark monkeysign failures as ignored? I.e. on i386 it passed only one time of 19, according to http://autopkgtest.ubuntu.com/packages/monkeysign/zesty/i386.
[14:23] <mitya57> And it is the last package that blocks sphinx migration.
[14:23] <rbasak> I can't (no ACL bit) but sphinx migration \o/
[14:23]  * rbasak had something blocked on that but can't remember what :-/
[14:23] <mitya57> Laney, ^^ are you the right person to ask about this?
[14:36] <mitya57> rbasak, by the way I don't see anything that depends on Sphinx on the proposed-migration page.
[14:37] <mitya57> Maybe you are talking about sphinx-the-speech-engine, not sphinx-the-doc-generator? :)
[14:41] <rbasak> No it was the doc generator. It's an FTBFS with the old sphinx that builds successfully in Debian. With the new sphinx, I'm hoping it'll work.
[14:41] <rbasak> Though, the new sphinx is in proposed already, and we build against that already.
[14:41] <rbasak> So perhaps finishing the transition won't help.
[14:41] <rbasak> I wish I could remember what package it was.
[15:05] <mitya57> rbasak, in case you remember it, please let me know — I want to make sure all packages can build against both 1.4 in Debian and 1.5 in Ubuntu.
[15:05] <rbasak> Will do.
[15:15] <andyrock> fossfreedom: I forgot tbh
[15:15] <andyrock> and seb is likely travelling to fosdem
[15:18] <fossfreedom_> andyrock: ah.  ok - thanks for the info.
[15:18] <andyrock> sorry about that
[15:19] <fossfreedom_> andyrock: yeah - sorry to be persistent - this bug is kind of a show-stopper for us :/
[15:30] <barry> i guess bitlbee now hijacks port 6667 via systemd :/
[15:31] <enyc> barry: hhahahah
[15:32] <enyc> barry: devuan to the rescue?
[15:32] <barry> enyc: systemctl start emacs.service
[16:18] <GunnarHj> bdmurray: Re that im-config bug: rbasak fixed my permissions, and since you didn't do it yesterday, I uploaded it myself a couple of hours ago, so now there is a duplicate... Sorry, should have made a note on the bug report.
[16:20] <bdmurray> GunnarHj: or unsubscribed the sponsors team. ;-)
[16:21] <GunnarHj> bdmurray: Actually I did that.
[16:21] <bdmurray> GunnarHj: oh, maybe I should have refreshed that tab
[16:21] <GunnarHj> bdmurray: ;)
[17:17] <bdmurray> cjwatson: You have some familiarity with debmirror right?
[17:17] <cjwatson> bdmurray: I do, but I'm about to go away for the weekend so now isn't the best time
[17:18] <bdmurray> cjwatson: Okay, its not a big deal but if you could look at bug 1658203 sometime that'd be nice.
[17:20] <cjwatson> I suspect it's because trusty didn't list Contents in Release
[17:21] <cjwatson> or at least related to that
[19:53] <dobey> is there a way to use globs with seeded-in-ubuntu?
[19:55] <sarnold> if you need to build an ugly script you might find apt-cache pkgnames helpful
[19:55] <dobey> no, i just want to see the seed list for a set of packages
[19:55] <dobey> ie indicator-*
[19:56] <dobey> from source packages, that is
[21:52] <nacc> rbasak: heh, fun issue with the importer / cron, if launchpad hiccups during one of its connections, something (presumably launchpadlib, but i'm not sure) doesn't seem to notice and just hangs ... so when we had the fw maintenance earlier, the importer got stuck (but didn't crash)
[21:52] <nacc> jgrimm: --^ fyi, that's why openvpn hadn't picked up the new version yet, i just restarted the script
[21:53] <jgrimm> nacc, aha! ok
[21:53] <nacc> jgrimm: it might take the importer a bit to catch back up, but it should relatively soon
[21:56] <jgrimm> nacc, no worries at all.  plenty of other work i can pivot to
[21:56] <rbasak> nacc: wrap the cron with a timeout command perhaps?
[21:57] <rbasak> timeout -k60 3600 usd ...
[21:57] <jgrimm> nacc, thoughts on how to rebase my current work to newer/debian?
[21:58] <jgrimm> not that its that hard to start over, its all pretty minor
[21:58] <nacc> jgrimm: ack, so i *think* the simplest way is
[21:58] <nacc> git checkout <your branch/ref/whatever>
[21:59] <nacc> git fetch lpusip
[21:59] <nacc> <presuming it updates the debian/sid branch>
[21:59] <nacc> git rebase -i lpusip/debian/sid
[21:59] <nacc>  ... drop the merge-changelogs, reconstruct-changelog, update-maintainer bits
[22:00] <nacc> then re-run those steps, except for merge-changelogs you'll need to pass
[22:00] <nacc> git merge-changelogs old/debian old/ubuntu lpusip/debian/sid
[22:00] <nacc> and correspondingly
[22:00] <nacc> git reconstruct-changelog lpusip/debian/sid
[22:01] <nacc> alternatively to all that :) you can probably checkout ubuntu/devel again, and run `usd merge -f --tag-only`
[22:01] <nacc> e.g, `usd merge -f --tag-only ubuntu/devel lpusip/debian/sid`
[22:02] <jgrimm> heh, i'll give those a try on monday.. brain at EOW sluggishness
[22:02] <jgrimm> nacc, thanks!
[22:03] <nacc> jgrimm: you're basically doing a normal git-rebase at this point
[22:04] <nacc> it would be good to test, actually, i think the merge-changelogs step might 'just work' (with fuzz/offsets)
[22:04] <nacc> as in, you don't need to drop it
[22:04] <nacc> but reconstruct will fail, as it wont' find the right context (or it'll put it somewhere below the top of the file)
[22:04] <nacc> udpate-maintainer will probably carry-forward, though
[22:04] <jgrimm> right, this'll be an interesting test / good exercise
[22:31] <jgrimm> nacc, '> - While it's not wrong by any means to have a carry-forward and revert of
[22:31] <jgrimm> > the CVE delta, it does mean that the next merger has to think a bit about  '
[22:32] <jgrimm> nacc, I agree.. though we may want to recommend 'edit' instead of pick on the rebase to new/debian
[22:32] <jgrimm> nacc, as otherwise it clean rebases something you intend to drop (which is how i got there)
[22:32] <nacc> jgrimm: oh i see
[22:33] <nacc> jgrimm: hrm, well if you first squash those and commit an empty-commit
[22:33] <nacc> jgrimm: it should result on rebase in it being dropped
[22:33] <jgrimm> yes, i could easily fix it .. was following the docs
[22:34] <jgrimm> nacc, indeed -> squash and empty-commit would work as well
[22:38] <nacc> jgrimm: ack, it's on my todo list to update more use cases on the wiki for stuff like this
[22:38] <nacc> recommended practices for changing delta, for dropping delta, etc.
[22:38] <jgrimm> nacc, it was a great observation, so thank you for seeing that
[23:41] <wxl> anyone here that can help sponsor a bugfix upload of konversation in yakkety? debdiff's big but that's because it includes translations. https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/1635911
[23:44] <sarnold> 578 KB debdiff for what looks like a _one line_ fix? ouch
[23:44] <sarnold> are you sure the translation changes are needed? I only inspected a hansdful but most looked like they were updating comments