[01:56] <smoser> pitti, awake ?
[03:50] <Guest36261> Hey guys! Can someone suggest a resource for how to get started submitting this: http://https://askubuntu.com/a/674103/299065 as a patch for 14.04? Every time I update ubuntu base I have to do this and wanted to just backport it once and for all.
[03:52] <Guest36261> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498633
[03:54] <micahg> Guest36261: the xenial kernel will be backported to 14.04 sometime after the initial release
[03:54] <sarnold> Guest36261: try using the linux-lts-wily packages
[03:55] <Guest36261> ah ok
[03:56] <Guest36261> exit
[03:56] <sarnold> Guest36261: this may be helpful https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[03:56] <Guest36261> lol
[03:56] <sarnold> (and you;'re probably looking for /quit)
[03:57] <Guest36261> heh... been using slack too much. spoiled
[03:58] <RAOF> Oh, urgh.
[03:58] <Guest36261> sarnold: oh I think this is exactly what I need
[03:58] <RAOF> I don't suppose we can throw away a single architecture's builds from -proposed.
[03:59] <sarnold> Guest36261: note that you'll probably want to switch to linux-generic-lts-xenial once it is available, it'll be supported a lot longer
[03:59] <RAOF> (apitrace hasn't migrated from -proposed because it built on s390x before libprocps4 was available there)
[04:00] <sarnold> Guest36261: (or switch to xenial itself, of course, up to you :)
[04:07] <tumbleweed> RAOF: nope, no-change rebuild
[04:08] <RAOF> tumbleweed: Yup, thought as much.
[04:09] <tumbleweed> LP has principles about rewriting history :)
[04:28] <AustinPray> Guest dude here
[04:28] <AustinPray> thanks for the help. Maybe one of these days I'll get to patch something :P
[04:28] <sarnold> :)
[04:30] <AustinPray> sarnold: I don't think you understand how much that wiley kernel fixed lol
[04:30] <AustinPray> problems I didn't even know I had
[04:34] <sarnold> AustinPray: oh? :)
[05:52] <cpaelzer> good morning
[07:26] <rbasak> mvo: sure. ping.
[07:54] <dholbach> good morning
[08:16] <cpaelzer> hi, I'd ask for some advice on a dependency for a package I'm working on
[08:16] <cpaelzer> its working fine without, but depending on the case can be enhanced when modules from "linux-image-extra*" are around
[08:16] <cpaelzer> that fulfils a "suggests" IMHO
[08:17] <cpaelzer> but my gut feeling says that with a dependency because of a kernel module it might be more complex than just "suggests linux-image-extra-virtual"
[08:18] <cpaelzer> like what about hwe kernels ...
[08:18] <cpaelzer> any general rule how we usually do this?
[08:31] <cpaelzer> still too early :-) rbasak I saw you pinging already this morning do you have an advice on my question above?
[08:33] <rbasak> I wonder if "extra" is something that those packages official Provide or something.
[08:33] <rbasak> I don't know though. apw is a good person to ask.
[08:33] <rbasak> (he's UK based so may be around soon)
[08:33] <cpaelzer> rbasak: thanks, I'll ask him later
[08:53]  * LocutusOfBorg wonders about a glibc upgrade for xenial
[09:06] <smb> cpaelzer, rbasak, If it is just about what "extra" this is. More or less any modules that were not deemed critical (or in other words, those that cloud-image did not want to get installed)
[09:07] <cpaelzer> smb: I found what the package is about and it clearly is a suggets
[09:07] <cpaelzer> smb: I wondered if that would be "Suggests: linux-image-extra-virtual" then or any more special case to get dependencies and versioning right
[09:09] <cpaelzer> that line above is what I think it should be atm, but I wanted some confirmation about that as my gut feeling was telling me this could be a special case
[09:09] <smb> cpaelzer, That and the virtual. That is something (iirc) that only exists as meta package dependencies. There is (for quite a while now) no kernel flavour of virtual anymore
[09:09] <smb> only generic and lowlatency (for x86)
[09:09] <rbasak> Part of the problem is that it's only a moving metapackage and it's feasible to not have one installed.
[09:10] <cpaelzer> smb: yeah linux-image-extra-virtual is a meta that pulls in what currentl ymatches
[09:10] <rbasak> So it'd be better if the real package provided an unmoving virtual package.
[09:10] <rbasak> (I don't know if it already does)
[09:10] <smb> rbasak, there is no real virtual package
[09:10] <rbasak> OTOH, it's only a Suggests, and nothing does anything with those by default AFAIK.
[09:14] <smb> actually linux-image-extra-virtual would be even more feasible having not installed as the whole virtual meta thing is about having a meta that keeps the combination of kernel and headers moving over abi changes without the extra ...
[09:14] <cpaelzer> smb: rbasak: thanks for the discussion - I just wanted to do it right in te first try, but it seems there are no hard objections against it
[09:14] <cpaelzer> so I can go on and test it like this for now
[09:15] <smb> cpaelzer, ^ not sure you saw my last comment as we probably typed at the same time
[09:16] <cpaelzer> smb: in a meeting, thanks IÄll go through it in a minuzte
[09:19] <mvo> stgraber: the most recent gosexy-gettext upload had issues, I did a followup upload (just fyi), stuff should be fixed now
[09:19] <mvo> rbasak: hi, oh, software-properties-common, hm
[09:20] <mvo> rbasak: I htink we can drop this dependency, we just need to make sure that the GUI does not offer to set "auto-install-security-updates"
[09:20] <oSoMoN> Mirv, seen the latest comments on https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1552860 ? Can you maybe comment?
[09:20] <mvo> rbasak: if it is not installed
[09:20] <mvo> rbasak: that was the question, right?
[09:22] <rbasak> mvo: yes, I think so. I think it comes from "Why can't I remove unattended-upgrades without breaking my system more deeply?" -> "Can we remove the dependency?" -> "What might we break if we remove the dependency and how might we fix that?"
[09:24] <Mirv> oSoMoN: ok
[09:24] <mvo> rbasak: I think we should remove the dependency and fix the gui to ensure it DTRT and then we seed unattended-upgrades explicitely where it is needed
[09:24] <rbasak> mvo: that sounds good :)
[09:24] <rbasak> Beret: ^
[09:25] <rbasak> mvo: right now it's a hard dependency. I wonder if seeding as a recommend would be more appropriate for what it is?
[09:27] <mvo> rbasak: that might be a good compromise and less work, I think removing the hard dependency is slightly better though
[09:34] <rbasak> mvo: sorry, I didn't explain that well. That's not what I meant. I mean to remove the hard dependency *and* seed it as a recommend only.
[09:37] <mvo> rbasak: indeed, that makes a lot of sense
[09:49] <Odd_Bloke> So I've found a bug in python-colorama, which has no diff from Debian.  Upstream have kindly cut a new microrelease, which only contains bugfixes (including the fix for my bug, obvs :p).  If I find someone to upload the fixed version to Debian, presumably it can just be sync'd across?  Though presumably I still need an FFE?
[09:50] <juliank> Something seems broken with the APT translation import in launchpad. https://translations.launchpad.net/ubuntu/+source/apt lists the apt-all template shipped in the source package; and a lot of others. Now, apparently the importer tried to import some apt and apt-utils templates (don't ask me how), but those miss headers.
[09:51] <juliank> mvo: ^ Do you know how this stuff works?
[09:52] <mvo> juliank: I don't know much about it either, its all black magic to me :/ dpm or danilo probably do
[09:53] <juliank> OK, I wonder where it gets those split templates from
[09:54] <seb128> juliank, there are probably several .pot in the apt builddir?
[09:54] <seb128> or srcdir
[09:54] <juliank> There are somewhere in build/, yes
[09:55] <seb128> k, well if they are there then launchpad import them
[09:55] <seb128> why is that an issue?
[09:55] <juliank> Because they are only partial templates, they only contain msgid and msgstr, but no headers
[09:56] <juliank> the files are then merged into apt-all
[09:56] <seb128> it's fine
[09:56] <seb128> juliank, https://translations.launchpad.net/ubuntu/xenial/+source/apt/+imports?field.filter_status=all&field.filter_extension=pot
[09:56] <seb128> the apt-all has been imported
[09:56] <seb128> which is what matters no?
[09:58] <juliank> Hmm. The apt packages split apt-all translations later on to create individual apt, apt-utils, ... mo files. So I'd assume the split domain imports are the important ones, as apt does not use an apt-all domain
[09:58] <seb128> weird setup :-/
[09:59] <juliank> If so, we might not have noticed that in the past years, and APT never used langpack translations.
[09:59] <seb128> can you make those templates be valid and have headers then?
[10:00] <juliank> I don't know yet
[10:01] <cjwatson> apt basically can't use langpacks anyway
[10:01] <cjwatson> I mean, it's not just that it happens not to, but that its translations are needed before we get langpacks in place ...
[10:02] <juliank> cjwatson: then it's kind of silly to waste translator time with this at all, isn't it?
[10:02] <cjwatson> *shrug*
[10:03] <cjwatson> ah, no, its translations actually do end up in langpacks, they just can't be *stripped* from the apt packages
[10:03] <cjwatson> so I guess that means apt gets newer translations from langpacks if they're there, but it also ships its own for bootstrapping purposes
[10:03] <cjwatson> that would approximately make sense
[10:04] <juliank> mvo: Feel free to sync 1.2.6 now, BTW. This fixes comment typos and also takes care of the stack buffer overflow in the resolver.
[10:04] <juliank> cjwatson: yep
[10:05] <juliank> thanks to xnox for already having done the 1.2.5 sync
[10:05] <dpm> juliank, seb128, yeah, I don't have to add anything else that cjwatson hasn't already said. apt is a bit of a special case in that regard
[10:05] <juliank> mvo: oh, it's already there
[10:05] <xnox> Odd_Bloke, not really. depends on how cryptic the things are.... ping people, e.g. me, when there are things to sync =)
[10:06] <juliank> It's listed as latest upload; but not under the xenial section in https://launchpad.net/ubuntu/+source/apt
[10:06] <cjwatson> https://launchpad.net/ubuntu/+source/apt/+publishinghistory makes the state clearer
[10:06] <juliank> Yeah
[10:07] <juliank> I should complete my uploading thingy, so I can sync APT bugfixes myself
[10:07] <Odd_Bloke> xnox: Well, barry last uploaded python-colorama in Debian so I was going to ping him. ^_^
[10:08] <Odd_Bloke> barry: There's a new upstream version of python-colorama which has a bugfix (https://bugs.launchpad.net/ubuntu/+source/python-colorama/+bug/1554129) that I'd like for xenial; would you be able to upload and sync? :)
[10:08] <Odd_Bloke> It's, like, super critical because I can't autocomplete Python in vim any more, and it turns out I have the memory of a dead wombat. :p
[10:08] <xnox> Odd_Bloke, breaks jedi-vim -> sounds like a feature to me
[10:08] <Beret> mvo, rbasak - +1 - the hard dependency doesn't make sense
[10:08]  * xnox hides
[10:09] <juliank> uploading thingy = https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU2
[10:09] <juliank> (which was not supposed to have a 2 in it, but wiki did not let me create a page without the 2 IIRC)
[10:09] <juliank> It also needs severe updating.
[10:13] <mvo> juliank: yeah, I did sync it this morning
[10:47] <xnox> caribou, may i cherrypick sosreport patch into ubuntu upload?
[10:47] <xnox> and then you can trump it whenever?
[10:47] <caribou> xnox: sure
[10:49] <cpaelzer> apw - smb and I came to an interim solution, but still want to hear your input on the discussion we had this morning, so just let us know when you are around
[11:00] <cjwatson> pitti: https://bugs.launchpad.net/bugs/1554266 - neither openssh nor systemd apparently changed at the relevant time.  do you have any ideas even on what category of problem might be involved here?
[11:13] <LocutusOfBorg> please ignore virtualbox autopkgtest
[11:22] <pitti> cjwatson: the postinst looks okay to me; init-system-helpers changed, perhaps there's some subtle behaviour change there
[11:24] <Mirv> pitti: could you rerun the failed amd64 ubuntuone-credentials test from https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-050/excuses.html manually since it's one of these "does not have any test results" ones?
[11:26] <pitti> barry: done; but it failed on the other arches, so that won't unblock it
[11:26] <pitti> smoser: sorry, I'm sick, please email
[11:27] <pitti> smoser: ah, I have an email from you already
[11:28] <pitti> Mirv: poked
[11:30] <pitti> cjwatson: sorry, can't investigate today, still too sick
[11:31] <cjwatson> pitti: fair enough!  gws
[11:32] <pitti> cjwatson: https://launchpad.net/ubuntu/+source/init-system-helpers/1.29ubuntu1 landed on March 4th, so most probably that one
[11:33] <pitti> cjwatson: most of the changes are for OpenRC and thus a no-op for ubuntu; apparently update-rc.d works fine (as the service works after reboot), so maybe some weird fallout from invoke-rc.d
[11:33]  * cjwatson scribbles a note in the bug
[11:35] <Laney> apw: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1550741/comments/10 might interest you :-)
[12:03] <jamespage> cjwatson, need a second opinion on a net-tools merge I've managed to miss if you have a second
[12:03] <cjwatson> jamespage: I guess - what's up?
[12:04] <jamespage> cjwatson, so - there was a upload of a git snapshot into debian last year (1.60+git20150829.73cef8a)
[12:04] <jamespage> I've rebased all of the Ubuntu patches, and it works OK but the output of the tools is quite different..
[12:05] <jamespage> cjwatson, my gut feel is right now is not the right time to make that kind of change in xenial - what do you think?
[12:05] <cjwatson> hmm.  all other things being equal I'd prefer to have something vaguely resembling an upstream snapshot rather than 14yo orig + pile of patches, but I'd tend to agree now maybe isn't the best time to go finding new and exciting bugs in scripts that use net-tools
[12:07] <jamespage> cjwatson, for reference:
[12:07] <jamespage> http://paste.ubuntu.com/15327221/
[12:07] <jamespage> http://paste.ubuntu.com/15327223/
[12:07] <jamespage> first is new, second is current
[12:08]  * jamespage shudders about all of the sed/awk/grep -ing that will break...
[12:09] <Saviq> doko, hey, can you please have a look at bug #1552914, thanks!
[12:10] <tjaalton> pitti: hey, do you know why virtualbox is confused about the xserver version? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/v/virtualbox/20160306_082831@/log.gz
[12:12] <tjaalton> oh, some dependency not rebuilt against the new xserver then
[12:12] <pitti> tjaalton: I re-ran against all of -proposed for now, might just be some missing versioned dep
[12:13] <jamespage> rbasak, not sure if net-tools is on your list but raised:
[12:13] <jamespage> https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1554490
[12:13] <jamespage> not for this cycle...
[12:13] <tjaalton> pitti: ok thanks
[12:13] <cjwatson> jamespage: mm, quite.
[12:14] <tseliot> pitti: what's up with virtualbox? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/v/virtualbox/20160307_205918@/log.gz
[12:14] <rbasak> jamespage: thanks. Looks like it is on our list.
[12:15] <rbasak> (ie. ~ubuntu-server has a team subscription)
[12:15] <pitti> tseliot: see tjaalton's question from 3 minutes ago; retried with all of -proposed for now
[12:15] <pitti> if that still doesn't help, then there's some rebuild missing somewhere
[12:15]  * pitti crawls back into bed, sorry
[12:15] <tseliot> pitti: oh, sorry, I missed that
[12:15] <tjaalton> hehe, echo here too
[12:15] <tjaalton> pitti: ouch.. sorry for pinging
[12:16] <pitti> tjaalton: no worries, I answered :)
[12:16] <tseliot> tjaalton: ok, ok, I'll let you do all the speaking today :P
[12:16] <tjaalton> tseliot: :P
[12:17] <jamespage> rbasak, yes - it comes up under ubuntu-server...
[12:49] <ogra_> hmm, looks like the livefs builders do not produce any images for snappy anymore ... i only see manifest files
[12:50] <Odd_Bloke> caribou: Any news on https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/1544719?
[12:51] <caribou> Odd_Bloke: I wanted to ping smoser about it to see if he was planning on fixing it
[12:52] <caribou> smoser: ^^
[12:52] <caribou> Odd_Bloke: other than that I don't mind fixing ig, just got bitten by it again today
[13:06] <LocutusOfBorg> doko, could you please wait next time for llvm-toolchain-3.8?
[13:06] <LocutusOfBorg> ginggs, ^^
[13:07] <LocutusOfBorg> I don't agree with your upload
[13:09] <LocutusOfBorg> you forget to mention the breaks+replaces in changelog, the dh_strip hack is not needed anymore (done in dh_install already), and I don't think disabling lldb on s390x is needed
[13:09] <LocutusOfBorg> do you have any information about it?
[13:10] <LocutusOfBorg> oh loool, you didn't disable it, Debian disabled it :) so just changelog needs to be dropped on that point
[13:11] <cjwatson> ogra_: link?
[13:11] <LocutusOfBorg> anyhow, maybe you can sponsor this package as ubuntu2 https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/6183347/+listing-archive-extra
[13:11] <cjwatson> ogra_: note that binary files are garbage-collected after a day or so
[13:11] <ogra_> cjwatson, yeah, seems it was some browser weirdness, now i see them
[13:15] <LocutusOfBorg> BTW thanks for your work :)
[13:20] <ogra_> cjwatson, mind taking a look at http://paste.ubuntu.com/15327524/ ? i want to have the livefs build spit out an os-snap with that (i'm specifically unsure about line 41, but dont really want to make snappy a dependency of livecd-rootfs)
[13:22] <kirkland> mvo: seb128: hey guys -- could you make unattended-upgrades a "recommends" in software-properties, rather than a depends?
[13:23] <kirkland> mvo: seb128: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/831487
[13:23] <seb128> kirkland, hey, mvo and rbasak discussed it earlier, see backlog from ~4hours ago
[13:23]  * kirkland scrolls up
[13:24] <kirkland> seb128: excellent, thanks.
[13:24] <seb128> yw
[13:24] <ricotz> hi, this could probably use some more attention https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/1493999
[13:25] <seb128> unsure if somebody agreed on doing the changes though
[13:25] <ricotz> doko, hi, this aptitude merge should be stable https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6180753/+listing-archive-extra
[13:25] <rbasak> That's a good point. mvo, are you taking on the work?
[13:26] <cjwatson> ogra_: don't cd, you don't really need to here and it's implicit state that will confuse somebody.  I don't remember whether you can apt-get install there; try it with a livecd-rootfs in a PPA and see if it works.  The important thing for adding new artifacts is that they need to be copied/moved/linked to something beginning with "$PREFIX."
[13:26] <cjwatson> ogra_: also consistent indentation would be nice
[13:27] <cjwatson> (bottom three commands inside the inner if/fi block are misindented)
[13:27] <ogra_> oh
[13:29] <ogra_> hmm, the $PREFIX thing might be a bit of a problem since snappy checks the filename against the metat data at install time, so the filename needs to end up without $PREFIX again
[13:30] <cjwatson> ogra_: you're entirely free to rename it again in whatever code downloads the built artifacts from Launchpad
[13:30] <ogra_> yeah
[13:38] <kirkland> seb128: I attached a patch at https://launchpadlibrarian.net/247135751/831487.patch
[13:38] <kirkland> seb128: can I go ahead and upload that?
[13:38] <kirkland> seb128: or are you guys working on a different solution?
[13:45] <flexiondotorg> xnox, smoser, tjaalton Hi pilots - I'd really appreciate it if you can look at my sponsoring requests during your stints today :-)
[13:46] <seb128> kirkland, it's not as simple I think, as discussed between mvo and rbasak earlier, if it's demoted from depends then the code needs to deal with the case where it's not installed (which it doesn't atm)
[13:47] <seb128> kirkland, like the combo should let you pick auto update if the service is not there
[13:47] <seb128> kirkland, sorry, "should *not*"
[13:47] <kirkland> seb128: oh, interesting.
[13:47] <kirkland> seb128: is someone actually working that, then?
[13:48] <seb128> kirkland, that's what I asked earlier, but I don't think so no
[13:51] <mterry> cyphermox, didrocks: do either of you have time for some python MIRs?
[13:53] <kirkland> seb128: okay thanks;  mvo, rbasak: can you please comment in the bug, with anything else that needs to be done, above and beyond the simple depends->recommends change?
[13:57] <didrocks> mterry: unfortunately, not at all :/ I don't have enough time to finish what I need to do already :(
[14:05] <rbasak> kirkland: done
[14:08] <cyphermox> mterry: assign me stuff, I'll make the time
[14:19] <smoser> caribou, i have no plan on fixing squid-deb-proxy, but i think that -proposed should have a fix from rbasak
[14:19] <smoser> bug https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691
[14:19] <caribou> smoser: true, he's merging the newest
[14:19] <caribou> Odd_Bloke: ^^
[14:19] <caribou> smoser: thanks!
[14:20] <smoser> Odd_Bloke, caribou you can and should test -proposed
[14:20] <smoser> enable proposed, see if it works for you
[14:20] <caribou> smoser: ok, I will
[14:20] <smoser> if not, please respond on that bug
[14:22] <barry> Odd_Bloke: yep, i'll look at it
[14:22] <barry> pitti: no worries, we have a new version i'm about to sync
[14:23] <Odd_Bloke> barry: Thanks!
[14:39] <tjaalton> how frequently should "valid candidates" be moved to main from excuses list?
[14:41] <juliank> Where should bug #1553870 be reassigned? Apparently upgrading a trusty system from the xenial live did not write correct sources.list
[14:49] <Odd_Bloke> rbasak: smoser: I hit a problem when upgrading to the -proposed squid; I've added a comment to bug 1473691 with details. :)
[14:50] <juliank> Alberto Salvia Novella is a pain in the ass.
[14:51] <juliank> *Every* bug I see him doing something, the importance is extremely wrong; he closed the bug in the wrong package; or did other crazy stuff.
[14:52] <juliank> It is completely unbelievable to me why he is in ubuntu bug control.
[14:53] <smoser> rbasak, please see Odd_Bloke 's comment in said bug
[14:55] <cyphermox> juliank: ubuntu-release-upgrader?
[14:57] <mdeslaur> pitti: I'm stealing your bsh merge
[15:02] <juliank> cyphermox: thx
[15:31] <rbasak> kirkland: I don't know who will fix the GUI. I asked mvo above but I guess he's not around.
[15:32] <mvo> rbasak: ups, sorry, I must have missed that. I could fix it (i.e. I know this code) but I'm super busy with stuff, would be better if someone from the desktop team could have a look, probably really easy
[15:37] <seb128> rbasak, mvo, I can have a look I guess
[15:38] <LocutusOfBorg> can anybody ruby-savvy look at gitlab migration? some dependencies don't build cleanly, e.g. ruby-sentry-raven
[15:38] <LocutusOfBorg> but I fail to understand why
[15:40] <mvo> seb128: its hopefully as simple as "if not os.path.exists("/usr/bin/unattended-upgrade"): combobox.remove(security_option)"
[15:40] <seb128> mvo, yeah, I looked around that code yesterday for the autodownload thing, so I think I know what to do
[15:40] <mvo> great
[15:40] <mvo> thanks a bunch seb128
[15:40] <seb128> yw!
[16:17] <hallyn> pitti: mvo: is there a way to tell adt to update a kvm image?  or do i need to run it by hand and update?
[16:41] <Odd_Bloke> arges: I believe you're on the hook for migration of cloud-init in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1551419; I've performed validation and it's good to go. :)
[16:44] <arges> Odd_Bloke: looking
[16:44] <Odd_Bloke> arges: Thanks. :)
[16:57] <arges> Odd_Bloke: so cloud-init has only been in proposed for 4 days, is the main conern ensuring this gets in before the kernel update?
[16:57] <Saviq> slangasek, hey, can you make sure someone has a look at bug #1552914
[16:57] <Saviq> slangasek, +please, thanks!
[17:00] <Odd_Bloke> arges: That's the primary concern, yes.
[17:01] <smoser> so why do i not see journal entries for all jobs that ran ?
[17:21] <rharper> rbasak: nacc:  I'm doing another git merge reconstruct;  the first ubuntu delta has changes to package debs in debian/control as well as the maintainer change;  should I attempt to break those out into separate changes (so one can commit just the maintainer change as a single commit) ?
[17:24] <nacc> rharper: right, the maintainer change should be in its own meta
[17:24] <nacc> and it's only present in reconstruct/
[17:24] <rharper> ok
[17:24] <nacc> it gets dropped for logical/
[17:24] <rharper> yeah
[17:24] <nacc> so it's best to have it separate
[17:24] <nacc> iirc, it's always in that first delta, and then propogated from there. I think there's a bit in the wiki that mentions that
[17:25] <nacc> rharper: but the goal should be one logical (bad choice of words) change in each commit ... ideally relative to the changelog entries themselves, followed by a changelog commit and a meta commit
[17:25] <rharper> yep; it is
[17:26] <rharper> it just wasnt' clear from the text if one should explicitly modify control changes into two commits (maintainer, <other changes logged in changelog> )
[17:28] <doko> LocutusOfBorg, no
[17:28] <LocutusOfBorg> doko, no <-- context? :p
[17:28] <nacc> rharper: that's what i've always done, at least :)
[17:29] <doko> Saviq, next week; please ask xnox if it needs to be done earlier
[17:30] <doko> Saviq, xnox: maybe just drop that compiler dependency
[17:31] <Saviq> doko, ack, thanks
[17:31] <xnox> doko, i think so.
[17:46] <rbasak> nacc: I think logical is exactly the right choice of words. That's why I call that branch "logical" :)
[18:23] <rbasak> infinity: around?
[18:23] <rbasak> (about that Juju discussion)
[18:31] <mterry> cyphermox,  thanks for the MIR help!
[18:32] <cyphermox> mterry: no worries
[18:55] <dobey> does xorg in xenial not do randr 1.5?
[19:01] <nacc> dobey: it would appear to be 1.4, based upon xrandr's output, but libxrandr2 is at 1.5.0-1?
[19:02] <seb128> dobey, that's a question for tjaalton but I would guess it does because we had to patch gtk to handle randr 1.5
[19:03] <tjaalton> dobey: xserver 1.18 just went in, it does 1.5
[19:05] <dobey> i just took the daily image and booted it, and xrandr was saying the server only does 1.4
[19:05] <dobey> on haswell i7
[19:05] <tjaalton> the image is too old
[19:05] <dobey> oh
[19:06] <tjaalton> I'm talking it went in like 2h ago :)
[19:06] <dobey> tomorrow should be good?
[19:06] <tjaalton> yeah
[19:06] <dobey> ah
[19:06] <dobey> ok, i'll try again tomorrow
[19:06] <tjaalton> hmm I'll sync x11-xserver-utils too so that xrandr can do 1.5
[19:07] <dobey> because it's my understanding that i need 1.5 to get 60Hz 4K correctly with MST
[19:07] <tjaalton> oh we have latest x11-xserver-utils already
[19:07] <tjaalton> probably so
[19:07] <tjaalton> i've never seen one
[19:08] <dobey> well i know currently i just get two 1920x2160 screens that are ordered incorrectly by default, when i try to use MST
[19:08] <dobey> on trusty with lts-wily kernel/xorg
[19:10] <tjaalton> yep
[19:12] <nacc> tjaalton: while you're around, i hit bug # 1500751 on my laptop at home over the weekend after updating to xenial; I had been running mainline (which did work) and had to use you workaround from c54 to be able to type my password into the cryptfs prompt at bootup with the stock kernels. I didn't see xenial mentioned specifically in that bug, though
[19:13] <tjaalton> nacc: should be fixed now?
[19:14] <nacc> tjaalton: hrm, i can try removing the workaround again ... "now" relative to when? I did the dist-upgrade over this past weekend
[19:15] <tjaalton> nacc: well the bug apparently got fixed on sunday
[19:15] <nacc> tjaalton: ah :) ... i'll try w/o the workaround then
[19:16] <nacc> tjaalton: thanks, didn't see the update to the bug, my fault
[19:17] <tjaalton> nw
[19:56] <slangasek> nacc: right, so fixing gosa for php-imagick means it's now uninstallable when updating php7.0, due to the drops of php-mcrypt and php-imap, both of which it depends on
[19:56] <slangasek> nacc: so that's critical path now :)
[19:56] <nacc> slangasek: yep, i sent an e-mail last night about it?
[19:57] <nacc> slangasek: but yeah, i'd like to get that fixed asap, i'm  happy to try my approach, but didn't want to do something that doesn't make sense
[20:01] <nacc> slangasek: i'm not even sure my suggestion is very good, but it seems like a way forward where the sources *should* be easy to keep in sync
[20:02] <nacc> slangasek: is it feasible to just have two src packages that are identical, one living in univers and one living in main? i know that's quite ugly, but if they had different control files, they'd generate their respective binaries correctly, and would stay in sync that way too (that's basically what i'm suggesting, except i'd pare down the universe one and make it depend on a binary pkg from the main
[20:02] <nacc> one)
[20:22] <xnox> nacc, see boost1.54 and boost-mpi-source1.54 for example.
[20:23] <nacc> xnox: thanks, will look!
[20:34] <nacc> Pharaoh_Atem: ping
[20:34] <Pharaoh_Atem> nacc: pong
[20:35] <nacc> Pharaoh_Atem: can you check something for me, i think php7.0-dev has a bad symlink, specifically for /usr/lib/php/20151012/build/ltmain.sh
[20:35] <nacc> Pharaoh_Atem: it seems relevant to LP#359062
[20:35] <nacc> err, LP #359062
[20:36] <nacc> i wonder if the same change got dropped in php7
[20:47] <nacc> slangasek: fyi, looks like we're missing at least one more imagmageick backport ofr this test -- when i skipped the version checks, it fails on amd64 :) ... bisecting now
[20:49] <Pharaoh_Atem> nacc: looks good here
[20:49] <nacc> Pharaoh_Atem: oh, i wonder
[20:49] <nacc> Pharaoh_Atem: ok, try install php5-dev as well (just to test)
[20:49] <Pharaoh_Atem> it seems to properly reference /usr/share/libtool/build-aux/ltmain.sh
[20:49] <nacc> Pharaoh_Atem: i wonder if the two packages conflict (which is fine for now)
[20:53] <nacc> xnox: ok, those do seem like a good example to base off of! on first glance, they share an orig.tar.gz (with altered naming) and simply have different debian.tar.gz?
[21:02] <xnox> nacc, and there is magic in debian/rules to generate the other one, based on the change of the name in the changelog.
[21:03] <nacc> xnox: ah very cool ... ok, i'll d/l them and take a look
[21:03] <nacc> xnox: really appreciate it!
[21:21] <slangasek> nacc: having two source packages - it's feasible, there are certainly other examples of it in the archive; it's also annoying, but until we finalize the build-deps-in-universe change it's unavoidable
[21:22] <nacc> slangasek: yep, but it seems better than doing what was done with php5 and having (potentially) 4 separate src packages that have to be kept in sync (or so it seems to me)
[21:22] <slangasek> nacc: sure
[21:23] <nacc> slangasek: but you're the long term bd-in-universe is the "right" solution
[21:23] <nacc> slangasek: i'll work on getting something to you by EOD
[21:25] <kgunn> stgraber: you about? i feel like i'm missing something...
[21:25] <kgunn> https://pastebin.canonical.com/151393/
[21:25] <kgunn> i've got a local container, just trying to grab a file off of it...
[21:26] <stgraber> kgunn: is the path correct?
[21:27] <stgraber> kgunn: looks like we return this very confusing error when the path doesn't exist
[21:27] <kgunn> double checking...
[21:27] <kgunn> hmmm...i could pull hosts like the example
[21:27] <kgunn> stgraber: permissions?
[21:27] <kgunn> maybe
[21:28] <stgraber> it's done as root, so unlikely
[21:28] <stgraber> kgunn: lxc exec xen -- ls -lh /home/ubuntu/mir-server-snap/mir-client_0.21_amd64.snap
[21:28] <kgunn> :) right was just doing
[21:29] <kgunn> sort of
[21:31] <kgunn> stgraber: well i feel sorry for disturbing you....i think it was perms on my host side
[21:31] <kgunn> copied fine using .
[21:31] <kgunn> into my working dir
[21:31] <stgraber> ah, interesting
[21:32] <stgraber> anyway, our error reporting for file pull/push really sucks... there are reasons for it sucking but we should try harder :)
[21:32] <stgraber> (basically we need to fork a tiny C program into the container and then send stuff through fds so the Go daemon isn't the one actually getting the errors)
[21:32] <kgunn> well thanks...
[21:32] <kgunn> sorry for pestering
[21:41] <matv1> can someone please confirm that I can just use relative paths for an image file inside a strictly qml/js (using qmake) app?
[21:42] <matv1> or do I have to use recources system?
[21:42] <matv1> it seems the most trivial of things but its about to do my head in :(
[21:50] <dobey> matv1: you probably need full path URIs for file:///
[21:50] <dobey> matv1: also, seems like a question for #ubuntu-app-devel
[21:51] <matv1> ah sorry I seem to be in trouble with my locations in more ways then one :)
[21:53] <matv1> dobey thanks I will try it
[22:32] <nacc> Pharaoh_Atem: i think it's a php bug now ... cf my (just posted) update to the pcre bug
[22:32] <nacc> Pharaoh_Atem: the twig failures
[22:39] <Pharaoh_Atem> nacc: yeah, I saw
[22:39] <Pharaoh_Atem> but have you updated the php bug with your conclusions?
[22:39] <Pharaoh_Atem> or are we just going to kill pcre jit for php7?
[22:48] <nacc> Pharaoh_Atem: just did
[22:48] <bdmurray> cyphermox: any ideas about bug 1553870?
[23:19] <nacc> slangasek: fyi, i've got a fixed version of fusiondirectory that does update the path (and a ton of string references :/) to php7 naming. Building it now and will send an updated debdiff in the same bug