=== charles_ is now known as charles
=== freeflying is now known as freeflying_away
=== _salem is now known as salem_
=== salem_ is now known as _salem
[03:39] <pitti> Good yawning
[03:40] <stgraber> hey pitti (probably a sign I should stop working soonish ;))
[03:40] <pitti> hey stgraber, ça va ?
[03:41] <stgraber> pitti: bien et toi ?
[03:41] <pitti> stgraber: un peu fatigué, mais bien, merci !
[04:31] <RAOF> pitti: Good morning!
[04:31] <pitti> hey RAOF, how are you?
[04:32] <RAOF> I'm pretty good, yourself?
=== freeflying_away is now known as freeflying
[04:35] <RAOF> pitti: Feel like doing a colord upload from git?
[04:35] <pitti> RAOF: can do
[04:36] <pitti> RAOF: any hope this will fix https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/?
[04:36] <RAOF> Oh, *that's* what I forgot!
[04:36] <RAOF> So, maybe :)
[04:38]  * RAOF checks
[04:55] <RAOF> Bah. Stupid run-adt-test wanting an ubuntu-distro-info update that doesn't exist!
[04:58] <pitti> RAOF: that was fixed in September already..
[04:58] <pitti> revno: 232
[04:58] <pitti>   Install distro-info during initial provisioning
[04:58] <RAOF> “Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details” wasn't.
[04:58] <pitti> RAOF: ah, I think you can ignore that
[04:59] <RAOF> Except that it appears to be a fatal error for run-adt-test :)
[04:59] <RAOF> But I can work around it by extending Saucy's lifespan into November ☺
[04:59] <pitti> hm, I never ran into that
[05:00] <sarnold> seen roughly six hours ago... < cjwa tson> It's "distro-info-data is broken" day
[05:01] <pitti> oh, because there is no development series
[05:03] <RAOF> Indeed
[05:04] <stgraber> we just need to make distro-info send an e-mail to Mark asking for the new dev release name every time someone runs it, that may make things move faster ;)
[05:05] <pitti> RAOF: built fine in sbuild; ok to upload? (I guess you don't want to un/re-tag that upload anyway, but would be nice to fix the autopkgtest at some point)
[05:06] <RAOF> pitti: I don't mind blocking the upload on working out precisely why the test is broken.
[05:06] <RAOF> It's not urgent.
[05:06] <pitti> RAOF: ok
=== freeflying is now known as freeflying_away
[06:03] <RAOF> pitti: Hm. I think the particular adt failure is fixed, to be replaced by a new and exciting test failure!
[06:04] <sirblubber> exit
[06:10]  * hyperair wonders if it's an intentional design decision to have zero spacing between the icon and the text in appindicators.
[06:11] <hyperair> which looks even better when the icons are not of the same width.
[06:13] <RAOF> Grargh.
[06:13] <RAOF> Stupid libtool stupid stupid stupid waaarghl.
[06:15] <StevenK> RAOF: Tautology
[07:17] <RAOF> pitti: Bah. I might just disable the tests :/
[07:20] <mlankhorst> hahha
[07:20] <pitti> slangasek: oh, still awake? must be release day..
[07:20] <pitti> slangasek: or are you in London?
=== tkamppeter_ is now known as tkamppeter
=== pete-woods is now known as pete-woods-brb
=== ac is now known as Guest17711
[09:44]  * tumbleweed grumbles at distro-info
[09:44] <tumbleweed> I wonder if we'll ever get a release name in advance of release, again
[09:46] <tjaalton> meh, a local news site jumped the gun on the release..
[09:47] <smartboyhw> tjaalton, which one?
[09:47] <smartboyhw> (Can't these news sites be a bit patient?)
[09:48] <tjaalton> smartboyhw: http://www.tietokone.fi/artikkeli/uutiset/ubuntun_uusi_versio_julkaistiin
[09:48] <Laney> Wouldn't worry about it, happens every time
[09:48] <tjaalton> hmm actually the headline is in past tense ("was released"), and the subtitle says "will be released today"
[09:49] <smartboyhw> Nice grammar
[09:49] <tjaalton> you bet :)
=== pete-woods-brb is now known as pete-woods
[10:23] <mlankhorst> can someone accept mesa-lts-raring to precise-proposed
[10:23] <mlankhorst> and then the binaries again after that?
[10:44] <lifeless> slangasek: heh - are you really still working on https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/864466 ?
[10:44] <ubottu> Ubuntu bug 864466 in kbd (Ubuntu) "break=foo boot option incompatible with gfxpayload=keep" [Medium,Triaged]
=== MacSlow is now known as MacSlow|lunch
[11:14] <mlankhorst> hm distro_info complains about being outdated :(
[11:14] <Laney> yeah :(
[11:21] <xnox> mlankhorst: file a bug and assign to sabdfl ?! =)
[11:21] <mlankhorst> well I guess we need to know the new series first :P
[11:22] <Saviq> pitti, ping
[11:22] <pitti> hello Saviq
[11:23] <cjwatson> mlankhorst: we've set silbs on the problem
[11:23] <Saviq> pitti, hey, Q: since we can't send bug reports to LP from apport, how do I know it's actually sent et all?
[11:23] <Saviq> pitti, for a 32MB report of Banhsee, it exits straight away after pressing S
[11:24] <pitti> Saviq: they are (supposed to be) uploaded in the background; you should eventually get an .uploaded stamp in /var/crash/
[11:24] <pitti> Saviq: pressing S will just generate the .upload stamp, which whoopsie should pick up
[11:24] <Saviq> pitti, aah, so it needs to be there in /var/crash - if I retraced, need to put it there anyway
[11:24] <Saviq> pitti, got it
[11:25] <pitti> Saviq: (as I said, you can also comment out the problem_types line in /etc/apport/crashdb.conf to send it to apport, but you don't want that on the phone anyway)
[11:25] <Saviq> pitti, yeah this one's from the desktop, but yeah, thanks
[11:25] <pitti> Saviq: whoopsie doesn't do anything with the retraced result
[11:25] <pitti> so that won't help
[11:25] <Saviq> pitti, ah ok, so I just need to send the raw crash then :)
[11:26] <pitti> Saviq: local retracing is mostly for your own benefit, not for error.u.c./LP
[11:27] <Saviq> pitti, yeah
=== freeflying_away is now known as freeflying
[11:39] <YokoZar> http://i.imgur.com/FC5VM2S.png
=== MacSlow|lunch is now known as MacSlow
[12:04] <ion> :-D
[12:45] <smoser> worlds most annoying bug
[12:46] <smoser> chromium alerts me to something in the middle of the night. its dialog window goes beind some other window i have.
[12:46] <smoser> no way to find it.
[12:46] <smoser> clicking on the launcher chromium just brings the primary window forward
[12:53] <StevenK> smoser: Alt-` ?
[12:56] <smoser> StevenK, i guess the other part i didn't mention was the dialog goes on a different desktop
[12:56] <smoser> (ie, i left the machine on a different desktop at night, so the dialog popped up there)
[13:07] <smoser> so what would i open that bug on ? it reproduces with other non-chromium things. anything with a dialog.
[13:08] <smoser> is that unity or compiz
=== pete-woods is now known as pete-woods-brb
=== cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[13:16] <Saviq> hyperair, ping
[13:16] <hyperair> Saviq: pong
[13:16] <Saviq> hyperair, hey, wanted to ask if I could help you somehow in getting banshee 2.9.0 packaged?
[13:17] <hyperair> Saviq: eh well, i'm waiting for a dependency to pass throguh NEW
[13:17] <Saviq> hyperair, ah, so probably not on release day :D
[13:17] <hyperair> :)
[13:18] <Saviq> hyperair, got a branch I could build locally?
[13:18] <hyperair> Saviq: nope
[13:18] <hyperair> Saviq: there are quite some changes in 2.9.0
[13:18] <Saviq> hyperair, yeah I saw that
[13:18] <hyperair> a lot of build-deps are changing
[13:18] <hyperair> stuff moving to gtk3
[13:19] <Saviq> hyperair, interesting all (save one) distro patches apply cleanly :D
[13:19] <hyperair> oh that's nice
[13:19] <Saviq> or with some offsets at most
[13:19] <hyperair> configure flags will need fixing, build-deps will need tweaking..
[13:20] <Saviq> hyperair, and what's the dep that's NEWing/
[13:20] <Saviq> ?
[13:20] <hyperair> gudev-sharp
[13:22] <Saviq> hyperair, k thanks, feel free to ping me if you need help with it
[13:24] <hyperair> sure
[13:30] <smoser> anyone able to triage https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1240977
[13:30] <ubottu> Ubuntu bug 1240977 in unity (Ubuntu) "some modal dialog windows such as chromium-browser get stuck/lost/do not raise if on different desktop" [Undecided,New]
[13:30] <smoser> i'm not even sure if that is the right package.
[13:40] <ChrisTownsend> smoser: One of us on the Unity team will take a stab first
[13:56] <pitti> infinity: congrats!
[13:57] <infinity> pitti: Thanks, I did it all by myself.
[13:57] <pitti> infinity: and will receive all the blame, too!
[13:58] <infinity> pitti: well, all the VAC bounces, anyway. :)
[13:58] <seb128> is t open yet?! :p
[13:58] <knocte> hyperair: speaking of 2.9.0, have you tested it with the mono that ubuntu 13.10 bundles? it crashes for me
[13:58] <Laney> Onwards to Turgid Teletubby
[13:59] <hyperair> knocte: er. nope, haven't tested 2.9.0 art all.
[13:59] <hyperair> at*
[13:59] <hyperair> knocte: but the last git version before gtk3 works
[13:59] <hyperair> (the one in banshee-daily)
[13:59] <knocte> I see
[14:00] <knocte> well, I'm going to test with mono 3.2.1 now from directhex PPA
[14:00] <pitti> seb128: telephatic tortoise
[14:00] <knocte> I think it will fix it
[14:00] <hyperair> okay
[14:00] <pitti> away with hud, keyboard, touch, and mouse -- it will just read your mind
[14:00] <barry> twerking turkey
[14:00] <knocte> hyperair: if that's the case, maybe the daily ppa should depend on mono 3.2.1? can ppas depend on other ppas?
[14:01] <hyperair> knocte: yes they can
[14:01] <hyperair> knocte: but why?
[14:01] <seb128> pitti, turbulent turkey you mean?
[14:02] <hyperair> knocte: doesmono 3.2.1 not work?
[14:02] <barry> tangy toucan
[14:02] <knocte> hyperair: the other way around, I'm saying banshee 2.9.0 crashes for me with mono 2.10.x (the one that ubuntu has by default)
[14:02] <hyperair> oh
[14:02] <tumbleweed> surely tranquil for an LTS?
[14:02] <hyperair> well try it and see, i guess
[14:02] <hyperair> knocte: the problem is upgrading mono typically means upgrading the world
[14:02] <directhex> hyperair, (banshee breaks on sgen on amd64)
[14:03] <knocte> I know :(
[14:03] <hyperair> knocte: i don't want to force such invasive changes for one app.
[14:03] <knocte> directhex: I wasn't talking about that crash
[14:03] <hyperair> (if possible)
[14:03] <hyperair> directhex: what's sgen?
[14:03] <directhex> the new default GC which was previously optional
[14:03] <hyperair> bleh
[14:04] <hyperair> is that a mono bug or a banshee bug?
[14:04] <knocte> mono bug, but there's a patch for that which already fixes it
[14:04] <knocte> cherrypicked from master
[14:04] <knocte> but I wasn't talking about that crash at all now
[14:04] <hyperair> oh
[14:04] <hyperair> so there's another bug?
[14:04] <knocte> I'm talking about mono 2.10.x crashing
[14:05] <directhex> knocte, stack trace on paste.ubuntu.com ?
[14:07] <knocte> directhex: unmanaged stacktrace for now, not very useful before I install debug symbols: http://paste.ubuntu.com/6251188/
[14:08] <directhex> that's new and exciting
[14:08] <knocte> the weird thing is that it doesn't happen with ubuntu 13.04 (which ships the same mono AFAIU)
[14:08] <knocte> at least that's what Bertrand runs I think
=== doko_ is now known as doko
[14:20] <knocte> directhex: http://paste.ubuntu.com/6251236/ your ppa doesn't work with saucy right?
[14:21] <directhex> knocte, add the raring repo, it should work the same on saucy
[14:21] <knocte> ok thanks
=== pete-woods-brb is now known as pete-woods
[15:11] <slangasek> lifeless: heh... no, not working on that one :/
[15:29] <seb128> Laney, ara: hum, I wonder if there is an issue with https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.12
[15:30] <seb128> the most frequent issues on e.u.c are segfaults in g-c-c networks's panel and e.u.c seems to indicate it started with that version
[15:30] <seb128> though the diff is a bit weird as a cause of the stracktraces
[15:30] <seb128> e.g
[15:30] <seb128> https://errors.ubuntu.com/problem/7fe3809ac4806e554174f3ea41f1f31656f91a3a
[15:31] <seb128> well, it didn't start with that version, but it was very unfrequent before
[15:32] <ara> oops
[15:37] <Laney> hmm
[15:41] <slangasek> pitti: so, you think this code is too ugly to be enabled on !arm?
[15:42] <pitti> slangasek: we don't need it on !arm, and we'd just make the filter chain unnecessarily slower
[15:42] <Laney> seb128: yeah it's probably caused by this
[15:42] <seb128> Laney, :-(
[15:42] <seb128> Laney, do you see the bug in the patch?
[15:42] <Laney> not immediately
[15:42] <pitti> slangasek: also, I wanted to make as un-invasive as possible for an SRU
[15:42] <pitti> slangasek: sorry, need to run now; TTYT?
[15:43] <slangasek> pitti: ok.  fwiw I'd be more comfortable with it as an SRU if it were being applied consistently across architectures
[15:43] <slangasek> I don't like arch-specific code paths
[15:43] <seb128> Laney, do you want to have a look or should I follow up via email with the certification team/the guys who worked on the backport?
[15:43] <pitti> slangasek: well, it's a signle-platform specific hack anyway, and while the overhead might not be that big it's certainly there
[15:43] <slangasek> so I wonder what the actual overhead is of the filtering :)
[15:43] <Laney> seb128: I'll look quickly but I can't verify it because I don't have precise/wifi to test flight mode
[15:44] <pitti> slangasek: it's "no filter chain at all" vs. "having that filter chain" (i. e. not jsut three more commands)
[15:44]  * pitti really off now, sorry
[15:46] <bdmurray> seb128: could you or someone have a look at bug 1239226?
[15:46] <ubottu> bug 1239226 in Ubuntu "battery suspend interval applies even when plugged in" [Undecided,New] https://launchpad.net/bugs/1239226
=== freeflying is now known as freeflying_away
[15:46] <seb128> bdmurray, seems like the bug Laney fixed in https://launchpad.net/ubuntu/+source/upower/0.9.22-1ubuntu1
[15:47] <seb128> bdmurray, I've asked on the bug if that's still an issue
[15:50] <bdmurray> seb128: thanks, I'd see it to and am rebooting to test again.
[15:50] <seb128> bdmurray, thanks
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
=== dpm is now known as dpm-afk
[16:29] <Saviq> kirkland, hey, is it possible that bug #878547 is back in byobu 5.17 (precise)?
[16:29] <ubottu> bug 878547 in byobu "starts "apt-get -s upgrade" everytime it starts, but doesn't stop them when it exits" [Medium,Fix released] https://launchpad.net/bugs/878547
[16:31] <kirkland> Saviq: hmm, the fix to that bug did land in precise, so if you're still seeing, it's probably another bug
[16:32] <Saviq> kirkland, I was definitely having a bunch of apt-gets hogging my machine - and it seems to have stopped after disabling byobu - if I confirm I'll file a new one
[16:36] <seb128> would be great if e.u.c was waiving a flag when a new bug jumps out, especially after a SRU in the lts
[16:37] <seb128> (e.g that -
[16:37] <seb128> (e.g that g-c-c segfault that was recently added in a sru)
[16:37] <seb128> is that on some roadmap from someone?
[16:37] <seb128> ev: ^?
[16:38] <Laney> more bdmurray's turf I'd say
[16:38] <Laney> We have the phased update stuff, it'd be similar-ish to that without the client side bits
[16:41] <bdmurray> seb128: what bug?
[16:42] <seb128> bdmurray, the one Laney just uploaded a SRU for,  https://errors.ubuntu.com/problem/7fe3809ac4806e554174f3ea41f1f31656f91a3a
[16:44] <bdmurray> phased-updates would have caught that, the support just doesn't fully exist in precise
=== _salem is now known as salem_
=== salem_ is now known as _salem
[19:19] <smoser> $ ubuntu-distro-info --devel
[19:19] <smoser> ubuntu-distro-info: Distribution data outdated.
[19:21] <ScottK> smoser: That happens whenever there is no devel release.
[19:22] <smoser> i know why :)
[19:22] <smoser> was wondering if there was going to be a 'T' soon. or if i just missed it.
[19:25] <ScottK> First sabdfl has to pick a name.
[19:25] <ScottK> AFAIK, he hasn't.
[19:25] <lifeless> congrats on the release
[19:26] <lifeless> I'm plumbing for Taunting Tortoise
[19:26] <smoser> plumbing ?
[19:26] <lifeless> bah
[19:26]  * smoser thinks of lifeless playing super mario
[19:26] <lifeless> plumping
[19:27] <Dayofswords> I wanted R to be Radiant Robin....
[19:28] <sarnold> I think Reliant Robin was a missed opportunity..
[19:28] <mwhudson> teratogenic texan!
[19:28] <sarnold> Maybe Turbo Trabant could make up for it.. a bit..
[19:36] <noskcaj> kirkland, roaksoax: Have either of you got time to help with testdrive now? A new Vbox release is out, i have a merge waiting, plus danChapman and i both have attempts at porting to gtk3 that need finishing.
[19:45] <xnox> cjwatson: infinity: bdrung_: ScottK: smoser: i fixed ubuntu-distro-info and pull-lp-source: https://code.launchpad.net/~xnox/ubuntu-dev-tools/fix-series-alias-lookups/+merge/191700 and http://paste.ubuntu.com/6252891/
[19:46] <xnox> the correct answer is "devel"
[19:47] <slangasek> xnox: erm, cjwatson had specific reasons for not doing that, else it would've been done much sooner; who says this is "correct"?
[19:47] <xnox> slangasek: i'd like to hear those reasons.
[19:49] <xnox> slangasek: it did seem "correct" to cjwatson/apw/infinity and I in the pub couple of hours ago =)
[19:50] <slangasek> xnox: hum, ok then
[19:50] <slangasek> I remembered cjwatson having objections :)
[19:50] <xnox> slangasek: well, it's not like there is any point to upload distro-info without new codename and cjwatson will be around to comment before that happens.
[19:51] <xnox> cjwatson: what's wrong with adding a timeless "devel" entry to ubuntu.csv?
[19:51] <slangasek> xnox: ack
[19:51] <slangasek> xnox: oh right, so there's nothing wrong with adding it as an option, but there was a reason we didn't want it to be the default
[19:52] <seb128> slangasek, hey, I was reading https://launchpad.net/ubuntu/+source/ubuntu-touch-session/0.81 ... do we have anything on the desktop supposed to "clean up pulseaudio on exit"?
[19:52] <seb128> slangasek, I'm asking because I've issues where
[19:52] <seb128> $ loginctl user-status ubuntu
[19:53] <seb128>                   ├─c22.session
[19:53] <seb128>                   │ ├─4322 /usr/bin/pulseaudio --start --log-target=syslog
[19:53] <seb128>                   │ ├─4395 /usr/lib/pulseaudio/pulse/gconf-helper
[19:53] <seb128>  
[19:53] <xnox> slangasek: oh i see, at the  moment "devel" ends up in "supported" =(
[19:53] <xnox> slangasek: which is clearly wrong.
[19:53] <seb128> slangasek, which makes lightdm/indicator-session show the "ubuntu" user as logged in when it's not
=== tvoss is now known as tvoss|eod
[19:54] <slangasek> seb128: upstart should reap all of its children on exit, and this *was* working earlier in the cycle
[19:55] <seb128> slangasek, well, I've also some indicator processes still running, those are not upstart managed, so maybe that's what is keeping pulseaudio active there
[19:56] <xnox> slangasek: hm, but even with "$ faketime 2013-10-10 ubuntu-distro-info --supported" shows saucy as "supported".
[19:56] <xnox> slangasek: i guess "supported" means stable+devel.
[19:56] <slangasek> well, all the processes should have been children of upstart, which I would expect to reap all its children on exit, not just the ones directly related to jobs. hmm.
[19:57] <xnox> slangasek: does our fast showdown/exit do this
[20:02] <slangasek> xnox: what do you mean?
[20:02] <xnox> slangasek: well the code fixes for "10s delay on logout"
[20:03] <slangasek> xnox: which I think have not landed yet, right?
[20:03] <xnox> i'm not sure i've seen it go into the path of reap all its children on exit.
[20:03] <slangasek> I may have just been assuming this based on the behavior I'd seen
[20:03] <xnox> slangasek: oh, right, it didn't. I thought it did....
[20:03] <slangasek> I know that before we switched to user sessions, pulseaudio would leave processes around all the time
[20:04] <slangasek> and when user sessions went live, this problem went away
[20:04] <slangasek> but maybe it's come back again.
[20:05] <slangasek> how do we launch pulseaudio, if not as a user job? .desktop?
[20:06] <xnox> slangasek: i don't see a user job, there is a system job.
[20:07] <xnox> slangasek: there is xdg-autostart .desktop file which calls the /usr/bin/start-pulseaudio-x11
[20:07] <xnox> which is an interesting shell script...
[20:08] <slangasek> yeah, but that script doesn't actually start the daemon
[20:08] <slangasek> except as a side-effect
[20:13] <slangasek> xnox: so pulseaudio is started ad-hoc on the desktop, and calls setsid(); which means signals don't propagate automatically to it, and I'm not sure session init even has a sane way to know it's there
[20:14] <stgraber> I tried making it a user job initially then gave up
[20:15] <stgraber> we'd need to override the pulseaudio dbus activation and then make it a user job. Or we possibly could ship a job that does nothing but has a post-stop which sends a kill signal to pulseaudio through pactl
[20:18] <robert_ancell> beuno, hey, is there anything else holding up my click apps in developer.ubuntu.com?
[20:19] <slangasek> stgraber: it seems to be a user job on the phone right now, fwiw... though the job is broken and is in state 'stop/waiting' because of a wrong expect rule
[20:21] <stgraber> hmm, not sure how that's not racy then, unless the way dbus works on the phone makes dbus activation impossible?
[20:22] <seb128> stgraber, slangasek: can we get upstart to do dbus activation?
[20:23] <slangasek> seb128: er, we had patches in the dbus package to do this, and those patches were dropped
[20:24] <seb128> slangasek, yeah, that's unfortunate, we got stucked with "no dbus maintainer, nobody knowing enough the code to update them"
[20:24] <slangasek> yes, and yet someone updated the package and dropped the patches
[20:24] <seb128> right, because it was either that or not updating dbus
[20:24] <slangasek> instead of leaving the package as-is until somebody could move it forward
[20:24] <seb128> iirc
[20:24] <seb128> well, leaving things behind has issues as well
[20:25] <xnox> slangasek: pkill -u $uid is a good call =)
[20:25] <xnox> slangasek: or making logind rip kill processes...
[20:26] <seb128> slangasek, but yeah, I don't disagree with you, it's just where we stand today :/
[20:26] <stgraber> xnox: I like my LXC containers and screen sessions, so no thanks :)
[20:28] <xnox> stgraber: if uid not in ['stgraber', 'hallyn', 'ubuntu']:
[20:29] <slangasek> xnox: not so much :P
[20:29] <seb128> xnox, seems you need to add slangasek to that list ... ;-)
[20:30]  * hallyn tries to make sense of backlog
[20:31] <slangasek> hallyn: xnox is trolling everyone who wants reliable systems
[20:31] <seb128> hallyn, we are speaking about user processes still running after session closing
[20:32] <stgraber> xnox: if lp.people[uid] not in lp.people['ubuntu-dev'].participants
[20:32] <hallyn> if i wanted reliable systems, woudl i have just bricked my arm laptop with non-working kernel?  I DON'T THINK SO
[20:34] <hallyn> we could do liek the cool systemd kids and use a cgroup :)
[20:35] <stgraber> no, the cool systemd way is precisely the problem :)
[20:35] <hallyn> (containers jumping into another cgroup)
[20:35] <stgraber> yeah, would work for containers
[20:35] <hallyn> stgraber: i was pretty sure that was the case :)
[20:35] <hallyn> (saw logind mentioned)
[20:35] <stgraber> not for screen/byobu :)
[20:35] <stgraber> so start a screen session, logout, it's gone, doesn't seem ideal ;)
[20:35] <stgraber> (and giving privileges to byobu/screen to change cgroups seems a bit hackish ;))
[20:36] <ccope> hey hallyn, what held up setting CONFIG_USER_NS=y in the 13.10 kernel?
[20:37] <ccope> i thought the last blocker were some xfs changes, which i thought got merged...
[20:37] <hallyn> ccope: not in 13.10
[20:37] <hallyn> they'r ein 13.11
[20:37] <hallyn> but also,
[20:37] <hallyn> there's an issue being worked on with overmounted directories not being deleteable by root
[20:38] <hallyn> used to be no big deal as only root could overmount.  but now that anyone can do so, it's a problem
[20:40] <ccope> ah. is the 13.11 milestone targeting a 14.04 release, or an update to 13.10, or something else?
[20:41] <ccope> nvm, i see it is for 14.04
[20:42] <kirkland> stgraber: what's this about byobu and cgroups?
[20:43] <stgraber> kirkland: tmux/screen/whatever stays in the background get killed on systems using logind with cgroups (so not Ubuntu) when the user logout from the graphical session
[20:43] <slangasek> kirkland: it's really a screen issue rather than a byobu one; but basically, reiterating that the cgroups model of managing desktop sessions is flawed
[20:43] <kirkland> stgraber: well, that's not how things are supposed to work :-)
[20:44] <kirkland> slangasek: ah, okay
[20:45] <slangasek> "we don't want to use process groups for managing sessions, because things can escape them by calling setpgrp() and then we don't clean up the session properly" "so let's use cgroups instead, so that processes can't escape!" "hey guys, there are processes that actually need to escape and you've broken the existing interfaces for doing that"
[20:46] <hallyn> slangasek: and then the answer is that you can escape cgroups anyway if you need to.  which means pgroups were just fine.  yes, i've argued that about 5 years ago iirc
[20:47] <stgraber> hallyn: the way logind works, you can't escape them, well, unless you happen to own a cgroup directory somewhere else in the hierarchy
[20:47] <hallyn> or you're root...
[20:48] <slangasek> right
[22:01] <bdmurray> slangasek: could you have a look at the upgrade failure in bug 1241120 with me?
[22:01] <ubottu> bug 1241120 in ubuntu-release-upgrader (Ubuntu) "Unable to update to 13.10" [Undecided,New] https://launchpad.net/bugs/1241120
[22:03] <Logan_> How should I version an SRU if I want it to be pushed up to t-series as well? And are SRUs being accepted right now for saucy?
[22:05] <hallyn> stgraber: i don't understand the libvirt 0.9.8-2ubuntu17.15 rejection - libvirt 0.9.8-2ubuntu17.14 failed to build, .15 includes the bugs for .14 (which it fixes), but there's no explicity bug for the FTBFSs
[22:06] <hallyn> anyway nonworking internet has me hulkified.  going outside for a bit
[22:12] <Logan_> ScottK? Could I rudely bother you for an answer to my question above? :P
[22:13] <ScottK> Logan_: SRUs are being accepted.  Just use regular SRU versioning.  As of now, the archive hasn't been copied to "T", so whatever gets in will automatically end up there.
[22:13] <Logan_> Awesome. Thanks!
[22:15] <slangasek> bdmurray: looking
[22:18] <slangasek> bdmurray: so can you reproduce it with the apt-clone state?
[22:19] <bdmurray> slangasek: I haven't tried that.  Do you know of a good way to test the apt clone files?
[22:19] <slangasek> bdmurray: hum, there's supposed to be "some" way to do it, but I don't know the details - I thought you might :-)
[22:20] <bdmurray> slangasek: I should probably sort that out then.
[22:22] <bdmurray> stgraber: did you have a good way for testing release upgrades?
[22:30] <slangasek> bdmurray: apt-clone itself has a 'restore' option, with a --destination flag; not sure if that tries to install all the packages or if it just restores the metadata
[22:30] <bdmurray> slangasek: it tries to install the packages from whatever mirror is listed in sources too
[22:31] <slangasek> ok, so maybe the fast path is to just unpack the tarball and point apt at it for upgrading
[22:41] <slangasek> bdmurray: d=/tmp/1241120; sed -i -e's/raring/saucy/g' $d/etc/apt/sources.list; rm -f $d/etc/apt/sources.list.d/*.list; mkdir -p $d/var/lib/dpkg $d/var/cache/apt ; cp $d/var/lib/apt-clone/dpkg-status $d/var/lib/dpkg/status; apt-get -oDir::State::status="$d/var/lib/dpkg/status" -oDir::State="$d/var/lib/apt" -oDir::Cache="$d/var/cache/apt/" -oDir::Etc="$d/etc/apt/" update; sudo apt-get -oDir::State::status="$d/var/lib/dpkg/status" ...
[22:42] <slangasek> ... -oDir::State="$d/var/lib/apt" -oDir::Cache="$d/var/cache/apt/" -oDir::Etc="$d/etc/apt/" dist-upgrade
[22:42] <slangasek> seems like something we ought to encapsulate in a nice little helper script
[22:44] <slangasek> unfortunately we can't just use -oRootDir because apt assumes that means it can find its binaries under that tree too
[22:46] <slangasek> also, that fails miserably if using apt configured for amd64 on an i386 apt-clone ;)
[22:48] <slangasek> bdmurray: in any case, that doesn't reproduce the reported problem
[22:48] <bdmurray> bug 1241123 is similar and on amd64
[22:48] <ubottu> bug 1241123 in ubuntu-release-upgrader (Ubuntu) "upgrade to saucy fails while calculating upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/1241123
[22:49] <bdmurray> however it looks like they have some package versions no longer available
[22:49] <bdmurray>  xserver-xorg-video-intel  <2:2.21.6-0ubuntu4.1>   <2:2.21.6-0ubuntu4.3>
[22:51] <slangasek> mm? 2:2.21.6-0ubuntu4.1 seems to be the raring-updates version
[22:52] <bdmurray> I think 4.3 is current
[22:52] <slangasek> not according to rmadison
[22:52] <slangasek> -4.3 is only listed in raring-proposed
[22:53] <bdmurray> oh, maybe its phasing
[22:54] <slangasek> ah, rmadison is 6 hours out of date, interesting
[23:02] <slangasek> bdmurray: tried with the other (amd64) one, can't reproduce the problem there either using apt-get dist-upgrade; maybe we need to simulate the upgrade with ubuntu-release-upgrader itself to reproduce the problem
[23:03] <bdmurray> Did you look at the problem resolver log?
[23:03] <slangasek> yeah
[23:04] <bdmurray> I'm working on using apt-clone restore on an i386 lxc container at the moment
[23:04] <slangasek> it gets in a loop w/ gdm/libgdm/gnome-shell, but I don't see any root cause for this
[23:05] <bdmurray> what would I look for if I get this test system squared away?
[23:06] <slangasek> bdmurray: I do see in https://launchpadlibrarian.net/154017777/VarLogDistupgradeMainlog.txt that it mentions removing gnome-bluetooth by request of lubuntu-desktop... which seems to be specific to u-r-u and could explain not being able to reproduce it with apt-get
[23:07] <slangasek> bdmurray: well, if it's reproducible with apt-get then I'm not sure what to look at.  If it's not reproducible with apt-get but is reproducible with u-r-u, then that could point to a bug in the u-r-u quirks, like the above which might be a problem
[23:08] <slangasek> but in theory that's a *post*-upgrade quirk
[23:09] <slangasek> AIUI
[23:10] <slangasek> anyway, both raring and saucy versions of gnome-shell depend on gnome-bluetooth, which makes that rule problematic but I'm not sure it's related to this upgrade problem
[23:12] <slangasek> bdmurray: both of those bug reports have both lubuntu-desktop and gnome-shell installed, and both show gnome-bluetooth in the problem resolver output... different solutions considered in each case, but I'm starting to think that yes this is the cause and u-r-u's labelling these as "post" upgrade removals is misleading
[23:13] <bdmurray> slangasek: yeah, it looks like an issue of having ubuntu-desktop & lubuntu-desktop installed
[23:14] <slangasek> so I think just dropping the lubuntu PostUpgradeRemove line should DTRT, since that was added for the oneiric->precise upgrade and is obsolete now
[23:18] <bdmurray> slangasek: okay, thanks