=== ming is now known as Guest70374
=== anthonyf is now known as Guest78303
[04:43] <pitti> Good morning
[04:43] <pitti> LocutusOfBorg1: please go ahead
[04:48] <alkisg> tjaalton: good morning, may I ping you to put the SRU'ed x11-utils (LP: #1463663) to precise-updates? I've done the verification-done step. Thank you.
[04:48] <ubottu> Launchpad bug 1463663 in x11-utils (Ubuntu) "[SRU] Enable setting property of type UTF8_STRING" [Medium,In progress] https://launchpad.net/bugs/1463663
[05:08] <pitti> infinity: nice alpha-1 quote :)
[05:29] <infinity> pitti: Wilde should be an inspiration to us all.
[05:30] <pitti> infinity: I always pass good advice. It is the only thing to do with it. It is never of any use to oneself.
[05:59] <tjaalton> alkisg: well, there's a rule not to ack pkgs to updates on friday.. :)
[05:59] <alkisg> Guys, it's getting really hard to do an SRU when one has to spend 8 hours on it
[05:59] <alkisg> And ping 4 persons
[06:00]  * alkisg will just put that in the greek schools PPA and ignore all other LTSP users out there... :-/
[06:03] <tjaalton> has it been 10 days in proposed
[06:03] <tjaalton> ?
[06:03] <alkisg> No, I don't think so, I haven't seen that requirement in the SRU wiki
[06:04] <alkisg> Ah, it's mentioned in the other page, https://wiki.ubuntu.com/StableReleaseUpdates, about 7 days
[06:04] <tjaalton> or was it seven
[06:05] <tjaalton> right
[06:05] <tjaalton> dunno where i got ten
[06:05] <alkisg> tjaalton, could you please tell me when do I need to ping devs?
[06:05] <alkisg> For getting the SRU approved, I've seen that if I don't ping anyone, it never gets approved,
[06:05] <alkisg> is it also needed for the move to -updates?
[06:06] <tjaalton> yes
[06:06] <tjaalton> two manual steps
[06:06] <alkisg> OK, thanks a lot, I'll do that after 4-5 days then. :)
[06:07] <tjaalton> i've been on holidays past three fridays, but not today
[06:08] <alkisg> We've spoken last friday when I was trying to get the SRU accepted :)
[06:08] <tjaalton> so will process the upload queue if nothing else
[06:08] <tjaalton> and it was midsummer here then
[06:08] <tjaalton> public holiday
[06:08] <alkisg> infinity did accept it 3 days ago
[06:08] <tjaalton> nice
[06:09] <alkisg> tjaalton: no problem at all, it appears that I didn't know the procedure well enough, that 2 pings are necessary, with 7 days interval...
[06:09] <alkisg> Thanks again
[06:10] <tjaalton> sure, no prob
[06:23] <RAOF> alkisg: I *generally* migrate all the things which are valid candidates on http://people.canonical.com/~ubuntu-archive/pending-sru.html at the beginning of my Tues SRU block.
[06:23] <RAOF> alkisg: That's for the -proposed → -updates transition.
[06:24] <RAOF> alkisg: Something is a valid candidate if it's (a) >= 7 days old (or less, if you make a compelling case for its urgency and safety), (b) all the bugs associated with it are green (ie: in validation-done state), and (c) there are no jenkins failures associated with it.
[06:25] <alkisg> RAOF, what about the "getting it to -proposed" part?
[06:25] <RAOF> alkisg: That's the bit that it's good to ping for :)
[06:25] <alkisg> Would I e.g. ping you for that, or let it stay there and rely that you'll process it when you have time for it?
[06:25] <alkisg> Good to know, thank you :)
[06:26] <RAOF> alkisg: Well, both. If there's something urgent it's nice to be pinged so I can prioritise.
[06:26] <alkisg> No urgency here, I just didn't want it to remain there forgotten... it can wait until next Tue :)
[06:27] <RAOF> But if it's not especially urgent you can just upload and we'll get to it eventually (how long varies depending on how many hours SRU members have been spending on the queue recently)
[06:27] <RAOF> I *like* to keep the queues < 2 weeks, but we've not been keeping up with that recently.
[06:27] <RAOF> (Partially because I've been missing some of my SRU days, as have others)
[06:28] <alkisg> I don't think I have upload rights, so that's an additional ping for me there... fortunately the #ubuntu-x folks did that
[07:00] <dholbach> good morning
[07:04] <pitti> stgraber: hm, lxc-net started failing on wily, although lxc itself didn't change; but yesterday we got a new dnsmasq, might that be it?
[07:18] <LocutusOfBorg1> pitti, the merge is ready on sponsors-queue :)
=== Malsasa_ is now known as Malsasa
[07:49] <pitti> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
[08:05] <pitti> seb128: is https://code.launchpad.net/~mir-team/gtk/mir-release-0.14.0/+merge/263034 something you'd like to handle in the desktop team, or should I sponsor it?
[08:09] <seb128> pitti, hey, we can handle it but feel free to do it if you want ... did they roll the mir update our yet?
[08:09] <seb128> Laney, ^
[08:09] <pitti> seb128: oh right, we still have 0.13.3, so nevermind
[08:09] <seb128> pitti, piloting? ;-)
[08:09] <pitti> seb128: yes
[08:10] <seb128> pitti, enjoy! and happy friday ;-)
[08:10] <pitti> seb128: and to you!
[08:10] <Laney> pitti: attente should probably merge that upstream
[08:10] <Laney> and hi too
[08:12] <pitti> hey Laney, how are you?
[08:12] <Laney> great!
[08:12] <Laney> I'm trying to find out how to access Dell tech support ;-)
[08:14] <pitti> Laney: urgh, your laptop broke?
[08:15] <Laney> nah, I just  got asked to file an issue about this space key repeating bug
[08:16] <Laney>               ↑ that one
[08:16] <Laney> bah, missed!
[08:19] <ogra_> blame the space key (for moving the arrow to far)
[08:20] <Laney> that is true, I was trying to count the right number of spaces to insert :)
[08:53] <jamespage> pitti, hey - did you just sponsor an oslo.messaging SRU for trusty?
[08:53] <pitti> jamespage: yes, I did
[08:53] <jamespage> pitti, its stacked alongside one already in the -proposed unapproved queue
[08:53] <pitti> I checked that the fix is in wily already and updated the bug
[08:54] <pitti> jamespage: oh, argh; I'll reject mine then; I already unsub'ed sponsors
[08:54] <pitti> whoever uploaded that, pretty please mentino this on the bug!
[08:54] <jamespage> pitti, np - just noticed it in -release and checked
[08:54] <jamespage> pitti, its not the same bug
[08:54] <pitti> jamespage: oh, it's something else
[08:54] <jamespage> pitti, https://bugs.launchpad.net/oslo.messaging/+bug/1448650
[08:54] <ubottu> Ubuntu bug 1448650 in oslo.messaging (Ubuntu Vivid) "rpc.server do not consume messages after message acknowledge failure" [High,New]
[08:54] <pitti> jamespage: ack, I'll ask Jorge to merge
[08:55] <jamespage> pitti, +1
[08:56] <pitti> jamespage: done
=== vrruiz_ is now known as rvr
[09:10] <TJ-> I'm unclear whether this requires an SRU or a Backport request, could someone advise? bug #1468938
[09:10] <ubottu> bug 1468938 in miniupnpd (Ubuntu) "postinst script writes garbage to /etc/default/miniupnpd" [High,Triaged] https://launchpad.net/bugs/1468938
[09:20] <rbasak> TJ-: an SRU would be suitable for that I think.
[09:20] <rbasak> TJ-: it's a direct maintainer script bug, no question.
[09:20] <rbasak> TJ-: task for Trusty approved.
[09:21] <TJ-> rbasak: Thanks, I thought so and have proceeded so far on that basis but the SRU Wiki  guidance made me wonder.
[09:21] <pitti> yes, destroying config files is absolutely a bug/SRU matter
[09:21] <TJ-> rbasak: Do I simply subscribe the SRU team to this? I have no upload rights
[09:22] <rbasak> TJ-: follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure step by step. It accomodates users with no upload rights - attach debdiffs to the bug at the appropriate step, and then subscribe ~ubuntu-sponsors to the bug.
[09:23] <rbasak> TJ-: if it also needs fixing in the development release, then you can just attach two debdiffs and ask for sponsorship for both at the same time.
[09:23] <rbasak> The documented procedure is unclear about this :(
[09:23] <TJ-> rbasak: Thats what I've been doing ... but I'm not sure a debdiff is appropriate since in this case it needs a backport
[09:23] <rbasak> TJ-: why does it need a backport?
[09:23] <TJ-> rbasak: The fix has been in from 14.10 onwards
[09:24] <rbasak> TJ-: "The fix has been in from 14.10 onwards" OK so comment to that effect in the bug and mark the main task Fix Released.
[09:25] <rbasak> TJ-: then mark the Trusty task Triaged if you feel appropriate.
[09:25] <TJ-> rbasak: Yes, I've already marked it Triaged and in the Description it says "It turns out these were fixed in Debian and are available in 14.10, 15.04 and 15.10. A backport to Trusty would solve this and several other issues."
[09:25] <TJ-> rbasak: This is why I'm sure what to do at this point ... simply subscribe the SRU team, or what?
[09:26] <rbasak> TJ-: an SRU is appropriate here, but how the SRU should work is still an open question. Why a backport, over cherry-pick of the fix or the patch you attached?
[09:26] <TJ-> rbasak: Well, mainly that the updated package contains "Fixes multiple vulnerabilities (Closes: #772644)."
[09:27] <rbasak> TJ-: to be clear, an SRU for *this particular issue* is appropriate here. "Several other issues" is far too vague to SRU.
[09:27] <rbasak> TJ-: OK, so if we want to fix those in the SRU as well, then they need to be documented for the SRU team to review in a bug somewhere.
[09:28] <TJ-> rbasak: OK ... I'll dig a little more
[09:28] <rbasak> TJ-: they look pretty well documented in the Debian bug actually.
[09:29] <rbasak> TJ-: if that's the complete set of patches applied, they just need documenting for the SRU team and would be suitable I think.
[09:29] <rbasak> TJ-: also, as they look to be security related, you could probably get all of these fixes through the security update process instead.
[09:29] <TJ-> rbasak: Yes, the security issues look like we should have them in an LTS for sure
[09:30] <TJ-> rbasak: Right ... so.... prefer a Security update over SRU to get all the fixes in?
[09:30] <rbasak> I would ask the security team. I think they'd be OK with fixing the postinst at the same time as the bundle of security fixes.
[09:30] <rbasak> As long as you can give them a debdiff to upload
[09:30] <rbasak> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[09:31] <rbasak> Hmm. Although some of the fixes aren't security fixes.
[09:31] <rbasak> See what they say, anyway.
[09:33] <TJ-> The postinst is arguably a Denial of Service :)
[09:34] <TJ-> rbasak: Thanks alot; I'm writing up the description then I'll ask the security team to look at it
[09:42] <rbasak> TJ-: no problem. The main thing to do is to create the actual thing you want sponsored (ie. source packages - debdiffs are the easiest way to get these to sponsors)
[09:48] <TJ-> rbasak: I usually do those or bzr branches depending on where the source lives, but the potential of a  backport to solve it doesn't make the procedure clear in the guidelines
[09:49] <rbasak> TJ-: "If all of the changes are appropriate for an SRU by the criteria above, then it is acceptable (and usually easier) to just upload the complete new upstream microrelease instead of backporting the individual patches."
[09:49] <rbasak> TJ-: from a policy perspective, there is no difference. A backport is fine provided that all the criteria are met for each part of the diff.
[09:51] <rbasak> TJ-: but that immediately disqualifies the backport if any change appears (between the current release version and the proposed backport version) that does not meet the appropriate (SRU or security) criteria.
[09:51] <rbasak> (unless the package has an exception; I don't believe this package does)
[09:53] <TJ-> rbasak: OK, my misuse of terms.... by backport I was meaning if the source package to be used to fix the issue is exactly what is in a later release, should a copy of that later release be added as a debdiff or should someone with upload rights be able to directly import the package from the fixed release
[09:55] <rbasak> TJ-: the debian/changelog file will still need manipulating to add a changelog entry and use a suitable version number for the SRU.
[09:56] <rbasak> TJ-: for sponsorship I would still provide a debdiff, but perhaps against the release you're backporting instead. Then the only thing in the debdiff would be the debian/changelog change, but that's still useful to sponsors to understand exactly what you want.
[09:57] <rbasak> TJ-: of course if you provide such a debdiff you'd probably want to make it clear which release and version your debdiff was generated against (though that could be inferred from the debian/changelog change)
[09:57] <rbasak> TJ-: does that help?
[09:58] <rbasak> TJ-: I guess the reason this isn't really documented is that in general sponsors don't particularly care _how_ you provide the changes that you want.
[10:02] <TJ-> rbasak: Yes, and I guess those familiar with the processes do them instinctively whilst those of us outside the process just go round in circles on the Wiki guides :)
[10:02] <rbasak> TJ-: I wish it were simpler :-/
[10:03] <TJ-> rbasak: I'm going to write it up as best I can and ask the security team to look at it; the Debian updates don't identify the CVEs they fix and it looks like there may be an additional CVE not covered too :)
[10:04] <rbasak> TJ-: thank you for your efforts!
[10:32] <TJ-> Is there up-to-date documentation somewhere on what tools and procedures are used to create the bootable hybrid ISO images? I'm working on a universal GRUB2-bootable image that'll work on x86/amd64, BIOS and UEFI, with raw block and ISO9660/El Torito, supporting multiple sector sizes (512/2048/4096) and want to design it to work with the current tooling
=== alkisg is now known as work_alkisg
[11:29]  * mdeslaur hugs rbasak for fixing indefinite grub timeout
=== pete-woods1 is now known as pete-woods
[11:51] <tjaalton> pitti: hey, can I persuade you to review xserver-xorg-video-intel for utopic (and matching -lts-utopic for trusty) from the sru queue?
=== MacSlow is now known as MacSlow|lunch
[11:57] <attente> Laney: we already have a similar patch upstream: https://git.gnome.org/browse/gtk+/commit/?id=9800d83a721fd21b34df6dd36684d3e0e2a9fd7b
[11:57] <Laney> attente: want to tell the MP / $person_who_filed_it?
[11:58] <pitti> tjaalton: I haven't been in the SRU team for a few years, but I can have a look
[11:59] <tjaalton> pitti: right, I know but you're on pilot duty today so figured I'd ask :)
[12:00] <tjaalton> my sru duty is on fridays, and noticed that this upload was still missing because of a previous sru taking a long time..
[12:00] <tjaalton> already acked grub2 and libvirt :)
[12:01] <pitti> tjaalton: are these fixed in wily?
[12:01] <tjaalton> and vivid, which have 2.99.917
[12:01]  * pitti adds an x-v-i task to bug 1443345
[12:01] <ubottu> bug 1443345 in HWE Next "[Dell Insprion 3646] Double cursor appeared when rotating the display back to normal [8086:0f31]" [Critical,In progress] https://launchpad.net/bugs/1443345
[12:02] <tjaalton> hmm didn't check that one
[12:02] <tjaalton> I'll fix that bug
[12:02] <pitti> I updated the tasks
[12:03] <tjaalton> ah, thanks
[12:03] <pitti> tjaalton: yes, it's fixed, just checked
[12:09] <pitti> tjaalton: done
[12:09] <tjaalton> pitti: much appreciated, thanks
[12:33] <rbasak> infinity: any chance of SRU review for docker.io please?
[12:38] <pitti> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== MacSlow|lunch is now known as MacSlow
[12:49]  * dholbach hugs pitti
[12:49]  * pitti hugs dholbach :)
[12:49] <beuno> hey hey. Stop that.
[12:52]  * ogra_ hugs beuno, dholbach and pitti 
[12:52] <pitti> group hug!
[12:52] <ogra_> !
[12:52]  * pitti hugs beuno and ogra_
[12:52]  * dholbach hugs you all
[12:52] <dholbach> can you tell it's Friday? :)
[12:53]  * beuno relents and sinks into the hug
[12:54] <TJ-> I hope everyone's showered!
[12:59] <pitti> TJ-: sure! once for Easter, once for christmas :)
[13:00] <ogra_> and we hug on fridays to keep some memory of each other over the weekend :)
[13:01]  * TJ- grins... I only said that since I suddenly realise I've not showered in a few days ... its a farmer thing I'm afraid :)
=== _salem is now known as salem_
=== salem_ is now known as _salem
[14:36] <hallyn_> pitti: hey - does a systemd service saying it "Wants" another service mean tha tit will wait until the other service starts, or finishes?
[14:48] <hallyn_> mbiebl: hey, ^ do you know the answer? :)  the jobs are both Type=oneshot
[14:59] <Laney> hallyn_: Don't you need Before= or After= for that?
[15:09] <hallyn_> Laney: dunno, that's why i'm asking.  right now lxc.service has Wants=lxc-net, and users are reporting races;  if it needs to be After that's a trivial fix, but i want to make sure it makes sense
[15:12] <Laney> hallyn_: Wants= without any ordering relation means they start up at the same time, let me find the reference
[15:12] <hallyn_> Laney: makes sense i guess
[15:13] <Laney> hallyn_: http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires= (same for Wants=)
[15:15] <hallyn_> thanks Laney
[15:25] <hallyn_> Laney: hm, from that it's still not clear to me that 'After=' really is equivalent to upstart's "start on stopped B"
[15:25] <hallyn_> oh,
[15:26] <hallyn_> so lxc-net.service should really do a ExecPreStart or something
=== Malsasa_ is now known as Malsasa
=== seb128_ is now known as seb128
=== dpm is now known as dpm-afk
=== pgraner is now known as pgraner-afk
[16:33] <tr3y> Hello, I'm having trouble with Nautilus and Nemo on Ubuntu 14.04. The Ubuntu channel told me I might have success asking here. I changed the .desktop files to execute these programs with "Exec=gksudo -k -u root nautilus" (and 'nemo' for nemo) and now when they open, there's no top menu (E.G "Edit", "View", etc). Anyone know what's causing this?
=== dpm-afk is now known as dpm
[19:37] <arges> cyphermox: hey are you merging multipath tools, niedbalski has a fix for it and I want to make sure his patch makes it in
[19:37] <arges> cyphermox: bug 1469143 fwiw
[19:37] <ubottu> bug 1469143 in multipath-tools (Ubuntu) "kpartx -d fails with image paths longer than 63 characters" [Undecided,In progress] https://launchpad.net/bugs/1469143
[19:37] <cyphermox> arges: yeah, I'm still working on merging multipath-tools
[19:37] <cyphermox> I have a few things to fix before it will work in the installer.
[19:38] <cyphermox> (including that extra module for multipath-modules) :)
[19:39] <arges> niedbalski: that ok to wait until cyphermox merges 0.5.0 then push your fix (unless its already in that release)
[19:39] <niedbalski> arges, sure, I can wait for 0.5.0 and put the patch on top of it.
[19:39] <arges> cool
[19:40] <niedbalski> cyphermox, arges there is any bug tracking the 0.5.0 merge?
[19:40] <cyphermox> niedbalski: won't that patch blow up if there is a collision in path names?
[19:41] <cyphermox> niedbalski: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1455482
[19:41] <ubottu> Ubuntu bug 1455482 in multipath-tools (Ubuntu) "Multipath: upgrade multipath-tools to upstream" [High,In progress]
[19:44] <niedbalski> cyphermox, thanks
[19:45] <niedbalski> cyphermox, I didn't get your first question