[03:29] <darkxst> larsu, https://code.launchpad.net/~darkxst/gnome-contacts/titlebar
=== duflu_ is now known as duflu
[06:00] <pitti> Good morning
[06:16] <didrocks> good morning
[06:55] <larsu> morning!
[06:56] <didrocks> hey larsu :)
[06:57] <seb128> good morning desktopers
[06:57] <seb128> hey didrocks larsu
[06:58] <didrocks> re seb128
[06:59] <pitti> bonjour didrocks, seb128, et larsu !
[07:01] <didrocks> hey pitti :)
[07:01] <didrocks> channel getting active suddenly
[07:02] <larsu> bonjour pitti!
[07:05] <seb128> hey pitti
[07:05] <seb128> wie gehts?
[07:08] <didrocks> pitti: thinking more about the emergency tmp thing… one solution would be to use something like that: http://paste.ubuntu.com/10523961/
[07:09] <didrocks> pitti: that way /tmp being a tmpfs or not, if the system isn't ro and have less than 50, we do that remount + tag (but this adds another mount point if /tmp was already a tmpfs)
[07:09] <didrocks> 50M*
[07:10] <didrocks> the thing is that if /tmp is mounted as tmpfs already with less than 50M of free space, it will always have that remount on top of it (not sure if that's a valid case for us though)
[07:15] <pitti> didrocks: well, if that happens (low-RAM systems), your new tmpfs isn't going to have more?
[07:17] <didrocks> pitti: right, it's just that it will have this errornous mount
[07:18] <didrocks> or I need to detect that /tmp isn't a tmpfs already
[07:18] <didrocks> or I just Conflicts=tmp.mount
[07:19] <didrocks> can do this, anyway, we detected the remaining disk space on a tmpfs in that case, so the remount with "overflow" has no meaning
[07:22] <pitti> didrocks: btw, can we avoid the subshells and awk?
[07:22] <pitti> $ for avail in $(df -BM --output=avail /tmp/); do true; done; echo ${avail%[^0-9]}
[07:22] <pitti> 7589
[07:22] <pitti> the for loop is ugly, but I don't know how to split on \n in POSIX
[07:23] <pitti> and no cookies for df to not have a --no-headers option :)
[07:23] <didrocks> pitti: if you prefer the loop approach, sure
[07:24] <pitti> didrocks: oh, wait
[07:24] <larsu> Trevinho: morning. I'm afraid to ask, but how is the gtkframeextents work coming along?
[07:24] <pitti> $ stat -f -c %f /tmp/
[07:24] <pitti> 1942715
[07:24] <pitti> ?
[07:24] <pitti> didrocks: ^
[07:26] <didrocks> pitti: raw mode in hex ?
[07:26] <pitti> didrocks: no, free blocks in the file system
[07:26] <pitti> or, if you want the MB
[07:26] <pitti> $ echo $(($(stat -f -c '%S*%f/1000000' /tmp/)))
[07:27] <pitti> 7957
[07:27] <pitti> that's still just one stat call, the rest is pure shell
[07:27] <didrocks> pitti: yeah, sounds good that way!
[07:27] <pitti> didrocks: je suis désolé
[07:27] <didrocks> pitti: however, there is still a race in the systemd mount…
[07:27] <pitti> show me a bit of expensive shell, and I can't resist optimizing away the execs..
[07:28] <didrocks> pitti: heh, that's fine, and thanks for it :)
[07:28] <pitti> why would it be a race, with teh After=?
[07:28] <didrocks> pitti: I don't know, it mounts even if not enabled the mount point…
[07:28] <didrocks> as if it was taking tmp.mount into consideration
[07:28] <pitti> oh, the ConditionPathIsReadWrite=/tmp sounds like a race?
[07:29] <didrocks> pitti: well, it shouldn't mount /tmp as tmpfs still
[07:29] <pitti> conditions are evalated as pretty much the first thing in systemd when building the transaction, way before actually running the unit, no?
[07:29] <didrocks> ah, so this is another issue then :p
[07:29] <didrocks> pitti: but even without that, there is no reason in my scenario to have /tmp mounted in tmpfs
[07:30] <didrocks> enough disk space
[07:30] <didrocks> tmp.mount not enable
[07:30] <didrocks> and 50% of the boots, it's enabled
[07:30] <pitti> oh, and the unit will fail if there's enough space
[07:31] <pitti> didrocks: hm, I don't know why it would run then
[07:31] <pitti> debug log?
[07:31] <didrocks> pitti: can try, but remember yesterday what happened…
[07:34] <didrocks> pitti: so ConditionPathIsReadWrite=/tmp is making it mounting 50% of the time here
[07:34] <didrocks> with ExecStart=/bin/echo true
[07:34] <didrocks> so not the service mounting itself
[07:35] <pitti> didrocks: that's without having /tmp/ in fstab and tmp.mount disabled? i. e. /tmp on the root partition?
[07:35] <pitti> didrocks: then that sounds like it's racing with remount-root.service?
[07:35] <didrocks> pitti: right, no /tmp in fstabe and tmp.mount disabled
[07:35] <pitti> but I'm not sure if ConditionPathIsMountPoint=!/tmp/ would actually help
[07:36] <pitti> I figure not
[07:36] <pitti> it's the early boot transaction, pretty much anything can happen
[07:36] <pitti> and mounts aren't set up yet
[07:37] <didrocks> so we need to test that in the shell?
[07:37] <didrocks> hum
[07:37] <didrocks> I disbled it
[07:37] <didrocks> disabled*
[07:38] <didrocks> and now, it's again mounted as tmpfs
[07:38] <didrocks> wth?
[07:38] <pitti> didrocks: so what's the problem now? you want your unit to *always* run, not just sometimes; so the ConditionPathIsReadWrite=/tmp needs to go
[07:38] <pitti> and then the shell tests if there's enough space on /, and mounts a tmpfs on it if not
[07:39] <pitti> and the After=tmp.mount will make sure that you don't do it if you enable tmp.mount
[07:39] <pitti> the remaining problem will be if you mount /tmp in fstab
[07:39] <didrocks> pitti: no, the condition is not enough, if the image is ro, are we ensure we will mount /tmp as tmps?
[07:39] <pitti> ah no, that'll generate a tmp.mount too
[07:40] <pitti> didrocks: if the image is ro, it's not that unit's job to ensure that the system has a tmp
[07:40] <pitti> then we do need tmp.mount or fstab
[07:40] <pitti> or initramfs, or wherever
[07:40] <didrocks> pitti: ok, so we always consider that /tmp is rw after tmp.mount
[07:41] <didrocks> but that doesn't fix the race anyway, I still get it even without ConditionPathIsReadWrite=/tmp or the symlink test
[07:41] <didrocks> (less often though)
[07:41] <didrocks> I wonder if it's not the After= or Conflicts=
[07:42] <pitti> didrocks: how about After=systemd-remount-fs.service ?
[07:42] <didrocks> pitti: why would that fix tmp mounted as tmpfs?
[07:44] <didrocks> so, it's either the Conflicts= or After=
[07:44] <didrocks> it seems to enable tmp.mount, where it shouldn't
[07:44]  * didrocks tries with just one
[07:45] <didrocks> After= "enables it"
[07:45] <didrocks> let me try with Conflicts= only
[07:46] <pitti> didrocks: I mean, we want this to run after root is r/w, but before local-fs.target
[07:46] <pitti> didrocks: if it runs while root is still r/o, we know even less about the state of the system
[07:46] <didrocks> pitti: yeah, but that's not related to the race/bug I'm seeing, right?
[07:47] <didrocks> pitti: btw, tmp.mount should maybe has that After=systemd-remount-fs.service as well in that case
[07:47] <pitti> didrocks: so with "After=systemd-remount-fs.service tmp.mount", we know that /tmp from tmp.mount or fstab already happened, and that we can check if /tmp is a mountpoint or if the root fs is r/o
[07:47]  * didrocks is lost, seems like we are having 2 discussions…
[07:48] <pitti> didrocks: yeah, I wonder if it implicitly has After=local-fs-pre.target, i. e. mounts are only done after that (but I'm not sure)
[07:48] <didrocks> I'm trying 30 boots first to isolate the current issue, where systemd mounts /tmp as tmpfs, where it shouldn't
[07:48] <pitti> didrocks: I don't understand your race yet
[07:48] <didrocks> pitti: tmp.mount disabled, no /tmp mount in fstab
[07:48] <didrocks> if I bring a dummy service which is enabled with ExecStart=/bin/echo True
[07:48] <didrocks> if it states After=tmp.mount
[07:49] <didrocks> then, /tmp will sometimes be mounted as tmpfs
[07:49] <didrocks> and confirmed that I see the same with Conflicts=tmp.mount
[07:49] <pitti> ok, I don't understand that for sure
[07:49] <didrocks> seems that then it evaluates and enable tmp.mount
[07:49] <pitti> After= shouldn't enable tmp.mount
[07:49] <didrocks> right
[07:50] <didrocks> retrying 10 boots without the After/Conflicts
[07:52] <didrocks> pitti: yeah, so 10 boots out of 10 without /tmp being mounted as tmpfs without After/Conflicts
[07:52] <didrocks> so they are bringing/enabling tmp.mount for unknown reasons :/
[07:53] <didrocks> rebooting in debug mode with those 2 markers
[07:55] <didrocks> Mar 04 08:54:37 autopkgtest systemd[1]: Deleting job tmp.mount/stop as dependency of job systemd-timesyncd.service/stop
[07:55] <didrocks> Mar 04 08:54:37 autopkgtest systemd[1]: Deleting job emergency-tmpfs.service/start as dependency of job tmp.mount/stop
[07:55] <didrocks> Mar 04 08:54:37 autopkgtest systemd[1]: Installed new job tmp.mount/start as 50
[07:55] <didrocks> pitti: yeah, the journal clearly shows that tmp.mount is executed
[07:56] <pitti> didrocks: hm, then I have no idea why :/ I see why this would happen if you call mount on /tmp/ manually, but you said you took that out
[07:56] <didrocks>    Loaded: loaded (/lib/systemd/system/tmp.mount; disabled; vendor preset: enabled)
[07:56] <pitti> i. e. removed/disabled that Exec= line
[07:57] <didrocks> pitti: yeah, my job is /bin/echo foo
[07:57] <didrocks> systemd bug it seems :/
[07:58] <didrocks> pitti: seems like the most robust way was yesterday's extension with current systemd…
[07:58] <didrocks> but it has the issue to mark as "overflow" ro system
[08:01] <pitti> didrocks: which one was that? the .service? or the tmp.mount.d/ snippet?
[08:02] <didrocks> pitti: tmp.mount.d snippet
[08:02] <didrocks> with the generator
[08:06] <pitti> didrocks: ah, hmm; I still think generators run too early to be able to decide that
[08:06] <didrocks> pitti: but we can't have any service using After=/Conflicts=tmp.mount due to this bug… seems like we are stuck then
[08:06] <pitti> didrocks: yeah, I'd ask on the upstream ML about that, this seems ood
[08:06] <pitti> odd
[08:06] <didrocks> seems a not-fun-bug to go to the dependency hell
[08:10] <didrocks> pitti: would be more confortable posting if anyone can reproduce that, but well, posting
[08:11] <pitti> didrocks: I thought you had a simple dummy unit with After= and Exec=/bin/true?
[08:11] <didrocks> pitti: yeah, that's what I have
[08:11] <pitti> didrocks: I can try that here
[08:11] <didrocks> pitti: that would be nice :)
[08:11] <pitti> argh, I lost my adt VM, using my pid1 one
[08:11] <didrocks> hum
[08:12] <didrocks> not nice for reboot testing…
[08:14] <pitti> didrocks: reproduced with http://paste.ubuntu.com/10524411/
[08:16] <didrocks> pitti: ok, I'm not that crazy then
[08:17] <pitti> didrocks: lost because of bug 1427999 FYI :)
[08:17] <ubot5> bug 1427999 in cloud-init (Ubuntu) "cloud images don't boot with systemd" [Critical,New] https://launchpad.net/bugs/1427999
[08:17] <pitti> apparently they got switched last night
[08:18] <excalibr> Any webapp team here? Any idea why clicking 'executing this code now' in this page does nothing?
[08:18] <excalibr> https://developer.ubuntu.com/api/devel/ubuntu-13.10/javascript/web-docs/index.html
[08:18] <didrocks> pitti: argh :/ without warning you?
[08:18] <didrocks> excalibr: I would try #ubuntu-touch rather
[08:19] <pitti> didrocks: well, I don't mind the "not warning", just that they are broken now
[08:19] <pitti> didrocks: trying to juggle the touch seeds now, I'll get to that later
[08:19] <excalibr> didrocks, but that is desktop integration, no?
[08:20] <didrocks> excalibr: yeah, but they are not on that channel, mostly the touch one
[08:21] <didrocks> pitti: email sent, let's see
[09:03] <Laney> hullo
[09:04] <larsu> hi Laney!
[09:05] <didrocks> hey Laney
[09:06] <Laney> how's it going?
[09:06] <pitti> hey Laney
[09:06] <Laney> hi pitti
[09:07] <larsu> darkxst: nice! Only issue I can see is that the change addressbook dialog still uses a header bar
[09:07] <larsu> Laney: good good, thanks. Getting a new laptop today :)
[09:07] <larsu> Laney: you?
[09:07] <Laney> oh, finally!
[09:08] <pitti> larsu: ah, nice! which one do you get?
[09:08] <Laney> doing good, managed to get a dentist appointment today
[09:08] <larsu> Laney: ya, took them some time to deliver...
[09:08] <Laney> toothache be gone
[09:08] <larsu> pitti: the new x1
[09:08] <larsu> (yes I know, with spyware - didn't know this when I ordered ;) )
[09:09] <pitti> Laney: ouch, time for dentist?
[09:09] <Laney> yep
[09:09] <larsu> Laney: all the best!
[09:09] <Laney> they gave me one the same day, quite impressed
[09:09] <pitti> Laney: *shrug* I'm root on your laptop either way :)
[09:09] <pitti> err, larsu ^
[09:09] <pitti> well, it's equally true for Laney
[09:09] <Laney> ha
[09:09] <Laney> you can use your root here to give me a root canal ...
[09:10] <larsu> pitti: haha
[09:10] <larsu> scary
[09:10] <pitti> Laney: "one" -> appointment?
[09:10] <Laney> yes
[09:19] <darkxst> larsu, change address dialog doesnt seem to set headers
[09:19] <darkxst> and it should be off by default for custom dialogs? right?
[09:22] <larsu> darkxst: it should look at Gtk/DialogsUseHeaders
[09:22] <larsu> not sure why it doesn't work in this case
[09:23] <Laney> look for use-header-bar being set, or gtk_dialog_new_with_header
[09:24] <Laney> you have to fetch the value from gtksettings and pass it in yourself
[09:24]  * larsu is annoyed that apps have to do that
=== greyback_ is now known as greyback
[09:28] <flexiondotorg> Laney, will you be packaging GTK 2.24.27 for 15.04 or backporting the recent commits?
[09:32] <Laney> I already backported those commits
[09:34] <darkxst> larsu ok, can override it easy enough, but all of the few dialog bugs I have seen have been because of hardcoded use-headers type things
[09:36] <larsu> darkxst: like what?
[09:36] <darkxst> larsu, apps hardcoding use-header to true
[09:37] <darkxst> larsu, admittedly I haven't fixed a huge number of dialogs though
[09:38] <flexiondotorg> Laney, great.
[09:38] <larsu> darkxst: it shouldn't hard-code to true...
[09:38] <larsu> darkxst: but find out which desktop its running on
[09:39] <larsu> gtk dialogs do that, but apparently every app needs to do it itself
[09:39] <darkxst> larsu, I mean apps hardcoding gtk dialogs to use headers
[09:41] <darkxst> larsu, https://bug745566.bugzilla-attachments.gnome.org/attachment.cgi?id=298494
[09:42] <larsu> darkxst: ah, that's even more annoying
[09:42] <larsu> why can't GtkDialog just do the right thinG?
[09:42]  * larsu had some patches for that at some point but forgot
[09:43] <darkxst> larsu, it only does the right thing for built-in dialogs atm?
[09:43] <larsu> ya
[09:46] <darkxst> didrocks, re ping last night, I assume you were talking about grilo-plugins-extra? that indeed should stay in universe
[09:47] <didrocks> darkxst: can you please answer it to doko? he seemed to have been puzzled about it
[09:47] <didrocks> (probably on -devel, where the ping was)
=== MacSlow is now known as MacSlow|lunch
[12:20] <didrocks> pitti: the more I poke, the more it becomes interesting
[12:20] <didrocks> (see upstream ML)
[12:20]  * didrocks goes for a run
[12:21] <pitti> didrocks: urgh
[12:26] <Laney> desrt: howdy, know anything about g_socket_send_messages being broken on sparc/linux? https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=sparc&ver=2.43.91-1&stamp=1425414202
=== alan_g is now known as alan_g|lunch
=== MacSlow|lunch is now known as MacSlow
=== alan_g|lunch is now known as alan_g
[14:15] <larsu> getting there: http://i.imgur.com/z3ZdNDZ.png
[14:15] <seb128> larsu, nice!
[14:15] <larsu> seb128: pure css (except the icon part itself)
[14:16] <larsu> seb128: turns out Radiance has totally different colors...
[14:16] <larsu> but meh, works in both now
[14:16] <seb128> great
[14:17] <seb128> larsu, speaking of which, the indicators selection dots are buggy since the GTK update under it
[14:17] <seb128> they are white on grey
[14:18] <larsu> seb128: which ones? I only see them in the session menu, and those are colored darkly for me
[14:20] <seb128> larsu, the messaging menu status
[14:21] <larsu> seb128: indeed!
[14:21] <larsu> weird, should be the same code
[14:21] <larsu> I'll look into it
[14:22] <larsu> but ups person was just here bringing me a laptop. So might take a bit ;)
[14:24] <seb128> larsu, have fun!
[14:29] <didrocks> pitti: I'm a little bit more lost with Lennart's answer, though
[14:30] <didrocks> on to why tmp.mount is pulled in sometimes then
[14:36] <didrocks> pitti: from what he wrote about condition evaluation, there is no reason at all why systemd-timesyncd.service is sometimes started, sometimes not
[14:37] <didrocks> pitti: I'm a little bit afraid about the answer on dependency
[14:38] <flexiondotorg> Laney, Do you have a sec to give me a nudge in the right direction?
[14:39] <desrt> Laney: i mean like, wtf?
[14:40] <desrt> no sendmmsg on solaris?
[14:40] <desrt> erm.  sparc.
[14:40]  * didrocks maintained some sparc machines at previous job
[14:41] <desrt> was the kernel randomly missing features on them?
[14:41] <didrocks> I was more remember of a lot of common utility not behaving the same than other platforms
[14:41] <didrocks> like "killall" not taking arguments…
[14:41] <desrt> oh.  that sounds like solaris, rather :)
[14:41] <didrocks> yeah, sparc does this as well
[14:42] <desrt> linux on sparc is still linux...
[14:42] <desrt> and GNU on sparc is still GNU....
[14:42] <desrt> i can't imagine that userland is substantially different in any way...
[14:42] <desrt> Laney: any chance that the sparc builds are being done on a machine with an old kernel?
[14:43] <didrocks> desrt: solaris running on sparc processors is still solaris :p (sparc doesn't imply linux)
[14:43] <desrt> well, certainly not
[14:43] <desrt> but you're complaining about sparc when you should be complaining about solaris
[14:44] <didrocks> indeed, sorry, but that was the naming convention (mostly by architecture) at the job, hence it's stuck on my brain
[14:44] <desrt> Laney: so linux on sparc gained support for the sendmmsg syscall particularly late.... early in the 3.x series... could be that the builder still has an older kernel than that?
[14:46] <desrt> would be nice if the builder stuff put the uname in the log along with all of the other envvars and such
[14:56] <pitti> didrocks: (sorry, too busy.. but maybe he's right, and we'll just enable tmp.mount on vivid+1, and be done with it..)
[14:57] <didrocks> pitti: so, won't fix it for vivid?
[14:58] <didrocks> pitti: still doesn't explain why the systemd-timesyncd.service is sometimes started, but well, I'll get that to "backlog" for now
[14:58] <didrocks> and do the workaroud for machin-commit-id on overlayfs
[14:58] <pitti> didrocks: ah nice, did you find out something there?
[14:59] <didrocks> pitti: overlayfs stat report different major block on file and folders
[14:59] <didrocks> so it's seen as a different mount point
[14:59] <pitti> WTH?
[14:59] <didrocks> discussed with apw, he can't think of a way to know if a file is a mountpoint with overlayfs
[14:59] <didrocks> so I can't fix that centrally in systemd is_mount_point() call
[14:59] <pitti> didrocks: ok; well, not worth fixing then I guess, as it's just cosmetical?
[15:00] <didrocks> well, I can at least in machine-id-commit, add a distro patch (because I guess upstream will tell "fix overlayfs") that if you can't unmount /etc/machine-id, instead of exit(1) right away, I check if the file system is overlayfs
[15:00] <didrocks> in that case, I exit 0
[15:54] <Laney> desrt: not sure, one sec
[15:55] <desrt> Laney: assuming that this is caused by an old builder, i'm not really likely to want to fix it....
[15:55] <Laney> oh yeah it totally is
[15:55] <Laney> Kernel: Linux 2.6.32-5-sparc64-smp sparc (sparc64)
[15:56] <desrt> ya... so there's the issue
[15:56] <desrt> i guess you could hack that test out if you're on sparc? :/
[15:57] <desrt> presumably this is for sid... which would have a new enough kernel, for sure
[15:58] <desrt> *shrug* this is the price of having wildly mismatched libc and kernel versions
[16:03] <Laney> I'm asking #debian-sparc to see what's up
[16:03] <Laney> flexiondotorg: you rang?
[16:04] <flexiondotorg> Laney, Thanks for checking in. pitti steered me in thr right direction.
[16:04] <Laney> 'kay
[16:04] <flexiondotorg> Laney, I've fixed up ubuntu-mate-settings, just doin gthe final testing now.
[16:04] <flexiondotorg> Laney, nothing in /etc/skel
[16:04] <Laney> oh man, happy days
[16:04] <flexiondotorg> Laney, Everything MATE specific too.
[16:35] <flexiondotorg> Laney, I've pushed my changes. Would be interested to here your thoughts.
[16:35] <flexiondotorg> http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-settings/files
[16:35] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1427182
[16:36] <ubot5> Ubuntu bug 1427182 in ubuntu-mate "ubuntu-mate-settings package needs updating" [Critical,New]
[16:38] <Laney> ok, will look when I get a chance
=== dpm_ is now known as dpm
[17:24] <attente_> seb128: can we top-approve and merge https://code.launchpad.net/~attente/maliit/1245925/+merge/250311?
[17:25] <seb128> attente_, sure, did you try to ask to one of the ubuntu-touch/ubuntu-keyboard guys to give it a try just to get an extra confirmation?
[17:28] <attente_> seb128: will do
[17:28] <seb128> attente_, thanks
=== alan_g is now known as alan_g|EOD
[22:57] <tmpRAOF> OK. What stupid piece of software has decided that it owns <ctrl>-<alt>-<space>?