[00:03] <smoser> lifeless, thanks. http://bugs.squid-cache.org/show_bug.cgi?id=3949
[00:03] <smoser> now me to bed.
[00:03] <lifeless> smoser: gnight
[00:03] <lifeless> smoser: thanks
[04:43] <snkt> hiii
[04:56] <slangasek> hallyn_: ovmf persistence> oh, very nice :)
[04:58] <pitti_> Good morning
[09:00] <brainwash> pitti: uhm, someone removed almost all duplicates from the logind suspend/resume bug report
[09:05] <pitti> erk, why's that? any comment about it?
[09:06] <ogra_> secret lennart conspiracy !
[09:06] <ogra_> :)
[09:06] <pitti> he'd be the first one to point bugs in our hacks :)
[09:06] <ogra_> yeah
[09:06] <pitti> point "out"
[09:06]  * ogra_ was just joking
[09:09] <brainwash> pitti: dunno, but I got some new info, so I replaced pm-suspend by a simple script which sleeps for a longer amount of time (10/15/30 sec, some value)
[09:09] <brainwash> this does reproduce the issue
[09:11] <brainwash> it still happens only occasionally I think
[09:12] <pitti> brainwash: oh, hang on
[09:13] <pitti> I just saw that systemd-shim times out after 10 seconds
[09:13] <brainwash> o.o
[09:13] <pitti> that should certainly be much longer
[09:13] <brainwash> yeah :D
[09:13] <pitti> brainwash: hang on, I'm finally through with what I was working on before, I'll look at the bug now
[09:14] <pitti> brainwash: where did you put the sleep, just to be sure?
[09:14] <pitti> brainwash: so perhaps this happens on machines where suspend/resume takes longer, due to some particular hardware, or slow machines, etc.
[09:14] <brainwash> I simple replaced the /usr/sbin/pm-suspend in systemd-shim
[09:15] <pitti> brainwash: developers tend to have fast boxes with SSDs and well-supported hardware where suspend is fast, perhaps that's why :)
[09:15] <brainwash> and pointed it to a script which contains "sleep"
[09:16] <pitti> brainwash: can you still reproduce it if you change g_timeout_add (10000, ... to g_timeout_add_seconds(600, ...) in src/systemd-shim.c ?
[09:16] <brainwash> but 10 sec is still a lot, don't think that my laptop needs that much time (it does wake up my dedicated gpu before going to sleep)
[09:16] <pitti> brainwash: that'll keep it alive for 10 minutes
[09:17] <brainwash> under real conditions or simulated?
[09:17] <brainwash> well, I try both and report back
[09:17] <pitti> brainwash: shouldn't matter
[09:18] <pitti> brainwash: i. e. if you have "pidof systemd-shim" being empty right after resume (e. g. after your logind d-bus call), it would explain that
[09:18] <pitti> or "could" rather (I'm not that familiar with the shim, desrt would know much better)
[09:19] <brainwash> systemd-shim is still there after resume, see my old log https://launchpadlibrarian.net/155226906/systemd-shim-debug.log
[09:20] <pitti> brainwash: ok, so probably not that then :/
[09:21] <brainwash> oh well, the timeout might have occurred after the resume, can't tell from that log I guess
[09:31] <tseliot> pitti: do we still support lpia as an arch?
[09:32] <pitti> tseliot: no, that got dropped afer lucid I believe
[09:32] <tseliot> pitti: ok, thanks, it's probably time to clean up my nvidia packages then ;)
[09:32] <ogra_> lol
[09:36] <brainwash> pitti: did some simulated runs, it seems to work, if there is a delay of 10/15/20sec, but failed twice with 30sec (logind not in prepare for sleep mode anymore, but network down)
[09:38] <brainwash> pitti: do you intend to upload a patched systemd-shim somewhere, so more people can test it?
[09:39] <pitti> brainwash: so your https://launchpadlibrarian.net/155226775/dbus-monitor-system.log log definitively shows the missing PrepareForSleep False; but you say it's probably not due to the shim timing out?
[09:40] <pitti> brainwash: oh, so the longer delay fixes the PrepareForSleep False signal?
[09:40] <pitti> brainwash: NM is supposed to pick that up
[09:40] <pitti> brainwash: sure, I'll put that into a PPA and follow up to the bug report, let's collect some data on that
[09:41] <brainwash> pitti: it seems, that logind didn't get stuck anymore, but I only did a small of amount of test runs
[09:41] <pitti> merely increasing the timeout is not a final solution, but if that works I'll know what to discuss with desrt :)
[09:43] <pitti> brainwash: uploaded, I'll wait with the bug update until binaries are available
[09:43] <brainwash> but in my case the current 10sec timeout should be actually enough, so it's strange
[09:46] <brainwash> pitti: were you able to reproduce the issue with the current timeout value and some delay of 10+sec?
[09:47] <pitti> brainwash: not yet, was reading the bug report so fara
[09:53] <brainwash> pitti: oh, just realized that the user who removed the duplicate reports is telling people to test the upstream kernel
[09:54] <pitti> bogus, won't help
[09:54] <brainwash> what a mess
[09:54] <pitti> in fact, I thought I duplicated a kernel bug to the systemd-shim one this morning
[09:55] <brainwash> ok, I have to go now and will do some more testing later, cya :)
[09:56] <pitti> brainwash: thanks! cu (packages are building)
[09:56] <ogra_> http://devnull-as-a-service.com/
[09:56]  * ogra_ grins 
[09:57] <pitti> lol
[10:01] <xnox> pitti: my 32GB RAM desktop does take a while to suspend to a spinny disk. and it is flaky sometimes.
[10:07] <pitti> brainwash: PPA is ready, followed up to the bug, and marked two handfuls of bugs as duplicates (based on a search on "resume network")
[10:08] <ogra_> 32G ? why do you use disks at all ?
[10:08] <ogra_> :)
[10:08] <pitti> xnox: yeah, worth trying the PPA then if you can reproduce that
[10:08] <pitti> xnox: oh wait, suspend to *disk*; that's something else then, most probably
[10:08] <xnox> pitti: ack.
[10:10] <pitti> ogra_: in fact I do most stuff in /tmp these days (tmpfs), as my RAM (16 GB) is bigger than my system partition :)
[10:11] <ogra_> yeah, same here
[10:11] <pitti> running VMs or schroot builds is incredibly fast there, quite nice
[10:11] <ogra_> yup
[10:11] <pitti> these were the main reasons I got so much ram in the first place
[10:11] <ogra_> even doing native arm builds in a qemu VM  is faster thann doing it on real HW
[11:46] <brainwash> pitti: great job, but the first comment on your patched package does not look promising :/
[11:46] <pitti> darn
[11:47] <brainwash> maybe logind does not get stuck anymore, but there is still something odd about nm
[11:47] <brainwash> time to start my tests and do some monitoring
[11:48]  * zyga wonders how hard would it be to copy ubuntu CD image into ramdisk before really starting the installation process
[11:48] <zyga> (like knoppix used to do)
[11:48] <zyga> installing from CD is really noisy
[11:48] <pitti> wow, you actually use CDs for installation? (good that someone tests this!)
[11:49] <brainwash> TORAM?
[11:49] <brainwash> https://wiki.ubuntu.com/BootToRAM
[11:53] <zyga> pitti: yes
[11:54] <zyga> pitti: i'm reusing a very old dvd-rw that I bought years ago
[11:54] <davmor2> pitti:  I always do :D
[11:54] <zyga> pitti: usb creator is broken and I didn't want to dd stuff to random partitions (even though I know how to find the right one)
[11:55] <zyga> pitti: still, is it "easy" to do something like that?
[11:55] <zyga> pitti: I have no idea how knoppix did it
[11:56] <zyga> pitti: or how hard that is to do with a modern kernel
[11:56] <pitti> zyga: I suppose something like "cat /dev/cdrom > /dev/null" already should do it, and let the cache take care of the rest
[11:56] <zyga> pitti: that doesn't stop the CD from spinning very noisily
[11:56] <pitti> well, you need to read the data once..
[11:56] <zyga> pitti: but perhaps that + some way of slowing the cd speed
[11:56] <zyga> pitti: well sure, I'm not asking for miracles
[11:57] <zyga> pitti: it's just after thet initial process, the cd should be ejectable
[11:57] <pitti> zyga: sudo hdparm -E 10 or so?
[11:57] <pitti> (never tried that, though.. -ENOCDROM)
[11:57] <zyga> pitti: do you think that's doable in trusty installer? :-)
[11:57] <pitti> zyga: I'm not sure it actually helps
[11:57] <pitti> especially on older machines without much RAM the 800 MB or so wouldn't even fit
[11:58] <pitti> and I suppose we are talking about older machines here
[11:58] <pitti> zyga: but it's worth a try whether the hdparm helps
[11:58] <zyga> pitti: well, not really, knoppix hat some heuristic where it would do if if you had 1GB of ram
[11:58] <zyga> pitti: (and you could really eject the cd and use it for other things then, it was a major selling point for the live CD that allowes you to use your CD)
[11:59] <zyga> pitti: this is a core i7 with 18GB of ram, it's also 5 years old so I don't know
[11:59] <pitti> zyga: that could be done by cat'ing to a file in tmpfs (in initramfs) and loop-mounting that instead of /dev/cdrom
[12:00] <zyga> pitti: which source package should be hacked to get that behavior? initrfams stuff or something "after"?
[12:00] <pitti> but that really requires >= 1.5 GB of RAM then
[12:00] <zyga> pitti: sure, many machines have enough of memory and that could be a nice improvement
[12:00] <pitti> zyga: my first thought would be casper
[12:00] <pitti> I think that handles everything
[12:00] <zyga> ok
[12:03] <brainwash> pitti: several test runs with a 20sec delay, everything works nice, increasing the artificial delay to 30sec causes some trouble
[12:03] <pitti> brainwash: so maybe that hits a d-bus timeout somewhere (but standard d-bus timeout is 30 s)
[12:04] <brainwash> but 30sec.. that's an eternity
[12:06] <pitti> yeah, you can boot 4 times in that..
[12:06] <brainwash> maybe due to the clock jump after resume?
[12:07] <brainwash> this would be really odd
[12:09] <brainwash> well, lets wait for some more test results
[12:54] <pitti> brainwash: ooh, more promising now :)
[12:55] <brainwash> pitti: great, so a restart is required?
[12:55] <pitti> brainwash: not sure why that would be, the old shim ought to time out quickly
[13:00] <brainwash> pitti: I'll test your package later, because I cannot do several suspend/resume cycles right now to verify it actually works
[13:01] <brainwash> but it works in theory for me (fake suspend)
[13:03] <pitti> brainwash: great; many thanks for your investigations!
[13:09] <mlankhorst> @pilot in
[13:36] <brainwash> pitti: still not fixed, see the latest comments :/
[13:37] <brainwash> I guess the current fix only covers a small amount of cases
[13:55] <voldyman> is this the correct place to ask about appindicators ?
[13:56] <voldyman> where can i find the list of icons available, the sample code uses "indicator-messages"
[13:56] <ricotz> voldyman, maybe better in #ubuntu-unity
[14:05] <jamespage> infinity, any chance I could persuade you to SRU the fix for bug 1187722 to quantal and raring as well?
[16:02] <zyga> http://packages.ubuntu.com/search?keywords=firefox&searchon=names&suite=all&section=all
[16:02] <zyga> why does trusty have firefox 24 while saucy got 25?
[16:03] <cjwatson> security updates for all stables; wonder if we can copy that forward
[16:03] <cjwatson> looks like it's possible
[16:03] <cjwatson> chrisccoulson: want me to copy firefox from saucy-updates to trusty-proposed?
[16:04] <cjwatson> or are you already working on an independent update?
[16:04] <chrisccoulson> cjwatson, feel free to copy it across
[16:06] <cjwatson> chrisccoulson: done
[16:06] <chrisccoulson> cjwatson, thanks
[16:10] <tsdgeos> guys, trusty won't update anymore in my laptop http://paste.ubuntu.com/6330740/
[16:10] <tsdgeos> who to i tell?
[16:25] <Laney> http://paste.ubuntu.com/6330818/
[16:26] <Laney> zul: are you working on openstack uploads for trusty or can we copy those?
[16:27] <zul> Laney: feel free to copy over
[16:27] <Laney> ta
[16:27] <Laney> Riddell: kubuntu-docs too
[16:29] <cjwatson> tsdgeos: Do you know what version of that package last worked?  Should be possible to find it from /var/log/dpkg.log
[16:31] <Riddell> Laney: what about it?
[16:31] <Riddell> Laney: oh right, yeah please copy
[16:31] <tsdgeos> cjwatson: 1.34 worked
[16:33] <cjwatson> the only change to the i2kmon init script appears to be that it's now enabled by default
[16:33] <cjwatson> do you actually have the hardware that this package drives?
[16:33] <Laney> Riddell: rockin'
[16:34] <cjwatson> oh no, there's s/--exec/--startas/ too, but still
[16:37] <cjwatson> tsdgeos: I think your best bet is to disable it in /etc/default/i2kmon and file a bug; I'm not familiar enough with the implementation language here to debug why it's exiting non-zero
[16:38] <tsdgeos> cjwatson: no clue to be honest
[16:38] <tsdgeos> it just came out as a dependency from somehwere
[17:16] <infinity> jamespage: Could do, I was under the impression when it was brought up that we only care about the LTS and current devel.
[17:17] <infinity> jamespage: Is there actually a concern for (nearly EOL) releases here, or just people who want to build all releases in a PPA for no good reason except "because they can"?
[17:59] <TheMuso> xnox: Do you want me to go ahead and drop libasound2-plugins-extra now, or are you on it already?
[17:59] <xnox> TheMuso: I'm on it already.
[17:59] <TheMuso> xnox: Ok thanks.
[17:59] <xnox> TheMuso: just planning my moves.
[17:59] <TheMuso> np
[18:00] <TheMuso> Gotta love patent encumbered codecs.
[18:01] <mterry> didrocks, I added a new wiki section that I think you'll like: https://wiki.ubuntu.com/MIRTeam#Making_Life_Easier_for_Archive_Team_Members  :)
[18:25] <TheMuso> xnox: Oh I didn't expect you to split things out. I was only going to follow through given the demand...
[19:46] <roaksoax> hi all! I was wondering what to do with packages that come from debian that use systemd
[19:46] <dobey> sarnold: hi! i requested a review from you for https://code.launchpad.net/~dobey/tarmac/add-apparmor/+merge/193323 if you could take a few minutes to review it please. :)
[19:46] <roaksoax> like: --with=systemd
[19:48] <xnox> roaksoax: nothing.
[19:48] <roaksoax> xnox: cool!
[19:48] <xnox> roaksoax: it should be able to build correctly.
[19:48] <roaksoax> zul: 6^
[19:48] <roaksoax> zul: ^^
[19:48] <roaksoax> xnox: yeah it does, I was just wondering if we should be dropping it or just not care
[19:48] <zul> cool
[19:48] <roaksoax> xnox: zul's fault :P
[19:49] <xnox> zul: roaksoax: be careful though, sometimes together with systemd "enablement" dh_installinit calls are dropped, which may affect and not install upstart jobs.
[19:52] <roaksoax> xnox: ok cool thanks!
[20:20] <bkerensa> http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
[20:20] <bkerensa> getting epic big
[20:20] <bkerensa> 89 items
[20:20] <bkerensa> :D
[20:47] <brainwash> xnox: can you build a working ubuntu package for bug 1183580 please? I lack the knowledge to properly build it myself :/
[20:48] <brainwash> if no, which developer(s) should I notify instead?
[20:50] <xnox> brainwash: $ sudo apt-get install build-essential fakeroot dpkg-dev
[20:50] <xnox> brainwash: $ sudo apt-get build-dep librcc
[20:50] <xnox> brainwash: $ apt-get source -b librcc
[20:50] <xnox> should produce recompiled packages
[20:51] <xnox> which you will be able to install with $ dpkg -i *.deb
[20:51] <xnox> brainwash: please let me know if that fixes the problem for you.
[20:52] <brainwash> xnox: the package in the repository is broken, would rebuilding it without any change help at all?
[20:53] <xnox> brainwash: in weird cases, it can.
[20:53] <xnox> brainwash: if you can do above and verify that recompiled _one over_ package resolves the problem, then all is good and it will be a quick SRU. If it doesn't, then the bug in question is harder.
[20:54] <xnox> brainwash: it usually helps resolve crasher bugs, due to un-noticed ABI breakage.
[20:54] <brainwash> xnox: sure, I can try it, will report back later
[20:54] <brainwash> thanks :)
[21:13] <brainwash> xnox: no luck, my locally built package still segfaults :(
[21:14] <xnox> brainwash: then debian binaries might be tainted, as debian accepts binary uploads from maintainer =(
[21:15] <xnox> (or not-matching source)
[21:15] <xnox> or there is something odd about our toolchain.... =(
[21:16] <sarnold> dobey: looks great! thanks :D
[21:17] <brainwash> xnox: it just feels like this problem is not going to be fixed in saucy, the workaround isn't complicated (install debian library), but it feels wrong
[21:20] <hallyn_> mterry: so fwiw, I've bristled from the start at, in bug 1126513, a non-server-team-member saying that server team would maintain it :)
[21:20] <dobey> sarnold: thanks!
[21:21] <hallyn_> but all right.  fine.  i'll subscribe to the bugs
[21:21] <dobey> sarnold: about the /**/tarmac though; i was hoping to make it also work for people who are installing it from source in /usr/local, or who are running it directly from within the source tree, as well
[21:21] <mterry> hallyn_, well
[21:22] <mterry> hallyn_, that's why only a team member can subscribe a team
[21:22] <mterry> hallyn_, so if you guys don't want to maintain it, that's fine.  We either find a team that does or we don't have it in main
[21:22] <hallyn_> mterry: yeah, i just mean that in the boilerplate in the Description, he put down "server team will maintain"
[21:22] <mterry> hallyn_, yeah  :)  Sorry, I didn't look into his team memberships, I just assumed he knew of what he spoke  :)
[21:22] <hallyn_> I dunno.  I have no love for the spice-originated source.  but it's only for qemu, so we should.
[21:23] <hallyn_> mterry: hah, actually he's so fed up he's stopped using ubuntu.
[21:23] <dobey> sarnold: is there any good way to do that? as otherwise, running from source (which is common), would be unconfined still
[21:23] <hallyn_> he's upset that spice didn't get into main until raring.
[21:23] <mterry> hallyn_, ah yes, I saw that comment
[21:23] <mterry> hallyn_, normal rage-quit material  :)
[21:23] <hallyn_> all right - so i've subscribed, will comment to that effect, and let the MIR-completion magic happen
[21:24] <mterry> hallyn_, I mean, do we want this feature?
[21:24] <mterry> hallyn_, original requester rage-quit.  Do other people want it?
[21:24] <mterry> Apparently users will benefit, I'm just curious if we have someone driving this change
[21:25] <hallyn_> it's not a server feature.  we don't hook usb crap up to servers :)
[21:25] <sarnold> dobey: it'd be ugly, giving multiple attachment paths. might as well leave it alone then. :) thanks
[21:26] <hallyn_> mterry: but the bar to enabling it is so high (build your own qemu-kvm) that it's probably worthenabling it.
[21:26] <hallyn_> mterry: I'm only saying this bc the changelog shows so few updates that either the code is stable enough to just have it on, or noone is using it :)
[21:26] <mterry> hallyn_, often the latter  :)
[21:27] <sarnold> would the work to enable qemu-kvm to load it as "plugin" be too steep?
[21:27] <hallyn_> got me
[21:28] <mterry> hallyn_, so do we need to change qemu to enable support?
[21:28] <hallyn_> mterry: just debian/control
[21:33] <mterry> hallyn_, we prefer team bug subscribers, so if you get hit by a bus, we still have someone looking at usbredir -- after a suitable mourning period :)
[21:34] <hallyn_> you know we sometimes travel as a team
[21:34] <hallyn_> lemme see how if i can do that
[21:35] <hallyn_> jamespage: ^ do you know how to subscribe the server team to usbredir bugs?
[21:35] <hallyn_> though i'm wondering about sarnold's suggestion.
[21:35] <Laney> it needs to be an administrator
[21:36] <Laney> Do you mean ubuntu-server-dev? I can do that if so
[21:38] <Laney> hallyn_: ↑
[21:40] <hallyn_> Laney: yeah i think that's what i mean
[21:40]  * hallyn_ checks
[21:41] <hallyn_> yup
[21:44] <Laney> doing
[21:44] <Laney> done
[21:46] <hallyn_> Laney: thanks
[21:46] <Laney> kein problem
[21:49] <mterry> hallyn_: which sarnold suggestion?
[21:49] <sarnold> modify qemu-kvm to load usbredir as a plugin if it is available, rather than require build-time linking
[21:51] <mterry> sarnold, ah neat.  That way we don't need usbredir in main indeed
[21:54] <hallyn_> won't be particularly easy though, near as i can tell
[21:56] <sarnold> aww. thanks for looking into it. (I didn't particularly like the feeling that usbredir drastically decreased the value of VM-based isolation..)
[21:57] <mterry> sarnold, hallyn_: no one seems excited about usbredir...  :)
[21:58] <sarnold> mterry: yeah. I can appreciate the desire for the feature, though.
[21:58] <mterry> Well, if the plugin way is unlikely to get done, I guess we can promote
[22:00] <sarnold> up to the server team if they want to maintain it :) hehe
[22:00] <hallyn_> i wonder whether rharper has any comments ont he feasability of making it a plugin
[22:01]  * mterry looks at rharper
[22:19] <TheMuso> Oh wow, and I thought we had gotten rid of dpatch...
[22:19] <TheMuso> At least not with universe packages...
[23:00] <rharper> hallyn_:  mterry : re plugins for qemu; it's been discussed on the list quite a lot and the maintainers always nack it;   If a feature is good enough to be maintained, than it can be compiled in and supported by the distro
[23:02] <hallyn_> rharper: thanks.  sounds like a no then :)
[23:02] <hallyn_> sarnold: ^
[23:03] <sarnold> hallyn_: bugger. the reasoning even makes some kind of sense. hehe. :)
[23:07] <hallyn_> sarnold: it's the inverse of our reasoning :)
[23:07] <sarnold> hallyn_: yes! bah. :)
[23:09] <hallyn_> maybe i'll spend tomorow looking at libpam-mount bugs
[23:09] <hallyn_> for great glory
[23:09] <hallyn_> anyway, i'm off - gnight