kokoye2007 | Hello | 00:28 |
---|---|---|
=== rcj` is now known as rcj | ||
slangasek | bdmurray: that's still https://code.launchpad.net/~vorlon/ubuntu/utopic/apport/lp.1354318, which is tied up in a question between ev and pitti about whether we're getting premature inotify regardless of umask settings | 01:06 |
bdmurray | slangasek: I didn't see that question and started a new branch based on yours but not using a .new report file per pitti's concerns. | 01:08 |
=== timrc is now known as timrc-afk | ||
slangasek | bdmurray: yes, I'm not sure ev has actually raised the point with pitti, though I asked him to do so... maybe a highlight will help :) | 01:10 |
=== lionel_ is now known as lionel | ||
=== mako_ is now known as mako | ||
pitti | Good morning | 04:38 |
pitti | slangasek, bdmurray: yeah, I'm still not convinced that a full rewrite instead of appending is better in any way; it's a lot more expensive and just changes the failure mode instead of improving them | 05:03 |
slangasek | pitti: so ev claimed to me that the current approach was giving problems with inotify behavior | 05:42 |
pitti | slangasek: i. e. the final close() and/or chown() doesn't trigger an inotify event any more? | 05:54 |
slangasek | pitti: I believe ev's assertion was that the inotify happens too early. But we shouldn't play telephone | 05:55 |
pitti | yeah, let's wait until he comes online | 05:56 |
pitti | apw: thanks for tracking down bug 1375805 | 06:10 |
ubottu | bug 1375805 in systemd (Ubuntu) "Lightdm fails to start in VirtualBox " [High,Fix committed] https://launchpad.net/bugs/1375805 | 06:10 |
dholbach | good morning | 07:18 |
mlankhorst | morning! | 07:47 |
mardy | pitti: hi! Is it a good idea to add -dbg packages to the projects I maintain, or do we have a different policy? | 07:49 |
pitti | mardy: they are redundant in Ubuntu as we autuomatically build -dbgsym packages for everything | 07:50 |
pitti | mardy: so don't bother | 07:50 |
mardy | pitti: OK, thanks | 07:50 |
apw | pitti, i was lucky to have a persistant tester :) | 07:54 |
pitti | dpm, wgrant: an hour ago or so I approved/cleaned up the POTs on https://translations.launchpad.net/ubuntu-rtm/14.09/+source/oxide-qt/+imports -- I don't need to do anything with the POs, right? they'll be auto-imported eventually? | 08:11 |
dpm | pitti, exactly. Once the .pots are approved and imported, the .pos will be too | 08:12 |
pitti | thanks | 08:14 |
seb128 | pitti, do you plan a langpack update in rtm? | 08:15 |
pitti | seb128: it's cron'ed; https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs will get another update tomorrow | 08:16 |
seb128 | pitti, ok, great, thanks :-) | 08:16 |
pitti | seb128: if weekly isn't enough, we can certainly ask wgrant to produce two every week? | 08:16 |
seb128 | pitti, weekly is enough, I saw none on https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-September/date.html but I guess for some reason they don't appear on -changes? | 08:17 |
pitti | seb128: correct; language-pack-* is filtered out for ACCEPTED mails, changes@ etc | 08:17 |
seb128 | k, makes sense | 08:18 |
pitti | seb128: https://launchpad.net/ubuntu-rtm/+source/language-pack-touch-de/+changelog | 08:18 |
seb128 | pitti, thanks | 08:18 |
seb128 | weekly seems fine to me | 08:18 |
seb128 | is jenkins.qa.ubuntu.com down? | 08:20 |
pitti | seb128: apparently, yes; d-jenkins works fine | 08:25 |
seb128 | where is the right place to let people know in they case they don't? #is? | 08:25 |
pitti | seb128: yes, in particular retoaded | 08:26 |
Laney | it did load for me, but it was s-u-p-e-r-s-l-o-w | 08:27 |
seb128 | Laney, it's spinning for over 5 minutes for me | 08:28 |
seb128 | that's not usable, I'm still going to let #is know | 08:28 |
Laney | needs attention either way | 08:28 |
seb128 | yeah | 08:29 |
mlankhorst | doko_: ping? | 08:29 |
seb128 | Laney, pitti, #is restarted it, back to normal | 08:47 |
pitti | seb128: cool, thanks | 08:47 |
seb128 | yw! | 08:47 |
Laney | great | 08:48 |
flexiondotorg | Laney, Thanks for uploading the update xzoom to Debian and Ubuntu. | 09:03 |
=== vrruiz_ is now known as rvr | ||
Laney | flexiondotorg: no worries | 09:52 |
wwlzhuzhu | Hi everyone, I am trying to add a net samba printer, I try to see the windows computer from Places net,I can. But from printer manager i can not accesss trough examine. I am on ubuntuMATE beta2 | 10:07 |
=== timrc-afk is now known as timrc | ||
=== doko_ is now known as doko | ||
doko | mlankhorst, pong | 11:03 |
mlankhorst | so it seems llvm detects qemu32 as pentium2, which disables the sse extensions, causing the llvmpipe breakage | 11:04 |
=== Sweetsha1k is now known as Sweetshark | ||
=== MacSlow is now known as MacSlow|lunch | ||
=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
=== ycheng is now known as ycheng-afk | ||
doko | mlankhorst, but why are these needed by llvmpipe? | 13:01 |
doko | mlankhorst, how comes qemu into the game? | 13:19 |
mlankhorst | doko: things were already broken before it seems, but with the change to 3.5 to no longer autodetect features it started to show.. | 13:23 |
doko | mlankhorst, lp_screen.c explicitly checks for sse2 | 13:25 |
doko | so why did that work before? | 13:25 |
mlankhorst | because we passed an empty string to cpu/feature flags | 13:25 |
mlankhorst | which meant 'autodetect all capabilities please' | 13:25 |
=== _salem is now known as salem_ | ||
mlankhorst | this is no longer supported in 3.5 | 13:26 |
mlankhorst | and llvm::sys::gethostcpuname() returns 'pentium2' | 13:26 |
=== ycheng-afk is now known as ycheng | ||
nrbrtx | Dear all! I can't understand why Ubuntu does not have an init script for saving and restoring display backlight level. I have prepared one (see bug 1270579 ), it works on my laptops as expected. | 13:27 |
ubottu | bug 1270579 in sysvinit (Ubuntu) "Ubuntu should have an init script for saving/restoring backlight level on laptops" [Medium,Confirmed] https://launchpad.net/bugs/1270579 | 13:27 |
doko | mlankhorst, that would be correct, as we build for i686. but where is qemu32 called? can't you specify a target cpu? | 13:28 |
mlankhorst | you can specify a target cpu, but llvm detects it as a generic pentium2, without sse support or anything.. | 13:28 |
mlankhorst | it can be overridden partially, but setting all the feature flags manually will be a bit of a pain | 13:29 |
mlankhorst | still, i probably should :/ | 13:29 |
=== ycheng is now known as ycheng-afk | ||
ted | bdmurray, Do you know what tool generates this list: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-incoming-bug-tasks.html | 13:36 |
pitti | apw: oh right, you forgot the debian/rules bit | 13:42 |
pitti | apw: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=0c114f9497ca8771c96229e6ccc59544f7cd6c0b | 13:42 |
pitti | apw: that was my original commit until I saw your upload | 13:42 |
nrbrtx | Am I understand correctly, that Ubuntu Utopic has screen backlight save/restore on via systemd? | 13:43 |
apw | pitti, yeah ... just fixed it ... stupid test box has that file as a "conf" file from the old days ... and if you had gotten their first it would have been fixed first time ... grr | 13:51 |
pitti | apw: urgh, conffile? oh blergh, this is an upstart job, not an udev rule, right | 13:52 |
pitti | apw: no worries :) | 13:52 |
apw | pitti, i know, but somehow apt has it down as one of those ... | 13:52 |
apw | pitti, anyhow this time the builders are working so i was able to get a reliable test before upload, though it matches yours exactly | 13:52 |
pitti | and yeah, init scripts/jobs really should not be conffiles, but be treated as code; they are the #1 offender in /etc for cleaning it up | 13:53 |
mlankhorst | doko: http://paste.debian.net/123989/ untested, but would something like this work? | 14:05 |
=== timrc is now known as timrc-afk | ||
mlankhorst | hm seems to! D | 14:19 |
mlankhorst | *:D | 14:19 |
mdeslaur | doko: can I expect a twisted sync? | 14:21 |
mlankhorst | doko: the paste I linked above fixes the crash in the test for me. Would this be a sane way to deal to have some form of autodetection? | 14:28 |
=== timrc-afk is now known as timrc | ||
mlankhorst | it should at least match llvmpipe's idea of the cpu caps to llvm | 14:36 |
bdmurray | pitti, slangasek: I wonder if ev's concern stemmed from incomplete reports appearing in the error tracker due to bug 1360417. | 14:38 |
ubottu | bug 1360417 in apport (Ubuntu Trusty) "thread_collect_info can leave out information in .crash files" [Medium,Fix released] https://launchpad.net/bugs/1360417 | 14:38 |
bdmurray | ted: yes, I know what tool generates that list | 14:39 |
ted | bdmurray, Will you tell me? :-) | 14:40 |
bdmurray | ted: https://code.launchpad.net/~arsenal-devel/arsenal/2.x see the rls-mgr folder | 14:42 |
doko | mdeslaur, no, but there is an upload in the unapproved queue | 14:56 |
doko | mlankhorst, maybe guard this for ix86? | 15:01 |
slangasek | ev: ^^ can you provide some more detail on your whoopsie_upload_all / inotify concern? | 15:03 |
mdeslaur | doko: cool, thanks | 15:09 |
=== mpt_ is now known as mpt | ||
ev | slangasek: sure, looking now | 16:13 |
ev | I believe my concern was that the report would appear to whoopsie via inotify before it had the correct permissions. Whoopsie would try to read this, fail, and put it in a queue for two hours later. | 16:15 |
ev | This doesn't appear to be the case, looking at Martin's MP | 16:15 |
ev | whoopsie isn't looking for .new files, so it will only act on the report after the rename, after it has the right permissions | 16:16 |
ev | slangasek: err your MP :) | 16:16 |
ev | ohhh | 16:16 |
ev | your MP introduces the .new behaviour | 16:16 |
ev | so this makes more sense now | 16:16 |
slangasek | ev: ok, I thought you had expressed a concern that things were /already/ appearing to whoopsie before they had the correct permissions | 16:17 |
ev | I was looking at a bug that asac was encountering at the time. I believe your MP will fix it. | 16:17 |
slangasek | ev: pitti has claimed that the inotify only happens once the file is readable | 16:17 |
slangasek | ev: right, and pitti wants me to not use the .new | 16:17 |
ev | oh boo | 16:17 |
=== henrix_ is now known as henrix | ||
slangasek | so what was the bug, specifically? | 16:17 |
ev | well, we could have a unit test for this sort of thing | 16:17 |
=== lan3y is now known as Laney | ||
pitti | ev, slangasek: no, I'm fairly sure the inotify happens already on creation; I wondered if there's another inotify event on close() or chmod(), so that we can wait until teh file becomes readable | 16:18 |
slangasek | ok | 16:18 |
slangasek | pitti: so it's speculation on your side that this works in a non-racy manner? ;-) | 16:19 |
mitya57 | Is it normal when a package in universe depends on a package in multiverse? | 16:19 |
slangasek | mitya57: no, it's disallowed by policy | 16:19 |
pitti | slangasek: well, it's a question :) | 16:19 |
slangasek | ok | 16:19 |
* mitya57 files a bug then (the package in question is ubuntu-emulator) | 16:20 | |
slangasek | so, notwithstanding the increase in disk writes, I'm sure that my MP is non-racy wrt inotify | 16:20 |
pitti | slangasek: but according to the manpage, inotify can do this (subscribe to IN_CLOSE_WRITE) | 16:20 |
pitti | or even better, IN_ATTRIB (and then checking if it's readable) | 16:21 |
pitti | that's the thing which we are actually looking out for | 16:21 |
pitti | as it has permissions 000 during writing | 16:21 |
slangasek | pitti: ok, well I gather that this isn't what's being done today | 16:21 |
pitti | hmm, grepping whoopsie for "inotify" gives no results | 16:22 |
slangasek | ev: where does the inotify watching happen for this? no references to 'inotify' in the whoopsie source | 16:23 |
pitti | oh, glib -- GFileMonitor? | 16:23 |
pitti | bingo | 16:23 |
slangasek | ok | 16:23 |
pitti | so I suppose we want G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED | 16:24 |
pitti | if ((event_type == G_FILE_MONITOR_EVENT_CREATED) || | 16:24 |
pitti | (event_type == G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED)) | 16:24 |
pitti | and the first one should be dropped (or there shoudl be at least an additional check that the file is readable) | 16:25 |
pitti | oh wait | 16:26 |
slangasek | pitti: the first one is necessary for offline notifications of files already created when whoopsie starts | 16:26 |
pitti | this is the monitor for the .upload stamp | 16:26 |
pitti | that looks fine | 16:26 |
pitti | in fact, whoopsie isn't concerned about the completeness of .crash files at all; apport writes the stamps, and whoopsie is only looking for .upload | 16:26 |
pitti | sorry, so this was a red herring, whoopsie looks fine | 16:26 |
ev | yeah, damn | 16:27 |
pitti | we only need to ensure to write the .stamp file after the .crash file is completely written and readable | 16:27 |
slangasek | ev: so is there not actually a bug here? | 16:27 |
pitti | which again is contained in whoopsie-upload-all | 16:27 |
ev | I don't believe so, no | 16:27 |
slangasek | ok | 16:27 |
slangasek | bdmurray: ^^ so I think this should unblock you regarding your fix to my branch to not do the .new handling | 16:27 |
pitti | and AFAICS the current version already does that | 16:27 |
bdmurray | slangasek: okay, thanks | 16:31 |
=== ikonia_ is now known as ikonia | ||
bdmurray | pitti: the fix for bug 1354571 will prevent uploading of incomplete core dumps right? | 16:41 |
ubottu | bug 1354571 in apport (Ubuntu) "apport-retrace ignores warnings from gdb" [Medium,Fix released] https://launchpad.net/bugs/1354571 | 16:41 |
=== Pici` is now known as Pici | ||
pitti | bdmurray: yes, this was specifically adjusted in w-u-a as well | 16:44 |
pitti | i. e. not just with UnreportableReason | 16:44 |
bdmurray | pitti: okay, I think I'll SRU this to Trusty to reduce the work load for the error tracker then | 16:46 |
=== ChrisTownsend1 is now known as ChrisTownsend | ||
=== salem_ is now known as _salem | ||
=== roadmr is now known as roadmr_afk | ||
=== _salem is now known as salem_ | ||
brainwash_ | xnox: hey, have you already been pinged by the xubuntu team re bug 1375893 ? | 19:32 |
ubottu | bug 1375893 in ubiquity (Ubuntu) "Black background to Try/Install Dialogue" [Undecided,Confirmed] https://launchpad.net/bugs/1375893 | 19:32 |
=== nik90 is now known as nik90|Dinner | ||
brainwash_ | you've fixed the ubiquity wallpaper problem some months ago, back then it showed the debian background | 19:38 |
=== roadmr_afk is now known as roadmr | ||
=== nik90|Dinner is now known as nik90 | ||
Noskcaj | mitya57, Anything i still need to do for bug 1372224 | 20:47 |
ubottu | bug 1372224 in tortoisehg (Ubuntu) "[FFe] sync tortoisehg 3.1.1-1 (universe) from Debian unstable (main)" [High,Triaged] https://launchpad.net/bugs/1372224 | 20:47 |
AMDCeleron | !ops | 21:36 |
ubottu | Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! | 21:36 |
AMDCeleron | !ops | 21:41 |
=== AMDCeleron is now known as HFSPLUS | ||
doko | Logan_, are you this logan? http://bugs.python.org/issue18096 | 21:50 |
doko | slangasek, infinity: did you make progress with the cross-toolchain-base packages? | 22:43 |
slangasek | doko: I've gotten a successful build of the arm64 one, but I understand that there's still some more work needed for any of the biarch cross-compilers; also the packaging has drifted between the various targets and badly needs to be resynced... that's currently backburnered for me | 22:47 |
doko | slangasek, ok, once you have the arm64 case, I can have a look at the biarch stuff | 22:51 |
slangasek | well, I think infinity wanted to look at it from the glibc side | 22:51 |
doko | ahh, nice | 22:51 |
infinity | I'm looking at it, yes. | 22:51 |
infinity | Have some patches from helmut to toss in, and then some test building to see the state of things and where it now breaks. | 22:52 |
=== salem_ is now known as _salem |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!