[00:28] Hello === rcj` is now known as rcj [01:06] 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:08] 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. === timrc is now known as timrc-afk [01:10] 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 :) === lionel_ is now known as lionel === mako_ is now known as mako [04:38] Good morning [05:03] 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:42] pitti: so ev claimed to me that the current approach was giving problems with inotify behavior [05:54] slangasek: i. e. the final close() and/or chown() doesn't trigger an inotify event any more? [05:55] pitti: I believe ev's assertion was that the inotify happens too early. But we shouldn't play telephone [05:56] yeah, let's wait until he comes online [06:10] apw: thanks for tracking down bug 1375805 [06:10] bug 1375805 in systemd (Ubuntu) "Lightdm fails to start in VirtualBox " [High,Fix committed] https://launchpad.net/bugs/1375805 [07:18] good morning [07:47] morning! [07:49] pitti: hi! Is it a good idea to add -dbg packages to the projects I maintain, or do we have a different policy? [07:50] mardy: they are redundant in Ubuntu as we autuomatically build -dbgsym packages for everything [07:50] mardy: so don't bother [07:50] pitti: OK, thanks [07:54] pitti, i was lucky to have a persistant tester :) [08:11] 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:12] pitti, exactly. Once the .pots are approved and imported, the .pos will be too [08:14] thanks [08:15] pitti, do you plan a langpack update in rtm? [08:16] seb128: it's cron'ed; https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs will get another update tomorrow [08:16] pitti, ok, great, thanks :-) [08:16] seb128: if weekly isn't enough, we can certainly ask wgrant to produce two every week? [08:17] 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] seb128: correct; language-pack-* is filtered out for ACCEPTED mails, changes@ etc [08:18] k, makes sense [08:18] seb128: https://launchpad.net/ubuntu-rtm/+source/language-pack-touch-de/+changelog [08:18] pitti, thanks [08:18] weekly seems fine to me [08:20] is jenkins.qa.ubuntu.com down? [08:25] seb128: apparently, yes; d-jenkins works fine [08:25] where is the right place to let people know in they case they don't? #is? [08:26] seb128: yes, in particular retoaded [08:27] it did load for me, but it was s-u-p-e-r-s-l-o-w [08:28] Laney, it's spinning for over 5 minutes for me [08:28] that's not usable, I'm still going to let #is know [08:28] needs attention either way [08:29] yeah [08:29] doko_: ping? [08:47] Laney, pitti, #is restarted it, back to normal [08:47] seb128: cool, thanks [08:47] yw! [08:48] great [09:03] Laney, Thanks for uploading the update xzoom to Debian and Ubuntu. === vrruiz_ is now known as rvr [09:52] flexiondotorg: no worries [10:07] 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 === timrc-afk is now known as timrc === doko_ is now known as doko [11:03] mlankhorst, pong [11:04] so it seems llvm detects qemu32 as pentium2, which disables the sse extensions, causing the llvmpipe breakage === 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 [13:01] mlankhorst, but why are these needed by llvmpipe? [13:19] mlankhorst, how comes qemu into the game? [13:23] 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:25] mlankhorst, lp_screen.c explicitly checks for sse2 [13:25] so why did that work before? [13:25] because we passed an empty string to cpu/feature flags [13:25] which meant 'autodetect all capabilities please' === _salem is now known as salem_ [13:26] this is no longer supported in 3.5 [13:26] and llvm::sys::gethostcpuname() returns 'pentium2' === ycheng-afk is now known as ycheng [13:27] 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] 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:28] mlankhorst, that would be correct, as we build for i686. but where is qemu32 called? can't you specify a target cpu? [13:28] you can specify a target cpu, but llvm detects it as a generic pentium2, without sse support or anything.. [13:29] it can be overridden partially, but setting all the feature flags manually will be a bit of a pain [13:29] still, i probably should :/ === ycheng is now known as ycheng-afk [13:36] bdmurray, Do you know what tool generates this list: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-incoming-bug-tasks.html [13:42] apw: oh right, you forgot the debian/rules bit [13:42] apw: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=0c114f9497ca8771c96229e6ccc59544f7cd6c0b [13:42] apw: that was my original commit until I saw your upload [13:43] Am I understand correctly, that Ubuntu Utopic has screen backlight save/restore on via systemd? [13:51] 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:52] apw: urgh, conffile? oh blergh, this is an upstart job, not an udev rule, right [13:52] apw: no worries :) [13:52] pitti, i know, but somehow apt has it down as one of those ... [13:52] 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:53] 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 [14:05] doko: http://paste.debian.net/123989/ untested, but would something like this work? === timrc is now known as timrc-afk [14:19] hm seems to! D [14:19] *:D [14:21] doko: can I expect a twisted sync? [14:28] 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? === timrc-afk is now known as timrc [14:36] it should at least match llvmpipe's idea of the cpu caps to llvm [14:38] pitti, slangasek: I wonder if ev's concern stemmed from incomplete reports appearing in the error tracker due to bug 1360417. [14:38] 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:39] ted: yes, I know what tool generates that list [14:40] bdmurray, Will you tell me? :-) [14:42] ted: https://code.launchpad.net/~arsenal-devel/arsenal/2.x see the rls-mgr folder [14:56] mdeslaur, no, but there is an upload in the unapproved queue [15:01] mlankhorst, maybe guard this for ix86? [15:03] ev: ^^ can you provide some more detail on your whoopsie_upload_all / inotify concern? [15:09] doko: cool, thanks === mpt_ is now known as mpt [16:13] slangasek: sure, looking now [16:15] 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] This doesn't appear to be the case, looking at Martin's MP [16:16] 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] slangasek: err your MP :) [16:16] ohhh [16:16] your MP introduces the .new behaviour [16:16] so this makes more sense now [16:17] ev: ok, I thought you had expressed a concern that things were /already/ appearing to whoopsie before they had the correct permissions [16:17] I was looking at a bug that asac was encountering at the time. I believe your MP will fix it. [16:17] ev: pitti has claimed that the inotify only happens once the file is readable [16:17] ev: right, and pitti wants me to not use the .new [16:17] oh boo === henrix_ is now known as henrix [16:17] so what was the bug, specifically? [16:17] well, we could have a unit test for this sort of thing === lan3y is now known as Laney [16:18] 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] ok [16:19] pitti: so it's speculation on your side that this works in a non-racy manner? ;-) [16:19] Is it normal when a package in universe depends on a package in multiverse? [16:19] mitya57: no, it's disallowed by policy [16:19] slangasek: well, it's a question :) [16:19] ok [16:20] * mitya57 files a bug then (the package in question is ubuntu-emulator) [16:20] so, notwithstanding the increase in disk writes, I'm sure that my MP is non-racy wrt inotify [16:20] slangasek: but according to the manpage, inotify can do this (subscribe to IN_CLOSE_WRITE) [16:21] or even better, IN_ATTRIB (and then checking if it's readable) [16:21] that's the thing which we are actually looking out for [16:21] as it has permissions 000 during writing [16:21] pitti: ok, well I gather that this isn't what's being done today [16:22] hmm, grepping whoopsie for "inotify" gives no results [16:23] ev: where does the inotify watching happen for this? no references to 'inotify' in the whoopsie source [16:23] oh, glib -- GFileMonitor? [16:23] bingo [16:23] ok [16:24] so I suppose we want G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED [16:24] if ((event_type == G_FILE_MONITOR_EVENT_CREATED) || [16:24] (event_type == G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED)) [16:25] and the first one should be dropped (or there shoudl be at least an additional check that the file is readable) [16:26] oh wait [16:26] pitti: the first one is necessary for offline notifications of files already created when whoopsie starts [16:26] this is the monitor for the .upload stamp [16:26] that looks fine [16:26] 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] sorry, so this was a red herring, whoopsie looks fine [16:27] yeah, damn [16:27] we only need to ensure to write the .stamp file after the .crash file is completely written and readable [16:27] ev: so is there not actually a bug here? [16:27] which again is contained in whoopsie-upload-all [16:27] I don't believe so, no [16:27] ok [16:27] bdmurray: ^^ so I think this should unblock you regarding your fix to my branch to not do the .new handling [16:27] and AFAICS the current version already does that [16:31] slangasek: okay, thanks === ikonia_ is now known as ikonia [16:41] pitti: the fix for bug 1354571 will prevent uploading of incomplete core dumps right? [16:41] bug 1354571 in apport (Ubuntu) "apport-retrace ignores warnings from gdb" [Medium,Fix released] https://launchpad.net/bugs/1354571 === Pici` is now known as Pici [16:44] bdmurray: yes, this was specifically adjusted in w-u-a as well [16:44] i. e. not just with UnreportableReason [16:46] pitti: okay, I think I'll SRU this to Trusty to reduce the work load for the error tracker then === 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_ [19:32] xnox: hey, have you already been pinged by the xubuntu team re bug 1375893 ? [19:32] bug 1375893 in ubiquity (Ubuntu) "Black background to Try/Install Dialogue" [Undecided,Confirmed] https://launchpad.net/bugs/1375893 === nik90 is now known as nik90|Dinner [19:38] you've fixed the ubiquity wallpaper problem some months ago, back then it showed the debian background === roadmr_afk is now known as roadmr === nik90|Dinner is now known as nik90 [20:47] mitya57, Anything i still need to do for bug 1372224 [20:47] bug 1372224 in tortoisehg (Ubuntu) "[FFe] sync tortoisehg 3.1.1-1 (universe) from Debian unstable (main)" [High,Triaged] https://launchpad.net/bugs/1372224 [21:36] !ops [21:36] Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! [21:41] !ops === AMDCeleron is now known as HFSPLUS [21:50] Logan_, are you this logan? http://bugs.python.org/issue18096 [22:43] slangasek, infinity: did you make progress with the cross-toolchain-base packages? [22:47] 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:51] slangasek, ok, once you have the arm64 case, I can have a look at the biarch stuff [22:51] well, I think infinity wanted to look at it from the glibc side [22:51] ahh, nice [22:51] I'm looking at it, yes. [22:52] Have some patches from helmut to toss in, and then some test building to see the state of things and where it now breaks. === salem_ is now known as _salem