| pitti | Good morning | 06:27 |
|---|---|---|
| robru | pitti, good evening! | 06:28 |
| robru | pitti, did you have a good flight home? | 06:28 |
| 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:29 |
| darkxst | pitti, hi | 06:30 |
| 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:31 |
| 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:32 |
| 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:35 |
| 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:37 |
| pitti | in /usr/lib/python3/dist-packages/language_selector-0.1.egg-info/entry_points.txt | 06:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| darkxst | pitti, as in uninstalled langugage packs | 06:43 |
| pitti | that is, installed locales which don't have langpacks installed? | 06:43 |
| 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:44 |
| pitti | locale -a -> installed locales | 06:45 |
| 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:46 |
| darkxst | my first idea was to add a dbus interface to language-selector | 06:48 |
| darkxst | pitti, so what would you suggest I do then? | 07:09 |
| 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:38 |
| 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:39 |
| 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:41 |
| darkxst | he just read SUPPORTED directly, but that ends up with a list with lots of duplicates | 07:42 |
| darkxst | actually I don't think he ever tested his code, it was incredibly broken | 07:43 |
| darkxst | pitti, thers actually quite a lot going on in l-s, like reading hardcoded lists and intersecting them with other lists | 08:06 |
| pitti | yeah, I know | 08:13 |
| 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:49 |
| 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:50 |
| 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:51 |
| pitti | well, we can drop it once g-c-c DTRT | 08:52 |
| pitti | but somehow the upstream g-c-c needs to figure out a list of available locales? | 08:53 |
| 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 | 08:54 |
| darkxst | they did say I could add an install languages button | 09:03 |
| darkxst | but not sure they are really keen on full packagekit integration with the region gui | 09:04 |
| * pitti crawls back into bed, argh ubuflu | 09:15 | |
| === soren_ is now known as soren | ||
| mlankhorst | ooh fun | 09:29 |
| mlankhorst | pitti: conferences, where young parents share their kids diseases | 09:30 |
| mlankhorst | :D | 09:30 |
| robru | hmmmm, where is didrocks? is it a holiday in France? | 09:46 |
| robru | did his plane crash?!? WHERE IS HE?!?! ;-) | 09:46 |
| didrocks | good morn…well afternoon :) | 11:10 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| didrocks | saucy, here I come!!! | 11:39 |
| 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:42 |
| didrocks | robru: sure, will do! :) | 11:43 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| 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 :) | 11:59 |
| didrocks | but that won't show you up that the stack is in manual publishing mode for instance | 12:00 |
| 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:01 |
| * didrocks reboots | 12:08 | |
| didrocks | hum | 12:11 |
| 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:12 |
| didrocks | interesting :) | 12:13 |
| Nafallo | no intel :-P | 12:13 |
| didrocks | libgl1-mesa-dri is installed though | 12:13 |
| didrocks | tseliot: any idea? (if around) ^ | 12:14 |
| didrocks | sudo modprobe i915 seems to do nothing… | 12:14 |
| === zimmerle` is now known as zimmerle | ||
| didrocks | http://paste.ubuntu.com/5638376/ | 12:15 |
| didrocks | added myself to the video group, way better :) | 12:17 |
| didrocks | robru: FYI ^ | 12:18 |
| robru | weird | 12:18 |
| robru | ok, will keep that in mind, thanks | 12:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| === seb128_ is now known as seb128 | ||
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| seb128 | check with Laney or pitti when they are around | 12:40 |
| didrocks | seb128: yep | 12:40 |
| 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:41 |
| 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:42 |
| seb128 | didrocks, do you have libpam-systemd installed? | 12:43 |
| didrocks | Installé : 202-0ubuntu5 | 12:43 |
| pitti | seb128: not exactly swapping, just taking it easy (ubuflu and jetlag) | 12:44 |
| 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:45 |
| didrocks | s/\?// | 12:46 |
| pitti | didrocks: grep login /var/log/auth.log ? | 12:47 |
| didrocks | pitti: http://paste.ubuntu.com/5638449/ | 12:47 |
| pitti | hm, nothing unusual | 12:48 |
| * didrocks logs out quickly | 12:51 | |
| didrocks | hum, even adding myself to the audio and pulse group didn't help… | 12:52 |
| 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:53 |
| 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:54 |
| didrocks | pitti: http://paste.ubuntu.com/5638461/ | 12:56 |
| didrocks | interesting, no nm-applet either, I guess same issue… | 12:57 |
| didrocks | but consequence is that I can't connect to the vpn :/ | 12:58 |
| * 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? | 12:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| pitti | but we fixed that; so something else was apparently blocking the suspend on your first try | 13:03 |
| 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:04 |
| 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:05 |
| tseliot | didrocks: I'm not really sure as to what's going on there. Maybe Mesa is messed up? | 13:08 |
| 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:09 |
| 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:10 |
| didrocks | pitti: well, at least the VT switching gives real boundaries :) let me try it | 13:11 |
| didrocks | pitti: http://paste.ubuntu.com/5638505/ | 13:14 |
| didrocks | pitti: I logged in with my "goo" user | 13:16 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| pitti | I don't have any .pam-old files | 13:28 |
| 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:29 |
| 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:30 |
| 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:32 |
| pitti | seb128: /var/log/pm-suspend.log | 13:33 |
| pitti | seb128: also, /var/log/auth.log about logind itself | 13:33 |
| 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:34 |
| * 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:36 |
| === m_conley_away is now known as m_conley | ||
| didrocks | and it leads to something broken, we need to find it :) | 13:37 |
| === tkamppeter_ is now known as tkamppeter | ||
| pitti | seb128: (will try as soon as my schroot upgrade finishes) | 13:39 |
| pitti | seb128: hm, no; breaking a pm-utils hook still works fine here | 13:42 |
| * pitti -> back to bed, bbl | 13:43 | |
| 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:46 |
| 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 | 13:47 |
| mlankhorst | http://www.knmi.nl/actueel/images/tempgmt.png | 14:41 |
| mlankhorst | grrrr @ heat | 14:41 |
| desrt | seb128: :( | 15:41 |
| desrt | seb128: we had exactly the issue you were describing when i first implemented suspend support -- thought it had been fixed :/ | 15:42 |
| 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:11 |
| didrocks | robotfuel: and also something taking the project name, but with the version number | 16:12 |
| didrocks | robru: ^ | 16:16 |
| didrocks | sorry robotfuel :) | 16:16 |
| 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:17 |
| desrt | seb128: can you ever get a failure on the first suspend or is it always on the second attempt? | 16:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| 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:55 |
| seb128 | desrt, what info would be useful next time I get the issue? | 16:57 |
| desrt | seb128: a core of systemd-logind could help | 17:06 |
| desrt | let me see if i can reproduce it myself, though | 17:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| seb128 | I just don't want to suspend now :p | 17:11 |
| desrt | it's on the top of my pile now | 17:13 |
| desrt | ..so much for swap days :p | 17:13 |
| desrt | seb128: starting to think that we have a good old-fashioned race condition here | 17:20 |
| seb128 | desrt, I can easily reproduce | 17:33 |
| seb128 | desrt, note that I suspend using indicator-session, not lid close | 17:33 |
| === m_conley is now known as m_conley_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
