[01:58] <hallyn> kees: hey - are you up for a ptrace question? :-)
[01:58] <hallyn> kees: I'm wondering whether it's expected that PTRACE_O_TRACEEXIT not always catch all exits
[01:59] <hallyn> I've got a testcase that fires off one child that spanws 100 threads, all are traced with PTRACE_O_TRACEEXIT .  2/3 times between 1-3 of the threads end exiting without a PTRACE_EVENT_EXIT
[01:59] <hallyn> (i do get a WIFEXITED)
[03:49] <kees> hallyn: that doesn't surprise me. the death handling for ptrace events is rather a mess :(
[03:49] <kees> hallyn: IIRC Eric Biederman was working on some code to sort it out, but it has a lot of evil corner cases
[04:05] <hallyn> kees: yeah i ran across a thread from earlier this year with Eric and Oleg...  drat.  reliability would be nice :)
[04:06] <hallyn> i did see them asking "i wonder whether anyone uses this" :)
[04:08] <hallyn> kees: but actually this i ran across in a testcase;  the more immediate but harder to reproduce case was one where i did get the PTRACE_EVENT_EXIT, i ptrace-detach, but then i get another waitpid event for it later
[04:25] <hallyn> (and after the detach, /proc/pid/status shows still traced by the same task;  )
[05:31] <tsimonq2> coreycb: Good morning. When you have a minute, could you please take a look at bug 1699426?
[05:31] <ubottu> bug 1699426 in python-tornado (Ubuntu) "Merge 4.5.1-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1699426
=== maclin1 is now known as maclin
=== klebers_ is now known as klebers
[10:16] <hjd> Hi, could someone please trigger a rebuild of node-magic-string in artful (https://launchpadlibrarian.net/327201368/buildlog_ubuntu-artful-amd64.node-magic-string_0.21.3-1_BUILDING.txt.gz). Failed to build intially, but works now that the latest version of node-es6-module-transpiler has been synced. TIA :)
[11:33] <infinity> didrocks: Hey, apw just randomly Googled https://extensions.gnome.org/extension/413/dash-hotkeys/ for me.
[11:34] <infinity> didrocks: I'm not sure what our goals are for painless migration, but that seems like a think Unity users might expect to work on upgrade.  Maybe.
[11:34] <infinity> s/think/thing/
[11:35] <didrocks> infinity: dash2dock (which we are considering) has a similar optional feature
[11:35] <didrocks> I would be interesting to see that with an azerty keyboard btw :p
[11:35] <infinity> didrocks: azerty keyboards are an abomination.
[11:35] <didrocks> even in unity, it was all messed up before I patched it (yeah, number can be with Shift required on insane layouts!)
[11:36] <didrocks> heh
[11:36] <didrocks> I was waiting for that one :p
[11:36] <didrocks> do you know there is a poll currently in France for standardizing it btw?
[11:36] <didrocks> a mix between azerty + bepo
[11:36] <didrocks> seeing the proposals, none are dev friendly though
[11:37] <infinity> didrocks: Why not just standardize on qwerty + deadkeys, like normal humans.
[11:37] <infinity> If it's good enough for the Japanese...
[11:37] <infinity> And they have a whole lot more weird characters than you do.
[11:37] <infinity> So suck it up.
[11:37] <didrocks> because I guess we don't have a bunch of weird characters, so upfront cost for just a few ones
[11:37] <infinity> Yeah. :/
[11:38] <infinity> The "standard Canadian International" keyboard is a mess.
[11:38] <infinity> And if I'm not careful, it's what lenovo.ca tries to ship me.
[11:38] <didrocks> ahah "but it's all the same", right?
[11:38] <infinity> Thankfully, they learned in their first year or so doing business here that most of us have never seen that layout and really don't want one.
[11:38]  * didrocks googles
[11:39] <didrocks> oh, looks yummy, indeed
[11:39] <infinity> Yeah, it's qwerty, but very NOT PC101, and the differences matter.  A lot.
[11:40] <infinity> Plus key shapes change to accomodate the madness, so even remapping it doesn't fix it.
[11:40] <mdeslaur> eww, I hate that keyboard too
[11:45] <infinity> mdeslaur: I assume it's more or less the standard for bulk consumer/office purchases in QC?  It would dive me nuts if I had to use it.
[11:45] <mdeslaur> the language police mandate it
[11:46] <xnox> cpaelzer, both debian and ubuntu packaging of systemd is managed in git, with shared history using gbp dch to manage the changelog and gbp pq to manage patches
[11:46] <infinity> If only the PC world had discovered the Compose key.
[11:46] <xnox> cpaelzer, i guess you simply want us to cherry-pick the serialisation / deserialisation patches for the cgoup units?
[11:46] <infinity> Though deadkeys work well enough, once you train your fingers.
[11:47] <xnox> cpaelzer, there is ./debian/git-cherry-pick script that does exactly that, and correctly injects patches in the right place for the patch series.
[11:47] <mdeslaur> infinity: I don't get why they had to change the key sizes...the vertical enter and tiny backspace are insane
[11:47] <infinity> mdeslaur: It's to accomodate extra keys.  It's fairly similar to the (equally broken, IMO) UK101 layout.
[11:47] <xnox> cpaelzer, can you simply state the ids of the patches you are after; and series you want them in; and i can look into cherrypciking/backporting them and SRUing them throughout.
[11:48] <xnox> cpaelzer, as i do manage systemd SRUs holistically, and there is always a queue of things that people want/need in the next upload.
[11:48] <infinity> mdeslaur: The tiny left shift is what always trips me up.
[11:48] <mdeslaur> ah yes, that too
[12:08] <doko> mwhudson: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-zesty.html some python related failures
[12:09] <doko> jamespage: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-zesty.html  some openstack related failures
[12:20] <apw> didrocks, with that panel moved to the top and made the same size it was before ... it is pretty nice
[12:25] <didrocks> apw: yeah, I guess we'll discuss soon about the ubuntu experience we can provide (but yeah, at worst, extensions)
[12:28] <apw> didrocks, well if you make an ubuntu experience i guess it gets to be an extension ...
[12:29] <apw> if you could make the alt do the menu like it did in ubuntu, across the top rather than in a button, that might be the best of all worlds
[12:33] <jbicha> that's "global menus"
[12:33] <jbicha> it wouldn't really make a difference for "native" GNOME3 apps that don't have traditional File Edit View menus
[12:35] <coreycb> tsimonq2: hi, just commented. sigh.
[12:36] <coreycb> jamespage: can you take a look at my comment on bug 1699426 and comment if you have an opinion?
[12:36] <ubottu> bug 1699426 in python-tornado (Ubuntu) "Merge 4.5.1-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1699426
[12:37] <jamespage> coreycb: we have both in main still?
[12:37] <jamespage> that sounds wonky
[12:38] <tsimonq2> coreycb: ack
[12:41] <coreycb> jamespage: yeah
[14:17] <powersj> slangasek: any idea why there are no daily amd64 or i386 daily server images? http://cdimage.ubuntu.com/ubuntu-server/daily/20170707/
[14:27] <slangasek> powersj: good question
[14:29] <slangasek> powersj: here's the i386 error from the log http://pastebin.ubuntu.com/25039610/
[14:30] <seb128> xnox, slangasek, did you get anywhere with the nplan/n-m issue?
[14:31] <slangasek> I have not
[14:31] <slangasek> xnox seemed to believe it was a real regression introduced by NM
[14:32] <apw> slangasek, when infinity was looking at iso issues this morning he found isolinux was unseeded, dunno if that could be the issue; he thought it was apt for a bit, which i would from that log there
[14:35] <xnox> seb128, on my todo list
[14:46] <slangasek> powersj: apparently this issue was identified and fixed last night for desktop; I'll retry ubuntu-server now
[14:46] <powersj> slangasek: thanks
[14:46] <slangasek> powersj: (discussion on #ubuntu-release)
[15:51] <acheronuk> DNS on artful seems frequently broken
[15:51] <acheronuk> ^^^ clivejo
[15:51] <rbasak> nacc: the way I see "git ubuntu lint" working is a little like lintian - it'll act on HEAD by default, analyze, and print a load of warnings and errors.
[15:52] <rbasak> Some stuff will need LP connectivity, which I think it should do by default, but have an offline option to turn that off (and lose some tests)
[16:09] <nacc> rbasak: ack, are you ok with 'lint' as the subcommand? or 'review'?
[16:30] <rbasak> nacc: I think review implies a human
[16:32] <Unit193> nacc: Also, FYI I uploaded (to Debian) the package that recommends python3-parsedatetime.
[16:32] <Unit193> (FSVO "I")
[16:33] <nacc> Unit193: ok good to know
[16:33] <nacc> rbasak: true, good point
[16:34] <nacc> rbasak: i suppose we would eventually have two commands -- one for reviewing a MP and one for linting a current branch
[16:34] <nacc> review could use lint then
[16:34] <rbasak> Yeah
[16:44] <slangasek> nacc, rbasak: you're not putting AIs in charge of your reviews? :)
[16:44] <nacc> slangasek: one day :)
[16:44] <nacc> All Interestedparties
[16:45] <nacc> that's as clever as i can be on one cup of coffee
[16:50] <rbasak> slangasek: we're working on it :)
[17:07] <nacc> rbasak: around still?
[17:08] <rbasak> nacc: just
[17:08] <nacc> rbasak: your review comment, is 'branch_name' to pristine_tar_list meant to be the branch to use for querying pristine-tar?
[17:08] <nacc> rbasak: just trying to understand the intended semantics of it
[17:08] <rbasak> nacc: right - if pristine-tar ever grew that feature. Until then, the implementation needs to rename around
[17:09] <nacc> rbasak: ok, but is the idea that the function will return *all* the pristine-tars? or just the ones for that branch (that is the caller will need to pass 'pkg/importer/ubuntu/pristine-tar' and 'pkg/importer/debian/pristine-tar'?
[17:10] <rbasak> The latter
[17:10] <nacc> rbasak: given you have a default value for branch_name, i'm not sure the intent
[17:10] <nacc> got it
[17:10] <rbasak> The default is only because that's pristine-tar's default so it follows logically.
[17:10] <rbasak> Perhaps for us that's wrong though and we should have no default.
[17:10] <rbasak> I'd never expect us to use it.
[17:11] <nacc> yeah, i'd be more comfortable not using it (or not specifying it by default) and then handling the allow_override semantics as you listed
[17:11] <nacc> that makes more immediate sense to me
[17:11] <rbasak> OK
[17:11] <rbasak> I'm fine with that
[17:12] <rbasak> If I understand you correctly
[17:12] <rbasak> I'm not sure I follow exactly
[17:13] <nacc> basically, i think branch_name is meant to reflect, i want the pristine-tars from this branch. But given that 'pristine-tar' is sort of a reserved name, I'd rather we make that explicit in the caller and drop the default (i don't think we'd have any callers anyways  that don't pass branch_name)
[17:13] <rbasak> Ah
[17:13] <rbasak> Yeah that's fine
[17:13] <nacc> rbasak: code will speak louder than words, I can implement it and you can review
[17:13] <rbasak> OK thanks!
[17:13] <nacc> rbasak: enjoy your w/e
[17:56] <coreycb> hi all, could someone please reject my libvirt uploads for xenial and zesty? i have some changes to upload.
[18:42] <coreycb> i've gone ahead and uploaded new versions of libvirt to xenial and zesty to the unapproved queues.  the older uploads of libvirt from 2017-06-27 are the ones that can be rejected.