[00:28] <kokoye2007> Hello
[01:06] <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:08] <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:10] <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 :)
[04:38] <pitti> Good morning
[05:03] <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:42] <slangasek> pitti: so ev claimed to me that the current approach was giving problems with inotify behavior
[05:54] <pitti> slangasek: i. e. the final close() and/or chown() doesn't trigger an inotify event any more?
[05:55] <slangasek> pitti: I believe ev's assertion was that the inotify happens too early.  But we shouldn't play telephone
[05:56] <pitti> yeah, let's wait until he comes online
[06:10] <pitti> apw: thanks for tracking down bug 1375805
[07:18] <dholbach> good morning
[07:47] <mlankhorst> morning!
[07:49] <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:50] <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:54] <apw> pitti, i was lucky to have a persistant tester :)
[08:11] <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:12] <dpm> pitti, exactly. Once the .pots are approved and imported, the .pos will be too
[08:14] <pitti> thanks
[08:15] <seb128> pitti, do you plan a langpack update in rtm?
[08:16] <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:17] <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:18] <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:20] <seb128> is jenkins.qa.ubuntu.com down?
[08:25] <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:26] <pitti> seb128: yes, in particular retoaded
[08:27] <Laney> it did load for me, but it was s-u-p-e-r-s-l-o-w
[08:28] <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:29] <seb128> yeah
[08:29] <mlankhorst> doko_: ping?
[08:47] <seb128> Laney, pitti, #is restarted it, back to normal
[08:47] <pitti> seb128: cool, thanks
[08:47] <seb128> yw!
[08:48] <Laney> great
[09:03] <flexiondotorg> Laney, Thanks for uploading the update xzoom to Debian and Ubuntu.
[09:52] <Laney> flexiondotorg: no worries
[10:07] <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
[11:03] <doko> mlankhorst, pong
[11:04] <mlankhorst> so it seems llvm detects qemu32 as pentium2, which disables the sse extensions, causing the llvmpipe breakage
[13:01] <doko> mlankhorst, but why are these needed by llvmpipe?
[13:19] <doko> mlankhorst, how comes qemu into the game?
[13:23] <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:25] <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:26] <mlankhorst> this is no longer supported in 3.5
[13:26] <mlankhorst> and llvm::sys::gethostcpuname() returns 'pentium2'
[13:27] <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:28] <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:29] <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:36] <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:42] <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:43] <nrbrtx> Am I understand correctly, that Ubuntu Utopic has screen backlight save/restore on via systemd?
[13:51] <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:52] <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:53] <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
[14:05] <mlankhorst> doko: http://paste.debian.net/123989/ untested, but would something like this work?
[14:19] <mlankhorst> hm seems to! D
[14:19] <mlankhorst> *:D
[14:21] <mdeslaur> doko: can I expect a twisted sync?
[14:28] <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:36] <mlankhorst> it should at least match llvmpipe's idea of the cpu caps to llvm
[14:38] <bdmurray> pitti, slangasek: I wonder if ev's concern stemmed from incomplete reports appearing in the error tracker due to bug 1360417.
[14:39] <bdmurray> ted: yes, I know what tool generates that list
[14:40] <ted> bdmurray, Will you tell me? :-)
[14:42] <bdmurray> ted: https://code.launchpad.net/~arsenal-devel/arsenal/2.x see the rls-mgr folder
[14:56] <doko> mdeslaur, no, but there is an upload in the unapproved queue
[15:01] <doko> mlankhorst, maybe guard this for ix86?
[15:03] <slangasek> ev: ^^ can you provide some more detail on your whoopsie_upload_all / inotify concern?
[15:09] <mdeslaur> doko: cool, thanks
[16:13] <ev> slangasek: sure, looking now
[16:15] <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:16] <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:17] <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] <slangasek> so what was the bug, specifically?
[16:17] <ev> well, we could have a unit test for this sort of thing
[16:18] <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:19] <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:20]  * 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:21] <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:22] <pitti> hmm, grepping whoopsie for "inotify" gives no results
[16:23] <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:24] <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:25] <pitti> and the first one should be dropped (or there shoudl be at least an additional check that the file is readable)
[16:26] <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:27] <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:31] <bdmurray> slangasek: okay, thanks
[16:41] <bdmurray> pitti: the fix for bug 1354571 will prevent uploading of incomplete core dumps right?
[16:44] <pitti> bdmurray: yes, this was specifically adjusted in w-u-a as well
[16:44] <pitti> i. e. not just with UnreportableReason
[16:46] <bdmurray> pitti: okay, I think I'll SRU this to Trusty to reduce the work load for the error tracker then
[19:32] <brainwash_> xnox: hey, have you already been pinged by the xubuntu team re bug 1375893 ?
[19:38] <brainwash_> you've fixed the ubiquity wallpaper problem some months ago, back then it showed the debian background
[20:47] <Noskcaj> mitya57, Anything i still need to do for bug 1372224
[21:36] <AMDCeleron> !ops
[21:41] <AMDCeleron> !ops
[21:50] <doko> Logan_, are you this logan? http://bugs.python.org/issue18096
[22:43] <doko> slangasek, infinity: did you make progress with the cross-toolchain-base packages?
[22:47] <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:51] <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:52] <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.