[02:18] <jbicha> robert_ancell: did you see https://code.launchpad.net/~jbicha/lightdm/have-lib-only-suggest-lightdm/+merge/184439 ?
[02:19] <robert_ancell> jbicha, makes sense to me
[02:20] <robert_ancell> jbicha, actually, can you do a quick merge with trunk and bump the version number?
[02:20] <robert_ancell> Then can land
[02:21] <jbicha> ok, I did that earlier today but I can do it again if it will be accepted :)
[02:22] <robert_ancell> jbicha, sorry :)
[02:23] <jbicha> done, thanks :)
[02:25] <didrocks> robert_ancell: please no more lightdm today
[02:25] <robert_ancell> didrocks, why not? I hear you love LightDM!
[02:26] <didrocks> robert_ancell: we already try to stabilize the ubuntu-touch image
[02:26] <didrocks> and having stuff changing is making it… hard ;)
[02:26] <didrocks> not a question of love/hate ;)
[03:38] <cyphermox> didrocks: https://code.launchpad.net/~mathieu-tl/unity-system-compositor/0.0.1+13.10.20130903-0ubuntu2/+merge/184917
[03:39] <didrocks> approved
[04:04] <Mirv> wow, arm64 has cu2d in jenkins and apparently needs cu2d-skip for mir
[04:04] <Mirv> how it has arrived there is beyond me, the PPA doesn't have it so obviously it's not finished "building"
[04:05] <Mirv> cu2d has arm64, not arm64 has cu2d, need to finish this coffee
[04:10] <Mirv> didrocks: cyphermox: any idea where that arm64 has come from to cu2d, and maybe it shouldn't be there?
[04:16] <Mirv> oh, great, it does happen now with each stack, so each stack is halted because it waits for non-existend arm64 build eternally
[04:17] <Mirv> but, I'm happy to see unity8 has landed, so we're on our way away from manual publishing
[04:23] <didrocks> Mirv: I think the support in the ppa is coming
[04:23] <didrocks> Mirv: I'm totally exhausted, can you try to ignore arm64 like we do for powerpc if there was no build before in cu2d?
[04:23] <didrocks> the code should be straightfoward
[04:24] <didrocks> now that unity8 landed, I'll EOD
[04:24] <Mirv> didrocks: sure, sure, go sleep, I'll look or if nothing else I'll keep cu2d-skip:ing :)
[04:25] <didrocks> Mirv: thanks! ;)
[04:25] <didrocks> Mirv: just don't publish before asac or I ack on those, we need the current image
[04:25] <Mirv> yeah, I know
[04:26] <didrocks> oh, in fact I can push that quickly and run
[04:26] <didrocks> if things explodes, it's not me
[04:27] <didrocks> Mirv: is it waiting on arm64 or armel64?
[04:27] <didrocks> (the exact string)
[04:28] <Mirv> didrocks: arm64, I see it could be added to cupstream2distro/settings.py
[04:28] <didrocks> Mirv: right, just pushing quickly, one sec
[04:28] <didrocks> and pulling on mangers
[04:28] <Mirv> ok
[04:29] <didrocks> Mirv: as you probably figured out: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/386
[04:30] <Mirv> yep
[04:30] <didrocks> deployed on magners, so next tick should be fine
[04:30] <Mirv> grep -r powerpc made it quite easy find
[04:30] <Mirv> cool, thanks
[04:30] <didrocks> heh, I didn't even remember I used an array
[04:30] <didrocks> FYI, we workarounded the DNS issue
[04:30] <didrocks> so we should be safer for that
[04:31] <didrocks> everything should be fine today
[04:31] <didrocks> or at least, "finer" if I would say so
[04:31] <didrocks> time to go to bed, good luck Mirv, have a nice day!
[04:31] <Mirv> thanks, g'night!
[04:31] <didrocks> thx!
[08:04] <Laney> morning
[08:06] <darkxst> hi Laney
[08:06] <Laney> hello darkxst
[08:06] <Laney> how do?
[08:08] <hyperair> lwl/w #bakabt
[08:08] <hyperair> oops
[08:08] <Laney> nice password
[08:08] <hyperair> that's not a password. i was trying to switch windows
[08:08] <Laney> suuuuuuuuuuuuure :P
[08:08] <hyperair> but this happened enough times to make that assumption eh? =p
[08:08] <Mirv> so you even try to avoid the need to change the password by claiming it didn't leak ;)
[08:08] <hyperair> i think i typed my password into ##c++ once and #ck once
[08:09] <hyperair> Mirv: eh well you're free to go try that password elsewhere :)
[08:09] <Mirv> hehe
[08:09] <Laney> OH GOD HAND ME THE MIND BLEACH
[08:09] <hyperair> my username's hyperair everywhere except steam (it's hypera1r there because somebody took my nickname. *shakes fist*)
[08:09] <Laney> why do you have that kind of stuff in your email?!
[08:09] <darkxst> Laney, yeh good, nice spring weather here now ;)
[08:09] <hyperair> Laney: that was a honeypot account
[08:09]  * hyperair whistles
[08:11] <Laney> you got me good
[08:11] <Laney> darkxst: heading the opposite way for us now :(
[08:11] <Laney> still managed to get out on the bike yesterday
[08:11] <darkxst> nice, I have to wait until the weekend for another ride
[08:15] <darkxst> Laney, my bike has been feeling its age of late, been spending as much time fixing as riding, although getting close to being a brand new bike again!
[08:16] <Laney> mine is new enough to not have those kind of problems yet
[08:16] <Laney> which is good because I don't really know much about fixing stuff :P
[08:24] <darkxst> and mine is too expensive to replace very often!
[08:24] <Laney> hehe
[08:24] <Laney> they are skills that are good to have
[08:25] <Laney> probably need a new chain actually
[08:26] <darkxst> bikes are rather overpriced here, but either way I could buy a cheap car cheaper than my MTB!
[08:43] <mlankhorst> your *expensive* MTB :P
[09:03] <Mirv> sil2100: can you approve the branch from status page before your next tick?
[09:08] <darkxst> mlankhorst, all good MTB's are expensive!
[09:08] <xnox> darkxst: mostly yes.
[09:08] <Laney> woah channel switch
[09:15] <sil2100> Mirv: doing...
[09:17] <Mirv> sil2100: thanks!
[09:17] <Mirv> deploying
[09:19] <darkxst> xnox, there is some bit you don't like?
[09:19] <sil2100> Mirv: feeling sicklish today, had only a few hours of sleep - how are the stacks today?
[09:20] <Mirv> sil2100: did you read my e-mail? the stacks status is getting better all the time now.
[09:20] <sil2100> Mirv: yes, I read the e-mail, but heard about some arm64 pop-ups there
[09:20] <Mirv> sil2100: take care, hopefully you'll feel better soon
[09:20] <sil2100> Do we have to cu2d-skip that every time, or is this arch ignored by cu2d automatically?
[09:20] <Mirv> sil2100: yeah so the fix fixed it
[09:21] <Mirv> that was proven now during this 2nd tick of mine
[09:21] <Mirv> ignored as was previously done with powerpc
[09:21] <seb128> sil2100, you might want to ask on #ubuntu-devel about the arm64 thing, cjwatson or the launchpad guys (wgrant/StevenK/infinity) might have a clue what's going on
[09:22] <Mirv> seb128: I resolved it with didrocks in the morning already
[09:22] <seb128> ok, do you know where the arch was added? to launchpad?
[09:22] <seb128> do they plan to enable the port soon?
[09:23] <Mirv> seb128: not exactly, but yes apparently it's planned to be enabled now soon and coming to PPAs as well
[09:23] <Mirv> I mean, I don't know exactly
[09:23] <Mirv> and that's why it hit cu2d as well, as it started waiting on arm64 builds that didn't happen
[09:23] <sil2100> Mirv: btw. do you know anything about the unity8/platform bits? Do you know if Ricardo was able to get a nice binary copy of the packages?
[09:23] <seb128> Mirv, how did you get it fixed?
[09:23] <sil2100> asac: ^ ?
[09:24] <Mirv> sil2100: it seems stuff landed yesterday, but we're still not touching anything until asac/didrocks say otherwise
[09:24] <sil2100> seb128: cu2d now automatically 'doesn't care' about arm64 it seems, we have that for powerpc as well
[09:24] <seb128> k
[09:24] <Mirv> seb128: we added arm64 to be in the same list as powerpc
[09:25] <Mirv> to 'ARCHS_TO_EVENTUALLY_IGNORE' in cupstream2distro settings.py
[09:37] <seb128> sil2100, Mirv: thanks
[09:37] <seb128> sil2100, Mirv: do you think we could publish indicators today or is that blocked on asac/didrocks' to approve as well?
[09:38] <seb128> qengho, hey, did you get a fixed chromium-browser ready for upload (do you need sponsoring)?
[09:38] <seb128> chrisccoulson, hey, ^ do you know?
[09:39] <sil2100> seb128: not sure what the status is today, but I guess it would be alright to publish that, as it has those important things right?
[09:39] <sil2100> The next tick should fix the Indicator stack
[09:39] <chrisccoulson> seb128, i don't sorry (i've just had 2 days off, so still catching up)
[09:39] <seb128> sil2100, yes, that has important fixes for the messaging menu on the phone and for the hud
[09:39] <seb128> chrisccoulson, ah, welcome back ;-)
[09:40] <seb128> chrisccoulson, I hope you had a good mini-holiday! did you go anywhere?
[09:40] <Mirv> seb128: seems blocked if I understand this correctly '< didrocks> Mirv: just don't publish before asac or I ack on those, we need the current image'
[09:40] <chrisccoulson> seb128, yeah, we went to legoland :)
[09:40] <Mirv> seb128: meanwhile that config commit I got sil2100 to approve might mean successful build & autopilots on indicators stack, which would then mean possibility to ask for permission to publish it
[09:41] <seb128> chrisccoulson, nice!
[09:41] <sil2100> ;)
[09:41] <sil2100> Mirv: ok, good to know
[09:41] <seb128> Mirv, great!
[09:42] <sil2100> Just hope didrocks or asac will be up in the next few hours
[09:42] <Mirv> well didrocks went to sleep 5h ago, so depending on how much sleep he needs :)
[09:42] <Laney> seb128: don't you want the buildClickView branch reviewed then?
[09:43] <Laney> oh, it misses the new files, that makes a bit more sense
[09:44] <seb128> Laney, I welcome input/comments on it
[09:45] <ochosi> hi Laney
[09:45] <seb128> Laney, doh, I forgot to bzr add those? fixing
[09:46] <Laney> seb128: yeah, see the bot's angry message
[09:46] <Laney> hi ochosi
[09:46] <ochosi> Laney: sorry for pinging you out of the blue, i'm part of the xubuntu team (mostly dealing with artwork) and maintaining lightdm-gtk-greeter
[09:47] <ochosi> Laney: you submitted a patch a while back for xfce4-session and logind (if i'm not mistaken)
[09:47] <Laney> I kind of remember that
[09:47] <ochosi> Laney: which fixed reboot and shutdown, but at the moment logout still seems broken
[09:47] <ochosi> and we noticed because the greeter was misbehaving
[09:47] <ochosi> so i tried to fix the greeter (robert gave me a few pointers)
[09:48] <ochosi> but that didn't work, and then i realized that it takes me 8+ seconds to logout (when it used to take me 1sec on raring with the same machine)
[09:48] <ochosi> so i drew a connection and started to read xfce4-session's source, but i'm just not familiar enough with sessions and logind to be able to fix this
[09:48] <ochosi> so i cowardly come to you for help
[09:49] <seb128> Laney, did you find a good tutorial for QAbstractListModel? that api seems complex (at least compared to using a List<QObject*>), I'm not sure if it's overdoing it for the simple model we have there (no filtering needed, though we need sorting ...)
[09:50] <Laney> ochosi: not sure that I'm going to be able to help there :-/
[09:50] <Laney> we have some problems like that in ubuntu too that we haven't debugged yet
[09:51] <ochosi> Laney: oh, you do? could you ping me when you start the debugging? (or is there a bugreport yet?)
[09:51] <Laney> yeah logout taking a while, seems like it hits some timeout
[09:52] <ochosi> here it also seems to crash the session or something
[09:52] <ochosi> but tbh i'm not a debugging master and now that xsession-errors seems kinda gone and half-empty i'm not sure where to look anymore
[09:52] <Laney> are you on upstart user sessions?
[09:52] <Laney> if so: ~/.cache/upstart/<service>.log.*
[09:53] <Laney> seb128: hmm, don't remember a tutorial
[09:53] <Laney> seb128: anyway, that's something I've done before so I could look at that for storage if you want
[09:53] <Laney> it does make things nice from the qml side if you do it using models in cpp
[09:53] <ochosi> Laney: startxfce is there, so far i haven't found anything useful there
[09:57] <seb128> Laney, after spending 1 day on that code I start really liking my few lines of js better :p
[09:59] <Laney> heh
[09:59] <Laney> well, leave it to me if you like
[09:59] <Laney> otherwise I'm a bit unsure of what setting to work on next
[10:03] <seb128> Laney, well, I'm done with that, as said I'm on vac tonight for 1.5 week, I don't want to spend my day on that, need to put things in order for the week I'm not there
[10:03] <Laney> ok
[10:03] <seb128> Laney, so if you want to pick it up and turn it to a qabstractmodel please do
[10:03] <Laney> will do some of that then
[10:03] <seb128> Laney, I mostly put it up because it has the json parsing done, so it's a base
[10:03] <Laney> so yeah kind of stuck for what settings to do otherwise
[10:03] <Laney> got any ideas?
[10:04] <sil2100> hm, is LP down for you guys as well?
[10:04] <Laney> yes, maintenance
[10:04] <seb128> sil2100, yes
[10:04] <seb128> sil2100, usually a few minutes I think
[10:04] <sil2100> ACK, thanks
[10:04] <Laney> https://twitter.com/launchpadstatus/status/377723930133274624
[10:04] <seb128> Laney, things that you can help on if you are looking for idea:
[10:04] <sil2100> Bad timing, as the next tick just started...
[10:04] <seb128> - the click model
[10:04]  * sil2100 sighs
[10:05] <sil2100> We're all red again
[10:05] <seb128> - Laney: backporting https://git.gnome.org/browse/glib/commit/?id=6ec2bb17c393c411a2182e865aa0979165dfbac5 and using it to get the size of the xdg directories in storage
[10:05] <seb128> e.g video, music
[10:05] <seb128> Laney, libgdata handing tests
[10:05] <seb128> Laney, building e-d-s without goa on armhf
[10:05] <Laney> handing tests?
[10:05] <Laney> hanging?
[10:05] <seb128> hanging
[10:06] <Laney> aha
[10:06] <seb128> yes
[10:06] <seb128> https://launchpad.net/ubuntu/+source/libgdata/0.14.0-1ubuntu1
[10:06] <Laney> yeah saw that
[10:06] <seb128> Laney, do you have access to https://docs.google.com/a/canonical.com/document/d/1Anaxk4gaIjAJYdgpKICwxRpEinCVprIHl01sOGDaCFs/edit ?
[10:07] <Laney> seems so
[10:07] <seb128> Laney, ok, I'm going to add comments on that, but that's the current list of things we think need to be done/postponed
[10:09] <Laney> changing OSK options is what attente has a branch up for atm
[10:09] <seb128> right
[10:09] <Laney> or is it not hooked up in maliit yet?
[10:09] <seb128> they have an ini style config
[10:09] <seb128> we had a meeting about that 10 days ago
[10:09] <seb128> they plan to port ubuntu-keyboard's config to gsettings
[10:09] <seb128> I don't think that happened yet though
[10:10] <Laney> yeah it uses QSettings
[10:10] <Laney> seems alright though if it works
[10:10] <seb128> right
[10:11] <seb128> Laney, anyway, the click model and the xdg disk space are good ones to work on next, then power maybe (the wifi on/off might be better off using the dbus status/get dynamic update, bluetooth should be easy to do using dbus methods as well I think, and the screen brightness slider should copy what indicator-power does)
[10:13] <Laney> those last ones in the battery panel you mean?
[10:13] <seb128> Laney, yes
[10:13] <Laney> ok
[10:13] <Laney> seems like a decent list, thanks
[10:13] <seb128> yw
[10:13] <Laney> i'll be off friday and monday anyway
[10:13] <sil2100> seb128, Laney: related to the settings, is it normal that I can't change the background wallpaper? How can I do that? Since when I access 'Background', I get the two 'Welcome screen' and 'Home screen' images but clicking on them doesn't work - am I doing anything wrong?
[10:14] <Laney> sil2100: I haven't been tracking that since Ken started working on the content hub stuff
[10:14] <Laney> but I thought someone made it work
[10:14] <sil2100> I could try working on that as a first thing for familiarization, just wanted to make sure it's not just broken on my device
[10:15] <Laney> maybe it was blocked by the delayed releases
[10:16] <seb128> sil2100, the fix for the gallery activation is pending landing since thursday or something :/
[10:16] <Laney> sil2100: Getting rid of the snail and cogs would be good
[10:16] <Laney> i.e. use the default unity8 does
[10:16] <sil2100> Maybe, I built and installed the latest u-s-s on the device, so it should be the latest one I guess...
[10:16] <seb128> sil2100, that's using the file picker which is supposed to spawn the gallery app, but the spawning was not done
[10:16] <seb128> sil2100, the fix is in content-hub
[10:16] <sil2100> Ah, ACK
[10:16] <Laney> if you want somethingn to work on
[10:17] <sil2100> Good to know ;)
[10:17] <seb128> sil2100, http://bazaar.launchpad.net/~phablet-team/content-hub/trunk/revision/35
[10:17] <sil2100> Laney: hm, ok, is there a bug for that already?
[10:17] <seb128> sil2100, we need that to land
[10:17] <Laney> no
[10:17] <sil2100> seb128: noted!
[10:17] <Laney> just look at the fallback logic
[10:17] <Laney> it's for what happens if you pick an invalid image
[10:17] <Laney> i.e. in gnome you can have these .xml files
[10:17] <Laney> or some corrupt file or so
[10:18] <Laney> you need to fall back to something - see what unity does there and copy that
[10:18] <sil2100> Laney: ACK ;)
[10:18] <seb128> Laney, can you open a bug for tracking maybe?
[10:18] <Laney> ok
[10:18] <seb128> thanks
[10:19] <Laney> It shouldn't be that much work as there's already logic in there for trying to load an image and doing something if that fails
[10:19] <Laney> it's making the "something" not be "set my background to a picture of a snail"
[10:20] <seb128> sil2100, Laney: I'm going to file some bugs today, for the things I know that are missing/buggy/todo
[10:20] <seb128> that should help having a list of things to pick up
[10:20] <Laney> as much as I do like seeing that thing around the place :-)
[10:20] <seb128> ;-)
[10:20] <sil2100> \o/
[10:20] <sil2100> Laney: ;D
[10:24] <Laney> hmm, actually, I guess you want to fall back to the default wallpaper
[10:25] <Laney> filed anyhow
[10:26] <seb128> chrisccoulson, is there a place where qengho usually puts chromium updates when they need sponsoring?
[10:32] <seb128> sil2100, you might want to look at bug #1221179
[10:32] <ubot2`> Launchpad bug 1221179 in ubuntu-system-settings "[background] image previews should include shell components" [Low,Confirmed] https://launchpad.net/bugs/1221179
[10:33] <seb128> sil2100, we don't have the asset but it should be possible to get the code ready with a faked image/local hack
[10:33] <seb128> sil2100, it's basically stacking asset from unity/greeter ui on top of the image
[10:33] <sil2100> Ah, sounds fairly simple indeed!
[10:34] <Laney> I decided the fallback case was more complex and added some of my annoying thoughts to the bug
[10:34] <sil2100> seb128: I'll assign this to myself for starters maybe, then look at Laney's proposition inbetween stack and appmenu-qt5 actions :)
[10:34] <Laney> https://bugs.launchpad.net/ubuntu-system-settings/+bug/1223798
[10:34] <ubot2`> Launchpad bug 1223798 in ubuntu-system-settings (Ubuntu) "[background] Remove initial fallback images" [Undecided,New]
[10:35] <Laney> there's some thinking to be done there unless I've gone nuts
[10:35] <seb128> sil2100, great, thanks
[10:35] <Laney> yes, welcome to the u-s-s team
[10:35] <Laney> muhahaha
[10:36]  * sil2100 is scared
[11:02] <sil2100> seb128: btw. is it 'safe' to install the touch ubuntu-system-settings on my desktop system?
[11:11] <seb128> sil2100, sure
[11:11] <Laney> that's how we develop it
[11:11] <seb128> sil2100, I do 95% of my work/testing on the desktop, I just run it once every now and then on the device to check that everything is ok and see how it behaves with touch
[11:23] <seb128> dpm, hey
[11:23] <dpm> hi seb128
[11:24] <seb128> dpm, replying there to your launchpad question, that bug means the pot of all sources under daily landing are not updated
[11:25] <seb128> dpm, daily landing includes all unity, indicators, touch components, settings, sdk, etc
[11:26]  * seb128 kicks firefox, you piece of c***
[11:27] <seb128> it's downloading stuff when it said download failed, without telling me what nor letting me a way to stop the downloads
[11:30] <dpm> seb128, ah, thanks, I wasn't sure I could follow it. But it is not the builders task to update the templates according to the package rules when the packages are uploaded? I thought that happened automatically. Or is it just about those updated .pot files from the tarballs not getting updated in https://translations.launchpad.net/ubuntu ?
[11:30] <seb128> dpm, it's about the .pot/.mo files not being imported from the build dir to launchpad
[11:31] <seb128> dpm, e.g the translations tarball generated on the builders is not used
[11:48] <seb128> dpm, basically we should manually update all those pots before saucy I guess :/
[11:48]  * dpm otp, bbiab
[12:04] <seb128> chrisccoulson, help, how do I stop firefox to keep downloading stuff that he claims failed to download?
[12:05]  * seb128 kicks firefox in the nuts
[12:21] <Mirv> sil2100: https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/platform_additions/+merge/185032
[12:24] <sil2100> Mirv: finishing lunch and approving ;)
[12:24] <qengho> seb128: On Chromium, I have the two known bugs fixed, but there's one additional webapps-related bug I want to squash also.
[12:25] <seb128> qengho, hey ... ok, do you have an eta on that? we need to get the other ones fixed
[12:25] <sil2100> Mirv: things are building a long time today...
[12:26] <qengho> seb128: Want these now and another package in a day?  It's hard to estmate the unknown.
[12:26] <Mirv> sil2100: yes, there are clearly some performance problems now
[12:27] <seb128> qengho, well, I don't want to end up like the previous time, where "it's going to be fixed in the next update, just one thing to sort out" took weeks
[12:27] <seb128> qengho, what's the webapp issue and its impact?
[12:28] <pitti> hey hey
[12:28] <qengho> Open a webapps page first from a docked icon. Then open normal window. Normal window doesn't respond to Ctrl-T tab opening.
[12:28] <seb128> pitti, good morning!
[12:28] <pitti> seb128: ça va ?
[12:28] <qengho> seb128: ^
[12:28] <seb128> qengho, ok, that doesn't seem worth delaying the other fixes, can be in another upload next week imho ... what do you think?
[12:28] <seb128> pitti, très bien, et toi ?
[12:28] <Mirv> sil2100: how about this one https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/mirslave_allow_both_libmirclient2_and_3/+merge/185034 - it seems that it was not a good idea to replace 2 with 3 in the previous commit, since it tries to actually install both at the moment
[12:29] <seb128> qengho, currently we have upgrades that hit package conflicts and some users who can't use their browser because they are missing the UI elements ... let's get those fixed
[12:29] <sil2100> Checking the diff
[12:29] <seb128> qengho, there is going to be another upload soon enough which can fix the webapp issue
[12:30] <pitti> seb128: mon aussi, didn't get ubuflu so far (although overcooled rooms are eeeverywhere :/), and jetlag wasn't too bad
[12:30] <seb128> pitti, you seem up very early ... but I guess that's usual for you
[12:30] <seb128> pitti, are people at the sprint starting to get ubuflu? be careful, it often hits at the end of the week
[12:31] <sil2100> Mirv: *sigh* ok, let's do it like that, I usually tend to workaround this not to introduce noise into the repo (i.e. just changing the packages list in the jenkins job temporarily) as this will be gone once mir is released
[12:31] <seb128> pitti, is the sprint productive? do you guys do hacking or more discussions?
[12:31] <sil2100> Mirv: but I guess now it makes sense
[12:31] <Mirv>  sil2100 temporary is fine for me as well, ie just deploying
[12:31] <pitti> seb128: I looked into IRC around 7, but now it's 8:30, we just arrived at the office
[12:31] <pitti> seb128: there's two buses, so not that much choice
[12:31] <sil2100> Mirv: especially that we're not releasing stuff, so better have it in the branch
[12:31] <seb128> k
[12:34] <pitti> seb128: we actually do have quite some discussions, but we get to do hacking in the afternoons
[12:34] <seb128> pitti, k, shame that we don't a joined sprint, I miss you guys!
[12:35] <desrt> brrrraaaaiiinnnsssss
[12:35] <pitti> seb128: likewise! didrocks and jibel are here at least, so I have at least some of my favourite French here :)
[12:35] <seb128> ;-)
[12:35] <Mirv> sil2100: there's some random stuff going on, once again. http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/label=qa-nvidia-gtx660/1738/console doesn't seem like progressing.
[12:36] <Mirv> I'm going to just abort that
[12:38] <sil2100> Thanks
[12:39] <sil2100> hm, too bad it's from platform, that's a base package that I'd like released with anything else
[12:40] <sil2100> Mirv: nvidia seems awfully strange today
[12:40] <sil2100> Mirv: not moving really on the mirslave job...
[12:44] <sil2100> Mirv: I think we'll have to reset the nvidia machine
[12:44] <Mirv> sil2100: argh
[12:44] <sil2100> Mirv: http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/1739/label=qa-nvidia-gtx660/console <- it's not moving, and when I ssh to the nvidia machine and try to do lxc-ls --fancy, it's just hanging
[12:44] <sil2100> b0rken :<
[12:44] <Mirv> that's b0rken indeed
[12:44] <Mirv> bah
[12:45] <sil2100> Should I sudo reboot it?
[12:45] <Mirv> sil2100: will you powerswitch or will I?
[12:45] <Mirv> sil2100: yes, by all means
[12:45] <Mirv> of course that's softer way :)
[12:45] <sil2100> Mirv: I'll try by ssh, if it doesn't work we'll powerswitch it ;p
[12:46] <sil2100> heh, ok, reboot doesn't seem to work ;p
[12:46] <Mirv> seb128: at least some good news anyway. as I predicted indicators would be now happy to publish itself if we'd just allow it.
[12:47] <seb128> Mirv, \o/
[12:47] <seb128> just need to get asac to +1 that then
[12:47] <Mirv> yep
[12:49] <sil2100> Mirv: I powerswitched it
[12:50] <sil2100> Reboot just made things worse ;p
[12:50] <qengho> seb128: Cr updates in  chinstrap:~cmiller/packages/ , if you care to sponsor.
[12:51] <seb128> qengho, thanks, I can do that ;-)
[12:51] <qengho> seb128: merci bien.
[12:51] <seb128> de rien ;-)
[12:52] <seb128> didrocks, oh a didrocks, can we get the hud and indicators published today? there are important fixes for touch and desktop in there
[12:52] <sil2100> didrocks: morning! Less jet-lagged now? ;)
[12:52] <didrocks> sil2100: seb128: hey! well. First asac wants a touch image with unity8 + mir running
[12:53] <Mirv> sil2100: oh..
[12:53] <didrocks> so gating on the tests to turn green before releasing the rest of locks
[12:53] <kenvandine> Laney, seb128: should setting timezone with the datetime plugin in system-settings work?
[12:53] <didrocks> sil2100: no jetlag, but slept 4 hours because of the above (finished at 1am yesterday) ^
[12:53] <seb128> kenvandine, hey, on desktop yes
[12:53] <sil2100> didrocks: I noticed there was a publish of unity8 last night, was that ACKed by you and done by Ken?
[12:53] <seb128> kenvandine, touch still has the logind issue
[12:53] <kenvandine> seb128, ah, ok
[12:54] <didrocks> seb128: acked and done by me
[12:54] <didrocks> asac was next to me to testify
[12:54] <seb128> sil2100, ^
[12:54] <Mirv> sil2100: so does the nvidia machine look like kaboom now?
[12:54] <sil2100> ACK
[12:54] <didrocks> we had beers and pizzas
[12:54] <didrocks> and worked :p
[12:54] <didrocks> (I guess that was the deal)
[12:54] <sil2100> Mirv: it looks better, at least lxc-ls doesn't die ;)
[12:54] <Mirv> sil2100: hmmkay
[12:54] <sil2100> Mirv: is it visible on jenkins?
[12:55] <pitti> seb128: darn, https://translations.launchpad.net/ubuntu/saucy/+language-packs didn't get a new delta tarball for a week, so no new langpacks today :/
[12:55] <pitti> seb128: but it did copy ubuntuone-client into the local source packages now
[12:55] <pitti> so the next actual export will have it
[12:55] <Mirv> sil2100: not sure yet, but guess what intel seems stuck http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/label=autopilot-intel/1739/console
[12:56] <seb128> pitti, so next update should have it? do you know why previous one didn't?
[12:56] <sil2100> Come oon...
[12:56] <pitti> seb128: yes, it was considered to be KDEish
[12:56] <sil2100> Mirv: the machine seems responsive, checking the container
[12:56] <Mirv> sil2100: didrocks: just as one more data point there was some apparently daily otto autopilot job, which stuck at "starting lxc" or such on both intel and nvidia machine and didn't continue from there
[12:57] <Mirv> around 09:45 UTC
[12:57] <seb128> pitti, oh ok, good if it's fixed in the next update then ... do you know what's the issue with the "no tarball for a week"?
[12:57] <pitti> no, I don't
[12:57] <pitti> I just noticed myself
[12:57] <didrocks> Mirv: interesting, let jibel knows when connected, he said he will look at those kinds of issues today
[12:57] <sil2100> Mirv: the container seems responsive, not sure on what process it's hanged, let me try moving that
[13:00] <Mirv> sil2100: can you let jibel know about http://<IP_ADDRESS>:8080/job/autopilot-saucy-setup_otto/label=autopilot-intel/116/console when he arrives?
[13:00] <Mirv> so it just stuck there, and same for nvidia
[13:00] <Mirv> until aborted
[13:00] <Mirv> the logs stated that yesterday at the same time it worked fine
[13:01] <sil2100> Mirv: ok, will do
[13:01] <Mirv> sil2100: now nvidia seems offline..
[13:01] <sil2100> Mirv: ah, you aborted the intel job? I was in the container when you did that ;
[13:02] <sil2100> ;p
[13:02] <sil2100> And it was like 'huh, what happened?!'
[13:02] <sil2100> Mirv: ok, so the jenkins slave didn't start again probably...
[13:02] <Mirv> sil2100: haha, right....
[13:02] <Mirv> sil2100: yes, I just started the slave again
[13:02] <Mirv> sil2100: jibel is probably already aware that it doesn't automatically seem to start?
[13:03] <sil2100> Mirv: yes, I'll re-inform him since I though he mentioned having a workaround
[13:03] <Mirv> sil2100: ok, I'll let you have the full control so that I won't come to your turf, the queue and hangs just look so sad :)
[13:04] <sil2100> Mirv: I always appreciate help ;) Especially when I'm doing something else as well
[13:05] <sil2100> Mirv: but I opt for even missing the next tick just to get the stacks into shape - what do you think?
[13:05] <sil2100> I wonder what's happening with the test machines recently, since in the past we never had so many issues like these
[13:06] <Mirv> sil2100: well, depending on how it goes. if it's just unity 55mins from now, it might be easier to abort its job and allow normal "restart all"
[13:06] <Mirv> sil2100: but on the other hand hand-guiding this tick to an actual end would be nice as well
[13:06] <seb128> sil2100, they send didrocks and jibel in the US to drink beers and eat pizzas, that's where it all started going down ;-)à
[13:07] <sil2100> ...;D
[13:13] <sil2100> Mirv: ok, now the machines seem to work correctly (so far)
[13:15] <sil2100> didrocks: could you do a final review of https://code.launchpad.net/~canonical-desktop-team/cupstream2distro-config/new_saucy_series/+merge/184641 ? Francis already ACKed it - if it's ok, I'll maybe top-approve once we get something released from the current arch
[13:15] <Mirv> seb128: sure..
[13:15] <sil2100> didrocks: and move on with redeploying and filling RT's
[13:15] <Mirv> sil2100: sure.. (meant for you)
[13:16] <Mirv> but well I agree also with seb's analysis of the situation
[13:16] <seb128> (I was wondering/reading backlog for context :p)
[13:16] <sil2100> ;)
[13:32] <sil2100> Mirv: intel again hanged up...
[13:32] <sil2100> jibel, didrocks: we have a problem with the intel machine it seems
[13:33] <sil2100> jibel, didrocks: it's the second time this happens - otto hangs after hook 10-autopilot and doesn't move a muscle
[13:33] <sil2100> jibel, didrocks: last time, I couldn't even reboot the machine by SSH, had to powerswitch it
[13:33] <sil2100> jibel, didrocks: http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/1743/label=autopilot-intel/console
[13:34] <sil2100> Mirv, didrocks, jibel: daily-release is pointless in this state, as it implies someone from the maintainance team to look at every test job every 5 minutes and abort
[13:34] <jibel> sil2100, given the place it stopped it'd means the session fails to start
[13:35] <jibel> sil2100, did you look at any error message from lightdm or X or kernel?
[13:35] <sil2100> I'll try attaching to the container, as it's still running
[13:37] <sil2100> jibel: kernel seems fine, at least nothing obvious - you would know better, but checking other logs
[13:38] <jibel> sil2100, check lightdm logs
[13:38] <sil2100> Ok, I see a crash in X
[13:39] <jibel> sil2100, it doesn't look good
[13:39] <jibel> [+2.22s] DEBUG: Launching process 3699: /usr/bin/X -core :0 -auth /var/run/lightdm/root/:0 -mir 0 -mirSocket /tmp/mir_socket -nolisten tcp
[13:39] <jibel> [+2.22s] DEBUG: DisplayServer x-0: Waiting for ready signal from X server :0
[13:39] <jibel> [+2.56s] DEBUG: Process 3699 terminated with signal 6
[13:39] <sil2100> jibel: ok... the last stack that ran before this was unity8 I think ;/
[13:39] <mterry> seb128, didrocks, pitti:  you guys are members of the lightdm dev team I see...  Do you ever review branches for landing?
[13:40] <pitti> mterry: not really, I'm not involved in day-to-day development; Robert added me when I added some apparmor/guest session fixes
[13:41] <pitti> I can certainly review/merge some easy fixes when someone asks me to
[13:41] <pitti> but I don't feel qualified to review bigger changes (design, behaviour, etc.)
[13:42] <sil2100> jibel: I guess we'll have to terminate this run, right? But I wonder why mirslave AGAIN causes problems, this time on intel
[13:42] <sil2100> jibel: should I inform upstream about it? You think it's a real mir problem?
[13:43] <mterry> pitti, well, this might be too nuanced, but it's just a bug fix, not a feature: https://code.launchpad.net/~mterry/lightdm/keep-vt-around/+merge/184887
[13:45] <seb128> mterry, not often, I don't know the codebase enough to be comfortable reviewing most of the changes ... I can have a look to something easy/that doesn't need to know in detail how lightdm works though
[13:45] <pitti> mterry: (will look in a bit, in meeting here)
[13:45] <jibel> sil2100, there has been an upload of intel driver on the 9th and mir yesterday, file a bug, ping the mir guys and they'll have to handle it from here, didrocks ^^ what do you think?
[13:45] <mterry> seb128, just trying to land that bugfix branch ^
[13:45] <pitti> mterry: in fact, perhaps I'm sitting on your old chair :)
[13:46] <mterry> pitti, you're in lex now?
[13:46] <jibel> sil2100, it is not a problem with the test system anyway
[13:46] <pitti> mterry: yes, QA team sprint
[13:46] <pitti> mterry: my first time in Lex
[13:46] <mterry> pitti, awesome  :)  I was in on Monday, didn't notice ya
[13:46] <pitti> ah, too bad
[13:46] <sil2100> jibel: thanks! After checkign that with you, filling out the bug
[13:51] <Laney> where can I get a test click package from?
[13:51] <Laney> I just want one to install on my desktop for this s-s stuff
[13:54] <seb128> Laney, http://people.canonical.com/~ubuntu-archive/click_packages/
[13:54] <seb128> Laney, install them with "sudo click install --force-missing-framework --user=Laney ...click"
[13:56] <Laney> ok, ta
[13:58] <Laney> cool, seemed to work
[13:58] <seb128> Laney, great ;-)
[13:59] <seb128> Laney, some of the infos are going to be missing from some clicks btw, that's normal
[13:59] <seb128> Laney, installed-size is only available for clicks built with > 0.4.something
[13:59] <Laney> I noticed that
[13:59] <seb128> some didn't get rebuilt since
[13:59] <Laney> what are you doing then?
[13:59] <seb128> the icon is a new field also, they don't all provide it
[14:00] <seb128> Laney, atm I display a N/A for the size when it's missing, and the icon has a fallback
[14:00] <Laney> sounds fair
[14:00] <seb128> Laney, but the size isn't going to be missing over time, we have only a few old packages leftover, any new package isn't going to have that issue
[14:01]  * Laney runs this for the first time ...
[14:11] <Laney> yay
[14:11] <seb128> Laney, working?
[14:12] <Laney> gets the data
[14:12] <Laney> no sorting yet
[14:13] <jbicha> seb128: what do you think of bug 1092719?
[14:13] <ubot2`> Launchpad bug 1092719 in gnome-disk-utility (Ubuntu) "FFe: Update gnome-disk-utility to 3.8" [Wishlist,Confirmed] https://launchpad.net/bugs/1092719
[14:13] <seb128> jbicha, that you should stop being new versions addict ;-)
[14:14] <seb128> jbicha, how did you resolve the libdvdread depends?
[14:16] <jbicha> I've got a big patch to revert the dependency/feature because I didn't want to be blocked by the mir
[14:16] <seb128> "big patch" :/
[14:17] <jbicha> yeah :( it'll be fine for 3.8 but it'll probably be a headache for any newer version
[14:17] <seb128> jbicha, well, in any case I've no objection to the update, under the condition that whoever does the update deals with issues/fallouts
[14:17] <pitti> mterry: what is the use_vt_switching flag?
[14:18] <mterry> pitti, that's when we can't start the compositor, we fall back to using VTs
[14:18] <mterry> pitti, (if we are using the compositor, everything happens on the same VT)
[14:18] <pitti> mterry: ah, so true -> lightdm running on system mir, false -> old way?
[14:19] <mterry> pitti, yeah.  And my branch tries to add a fallback for the old way, when we don't have mir yet and don't have VTs either
[14:19] <mterry> pitti, by just faking it on VT 1, where we are stuck because we can't switch VTs
[14:20] <pitti> mterry: so in that case when we don't have mir yet, wouldn't use_vt_switching be false?
[14:20] <mterry> pitti, (my understanding is that XDG_VTNR is an override to logind's normal VT detection, so we force it to assume a VT.  That's what we do in the Mir case, and what I want to do in this fallback case
[14:20] <pitti> mterry: so your fallback code wouldn't even run?
[14:20] <pitti>  if (!SEAT_UNITY (seat)->priv->use_vt_switching)
[14:20] <pitti> 18+ vt = SEAT_UNITY (seat)->priv->vt;
[14:20] <mterry> pitti, if (have_mir) use_vt_switching = false
[14:20] <pitti> so without mir (old way) this would run?
[14:21] <mterry> pitti, with Mir, we don't need VT switching.  Everything happens on same VT
[14:21] <mterry> pitti, without Mir (old way), we fallback to switching between VTs, as if it were the 2000s
[14:21] <pitti> right
[14:22] <pitti> mterry: ah sorry, I was wrong above
[14:22] <pitti> it's true -> old way, false -> mir
[14:22] <pitti> right?
[14:23] <ochosi> sorry to interfer, but would VT switching also not be needed with XMir?
[14:24] <pitti> ochosi: (why sorry? :) )
[14:24] <mterry> pitti, so without Mir, we set use_vt_switching to true
[14:24] <mterry> But sometimes (like on phone), we don't have Mir, and our VT subsystem doesn't work.  So we're stuck on VT1
[14:25] <mterry> pitti, right
[14:25] <pitti> mterry: right, so I got it the wrong way around above; it makes much more sensenow
[14:25] <ochosi> pitti: heh, because i'm not really technically on top of Mir etc so it could be a really silly question (and you seemed to talk about something important)
[14:25] <mterry> ochosi, I believe in that case, the system compositor is still running in one VT, and XMir sessions just talk to it
[14:26] <pitti> mterry: approved, merging now
[14:26] <mterry> pitti, awesome, thanks!  :)
[14:26] <pitti> mterry: ah no, it gets auto-merged I assume
[14:26] <mterry> pitti, yeah, but not auto-released...  :(
[14:27] <ochosi> mterry: so when switching to the greeter (which would usually spawn a new VT), would there still be the blackout and flickering with XMir?
[14:27] <mterry> ochosi, I believe the idea is "no"
[14:28] <ochosi> mterry: that sounds like a nice feature. so no-one has tested this yet?
[14:29] <mterry> ochosi, I'm not sure.  I've been so phone focused these days, I don't know where we are with the desktop and XMir
[14:29] <ochosi> mterry: okies, thanks though!
[14:45] <didrocks> mterry: we need it for deploying the branches
[14:46] <didrocks> seb128: I'll look at it in the incoming hours
[14:47] <seb128> didrocks, that's re what? sorry so much going on during the day, I forgot what that specific ping was aobut
[14:48] <didrocks> jibel: sil2100: ack with pinging Mir team
[14:48] <sil2100> didrocks: they're ping, aware and hopefully will fix this soon, for now I skipped mirslave so that we're not blocked on a broken intel machine
[14:49] <didrocks> seb128: that's re: failing s<tab>
[14:49] <didrocks> sil2100: I'll look at it in the incoming hours
[14:49] <didrocks> it being your branch
[14:49] <seb128> didrocks, I see :p
[14:49] <sil2100> didrocks: thank you, no rush, I think top-priority for now is to get things released
[14:49] <didrocks> seb128: I know you pinged me, will be your turn soon :p
[14:50] <seb128> didrocks, btw I need you input on why it would be hard to list click updates in the system update panel ... it feels like it's just another list widget/model/delegate if they have a working backend
[14:50] <seb128> didrocks, right
[14:50] <sil2100> Poor seb128 is pinged in my stead so many many times ;p
[14:52] <didrocks> seb128: because the design UI totally changed?
[14:52] <didrocks> and we need to have one daemon to talk to I guess
[14:52] <didrocks> and rick told that we need to "finish what we have"
[14:52] <didrocks> and they already have a separate app for that
[14:52] <didrocks> so let's have V1 doing that
[14:53] <didrocks> design changed late
[14:53] <seb128> didrocks, ok, we just don't have a design for the solution you guys suggest :/
[14:53] <seb128> didrocks, I guess it's up to design to update back the design then
[14:54] <didrocks> seb128: yeah, and we can say, for us, too late, let's focus on make V1 rock solid first
[14:54] <didrocks> (and use the apps already written by the team for click packages)
[14:55] <seb128> didrocks, sure, we don't have a design anymore for our current UI though, since the wiki got updated
[14:55] <seb128> didrocks, so it's a bit flacky
[14:55] <didrocks> seb128: we can go back in history, it's versionned
[14:55] <seb128> didrocks, and we don't have guidance for handling of the error/some of the cases
[14:55] <seb128> didrocks, right, but we were lacking details by then
[14:55] <seb128> oh, well
[14:55] <didrocks> yeah, on the error handling
[14:55] <didrocks> anyway, I won't have time to implement the new design, and I asked the management about it and they agree to finish what we have
[14:56] <seb128> didrocks, ok, btw I already modified some of the UI bits while you were on holidays
[14:56] <didrocks> seb128: ah great! Sure, feel free
[14:56] <seb128> didrocks, but it's minor, moving the never/on wifi/always selector to a new screen
[14:56] <didrocks> there is this qdbus stuff with the array of dict
[14:57] <didrocks> which worries me
[14:57] <seb128> didrocks, which was part of the design changes (ported it to the new optionselector as well)
[14:57] <didrocks> but I'll have a look at it next week
[14:57] <seb128> k
[14:57] <didrocks> seb128: perfect, thanks a lot!
[14:57] <seb128> yw
[15:09] <didrocks> sil2100: +  dest: ubuntu-unity/next-next
[15:09] <kenvandine> didrocks, can i publish services?  we really need content-hub published
[15:09] <sil2100> didrocks: oh, ok ;p next-next it will be...;p
[15:10] <didrocks> -      target_branch: lp:autopilot/1.3
[15:10] <didrocks> 347+      target_branch: lp:autopilot
[15:10] <didrocks> -> not needed
[15:10] <didrocks> just remove target_branch
[15:10] <didrocks> to target trunk
[15:10] <didrocks> kenvandine: not as long as I didn't talk to alexander
[15:10] <sil2100> Right, slipped through, fixing too! Thanks
[15:10] <didrocks> kenvandine: we need to publish an image
[15:10] <didrocks> -      target_branch: lp:autopilot-gtk/1.3
[15:10] <didrocks> 363+      target_branch: lp:autopilot-gtk
[15:10] <didrocks> sil2100: same ^
[15:11] <didrocks> -      target_branch: lp:autopilot-qa/1.3
[15:11] <didrocks> 375+      target_branch: lp:autopilot-qa
[15:11] <didrocks> same ^
[15:11] <sil2100> didrocks: indeed, all those I just removed the 1.3 it seems
[15:11] <sil2100> Unnecessarily
[15:11] <sil2100> kenvandine: let's wait for this tick to finish, maybe the stacks will be in much better state
[15:11] <sil2100> kenvandine: and then we talk to asac about publishing smaller stacks
[15:12] <kenvandine> sil2100, ok, the only package that'll publish in services is content-hub
[15:13] <didrocks> sil2100: shouldn't we remove    manualpublish: True # XXX: as requested by asac, we're in manual mode!
[15:13] <kenvandine> which is being added to the seed
[15:13] <didrocks> on all head's?
[15:13] <sil2100> kenvandine: ACK, let's have a chat with asac then
[15:14] <didrocks> kenvandine: don't change anything on the touch image before we are sure we are in a good state
[15:14] <kenvandine> didrocks, understood
[15:14] <didrocks> let me gather the state in ~50 minutes
[15:14] <sil2100> didrocks: understood as well, but I agree that new content-hub is needed, since otherwise settings background-changing is b0rken ;)
[15:14] <kenvandine> yup
[15:14] <didrocks> sil2100: kenvandine: when did that change?
[15:14] <kenvandine> it's a little broken right now :)
[15:15] <didrocks> the previous settings is already broken?
[15:15] <kenvandine> kind of
[15:15] <kenvandine> missing depends on content-hub
[15:15] <kenvandine> gallery-app and uss depend on the lib
[15:15] <didrocks> hum…
[15:15] <kenvandine> which doesn't depend on the service
[15:15] <didrocks> ah, so the red on the dashboard is because of this?
[15:16] <kenvandine> not sure actually... maybe
[15:16] <didrocks> for gallery-app?
[15:16] <didrocks> can you check please?
[15:16] <kenvandine> yeah
[15:16] <didrocks> keep me posted
[15:17] <kenvandine> didrocks, actually, no
[15:17] <kenvandine> it wouldn't cause a failure in gallery-app
[15:17] <didrocks> so let's get the baseline green
[15:18] <didrocks> and then, move
[15:18] <kenvandine> but if there were tests in settings for background, then it would fail
[15:18] <kenvandine> yeah
[15:18] <didrocks> it's difficult enough already
[15:18] <kenvandine> please ping me :)
[15:18] <didrocks> kenvandine: will surely do
[15:18] <kenvandine> thx
[15:18] <didrocks> I need to get my hand on the German first
[15:18]  * didrocks will look near the fridge, beers are here, we should find him :)
[15:19] <kenvandine> asac, fyi we need to add content-hub to the touch seed, i have that ubuntu-touch-meta ready to upload... but i'll wait until you have images :)
[15:19] <sil2100> ;D
[15:20] <sil2100> didrocks: fixed those issues that you pointed out, I'll create the next-next PPA now
[15:21] <didrocks> kenvandine: yeah, don't upload it
[15:21] <didrocks> let's get green first
[15:21] <didrocks> sil2100: create the next-next?
[15:21] <kenvandine> don't worry, i won't :)
[15:21] <didrocks> sil2100: wait, what's this?
[15:21] <sil2100> didrocks: ...scratch that, don't look at that branch
[15:22] <sil2100> didrocks: wait, going for some coffee and then repushing the branch ;p
[15:23] <didrocks> k
[15:24] <sil2100> didrocks: anyway, now it should be good
[15:24]  * didrocks refreshessssss
[15:27] <didrocks> sil2100: approved
[15:27] <didrocks> I'll let you redeploy once ready :)
[15:28] <sil2100> ACK, thanks!
[15:42] <sil2100> jibel: oh my god, again the DNS problem on the otto machines :P!
[16:02] <tkamppeter> larsu, hi
[16:05] <larsu> tkamppeter: hi
[16:07] <asac> kenvandine: yeah. we want to land indicators and the unity8 fix now
[16:09] <Sweetshark> OMG another heroic effort finished at libreoffice: runnable instdir -- this build LibreOffice in a work directory, out of which it can then directly run without additional copying foo ...
[16:10] <didrocks> sil2100: around at all?
[16:10] <tkamppeter> larsu, we have the conference call
[16:11] <sil2100> didrocks: yes
[16:11] <didrocks> sil2100: hangout ready?
[16:11] <sil2100> didrocks: coding something
[16:11] <sil2100> What hangout?!
[16:11] <sil2100> :O
[16:11] <didrocks> need to talk to you for 10 minutes
[16:11] <didrocks> right NOW
[16:11] <sil2100> : O
[16:11] <sil2100> Ok, ready if anything, I guess
[16:12] <didrocks> https://plus.google.com/hangouts/_/633f1bb81a28926867d218765030050bc23a5be9?hl=fr
[16:15] <larsu> tkamppeter: please do it without me today, I don't have anything printing-related to report. I'll look at the notes later
[16:40] <attente> seb128, is it better to have the maliit schema in gsettings-ubuntu-touch-schemas or in ubuntu-keyboard?
[16:41] <qengho> seb128: I haven't seen anything about Cr package acceptance. Should I be worried?
[16:45] <Laney> GOD
[16:45] <Laney> QT :|
[17:06] <Laney> attente: I'd say in the keyboard itself
[17:06]  * Laney leaves, irritated at qt
[17:06] <attente> Laney, yeah, that made the most sense to me initially
[17:06] <Laney> maybe I'll have an evening brainwave
[17:06] <attente> :)
[17:06] <Laney> see you
[17:28] <seb128> qengho, sorry, pings didn't stop and I forgot about it, uploaded now
[17:29] <qengho> seb128: my french obviously dazzled you, n'est pas?
[17:29] <seb128> qengho, on dirait que oui ;-)
[17:30] <attente> seb128, do you have time to help me with a build issue?
[17:42] <seb128> attente, sure
[17:44] <attente> seb128, when building http://bazaar.launchpad.net/~phablet-team/ubuntu-keyboard/trunk/, i get dpkg-source: unrepresentable changes to source
[17:46] <seb128> attente, update the version number in debian/changelog
[17:46] <seb128> attente, it tries to use the tarball from the archive for that version and add the changes in a diff on top
[17:46] <seb128> attente, and you probably have a binary file or something that can't be diffed
[17:46] <seb128> attente, if you bump the changelog it's going to create a new tarball rather than reusing the archive one, that should work
[17:47] <seb128> attente, version = the part before "-0ubuntu1"
[17:47] <attente> seb128, thanks, i'll give it a try
[17:47] <seb128> attente, yw
[17:48] <qengho> seb128: Can we revert the chromium back to 28 and take a few days to test 29 more?
[17:48] <attente> seb128, thanks, that fixed it completely
[17:48] <seb128> attente, great
[17:49] <seb128> qengho, we could, what's the issue with 29?
[17:50] <seb128> qengho, are the user profiles compatible (e.g can you run 28 again after running 29, or is 29 writing configs that 28 can't understand?)
[17:52] <qengho> seb128: I haven't had any trouble going back to 28, but I have no formal knowledge about no change.
[17:52] <seb128> qengho, what's the rational for going back?
[17:53] <qengho> seb128: #webapps is scared of it and wants to test thoroughly. One bug means there could be other bugs.
[17:54] <seb128> qengho, that doesn't seem a strong rational for a revert, that needs better coordination next time/them keeping more on top of the beta channel
[17:55] <qengho> seb128: reverting the index of released wouldn't help people who have aready installed anyway, right?
[17:55] <seb128> qengho, you can't revert in versions, you would have to use an epoch or reupload 28 as 29.is.really.28
[17:55] <seb128> qengho, e.g fake the version to be > 29
[17:56] <qengho> seb128: right.
[17:56] <seb128> qengho, but we don't have enough proved issues to justify going through a revert, especially when we are unsure it's not going to create issues with user configs (not to mention file conflicts with l10n)
[18:16] <dbarth> seb128: quick note, we're sorry about the regression on chromium; we're re-testing the new build right now to ensure this doesn't snowball
[18:16] <seb128> dbarth, thanks
[18:19] <qengho> seb128, dbarth: Thank you for your help, too.
[18:20] <seb128> qengho, thanks for getting those fixes out!
[18:20] <seb128> qengho, that, and for considering the webapps issues as well ;-)
[18:22] <qengho> seb128: Next chromium will have UI autopkgtests covering everything we saw today!  I'm excited.
[18:22] <seb128> \o/
[19:50] <didrocks> pitti: around? mind bumping some stuff?
[19:50] <pitti> didrocks: bring'em on
[19:50] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4956393
[19:50] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4956391
[19:50] <pitti> didrocks: fait
[19:50] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4956399
[19:51] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4956397
[19:51] <didrocks> pitti: et ce sera tout ;)
[19:51] <didrocks> merci!
[19:51] <pitti> didrocks: de rien
[19:54] <didrocks> pitti: it's back to 10 minutes? https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4956397
[19:54] <didrocks> did you bump for the last 2 the priority?
[19:55] <pitti> didrocks: oh, sorry
[19:56] <pitti> didrocks: done all 4 now
[19:56] <didrocks> pitti: merci beaucoup
[20:09] <qengho> fg
[20:13] <qengho> Bah!


[09:33] <troulouliou_dev> hi i m trying to register on launchpad but i do not receive a confirmation email and when i m trying to log in it say "Your page was stale."
[09:36] <wgrant> troulouliou_dev: That usually means that your browser isn't sending a Referer header.
[09:37] <troulouliou_dev> wgrant, ha right it is disable here thanks !!
[09:38] <troulouliou_dev> wgrant, bugtrack is mixed for ubuntu / mint ?
[09:39] <wgrant> troulouliou_dev: No, Mint is a separate project with a separate bug tracker
[09:39] <wgrant> The Ubuntu bug tracker is not for Mint bugs
[09:40] <troulouliou_dev> wgrant, ok
[10:19] <Terry_Guo> Hi, I just successfully packaged my source and uploaded them into Launchpad. They did get successfully built and published. The .org.tar.bz2 file is also uploaded. Now I made some changes to my source, what command should I use to repackage the source? I used "dpkg-buildpackage -sa -S", and then "dput ppa:/xxxx  yyy_source.change". The problem is that the .org.tar.bz2 file will be uploaded...
[10:19] <Terry_Guo> ...again. It is quite annoying. What should I do to just upload the necessary files? Thanks.
[10:19] <StevenK> Terry_Guo: -sa is the problem
[10:19] <StevenK> -sa says to include always
[10:19] <wgrant> -sa means "include the orig tarball always"
[10:19] <wgrant> The only thing it does is exactly what you're asking it to not do :)
[10:20] <Terry_Guo> So I should just use "dpkg-buildpackage -S"??
[10:20] <wgrant> Yes
[10:21] <Terry_Guo> OK. Thank you.
[10:23] <Terry_Guo> I once misunderstood that "-sa" means sign my files.  Thank you guys.
[10:24] <StevenK> Terry_Guo: It signs by default, there are two options to stop it doing so
[10:25] <Terry_Guo> Yes. I am reading the manual again.
[14:42] <ricotz> czajkowski, hi :)
[14:43] <czajkowski> ricotz: what's up
[14:43] <ricotz> yesterday an upload of a successful build timed-out and i am fearing it will happen again with that try https://launchpad.net/~ricotz/+archive/ppa/+build/4596196
[14:44] <ricotz> czajkowski, wgrant seems to be aware of such an internal time-out
[14:44] <czajkowski> yes I read the scroll back
[14:45] <ricotz> it seems to be like that now for over half an hours
[14:45] <ricotz> and i am hoping it won't fail again
[14:46] <ricotz> czajkowski, i just wanted to point you there maybe it can be debugged somehow
[14:47] <czajkowski> ricotz: nobody is around I'm afraid right now
[14:48] <ricotz> czajkowski, no worries, thank you
[15:03] <marcoceppi> So, I updated a daily recipe, requested another build and fo this error: https://launchpadlibrarian.net/140463202/upload_466117_log.txt I'm not sure what to do at this point.
[15:03] <marcoceppi> s/fo/got
[15:19] <czajkowski> cjwatson: have you ever seen an error like marcoceppi is getting before?
[15:19] <czajkowski> cjwatson: sprry for ping but StevenK and wgrant are not on
[15:20] <marcoceppi> czajkowski: I think I figured it out, I bumped the revision in the recipe link and it seem to have accepted that
[15:21] <czajkowski> ah ok if you'd had a ppa before and deleted it and need to reupload
[15:21] <czajkowski> you need to increase the version number
[15:22] <marcoceppi> czajkowski: right, which is what these recipe things do apparently. The version was slightly cryptic but made sense after a bit more poking
[15:25] <cjwatson> czajkowski: I have very little experience with recipes, sorry
[15:26] <czajkowski> cjwatson: np thanks
[15:27] <ricotz> czajkowski, marcoceppi, the source package itself is already present and one can't upload a new *different* tarball
[15:28] <ricotz> the recipe created a new tarball, but that exactly revision was already uploaded to the target ppa and maybe even already built
[15:40] <marcoceppi> ricotz czajkowski thanks for the help/clarification
[16:15] <rockstar> losa ping?
[16:23] <rockstar> Apparently mthaddon or mew are the guys I need.
[16:23] <wedgwood> rockstar: what's that you say?
[16:23] <wedgwood> (wedgwood=mew)
[16:23] <rockstar> wedgwood, hello sir
[16:24] <rockstar> I am looking to get the mailman pickle file of of the ~openstack mailing list so we can migrate away.
[16:26] <wedgwood> rockstar: Aha. I think I can do that for you.
[16:27] <rockstar> wedgwood, the -infra team got a pickle from flacoste when he was still engineering manager, so I assume that's *way* old. :)
[16:29] <wedgwood> rockstar: I don't expect that there's anything in that file that would be considered sensitive information, but as it is a convenient list of thousands of OpenStack users' email addresses, I'd feel a bit more comfortable handing it over to one of that team's administrators
[16:30] <rockstar> wedgwood, okay. Lemme get someone to make me an administrator. :)
[16:43] <rockstar> wedgwood, the due diligence is completed and I am an admin of that team.
[16:45] <wedgwood> rockstar: OK, just sorting out some sanitization of the file.
[16:45] <rockstar> wedgwood, okay, great.
[16:59] <sebbu> hi
[16:59] <sebbu> is/will launchpad be able to crosscompile & package for other distributions/systems ?
[17:41] <wedgwood> rockstar: ok, that's in the mail
[17:41] <rockstar> wedgwood, thank you kindly!
[17:43] <wedgwood> rockstar: or so I thought...
[19:11] <marcoceppi> So, I'm back to breaking things. Trying to request a build for a recipe and I'm getting "You have exceeded today's quota for ubuntu saucy." Is there anyway to squeak by this just one time?
[19:23] <dobey> marcoceppi: request the build as a different user
[19:23] <marcoceppi> dobey: ah, thanks. I'll have someone else on the team do that for me
[19:24] <dobey> i don't know of any other way. and i've complained about the recipe build request quota a fair bit ;)
[19:40] <sebbu> what is the current limit ?
[19:40] <sebbu> i'll soon be trying to set up automated build for at least one of my project, so i may try quite a few
[19:48] <dobey> sebbu: it's like 5 per day or something small
[19:49] <dobey> sebbu: if you want to set up a recipe, you can use "bzr dailydeb recipe.txt" to build the source package locally, and pbuilder or sbuilder to test build it in a clean chroot
[19:54] <sebbu> I don't have the same distribution @home
[19:55] <sebbu> all i have is a debian7 & a win7 ^^
[19:58] <ScottK> sebbu: The Debian debbootstrap knows about Ubuntu.  You can do it fine on a Debian system.
[19:59] <dobey> yeah. and if you use a service like s3 or whatever, you can spin up an ubuntu or debian instance to do it on as well
[20:05] <sebbu> don't have any service like s3
[22:53] <semiosis> the build time estimates are ridiculous. right after upload, said it would start building in 6 hours. an hour later, it said 7 hours.  now 7 hours since upload, says 3 hours.
[22:53] <semiosis> why even bother to have an estimate


[05:37] <didrocks> good morning
[06:08] <oSoMoN> good morning desktoppers
[06:12] <didrocks> salut oSoMoN
[06:12] <oSoMoN> salut didrocks
[06:23] <KGB-0> system-config-printer ubuntu/jammy b18f13b Gunnar Hjalmarsson * pushed 9 commits (first 5 follow) * https://deb.li/G1H1
[06:23] <KGB-0> system-config-printer ubuntu/jammy 8a7ad9a Jeremy Bicha debian/patches/ series Allow-installing-non-free-drivers-from-OpenPrinting.patch Hide-Printers-app-in-GNOME-and-KDE.patch Rename-app-to-Printers.patch * Add remaining Ubuntu patches * https://deb.li/35g5N
[06:24] <KGB-0> system-config-printer ubuntu/jammy 761a928 Jeremy Bicha debian/ control control.in gbp.conf * Update Maintainer and Vcs fields and debian/gbp.conf * https://deb.li/P3Qc
[06:24] <KGB-0> system-config-printer ubuntu/jammy cae8ee3 Jeremy Bicha debian/changelog * releasing package system-config-printer version 1.5.15-1ubuntu1 * https://deb.li/3JP9y
[06:24] <KGB-0> system-config-printer ubuntu/jammy e46e53e Jeremy Bicha debian/ (5 files in 2 dirs) * Merge tag 'debian/1.5.15-2' into ubuntu/master * https://deb.li/WYns
[06:24] <KGB-0> system-config-printer ubuntu/jammy eab997d Jeremy Bicha debian/changelog * releasing package system-config-printer version 1.5.15-2ubuntu1 * https://deb.li/3FifU
[06:40] <KGB-0> system-config-printer ubuntu/jammy 6e378ba Gunnar Hjalmarsson debian/rules * Fix syntax error in d/rules * https://deb.li/iUqXM
[07:04] <lissyx> oSoMoN, good, the cron is ready :) https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=symbols&selectedTaskRun=JuLzffjpSCeRHe-RczPocA.0
[07:14] <duflu> Hi didrocks, oSoMoN, lissyx
[07:50] <didrocks> hey duflu
[08:07] <ricotz> good morning desktopers :)
[08:13] <alocer> morning all
[08:16] <duflu> Hi ricotz and alocer
[08:25] <seb128> goood morning desltopers
[08:25] <seb128> hey duflu ricotz alocer
[08:26] <duflu> Hi seb128
[08:27] <didrocks> hey alocer, seb128
[08:33] <seb128> hey duflu, how is it going?
[08:34] <duflu> seb128, too much drama for one day but I am getting on top of it
[08:35] <duflu> How are you?
[08:36] <ricotz> duflu, seb128, didrocks, alocer, hello
[08:37] <seb128> lut didrocks
[08:37] <seb128> seems like IRC timeouted again :/
[09:45] <lissyx> oSoMoN, finger crossed.
[09:48] <oSoMoN> lissyx, I'm seeing the same build failures for arm64 dbgsym-enabled builds on Launchpad :/ So if the patch to reduce the debug info is working for you, we'll probably need to apply it conditionnally depending on the architecture
[09:51] <lissyx> what are the limitations on launchpad?
[09:52] <lissyx> maybe you can raise some more easily?
[09:58] <lissyx> oSoMoN, build seems to be successfully finishing for me
[09:59] <lissyx> oSoMoN, I'm not so used to quilt, how can we apply arch-based?
[10:01] <oSoMoN> lissyx, quilt doesn't allow to apply patches conditionnally, so the condition has to be written in the patch itself
[10:01] <oSoMoN> lissyx, or, put the patch in a different place, and apply it conditionnally from snapcraft.yaml
[10:02] <lissyx> oSoMoN, what solution do you prefer?
[10:03] <lissyx> given that for now we would need to condition on GitHub Actions running, or on ARM64 builds, I tend to think we might want to deal with it at snapcraft.yaml level?
[10:03] <lissyx> I'm also verifying if it it safe to apply always ...
[10:04] <lissyx> (I was suggested that because it is what opensuse does, and according to their spec file, it seems they do unconditionnally?
[10:07] <oSoMoN> yes, doing it conditionally at the snapcraft.yaml level sounds fine
[10:07] <oSoMoN> we already do quite a lot of conditional work there anyway
[10:08] <lissyx> I've failed to be able to pass env var to snapcraft, do you know how I could detect a GitHub Actions build VS a Launchpad build?
[10:12] <oSoMoN> lissyx, according to https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#file-systems , there's $GITHUB_WORKSPACE and $GITHUB_EVENT_PATH that we could use to detect a github action run
[10:12] <lissyx> ok
[10:12] <lissyx> lunch time
[11:25] <lissyx> oSoMoN, but do we get those inside snapcraft.yaml?
[11:30] <lissyx> oSoMoN, updated my patch
[11:32] <lissyx> oSoMoN, testing: https://github.com/lissyx/firefox-snap/actions/runs/2739152389
[11:55] <oSoMoN> lissyx, I would think that snapcraft doesn't strip the environment (but I might be wrong), so we should be seeing $GITHUB_WORKSPACE inside the build scriptlets
[12:05] <lissyx> oSoMoN, /bin/bash: line 53: GITHUB_WORKSPACE: unbound variable
[12:08] <lissyx> I'm going to rely on the symbols upload token file ...
[12:17] <ricotz> oSoMoN, is it possible that https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1951210 regressed?
[12:21] <ricotz> oSoMoN, this isn't working anymore in a clean VM with snapd 2.56.2 and firefox 102.1.0 snap
[12:55] <lissyx> oSoMoN, weird
[12:55] <lissyx> oSoMoN, https://github.com/lissyx/firefox-snap/runs/7519781080?check_suite_focus=true#step:5:21435
[12:55] <lissyx> oSoMoN, like it skipped the build ?
[13:11] <oSoMoN> lissyx, it looks like it stopped the build script after "patch -p1 patches/mozilla-reduce-rust-debuginfo.patch"
[13:11] <oSoMoN> maybe the patch didn't apply cleanly?
[13:12] <lissyx> there was no error reported
[13:59] <lissyx> oSoMoN, meh
[13:59] <lissyx> oSoMoN, "patch -p1 ..."
[13:59] <lissyx> like, it misses "<" ...
[14:01] <oSoMoN> heh
[14:44] <lissyx> oSoMoN, so the file is there: https://github.com/lissyx/firefox-snap/blob/debug-symbols_only_TESTS/patches/mozilla-reduce-rust-debuginfo.patch
[14:45] <lissyx> but it's not finding it? https://github.com/lissyx/firefox-snap/runs/7521824157?check_suite_focus=true#step:5:21357
[14:46] <lissyx> relative vs abslute path maybe?
[14:46] <oSoMoN> lissyx, you'll need to prefix the path to the patch with $SNAPCRAFT_PROJECT_DIR/
[14:46] <oSoMoN> because the build script is running relative to a different directory, not the project's root
[14:54] <lissyx> yeah
[14:56] <oSoMoN> ricotz, it looks like bug #1951210 regressed indeed
[15:03] <oSoMoN> a possible suspect: https://github.com/snapcore/snapd/commit/5abb3aab6b74db5a9e9920c537d673806603349a
[15:07] <oSoMoN> jbicha, could it be that the changes you made to interfaces/builtin/system_packages_doc.go in that commit regressed RO access to /usr/share/libreoffice/help ?
[15:07] <oSoMoN> the removal of 'apparmor.GenWritableProfile(emit, "/usr/share/libreoffice/help", 3)' looks suspicious to me
[15:09] <oSoMoN> I've verified that /usr/share/libreoffice is mounted in the snap's namespace, but not its subdirectories
[16:16] <lissyx> oSoMoN, 1h28m still building, we might be on something :)
[18:07] <lissyx> oSoMoN, yallah! https://github.com/lissyx/firefox-snap/runs/7522784969?check_suite_focus=true#step:5:33874
[18:08] <lissyx> oSoMoN, wrong token, so it's all good
[18:08] <lissyx> oSoMoN, I'm going to change the URL back to the prod server on my other PR
[19:59] <ricotz> oSoMoN, thanks for confirming


[05:44] <pavlushka> Almost morning Kilos
[05:58] <Kilos> morning pavlushka hopefully power stays on today. 3 days of 8am to 5pm no power
[14:02] <Kilos> pavlushka  ping
[14:05] <pavlushka> Kilos: pong
[16:45] <Kilos-> pavlushka  sorry. power cut and i  missed you last messages


[01:18]  * bhale pokes Hobbsee with a pointy stick
[01:28] <ajmitch> careful there...
[01:34] <bhale> :/
[01:43] <ajmitch> how's it going? haven't seen you around for awhile
[02:05] <bhale> ajmitch: its all good, I travel like a mad man
[02:05] <bhale> ajmitch: you?
[02:05] <ajmitch> busy with work, clients driving me mad, etc
[02:05] <ajmitch> nothing out of the ordinary
[02:06]  * Hobbsee pokes bhale back
[02:06] <bhale> San Diego was lovely, beats my usual destinations
[02:18] <bhale> whats up Hobbsee ?
[02:19] <Hobbsee> bhale: well, i dist-upgraded my server, and part of it's exploded, so...
[02:19] <bhale> oops
[02:20] <bhale> my desktop did that yesterday, turned out to be bad blocks
[02:20] <bhale> I cleaned it up
[02:26] <ajmitch> Hobbsee: do you get to keep all the bits?
[02:27] <Hobbsee> ajmitch: yeah, seems so
[02:28] <ajmitch> so what part exploded? uninstallable stuff, or everything segfaulting with a bad filesystem?
[02:28] <bhale> mine refused to start X, I found out the fs was mounted RO with errors
[02:29] <bhale> it seems like I lost power the week I was away
[02:29] <bhale> although the drive would have been idle for days and ext3 usually doesn't have this sort of problem
[02:30] <ajmitch> idle except for daily cron jobs?
[02:30] <bhale> not much there besides apt-get update and updatedb
[02:31] <ajmitch> updatedb or find takes quite awhile on my desktop
[02:31] <bhale> yeah mine is getting pretty sad
[02:31] <bhale> its only got 512mb
[02:31] <ajmitch> mine only has 4GB, but far too many files
[02:31] <bhale> struggles to run a few tabs in FF
[08:41] <slomo_> mvo: gnome-app-install needs to provide the gstreamer-codec-install alternative and needs to accept gstreamer-codec-install as argv[0] ;)
[08:48] <mvo> slomo_: thanks, is it gstreamer itself that has changed and now call gstreamer-codec-install instead of gnome-codec-install? what sync/merge brought in thiose changes?
[08:50] <slomo_> mvo: one of the gst-plugins-base syncs brought this change... the installer is now called /usr/bin/gstreamer-codec-install which is an alternative provided by gnome-codec-install in debian
[08:50] <slomo_> mvo: as ubuntu only has parts of the new codec installation stuff gnome-app-install needs to get this small change for this release ;)
[08:51] <slomo_> seb128: please sync gst-plugins-bad 0.10.8-3 from experimental... and only this version, not <IP_ADDRESS>-1 ;) is this possible?
[08:51] <seb128> slomo_: can sync any source which is available on the mirrors, is that the case for this one? and why not the new version? ;-)
[08:52] <seb128> slomo_: what about the new good?
[08:53] <slomo_> seb128: well, the new good and bad are pre-releases... except a small regression in flvdemux(from -bad) that will be fixed with next pre-release they should be good
[08:54] <slomo_> if you want them, take them :) but i can't guarantee that the releases will be before intrepid release (but they should be end of the week or monday)
[08:54] <seb128> slomo_: we have a running bug about dvd playing not working in intrepid at the moment do you know about that?
[08:55] <slomo_> yes, this will be improved by 0.10.8-3 and newer (i've uploaded -3 for the dvd bug)
[08:56] <seb128> ok
[09:01] <huats> morning everyone
[09:03] <slomo_> seb128: do you want the bad/good pre-releases? in theory we could get the real releases into intrepid-updates, no?
[09:04] <seb128> slomo_: not sure about any of those, depends how much unstability they can bring, it's late for changes in intrepid, stable updates are limited to bug fix versions usually
[09:05] <slomo_> seb128: the releases will only have regressions fixed and cosmetic changes compared to the pre-releases so that part should be fine
[09:06] <seb128> right, the question is to know if upgrading to the current candidate will give something better than what intrepid has
[09:15] <seb128> ups
[09:15] <seb128> mvo: !!!!
[09:16] <slomo_> seb128: i know a few files that don't work with the stuff in intrepid but work with the pre-releases ;) well, IMHO it should be an improvement at several places and the only known regression will be fixed with the next pre-release in the next two days
[09:16] <seb128> ok good, I'll do the syncs then
[09:16] <seb128> mvo: closing xchat-gnome tabs accidentally again, I blame you ;-)
[09:18]  * mvo runs from seb128
[09:18] <seb128> mvo: ;-)
[09:43] <seb128> pitti: how do I check the tzdata dst for a timezone?
[09:46] <pitti> seb128: zdump -v Europe/Berlin
[09:46] <pitti> seb128: and grep/look for the year you are interested in
[09:56] <didrocks> morning
[09:56] <huats> hey didrocks !
[09:56] <didrocks> hi huats :)
[09:59] <seb128> pitti: zdump -v Europe/Brussel has only 1901 and 2038?!
[09:59] <seb128> pitti: trying to look at bug #281956
[09:59] <seb128> arg, typo
[10:00] <seb128> the intrepid tzdata looks correct
[10:02] <didrocks> seb128: I think this bug can be linked: bug #43644
[10:02] <seb128> grrr, wrong focus again
[10:02] <seb128> didrocks: no
[10:02] <seb128> didrocks: that's a tzdata issue
[10:03] <seb128> is there anybody using hardy there?
[10:03] <seb128> huats: hey ;-)
[10:03] <didrocks> yes, I have it in a VM :)
[10:03] <huats> seb128: in the glom update (I am working on it right now), we are currently taking the bdeps for maemo, which is useless I think. Don't you think I can safely put a disable-maemo
[10:03] <huats> ?
[10:03] <huats> hey seb128 :)
[10:03] <seb128> can you "zdump -v Europe/Brussels | grep 2008"?
[10:03] <huats> I am here
[10:03] <huats> I am doing
[10:04] <seb128> huats: dunno about the maemo build if that's useful you should ask the #ubuntu-mobile guys if they are the one who added that there
[10:04] <didrocks> seb128:
[10:04] <huats> nobody add it, it is the defalt...
[10:04] <didrocks> Europe/Brussels  Sun Mar 30 00:59:59 2008 UTC = Sun Mar 30 01:59:59 2008 CET isdst=0 gmtoff=3600
[10:04] <huats> http://paste.ubuntu.com/56950/
[10:04] <pitti> seb128: hm, I really doubt that Brussels has different DST rules than the rest of europe?
[10:04] <didrocks> oupss, huats as already done it :)
[10:05] <pitti> last Sunday in March and October, that looks just fine to me
[10:05] <seb128> pitti: it doesn't, I'm trying to understand this bug
[10:08] <seb128> huats: not sure, if it's not useful don't build using it?
[10:09] <huats> seb128: I am asking on -mobile :)
[11:01] <glatzor> morning mvo
[11:01] <glatzor> mvo, what is your plan regarding bug #281606?
[11:02] <mvo> glatzor: its fix commited
[11:02] <glatzor> mvo, do you want to rename gnome-codec-install to gstreamer-codec-install or patch gstreamer?
[11:02] <mvo> glatzor: I upload in a sec, I added the alternative patch and renamed it
[11:02] <glatzor> mvo, ui great
[11:03] <mvo> done
[11:03] <mvo> glatzor: I guess you need to update packagekit now as well, right?
[11:03] <glatzor> mvo, so gstreamer0.10-packagekit no longer has to conflict with gnome-app-install
[11:03] <mvo> glatzor: yes, just update the alternative
[11:03] <glatzor> mvo, In the ppa version I just shipped alternatives for both (gnome|gstreamer)-codec-install
[11:03] <glatzor> :)
[11:04] <mvo> aha
[11:04] <didrocks> seb128 & mvo: what do you thing about my commentary and tests on bug #212098. Do we only make a SRU for hardy?
[11:07] <seb128> didrocks: not sure, pre-adding the user is an ubiquity workaround apparently
[11:07] <seb128> didrocks: would be nice to fix in hardy in any case right
[11:08] <didrocks> seb128: if someone else can confirm my test for intrepid, it would be great (yes, it's maybe ubiquity which make it and not smb-client)
[11:08] <didrocks> but ok, I will do the trick for hardy
[11:09] <seb128> didrocks: we discussed it some days ago and it was pointed that the first user was added to the group but that was an ubiquity workaround, is that true of any admin user?
[11:10] <glatzor> bye mvo, I have to leave for work!
[11:11] <didrocks> seb128: as I told in my test, I tried to add a second admin user (with user and group GNOME tool) and this one was added to the samba group as well (so, no, it's not an ubuquity trick, the admin profile seems to contains the sambashare group)
[11:11] <seb128> ok
[11:11] <seb128> didrocks: are you sure that's not only because users-admin automatically add users to this group?
[11:16] <didrocks> seb128: I do not know very well how the "profile" in users-admin work actually
[11:16] <seb128> didrocks: you can switch to the groups tab to see what groups are selected
[11:17] <didrocks> seb128: ok, I will confirm that this afternoon (currently installing intrepid beta on this computer)
[11:18] <seb128> ok
[11:18] <seb128> time for lunch here bbl
[11:18] <didrocks> have a good lunch :)
[11:18] <seb128> thanks, you too
[12:29] <crevette> hello there
[12:29] <crevette> who should I contact about a pwc/v4l2 regression?
[12:30] <crevette> is there a chan/person dedicated for such problem, I would like debug that to open a bug report
[12:31] <seb128> crevette: try rather #ubuntu-devel, you might want to try to ping kees when he's be around
[12:31] <seb128> crevette: lut
[12:31] <crevette> salut seb128
[12:31] <crevette> merci
[12:32] <seb128> crevette: could you look at bug #282325?
[12:32] <crevette> it is shame that it was working fine 2 weeks ago
[12:32] <crevette> okay I'll try
[12:33] <seb128> crevette: thank you
[12:33] <seb128> I should really get some bluetooth phone or something
[12:33] <crevette> seb128: it is working fine for me
[12:34] <seb128> crevette: ok, so you can test now? ;-)
[12:34] <crevette> I pickup all the phone of the people around to test
[12:34] <crevette> and when I package it was working fine
[12:34] <crevette> pckaged
[12:34] <crevette> packaged
[12:34] <seb128> crevette: thanks for your work on those btw
[12:34] <crevette> no problemo, I was happy to have bluez 4 in intrepid
[12:35] <crevette> perhaps the phone capabilities in nautilus-sendto doesn't detect well those supported by it's phone
[12:35] <crevette>  phone detection capabilities
[12:35] <seb128> I've no clue about bluetooth debugging
[12:36] <seb128> do you know if there is a command line call to try to see if the issue is a obex one rather?
[12:37] <seb128> fta, Keybuk: would be nice to update cairo to 1.6 before intrepid, did any of you has a clue of what to do since they dropped the lcdfilter changes?
[12:42] <huats> seb128: regarding the bakery update, james_w is asking me if I have a FFe :)
[12:42] <huats> not sure that the answer seb128 knows about it is enough :)
[12:44] <seb128> huats: I would say it can wait for intrepid+1 now since that starts being quite some updates
[12:44] <huats> seb128: ok
[12:45] <crevette> seb128: I did a sponsoring request for nemiver also
[12:45] <seb128> crevette: right I read the mails about this one
[12:56] <seb128> huats: don't bother too much, those updates are not important for intrepid, upstream just like to have current versions available
[12:56] <seb128> but bakery is not really useful without the other updates
[12:56] <huats> seb128: I know...
[12:56] <huats> but at least the work is in LP which is way safer than my laptop :)
[12:57] <crevette> seb128: should I do a FFe for nemiver
[12:57] <huats> seb128: I also have the goocanvasmm package now which is ready (I just need to fill correctly the copyright file)
[12:58] <huats> I'll put it on REVU as soon as package can be built on jaunty
[13:01] <Keybuk> seb128: does the old patch not apply from 1.4 ?
[13:04] <Keybuk> if not, I would prefer us to wait until the next release when we'd have time to work to keep the patch
[13:05] <Keybuk> we shouldn't do upstream version updates this close to release if it means losing functionality
[13:06] <Keybuk> we have resource from David Mandala's team available to help us rework the patch, it might be worth asking lool if he can spare anyone's time to look at it
[13:06] <Keybuk> might be worth asking mvo if he's interested in looking at it?
[13:06] <Keybuk> (and has the time)
[13:07] <seb128> Keybuk: I need to check if the old patch applies, we also have the option to use the new patch they dropped before 1.6
[13:07] <seb128> Keybuk: mvo has lot to do already
[13:08] <Keybuk> did you ask him? :p
[13:08] <Keybuk> I'm not suggesting he doesn't, just that it might interest him
[13:08] <Keybuk> (it might not)
[13:09] <seb128> Keybuk: and I didn't suggest dropping the patch but I would really prefer to avoid staying on an unstable version, 1.6 has some bug fixes that would be nice to get in intrepid and that would avoid upstream tensions
[13:09] <Keybuk> I understand, is why I suggested some people who might be able to help out getting the patch to apply to 1.6 so we can update it
[13:09] <seb128> Keybuk: no I didn't be I pinged him with some other things already and he replied ETOOMUCHTODO
[13:09] <Keybuk> ok, try asking lool - his team are officially "nothing to do" afaiui
[13:10] <seb128> Keybuk: ok thanks, will try to see if fta or lool are interested to work on this one
[13:10] <Keybuk> lool himself might not have the time, but someone on his team might
[13:10] <seb128> ok thanks
[13:10] <seb128> lool: hello ;-)
[13:11] <Keybuk> seb128: also might be worth posting a general "HELP!" to ubuntu-devel{,-discuss}/desktop and seeing if any community member wants to give it a go?
[13:12] <seb128> Keybuk: that's worth trying, I would just prefer to have somebody having a clue doing the update just before intrepid rather than sponsoring changes I've no real clue about made by some community member who might have no real clue about those either ;-)
[13:13] <Keybuk> I'm more than happy to review any diffs that come in
[13:13] <seb128> Keybuk: I'll wait for fta's reply first, since he did the previous updates
[13:13] <Keybuk> being on the ML, I'd see them at the same time you do
[13:13] <seb128> Keybuk: ok noted, thanks
[13:15] <mvo> Keybuk, seb128 what patch is this?
[13:15] <seb128> mvo: the cairo lcdfilter
[13:15] <Keybuk> mvo: the lcdfilter patch to cairo, that sets the freetype lcd filter setting based on the fontconfig xsetting
[13:15] <Keybuk> it's based on an original patch by David Turner: http://david.freetype.org/lcd/
[13:16] <seb128> mvo: we had it as a distro patch for some cycle, they commited something similar upstream during 1.5 and reverted for 1.6 because they figured that the patch didn't match their quality standard and they wanted to roll 1.6
[13:16] <Keybuk> which we extended to support the fontconfig stuff
[13:16] <Keybuk> part of it went upstream, then came back out again
[13:18] <mvo> hm, I'm indeed pretty busy and would prefer someone else taking it if possible
[13:18] <Keybuk> ok, np
[13:18] <seb128> mvo: don't worry, I'll see if fta is interested he did the previous cairo updates
[13:43] <lool> seb128: What package do you need help for?
[13:43] <lool> tell me it's not pygobject/pygtk
[13:44] <seb128> lool: cairo, but speaking about pygtk apparently the debug variant is broken again, bug #282320
[13:44] <seb128> lool: cairo, we had it as a lcdfilter distro patch for some cycle, they commited something similar upstream during 1.5 and reverted for 1.6 because they figured that the patch didn't match their quality standard and they wanted to roll 1.6
[13:45] <seb128> lool: so we want the lcdfilter change and 1.6
[13:45] <seb128> lool: I'm waiting for fta to reply to my ping since he did the previous cairo update
[13:55] <didrocks> seb128: so, I confirm, when you want to create a new user and choose the "Administrator" profile, you get the "Share files with the local network" privilege which corresponds to adding you to the sambashare group
[13:55] <seb128> didrocks: ok what I though
[13:56] <didrocks> so, appart from the target cases I described (special cases corresponding to advanced use), there is nothing to perform for intrepid. But a SRU for hardy is needed
[13:56] <seb128> right
[13:58] <lool> Ok, found the pygtk issue
[13:59] <seb128> lool: cool ;-) what was it?
[14:01] <lool> PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
[14:01] <lool> in configure.ca
[14:02] <seb128> grrrr, this focus issue starts being really annoying
[14:02] <seb128> lool: ah, I see
[14:02] <lool> we're really luck that the current m4 macro works, it relies on the "Refs" output to match between two runs
[14:43] <lool> Pff another xvfb failure again,
[16:36] <fta2> seb128, http://launchpadlibrarian.net/18500998/buildlog_ubuntu-intrepid-hppa.xulrunner-1.9_<IP_ADDRESS>%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:36] <seb128> hi fta2, when did it try to build?
[16:39] <fta2> just now
[16:40] <seb128> fta2: I would not bother about hppa, it's usually lagging behind a lot
[16:41] <seb128> fta2: did you read the conversation about cairo before?
[16:41] <fta2> seb128, hm, no
[16:41] <fta2> seb128, about 1.8.0 ?
[16:41] <seb128> fta2: to summarize updating to 1.8 would be nice, do you want to do the update? ;-)
[16:42] <fta2> seb128, i wanted to do it but the lcd patch needs a decision
[16:42] <seb128> fta2: which one?
[16:42] <asac> fta2: could you also talk to vlad about performance with xul + cairo 1.8.0?
[16:42] <seb128> fta2: is it hard to undo the commit they did to drop the patch?
[16:42] <fta2> should we keep the patch as of 1.7.6 or reuse the one we had up to 1.7.4
[16:42] <asac> not that we push a heavy impact bug if its known and maybe there is a hack/fix or something :)
[16:43] <fta2> seb128, afaik, 1.8.0 is just 1.7.6 with the all the lcd patches reverted, so it's easy
[16:43] <seb128> fta2: they didn't fix any other bug?
[16:44] <fta2> seb128, i'll recheck but 1.8.0 appeared just a few days after 1.7.6 once they decided the lcd patch was too ugly
[16:48] <seb128> fta2: they did a lot of commits apparently during those days, anyway have 1.8 not dropping lcdfilter would be nice ;-) was the patch we had before working better?
[16:48] <seb128> or working differently?
[16:50] <fta2> seb128, it was different, but working better with our customized fontconfig. I changed fontconfig accordingly, but it's still slightly different, depending who you ask
[16:50] <seb128> fta2: do whatever is easier, I would say use whatever we have now in 1.7.6
[16:51] <fta2> ok, that was my preferred choice too
[17:06] <lapo> hi
[18:09] <crevette> hey seb128,
[18:09] <crevette> ca s'en va et ca revient ?
[18:09] <seb128> re crevette
[18:09] <crevette> :)
[18:10] <crevette> seb128: need an advice to build a package with debug to track the problem with nautilus-sendto
[18:10] <seb128> crevette: just edit debian/rules to add the configure option you want
[18:10] <crevette> hmm not that way
[18:11] <crevette> I want to write code to add debugging statement
[18:11] <crevette> should I put the resulting package in my ppa or this is not wanted
[18:12] <seb128> crevette: edit the code directly or use cdbs-edit-patch to create a patch in the debian directory
[18:12] <crevette> should I put a suffix like ~debuild1
[18:18] <pedro_> pitti: if you have a time, may you look at bug 269651 , it has a few dups already
[18:24] <pitti> pedro_: I couldn't really make sense of it either, but as a first step I'll report it upstream
[18:24] <pedro_> pitti: ok, thanks ;-)
[18:45] <Laney> Hey, bug #263026 has recently been resolved upstream. I'd like to backport the fix if it applies cleanly. What do people think?
[19:13]  * pochu waves hello
[19:28] <james_w> Laney: hey
[19:28] <james_w> Laney: how intrusive is it?
[19:28] <Laney> james_w: It doesn't seem very, just small patches to two files
[19:28] <Laney> james_w: See http://svn.gnome.org/viewvc/file-roller?view=revision&revision=2515
[19:29] <Laney> But most of the changes are renaming of variables
[19:31] <james_w> Laney: looks like a one-line change to me, excluding the renaming.
[19:31]  * Laney nods
[19:31] <james_w> Laney: should be fine to pull it in, assuming it's not dependent on a port to GIO or something
[19:32] <Laney> I am testbuilding it to see
[19:32] <Laney> james_w: What did Windows do to my debdiff, btw?
[19:32] <Laney> I literally copied it to public_html, saved it in IE and then attached it to the bug :(
[19:33] <Laney> line endings, I presume
[19:33] <james_w> it was z:/something/debdiff
[19:33] <james_w> and then line-endings, yeah
[19:33] <Laney> bah
[19:33] <james_w> until the line-endings I thought you might have just been playing a joke
[19:33] <Laney> Saving a file should *not* change it in any way
[19:34] <Laney> Well I left it building and then went to campus, and tested/uploaded once I got there
[19:34]  * Laney strops
[19:34] <Laney> in other, positive, news, the file-roller fix is good \o/
[20:02] <Laney> Patch is up there if anyone's interested
[20:02]  * Laney moshes
[20:02] <james_w> :-)
[21:01] <Laney> YES
[21:01] <Laney> My pet gnome-terminal bug has been fixed \m/
[21:01] <Laney> we have have have to get this
[21:03] <Laney> Will new gconf schemas be imported automatically (by the packaging)?
[21:09] <crevette> Laney: which one ?
[21:09] <Laney> crevette: http://bugzilla.gnome.org/show_bug.cgi?id=548600
[21:33] <Laney> hallelujah, it works
[22:12] <james_w> seb128: hey, are you still working? Do you have a couple of minutes for gnome-session stuff?
[22:13] <seb128> james_w: I'll close IRC soon but ask your questions, I'll tell you if that's rather something for tomorrow
[22:14] <james_w> seb128: I've got a patch to add a third logout dialog with all the options, it's pretty easy, and doesn't change any existing behaviour.
[22:15] <seb128> cool
[22:15] <james_w> :-)
[22:16] <seb128> james_w: sorry, still this compiz issue which send key events to the wrong dialogs
[22:16] <james_w> that must suck
[22:16] <seb128> I keep closing things on other workspaces
[22:16] <seb128> yeah, the focus stay on workspace when switching to an another
[22:16] <james_w> firstly, I'd like to know where to propose this change, would http://bugzilla.gnome.org/show_bug.cgi?id=507101 be a good place?
[22:17] <seb128> anyway, you were saying, you got a working patch which doesn't change the current dialogs?
[22:17] <james_w> or a new bug, or a mailing list?
[22:17]  * dobey just doesn't use compiz :)
[22:17] <seb128> try asking to vuntz but when we discussed that he said that upstream was not interested by having one dialog listing everything
[22:18] <seb128> though having the option should not be an issue if that's not used by default
[22:18]  * dobey agrees with the not having one dialog listing everything sentiment
[22:18] <seb128> that's some extra code to maintain but should not complicated
[22:18] <james_w> ok, I'll talk to him, thanks.
[22:19] <seb128> you're welcome
[22:19] <james_w> my other question was about what happens when you press the power button
[22:19] <james_w> at the moment if you have g-p-m preference set to "ask me" then it asks you if you want to log off or switch user when you press the power button
[22:20] <dobey> pressing the power button to change users seems rather odd to me :)
[22:20] <james_w> I believe g-p-m asks gnome-session to do this via libSM, a I correct?
[22:21] <dobey> i don't think it's via SM, but i think it does just open the log out dialog
[22:23] <seb128> james_w: it uses the gnome_client_* calls to display the session dialog
[22:23] <seb128> 		gpm_info_explain_reason (manager->priv->info, GPM_EVENT_NOTIFICATION,
[22:23] <seb128> 					_("GNOME interactive logout."), reason);
[22:23] <seb128> 		gnome_client_request_save (gnome_master_client (),
[22:23] <seb128> 					   GNOME_SAVE_GLOBAL,
[22:23] <seb128> 					   TRUE, GNOME_INTERACT_ANY, FALSE, TRUE);
[22:23] <dobey> yeah
[22:24] <james_w> seb128: that's what I had found, I just get lost trying to follow it through to see what gets triggered at the other end
[22:26] <seb128> james_w: something in gnome-session, try looking to gsm-xsmp-client.c
[22:27] <Laney> Is something special done with gconf schemas? I'm patching one for this gnome-terminal fix but the new version doesn't seem to be getting installed.
[22:28] <james_w> seb128: ah, I see it this time I think, it's done with signals.
[22:28] <james_w> Laney: what do you mean by "installed"?
[22:29] <Laney> james_w: Well, I don't see the new version in /usr/share/gconf/schemas
[22:29] <james_w> Laney: I believe the files are just installed there as normal files
[22:29] <james_w> Laney: are you patching it from debian/patches?
[22:29] <Laney> yes
[22:29] <james_w> what's the patch system?
[22:30] <james_w> have you added it to debian/series or whatver?
[22:30] <Laney> cdbs, and yes the patch is being applied
[22:30] <james_w> good start :-)
[22:30] <james_w> Laney: extract your built .deb and check the file contents
[22:30] <Laney> It's not there - hence my question
[22:30] <Laney> The existing version has translations in it, so I'm wondering if some magic happens
[22:31] <james_w> ooh, maybe
[22:32] <james_w> seb128: ok, making it show the shutdown dialog wouldn't be hard, but I don't know if that would lead to unexpected behaviour elsewhere, do you? Do you showing the shutdown dialog would be better?
[22:33] <seb128_> james_w: my internet disconnected apparently, what did you read or write after that?
 seb128: that's what I had found, I just get lost trying to follow it through to see what gets triggered at the other end
 james_w: something in gnome-session, try looking to gsm-xsmp-client.c
[22:33] <seb128_>  hum, no, that's rather the code handling the clients
[22:33] <seb128_>
[22:33] <seb128_> james_w: gsm-manager.c on_xsmp_client_logout_request()
[22:34] <james_w> ah, missed that bit, I was figuring it out for myself :-)
[22:34] <james_w> once I had I asked
 seb128: ok, making it show the shutdown dialog wouldn't be hard, but I don't know if that would lead to unexpected behaviour elsewhere, do you? Do you showing the shutdown dialog would be better?
[22:35] <seb128_> that's something worth raising upstream I think
[22:35] <Laney> seb128_: Do you know anything about gconf schemas - specifically if updating them in new package versions requires anything special? I'm trying to patch gnome-terminal but the new version doesn't get installed.
[22:35] <dobey> Laney: did you change the .schemas file, or .schemas.in?
[22:35] <seb128_> Laney: did you patch the .schemas.in correctly?
[22:36] <Laney> I patched the .schemas.in
[22:36] <seb128_> Laney: if those are debian changes be carreful .gconf-defaults in the debian directory are used before schemas
[22:36] <Laney> They're upstream changes
[22:36] <seb128_> did you try on a new user or did you unset you settings?
[22:37] <seb128_> if the application write user key you will not pick new system defaults
[22:37] <Laney> I don't see the new version in /usr/share/gconf
[22:37] <Laney> (nor in dpkg --contents)
[22:37] <seb128_> what do you mean?
[22:37] <seb128_> what change do you try do to exactly?
[22:37] <Laney> Shouldn't it be installed there?
[22:37] <Laney> I'm including an upstream patch which adds (back) some keys to the schema
[22:38] <seb128_> Laney: is it installed in the current version?
[22:38] <Laney> There's a schema in there already, yes
[22:38] <seb128_> Laney: btw thanks for backport changing but don't bother backport stable GNOME changes, 2.24.1 will be in intrepid
[22:38] <seb128_> s/changing/chnages
[22:38] <dobey> you're saying the file doesn't exist? are you looking at the right package?
[22:38] <dobey> Laney: ie, gnome-terminal-data instead of gnome-terminal?
[22:39] <Laney> seb128_: Hm, how do I know which are going to be in .1 and which will be in 2.25?
[22:39] <james_w> seb128: yeah, I'll bring it up upstream, just wanted to know if you could think of anything I was missing.
[22:39] <Laney> dobey: Oh. Yes, that might be it ;)
[22:39] <seb128_> Laney: look if it has been commited to gnome-2-24 if there is one or trunk
[22:39] <dobey> heh
[22:39] <Laney> dobey: Didn't sbuild with -A
[22:39]  * Laney runs
[22:39] <dobey> there you go.
[22:40] <Laney> (although, shouldn't gnome-terminal depend on -data = ${Source:Version}?
[22:40] <seb128_> Laney: the bug fixes will likely go to next stable tarballs
[22:40] <dobey> Laney: the version number didn't change in your build perhaps?
[22:41] <Laney> it did
[22:41] <dobey> the version changed, or the -0ubuntuN changed?
[22:41] <seb128_> Laney: no, usually we use >= rather, strict depends create issues during updates between i386 and other archs
[22:41] <Laney> Ah, it depends on gnome:version rather than source:version
[22:43] <seb128_> enough for today see you tomorrow
[22:44]  * Laney rocks out
[22:44] <Laney> nice one dobey
[22:44] <dobey> james_w: it's probably best to fix it so that there is some way to request either dialog, rather than having only one dialog be usable
[22:44] <Laney> the gnome-terminal fix isn't on the 2.24 branch
[22:44] <Laney> I hope it'll still get in as the bug is very very irritating
[22:45] <james_w> dobey: true
[22:45] <dobey> james_w: you probably don't want gnome-session-save --kill to bring up the shutdown dialog, but instead the log out dialog (or rather, it should probably have --logout and --shutdown options instead)
[22:45] <james_w> it does now
[22:45] <dobey> oh?
[22:45] <james_w> that was changed recently because --kill was confusing apparently
[22:45] <james_w> --shutdown-dialog and --logout-dialog
[22:46] <dobey> ah. do both options do the same thing?
[22:46] <james_w> I propose adding --combined-dialog
[22:46] <james_w> no, one shows the shutdown dialog, the other the logout dialog :-)
[22:46] <dobey> if they already behave differently, then the code probably already allows doing either one, so patching gpm to use the shutdown dialog instead (matching the gnome-session-save code), would probably be good :)
[22:47] <james_w> yeah, the problem is that gpm doesn't directly call gnome-session
[22:48] <dobey> anyway, i should try to finish what i'm working on
[22:48] <james_w> seb pointed out where the call comes in, so you could change that, but I don't know what else will make that sort of a request
[22:48] <dobey> james_w: well, you could just make it g_spawn_command_line_async ("gnome-session-save --shutdown-dialog"); :)
[22:48] <james_w> heh :-)
[22:48] <dobey> later :)