[06:27] <pitti> Good morning
[06:28] <robru> pitti, good evening!
[06:28] <robru> pitti, did you have a good flight home?
[06:29] <pitti> it was uneventful, and everything on time, so "yes"
[06:29] <robru> pitti, excellent ;-)
[06:29] <pitti> as "good" as a flight back to Europe can be :)
[06:29] <pitti> still jetlagged and a bit ubuflu-ed, but that'll settle
[06:29] <robru> pitti, I had a bad connection and got to spend a day in Seattle. The weather was beautiful and I took a ride on a ferris wheel. What fun! ;-)
[06:30] <darkxst> pitti, hi
[06:31] <pitti> hey darkxst, how are you?
[06:31] <pitti> robru: hm, you didn't get very far then
[06:31] <pitti> robru: but I'm glad you could make the best of it!
[06:32] <robru> pitti, no, not very far at all ;-) but home now and gearing up for a fresh work week.
[06:32] <darkxst> pitti, good
[06:35] <darkxst> pitti, so packagekit stuff seems to be working now, but I need to add a new api to get language lists from language-selector
[06:35] <darkxst> I suspose I need to add that to packagekit, before the python plugins will work?
[06:37] <pitti> darkxst: depends; our preferred implementation in Ubuntu is language-selector
[06:37] <pitti> darkxst: err, aptdaemon
[06:37] <pitti> language-selector ships an aptdaemon plugin for "provides: locale"
[06:38] <pitti> in /usr/lib/python3/dist-packages/language_selector-0.1.egg-info/entry_points.txt
[06:39] <pitti> unfortunately packagekit discontinued the apt backend and only has the aptcc backend now, which doesn't understand these plugins any more
[06:39] <pitti> so if you actually use packagekit, you can't use these python plugins any more
[06:39] <pitti> but again, we actually want to use aptdaemon in Ubuntu
[06:41] <darkxst> so I just add it there, and wherever in the python scripts?
[06:41] <pitti> darkxst: what exactly do you want to add?
[06:42] <pitti> darkxst: the specification for new what-provides queries needs to go into packagekit first indeed
[06:42] <darkxst> pitti, I want to get the list of available languages
[06:42] <pitti> hm, that doesn't really need a PK query
[06:42] <darkxst> hmm, Laney suggested to do in package-kit
[06:42] <pitti> accountsservice already has that AFAIK
[06:43] <darkxst> pitti, as in uninstalled langugage packs
[06:43] <pitti> that is, installed locales which don't have langpacks installed?
[06:44] <darkxst> no, the locales are not installed (this is for g-c-c region capplet)
[06:44] <pitti> https://gitorious.org/packagekit/packagekit/blobs/master/docs/provides-component-naming.txt
[06:44] <pitti> querying for a particular language is exactly what LANGUAGE_SUPPORT does
[06:45] <pitti> locale -a -> installed locales
[06:46] <pitti> and language-selector has some code to determine the set of available languages from /usr/share/i18n/SUPPORTED
[06:46] <pitti> (that bit is not package related)
[06:46] <darkxst> pitti, yes I wanted to hijack the language-selector code, rather than read SUPPORTED and check each locale to see if langugage packs are installed
[06:48] <darkxst> my first idea was to add a dbus interface to language-selector
[07:09] <darkxst> pitti, so what would you suggest I do then?
[07:38] <pitti> darkxst: I think you should just copy the logic from l-s, instead of changing PK's API (as getting this released will take a while)
[07:39] <darkxst> pitti, I really don't want to duplicate the l-s code, and besides converting python code into C is not much fun
[07:41] <pitti> I thought rodrigo_ already had a g-c-c branch for this stuff a while ago
[07:41] <pitti> so I guess that still didn't land
[07:41] <darkxst> rodrigo's branch was never finished
[07:42] <darkxst> he just read SUPPORTED directly, but that ends up with a list with lots of duplicates
[07:43] <darkxst> actually I don't think he ever tested his code, it was incredibly broken
[08:06] <darkxst> pitti, thers actually quite a lot going on in l-s, like reading hardcoded lists and intersecting them with other lists
[08:13] <pitti> yeah, I know
[08:49] <darkxst> pitti, so l-s isnt going away anytime soon right? since Kubuntu and Xubuntu use it also
[08:49] <pitti> we actually wanted to drop it in favor of the g-c-c region panel for quite a while now
[08:49] <pitti> but it seems the full design has never been implemented there
[08:50] <darkxst> pitti, you can drop the gui, but there is nothing there to handle ubuntu languages
[08:50] <pitti> the idea was to use the PK what-provides API
[08:50] <pitti> and language-selector common implements that for aptdaemon and PK's apt backend
[08:51] <darkxst> so you can't drop l-s anyway
[08:51] <darkxst> it would be much nicer to just get a list of available languages from there as well
[08:51] <pitti> right
[08:52] <pitti> well, we can drop it once g-c-c DTRT
[08:53] <pitti> but somehow the upstream g-c-c needs to figure out a list of available locales?
[08:54] <pitti> how should it do that other than parsing SUPPORTED?
[08:54] <pitti> AFAIK the problem was to teach it to install additional packages, not figuring out the list of available languages
[08:54] <darkxst> pitti, I don't think upstream has much interest in this problem
[09:03] <darkxst> they did say I could add an install languages button
[09:04] <darkxst> but not sure they are really keen on full packagekit integration with the region gui
[09:15]  * pitti crawls back into bed, argh ubuflu
[09:29] <mlankhorst> ooh fun
[09:30] <mlankhorst> pitti: conferences, where young parents share their kids diseases
[09:30] <mlankhorst> :D
[09:46] <robru> hmmmm, where is didrocks? is it a holiday in France?
[09:46] <robru> did his plane crash?!? WHERE IS HE?!?! ;-)
[11:10] <didrocks> good morn…well afternoon :)
[11:33] <didrocks> robru: (backlogging on irclogs.ubuntu.com): no no, no crash, just heavily jetlag. just 5 hours of sleep since Friday, seems I needed 14 hours of sleep to get back on shape today :-)
[11:34] <didrocks> well "on shape", just enough for dist-upgrading to saucy I guess + pushing my hacking to cupstream2distro I did during the travel :)
[11:34] <robru> didrocks, yikes
[11:34] <didrocks> robru: oh, still awake? :)
[11:34] <robru> didrocks, oh god, is it 4:30AM? well, call me a little jetlagged too ;-)
[11:34] <BigWhale> Greetings all.
[11:34] <didrocks> robru: heh, indeed, another kind of jetlag! :)
[11:34] <didrocks> hey BigWhale
[11:35] <BigWhale> I envy you all this jetlag! :P
[11:35] <didrocks> robru: so, you enjoyed an extra day in Seattle?
[11:35] <didrocks> BigWhale: I bet you do :)
[11:35] <robru> didrocks, seattle was wonderful! we should do the next sprint there!
[11:35] <didrocks> robru: I only know the airport when going to Portland :)
[11:35] <didrocks> robru: I heard the weather is quite rainy generally though
[11:35] <robru> BigWhale, I didn't have to leave my time zone to get to the sprint, but somehow I am really off my sleep schedule right now...
[11:36] <BigWhale> :))
[11:36] <robru> didrocks, well it was sunny and beautiful for me... ;-)
[11:36] <didrocks> nice!
[11:36] <BigWhale> you're not really making it easier for me! you all shoud say that sprint really sucked... :P
[11:37] <didrocks> BigWhale: we didn't see that much the light of the day, as every room had no window if you prefer :p
[11:37] <BigWhale> :)
[11:38] <BigWhale> I somewhat solved the biggest Kazam issue, now I have to start hanging out around the Mir guys ... :)
[11:38] <robru> BigWhale, no no, I was talking about the city I got stuck in for a day on my way home... not the sprint itself ;-)
[11:38] <didrocks> heh :)
[11:39] <didrocks> saucy, here I come!!!
[11:42] <robru> didrocks, let me know how it goes. I already have some bug reports about friends not running very well in saucy... some API breakage in new libraries. I expect I'll upgrade tomorrow
[11:43] <didrocks> robru: sure, will do! :)
[11:53] <didrocks> robru: for webapps-applications, I'll do the bootstrapping again FYI and rerun
[11:53] <robru> didrocks, ok, thanks buddy.
[11:53] <didrocks> yw! :-)
[11:54] <robru> didrocks, btw, so jenkins emails me about the build failures once they've been uploaded to the PPA -- that's really great. but I guess there's no way to be emailed about failures before the upload even happens?
[11:54] <didrocks> robru: it's not jenkins emailing you, it's launchpad
[11:55] <robru> didrocks, right, that's what I meant
[11:55] <didrocks> as you are part of the ubuntu-unity team
[11:55] <robru> PPA build failures from launchpad, those are handy
[11:55] <didrocks> robru: yeah, we'll need the dashboard for that
[11:55] <didrocks> to have a "higher view"
[11:55] <didrocks> and emails when needed on what…
[11:57] <robru> didrocks, does jenkins always use a staging PPA even once we enable releasing to distro?
[11:57] <didrocks> robru: yeah, it's always a 2 steps process
[11:57] <didrocks> build in a ppa
[11:57] <didrocks> if the stack is validated -> copy to distro
[11:57] <didrocks> the difference is daily-build-next is called daily-build
[11:58] <didrocks> and next is distro
[11:58] <didrocks> (so we only use one PPA instead of 2)
[11:58] <robru> didrocks, right, that makes sense now. I was wondering why we were using 2 PPAs ;-)
[11:58] <didrocks> robru: we just mimick "distro" as long as we don't have it :-)
[11:59] <robru> but that's good because I can be confident that I'll keep getting build failure emails even after we move back to distro releases
[11:59] <didrocks> exactly :)
[12:00] <didrocks> but that won't show you up that the stack is in manual publishing mode for instance
[12:01] <robru> yeah
[12:01] <didrocks> or that some components have their prepare step yellow as a manual upload has been done
[12:01] <robru> and it wouldn't email me about failures to build the source packages.
[12:01] <didrocks> so still need to check jenkins
[12:01] <didrocks> yep
[12:01] <robru> but some emails are nice ;-)
[12:01] <didrocks> :)
[12:08]  * didrocks reboots
[12:11] <didrocks> hum
[12:12] <robru> didrocks, problems?
[12:12] <didrocks> I have llvmpipe rendering on saucy…
[12:12] <robru> didrocks, slow?
[12:12] <didrocks> robru: yeah, and artefacts due to it :/
[12:12] <robru> didrocks, yikes. intel?
[12:12] <didrocks> right
[12:12] <robru> didrocks, so I'll wait before upgrading ;-)
[12:12] <didrocks> libGL error: failed to load driver: i965
[12:13] <didrocks> interesting :)
[12:13] <Nafallo> no intel :-P
[12:13] <didrocks> libgl1-mesa-dri is installed though
[12:14] <didrocks> tseliot: any idea? (if around) ^
[12:14] <didrocks> sudo modprobe i915 seems to do nothing…
[12:15] <didrocks> http://paste.ubuntu.com/5638376/
[12:17] <didrocks> added myself to the video group, way better :)
[12:18] <didrocks> robru: FYI ^
[12:18] <robru> weird
[12:18] <robru> ok, will keep that in mind, thanks
[12:19] <ogra_> sounds liek the driver misses a udev-acl rule then
[12:19] <didrocks> ogra_: yeah, I wonder though as some other have the same hw and upgraded already
[12:20] <ogra_> well, who cares about intel anyway ... ask long as arm works :)
[12:20] <mlankhorst> ogra_: I want to get 1.14 ready for saucy, I heard the latest tegra drivers had support for 1.14?
[12:21] <didrocks> ogra_: tssss :p
[12:21] <ogra_> mlankhorst, we dont build any tegra Xorg images anymaore ... the only arm desktop image left is pandaboard ... for which we wont get a new binary driver
[12:21] <seb128> the permission issue is likely a logind problem, better to ask pitti tomorrow (I think he's swapping today)
[12:22] <mlankhorst> so that's no new armhf desktop images then? o.o
[12:22] <seb128> mlankhorst, is the plan to get 1.14 in saucy? if it breaks drivers we might have to hold on that update...
[12:22] <ogra_> mlankhorst, right, we keep panda adound (but thats 1.13) to test arm desktop apps ....
[12:23] <mlankhorst> I thought fglrx and nvidia were ready though
[12:23] <ogra_> there was kind of the rumour around that we will not touch xorg this cycle
[12:23] <ogra_> (during the sprint)
[12:23]  * ogra_ heard that from several sources
[12:23] <mlankhorst> I'll ask bryce when he gets online then
[12:23] <seb128> ogra_, well, it was said during the sprint that we need to have a working armhf image to test apps
[12:23] <seb128> mlankhorst, ^
[12:23] <mlankhorst> seb128: well the tegra touch issue is going to be fixed
[12:24] <ogra_> seb128, it was also said that we wont have x86 bianry driver updates
[12:24] <seb128> ogra_, is the current driver working on 1.14 or not?
[12:24] <ogra_> mlankhorst, see above,  no more touch image that uses xorg
[12:24] <ogra_> seb128, it sint
[12:24] <ogra_> *isnt
[12:24] <seb128> what driver is used on the nexus desktop image?
[12:24] <ogra_> well, i doubt anyone tested ... it isnt supposed to :)
[12:25] <ogra_> seb128, tegra3 ... but that image is gone
[12:25] <seb128> hum
[12:25] <ogra_> (i just disabled it)
[12:25] <seb128> would tegra3 work on x 1.14?
[12:25] <ogra_> sure
[12:25] <ogra_> but not on the kernel we have for the nexus7
[12:25] <seb128> can't we keep the nexus image and disable the pando one instead?
[12:25] <ogra_> which is completely touch centric
[12:26] <seb128> I'm just trying to understand the options
[12:26] <ogra_> you wish
[12:26] <ogra_> panda is our only option for desktop atm
[12:26] <seb128> we need a working armhf xorg
[12:26] <seb128> why?
[12:26] <seb128> seems like nexus would be
[12:26] <seb128> define" desktop"
[12:26] <ogra_> because we have no working kernel for nexus7 non touch
[12:26] <seb128> oh ok
[12:26] <seb128> stucked either way :/
[12:26] <mlankhorst> why wouldn't the touch kernel work though?
[12:27] <ogra_> to make xorg work it needs a patch that breaks touch on android based images
[12:27] <ogra_> (nexus7 that is)
[12:27] <mlankhorst> what patch? it might be possible to workaround
[12:27] <seb128> so we would have to maintain an extra kernel/image for non-touch nexus
[12:27] <seb128> ?
[12:27] <ogra_> additionally you would break ubuntu-touch through a lot of options we use on the desktop
[12:28] <ogra_> seb128, right
[12:28] <seb128> sucks
[12:28] <seb128> mlankhorst, what changed in xorg 1.13 -> 1.14 ?
[12:28] <ogra_> due to that and the fact that it was communicatede that we cant upgrade xorg anyway it was decided to keep the panda one
[12:28] <mlankhorst> brr
[12:29] <ogra_> (cant upgrade due to not getting bijnary drivers for nvidia/fglrx)
[12:29] <ogra_> thats at least my last info
[12:29] <mlankhorst> seb128: some touch fixes, they're increasingly hard to backport
[12:30] <mlankhorst> oh and proper upstream support for pointer barriers
[12:30] <seb128_> dsl disconnected
[12:30] <ogra_> seb128, also, the panda image is now in hands of foundations ... (i'm phonedations now) ... i guess infinity is your man for them
[12:30] <seb128_> mlankhorst, sorry, can you repeat what you wrote between my question and that "oh ..."
[12:30] <mlankhorst> 14:29 < ogra_> (cant upgrade due to not getting bijnary drivers for nvidia/fglrx)
[12:30] <mlankhorst> 14:29 < ogra_> thats at least my last info
[12:30] <mlankhorst> 14:29 < mlankhorst> seb128: some touch fixes, they're increasingly hard to backport
[12:30] <mlankhorst> 14:30 < mlankhorst> oh and proper upstream support for pointer barriers
[12:30] <seb128_> mlankhorst, thanks
[12:31] <ogra_> (always happy to help indeed, but officially they are in foundation team hands)
[12:31] <seb128_> ogra_, well, my understanding was that we don't want to do any extra work on the panda image, out of "keep it working to be able to test apps on armhf/xorg"
[12:32] <seb128_> but yeah, noted, it's maintained by foundations
[12:32] <ogra_> right
[12:32] <ogra_> i voted against that until it turned out we cant use the nexus7 kernel for desktop images
[12:32] <seb128_> mlankhorst, how much do we care about touch on xorg if our device images are going to be based on Mir?
[12:33] <ogra_> well, there are a lot x86 touch laptops now
[12:33] <mlankhorst> nexus7 is just the easiest testcase I have for touch applications, mostly
[12:34] <mlankhorst> I'm running a hacky xorg that has a bunch of abi patches reverted, not enough to keep tegra fully happy though, there are some graphical glithces
[12:35] <mlankhorst> but for now it's good enough, I'll try to backport any input changes back to 1.13
[12:35] <mlankhorst> once upstream xserver is fixed
[12:36] <mlankhorst> seb128: but I was just running into a problem where I'm not sure whether mir currently supports any keyboard/mouse/touch input at all ;)
[12:36] <seb128> mlankhorst, right, well the main constrain we have with the xorg update is "need a working amrhf image"
[12:37] <mlankhorst> yeah I'm aware
[12:37] <seb128> knowing that we will not get updated binary drivers for the panda
[12:37] <seb128> which sort of block us to update to 1.14 if we don't find another solution
[12:39] <mlankhorst> unfortunately :/
[12:39] <didrocks> hum, and no sound as well on saucy…
[12:39] <seb128> didrocks, you have an acl issue with logind
[12:39] <seb128> it seems
[12:40] <seb128> check with Laney or pitti when they are around
[12:40] <didrocks> seb128: yep
[12:41] <didrocks> I can reproduce in the guest session as well
[12:41] <didrocks> so at least, easier to debug
[12:41]  * didrocks adds himself to the audio group
[12:41] <seb128> adding yourself to those groups seem like a workaround
[12:41] <didrocks> seb128: right, but I prefer to have something while they are not around :)
[12:41] <tjaalton> so how can panda block x86?
[12:41] <didrocks> seb128: or you have better options?
[12:42] <didrocks> no 3D acc or no sound isn't nice
[12:42] <tjaalton> the touch bug is oem critical
[12:42] <tjaalton> on x86
[12:42] <seb128> is systemd-logind running?
[12:42] <didrocks> /lib/systemd/systemd-logind
[12:42] <didrocks> yep
[12:43] <seb128> didrocks, do you have libpam-systemd installed?
[12:43] <didrocks>   Installé : 202-0ubuntu5
[12:44] <pitti> seb128: not exactly swapping, just taking it easy (ubuflu and jetlag)
[12:45] <didrocks> hey pitti!
[12:45] <seb128> pitti, oh, I though you were one of the ones that were swapping it, sorry
[12:45] <pitti> bonjour didrocks, ça va ?
[12:45] <pitti> didrocks: what's wrong?
[12:45] <seb128> pitti, hey, had a good flight back? ubuflu :-(
[12:45] <didrocks> pitti: ça va bien, jetlag, mais bon… ;)
[12:45] <didrocks> pitti: et toi? à part ton ubuflu?
[12:45] <pitti> didrocks: do you have a session in loginctl?
[12:45] <pitti> didrocks: yeah, unfortunately :(
[12:45] <pitti> can't escape it
[12:45] <didrocks> pitti: no, 0 session in loginctl?
[12:46] <didrocks> s/\?//
[12:47] <pitti> didrocks: grep login /var/log/auth.log ?
[12:47] <didrocks> pitti: http://paste.ubuntu.com/5638449/
[12:48] <pitti> hm, nothing unusual
[12:51]  * didrocks logs out quickly
[12:52] <didrocks> hum, even adding myself to the audio and pulse group didn't help…
[12:53] <pitti> argh
[12:53]  * pitti replays last messages
[12:53] <pitti> hm, nothing unusual
[12:53] <pitti> didrocks: what did you do exactly?
[12:53] <pitti> in terms of upgrades, reboot, etc.
[12:53] <pitti> didrocks: ls -lR /sys/fs/cgroup/ ?
[12:53] <didrocks> pitti: I just dist-upgraded to saucy
[12:53] <didrocks> then reboot
[12:54] <didrocks> no hardware acc (see above)
[12:54] <pitti> yeah, that would be missing ACLs
[12:54] <didrocks> so added myself to the video group (I wasn't in it)
[12:54] <pitti> didrocks: you aren't supposed to be
[12:54] <didrocks> pitti: yeah, I'm just trying to get back my saucy install on shape, I have my second user which is still broken for checking we get the fix :)
[12:54] <didrocks> pitti: and so, same story with sound, so yeah, really having some acl broken
[12:56] <didrocks> pitti: http://paste.ubuntu.com/5638461/
[12:57] <didrocks> interesting, no nm-applet either, I guess same issue…
[12:58] <didrocks> but consequence is that I can't connect to the vpn :/
[12:59]  * didrocks tries to install indicator-network and starts a guest session
[12:59] <pitti> # killall systemd-logind; SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind
[12:59] <pitti> not much will work without that, though
[12:59] <pitti> can you please open a root shell on VT1, run above command (perhaps with 2>&1 | tee /tmp/debug.log) and try to log in on VT2?
[13:00] <pitti> (or into X; just don't login twice under the same X server)
[13:00] <didrocks> pitti: ok, stopping it and doing that
[13:00] <seb128> pitti, btw, is suspend not reliably working in saucy a known issue?
[13:01] <pitti> seb128: no, not known, unless you mean right after logging in
[13:01] <pitti> (we delay the screensaver for 15 seconds or so)
[13:01] <pitti> so closing the lid doesn't work for the first 10 secs
[13:01] <seb128> pitti, no, I had the issue several times during my return trip, it wouldn't suspend at some point
[13:02] <seb128> I tried to suspend it through d-feet(iirc, not sure now) and it told me that a suspend was already pending
[13:02] <seb128> but the action never happens
[13:02] <seb128> well it seemed to have happened after logout, because I picked shutdown, and then it suspendend in middle of the shutdown
[13:02] <pitti> ah, I had that a few times when debugging systemd-shim with desrt last week
[13:03] <pitti> but we fixed that; so something else was apparently blocking the suspend on your first try
[13:04] <seb128> ok, I will ping you next time it happens, if you have any idea on how to debug
[13:04] <pitti> if you still vaguely know what you did, please file a bug against systemd-shim
[13:04] <pitti> seb128: workaround is "sudo killall systemd-logind", FYI
[13:04] <seb128> ok
[13:05] <didrocks> pitti: nothing happens, I just have "SWITCH to VTx"
[13:05] <didrocks> or rather VT changed to…
[13:05] <seb128> I didn't do anything special that I know about, just woke up and suspended a few times on my trip to the airport
[13:08] <tseliot> didrocks: I'm not really sure as to what's going on there. Maybe Mesa is messed up?
[13:09] <didrocks> tseliot: it's an ACL issue, so yeah, nothing to do with the driver :)
[13:09] <didrocks> trying to see with pitti what's going on
[13:09] <tseliot> ah, ok
[13:09] <didrocks> thanks tseliot :)
[13:10] <pitti> didrocks: hm, same exercise with strace perhaps? # killall systemd-logind; strace -fvvs1024 -o /tmp/logind.trace /lib/systemd/systemd-logind
[13:10] <pitti> didrocks: btw, you can also run that in X, and use "ssh otheruser@localhost"
[13:10] <pitti> didrocks: saves the VT switching
[13:11] <didrocks> pitti: well, at least the VT switching gives real boundaries :) let me try it
[13:14] <didrocks> pitti: http://paste.ubuntu.com/5638505/
[13:16] <didrocks> pitti: I logged in with my "goo" user
[13:19] <pitti> hm, there is nothing happening at all when you log in
[13:19] <didrocks> yeah, it seems like I don't use systemd-logind at all
[13:20] <pitti> didrocks: can you check /etc/pam.d/common-session whether it has "sessionoptionalpam_systemd.so"?
[13:20] <pitti> erk, weechat not pasting tabs
[13:21] <didrocks> pitti: no trace of pam_systemd.so
[13:21] <didrocks> pitti: so it's a start :)
[13:21] <seb128> didrocks, "session optional        pam_systemd.so "
[13:21] <pitti> ah, that would be it
[13:21] <seb128> right
[13:21] <didrocks> pitti: I have ecryptfs
[13:21] <didrocks> which changed the conffile
[13:21] <seb128> I do have it as well
[13:21] <pitti> me too
[13:21] <seb128> ecryptfs
[13:22] <pitti> pam-auth-update is supposed to get along with this
[13:22] <seb128> session required        pam_unix.so
[13:22] <seb128> session optional        pam_systemd.so
[13:22] <seb128> session optional        pam_ecryptfs.so unwrap
[13:22] <seb128> in the config here
[13:22] <pitti> didrocks: "sudo pam-auth-update
[13:22] <didrocks> pam-auth-update: Local modifications to /etc/pam.d/common-*, not updating.
[13:22] <didrocks> pam-auth-update: Run pam-auth-update --force to override.
[13:23] <pitti> didrocks: that should give you a debconf prompt about the modules; I guess systemd is shown, but not activated?
[13:23] <pitti> ooh
[13:23] <pitti> that's not happening here
[13:23] <pitti> didrocks: put your file somewhere? people.u.c. ?
[13:23] <didrocks> it doesn't seem I have local modification though: http://paste.ubuntu.com/5638522/
[13:24] <didrocks> pitti: but a year ago, I tried to add fingerprint support
[13:24] <didrocks> and then removed it
[13:24] <didrocks> so maybe the md5sum or anything that pam-auth-update expect is not there
[13:24] <pitti> http://paste.ubuntu.com/5638526/ is my diff
[13:24] <pitti> didrocks: ah, I'm not entirely sure how pam-auth-update works; it might have some md5sum somewhere indeed
[13:25] <didrocks> pitti: should I try to edit it by hand?
[13:25] <pitti> didrocks: so --force should be your friend
[13:25] <didrocks> or want to trace?
[13:25] <didrocks> ok
[13:26] <pitti> didrocks: you can save the file somewhere, and perhaps tar /var/lib/pam ?
[13:26] <pitti> for reproducing
[13:26] <didrocks> pitti: yeah, I've backed it up
[13:26] <didrocks> after forcing, I have:
[13:26] <didrocks> +sessionoptionalpam_winbind.so
[13:26] <didrocks> +sessionoptionalpam_systemd.so
[13:26] <didrocks> well, with tabs…
[13:26] <pitti> hmm
[13:26] <pitti> even when I manually modify /etc/pam.d/common-session, pam-auth-update still works
[13:27] <pitti> so I guess it only complains if there are pending package changes AND local modifications?
[13:27] <didrocks> pitti: possibly, that's the content of my /etc/pam.d/ FYI: didrocks@tidus:~$ ls /etc/pam.d/* | pastebinit
[13:27] <didrocks> http://paste.ubuntu.com/5638540/
[13:28] <pitti> I don't have any .pam-old files
[13:29] <pitti> seb128: btw, which version of systemd-shim did you have in the plane?
[13:29]  * didrocks tries to log out and in again
[13:29] <seb128> pitti, 3+real
[13:29] <pitti> ok, that's current
[13:30] <seb128> pitti, if I do resume and try to suspend in the next 15s second, will that break like the 15s after login?
[13:30] <pitti> seb128: no, that should work fine
[13:30] <seb128> ok, so that's not it
[13:30] <pitti> what's likely is that a failure to suspend causes this
[13:32] <pitti> hm, not even that; if pm-suspend fails, things still work
[13:32] <seb128> is there any log that could contain infos about suspend failure issues?
[13:33] <pitti> seb128: /var/log/pm-suspend.log
[13:33] <pitti> seb128: also, /var/log/auth.log about logind itself
[13:34] <seb128> Running hook /usr/lib/pm-utils/sleep.d/95anacron resume suspend:
[13:34] <seb128> start: Job is already running: anacron
[13:34] <seb128>
[13:34] <seb128> I wonder if that's an issue
[13:34] <seb128> hum, no, that's not the current portion of the log
[13:36]  * pitti tries to "exit 1" in /usr/lib/pm-utils/sleep.d/95anacron resume
[13:36] <didrocks> pitti: ok, I've cleaned my user groups to remove it from video and everything's fine
[13:36] <didrocks> tried on a guest session as well
[13:36] <pitti> good
[13:36] <didrocks> pitti: thanks! I have my old pam file if needed
[13:36] <pitti> so something failed pam-auth-update
[13:36] <didrocks> right
[13:37] <didrocks> and it leads to something broken, we need to find it :)
[13:39] <pitti> seb128: (will try as soon as my schroot upgrade finishes)
[13:42] <pitti> seb128: hm, no; breaking a pm-utils hook still works fine here
[13:43]  * pitti -> back to bed, bbl
[13:46] <didrocks> pitti: seb128: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1176910 FYI
[13:46] <ubot2`> Launchpad bug 1176910 in pam (Ubuntu) "pam-auth-update can fail during raring -> saucy upgrade leading you to a broken session" [Undecided,New]
[13:47] <seb128> didrocks, thanks! can you ping slangasek as well about it? not sure if he keeps up with launchpad bugs
[13:47] <didrocks> seb128: will do :)
[13:47] <seb128> 'ci
[14:41] <mlankhorst> http://www.knmi.nl/actueel/images/tempgmt.png
[14:41] <mlankhorst> grrrr @ heat
[15:41] <desrt> seb128: :(
[15:42] <desrt> seb128: we had exactly the issue you were describing when i first implemented suspend support -- thought it had been fixed :/
[16:11] <didrocks> robru: updated the spreadsheet btw. There is a failure in at least one package at the second run (some files missing in POTFILES.in). Letting you fixing it :)
[16:12] <didrocks> robotfuel: and also something taking the project name, but with the version number
[16:16] <didrocks> robru: ^
[16:16] <didrocks> sorry robotfuel :)
[16:17] <didrocks> robru: also the twitter one is failing on command not found. I think you will have to again manually upload a new webapps-applications with a fix to the daily-build-next ppa :)
[16:49] <desrt> seb128: can you ever get a failure on the first suspend or is it always on the second attempt?
[16:50] <seb128> desrt, hey, sorry I'm just back from exercice
[16:50] <seb128> desrt, had a good trip back?
[16:50] <seb128> desrt, I didn't try today
[16:50] <seb128> but the few times in happened saturday it was after the first suspend
[16:50] <desrt> seb128: ya.  fairly uneventful.
[16:50] <seb128> second or third, I'm not sure
[16:51] <desrt> seb128: so the issue is that logind checks to make sure that the systemd suspend job is finished before it will issue another one
[16:51] <desrt> probably in an attempt to avoid double-suspending...
[16:52] <desrt> so at first this was completely failing with systemd-shim since it was saying nothing at all
[16:52] <desrt> but i added a signal to say "okay!  done!" after it comes back
[16:52] <desrt> apparently it's not doing the trick in all cases, though
[16:54] <didrocks> robru: ok, I did the webapps-applications manual bootstrap so that we don't have to do it again.
[16:54] <didrocks> robru: everything update on the spreadsheet :)
[16:55] <desrt> it could also be the timeout logic in systemd-shim itself that is causing trouble but i consider that to be somewhat less likely
[16:57] <seb128> desrt, what info would be useful next time I get the issue?
[17:06] <desrt> seb128: a core of systemd-logind could help
[17:06] <desrt> let me see if i can reproduce it myself, though
[17:07] <desrt> does it impact all forms of suspending?
[17:07] <desrt> ie: lid, keyboard key, suspend menuitem?
[17:07] <seb128> I didn't try to debug
[17:07] <seb128> I resumed from suspend at the airport, and tried to suspend again before boarding and it didn't want to
[17:08] <seb128> then I picked shutdown, it closed the session, started shutdown and suspended on the plymouth logo
[17:08] <desrt> _seriously_?
[17:08] <seb128> when I resumed it finished the shutdown
[17:08] <desrt> ouch.
[17:08] <seb128> I didn't try to debug further
[17:08] <seb128> yeah, well, I poked a bit manually in the session before doing shutdown
[17:08] <desrt> okay.  i have a theory about why this may be the case.
[17:08] <desrt> here's a bit more background:
[17:09] <seb128> the dbus method was returning a "suspend already pending"
[17:09] <desrt> systemd creates job objects for all requests you give it
[17:09] <desrt> and returns this object as the return value of the call
[17:09] <desrt> i always just say "/"
[17:09] <desrt> then you emit a signal "job done!" on the object when it's done
[17:09] <desrt> which i just always send immediately
[17:09] <desrt> so i'm sending a "job done!" on "/" as a result of both shutdown and suspend
[17:09] <desrt> logind is probably seeing my "job done!" on the shutdown as if it were for the suspend
[17:10] <desrt> thus allowing the next suspend...
[17:10] <desrt> or something
[17:10] <desrt> i'm going to have to do some logind code reading
[17:10] <desrt> pitti and i did a pretty quick job of it in oakland... i'll have to look more closely this time
[17:10] <seb128> ok
[17:10] <seb128> I will let you know if that happens every time
[17:11] <seb128> I just don't want to suspend now :p
[17:13] <desrt> it's on the top of my pile now
[17:13] <desrt> ..so much for swap days :p
[17:20] <desrt> seb128: starting to think that we have a good old-fashioned race condition here
[17:33] <seb128> desrt, I can easily reproduce
[17:33] <seb128> desrt, note that I suspend using indicator-session, not lid close