[00:06] <sarnold> smoser: when you roll out the new cloud-init changes, could you include instructions on how to provide a datasource identifier via qemu commandline or libvirt or both? :)
[00:16] <cjwatson> Unit193: not 0.68, but Simon's passed me some more limited security patches that are on my to-do list to apply.
[00:16] <cjwatson> Unit193: at least probably not 0.68.  it seems like a stretch post-FF.
[00:17] <Unit193> cjwatson: OK, thanks.  I've been using a git snapshot package for the Ed25519 support, was wondering if I could finally get rid of it.  As always, thanks for the info.
[00:18] <cjwatson> Unit193: I'll think about it :)
[00:21] <Unit193> :)
[07:07] <doko> toabctl, nacc, xnox: about zypper: the right thing to do is to have a libzypp transition (which was not done when doing the GCC 5 transitions)
[08:41] <pitti> Laney: hm, I can't push to autopkgtest-cloud any more; do you mind grabbing http://www.piware.de/tmp/0001-autopkgtest-web-charm-Fix-description-of-github-stat.patch ?
[08:42] <pitti> Laney: I was looking what it would take to support alternative users for github requests, and spotted that in the meantime
[08:43] <pitti> (turns out I was confused and we don't actually need this, though)
[09:07] <Laney> pitti: righto
[09:07] <Laney> I still haven't looked at that github stuff at all
[11:50] <cult-> only 1 day left!!
[13:04] <Laney> pitti: do you have a sec for a quick autopkgtest question?
[13:04] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/armhf/b/bbswitch/20170222_094343_2af9f@/log.gz
[13:04] <Laney> missing apt update I guess, but how's that meant to happen?
[13:08] <pitti> Laney: that looks very odd indeed -- I see the partial apt upgrade from --apt-pocket=proposed, but not the one from --apt-upgrade
[13:12] <pitti> oh, I see -- we usually hide it: apt-get update | tee /proc/self/fd/2
[13:13] <pitti> ah no, it should appear on stdout for grepping for "Not Found", and also to stderr, so where did that go
[13:14] <Laney> https://paste.ubuntu.com/24052958/
[13:14] <Laney> with --debug
[13:24] <zul> doko: ping...have you had a chance to look at those reviews yet?
[13:25] <pitti> Laney: whee, where did the --apt-upgrade go to,  it's not there at all
[13:29] <Laney> pitti: looks like it's meant to be in setup_commands, but isn't
[13:30] <Laney> no wait, it is
[13:30] <Laney> but it's after setup-canonical.sh
[13:30] <Laney> and setup-canonical wants to do apt-get install build-essential on trusty
[13:30] <pitti> I don't see it in e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/l/lxc/20170221_084939_cab44@/log.gz either
[13:31] <pitti> Laney: it is? I don't see it in your pastebin at all
[13:32] <Laney> pitti: https://paste.ubuntu.com/24053024/
[13:32] <pitti> Laney: oh! so this is from setup-canonical (build-essential) indeed
[13:32] <pitti> Laney: so yes, seems we need to run --apt-upgrade before setup-canonical then?
[13:32] <Laney> seems like it
[13:32] <Laney> maybe just swapping the add_argument() will do it?
[13:32] <pitti> fun that this never broke before
[13:33] <pitti> the argv.append() you mean? yeah, the order of --setup-commands is the one you give on the CLI
[13:34] <pitti> Laney: untested: http://paste.ubuntu.com/24053032/
[13:35] <pitti> Laney: I'm not completely sure that some of the setup scripts might need to run before upgrading the testbed
[13:35] <Laney> pitti: meh, I would rather fix autopkgtest so the order you give stuff doesn't matter
[13:35] <pitti> Laney: well, but it does
[13:36] <pitti> we can't predict the order in which to run them if the user can't
[13:36] <pitti> it's not a given whether you need to run some setup before or after upgrading; think firewall rules or other networking setup
[13:36] <Laney> just make apt-upgrade always happen before setup commands
[13:36] <Laney> hmm
[13:37] <Laney> good point
[13:37] <pitti> setup-testbed for sure needs to run before
[13:38] <pitti> well, actually not, as long as we use custom images (but we don't for stables)
[13:39] <pitti> I'd rather rearrange setup-canonical to install build-essential later, or just add an apt-get update right before it
[13:39] <pitti> (last is easiest, but also costs a few seconds extra)
[13:40] <Laney> what's this Jenkins testbed comment?
[13:40] <Laney> is that still relevant?
[13:43] <pitti> Laney: yes, it is; until around that time we ran stuff on handcrafted VMs which had build-essential pre-installed
[13:43] <pitti> Laney: later on we fixed tests to declare that as a test dep if they needed to build stuff, but our standard cloud images don't have build-essential
[13:43] <pitti> so when we moved to the "new" infra, a lot of tests failed due to missing gcc and the like
[13:44] <pitti> so either we SRU all those to trusty, or (what we opted for back then) we just grandfather this to install build-essential into trusty testbeds
[13:46] <Laney> pitti: ok, so it's a transitional thing that was later fixed, that makes sense
[13:52] <Laney> I'm worried about that MTU thing if I put the --apt-upgrade first
[13:53] <pitti> Laney: yeah; as a quick fix I'd just add an apt update into setup-canonical (for trusty)
[13:54] <Laney> pitti: Yeah, but then I get worried about dealing with that being flaky
[13:54] <Laney> Maybe it won't be
[13:56] <smoser> sarnold, we will have that, yes. how would you use it?
[13:57] <smoser> are you using the ec2 metadata service?
[13:58] <pitti> Laney: copy the retry bit from lib/autopkgtest_args.py?
[13:58] <Laney> right
[13:58] <pitti> Laney: a simple apt-get update || (sleep 15; apt-get update) should probably do, too
[13:58] <Laney> I did that for now (well, 10 instead of 15)
[15:20] <smoser> rbasak, is it approved behavior still for me to run usd import if there is a package missing that i want ?
[15:20] <smoser> or is there a "proper" way to get it
[15:20] <smoser> by 'run', i mean run with push
[15:21] <rbasak> smoser: yeah just run with push
[15:21] <rbasak> usd import -l racb -v foo # is what I use
[15:26] <smoser> usd import -v --directory=foo --lp-user=smoser --lp-owner=usd-import-team foo
[15:26] <smoser> is what my wrapper does
[15:27] <smoser> i'll drop explicitly adding the --lp-owner
[15:28] <doko> zul: networking-bagpipe networking-bgpvpn os-faults accepted (wondering who else is doing source reviews ...)
[15:28] <zul> doko: thanks!
[16:09] <LocutusOfBorg> pitti, any idea about acct and  https://wiki.ubuntu.com/Teardown ?
[16:09] <LocutusOfBorg> I would like to drop the merge
[16:10] <pitti> LocutusOfBorg: https://merges.ubuntu.com/a/acct/acct_6.5.5-2.1ubuntu1.patch is wrong anyway
[16:10] <pitti> LocutusOfBorg: well, the debian/rules portion is
[16:10] <LocutusOfBorg> yes, the override in rules file
[16:10] <pitti> debian/acct.init.d is fine (and the only thing that is relevant)
[16:11] <LocutusOfBorg> sooooo sync?
[16:11] <pitti> if you want to go back in sync, it's not the worst thing in the world
[16:11] <pitti> it should at least be reported in Debian though, and applied there
[16:11] <LocutusOfBorg> is this thing still an issue with systemd?
[16:11] <pitti> although in systemd it's completely irrelevant
[16:11] <pitti> no, if a service is running, it will be stopped regardless of what that LSB header says, it's only a small optimization in Debian under sysvinit
[16:11] <LocutusOfBorg> so, since we don't support multiple init systems...
[16:11] <pitti> LocutusOfBorg: so yes, go sync it
[16:12] <LocutusOfBorg> done thanks
[16:12] <pitti> dropping deltas is always nice
[16:13] <LocutusOfBorg> maybe I can commit on debian git
[16:15] <LocutusOfBorg> done :)
[17:52] <kierqueen> how id a package made ? after compiling my program using make ?
[17:52] <kierqueen> what then shall I do , use tar to compress, and archive
[17:52] <kierqueen>  then where did .deb come in the story
[17:52] <kierqueen> nacc: hi
[17:52] <nacc> kierqueen: ok, are you asking how to make a new package?
[17:56] <kierqueen> nacc yes
[17:57] <kierqueen> nacc sorry for the late reply hope you don't mind
[17:57] <nacc> kierqueen: it's fine
[17:57] <nacc> kierqueen: you don't really need to use bzr, of course
[17:58] <nacc> kierqueen: http://packaging.ubuntu.com/html/packaging-new-software.html is just a guide
[17:58] <kierqueen> yeah, the nwhat shall I use ?
[17:58] <nacc> https://wiki.debian.org/HowToPackageForDebian may also help
[17:58] <kierqueen> I have a ismple C program I want to package it ?
[17:59] <nacc> kierqueen: technically your SCM choice is irrelevant
[17:59] <nacc> kierqueen: if it's a simple application, you may wnat to snap it
[17:59] <nacc> kierqueen: http://www.snapcraft.io/
[18:00] <nacc> kierqueen: requires some ramp-up, but a lot less knowledge of debian packaging
[18:00] <nacc> kierqueen: why do you want to package up your C program as a .deb?
[18:01] <kierqueen> dude most binaries that you download are in C or C++
[18:01] <nacc> kierqueen: binaries are not in a language.
[18:02] <kierqueen> flightgear a large game, and tons of other packages of .deb they are all programs
[18:02] <kierqueen> binaries are compiled, their source is C or C++ usually or python
[18:02] <kierqueen> I don't use java
[18:02] <nacc> kierqueen: i genuinely asked to help -- making your own .deb for a simple program is probably overkill
[18:02] <nacc> kierqueen: if it's a simple program, snapping will be fastger
[18:02] <nacc> *faster
[18:03] <kierqueen> yeah I like ubuntu is always lenient on you. actually I migrated from arch, so that old overkill arch habit
[18:03] <kierqueen> In arch we use PKGBUILD and make that, if there is no build file for a software
[18:05] <nacc> kierqueen: i know nothing about arch. If you insist on building your own .deb, read the above guides (and you can use dh_make to frame out your pacakge, potentially)
[18:06] <kierqueen> nacc: I guess ubuntu is so friendly, that I wont need it at all :)
[18:06] <kierqueen> and I am not doing a computer related job either
[18:07] <nacc> kierqueen: i have no idea what you're talking about now
[18:07] <kierqueen> so I don't need it , i feel
[18:07] <kierqueen> nacc: ?
[18:07] <kierqueen> I don't need it ?
[18:07] <nacc> kierqueen: you don't need what?
[18:07] <kierqueen> I am not a software developer, to package a thing ?
[18:07] <nacc> kierqueen: I don't know if you need to package something or not
[18:07] <kierqueen> to make a pakcge of a source ? why should I?
[18:07] <nacc> kierqueen: I don't know, you asked the question...
[18:07] <kierqueen> why should I ? I am not getting paid anyway
[18:08] <kierqueen> why should anyone else if they are not getting paid, unless they are stupid, and want to kill their time
[18:08] <viral_mutant> I am building a deb package. I need to include a bunch of service files into the package. I dumped all the files in debian directory
[18:08] <kierqueen> nacc: there are lots of linux hobbysts out their who want to kill their time
[18:08] <nacc> kierqueen: ok, i'll assume you're trolling now
[18:08] <kierqueen> lol
[18:08] <viral_mutant> but it picks only the one which matches the name exactly
[18:09] <kierqueen> no I am not
[18:09] <nacc> viral_mutant: the name of the pacakge?
[18:10] <kierqueen> nacc I don't have time to waste on trivial pc matters, there are other things in my llife, and ubuntu makes things easier, so no need , unless I get paid, but I don't DO A JOB IN THAT category
[18:10] <nacc> kierqueen: i have no idea why that's relevant to discussing why you want to package your simple C program. I guess you're saying you don't. Then I don't understand why you asked the question in the first place.
[18:10] <viral_mutant> I am building openstack-account package. And the service files are named openstack-account.service, openstack-account-auditor.service, -reaper.service etc
[18:11] <kierqueen> nacc you are right, I don't neeed it , I misjudged
[18:11] <viral_mutant> it includes only openstack-account.service in openstack-account.deb package
[18:11] <nacc> viral_mutant: right, by default, dh_systemd will only install services named for the package, maybe?
[18:11] <kierqueen> was just curious
[18:11] <nacc> kierqueen: and you were given guides, and several suggestions
[18:11] <kierqueen> that's all nacc nothing else, no other purpose
[18:13] <viral_mutant> nacc: but there must be a way to override it
[18:13] <viral_mutant> like there is for the init files
[18:14] <nacc> viral_mutant: i think you need to override dh_installinit in your rules and specify to install multiple named services
[18:15] <nacc> viral_mutant: that's where that default is specified (dh_installinit by default uses the package name)
[18:16] <viral_mutant> yes, I am trying with that
[18:17] <viral_mutant> but it’s not picking it. The man page says that —name option works for init files
[18:17] <viral_mutant> there is no mention of service files
[18:19] <nacc> viral_mutant: the manpage says it works for all types, what versin of ubuntu are you on?
[18:19] <viral_mutant> 16.04
[18:20] <sarnold> smoser: just the usual stuff I think: create user with ssh keys, install different packages based on the 'type' of VM I want to spin up, etc
[18:20] <nacc> http://manpages.ubuntu.com/manpages/xenial/en/man1/dh_installinit.1.html "associated defaults files, as well as upstart job files, and systemd service files"
[18:20] <viral_mutant> I am looking at manpage on the net
[18:20] <nacc> viral_mutant: can you pastebin your d/rules?
[18:21] <nacc> viral_mutant: and the output from building your package
[18:24] <smoser> sarnold, where do you do it ?
[18:24] <smoser> locally with kvm you mean ?
[18:25] <smoser> i suspect you'll be ok if you're launching things locally, and the intent is to not cause issue on any cloud. but just trying to get more example so i can (if possible) make sure i *dont* break you
[18:26] <sarnold> smoser: well, I haven't -written- my libvirt NIH yet :)
[18:26] <sarnold> smoser: I'm still NIHing simplestreams..
[18:26] <smoser> :)
[18:27] <sarnold> which btw serde was able to derive implementations piece of cake. Amazing thing.
[18:27] <smoser> ?
[18:27] <sarnold> serde is rust's magic serialization / deserialization framework
[18:28] <smoser> oh ok.
[18:30] <smoser> sarnold, well, if you use NoCloud (attached disk) it should all just work. if you are planning on using another datasource, then you'll have to "fake" out that datasource.
[18:31] <sarnold> smoser: thanks for the tip :D
[18:31] <smoser> if you're able to modify the kernel command line, or put a config in place, then you can do that too
[18:31] <smoser> kernel command line:
[18:31] <smoser> ci.ds=Ec2
[18:31] <smoser> will make you do ec2.
[18:34] <sarnold> ooooo
[18:34] <sarnold> that's the magic sauce :)
[18:34] <viral_mutant> nacc: here is the d/rules file http://pastebin.com/MuiQcP19
[18:35] <sarnold> thanks smoser :)
[18:35] <viral_mutant> I am using rules file bundled with Ubuntu swift-account package as reference
[18:39] <nacc> viral_mutant: did you read the manpage? debian/package.name.init,
[18:39] <nacc>            debian/package.name.default and debian/package.name.upstart
[18:39] <nacc> viral_mutant: which to me implies you need to put the .service file in a similar named structure
[20:08] <juliank> Mmh, apt seems to be tricky today. It failed three times in the download progress test. I know that's an unreliable test, but that's a new low (or rather, a high)...
[20:08] <juliank> Let's give that one more go. Everyone else did it right, just armhf wants to annoy me
[20:09] <juliank> Not that it's urgent with beta freeze, but it's still fairly annoying.
[20:37] <pitti> juliank: wrt. debian bug 855954 -- is there some version of "apt-cache policy pkg" that *only* gives me results for the package pkg?
[20:38] <pitti> juliank: by default it seems to do some kind of substring matching, and enclosing it between ^ and $ then gets confused by '+' in the package name
[20:38] <pitti> juliank: i. e. some equivalent of apt-get source's --only-source option?
[20:39] <pitti> I want to know the candidate version of a given package -- perhaps I shouldn't be using apt-cache for that
[20:39] <juliank> pitti: Not sure, I don't think so. Maybe ask python-apt instead
[20:40] <pitti> juliank: I can't assume that this is installed
[20:40] <juliank> pitti: Use apt-cache show <pkg>/candidate
[20:40] <pitti> juliank: ok, thanks; I just wanted to know whether I'm missing something obvious
[20:41] <juliank> pitti: But I'm not sure when /candidate was added to show, so please try if you need to run that on old distros :)
[20:41] <pitti> yeah, it needs to work on precise, will check; thanks!
[20:41] <pitti> (if it works on trusty, I could kick the code in a few months :) )
[20:41] <juliank> pitti: Hmm, that probably does matching as well
[20:42] <juliank> pitti: Maybe just escaping the allowed regex characters, and turn it into an anchored regex is easier
[20:42] <pitti> yeah, I'm currently trying that; a bit fiddly with posix shell and nested $(), but I'll pour the right amount of escaping into it :)
[20:51] <pitti> $ dash -c 'pkg=minisat+; apt-cache policy "^$(echo $pkg | sed -r "s/([.+])/\\\\\1/g")\$"'
[20:51] <pitti> ain't that obvious :)
[21:17] <juliank> pitti: Whoa, what kind of regex is that?
[21:17] <pitti> juliank: well, apparently the one that tells apt-cache policy "please give me *THIS* package name *ONLY*" :)
[21:18] <juliank> pitti: The \  have an uneven number, that's a bit odd
[21:19] <juliank> with one more \ it works as well
[21:19] <juliank> or not
[21:19] <pitti> juliank: yeah, true that
[21:19] <pitti> (haven't tested, but it sounds plausible)
[21:19] <juliank> well, it gives me "minisat \+"
[21:19] <pitti> \\\\ through the two shells becomes \
[21:19] <juliank> Ah no, input error
[21:19] <pitti> and \1 is the backref for sed
[21:20] <juliank> Actually, the number of shells does not matter
[21:21] <juliank> Just running echo minisat+ | sed ... in the terminal has the same result as putting that inside a dash -c
[21:21] <juliank> $() has some odd quoting rules
[21:23] <pitti> juliank: TBH, I kept adding \ until it worked..
[21:23] <pitti> the sophisticated term for that that hides the fact that you don't understand what you are doing is "Test Driven Development" :)
[22:00] <acheronuk> barry: gpgme -> release seems to be happening :)
[22:20] <barry> acheronuk: yep, i believe it was blocked for beta1.  yay
[22:22] <nacc> whew and it looks like perl will transition too
[23:05] <juliank> I think I'm about to give up. I tried running the apt tests on armhf 4 times now, but they still fail with one of these test cases that fails from time to time