[05:55] <pitti> Good morning
[06:51] <ochosi> morning everyone
[06:52] <ochosi> larsu: since you said i should ping you if i don't get a response within a few days, here it comes! PING :D https://bugzilla.gnome.org/show_bug.cgi?id=744601
[06:57] <darkxst> ochosi, won't that conflict with unity where they do hide titlebars for maximised apps?
[06:58] <ochosi> darkxst: i'm not really an expert on unity over here, but since larsu approved it, i presume it's ok for them
[06:59] <darkxst> seb128, does unity rely on set_hide_titlebar_when_maximized, or do the global menu bar hacks override that?
[07:00] <seb128> hum, to hide what?
[07:00] <seb128> titlebars are handled by the wm and always removed afaik
[07:01] <seb128> if it was relying on a flag it would work on every application
[07:01] <ochosi> yeah, i think this line in evince is just a relic
[07:02] <pitti> bonjour seb128
[07:02] <seb128> pitti, salut, ça va ?
[07:03] <pitti> seb128: ça va bien, mieux que systemd :)
[07:03] <pitti> seb128, Laney: I filed bug 1423811
[07:03] <seb128> pitti, are Laney and I the only ones to see the issue?
[07:03] <pitti> I now get this as well
[07:03] <seb128> oh
[07:03] <seb128> great!
[07:03] <pitti> some dist-upgrade or change or whatever triggered it
[07:03] <pitti> so I'm debugging it now
[07:04] <seb128> going to be easier for you to debug
[07:04] <seb128> let me know how you debug
[07:04] <pitti> I added the minimal set of packages to downgrade there
[07:04] <seb128> can be useful for next time :-)
[07:04] <pitti> seb128, Laney: would be nice if you could confirm that you have exactly the same, i. e. downgrading these four packages and doing no other modifications makes things work again? (with and without splash)
[07:04] <seb128> can do that in a bit
[07:05] <seb128> but I need to do some catchup on email and stuff first
[07:05] <pitti> seb128: no worries
[07:05] <pitti> seb128: I'm fairly sure it's the same issue, it woudl be too much of a coincidence
[07:05] <pitti> Laney, seb128: or, eaiser: just wait until I have a fix, and if things still go haywire for you, you file another bug (but chances are low)
[07:06] <seb128> right, I was going to say
[07:06] <seb128> still please keep us updated on what you do and what you found
[07:08] <pitti> seb128: I got a debug journal and did the usual package bisecting first, so pretty much what you did yesterday
[07:08] <pitti> seb128: I now build a package with a sysv-generator fix, to ensure that it's not that (or maybe it actually is)
[07:08] <pitti> seb128: and then I'll start bisecting individual /lib/systemd/systemd-* binaries
[07:08] <pitti> and also have a good deep look at the debug log
[07:09] <pitti> (wrt. "what do I do now"); but I keep track of stuff in the bug report too
[07:09] <seb128> k
[07:10] <darkxst> seb128, well the hints come from gtk, but we have mostly been on CSD's for a while now, so....
[07:22] <didrocks> good morning
[07:22] <didrocks> seb128: pitti: I got the boot issue once this morning
[07:23] <seb128> lut didrocks
[07:23] <didrocks> spent 30 minutes rebooting/trying multiple things…
[07:23] <seb128> didrocks, pitti gets it as well
[07:23] <didrocks> didn't retrigger it
[07:23] <seb128> he's debugging
[07:23] <didrocks> ah
[07:23] <seb128> you guys and you "no, works fine here" :-)
[07:23] <didrocks> seb128: well, I did boot twice with the new systemd without any issue
[07:23] <seb128> didrocks, happy friday btw!
[07:23] <didrocks> and this morning, got it once on 10 boots!
[07:24] <didrocks> so clearly annoying issue :/
[07:24] <didrocks> happy friday seb128 :)
[07:24] <pitti> bonjour didrocks
[07:25] <pitti> yeah, until yesterday 219-1ubuntu1 was humming away fine for me, too..
[07:25] <didrocks> pitti: I don't want to say, but seb128 saw it first
[07:25] <pitti> didrocks: hereux vendredi !
[07:25] <didrocks> I will definitively put the blame on him :)
[07:25] <didrocks> and happily :p
[07:25]  * didrocks hugs seb128
[07:25] <didrocks> pitti: joyeux vendredi aussi!
[07:25]  * seb128 hugs didrocks back
[07:25] <pitti> didrocks: keeping track in bug 1423811
[07:25]  * didrocks opens
[07:26] <didrocks> oh, you were able to use list-jobs
[07:26] <pitti> sudo works, yes
[07:27] <didrocks> my vt1 login was totally screwed for me
[07:27] <pitti> without sudo it wants polkit which doesn't work
[07:27] <didrocks> no sudo, no dbus…
[07:27] <didrocks> the machine was really in a weird state
[07:27] <didrocks> all commands hanging basically
[07:28] <pitti> I get something funny in qemu as well: I see the plymouth dots on top of my X session
[07:29] <didrocks> so "sudo plymouth quit" didn't work
[07:29] <didrocks> (and we ignore the return value for this job)
[07:32] <pitti> that's unexpectedc -- my locally built .debs with merging a few trivial fixes from debian work
[07:32]  * pitti rebuilds our exact vivid package locally to verify
[07:33] <pitti> but that may explain why it worked for me until yesterday, when I got my self-built debs replaced with the archive's
[07:33] <didrocks> pitti: well, I always used the archive version, and so, on 12 boots since I upgraded, I only got the issue once
[07:34] <pitti> didrocks: obviously a race; it also works fine with teh archive debs in a VM
[07:35]  * pitti tries some other things, bbl
[07:35] <didrocks> good luck!
[07:42] <pitti> WTF, I managed to kill the dpkg database
[07:42] <pitti> /var/lib/dpkg/status is mostly empty
[07:46] <pitti> seb128, didrocks, Laney: it works again here without persistant journal
[07:47] <pitti> but I rm'ed mine; could you perhaps mv /var/log/journal{,.old} to keep it for reproducing, and check if that helps?
[07:47] <didrocks> pitti: I disabled persistent journal last week
[07:47] <didrocks> pitti: and so, got the issue this morning
[07:48] <pitti> ack, noting that down
[07:48] <didrocks> $ ls /var/log/journal
[07:48] <didrocks> ls: impossible d'accéder à /var/log/journal: Aucun fichier ou dossier de ce type
[07:48] <pitti> so now I hope I can get the issue again somehow
[07:48] <didrocks> yeah, definitively can't here :/
[08:19] <pitti> didrocks: *phew*, I got it in a VM! https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1423811/comments/3
[08:20] <pitti> that makes things a ton easier
[08:21] <didrocks> pitti: interesting, not sure how this is related as I didn't touch the journal for quite a while, but if this can trigger the race reliably, that's nice!
[08:21] <pitti> didrocks: well, reliable enough at least, for me
[08:23] <pitti> in qemu it only seems to hang once after that, but good enough I guess
[08:25] <didrocks> interesting…
[08:25]  * pitti runs off to get a haircut, bbl
[08:25] <didrocks> see you pitti :)
[08:25] <seb128> pitti, have fun!
[08:46] <willcooke> morning
[08:46]  * willcooke <-- no here
[08:47] <willcooke> *not
[08:47] <didrocks> hey willcooke-london :)
[08:48] <willcooke> So much for my day off
[08:48] <tsdgeos> hmmm
[08:48] <tsdgeos> guys i have no indicators at atll running
[08:49] <tsdgeos> is it something i did?
[08:49] <tsdgeos> or did some update land yesterday?
[08:49] <seb128> hey willcooke
[08:49] <didrocks> tsdgeos: do you have unity-panel-service running?
[08:49] <seb128> tsdgeos, desktop, phone, Ubuntu version, desktop env?
[08:49] <tsdgeos> didrocks: yes
[08:49] <tsdgeos> seb128: desktop
[08:50] <seb128> vivid?
[08:50] <tsdgeos> otherwise i'd be in #ubuntu-touch :D
[08:50] <tsdgeos> seb128: yes
[08:50] <seb128> https://launchpad.net/ubuntu/+source/unity/7.3.1+15.04.20150219.2-0ubuntu1 landed
[08:50] <seb128> do you have anything in your .cache/upstart/unity7.log
[08:51] <seb128> or unity-panel-service.log
[08:51] <tsdgeos> untiy7 is not interesting
[08:52] <tsdgeos> this is unity panel service http://paste.ubuntu.com/10321094/
[08:52] <tsdgeos> not sure if interesting or not
[08:54] <seb128> Trevinho, ^ can you help there?
[08:57] <tsdgeos> actually it's weird
[08:57] <tsdgeos> since indicator time is running for example
[08:57] <tsdgeos> but i can't see it
[08:57] <seb128> do you have any indicator showing or menus?
[08:58] <tsdgeos> the title of the app
[08:58] <tsdgeos> and the [x] to close
[08:58] <tsdgeos> no idea about appmenu
[08:58] <tsdgeos> since it's kind of broken in qt5 apps
[08:59] <tsdgeos> but probably not since firefox does not show me the menus either
[08:59] <tsdgeos> let me reboot
[08:59] <tsdgeos> and see if it fixes anything
[09:00] <larsu> ochosi, darkxst: what seb128 says. Unity always removes title bars for maximized windows, whereas gnome shell only does it when the application requests it (basically if it has window controls inside of its main toolbar)
[09:00] <larsu> but this has gone out of style anyway for csd
[09:03] <larsu> ochosi: pinging upstream about it
[09:04] <Laney> morning!
[09:04] <larsu> morning Laney!
[09:05] <Laney> ah pitti, you managed to get the bug?
[09:06] <pitti> Laney: yeah, I keep notes in the LP bug report
[09:06] <Laney> do you remember what I said yesterday too?
[09:06] <didrocks> hey Laney
[09:07] <Laney> 19/02 18:15:00 <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
[09:07] <pitti> Laney: it's a bit finicky to reproduce, but I now found a recipe that at least works on my laptop and in qemu
[09:07] <pitti> Laney: not everything, sorry; I got sidetracked by some other pings
[09:07] <Laney> hopefully that wasn't a coincidence
[09:08] <Laney> oh, maybe it was, now I have low graphics ^o)
[09:08] <pitti> Laney: do you use persistant journal?
[09:08] <Laney> yep
[09:09] <Laney> wait
[09:09] <pitti> I have a hunch that this is related to the new ACL tmpfiles.d feature
[09:09] <Laney> I'm getting confused between systems
[09:09] <pitti> but I'm currently bisecting the changes
[09:09] <Laney> I need to check
[09:09] <pitti> I have four debs to test, then a couple of binaries, etc.
[09:09] <Laney> I enabled it on this laptop, but that system → I just installed systemd-sysv and rebooted
[09:09] <Laney> (the one with the bug)
[09:10] <Laney> no, no persistent journal there
[09:10] <pitti> didrocks got it without persistant journal once, too, but it also applies ACLs to /run/systemd/journal/
[09:10] <pitti> so having a persistant journal is not "the" trigger, but it helps on my systems at least
[09:10] <didrocks> yeah, the ACL one is a good lead I guess
[09:10] <didrocks> pitti: tell us if you need help, I'm almost done with my backlog
[09:12] <tsdgeos> seb128: a reboot "fixed" it btw
[09:13] <tsdgeos> i'll see if it happens again
[09:13] <seb128> tsdgeos, weird :-/
[09:13] <seb128> tsdgeos, k, let we know
[09:13] <pitti> didrocks: can you reproduce it in a VM?
[09:13]  * pitti getting diverted by another high urgency issue again, argh
[09:15] <didrocks> pitti: I can give it a try, let me upgrade the VM to a more recent version
[09:18] <pitti> didrocks: btw, I edited /etc/default/grub to drop splash quiet and added systemd.debug-shell
[09:18] <pitti> then sudo update-grub
[09:19] <didrocks> pitti: ok, doing with that + persistent journal (but downloading a new iso for now)
[09:20] <pitti> meh, and now it stopped reproducing in vm
[09:23] <pitti> hah, and it starts again when I do an sbuild in the background on my host, to slow it down again
[09:25] <pitti> ah no, boot is just slower
[09:25] <pitti> bummer
[09:25] <mlankhorst> argh, using /bin/bash ../configure gives different results than ../configure
[09:26] <mlankhorst> giving the useless ../libtool: preserve_args+= --tag CC: not found
[09:31] <larsu> ochosi: pushed to master. Thanks!
[09:48] <didrocks> pitti: tried multiple reboots without quiet splash, creating persistent logs and nothing…
[09:49] <larsu> let me know if you guys need help debugging
[09:49] <didrocks> pitti: oh, however, my keyboard is now in qwerty, despite the indicator
[09:49] <didrocks> so, something fishy…
[09:50] <didrocks> LANG is right…
[09:50] <didrocks> and no LC_*
[09:52] <didrocks> loadkeys didn't work, and now, reboot and azerty…
[09:55] <didrocks> ah, got it this time
[10:03] <Laney> didrocks: did you get the bug?
[10:04] <davmor2> Hey guys on vivid desktop I can't update via software updater because of the extras repo is there any chance we can get them disabled if they are broken?
[10:04] <Laney> I turned of systemd dbus activation for logind too and it's booted a few times okay now ...
[10:05] <Laney> hi davmor2, do you mean upgrading from utopic?
[10:05] <didrocks> Laney: on qemu, once, on my system one as well (as said this morning ;))
[10:05] <davmor2> Laney: no fresh install
[10:05] <Laney> when did you install?
[10:06] <willcooke> change of plans, I will be here today
[10:06] <davmor2> Laney weekend
[10:06] <Laney> didrocks: lot of backlog, didn't read it all ........
[10:06] <didrocks> willcooke: sorry man :/
[10:06] <davmor2> Laney: last Saturday infact
[10:07] <Laney> it's supposed to not be enabled any more
[10:07] <Laney> https://launchpad.net/ubuntu/+source/apt-setup/1:0.80ubuntu7
[10:07] <Laney> try a new daily to double check?
[10:08] <willcooke> didrocks, thanks :)  It's not so bad.  I figure I wont need to work over the weekend, which is probably the better idea
[10:08] <davmor2> Laney: hmmmm should that not of got installed via update too though or will it not over write the existing list?
[10:09] <didrocks> willcooke: heh, not untrue
[10:09] <didrocks> grrrr, can't stop on shell-debug :/
[10:09] <Laney> davmor2: what existing list?
[10:09] <Laney> that's why I asked you if it was an upgrade
[10:09] <davmor2> Laney: only update from the fresh install on saturday
[10:10] <Laney> I don't think anything will fix it within vivid
[10:10] <Laney> only for new installs and upgrades after the fixes went in
[10:10] <didrocks> pitti: wait! I tried multiple reboots with upstart, and got one hang
[10:10] <didrocks> seb128: Laney ^
[10:11] <pitti> didrocks: with upstart?
[10:11] <Laney> with upstart?
[10:11] <didrocks> yeah
[10:11] <Laney> umm
[10:11] <davmor2> Laney: right.  I'll do a fresh install later then and see if it is fixed in that install
[10:11] <didrocks> init=/sbin/upstart
[10:11] <Laney> what are you suspecting?
[10:11] <seb128> different pb?
[10:11] <didrocks> don't know, but we got also newer kernels and such
[10:11] <didrocks> can maybe be unrelated to systemd
[10:11] <pitti> didrocks: where does it hang? I occasionally get graphics lockups when I boot without "quiet splash", but that's something else
[10:11] <Laney> it worked when I downgraded systemd though
[10:11] <seb128> it works with upstart for me
[10:12] <seb128> hangs every time with systemd
[10:12] <didrocks> seb128: Laney: well, it works 12 times in a raw here
[10:12] <didrocks> with latest systemd
[10:12] <didrocks> so seems $random, maybe systemd trigger it more…
[10:12] <didrocks> let me retry other reboots with upstart
[10:12] <Laney> well
[10:13] <didrocks> but I got the exact same behavior
[10:13] <seb128> we need to get at the bottom of it on a system having the issye
[10:13] <Laney> it's related to dbus service activation
[10:13] <didrocks> hanging, then xfailsafe…
[10:13] <Laney> for me
[10:13] <seb128> trying to do random config boots and draw conclusions is not leading anywhere
[10:13] <seb128> it's not consistant enough to do that
[10:14] <didrocks> confirming, hanging again, with upstart
[10:14] <didrocks> [   OK   ] on Started D-bus…
[10:14] <Laney> go to a vt
[10:14] <Laney> see if logind is running
[10:14] <didrocks> Laney: well, I'm unsure why my qemu doesn't enable me doing that
[10:14] <didrocks> I'm going to the qemu console
[10:14] <didrocks> use sendkey…
[10:15] <pitti> I haven't yet managed to get a reliable reproducer either; when I want to test with a different deb, I never get it any more, and then I also don't get it any more with the vivid deb
[10:15] <pitti> didrocks: alt+f9 works fine here in qemu (you need to grab the keyboard first)
[10:15] <didrocks> argh, it stopped being stalled after 60s and booted this time
[10:17] <didrocks> pitti: alt+f9 doesn't work here (after grabbing the keyboard)
[10:17] <didrocks> ok, hanging again
[10:17] <Laney> do it in virt-manager, then you get a nice menu to send those keys
[10:18] <didrocks> Started D-Bus system message bus
[10:18] <didrocks> and now unstall (I wasn't doing anything on my system)
[10:18] <didrocks> so maybe not the same thing, just a way slower boot
[10:19] <seb128> could be
[10:19] <seb128> if that was impacting upstart I'm surprised nobody else reported it
[10:19] <seb128> it's like 3 systemd users reported it
[10:19] <seb128> and 0 upstart users
[10:19] <didrocks> seb128: well, it boots in the end
[10:19] <seb128> and we probably have a lot more people on upstart than systemd
[10:19] <didrocks> just hanging for a while
[10:19] <seb128> systemd doesn't boot at the end
[10:19] <seb128> plytmouth go away that's all
[10:19] <seb128> then you can get to a vt
[10:19] <didrocks> yeah, but the root cause might be the same?
[10:19] <seb128> but you never get lightdm
[10:20] <seb128> could be I guess
[10:20] <seb128> systemd just not recovering from it?
[10:20] <Laney> well yes
[10:20] <Laney> because on systemd it breaks bus activation via systemd
[10:20] <Laney> on upstart that probably doesn't happen
[10:20] <pitti> yeah, and if downgrading to 218-10ubuntu2 also helps (just the 4 systemd binaries), that's another strong indication that it's systemd specific
[10:20] <Laney> ah bah, I think I've heisenbugged it
[10:20] <pitti> in the debug log I see lots of "[system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out"
[10:20] <seb128> same here
[10:21] <pitti> yeah, same here (heisenbug)
[10:21] <Laney> I just reverted the disable-systemd-bus-activation changes I did
[10:21] <Laney> and it still boots
[10:21] <Laney> hm, not the polkit one actually, lemme try that
[10:23] <Laney> kernel takes ages to init one of the drives :(
[10:23] <Laney> nah, it works now
[10:24] <Laney> after I've reverted all of the changes I made
[10:24] <Laney> :(
[10:24] <didrocks> Laney: told you, it's not 100%, maybe try multiple reboots as well?
[10:24] <Laney> it was 100% before
[10:24] <Laney> then it worked once and since then seems consistent
[10:25] <Laney> oh hang on, I forgot one more service ;-)
[10:27] <pitti> Laney: I had a certain success with https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1423811/comments/3
[10:27] <pitti> s/certain/some/ I mean
[10:27] <Laney> pitti: I never had persistent journal, but can try enabling that
[10:27] <pitti> just to slow things down a bit; plus booting without quiet/splash and with debug
[10:28] <didrocks> rebooting in loop, nothing :/
[10:30] <didrocks> ok, I can get sometimes this ~30s hang with systemd as well on the system dbus thingy
[10:30] <didrocks> but then, get to lightdm
[10:30] <didrocks> and systemctl status shows all services succeeding…
[10:31] <didrocks> maybe time for bootchart to see where it's waiting?
[10:35] <Laney> trying with debug/no quiet/no splash
[10:36] <Laney> no good
[10:36] <Laney> (in a world where 'good' is no good :P)
[10:37] <didrocks> hum, init=/lib/systemd/systemd-bootchart triggers a kernel panic here
[10:37] <didrocks> checked twice, no typo…
[10:38] <pitti> attempted to kill init?
[10:40] <didrocks> yeah
[10:42]  * pitti wonders how unhealthy http://paste.ubuntu.com/10322345/ is (polkit errors)
[10:43] <pitti> didrocks: do you have busybox-static installed? if not, install it (could be bug 1421117)
[10:43] <didrocks> pitti: ah thanks for the reference, doing
[10:45] <didrocks> pitti: was already installed
[10:45] <pitti> ok, need the error message then
[10:48] <didrocks> pitti: the issue is that it can't open /run/log for writing
[10:48] <didrocks> opening output file "/run/log/bootchart-<timestamp>" : No such file or directory
[10:49] <didrocks> like https://bbs.archlinux.org/viewtopic.php?id=166013
[10:50] <didrocks> I doubt -i /lib/systemd/systemd would work, but let's see…
[10:51] <didrocks> waow it does
[10:51] <pitti> didrocks: systemd-bootchart does have that option, you might need some quoting, i. e. init="... -i ..." ?
[10:51] <didrocks> pitti: yeah, this works
[10:51] <pitti> didrocks: ok, bug report SVP; I'll write an autopkgtest for bootchart
[10:51] <willcooke> seb128, do you know:  I want to have a new category in the u8 dash, where you can drop down for "All, Communicaton, Games" etc
[10:51] <didrocks> ok, something else to consider, not sure why the default isn't taken
[10:51] <didrocks> pitti: doing
[10:51] <willcooke> seb128, I want to create one called Productivity - is it easy?
[10:52] <didrocks> Laney: didn't you try to get a bootchart yesterday?
[10:53] <pitti> didrocks: how can I disable failsafe-x? it messes up qemu
[10:53] <pitti> I added an ExecStartPre=/bin/sleep 1 to /lib/systemd/system/polkitd.service which seems to help
[10:55] <pitti> didrocks: masking failsafe-x.service, I figure?
[10:55] <didrocks> pitti: that or disabling the fallback, one sec
[10:56] <didrocks> pitti: disable the target rather
[10:56] <didrocks> failsafe-graphical.target
[10:57] <didrocks> (the target is what is isolated, so remove other services)
[10:58] <didrocks> pitti: if that's not enough, maybe overriding graphical.target: /lib/systemd/system/graphical.target.d/xdiagnose.conf (this is where there is the OnFailure=failsafe-graphical.target)
[10:59] <didrocks> pitti: btw: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1423867
[11:01] <pitti> didrocks: confirmed, will look after that boot failure
[11:01] <didrocks> pitti: grrrr, I can't get to any vt, I'm having the issue now :/
[11:01] <pitti> debug-shell
[11:01] <didrocks> ah, send-key works now
[11:02] <didrocks> ok, need to disable failsafe as well
[11:11] <pitti> didrocks: masking failsafe-x WFM
[11:11] <ochosi> larsu: thanks a lot!
[11:12] <ochosi> larsu: btw, andrzejr (developer of xfce4-indicator-plugin) had some questions wrt libido and libindicator releases, because there haven't been any for a while
[11:15] <didrocks> pitti: I guess the target is failing and so isolation on the target isn't called
[11:19] <larsu> ochosi: we don't do traditional releases for those anymore, but import them to ubuntu directly
[11:20] <ochosi> larsu: yeah, i guess he noticed, the question was, are they intended for use within ubuntu only?
[11:21] <ochosi> (personally i get his request, because i think the indicators are great and shouldn't be limited to ubuntu. they work really well with other DEs like xfce too)
[11:24] <larsu> ochosi: I consider them to be ubuntu-only, because I don't like giving any stability guarantees for them. Other people think otherwise though :)
[11:25] <larsu> ochosi: in any case, tedg is the right guy to ask for releases
[11:25] <ochosi> ah ok :)
[11:25] <didrocks> pitti: ok, so during the hangs (that sometimes prevents to boot to graphical, sometimes don't), I can see: "systemd[1]: Failed to get initial list of names: Connection timed out"
[11:25]  * ochosi will annoy tedg in that case
[11:26] <larsu> :)
[11:26] <pitti> didrocks: hm, I don't see that in two failed cases
[11:26] <darkxst> ochosi, nothing is ubuntu only, but the flavours have to put in some leg work in that case
[11:26] <ochosi> larsu: are there concrete plans for unity8 yet – i mean: will indicators break for other DEs with unity8?
[11:26] <pitti> didrocks: just always the timeouts with activating the dbus services
[11:27] <didrocks> pitti: I have 16 jobs starting… and stuck at that number (which I guess is due to the dbus activation)
[11:27] <darkxst> pitti, systemd exploded now?
[11:27] <pitti> didrocks: I dropped the --no-debug from  polkitd.service
[11:27] <pitti> darkxst: yeah, it's a helluva bug :/
[11:27] <pitti> didrocks: in succeeding cases polkitd starts up and mumbles some stuff, but in the timeout cases it appears to not even start
[11:28] <pitti> didrocks: maybe the added sleep 1 helped a bit, but I get it more regularly now in VM
[11:28] <didrocks> urgh :/
[11:29] <darkxst> pitti, figured as much from the back log
[11:29] <didrocks> pitti: journactl "systemd[1]: Looping too fast. Throttling execution a little/"
[11:29] <larsu> ochosi: they work as they are with unity8 and I'm not aware of any concrete plans
[11:30] <larsu> ochosi: I wouldn't bet on the design staying the same though
[11:30] <larsu> ochosi: and I do have some non-concrete plans myself (which would totally change them), but I don't think I'll work on that
[11:31] <darkxst> larsu, but teams can share, I think Ubuntu GNOME has proven that ;)
[11:31] <larsu> darkxst: ah, I thought he meant non-ubuntu-flavors as well
[11:31] <larsu> darkxst: share what?
[11:31] <darkxst> larsu, ochosi is xubuntu?
[11:31] <ochosi> yup
[11:31] <Trevinho> tsdgeos: have you foxed your issues? Changes happened yesterday to indicators, so you need to make sure you reloaded everything properly
[11:31] <darkxst> larsu, packages,
[11:31] <tsdgeos> Trevinho: i rebotted and it worked
[11:32] <ochosi> darkxst: only the project lead, not xubuntu as a whole though ;)
[11:32] <darkxst> larsu, we have a huge overlap with -desktop
[11:32] <larsu> darkxst: I know, I thought this was about upstream, because why else would he care about releases?
[11:32] <tsdgeos> Trevinho: but when i found the issue i just had rebooted too
[11:32] <tsdgeos> Trevinho: so it's stading at 50% success/error at the moment since yesterday :D
[11:32] <Trevinho> tsdgeos: I see
[11:32] <larsu> darkxst: I know and I didn't say that was a bad thing!?
[11:32] <darkxst> larsu, maybe I came into the convo late!
[11:32] <larsu> darkxst: haha okay :)
[11:33] <ochosi> larsu: i think the idea was to get indicators playing nicely on other distros and getting them packaged
[11:33] <ochosi> larsu: without releases that's rather hard
[11:33] <larsu> ochosi: right. Talk to tedg about that. I would not recommmend it, but that's only me
[11:34] <ochosi> ok, either way, good to know
[11:34] <ochosi> thanks for the heads up
[11:34] <larsu> probably it will be fine
[11:46] <ochosi> larsu: one more thing, will the evince patch find its way to ubuntu naturally or should/can i do anything about this?
[11:49] <larsu> ochosi: will find its way naturally if you're fine with waiting until we get 3.16. Otherwise let's backport it
[11:51] <ochosi> right, would be good to have it in 15.04 for us
[11:51] <ochosi> it's a rather annoying bug in xubuntu, losing your window borders on a maximized window isn't very intuitive :)
[11:51] <ochosi> can i do anything to help backporting?
[11:52] <larsu> right, if you want to help, make an MR with the patch for our evince package
[11:52] <larsu> and assign me or Laney as reviewer
[11:52] <ochosi> ok, i'll try that
[11:52] <didrocks> pitti: bah, going for a run, can't get any useful logs and as it's not reliably reproduceable…
[11:52] <didrocks> pitti: I'm in a broken state in qemu right now, kept it like that
[11:52] <ochosi> larsu: i'm not that good at the patch/packaging stuff, but i'll do my best. to the worst you'll have to educate me and i'll learn something...
[11:52] <pitti> didrocks: ack, enjoy! continuing to bisect here
[11:52] <larsu> ochosi: a launchpad bug with one of us as assignee will work as well ;)
[11:53] <ochosi> heh, bugreport already exists
[11:53] <larsu> ochosi: ha, I don't know much either. Laney is the pro
[11:53] <ochosi> https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1422354
[11:53] <didrocks> pitti: keep me posted once I'll be of any help. I'm going to run, let's see how my knees will handle :)
[11:53] <larsu> ochosi: ah cool
[11:53] <pitti> didrocks: you're starting with a short round, I hop?
[11:53] <ochosi> larsu: upstream bug already added to watch ofc
[11:53] <Laney> pitti: are you reliably reproducing it now?
[11:54] <larsu> ochosi: cool. Do you want to try adding the patch? Otherwise I'll do it
[11:54] <didrocks> pitti: it's the 3rd time, my physiologist told me to try 8kms + some cycling
[11:54] <ochosi> larsu: i can give it a shot
[11:54] <didrocks> pitti: I'm sure I will run slowly though :/
[11:55] <larsu> ochosi: cool! let me know if you run into trouble
[11:55] <Laney> ochosi: no chance to get it via evince 3.14?
[11:55] <Laney> if not, yeah, we can totally backport it
[11:55] <pitti> Laney: no, not reliably, it's a lot of retries once I get to the broken state again
[11:55] <ochosi> Laney: it was applied in the 3.15 branch
[11:56] <Laney> indeed, sometimes fixes are put into the stable branch too
[11:56] <ochosi> oh, i wouldn't know. larsu?
[11:59] <larsu> Laney, ochosi: I hesitated to put onto stable for everyone because it _is_ a UI change
[11:59] <larsu> probably one that everyone wants, but still
[11:59] <larsu> please let's backport
[11:59] <ochosi> but it would only affect the !CSD folks, no?
[12:00] <ochosi> either way, i'm fine with whatever you guys say/prefer
[12:00] <larsu> ochosi: right, it's a ui change for those folks
[12:00] <larsu> could be more trouble than it's worth, and it's an insanely small patch for us to carry
[12:02] <ochosi> agreed
[12:08] <willcooke> Quesiton for gtk people...  Inside XMir gtk applications (well xhchat)  have MASSIVE fonts.  I wonder, perhaps it's picking up funny settings from gsd running on the device?
[12:08] <willcooke> can I over ride them some how?
[12:13] <larsu> willcooke: you can, but let's check whether that's the issue first. Do you have libgtk-3-dev installed?
[12:13] <larsu> willcooke: open the inspector with Ctrl+D and select "GtkSettings" on the left side, and check what the value of "gtk-font-name" is
[12:14] <larsu> sorry, Ctrl+Shift+D
[12:14] <willcooke> larsu, bear in mind this is on a tablet, inside Xmir - will installing that break much?
[12:14] <willcooke> let me backup my stuff quickly...
[12:14] <larsu> willcooke: oh. Shouldn't break anything, but I don't know if/how opening new windows works
[12:15] <willcooke> oki, installing
[12:16] <willcooke> larsu, ok, installed, ctrl-d doesnt do anything
[12:17] <willcooke> ctrl shift d doesnt either
[12:17] <larsu> willcooke: Ctrl+Shift+D, sorry
[12:17] <larsu> oh. Weird.
[12:17] <larsu> seb128: does opening the inspector not work on xmir?
[12:18] <willcooke> larsu, I'm seeing this in the logs...
[12:18] <willcooke> IceWM: Warning: Could not load font "DejaVu Sans".
[12:18] <willcooke> IceWM: Warning: Could not load font "sans-serif:size=11".
[12:18] <willcooke> IceWM: xft: fallback from 'DejaVu Sans,sans-serif:size=11'
[12:18] <willcooke> IceWM: Warning: Could not load font "DejaVu Sans".
[12:18] <willcooke> IceWM: Warning: Could not load font "sans-serif:size=10:bold".
[12:18] <willcooke> IceWM: xft: fallback from 'DejaVu Sans,sans-serif:size=10:bold'
[12:18] <willcooke> So I think it's trying to use ~ 11 point font
[12:18] <willcooke> but each letter is about an inch high
[12:18] <willcooke> I tried to create a .Xresources file with a lower dpi
[12:18] <willcooke> didnt help
[12:19] <larsu> shouldn't it try the ubuntu font?
[12:19] <larsu> maybe g-s-d isn't set up correctly?
[12:19]  * larsu doesn't know about the xmir setup, sorry
[12:20] <larsu> willcooke: in any case, you can override xsettings in g-s-d by settings the org.gnome.settings-daemon.plugins.xsettings key
[12:21] <larsu> gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "{'Gtk/font-name': <'ubuntu 10'> }"
[12:23] <willcooke> larsu, No such schema 'org.gnome.settings-daemon.plugins.xsettings'
[12:24] <larsu> willcooke: so g-s-d is not installed...
[12:24] <willcooke> so that's why I'm getting these massive fonts?
[12:24] <larsu> or the xsettings plugin
[12:24]  * willcooke install gsd
[12:25] <willcooke> larsu, do I need to tell it to start inside the Xmir session?
[12:27] <larsu> ya
[12:28] <willcooke> hahahaahahahah!!!!
[12:28] <willcooke> yaya
[12:28] <willcooke> thanks larsu
[12:28] <larsu> willcooke: I should probably look into our xmir setup a bit more to give better advice. Glad it works
[12:29] <willcooke> larsu, yah, we'll have to look in to this soon, but soon, not now :)
[12:31] <ochosi> larsu: wat, the ubuntu packaging docs told me to add the .pc folder and now the diff is totally screwed up :'( https://code.launchpad.net/~ochosi/evince/show_titlebar/+merge/250436
[12:31] <Laney> flexiondotorg: hi, did you have an LP bug to close with the new gtk?
[12:31] <flexiondotorg> Laney, Sure. One sec.
[12:31] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1351890
[12:32] <willcooke_phable> hello desktoppes from Xchat running on the phablet
[12:32] <popey> hello willcooke_phable
[12:32] <willcooke_phable> now with normal sized fonts
[12:32] <Laney> ty
[12:32] <flexiondotorg> Laney, So 15.04 is using the new release of GTK2 or patching an old releasE?
[12:32] <Laney> flexiondotorg: new one soon
[12:32] <willcooke> hello willcooke_phable would you like some lunch now
[12:32] <willcooke_phable> willcooke, yes, yes I would
[12:32] <flexiondotorg> Laney, Great.
[12:32] <larsu> willcooke_phable: haha
[12:32] <ochosi> willcooke_phable: hehe, your nick gave away the surprise ;)
[12:33] <willcooke> ochosi, :D
[12:33] <larsu> ochosi: I don't even know what that .pc directory does...
[12:33] <larsu> ochosi: clearly the diff is wrong ;)
[12:34] <ochosi> larsu: yeah, sorry about that. blaim http://packaging.ubuntu.com
[12:34] <ochosi> also blame
[12:34] <larsu> ochosi: never read that *cough*
[12:34] <Laney> um yeah, don't add that
[12:35] <ochosi> i would hope that the patch otherwise is ok, i even added the frickin DEP-3 header
[12:35] <Laney> ah right, we usually use lp:~ubuntu-desktop/evince/ubuntu not lp:ubuntu/evince
[12:35] <Laney> I can sort that out. :)
[12:35] <larsu> Laney: thanks
[12:35]  * larsu <-- clueless
[12:35] <ochosi> Laney: thanks a bunch
[12:35] <ochosi> <-- more clueless
[12:36] <larsu> *cluelesser?
[12:36] <Laney> there's some kind of fail going on with this workflow
[12:36] <ochosi> Laney: ok, so just that i learn something here: 1) don't add the .pc folder 2) correct MR-destination 3) ..?
[12:37] <Laney> if you bzr branch lp:~ubuntu-desktop/evince/ubuntu you get something which looks a bit different
[12:38] <ochosi> right, i guess i should've done that then, i branched lp:ubuntu/evince
[12:38] <Laney> i.e. we only store the changes in debian/ and not the full source
[12:38] <Laney> so .pc is not relevant for us
[12:40] <willcooke_phable> good bye
[12:41] <willcooke> well, it was nice of him to drop in
[12:41] <willcooke> what a great guy
[12:42] <seb128> willcooke, sorry, too much backlog, do you still need something?
[12:42] <seb128> IRC is crazy today
[12:42] <willcooke> seb128, erm....
[12:42] <willcooke> seb128, oh - maybe - I want to create a new category in the drop down from the apps scope "Productivity"
[12:42] <willcooke> seb128, I think I asked you this before, and it's non-trivial
[12:43] <willcooke> if so, care=zero
[12:45] <seb128> willcooke, oh, categories, I don't know exactly how that works, but part comes from the server since that's what provides the translations iirc
[12:46] <willcooke> seb128, kk - nw.  I wont worry about it then
[13:50] <didrocks> pitti: any lead?
[13:50] <pitti> didrocks: ça va ! comment était le cours ?
[13:50] <pitti> didrocks: bisecting individual binaries now
[13:51] <didrocks> pitti: la course était difficile, je cours lentement maintenant :p Sinon, quelques douleurs, mais globalement, ça allait
[13:51] <didrocks> pitti: do you need any help? (Not sure how many reboots you are doing to qualify the bisection :))
[13:52] <pitti> didrocks: I verified that current vivid and systemd+systemd-logind from 218 are FAIL
[13:52] <pitti> didrocks: i. e. the regression is not in systemd or systemd-logind
[13:53] <pitti> I never got a failure with those two plus journald from 218
[13:53] <pitti> so I'm currently trying to get a failure with vivid and just journald from 218
[13:53] <pitti> didrocks: and I keep leaving an sbuild -j4 on my host, to slow down things
[13:54] <didrocks> argh :/
[13:54] <cyphermox> didrocks: fwiw I didn't really get an issue that I noticed
[13:54] <didrocks> pitti: so, you would need the contrary, systemd 218 + journald alone from 219?
[13:54] <pitti> didrocks: to cross-check, yeah
[13:54] <didrocks> cyphermox: yeah, it's pretty random, seems to happen more on heavy load
[13:54] <didrocks> pitti: doing that
[13:54] <cyphermox> that would explain it, maybe
[13:54]  * didrocks downloads the binary
[13:54] <pitti> didrocks: do you now have a way to reproduce?
[13:55] <pitti> didrocks: I'm still doing the "reset /v/l/j, reinstall, swap binary, reboot a few times" approach
[13:55] <didrocks> pitti: rebooting like crazy, sometimes I have a hang which unblocked after ~30s, sometimes it will hang as we discussed
[13:55] <didrocks> I don't do the reset /v/l/j
[13:55] <pitti> didrocks: oh, and I think I still have the ExecStartPre=/bin/sleep 1 in polkitd.service
[13:55] <didrocks> that helped triggering it for you, right?
[13:55] <didrocks> (the sleep)
[13:56] <pitti> didrocks: a bit; hard to say
[13:56] <didrocks> happy to see we are all so clear about the issue :p
[13:57] <pitti> didrocks: I didn't yet try to downgrade systemd-tmpfiles, btw (that's still on my "to check" list)
[13:57] <didrocks> oh right
[13:57] <pitti> at least if we cannot confirm journald to be the culprit
[13:57] <didrocks> well, let's me downgrade everything and upgrade
[13:57] <didrocks> yeah
[14:07] <pitti> didrocks: I'm now running one VM with 219 and journald 218, and another VM with 218 and journald 219; no hangs on either so far..
[14:14] <didrocks> pitti: \o/
[14:15] <didrocks> pitti: when I was going to call bankrupcy on the journal after 30 successful boot, I just got a hang!
[14:15] <didrocks> so all systemd/udev and such on 218, but systemd-journald on 2219
[14:15] <didrocks> 219*
[14:15] <pitti> didrocks: oh!
[14:15]  * pitti feeds the hamsters harder then
[14:16] <didrocks> ahah :)
[14:16] <didrocks> took 30 boots here
[14:16] <pitti> didrocks: did you wait long enough to make sure it's really the same issue? i. e. you get into the loop of "restart services"?
[14:17] <pitti> didrocks: yay, got it too now!
[14:17] <didrocks> pitti: yeah, same states, with queued jobs
[14:17] <didrocks> nice to know at least which component is guilty :p
[14:17] <pitti> ok, so it's not the tmpfile ACL either, good!
[14:17]  * pitti records that in the bug
[14:18] <didrocks> nice that you confirmed with 218 + journald from 219
[14:20] <pitti> didrocks: hm, I had bet on logind, but I disproved this already
[14:21] <pitti> logind hanging/crashing polkit, everything else needing logind or polkit, would have made sense
[14:21] <pitti> didrocks: but journald makes it more plausible why I can trigger it with various-sized persistant journals :)
[14:22] <pitti> didrocks: do you have time for another test?
[14:22] <didrocks> pitti: sure
[14:22] <pitti> didrocks: I wonder if ForwardToSyslog=no makes a difference
[14:22] <pitti> although, hold that thought
[14:22]  * didrocks was looking at "git log v218..v219 src/journal" just in case
[14:23] <pitti> yeah, that would have been my next thingy
[14:23] <didrocks> ah
[14:23] <pitti> didrocks: so we should be able to use journalctl from upstream trunk with explicitly setting ForwardToSyslog=yes in journald.conf
[14:23] <didrocks> let me try to disable syslog forwarding then
[14:23] <didrocks> yeah
[14:23] <pitti> didrocks: wait, that might not be the cheapest next step
[14:23] <didrocks> hum?
[14:24] <pitti> didrocks: might be better to split the bisecting into two halves?
[14:24] <didrocks> not sure to follow you, you want to bisect the whole repo between the 2 tags?
[14:25] <pitti> didrocks: for src/journal
[14:25] <pitti> didrocks: well, first read all changes to see which could be plausible candidates
[14:25] <didrocks> yeah
[14:25] <pitti> didrocks: ok, let's do that then, and maybe split the candidates between us?
[14:25] <didrocks> well, if the change is in src/journal
[14:25] <didrocks> not in the share/static libs
[14:25] <didrocks> sounds good to me :)
[14:26] <pitti> ah yeah :/
[14:31] <didrocks> pitti: we did include the acl capabilities before 219, right?
[14:31] <didrocks> (as the acl support is unconditional now)
[14:35] <didrocks> well, there is the large commit on restarting the journal without loosing stream connexions, but I doubt the journal is restarting in this boot or shouldn't…
[14:35] <didrocks> (13790add4bf648fed816361794d8277a75253410)
[14:37] <pitti> didrocks: yes; just that 218 didn't have the tmpfiles.d ACL support, and /{run,var}/log/journal didn't get ACLs for group adm assigned
[14:37] <didrocks> ok
[14:38] <willcooke> Sweet5hark, when I open Writer in one DISPLAY and I try to open Calc in a different one, LO actually converts the Writer instance in to a calc instance.  Can I tell LO not to do that - to start a whole new process instead?
[14:38] <pitti> didrocks: I sent a message to the upstream ML as a heads-up
[14:39] <didrocks> good idea
[14:42] <didrocks> pitti: saw Michael's answer?
[14:42] <didrocks> ah, you are speaking on #debian-systemd :)
[15:05]  * Laney goes to lurk in there
[16:50] <pitti> didrocks: back from meeting
[16:50]  * pitti feels burned out, needs to go buy some groceries, and it's been too long a week anyway, so I guess I'll resume the systemd madness on Monday
[16:51]  * Laney hugs pitti 
[16:51] <didrocks> pitti: yeah, I doubt we'll dig deeper now
[16:51] <Laney> good investigating
[16:51] <didrocks> pitti: c'est l'heure de la glace :)
[16:51] <didrocks> et du week-end!
[16:54] <pitti> didrocks: did you try reverting/bisecting anything else? (just for keeping notes)
[16:56] <didrocks> pitti: no, I did backlog on what I planned for Ubuntu Make, started to be burnt out as well with this number of testing/reboots. So I guess we'll have to bisect the whole tree on Monday
[16:56] <pitti> ack
[17:02]  * didrocks waves good evening and good week-end to everyone :)
[17:02] <seb128> didrocks, bye
[17:02] <didrocks> see you seb128!
[18:10] <desrt> attente_: did you know that '(int) item' works on GVariant?
[18:10] <desrt> evil, but true
[18:11] <attente_> no
[18:11] <desrt> thanks for that vala bug, btw.  very well-explained.
[18:11] <attente_> oh
[18:23] <phablet_demo> willcooke, uiuouoiu
[18:25] <Laney> happy weekend!
[18:25] <Laney> hello phablet!
[18:29] <phablet_demo> cya Laney
[18:29] <qengho> Later, L.
[18:30] <qengho> kenvandine: are you on vivid on that high-dpi laptop?
[18:31] <kenvandine> qengho, yeah, vivid
[18:32] <qengho> kenvandine: there's a chromium landing in the PPA I mentioned that I would like you to try over the weekend. It's not downloadable yet, but I don't want you to disappear before I tell you.
[18:32] <qengho> kenvandine: Should be ready in the next 30 minutes.
[18:33] <kenvandine> qengho, sweet... can do!
[22:06] <Noskcaj> Laney, Should we be updating glibmm to match the glib2.0 updates?
[22:27] <andrzejr> ochosi, larsu, xfce4-indicator-plugin is using private (unreleased) API of libindicator - I have no problem with that as this plugin is only intended for xubuntu only. Especially users that install xubuntu-desktop on top of Ubuntu and want to use familiar indicators.
[22:27] <ochosi> tedg: ^
[22:29] <tedg> Which symbol is private that's being used?
[22:30]  * tedg might be missing some context here
[22:31] <andrzejr> tedg, sorry, I meant the API used by the plugin is not in a released version of libindicator. Mostly because the method of starting indicators has been changed ~2 years ago.
[22:33] <tedg> andrzejr, I'm still confused, which version is it in?
[22:33] <tedg> libindicator doesn't deal with starting indicators
[22:33] <tedg> It's just the plugin ABI really.
[22:34] <andrzejr> tedg, libindicator/indicator-ng.h is not yet released
[22:35] <tedg> andrzejr, By "released" do you mean "in a tarball" ? We're not really building tarballs anymore.
[22:37] <andrzejr> I noticed that. This is why I'm here to find out if that is simply an omission or if these libraries are intended for Ubuntu only
[22:38] <tedg> andrzejr, I wouldn't describe them as "Ubuntu only" but I'm not sure anyone else has them.
[22:38] <tedg> They're free software, anyone can download and build it.
[22:40] <andrzejr> As I mentioned, this is not a problem for xfce4-indicator-plugin (written deliberately for xubuntu). But it means I cannot depend on other libraries (like IDO) for distro-independent code (like xfce4-pulseaudio-plugin).
[22:40] <andrzejr> thank you for clarification, btw
[22:41] <tedg> andrzejr, Sure, on the other side you might just want to cut-and-paste from IDO. Realistically GTK+ isn't our focus right now, I doubt it'll change much.
[22:44] <andrzejr> tedg, that is something I was considering as a fallback. I agree that this may be a good solution.