| 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:58 |
| 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) | 01:59 |
| 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 | 03:49 |
| hallyn | kees: yeah i ran across a thread from earlier this year with Eric and Oleg... drat. reliability would be nice :) | 04:05 |
| hallyn | i did see them asking "i wonder whether anyone uses this" :) | 04:06 |
| 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:08 |
| hallyn | (and after the detach, /proc/pid/status shows still traced by the same task; ) | 04:25 |
| 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 | 05:31 |
| === maclin1 is now known as maclin | ||
| === klebers_ is now known as klebers | ||
| 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 :) | 10:16 |
| infinity | didrocks: Hey, apw just randomly Googled https://extensions.gnome.org/extension/413/dash-hotkeys/ for me. | 11:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 | |
| didrocks | oh, looks yummy, indeed | 11:39 |
| infinity | Yeah, it's qwerty, but very NOT PC101, and the differences matter. A lot. | 11:39 |
| 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:40 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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 | 11:48 |
| doko | mwhudson: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-zesty.html some python related failures | 12:08 |
| doko | jamespage: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-zesty.html some openstack related failures | 12:09 |
| apw | didrocks, with that panel moved to the top and made the same size it was before ... it is pretty nice | 12:20 |
| didrocks | apw: yeah, I guess we'll discuss soon about the ubuntu experience we can provide (but yeah, at worst, extensions) | 12:25 |
| apw | didrocks, well if you make an ubuntu experience i guess it gets to be an extension ... | 12:28 |
| 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:29 |
| 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:33 |
| coreycb | tsimonq2: hi, just commented. sigh. | 12:35 |
| 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:36 |
| jamespage | coreycb: we have both in main still? | 12:37 |
| jamespage | that sounds wonky | 12:37 |
| tsimonq2 | coreycb: ack | 12:38 |
| coreycb | jamespage: yeah | 12:41 |
| powersj | slangasek: any idea why there are no daily amd64 or i386 daily server images? http://cdimage.ubuntu.com/ubuntu-server/daily/20170707/ | 14:17 |
| slangasek | powersj: good question | 14:27 |
| slangasek | powersj: here's the i386 error from the log http://pastebin.ubuntu.com/25039610/ | 14:29 |
| seb128 | xnox, slangasek, did you get anywhere with the nplan/n-m issue? | 14:30 |
| slangasek | I have not | 14:31 |
| slangasek | xnox seemed to believe it was a real regression introduced by NM | 14:31 |
| 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:32 |
| xnox | seb128, on my todo list | 14:35 |
| 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) | 14:46 |
| 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:51 |
| 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) | 15:52 |
| nacc | rbasak: ack, are you ok with 'lint' as the subcommand? or 'review'? | 16:09 |
| rbasak | nacc: I think review implies a human | 16:30 |
| Unit193 | nacc: Also, FYI I uploaded (to Debian) the package that recommends python3-parsedatetime. | 16:32 |
| Unit193 | (FSVO "I") | 16:32 |
| nacc | Unit193: ok good to know | 16:33 |
| nacc | rbasak: true, good point | 16:33 |
| 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:34 |
| 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:44 |
| nacc | that's as clever as i can be on one cup of coffee | 16:45 |
| rbasak | slangasek: we're working on it :) | 16:50 |
| nacc | rbasak: around still? | 17:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| rbasak | If I understand you correctly | 17:12 |
| rbasak | I'm not sure I follow exactly | 17:12 |
| 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:13 |
| coreycb | hi all, could someone please reject my libvirt uploads for xenial and zesty? i have some changes to upload. | 17:56 |
| 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. | 18:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!