[02:06] <vthompson> I want to get the Unity 8/Ubuntu Desktop Next session running on an armhf device (RPi 2). Sadly, this means I can not install Unity 8 via the LXC container instructions because there is no armhf iso. If I install the "ubuntu-desktop-next" package, should I assume I might be able to use the Unity 8 session?
[06:30] <pitti> Noskcaj: yes; apt is rather resistant when it comes to uninstalling a package; there must be several new dependencies to the new one, and the new one must at least Provides: the old one, but that's not the case here
[06:30] <pitti> as I said, it might be that apt became more clever in the last year or so, but an upgrade needs to be tested
[06:40] <seb128> good morning desktopers
[06:41] <pitti> bonjour seb128
[06:41] <seb128> hey pitti :-)
[06:42] <pitti> so I got up late (we had a concert last night), you got up early, almost the same time now :)
[06:42] <pitti> convergence!
[06:46] <seb128> hehe
[06:48] <darkxst> so pitti can plug seb128 into the TV and get Ubuntu desktop then ;)
[06:49] <darkxst> hi all, btw
[07:25] <didrocks> good morning
[07:27] <seb128> hey didrocks
[07:27] <didrocks> hey seb128
[07:58] <pitti> bonjour didrocks
[07:59] <didrocks> guten morgen pitti
[07:59] <larsu> hi pitti!
[07:59] <pitti> larsu: moin moin!
[08:24] <mlankhorst> morning
[08:26] <didrocks> hey mlankhorst
[08:29] <mlankhorst> hey
[08:30] <seb128> hey mlankhorst
[08:59] <TheMuso> Hey willcooke. :)
[08:59] <willcooke> morning
[09:04] <Laney> yo
[09:05] <seb128> hey TheMuso Laney willcooke
[09:05] <willcooke> hi all
[09:06] <willcooke> oh, I just remembered - I'm on holiday tomorrow
[09:06] <willcooke> and in London on Monday
[09:06] <willcooke> larsu, cancelled our meeting tomorrow ^^^
[09:06] <willcooke> let me know if you need anything
[09:07] <larsu> willcooke: morning & thanks, will do
[09:07] <larsu> willcooke: and enjoy you day off ;)
[09:08] <willcooke> \o/ looking forward to it
[09:08] <Laney> ooh London, glamorous
[09:09] <willcooke> I'll send you a postcard of a telephone box Laney
[09:09] <didrocks> tell us if Doctor Who is around :)
[09:09] <Laney> go check out Cereal Killer
[09:11] <davmor2> Laney: we are all Cereal Killers otherwise they wouldn't sell it in boxes
[09:42] <Laney> darkxst: thx for uploading
[09:43] <Laney> seb128: can you check grilo-plugins in vivid new when you've got some minutes today please?
[09:43] <Laney> (then try totem 3.14 if you have a few more :p)
[09:43] <seb128> Laney, sure can
[09:43] <seb128> what should I try on totem exactly?
[09:43] <Laney> random use
[10:02] <Laney> desrt: thx, saw it, replied on the list
[10:02] <Laney> I should filter that one out of my main inbox
[10:09] <seb128> Laney, totem looks fine to me
[10:09] <Laney> cool
[10:10] <Laney> thanks to darkxst and Noskcaj for doing most of the work
[10:12] <seb128> Noskcaj, darkxst, good work!
[10:12] <seb128> it's a bit weird that the Videos tab is empty by default
[10:13] <seb128> would be nice if is was listing the content of XDG_VIDEOS_DIR
[10:13] <seb128> also the plugins list in preference is empty
[10:13] <seb128> is that normal?
[10:19] <Laney> has some here
[10:19] <Laney> is totem-plugins installed?
[10:22] <seb128> ups, that got uninstalled
[10:22] <seb128> Laney, thanks ;-)
[10:22] <larsu> Laney: I can't install it because it wants grilo-plugins-0.2-base, which isn't available
[10:23] <seb128> Laney, thanks
[10:23] <Laney> they're coming soon, or you can grab from https://launchpad.net/ubuntu/+source/grilo-plugins/0.2.13-3ubuntu3
[10:23] <larsu> thanks
[10:23] <seb128> larsu, I just NEWed those binaries, should be available after the next publisher run
[10:23] <seb128> Laney, ^
[10:23] <Laney> will need to wangle through proposed
[10:23] <Laney> thanks!
[10:24] <larsu> seb128: thanks! I'll just wait a bit then
[10:24] <seb128> hum
[10:24] <seb128> can't connect to people.canonical.com?
[10:25] <Laney> some kind of maintenance
[10:26] <seb128> yeah, saw that in the #is topic
[10:26] <seb128> I wanted to look at why glib didn't migrate out of proposed yet
[10:27] <Laney> gnome-photos failure
[10:27] <Laney> should indeed be retryable with this NEWing
[10:28] <Laney> to do with https://launchpad.net/ubuntu/+source/gnome-online-miners/3.14.0-2ubuntu1
[10:29] <seb128> that doesn't seem related to glib?
[10:29] <seb128> why do we block on it rather than overriding?
[10:30] <Laney> was fixing it
[10:31] <seb128> k, the logic still feels weird to me, but as long as it's fixed it's all good :-)
[10:32] <Laney> I always prefer to fix tests if reasonably possible even if they're not directly caused by the thing they are blocking
[10:32] <seb128> well that's orthogonal
[10:32] <seb128> you can unblock and still fix the test :-)
[10:51] <flexiondotorg> Morning. There has been a recent release of GTK2 which fixes a nasty bug. Is this where the right channel to progress the fix in Ubuntu?
[10:53] <Laney> Yeah, we're going to get that soon
[10:57] <ochosi> flexiondotorg: rly? what bug?
[10:59] <flexiondotorg> ochosi, https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1351890
[10:59] <ochosi> ah that one, ok
[10:59] <flexiondotorg> ochosi, Although our motivation to prepare the patch was to fix a segfault in MATE, other GTK2 applications are affected.
[10:59] <flexiondotorg> ochosi, Upstream release now.
[11:00] <flexiondotorg> Laney, Excellent. Thanks.
[12:12] <attente_> seb128: hi, do you have time to look at https://code.launchpad.net/~attente/unity-settings-daemon/fcitx-transition/+merge/230289 and https://code.launchpad.net/~attente/unity-control-center/fcitx-transition/+merge/249523
[12:46] <seb128> attente_, I can try to have a look today yes
[12:47] <attente_> seb128: thanks!
[12:47] <seb128> yw!
[12:48] <seb128> attente_, btw I did follow up that work recently, did anything change compared to previous cycle? should still be a no-op for ibus users riht?
[12:49] <attente_> seb128: yes, should only improve our situation with fcitx
[12:56] <seb128> attente_, my ibus is not working, I think it's still like the ubuntu-keyboard thing, do we have a bug open about that?
[12:57] <attente_> seb128: yeah, it's because of this: https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1245925
[12:58] <attente_> the workaround for now is to comment out the export of QT_IM_MODULES, or remove maliit-framework
[12:58] <attente_> sorry, QT_IM_MODULE
[12:59] <Laney> purge
[12:59] <attente_> ah, right. purge, sorry :)
[12:59] <seb128> Laney, ?
[12:59] <seb128> oh
[12:59] <seb128> that's not a solution
[12:59] <Laney> he called it a workaround
[12:59] <seb128> yeah, I'm not interested in a workaround
[13:00] <seb128> I was talking about fixing that issue
[13:00] <seb128> in the distro
[13:01] <Laney> yes indeed
[13:02] <attente_> one thing we can do is make im-config still set GTK_IM_MODULE and XMODIFIERS, but it doesn't fix the fact that we need QT_IM_MODULES to have both maliitphablet and ibus/fcitx
[13:02] <Laney> can it have multiple modules?
[13:02] <Laney> (does stuff work right then?)
[13:03] <attente_> don't think so. GTK_IM_MODULES can, but even then, it's just like going through a list of fallbacks until it picks one
[13:04] <Laney> how does maliit get used for gtk apps?
[13:05] <Laney> could we kill this file and teach im-config about maliit, then get $phone_place to call it?
[13:06] <attente_> i guess we could probably do that without teaching im-config about maliit
[13:06]  * Laney doesn't know how it works
[13:07] <attente_> but it needs to set the environment variable across the session
[13:09] <Laney> ye, some upstart job
[13:10] <Laney> well anyway, just throwing out ideas :)
[13:15] <seb128> well, I'm not even sure what should happen
[13:16] <attente_> is there a way to know when we change from having a physical keyboard to not having one?
[13:16] <seb128> it feels like the osk shouldn't be by session
[13:16] <seb128> but by input device
[13:16] <seb128> like usng a touch screen should display one
[13:16] <Laney> can the toolkits do that?
[13:16] <seb128> if you connect a bt keyboard to your phone it shouldn't display the osk then
[13:16] <seb128> not sure
[13:17] <seb128> I've feeling we are not going to resolve those usecases under xorg/unity7 though
[13:17] <seb128> so meanwhile having a way to turn osk on or off, like we do with onboard, would be something
[13:19] <Laney> perhaps we just say that we don't use maliit on unity 7 or something :|
[13:22] <seb128> that wfm
[13:22] <seb128> well, until we figure how we deal better with that
[13:22] <seb128> I'm not even sure ubuntu-keyboard works fine on unity7
[13:23] <Laney> the upstream one did at least work when I packaged it ages ago
[13:26] <Laney> seb128: do we do "= unity8-* || = ubuntu-touch" or "!= ubuntu"?
[13:26] <Laney> attente_: ^
[13:26] <seb128> something is wrong in any case, because it if was taking over ibus, it should display its UI when trying to im?
[13:26] <Laney> if you fix it like this, it would be good to also make that file a noop if maliit isn't installed
[13:27] <seb128> Laney, I would say unity8 | ubuntu-touch
[13:28] <attente_> yeah
[13:29] <Laney> ok, attente_ are you happy to do that?
[13:29] <attente_> Laney: sure
[13:29] <Laney> can review after that
[13:29] <Laney> sweet
[13:29] <Laney> lemme know
[13:30] <seb128> attente_, can you get desrt to look again to your indicator-keyboard changes and approve it if it's fine, if he is I can do a landing
[13:30] <attente_> seb128: sure
[13:30] <seb128> thanks
[13:44]  * Laney pulls ze totem trigger
[13:44] <Laney> chuk-chuk boom
[13:51] <attente_> this script doesn't even seem to run when i start a unity 8 session...
[13:53] <seb128> likely some Xsession.d hackery
[13:53] <seb128> or X hacks don't apply to Mir
[13:53] <attente_> so how does maliit currently work on the phone?
[13:55] <attente_> the phone runs the profile.d scripts but the desktop doesn't?
[13:56] <seb128> correct
[13:56] <seb128> http://bazaar.launchpad.net/~phablet-team/ubuntu-touch-session/trunk/view/head:/ubuntu-touch-session
[13:56] <seb128> that the ubuntu-touch-session script
[13:56] <seb128> which is some hackery used on the device
[13:57] <seb128> unity8 desktop doesn't have those hacks
[13:57] <seb128> the script sources profile.d
[13:57] <attente_> maybe this is what we need to disable in u7
[13:57] <seb128> that's one of those things we should deprecate by integrating what it does in the proper packages
[13:57] <seb128> you mean?
[13:58] <seb128> we are not going to install that script on unity7 if that's what you suggest :-)
[13:58] <seb128> it does things like forcing the qt qpa to mir
[13:58] <seb128> or has android bits
[13:58] <seb128> we should do it the other way around, move things out of this script to the proper packages instead
[13:59] <attente_> yeah
[14:01] <attente_> but the script is running on u7 right now...
[14:04] <attente_> no. i'm wrong, something else is running the /etc/profile.d scripts under u7
[14:05] <seb128> well, profile.d scripts are run through Xsession.d
[14:05] <attente_> oh, ok
[14:06] <seb128> hum, in fact I don't have that package/script
[14:07] <seb128> I wonder why my ibus is not working
[14:10] <seb128> cyphermox, hey, can you get https://code.launchpad.net/~mathieu-tl/mtp/lp1421664/+merge/249669 landed?
[14:10] <cyphermox> sure
[14:10] <seb128> thanks
[14:10] <cyphermox> happy new year btw ;)
[14:10] <seb128> cyphermox, I would try to write you that in chinese but my ibus is not working :p
[14:11] <cyphermox> ahahha
[14:11] <cyphermox> I could write it in vietnamese but for the same reasons
[14:12] <attente_> seb128: what does your ~/.xinputrc say
[14:12] <cyphermox> there's a bit fewer special accents to add that need ibus
[14:12] <seb128> attente_, I deleted that file like 10 minutes ago, but it was empty
[14:12] <attente_> can you try 'im-config -n ibus' and restart the session?
[14:12] <seb128> why is that needed?
[14:12] <seb128> how does it work with new users/installs?
[14:13] <attente_> yeah, you're right, it shouldn't be needed
[14:13] <seb128> let me restart session in case anyway
[14:13] <desrt> seb128: i really can't ACK those changes
[14:13] <seb128> desrt, why not?
[14:14] <desrt> because i don't know anything about input methods or indicators :)
[14:14] <seb128> are you happy with the code?
[14:15] <desrt> i can review that part of it again :)
[14:15] <seb128> thanks
[14:15] <seb128> I can test the IM/indicator side
[14:15] <attente_> i can look for another reviewer
[14:16] <attente_> or happyaron, do you know someone else? ^
[14:18] <seb128> 你好
[14:19] <attente_> :D
[14:19] <seb128> attente_, works after deleting that .xinput rc which had comments only
[14:19] <seb128> maybe that was preventing im-config to do his init or something
[14:19] <attente_> ah, maybe
[14:23] <tedg> larsu, Can you look at https://code.launchpad.net/~ted/indicator-messages/lp1385331-unescape-message-ids/+merge/250235
[14:25] <attente_> Laney, seb128, can you guys test https://code.launchpad.net/~attente/maliit/1245925/+merge/250311 on the device?
[14:25] <attente_> to make sure osk still works
[14:25] <attente_> i can't test it since the behaviour is different on the desktop
[14:25] <seb128> attente_, I can do that
[14:31] <GunnarHj> pitti: Hi Martin! Saw that https://translations.launchpad.net/ubuntu/trusty/+language-packs seems to be ready. Do you have time to get it into -proposed today?
[14:33] <larsu> tedg: sure, give a few mins
[14:33] <larsu> *me
[14:37] <pitti> GunnarHj: yes, it's on my list; I have to wait for the currently running vivid langpack build to finish, though
[14:37] <pitti> GunnarHj: I'm watching it on a foreground terminal :)
[14:37] <GunnarHj> pitti: Ok, great! :)
[14:46] <seb128> hum
[14:46] <seb128> so my desktop doesn't boot anymore
[14:47] <seb128> stucked on the plymouth logo
[14:47] <seb128> it boots fine if I remove quiet splash though
[14:47] <seb128> didrocks, pitti, ^ know of any issue with recent systemd updates?
[14:48] <didrocks> seb128: didn't upgdate since yesterday, can do if you want
[14:48] <didrocks> update*
[14:49] <didrocks> seb128: actually, I'm running latest systemd already, no issue at boot
[14:49] <didrocks> (did reboot just after latest upgrade)
[14:50] <pitti> GunnarHj: I'm asking in #ubuntu-release about when to upload them; I figure having them in trusty-proposed should be fine, but I'll double-check
[14:50] <pitti> seb128: I'm not aware of regressions; could you boot with systemd.debug-shell, and once it's hanging switch to VT9 and check systemctl list-jobs?
[14:50] <seb128> pitti, k
[14:50] <seb128> looking to the journal those boots have different fails
[14:51] <seb128> pitti, http://people.canonical.com/~seb128/log
[14:51] <GunnarHj> pitti: ok
[14:51] <seb128> fÃ©vr. 19 15:45:12 seb-e6410 systemd[1]: Starting Network Manager...
[14:51] <seb128> fÃ©vr. 19 15:46:02 seb-e6410 systemd[1]: Started Console System Startup Logging.
[14:51] <seb128> why that lag?
[14:52] <seb128> I guess I need debug as well
[14:56] <larsu> n conjugating directly for voice, English uses the past participle form of the verb plus an auxiliary verb, either be or get, to indicate passive voice.
[14:56]  * larsu accidentally pasted. Sorry
[14:56] <pitti> darn, I missed the start of the English lesson
[14:56]  * larsu hates middle-click paste
[14:56] <larsu> pitti: reading wikipedia about passive voice :)
[14:57] <pitti> o_O middle click paste == ♥
[14:57] <seb128_> +1
[14:58] <seb128_> pitti, no vt, including the vt9 one :/
[14:58] <pitti> meh
[14:59] <pitti> the 45 s lag is certainly odd, but it doesn't say anything in that log at that time
[14:59] <pitti> fÃ©vr. 19 15:46:27 seb-e6410 dbus[774]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
[14:59] <pitti> fÃ©vr. 19 15:46:27 seb-e6410 dbus[774]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
[14:59] <pitti> fÃ©vr. 19 15:46:27 seb-e6410 dbus[774]: [system] Failed to activate service 'org.freedesktop.ColorManager': timed out
[14:59] <seb128_> right, well it boots in 10s without quiet
[15:00] <pitti> seb128_: that's also weird -- after that it shuts down, did you request that manually, or does it happen automatically?
[15:00] <seb128_> I try one with debug to see if it has more
[15:00] <seb128_> I do ctrl-alt-f1 and ctrl-alt-del
[15:03] <pitti> ah, so manual shutdown
[15:03] <seb128_> yes
[15:04] <seb128> pitti, hum
[15:04] <seb128> févr. 19 15:59:09 seb-e6410 systemd[1]: Starting Run Click system-level hooks...
[15:04] <seb128> févr. 19 15:59:59 seb-e6410 systemd[1]: Received SIGINT.
[15:05] <pitti> seb128: urk :) you might not want to install weird stuff
[15:05] <seb128> that runs on non debug runs as well and doesn't hang the boot
[15:05] <seb128> I'm unsure how to debug that :-/
[15:06] <seb128> systemd.debug-shell doesn't give me a vt9
[15:06] <pitti> seb128: so with plymouth is it just taking "long" or actually hanging forever? does it get far enough to ssh in and see what's happening?
[15:06] <seb128> it seems to hang forever
[15:06] <seb128> but I didn't wait for more than 3 minutes
[15:06] <desrt> attente_: this patch is pretty great
[15:06] <pitti> seb128: you mean VT switching doesn't work? or it doesn't even boot far enough after the initramfs?
[15:06] <seb128> but a boot without quiet takes 15 seconds
[15:07] <desrt> step 1) attente copy/pastes something from one part of the code to another part
[15:07] <seb128> pitti, ctrl-alt-fn display empty screens
[15:07] <desrt> step 2) desrt flags in review "this is not necessary"
[15:07] <seb128> no command line
[15:07] <desrt> step 3) attente fixes all of the other instances of same
[15:07] <seb128> it just switches away from the plymouth logo
[15:07] <desrt> step 4) massive net-negative diff
[15:07] <pitti> seb128: yeah, 90s is the standard timeout, so anything which takes longer can safely count as "forever"
[15:07] <pitti> desrt: sounds like step 5) hug attente ?
[15:07] <desrt> srsly.
[15:08] <willcooke> Sweet5hark1, quick easy way to reset LO settings to default?  Deleting something from .config perhaps?
[15:08]  * Sweet5hark1 is in call
[15:08] <willcooke> nw
[15:08] <pitti> ./.config/libreoffice ?
[15:08] <Sweet5hark1> willcooke: "rm -rf ~/.config/libreoffice" should reset your user profile
[15:08] <willcooke> thanks pitti Sweet5hark1
[15:09] <seb128> pitti, I could try to boot with systemd-bootchart I guess
[15:09] <pitti> seb128: yeah, good first step
[15:09] <pitti> seb128: also, do you have plymouth in the initramfs?
[15:09] <pitti> zcat /initrd.img | cpio -t|grep ply
[15:09] <seb128> pitti, how do I tell?
[15:09] <seb128> yes
[15:10] <pitti> seb128: ok, so you have cryptsetup installed probably?
[15:10] <seb128> yes
[15:10] <pitti> seb128: if you don't have encrypted internal partitions, you could try removing it, to compare
[15:10] <seb128> but I don't use it
[15:10] <seb128> k
[15:10] <seb128> let me try
[15:10] <pitti> (cryptsetup-bin is enough for encrypted USB etc.)
[15:10] <pitti> seb128: if you still see plymouth, that at least means that it gets far enough into the root system to at least boot
[15:11] <pitti> seb128: another strategy:
[15:11] <pitti> - enable persistant journal: sudo mkdir /var/lib/journal
[15:11] <pitti> reboot with plymouth, wait two mins, reboot
[15:11] <pitti> - reboot without plymouth, journalctl -b -1
[15:11] <seb128_> pitti, I do have persistant journal, that's how I got you the boot log before
[15:11] <pitti> ah
[15:12] <pitti> seb128_: ah, so you boot with bootchart by default?
[15:12] <seb128_> pitti, ok, withoyt cryptsetup, stucked on plymouth with animated dots
[15:12] <pitti> seb128_: so exactly the same?
[15:12] <seb128_> pitti, not voluntarily
[15:12] <seb128_> yes
[15:13] <pitti> seb128_: voluntarily> you mean it accidentally boots with bootchart?
[15:13] <seb128_> I'm not using bootchart that I know*
[15:13] <seb128_> I use init=/lib/systemd
[15:13] <seb128_> sorry /bin
[15:13] <pitti> fÃ©vr. 19 15:46:34 seb-e6410 umount[1458]: umount: /dev/.bootchart/proc: target is busy
[15:14] <pitti> ah, perhaps this is normal then, but it looks odd for sure
[15:14] <seb128_> I've the bootchart package installed
[15:14] <pitti> seb128_: oh, you have an /etc/init.d/bootchart
[15:14] <pitti> seb128_: I don't think I ever tested that with systemd
[15:14] <seb128_> guess so
[15:14] <pitti> but that could very plausibly be the cause
[15:14] <seb128_> but that's not new
[15:14] <seb128_> ok
[15:15] <seb128_> pitti, after 2 minutes the plymouth logo went away
[15:15] <pitti> seb128_: does that actually work? (or rather, did?)
[15:15] <seb128_> I've only an empty screen now
[15:15] <pitti> hm, so why no VTs and debug shell; darn
[15:15] <seb128_> ohh
[15:15] <seb128_> I've a vt1
[15:15] <seb128_> shrug
[15:15] <seb128_> trying to log in displayed some logind not starting error
[15:16] <seb128_> and bounced me to xfailsafe
[15:16] <seb128_> ah
[15:16] <seb128_> got my vt
[15:16] <seb128_> systemctl status hangs :-/
[15:16] <seb128_> systemd is NOT happty
[15:16] <pitti> ah, bootchart depends: upstart
[15:17] <pitti> sounds like missing dbus
[15:17] <seb128_> "Failed to read server status: ... timeout"
[15:17] <pitti> *nod* (no dbus)
[15:18]  * pitti installs bootchart and upstart, uninstalls systemd-sysv, and boots with init=/bin/systemd
[15:18] <pitti> hm, that works
[15:18] <seb128_> I've virtualbox installed
[15:19] <seb128_> the line before the hangs on that box is virtualbox-guest-utils
[15:20]  * pitti installs that, too
[15:21] <seb128_> I don't understand why it would work without "quiet" though :/
[15:21] <pitti> yeah
[15:22] <pitti> seb128_: the main plymouth related change in 219 was the addition of didrocks's fsckd which tries to connect to plymouth
[15:22] <Laney> bleh, my system just hard locked
[15:23] <seb128_> Laney, one of those days!!
[15:23] <pitti> seb128_: for experimentation, could you try sudo systemctl mask systemd-fsckd ?
[15:23] <didrocks> can be the plymouth spam?
[15:23] <seb128_> "spam"?
[15:23] <didrocks> seb128_: if plymouth goes down, it tried to reconnect
[15:23] <seb128_> pitti, I purge virtualbox-utils, was not it
[15:23] <didrocks> tries*
[15:24] <didrocks> but yeah, masking systemd-fsckd can help as pitti told
[15:24] <seb128_> back on plymouth stucked animating dots
[15:24] <seb128_> can I do that without dbus?
[15:24] <ogra_> "rolex replica now cheap - contact your plymouth daemon !! "
[15:24] <seb128_> or is that going to fail like systemctl status?
[15:24] <pitti> wait
[15:24] <ogra_> "your plymouth won the lottery !!"
[15:25]  * Laney sinbins ogra_ 
[15:25] <ogra_> :)
[15:25] <pitti> seb128_: sudo ln -s /dev/null /etc/systemd/system/systemd-fsckd.service
[15:25] <didrocks> you can mask the unit manually with the null symlink
[15:25] <didrocks> yeah
[15:25] <didrocks> seb128_: also, do you mind checking if fsck runs?
[15:25] <seb128_> didrocks, how? I can't access to a vt
[15:25] <seb128_> well, not before the timeout that makes plymouth go away
[15:26] <didrocks> where did you type systemctl then?
[15:26] <didrocks> ah ok
[15:26] <didrocks> I doubt fsck would though run at every boot
[15:26] <didrocks> (and so systemd-fsck should exits without contacting systemd-fsckd)
[15:26] <didrocks> and thus plymouth
[15:27] <pitti> didrocks: that might be it
[15:27] <seb128_> when plymouth timeout, going to vt7 I've
[15:27] <pitti> didrocks: I do have it running after a clean boot in my VM
[15:28] <didrocks> pitti: oh?
[15:28] <seb128_> [*** ] (3 of 4) A Start job is running for Wait for Plymouth Boot Screen to quit (2min 43s / no limit)
[15:28] <seb128_> where the * are red
[15:28] <pitti> didrocks: it's still running actually
[15:28] <seb128_> the message was there on vt1 and changing
[15:28] <seb128_> before I tries to log in
[15:28] <didrocks> pitti: but only first boot, right?
[15:28] <didrocks> hum, weird
[15:28] <didrocks> fsck did run?
[15:28] <pitti> didrocks: no, I rebooted like 10 times
[15:28] <seb128_> no fsck running
[15:28]  * didrocks is puzzled
[15:28] <didrocks> seb128_: systemd-fsckd was running?
[15:28] <didrocks> (if you didn't mask)
[15:29] <Laney> oops, I just rebooted to systemd for the lolz
[15:29] <seb128_> didrocks, yes, didn't try to mask yet
[15:29] <seb128_> doing that now
[15:29] <pitti> Feb 19 16:27:13 pid1 systemd[1]: Listening on fsck to fsckd communication Socket.
[15:29] <pitti> Feb 19 16:27:13 pid1 systemd[1]: Starting fsck to fsckd communication Socket.
[15:29] <pitti> Feb 19 16:27:13 pid1 systemd-fsck[172]: /dev/vda1: clean, 188260/1179648 files, 1021730/4718592 blocks
[15:29] <Laney> lots of stuff is taking ages to start
[15:30] <didrocks> pitti: do you still have some systemd-fsck instances running?
[15:31] <didrocks> fscanf on the fsck pipe should return != 4
[15:31] <didrocks> and thus, systemd-fsck closes after the connection
[15:31] <pitti> $ sudo systemctl --all|grep fsck
[15:31] <pitti> [sudo] password for martin:
[15:31] <pitti>   systemd-fsck-root.service                                                           loaded    active   exited    File System Check on Root Device
[15:31] <didrocks> and systemd-fsckd doesn't even try to connect to plymouth
[15:31] <pitti>   systemd-fsckd.service                                                               loaded    active   running   File System Check Daemon to report status
[15:31] <pitti>   systemd-fsckd.socket                                                                loaded    active   running   fsck to fsckd communication Socket
[15:32] <seb128_> didrocks, pitti, with systemd-fsck masked I get a purple screen with no plymouth logo and it doesn't boot, get stucked on there
[15:32] <pitti> didrocks: so, -root was running, seems it didn't properly tell fsckd "I'm done"?
[15:32] <didrocks> pitti: at boot time, but after a while, (30s) systemd-fsckd.service exited?
[15:32] <pitti> didrocks: correct
[15:33] <didrocks> pitti: yeah, so expected, and it didn't even connect to plymouth (normally)
[15:33] <pitti> didrocks: fsckd to inactive/dead, the socket to active/listening
[15:33] <pitti> seb128_: I hope that was a typo in IRC only, that you masked fsckd and not fsck :)
[15:33] <seb128_> pitti, correct :-)
[15:33] <didrocks> pitti: yeah, so it's working as expected, we do wake up systemd-fsckd, I should probably do that only if we receive progress
[15:34] <desrt> attente_: okay.. reviewed again... as always, your patch is fine, but i'm picking on style issues :p
[15:34] <didrocks> pitti: but that's a noop, basically nothing happens after 30s and systemd-fsckd exits
[15:34] <attente_> desrt: thanks, looking at it again. vala did flag that as a warning
[15:34] <didrocks> (without connecting to plymouth)
[15:34] <pitti> didrocks: do you have any log_debug() there which could help?
[15:34] <pitti> didrocks: i. e. if seb128 boots with debug and plymouth, and collects the journal after the next (working) boot?
[15:35] <desrt> attente_: vala should be reasonable enough to know that inside of a foreach the variable will be non-null
[15:35] <pitti> seb128_: to be clear, without "splash" everything is fine, yes?
[15:35] <seb128_> pitti, correct
[15:35] <desrt> attente_: but uh... i guess that's why the mode is called "experimental"
[15:35] <didrocks> pitti: yeah, they are quite a lot of log_debug(), so that could work
[15:35] <didrocks> pitti: but as seb128_ still has the issue with systemd-fsckd masked…
[15:35] <desrt> attente_: odd that the indicator has it enabled, to be honest...
[15:35] <attente_> desrt: maybe it can't guarantee that for iterables in general..
[15:35] <didrocks> let's try to mask as well systemd-fsck@ as well?
[15:36] <desrt> attente_: it can in this case...
[15:36] <pitti> didrocks: yeah, I'd still llike to see the debug output; I don't have a better idea how to debug that remotely now
[15:36] <desrt> attente_: iterators work by ducktyping in a couple of possible ways
[15:36] <attente_> desrt: oh. right
[15:36] <pitti> didrocks: that might cause boot hangs, mounting the root fs etc. requires fsck?
[15:36] <desrt> attente_: in this way, it works by calling a next_value() function until it returns null
[15:36] <desrt> so it definitely knows :)
[15:36] <seb128_> pitti, sorry, it has the issue without splash as well :-/
[15:37] <seb128_> pitti, it doesn't have the issue if I remove "quiet" though, which doesn't make any sense to me
[15:37] <didrocks> seb128_: can you try to mask system-fsck as well?
[15:37] <pitti> seb128_: the long boot and failied dbus?
[15:37] <desrt> attente_: but good luck getting anyone to care.... it's called --enable-experimental-non-null for a reason
[15:37] <seb128_> pitti, no, atm I've no plymouth at all since I disabled fsckd
[15:37] <pitti> seb128_: oh wait -- if you boot without splash but with quiet, boot is hanging?
[15:37] <seb128_> didn't try to wait for 3 minutes
[15:37] <seb128_> yes
[15:38] <pitti> seb128_: with our without $vt_handoff?
[15:38] <didrocks> seb128_: sudo ln -s /dev/null /etc/systemd/system/systemd-fsck-root.service and sudo ln -s /dev/null /etc/systemd/system/systemd-fsck@.service
[15:38] <seb128_> with
[15:38] <seb128_> oh
[15:38] <seb128_> I stucked on
[15:38] <desrt> attente_: your countdown/countup loop is.... excessive :)
[15:38] <seb128_> A start job is running for File System Check on Root Device (40s / no limit)
[15:39] <seb128_> with a bouncing [***]
[15:39] <seb128_> this time
[15:39] <pitti> well, my VM is booting with or without $vt_handoff
[15:39] <seb128_> with quiet and no splash
[15:39] <seb128_> that job counting
[15:39] <seb128_> 1m15 now
[15:39] <didrocks> I guess it's trying to connect to the socket and wait
[15:40] <didrocks> (systemd-fsckd socket)
[15:40] <didrocks> now that systemd-fsckd is masked
[15:40] <pitti> seb128_: ok, it's a known thing that fsck doesn't report progress with quiet (not sure if that's a bug or a feature); do you think this could actually be a due fsck on your root fs?
[15:40] <pitti> ah, right
[15:40] <seb128_> I doubt it
[15:40] <seb128_> it's a 80G ssd
[15:40] <seb128_> it usually takes less than a minute
[15:40] <seb128_> and it's 3 min now and counting
[15:40] <didrocks> yeah, I guess it's blocked on the socket
[15:41] <pitti> I can reproduce a hang
[15:41] <didrocks> can you try to mask that unit to ensure it's all due to fsck-root?
[15:41] <pitti> with masking fsckd and booting with "quiet" but no splash
[15:41] <seb128_> pitti, I sent you a screen by email from my phone
[15:41] <didrocks> pitti: yeah, but not sure the first hangs is the same
[15:41] <seb128_> pitti, k, that's what I have as a config
[15:41] <pitti> so I guess masking fsckd isn't such a great idea after all
[15:41] <didrocks> this one is expected
[15:42] <seb128_> why is removing "quiet" fixing it?
[15:42] <pitti> but I don't get any other hang
[15:42] <pitti> ah, the $vt_handoff won't let me see the error message, that's what's causing the empty screen
[15:42] <pitti> yeah, I get symptoms like seb128 now
[15:43] <pitti> even the low-graphics mode now after some 5 mins :)
[15:43] <didrocks> without masking?
[15:43] <seb128_> :-)
[15:43]  * seb128_ removes the masking
[15:43] <didrocks> seb128_: no, please adds the masking on the others I asked
[15:43] <didrocks> add*
[15:44] <pitti> didrocks: no, with masking
[15:44] <seb128_> didrocks, let me read backlog
[15:44] <pitti> so if I mask fsckd *and* boot with "quiet $vt_handoff", I get the trouble
[15:44] <didrocks> pitti: yeah, as said, this is expected as the socket is blocking
[15:44] <didrocks> but that doesn't explain the first issue seb128_ had
[15:45] <pitti> if I boot without all options, I at least see the messages, but still blocking
[15:45] <pitti> right
[15:45] <seb128_> shrug, I don't manage to boot anymore now
[15:45] <pitti> actually, no -- without any options it doesn't hang (very long)
[15:45] <pitti> seb128_: boot with upstart (under advanced options in grub)
[15:46] <seb128_> pitti, yeah, I was going to do that by editing the init= :-)
[15:46] <didrocks> seb128_: did the option for you man :)
[15:46] <seb128_> didrocks, let me try
[15:47] <seb128_> shrug, you can't even ctrl-alt-del reboot when it's stucked waiting on thge socket
[15:47] <didrocks> pitti: I guess removing the non blocking socket wasn't a good idea after all :p
[15:48] <pitti> seb128_: press it 7 times in 2 s
[15:48] <pitti> err, "more than 7x"
[15:48] <seb128_> k
[15:48] <pitti> (that's an emergency fallback; haven't tested it yet)
[15:48] <seb128_> do I need to hang a chicken as well?
[15:48] <pitti> seb128_: ok, sorry for the bad advice with masking
[15:49] <pitti> seb128_: on the bright side, with that I reproduced something which is veeeery close to your symptoms, so it's useful after all
[15:49] <didrocks> pitti: actually, that's a good point that seb128_ masked it, I think I should reintroduce non waiting socket for this
[15:50] <seb128_> didrocks, ok, boots fine after masking fsck-root and @
[15:51] <didrocks> ok, so clearly related to this… what happens :/
[15:51] <seb128_> I also had a fsck run when I booted in recovery
[15:51] <seb128_> it took like 30 seconds
[15:51] <pitti> we don't have a debug journal for what actually happens, right?
[15:51] <seb128_> so it's not fsck holding boot for 3 minutes
[15:51] <pitti> i. e. without any masking, and plymouth and quiet and stuff
[15:52] <seb128_> pitti, the pastebin from earlier is a debug journal
[15:52] <pitti> yeah, it's clearly hanging at trying to talk to the socket
[15:52] <didrocks> there are quite a log of debug in system-fsckd, less then systemd-fsck
[15:52] <didrocks> but yeah, would be interesting to get the systemd-fsckd and systemd-fsck-root debugs
[15:52] <pitti> seb128_: ah, ok
[15:52] <pitti> http://people.canonical.com/~seb128/log ?
[15:53] <pitti> that doesn't have any fsckd messages
[15:53] <didrocks> nor fsck…
[15:53] <seb128_> let me try again
[15:53] <seb128_> removing all the masks and doing a debug boot
[15:57] <seb128_> bah
[15:57] <seb128_> my system works now
[15:58] <seb128_> I wonder if there was a fsck needed and it was never completing
[15:58] <didrocks> argh
[15:58] <seb128_> which it did when I booted in recovery
[15:58] <didrocks> do you mind forcing a fsck?
[15:58] <pitti> seb128_: thanks for the picture
[15:58] <seb128_> there is a flag to force it
[15:58] <seb128_> pitti, yw :-)
[15:58] <seb128_> didrocks, what's the file to touch again?
[15:58] <pitti> seb128_: "failed to listen on fsck to fsckd communication Socket"
[15:58] <pitti> didrocks: ^ does that tell you anything?
[15:59] <didrocks> pitti: yeah, it did write this, one sec
[15:59] <pitti> seb128_: sudo tune2fs -C 50 /dev/sdXX
[15:59] <seb128_> pitti, the picture was from fsckd masked
[15:59] <pitti> seb128_: ah, ok; that's expected then
[15:59] <pitti> seb128_: but I doubt that the actual fscking is related to that
[16:00] <didrocks> pitti: hum, no…
[16:00] <didrocks> so yeah :)
[16:00] <seb128_> ok, so forced fsck
[16:01] <didrocks> so, at least, it means the bailing out works
[16:01] <didrocks> now, let's see with your manual fsck forcing
[16:01] <seb128_> but that works, it indicates the % on plymouth
[16:01] <didrocks> :/
[16:01] <seb128_> and boots then*
[16:01] <pitti> yay heisenbug
[16:01] <seb128_> :-/
[16:01] <seb128_> thanks guys
[16:01] <seb128_> I can ping you again if it ever comes back
[16:02] <pitti> so I still think when it hung for you there was some problem to talk to fsckd
[16:02] <didrocks> yeah, especially if you can reproduce it in loop
[16:02] <didrocks> right, probably
[16:02] <didrocks> would be nice to know exactly why…
[16:02] <seb128_> bah
[16:02] <seb128_> doing it again, on the reboot after the fsck
[16:02] <seb128_> I didn't boot with debug though
[16:02] <seb128_> let me try to reboot
[16:03] <seb128_> I can journalctl -b -n anyway to get that log
[16:03] <didrocks> that's weird… as the next one was working as expected
[16:03] <didrocks> yeah
[16:04] <pitti> also, in http://people.canonical.com/~seb128/log there was no actual fsck
[16:04] <Laney> sooooooooo systemd takes ages to boot my system
[16:05] <pitti> fÃ©vr. 19 15:45:10 seb-e6410 systemd-fsck[272]: /dev/sda1Â : propre, 937151/4685824 fichiers, 16702765/18730240 blocs
[16:05] <didrocks> maybe Laney got the same issue…
[16:05] <pitti> I know what "prope" means :)
[16:05] <Laney> well it eventually timed out and booted
[16:05] <seb128_> sooo
[16:05] <Laney> kernel is 76 seconds, then networking is $ages
[16:05] <Laney> from a systemd-analyze plot
[16:05] <Laney> you probably can't be blamed for the kernel part, eh :)
[16:05] <pitti> Laney: journalctl | pastebinit ?
[16:06] <didrocks> Laney: yeah :p
[16:06] <pitti> well, 76 s is absurdly long
[16:06] <Laney> indeed
[16:06] <pitti> I figure that doesn't happen under upstart?
[16:06] <Laney> don't know
[16:06] <Laney> oh I did have bootchart installed, maybe I have some of those lying about
[16:06] <pitti> ah, don't :)
[16:06] <pitti> (I mean, uninstall it)
[16:07] <pitti> init=/lib/systemd/systemd-bootchart if you actually want one
[16:07] <Laney> oh yeah LOADS!
[16:07] <Laney> I mean from my previous upstart boots
[16:07] <seb128_> didrocks, pitti, you have email
[16:07] <pitti> Startup finished in 4.583s (firmware) + 4.202s (loader) + 2.719s (kernel) + 4.569s (userspace) = 16.075s
[16:07] <seb128_> that's my vt7 after the plymouth timeout
[16:08] <pitti> that can most certainly be improved, but it's not too bad, given that we did exactly zero work to optimize it
[16:08] <seb128_> A start job is running for oFono Mobile telephony stack (17s / 1min30)
[16:08] <didrocks> seb128_: not what I was expected…
[16:08] <seb128_> is that sort of thing expected?
[16:09] <didrocks> so, the first hang would have been oFono?
[16:09] <Laney> pitti: ah, I think that's lies
[16:09] <seb128_> dunno
[16:09] <Laney> at least part of it
[16:09]  * didrocks isn't familiar with that screen
[16:10] <pitti> I didn't get seb128's second mail yet
[16:10] <Laney> it was still trying to initialise some network iface even after the system was up
[16:10] <pitti> (btw, welcome to #ubuntu-bootwoes)
[16:10] <didrocks> pitti: 344Kb, too much for your mailbox :p
[16:10]  * seb128_ pets good old upstart
[16:10] <Laney> http://paste.ubuntu.com/10309940/
[16:11] <seb128_> didrocks, pitti, well at least I can easy reproduce again :/ doing a debug boot atm, waiting for plymouth to timeout so I go to a vt
[16:11] <didrocks> seb128_: always oFono?
[16:11] <seb128_> dunno yet, I can't get to anything until plymouth timeouts
[16:11] <pitti> Laney: hm, that's a mere 7 seconds
[16:11] <pitti> from first message to graphical.target
[16:12] <Laney> definitely did take longer
[16:12] <Laney> where does it get the 1min15.966 seconds from?
[16:12] <didrocks> ok, at least, fsck/fsckd doesn't hang Laney's laptop
[16:12] <Laney> desktop
[16:12] <Laney> laptop/systemd is super fast!
[16:12] <didrocks> seb128_: just for my understanding, so you boot, plymouth timeouts and drop you into that vt?
[16:13] <Laney> didn't try with 219 yet though
[16:13] <seb128_> didrocks, no, just goes away, then I can vt switch
[16:13] <seb128_> didrocks, vt7 is the screenshot I tool
[16:13] <seb128_> took
[16:13] <seb128_> I can log in on vt1
[16:13] <seb128_> well, "log in", then xfailsafe kicks in
[16:13] <didrocks> seb128_: ah ok, vt7…
[16:13] <didrocks> seb128_: if you notice some bugs in xfailsafe, it's on me :)
[16:14] <seb128_> :-)
[16:14]  * didrocks forgot that was this cycle as well
[16:15] <didrocks> seb128_: always, can locate ofono | grep service, I don't have any here
[16:15]  * didrocks smells a touch thingy…
[16:15] <pitti> Laney: ok, I'm afraid I don't see anything slow in that log; it starts at 15:40:38, eth0 is up at 15:40:42, lightdm is running at 15:40:45
[16:16]  * Laney reboots again
[16:17] <seb128> didrocks, ofono: /lib/systemd/system/ofono.service
[16:17]  * Laney uses irc-as-a-stopwatch
[16:17] <pitti> Laney: oh! I see you are affected by the "spontaneously unmounts my partitions" issue
[16:17] <didrocks> seb128: maybe try to hem… mask… it :)
[16:17] <Laney> grub...
[16:17] <Laney> hitting enter now
[16:17] <pitti> Laney: you want to upgrade your system, there was a badly broken lxcfs which messed up stuff
[16:17] <Laney> black screen
[16:17] <pitti> Laney: current vivid has that fixed, and systemd 219 has a robustification
[16:18] <seb128> didrocks, pitti, http://people.canonical.com/~seb128/log ... debug log from buggy boot
[16:18] <Laney> hmm, I thought I did dist-upgrade, when did that land?
[16:18] <pitti> Laney: bug 1419623
[16:18] <pitti> Laney: systemd 218-10ubuntu1, and lxcfs 0.5-0ubuntu2, but already a week ago
[16:18] <didrocks> seb128: pitti: yeah, the hang is way too late to be systemd-fsck* related (as it's blocking other phases and you won't be at the network stage there)
[16:19] <Laney> surely I have those
[16:19] <Laney> will see in a second
[16:19] <Laney> (still black screen)
[16:19] <didrocks> seeing it's just after some nm activity, it's probably this ofono…
[16:19] <didrocks> seb128: so try masking (I don't think anything else is depending on it) and reboot?
[16:20] <Laney> bleh
[16:20] <Laney> I hit escape
[16:20] <Laney> some stuff is still starting
[16:21] <Laney> ofono, plymouth, logind, virbr0
[16:22] <seb128_> didrocks, same issue with ofono uninstalled :-/
[16:22] <Laney> oh, xfallback
[16:22] <didrocks> seb128_: hum, and this time it's telling that it's waiting on… ?
[16:23] <seb128_> didrocks, waiting on the timeout ...
[16:23] <didrocks> seb128_: don't tell me that masking ofono was a bad idea, I don't want we create that meme :p
[16:23] <seb128_> lol
[16:25] <seb128_> it has 3 stuff he was cycle through
[16:25] <seb128_> login service
[16:25] <seb128_> waiting for plymouth to exit
[16:25] <seb128_> and some other
[16:25] <Laney> I think I'm in the same place as seb128_ now
[16:25] <Laney> \o/
[16:25] <seb128_> :-/
[16:25] <seb128_> oh, hey xfailsafe
[16:25] <didrocks> if only we could have a vt…
[16:26] <Laney> hahaha
[16:26] <Laney> I have a vt
[16:26] <seb128_> me too
[16:26] <didrocks> yeah, but not when it's hanging
[16:26] <Laney> oh right
[16:26] <didrocks> or while*
[16:26] <seb128_> just takes 3 minutes to get to it
[16:27] <pitti> GunnarHj: fresh trusty-proposed langpacks uploaded and accepted, they are building now
[16:27] <didrocks> so, maybe waiting on plymouth to exit would be due to fsckd in some form?
[16:27] <didrocks> (but the timeout is supposively 30s)
[16:27] <seb128_> could be
[16:27] <seb128_> masking fsck
[16:27] <seb128_> masking fsck* makes my system boot
[16:27] <GunnarHj> pitti: Great, Martin. I'm going to notify the translators later tonight.
[16:27] <didrocks> let's try to reinstall an older systemd-fsck, which doesn't talk to fsck
[16:28] <seb128_> didrocks, is that just the binary to copy?
[16:28] <didrocks> seb128_: yeah, /lib/systemd/systemd-fsck from https://launchpad.net/ubuntu/+source/systemd/218-8ubuntu2
[16:29] <didrocks> seb128_: you didn't upgrade this machine to 218-10ubuntu1 since Friday?
[16:29] <didrocks> (this was the first one with systemd-fsckd)
[16:29] <seb128_> I think I did
[16:29] <seb128_> I did daily upgrades
[16:30] <didrocks> I guess you would have got this one though
[16:30] <didrocks> but let's bail it out anyway
[16:30] <Laney> http://paste.ubuntu.com/10310208/
[16:30] <seb128_> maybe I didn't reboot
[16:30] <Laney> this troublesome boot starts at 16:19:49
[16:30] <seb128_> Laney, no such timestamp in your log?
[16:31] <didrocks> I was going to say…
[16:31] <Laney> there is ...
[16:31] <didrocks> seb128_: it's in the systemd binary btw (sorry, didn't told you)
[16:31] <didrocks> oh multiple boots
[16:31] <Laney> yeah it's just all of syslog
[16:32] <didrocks> so, fsck didn't block
[16:32] <pitti> From sebastien.bacher@laposte.net  Thu Feb 19 17:07:36 2015
[16:32] <didrocks> my only guess at this point (if fsckd is to blame) is that it hangs plymouth
[16:32] <pitti>  Subject: Screenshot
[16:32] <pitti>   Folder: spam
[16:32] <pitti> seb128_: ^ sorry
[16:32] <pitti> seb128_: what kind of pictures do you send me? :-)
[16:33] <seb128_> lol
[16:33] <didrocks> pitti: next time he will send with "Get a billion dollars in 30 minutes" :)
[16:35] <pitti> didrocks: yeah, sounds like it; sorry, got diverted in other channels -- did you ask Laney to mask the magic stuff and try with that already?
[16:35] <Laney> systemd-fsckd ofono ?
[16:36] <pitti> systemd-fsck-root also, I believe?
[16:36] <pitti> (didrocks knows that better, sorry)
[16:36] <didrocks> pitti: seb128_ is trying to downgrade systemd-fsck binary first
[16:36] <didrocks> Laney: systemd-fsck-root.service
[16:36] <Laney> okey dokey
[16:37] <pitti> Laney: ok, so perhaps let's wait until didrocks is done with debugging that with seb, and then we'll try the same on your box?
[16:37] <Laney> I'm suspicous that it booted properly the previous time
[16:37] <Laney> so could indeed be fsck
[16:37] <didrocks> yeah, sounds good :)
[16:37] <Laney> 'properly' but slow
[16:37] <pitti> I'm sure that using btrfs magically saves me from that, or it's just a weird timing difference
[16:37] <pitti> although my test VM does have ext4
[16:37] <didrocks> well, I never had any issue with ext4 here
[16:37] <seb128_> didrocks, pitti, sorry, I don't have the issue anymore now :/
[16:38] <Laney> how do I see if it wants to fsck?
[16:38] <didrocks> seb128_: try harder! :)
[16:38] <didrocks> Laney: you should have progress reported on plymouth and /dev/console
[16:38] <didrocks> seb128_: that was before downgrading the binary?
[16:39] <seb128_> didrocks, yes, didn't try that yet, I just downloaded the deb
[16:39] <didrocks> argh :/
[16:39] <didrocks> Laney: do you still get it?
[16:39] <seb128_> I wanted to restore the masked units first
[16:39] <didrocks> like every boot?
[16:39] <seb128_> bah
[16:39] <seb128_> I forced fsck and I get no plymouth
[16:39] <seb128_> frozen on a purple screen
[16:40] <Laney> didrocks: I wanted to see if the drive thinks it needs fscking
[16:40]  * seb128_ power down and reboot
[16:40] <pitti> didrocks: what kind of death message does fsckd send to plymouth :)
[16:40] <seb128_> back at having the bug
[16:40] <didrocks> pitti: a random one apparently :p
[16:40] <pitti> didrocks: could that be any 32 bit vs. 64 bit thing?
[16:40] <didrocks> I doubt Laney is using 32 bits
[16:40] <seb128_> didrocks, pitti, it seems to start happening after a fsck run, well the boot after that
[16:41] <didrocks> that's… weird
[16:41] <didrocks> seb128_: so replace the binary
[16:41] <Laney> tune2fs is hanging
[16:41] <Laney> beh
[16:41] <pitti> Laney: wut?
[16:42] <Laney> the system is in some kind of disturbing state
[16:42] <didrocks> pitti: it's really easy to crash plymouth for the record with the wrong protocole
[16:42] <didrocks> so that can be it, but we both tested this I guess in multiple boots…
[16:44] <Laney> oh I think it's sudo that is hanging
[16:44] <Laney> PAM woes probably
[16:44] <pitti> Laney: D-BUS not yet running, I figure?
[16:44] <seb128_> Laney, in my case logind and dbus were unhappy
[16:45] <Laney> yes this went wrong for me
[16:45] <pitti> ps aux|grep message.*dbus-daemon ?
[16:45] <seb128_> didrocks, boots fine with old systemd-fsck
[16:45] <seb128_> let me restore the new one and see if that restore the bug
[16:46] <kenvandine> bregma, i got my yoga 2 pro, beautiful laptop!
[16:46] <kenvandine> bregma, but chrome sucks in high dpi :/
[16:46] <kenvandine> bregma, is there anyway to make chrome suck less?
[16:46] <pitti> Laney: could you try replacing /lib/systemd/systemd-fsck with http://people.canonical.com/~pitti/tmp/systemd-fsck ?
[16:46] <seb128_> kenvandine, talk to qengho
[16:46] <Laney> pitti: it's running but services which want to use it didn't start up
[16:46] <pitti> Laney: that's the amd64 binary from 218-8ubuntu2
[16:46] <kenvandine> bregma, and wow... what a nice display!
[16:47] <seb128_> pitti, is that an old one or a new with debug one?
[16:47] <Laney> pitti: okay
[16:47] <kenvandine> qengho, any tips for making chrome work better with high dpi?
[16:47] <seb128_> pitti, Laney, old one works fine for me
[16:47] <didrocks> pitti: this is the one seb128_ installed FYI, let's see if reboots work for me
[16:47] <kenvandine> chromium seems to support it
[16:47] <didrocks> him*
[16:47] <kenvandine> but the menus are terrible in chromium
[16:47] <Laney> pitti: I pasted a syslog http://paste.ubuntu.com/10310208/ (search for 16:19:49) in case you can see anything useful
[16:47] <seb128_> didrocks, can you force a fsck and try to reboot twice?
[16:47] <didrocks> seb128_: so, interested into your second boot with the upgraded :p
[16:48] <didrocks> seb128_: you mean rebooting twice with fsck each time?
[16:48] <qengho> kenvandine: I may have something that works in a week or so, with release of 40.0.2214.115.
[16:48] <seb128_> didrocks, no, fsck once, then reboot
[16:48] <qengho> kenvandine: menus might be better for that.
[16:48] <qengho> kenvandine: for GOOG Chrome, i have no tips.
[16:48] <kenvandine> cool, i changed the resolution to 1080p for now :)
[16:49] <didrocks> seb128_: well, this is what you do with tune2fs, right? You get the fsck the first time, let it go. and then reboot?
[16:49] <kenvandine> which i shouldn't complain about
[16:49] <seb128_> didrocks, yes
[16:49] <didrocks> so you shouldn't get fsck the second time
[16:49] <seb128_> shrug, no plymouth on the fsck boot
[16:49] <didrocks> well fsck is running
[16:49] <didrocks> and telling "nothing to do"
[16:49] <kenvandine> but wow... at 3200x1800... beautiful!
[16:49] <kenvandine> just not the browser :/
[16:50] <kenvandine> firefox isn't much better
[16:50] <qengho> kenvandine: you can fix like four times the number of bugs, with that much screen!
[16:50] <kenvandine> qengho, exactly!
[16:50] <didrocks> seb128_: with the old version?
[16:50] <didrocks> or upgraded to the new one?
[16:50] <seb128_> new one
[16:51] <kenvandine> bregma, the touch pad annoys me more than the keyboard, it's really sensitive to taps
[16:51] <kenvandine> turned that off :)
[16:51] <didrocks> I don't understand, I don't send anything to plymouth if there is no fsck to do…
[16:51] <didrocks> so, why the second time wouldn't work well :/
[16:52] <seb128_> maybe it's nothing to do with it
[16:52] <didrocks> well, it sounds like it though :/
[16:52] <seb128_> in fact I had the run where fsck is needed not displaying plymouth on some boot
[16:52] <pitti> Laney: looks like plymouth indeed; so, things to try: (1) test with the older sytemd-fsck, or (2) test booting without "splash"?
[16:52] <seb128_> so I sit on power down
[16:52] <seb128_> because it seemed stucked
[16:53] <seb128_> maybe it made fsck unhappy
[16:53] <seb128_> and send something that plymouth doesn't handle
[16:53] <bregma> kenvandine, yeah, a little annoying until you get used to it
[16:54] <didrocks> seb128_: ah ok, so you would still have fsck on the second time
[16:54] <didrocks> and I send something to plymouth that it doesn't like
[16:54] <didrocks> but sometimes, for you, it's working
[16:54] <Laney> pitti: ack, trying without splash
[16:54] <didrocks> and here, every boot is :/
[16:54] <seb128_> didrocks, that's my guess
[16:55] <kenvandine> bregma, the tap to click is so touchy, i can't really use the indicators... but that could be me using only thinkpad's for 15 years :)
[16:55] <didrocks> ok, so the thing that changed last minute is the Control+C
[16:55] <kenvandine> and always disabling the touchpad completely :)
[16:55] <pitti> so, bug report; fsckd sends ping of death to plymouth?
[16:55] <didrocks> as plymouth boot and plymouth x11 have different protocoles
[16:56] <Laney> how come it makes dbus fail to work properly?
[16:56] <kenvandine> this is my first non-thinkpad in probably 15 years
[16:56] <didrocks> seb128_: it's on an amd64 machine?
[16:56] <seb128_> didrocks, 32bits for me
[16:57] <didrocks> hum, mind if I send you a patch then? and rebuild systemd? (just extract systemd-fsckd from it)
[16:57] <didrocks> I want to remove the "cancel" option
[16:57] <Laney> pitti: no 'splash' -> still broken
[16:57] <Laney> Still seeing 'Wait for Plymouth to quit'
[16:57] <bregma> kenvandine, mine is a clickpad, I never tap-to-click because of the lack of tactile feedback
[16:58]  * bregma needs clicks or does not compute
[16:58] <Laney> Plymouth Boot Screen
[16:59] <kenvandine> bregma, yeah, i'm happier with that
[16:59] <didrocks> seb128_: that should be enough: http://paste.ubuntu.com/10310639/
[17:00] <kenvandine> qengho, is there a PPA for chromium that you land stuff in before vivid?
[17:00] <qengho> kenvandine: Yes.  ppa:canonical-chromium-builds/stage
[17:01] <kenvandine> i'll enable that and hope to see some improvements :)
[17:01] <qengho> kenvandine: Nothing new there for another day or so.
[17:01] <kenvandine> qengho, mind pinging me when i should try testing high-dpi again?
[17:01] <qengho> kenvandine: sure.
[17:01] <kenvandine> fwiw... windows 8.1 isn't much better at that resolution :)
[17:02] <kenvandine> IE handles it fine
[17:02] <kenvandine> but quite a few apps i played with was terrible
[17:02] <kenvandine> the browsers are the only apps i had problems with on vivid
[17:02] <kenvandine> all the other apps i've tried worked well
[17:02] <kenvandine> so great job guys!
[17:02] <kenvandine> bregma, ^^ i suspect you had something to do with that :)
[17:07] <Laney> doesn't look like the old systemd-fsck is helping
[17:08] <seb128_> in fact I just had the issue with it as well I think
[17:08] <seb128_> waiting for the system to give me back a login to check that I correctly copied the binary
[17:08] <didrocks> seb128_: with the old systemd-fsck?
[17:08] <seb128_> yes
[17:09] <didrocks> pitti: this is becoming crazy ^ :/
[17:09] <seb128_> fsck is maybe just a redherring
[17:09] <seb128_> could be another bug in new systemd
[17:09] <didrocks> yeah
[17:09] <didrocks> Laney: you told you were not on latest systemd though?
[17:10] <didrocks> and did my memory/reading/english/french betrayed me?
[17:10] <Laney> should be, let me check
[17:10] <Laney> ya, 219
[17:10] <pitti> Laney does have 219
[17:10] <Laney> how come I get waiting for plymouth even without 'splash', btw?
[17:11] <seb128_> didrocks, pitti, so yeah, issue is there as well with old systemd-dsck
[17:11] <pitti> seb128_: that is, boot hangs on ofono and other stuff?
[17:11] <didrocks> ConditionKernelCommandLine=splash
[17:11]  * pitti lost track a bit, sorry (getting pinged in other channels)
[17:11] <seb128_> pitti, I removed ofono, so not it
[17:12] <didrocks> Laney: and you can't get a status of which job exactly it is waiting on?
[17:12] <Laney> there's some general problem with dbus
[17:12] <Laney> I think ofono is probably an instance of that
[17:12] <seb128_> yes, things timeout
[17:12] <didrocks> Laney: shouldn't be plymouth-start.service due to this ConditionKernelCommandLine
[17:12] <seb128_> likely
[17:12] <Laney> didrocks: grep splash /proc/cmdline -> nothing
[17:13]  * didrocks backlog to see the exact line that Laney is seeing
[17:13] <didrocks> "Plymouth Boot Screen"
[17:13] <Laney> I typed that
[17:13] <didrocks> Laney: do you have a "Show" before?
[17:13] <didrocks> Wait for
[17:13] <didrocks> or Terminate ?
[17:14] <Laney> terminate IIRC
[17:14] <didrocks> ExecStart=-/bin/plymouth quit
[17:14] <didrocks> unconditionally
[17:14] <didrocks> so we always tries to quit plymouth
[17:14] <didrocks> which is a noop I guess if not running
[17:14] <Laney> seems so
[17:15] <didrocks> then, maybe the dbus issues makes systemd puzzle or it's really that plymouth quit hangs
[17:15] <didrocks> Laney: the timeout is 20s, doesn't seem what you see though, right?
[17:15] <Laney> it has no timeout
[17:15] <Laney> just counts up forever
[17:15] <seb128> worry, I'm stopping debugging for today, need to go in less than 1 hour and I've stuff I wanted to get uploaded before feature freeze today
[17:15] <didrocks> seb128: yeah, I guess we won't solve it today TBH
[17:15] <Laney> some other jobs did get their timeouts though
[17:15] <didrocks> seb128: next step (tomorrow?) would be to downgrade to -10ubuntu1
[17:16] <didrocks> or 2
[17:16] <seb128> I've faith in Laney
[17:16] <didrocks> ahah :)
[17:16] <seb128> he can resolve it :-)
[17:16]  * didrocks should have stopped already btw :p
[17:16] <didrocks> Laney: the timeout is once the "quit" job fires
[17:16] <Laney> you're funny
[17:16] <didrocks> so if everything else is delayed
[17:17] <didrocks> I guess this one isn't accurate
[17:17] <didrocks> Laney: ok, let's try a bigger hammer, downgrade to -10ubuntu2?
[17:17] <Laney> ok
[17:17] <Laney> do you have the binaries on hand?
[17:17] <Laney> oh maybe ssh is working
[17:17] <Laney> don't fancy navigating LP at the console :p
[17:18] <didrocks> uno momento!
[17:18] <Laney> it's ok, ssh is working, I can scp them
[17:18] <didrocks> ah good: https://launchpad.net/ubuntu/+source/systemd/218-10ubuntu2/+build/6984026/+files/udev_218-10ubuntu2_amd64.deb
[17:18] <didrocks> (so that you can win 20s :p)
[17:19] <Laney> so many packages
[17:21]  * didrocks gives some TCP ones to Laney :p
[17:21] <Laney> wget --recursive \o/
[17:22] <Laney> come on udev postinst
[17:22] <Laney> you can do it
[17:23] <Laney> ...
[17:23] <Laney> can you?
[17:24]  * didrocks trusts in udev postinst :p
[17:24] <seb128> attente_, your osk .sh change seems to work fine on the device for me
[17:24] <Laney> wait what
[17:24] <Laney> I didn't have new udev stuff before
[17:25] <didrocks> oh?
[17:26] <attente_> seb128: great, thanks!
[17:26] <Laney> didrocks: I'd done apt-get install systemd-sysv but not dist-upgraded
[17:26] <Laney> let me try rebooting with 218 anyway
[17:27] <didrocks> yeah… let's see
[17:28] <Laney> didrocks: lightdm!
[17:29] <didrocks> Laney: you see lightdm, you mean, or you did spot it was lightdm? :)
[17:29] <Laney> I see lightdm now
[17:29] <Laney> i.e. it works
[17:29] <didrocks> "long time no see" :)
[17:30] <didrocks> mind reupgrading, just to confirm?
[17:30] <didrocks> oh before that
[17:30] <didrocks> please copy /lib/systemd/system-fsckd and /lib/systemd/system-fsck somewhere
[17:30] <Laney> k
[17:30] <didrocks> so that you can restore them
[17:30] <didrocks> just to check if it's the protocole change that would be in cause :p
[17:31] <Laney> erm
[17:31] <Laney> dist-upgrade wants to remove ubuntu-desktop
[17:31] <Laney> and all of xorg
[17:32] <willcooke> erm
[17:33] <didrocks> Laney: apt-get install <binary-packages>/vivid? :/
[17:33] <willcooke> Laney, you didnt add mlankhorst's ppa did you?
[17:33] <Laney> no
[17:33] <Laney> didrocks: can't on a dist-upgrade
[17:33] <Laney> aptitude points at xserver-xorg-core
[17:33] <Laney> meh, one thing at a time
[17:33]  * Laney leaves that behind for now
[17:34] <Laney> willcooke: oh wait, yes I did, ha
[17:35] <Laney> I just checked some package which wasn't in it
[17:35]  * Laney fail
[17:35] <willcooke> This is an epic day for me
[17:35]  * willcooke <-- l33t
[17:36] <willcooke> seb128, getting that power thing out the way has fixed 99% of my provlems
[17:36] <seb128> willcooke, great
[17:37] <willcooke> the 1% being my ability to type
[17:37] <seb128> lol
[17:38] <Laney> ok, systemd 219: take II
[17:41] <Laney> didrocks: seems bad again - try replacing those binaries?
[17:43] <didrocks> Laney: yes please
[17:45] <Laney> super ack
[17:48] <Laney> no good, looks like you are innocent
[17:49] <didrocks> |o|
[17:49] <didrocks> pitti: ok, bad news is that it seems there is a real regression in 219… :/
[17:50] <Laney> did you try it?
[17:53] <didrocks> Laney: I'm running it, no issue here
[17:53] <didrocks> (did reboot twice since yesterday)
[17:53] <didrocks> and I'm sure Martin did as well…
[17:53] <Laney> nod
[17:53] <Laney> always the way
[17:55] <didrocks> of course :/
[17:59] <mlankhorst> Laney: x-staging is needed for xorg-server 1.17
[17:59] <Laney> it's okay
[17:59] <Laney> I didn't really want to run it
[17:59] <didrocks> Laney: let's dig that more tomorrow I guess, until then, you can reboot with upstart with the grub menu
[18:00] <Laney> didrocks: ya, no worries, I gtg in a minute anyway
[18:00] <Laney> btw 'busctl' works
[18:00] <Laney> so the system bus isn't completely broken
[18:00] <didrocks> interesting
[18:00] <didrocks> well, we'll see :)
[18:00] <Laney> fun!
[18:01]  * didrocks will go as well, playing with unity3d support in ubuntu!
[18:01] <didrocks> see you guys :)
[18:01] <Laney> bye!
[18:11] <seb128> calling it a day, have a nice evening
[18:11] <larsu> seb128: enjoy!
[18:11] <seb128> larsu, thanks
[18:14] <Laney> pitti: go to go now, but for info
[18:15] <Laney> I removed BusName from polkitd.service and SystemdService from /u/s/dbus-1/system-services/org.freedesktop.PolicyKit1.service and now I have lightdm again
[18:15] <Laney> tried this because journalctl -u dbus was showing polkit failing to get the name as its first action, which I guessed probably caused cascading failures
[18:17]  * Laney waves \o
[18:17] <larsu> bye Laney!
[18:43] <dagerian> anyone mind helping me out
[18:52] <pitti> hm, so I missed didrocks and Laney
[18:52] <pitti> and seb128 too
[21:13] <andrzejr> Hi, what is the status of libraries like libindicator or libido? I'm using the first one in xfce4-indicator-plugin for xubuntu and was planning to use the other one (not limited to xubuntu) but there are no releases newer than 12.10.
[21:14] <andrzejr> There are quite a few new versions in bzr so it looks as if these libraries were now only intended for use in Ubuntu. Is that correct?
[22:38]  * Bl4ckD34Th Bl4ckD34Th return to take your soul! You own to Bl4ckD34Th!!!
[22:41] <dobey> nope
[22:41] <Bl4ckD34Th> ok
[22:41] <Bl4ckD34Th> sorry