[00:13] <hallyn> stgraber: practical question .  to migrate a kvm vm from old release to newer release, we need the old rom's (like pxe-virtio) on the new releases.  But the new releases have updated versions of the roms.  Is there a good way to support this?  i can't ship binary roms, and the old roms may not build on the new releases...
[00:14] <hallyn> i may be making this up, maybe it's not an issue excpet in my current broken case, but i'm not sure
[00:16] <stgraber> hallyn: I'm having a hard time understanding why the VM would need the old ROM
[00:32] <hallyn> stgraber: bc at the destination qemu you have to start qemu with that romfile loaded
[00:32] <hallyn> stgraber: so for instance if a precise kvm has a virtio nic, and you want to migrate that to a trusty host,
[00:33] <hallyn> (for which you have to use my ppa right now,) you have to use:
[00:33] <hallyn> sudo qemu-system-x86_64 -enable-kvm -drive file=/mnt/mini.iso,if=virtio,cache=none -m 256M -cdrom /mnt/mini.iso -boot d -vnc :1 -incoming tcp:0.0.0.0:5555  -global virtio-net-pci.romfile=pxe-virtio.rom.12.04 -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no -M pc-1.0-qemu-kvm
[00:33] <hallyn> the "-global virtio-net-pci.romfile=pxe-virtio.rom.12.04" argument tells kvm to load the old romfile.  if you let it load the new rom, thenmigratoin fails
[00:34] <hallyn> but i don't know how to sanely ship that romfile.  i have little faith that we can actually build a new one in trusty let alone 16.04
[00:34] <hallyn> anyway i've also asked the question of rharper.  i'll let this sit for a day while we think of alternatives.  mayb ei'm being silly.
[00:39] <stgraber> hallyn: sounds like a qemu bug to me... bios roms are loaded in memory, so if the VM was actively using the extension, it'd be in memory and so, not a problem. Otherwise, it's just a path to something it needs to read at boot time, so it should be perfectly fine to point it to whatever's current on that box...
[00:40] <hallyn> stgraber: i think it's just complaining about the file size.  which makes me wonder whether i could just create a file of the right size with all zeros
[00:42] <stgraber> hallyn: :)
[00:48] <hallyn> stgraber: lol - it works!
[00:48] <hallyn> well it hangs at 'detect network hardware' but it did that before too.  (this all feels very flaky)
[04:17] <pitti> Good morning
[06:57] <dholbach> good morning
[07:33] <dupondje> the ubuntu mozilla team seems sleeping? :D
[07:59] <chrisccoulson> dupondje, not so much sleeping, but dead
[09:00] <nrange> like to build ubuntu core for arm device, Could any body provide me link for the same.
[09:03] <pitti> mvo: hey Michael, wie gehts?
[09:03] <mvo> pitti: not too bad, thanks. how are you?
[09:03] <pitti> mvo: great, thanks! you don't happen to have an idea about https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/ARCH=amd64,label=adt/31/console ?
[09:03] <pitti> mvo: the test works fine on i386, but fails on amd64 (severeal times)
[09:03] <pitti> initially I thought it was something in binNEW or so, but that doesn't seem to be the case
[09:06] <mvo> pitti: let me investigate and see if I can reprouce it
[09:06] <pitti> mvo: it works fine for me locally
[09:07] <pitti> mvo: nevermind for now, I just wanted to know if you already happened to know about it
[09:07] <pitti> before I start digging
[09:08] <mvo> pitti: thanks, its probably transient, as it will look at the build-hosts sources.list (which is a bug in itself)
[09:08] <pitti> mvo: seems to be a little more than that, though; look at the history at https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/
[09:09] <mvo> pitti: indeed :/
[09:09] <pitti> mvo: oh, perhaps this is fallout from the new proxy settings; but why would that affect only one arch
[09:09] <pitti> anyway, I'll poke this
[09:09] <mvo> pitti: hm, I wonder if I overlooked a mail here?
[09:09] <mvo> pitti: would jenkins have mailed me about the failure?
[09:10] <pitti> hm, seems it didn't in this caes
[09:10] <pitti> case
[09:10] <mvo> because the failure affects only a single architecture?
[09:10] <pitti> sheesh, and now it succeeded
[09:10] <mvo> haha
[09:10] <mvo> schrödingers cat
[09:10] <pitti> mvo: sorry for the noise then; I retried 5 times in the past days and it kept failing..
[09:11] <mvo> no worries, I really need to fix it to use proper fixtures data instead :/
[09:11] <pitti> mvo: yet another instance of "the problem disappears/becomes clear to me as soon as I ask someone"
[09:13] <mvo> :)
[09:28] <seb128> jibel, hey, just curious but why do you tag fix released bugs?
[09:28] <jibel> seb128, they are not fixed on #1
[09:28] <jibel> 14.09 #1
[09:28] <seb128> jibel, we are on #56, most of the bugs are not fixed on #1 ;-)
[09:29] <jibel> seb128, 14.09-proposed is #56 but 14.09 is #1
[09:29] <seb128> oh ok
[09:29] <seb128> the tag names are confusing then
[09:29] <seb128> is that a way to say "needs-fixing-in-stable"?
[09:30] <nrange> I trying to get ubuntu-core source code ,
[09:30] <nrange> where do I get ubuntu-core source code & cross compilation link for ARM.
[09:32] <ogra_> nrange, from archive.ubuntu.com ... it is in source packages
[09:32] <ogra_> nrange, ubuntu-core itself is assmebled from the corresponding binary packages
[09:48] <cjwatson> mdeslaur: nginx> no problem, thanks
[09:50] <nrange> ogra_ :Is it possible to get ubuntu-core source code through apt-get command?
[09:50] <ogra_> you need the list of packages
[09:50] <ogra_> then you can apt-get source the packages
[09:51] <rbasak> mdeslaur: speaking of nginx, looks like it's failed dep8.
[09:51] <rbasak> (so stuck in -proposed)
[09:51] <rbasak> I don't think these dep8 tests have ever been in Ubuntu. Debian rewrote the one I submitted.
[10:17] <rbasak> Is there a tool that will let me easily download the already-built binaries from the archive corresponding to a given source package and architecture?
[10:18] <rbasak> I know I can fetch them by hand from Launchpad.
[10:18] <rbasak> (and I'll provide the version, of course)
[10:19] <rbasak> I just set off a local build to reproduce a dep8 issue in utopic-proposed, and realised that's a bit pointless since I can fetch the archive binaries.
[10:19] <rbasak> Except that it's tedious.
[10:42] <rbasak> mdeslaur, pitti, jibel: I can't reproduce nginx dep8 failure in utopic-proposed locally. The logs look about the same, and it passes for me.
[10:42] <rbasak> The Jenkins result appears to be a 404, which seems a bit odd. That suggests to me some issue in the test rather than the environment, but I don't see anything obvious.
[10:47] <nrange> ogra_ :  gone through (https://wiki.ubuntu.com/ARM/RootStock) doc, could u provide link for to get ubuntu-core package list.
[10:48] <ogra_> nrange, rootstock is dead since several years, dont use it
[10:49] <ogra_> nrange, look at the manifest file at http://cdimage.ubuntu.com/ubuntu-core/daily/current/
[10:57] <dholbach> salut seb128, is bug 1352142 something that happyaron or FJKong could ACK and we could get uploaded?
[10:57] <ogra_> ugh, another font ?
[10:58] <ogra_> we're just ripping them out like crazy to get the image size down :/
[11:02] <seb128> dholbach, hey, no idea what are the ffe/release rules for touch
[11:02] <seb128> dholbach, try asking on #ubuntu-ci-eng I guess
[11:04] <Laney> why are you asking the chinese guys about a japanese font? :P
[11:05] <seb128> because japanese looks chinese to him? ;-)
[11:10] <pitti> rbasak: one possible issue could be that in the DC tests run wiht a proxy
[11:10] <pitti> rbasak: is this test hitting the network?
[11:12] <dholbach> Laney, I think they're both in touch a lot with others who look into CJK issues, so they might know where to look up which fonts are recommended
[11:12] <dholbach> Laney, something I don't know anything about
[11:13] <Laney> was just doing some minor tuesday trolling, sorry
[11:13] <rbasak> pitti: aha.
[11:13] <rbasak> pitti: no, but it is hitting 127.0.0.1.
[11:13] <Laney> there's some feedback from a Japanese guy in there so I'd think it's okay depending on the touch guys
[11:13] <rbasak> pitti: and that 404s. So presumably that request is going to a proxy, which 404s on its _own_ 127.0.0.1?
[11:15] <infinity> If the test rig's proxy proxies for localhost, that pretty much breaks any attempt to test any http daemon.
[11:15] <rbasak> pitti: can you add a no_proxy environment?
[11:15] <infinity> Seems like a bug. :P
[11:16] <dholbach> seb128, I just looked at the MP - looks like it affects desktop as well
[11:16] <rbasak> Either that or the test needs to specifically unset http_proxy.
[11:16] <rbasak> I'm not sure it even makes sense to set that in the test environment.
[11:17] <rbasak> A transparent proxy might work better here (as evil as they are).
[12:20] <rbasak> mdeslaur, pitti, jibel: filed bug 1372903. As the test passes locally from the built binaries in utopic-proposed, do you want to override the test failure for now?
[12:23] <pitti> rbasak: re (sorry, was out for a bit)
[12:24] <pitti> rbasak: we do set that: http_proxy=http://squid.internal:3128 https_proxy=http://squid.internal:3128 no_proxy=localhost,ubuntu.com,launchpad.net
[12:25] <pitti> rbasak: ah, we might need to add 127.0.0.1 to no_proxy, not just "localhost"?
[12:25] <rbasak> pitti: that might be it.
[12:25] <mdeslaur> yes, the autopkgtest in debian went from localhost to 127.0.0.1
[12:25] <rbasak> Maybe 127.0.1.1 as well?
[12:26] <rbasak> I still think there's a bigger issue here though (hence the bug).
[12:26] <pitti> rbasak: ok, trying that; the machines are a bit busy ATM, so that'll take a while
[12:26] <pitti> mdeslaur: ah, splendid; that would fit pretty well
[12:26] <infinity> pitti: It would be a lot more elegant if that was implemented as a transparent proxy outside the VM, rather than exporting http_proxy in the test session.
[12:27] <pitti> infinity: absolutely
[12:27] <rbasak> We're changing behaviour in tests by setting these variables, and depending on what is being tested, this won't necessarily do the right thing.
[12:27] <infinity> pitti: A test session having unexpectedly weird environment is... Weird. :)
[12:27] <pitti> infinity: but that's not how our data center does it, so we need to set these stupid vars everywhere :/
[12:27] <rbasak> infinity: I suggest having the test declare that it needs external internet access, and when it does, to require that the test can grok the variables.
[12:27] <pitti> hopefully we won't have to any more in bootstack
[12:28] <infinity> pitti: Hrm?  I'm not sure how the DC factors into this.  Your VMs can have transparent proxies on the host that forward to the DC proxies.
[12:28] <rbasak> A transparent proxy is still not great. It does cause client issues in some cases.
[12:28] <rbasak> I'd rather push responsibility to the test.
[12:28] <rbasak> (and use non-transparent caches)
[12:28] <infinity> rbasak: Well, 99% of tests should never be trying to hit the outside world anyway.
[12:28] <pitti> infinity: ok, if that's possible I'm happy to send an RT about that
[12:29] <pitti> right, there's only a handful which need that
[12:29] <rbasak> Right, so do we need transparent caches on the ones that do?
[12:29] <pitti> we only added the proxy vars a few weeks ago for two tests which want it
[12:29] <rbasak> Make them explicit in that case.
[12:29] <rbasak> (my bug outlines a proposed spec)
[12:29] <cjwatson> the problem is tests that shouldn't hit the outside world but accidentally do.
[12:29] <infinity> But trying to hit the local host should be very common, and trying to be clever and guess what that is (or doing a blanket exclude of 127.0.0.0/8) is kludgy.
[12:30] <cjwatson> for example any of the gazillion things that will sometimes call out to fetch dependencies (maven, pip, etc.)
[12:30] <rbasak> Yeah, so by default: no inteference, and no access to the outside world.
[12:30] <cjwatson> oh right yeah
[12:30] <rbasak> If the test wants access, then it could declare a restriction, and then it would get access, but is required to grok http_access etc.
[12:30] <rbasak> http_proxy
[12:30] <infinity> Yeah, that's also workable.
[12:31] <infinity> I do like the idea of no non-lo network by default.
[12:31] <infinity> To catch people accidentally doing it rather than intentionally.
[12:31] <rbasak> Yeah, and also easier to analyse
[12:31] <rbasak> (to track packages down that are doing it but don't really need it)
[12:31] <infinity> pitti: So maybe that's the better solution.
[12:32] <infinity> pitti: Make those few tests actually declare that they need external access instead of granting it to everyone.
[12:32] <rbasak> Of course the catch here is that pitti now has to implement that :)
[12:32] <infinity> Sounds pretty trivial.
[12:32] <infinity> Except for the addition to the spec.
[12:33] <infinity> No idea how fluid that is.
[12:33] <rbasak> The spec is designed so that restrictions can be added. But a catch is that we're taking away functionality from existing tests.
[12:33] <rbasak> But if the number of affected tests is small, then that shouldn't be a problem.
[12:35] <infinity> rbasak: Well, by pitti's admission, those tests only got this functionality very recently. :P
[12:35] <pitti> finding and changing the tests is the real work here, not so much juggling the infrastructure
[12:35] <infinity> rbasak: So, it's a short-lived thing to take away again.
[12:35] <pitti> well, it also fixed some tests which had failed forevery
[12:35] <pitti> s/y$/
[12:35]  * rbasak suspects juju might be affected
[12:35] <infinity> pitti: I guess no one kept a list of the tests that were fixed by implementing the http_proxy stuff?
[12:36] <rbasak> Though that's been around for a while now.
[12:36] <pitti> but we also at some point want to move testing to bootstack, then this will hopefully also be obsolete
[12:36] <infinity> pitti: Still, I think it's better to be declarative here, rather than assume an external network.
[12:36] <rbasak> pitti: even after the move, it'd be nice to not have tests arbitrarily accessing the Internet unless they declare that they need to.
[12:36] <rbasak> That'll help keep things under control.
[12:36] <infinity> pitti: Cause that also makes it way easier to diagnose, if you say you need an external network, and my test infra doesn't have one, or doesn't have access to the right hosts, I know what's up more easily.
[12:36] <rbasak> Too many packages hitting the Internet == many arbitrary failures.
[12:37] <infinity> Plus, yes, reliance on external resources is usually wrong, unless absolutely the only way to test your thing.
[12:37] <infinity> The internet being such a reliable thing and all.
[12:38] <rbasak> I had fun with python-websocket (IIRC) having tests that hit a websocket test server on the Internet.
[12:39] <infinity> PS: Why am I still awake?
[12:40] <cyphermox> because you're not drunk enough yet?
[12:40] <infinity> Or at all.
[12:41] <mdeslaur> lol
[12:47] <happyaron> dholbach: hey I think if we do want to have Japanese fonts included, then fonts-takao-pgothic is the one to go
[12:51] <pitti> rbasak: nginx succeeds again
[12:52] <rbasak> Great. Thanks!
[12:53] <mdeslaur> thanks pitti, rbasak!
[13:01] <pitti> rbasak, infinity: I left some thoughts on bug 1372903
[13:04] <rbasak> pitti: could you "unshare -n" to enforce the restriction for adt-virt-null, etc?
[13:04] <pitti> rbasak: (1) breaks installing dependencies, (2) needs root
[13:04] <seb128> @pilot in
[13:04] <pitti> rbasak: we can't cut off the network completely
[13:05] <rbasak> pitti: for apt, use a proxy that permits only access to the archive.
[13:05] <pitti> rbasak: otherwise we could simply start qemu without a network card, etc.
[13:05] <rbasak> Good point about root though.
[13:05] <pitti> we need a proper network interface, and then restrict it to the set of deb sources
[13:05] <pitti> (there might be many, cf. testing PPAs, etc.)
[13:06] <pitti> TBH, I think it's a lot of work for a result which still isn't robust, and for only little gain
[13:06] <pitti> but maybe I'm missing something, we might discuss that face to face at some point
[13:07] <pitti> just saying that the proxy thing will go away soon, ev is pressuring hard for getting rid of our current machines
[13:07] <pitti> and so am I, these are hopelessly overloaded
[13:07] <rbasak> OK, no worries.
[13:07] <ev> +1
[13:07] <pitti> ah, this also fixes php-guzzle
[13:08] <pitti> and I have a gut feeling that it might also fix the python autopkgtests without the workaround of explicitly unsetting the proxy vars
[13:08] <pitti> rbasak: anyway, if you have an idea about a robust design, I'm happy to be convinced (honestly)
[13:09] <rbasak> pitti: thanks. You raise good points. I'll have to think a little and see if I can come up with something that addresses everything.
[13:09] <pitti> rbasak: let's stick our heads together in DC and add some beer :)
[13:10] <rbasak> I won't be in DC.
[13:10] <pitti> oh, too bad
[13:10] <pitti> servers aren't the right kind of devices? :-)
[13:11] <rbasak> Yeah, something like that!
[13:13] <pitti> rbasak: thanks so much for pointing out the proxy bug -- this fixed at least two other tests (and presumably there's some more)
[13:13] <rbasak> No problem! You provided the vital clue :)
[13:17] <dholbach> happyaron, if we want this new one, can we drop one we used before?
[13:17] <dholbach> happyaron, could you comment on the bug and/or MP=
[13:17] <dholbach> ?
[14:32] <FJKong> dholbach: he is not at front of computer,maybe
[14:33] <dholbach> FJKong, do we know who could have a look at the bug or merge proposal and make a decision?
[14:34] <FJKong> dholbach: you mean bug: https://launchpad.net/bugs/1352142
[14:35] <dholbach> yep
[16:01] <arges> ChrisTownsend: hey, should i review that unity SRU for trusty...
[16:02] <ChrisTownsend> arges: Please
[16:02] <ChrisTownsend> arges: Thanks
[16:02] <arges> ChrisTownsend: looks like you guys have alot of DPI fixes... did somebody get a fancy monitor?  : )
[16:03] <ChrisTownsend> arges: lol, well, it's stuff that just needed to be done.
[16:05] <arges> ChrisTownsend: bug 1349128 is mentioned in the changelog, but it says its already fix released. Do you know what changed there?
[16:08] <bregma> arges, that was a security upload that's now been folded back into upstream
[16:10] <arges> bregma: ok, but I see more details in the changelog that looks like additional logic was added over the security update?
[16:11] <arges> bregma: ChrisTownsend : also bug 1320071 is this fixed in Utopic?
[16:11] <smoser> kirkland, is http://launchpad.net/bugs/1350810 in correct state ?
[16:11] <smoser> it says fix-released for tmux, but not for byobu
[16:12] <kirkland> smoser: ah, yes, it's fix-release;  fix was in tmux
[16:12] <kirkland> smoser: so probably invalid for byobu
[16:12] <bregma> arges, I believe there were additional problems related to 1349128 fixed in trunk that were backported to 14.04 for the non-emergency fix
[16:12] <kirkland> smoser: updated
[16:13] <arges> bregma: ok
[16:13] <bdmurray> pitti: Could you have a look at RT 1372612?
[16:13] <bdmurray> pitti: I mean bug 1372612
[16:16] <bregma> arges, bug 1320071 is definitely fixed in utopic, don't know why ci-train missed changings its status
[16:17] <arges> bregma: ok i assume you'll update that then?
[16:17]  * bregma fixes the status manually
[16:22] <ara> bdmurray, hello! could you have a look to this unapproved SRU, please? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=unity-control-center
[16:23] <arges> ara: i'm planning on getting to it today (its my day)
[16:23] <ara> arges, sounds great, thanks!
[16:24] <ara> arges, not really aware of how the sru queue is managed
[16:24] <arges> ara: check https://wiki.ubuntu.com/StableReleaseUpdates
[16:24] <bdmurray> ara: we have a daily rotation of sorts
[16:24] <arges> section 4 shows SRU vanguards
[16:24] <Elimin8er> Im trying to build a package.. when I use checkinstall everything works great. but I want to build it with the intent of putting it on my ppa.. anyhow when I use bzr builddeb -- -us -uc, I get error at the end, take a look here: http://paste.ubuntu.com/8408128/ .. I just dont get it.. Hopefully someone can give me a pointer or two.. .. I have asked in every other channel I could think of..
[16:24] <ara> bdmurray, arges: nice! thanks! and sorry for nagging the wrong person :)
[16:25] <arges> ara: its all good! glad I had this channel up to see the message
[16:25] <bdmurray> ara: no problem
[16:25] <ara> the sru team is too small... you guys are heroes
[16:26] <bdmurray> ara: thanks
[16:57] <mdeslaur> @pilot in
[18:14] <ChrisTownsend> arges: Hey again, any chance you look at unity8-desktop-session to get into trusty-proposed?  It's a pretty simple fix.
[18:14] <arges> ChrisTownsend: yea its all on my radar
[18:14] <ChrisTownsend> arges: Awesome, thanks man!
[18:14] <arges> trying to do some kernel debugging ATM... so will context switch into SRU mode in a bit
[18:15] <ChrisTownsend> arges: Ok, cool
[18:59] <arges> hallyn: hey is bug 1038139 fixed in utopic already?
[19:04] <hallyn> arges: I pushed that to utopic right before pushing the SRU packages
[19:05] <arges> hallyn: ok shall i mark the utopic task fix released (not sure which version has that code in utopic) (also I'm being lazy. : ) )
[19:06] <hallyn> arges: hm, no, something's not right
[19:08] <hallyn> arges: d'oh, we're in beta freeze aren't we
[19:08] <hallyn> arges: so we'll have to wait until that passes
[19:08] <hallyn> if you don't mind please jsut leave the trusty/precise versions baking in the meantime :)
[19:08] <arges> hallyn: yup will do. thanks
[19:08] <hallyn> thank you
[19:23] <arges> ChrisTownsend: is bug 1340394 fixed in utopic version?
[19:24] <ChrisTownsend> arges: I think so, but lemme check to be sure.
[19:24] <arges> ChrisTownsend: thanks
[19:25] <arges> ChrisTownsend: also not really something that matters for this SRU, but do you have a script that continually appends AUTHORS?
[19:25] <ChrisTownsend> arges: Yeah, it was released into Utopic around July 11.
[19:25] <arges> ChrisTownsend: ok marked that fix released then
[19:26] <ChrisTownsend> arges: The release script in Unity does muck with AUTHORS.  Is there something wrong?
[19:26] <arges> ChrisTownsend: well it just seems to be duplicating author names over and over, vs it being a uniq list
[19:27] <ChrisTownsend> arges: Hmm...
[19:29] <arges> anyway, doesn't matter for the SRU, might just want ot check your script
[19:30] <ChrisTownsend> arges: I see 3 new AUTHORS entries and the entries themselves are unique in that the line is indicating the multiple authors are responsible for a commit.
[19:31] <ChrisTownsend> arges: Do you see something different?
[19:32] <arges> ChrisTownsend: no that's fine, I just usually see AUTHORS files with just a list of unique authors rather than commit->AUTHORS line mapping
[19:32] <ChrisTownsend> arges: Ok, I see.  Well, I guess Unity really wants to give credit where credit is due:)
[19:32] <arges> yep got it
[19:52] <roaksoax> arges: why did the djanog upload get rejected?
[19:52] <arges> roaksoax: i explained it in the bug report. there was an extra patch that wasn't explained in the changelog
[19:52] <arges> 99_fix_test.patch
[19:54] <roaksoax> arges: yeah that seems that it shouldn't be there for sure.. but it wasn't ebing applied either
[19:54] <roaksoax> arges: thanks for noticing, let me upload a new one asap
[19:54] <arges> roaksoax: cool. ping me when you do and I'll re-review
[20:08] <sarnold> pitti: hello, are the retracers happy? 1372980 hasn't been handled yet (five hours at the moment) -- and lately things have been running pretty smoothly, this seems anomalous :)
[20:13] <mdeslaur> @pilot out
[20:17] <seb128> @pilot out
[20:48] <roaksoax> arges: uploaded a new one! thanks
[20:50] <arges> roaksoax: this looks better... there is an extra line '+  * debian/patches/
[20:51] <arges> in the changelog. but that shouldn't hurt things
[21:05] <roaksoax> arges: awesome! thanks