darkxst | larsu, https://code.launchpad.net/~darkxst/gnome-contacts/titlebar | 03:29 |
---|---|---|
=== duflu_ is now known as duflu | ||
pitti | Good morning | 06:00 |
didrocks | good morning | 06:16 |
larsu | morning! | 06:55 |
didrocks | hey larsu :) | 06:56 |
seb128 | good morning desktopers | 06:57 |
seb128 | hey didrocks larsu | 06:57 |
didrocks | re seb128 | 06:58 |
pitti | bonjour didrocks, seb128, et larsu ! | 06:59 |
didrocks | hey pitti :) | 07:01 |
didrocks | channel getting active suddenly | 07:01 |
larsu | bonjour pitti! | 07:02 |
seb128 | hey pitti | 07:05 |
seb128 | wie gehts? | 07:05 |
didrocks | pitti: thinking more about the emergency tmp thing… one solution would be to use something like that: http://paste.ubuntu.com/10523961/ | 07:08 |
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:09 |
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:10 |
pitti | didrocks: well, if that happens (low-RAM systems), your new tmpfs isn't going to have more? | 07:15 |
didrocks | pitti: right, it's just that it will have this errornous mount | 07:17 |
didrocks | or I need to detect that /tmp isn't a tmpfs already | 07:18 |
didrocks | or I just Conflicts=tmp.mount | 07:18 |
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:19 |
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:22 |
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:23 |
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:24 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
pitti | didrocks: how about After=systemd-remount-fs.service ? | 07:42 |
didrocks | pitti: why would that fix tmp mounted as tmpfs? | 07:42 |
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:44 | |
didrocks | After= "enables it" | 07:45 |
didrocks | let me try with Conflicts= only | 07:45 |
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:46 |
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:47 | |
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:48 |
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:49 |
didrocks | retrying 10 boots without the After/Conflicts | 07:50 |
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:52 |
didrocks | rebooting in debug mode with those 2 markers | 07:53 |
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:55 |
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:56 |
didrocks | pitti: yeah, my job is /bin/echo foo | 07:57 |
didrocks | systemd bug it seems :/ | 07:57 |
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 | 07:58 |
pitti | didrocks: which one was that? the .service? or the tmp.mount.d/ snippet? | 08:01 |
didrocks | pitti: tmp.mount.d snippet | 08:02 |
didrocks | with the generator | 08:02 |
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:06 |
didrocks | pitti: would be more confortable posting if anyone can reproduce that, but well, posting | 08:10 |
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:11 |
didrocks | not nice for reboot testing… | 08:12 |
pitti | didrocks: reproduced with http://paste.ubuntu.com/10524411/ | 08:14 |
didrocks | pitti: ok, I'm not that crazy then | 08:16 |
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:17 |
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:18 |
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:19 |
didrocks | excalibr: yeah, but they are not on that channel, mostly the touch one | 08:20 |
didrocks | pitti: email sent, let's see | 08:21 |
Laney | hullo | 09:03 |
larsu | hi Laney! | 09:04 |
didrocks | hey Laney | 09:05 |
Laney | how's it going? | 09:06 |
pitti | hey Laney | 09:06 |
Laney | hi pitti | 09:06 |
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:07 |
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:08 |
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:09 |
larsu | pitti: haha | 09:10 |
larsu | scary | 09:10 |
pitti | Laney: "one" -> appointment? | 09:10 |
Laney | yes | 09:10 |
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:19 |
larsu | darkxst: it should look at Gtk/DialogsUseHeaders | 09:22 |
larsu | not sure why it doesn't work in this case | 09:22 |
Laney | look for use-header-bar being set, or gtk_dialog_new_with_header | 09:23 |
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 | 09:24 | |
=== greyback_ is now known as greyback | ||
flexiondotorg | Laney, will you be packaging GTK 2.24.27 for 15.04 or backporting the recent commits? | 09:28 |
Laney | I already backported those commits | 09:32 |
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:34 |
larsu | darkxst: like what? | 09:36 |
darkxst | larsu, apps hardcoding use-header to true | 09:36 |
darkxst | larsu, admittedly I haven't fixed a huge number of dialogs though | 09:37 |
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:38 |
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:39 |
darkxst | larsu, https://bug745566.bugzilla-attachments.gnome.org/attachment.cgi?id=298494 | 09:41 |
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:42 | |
darkxst | larsu, it only does the right thing for built-in dialogs atm? | 09:43 |
larsu | ya | 09:43 |
darkxst | didrocks, re ping last night, I assume you were talking about grilo-plugins-extra? that indeed should stay in universe | 09:46 |
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) | 09:47 |
=== MacSlow is now known as MacSlow|lunch | ||
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:20 | |
pitti | didrocks: urgh | 12:21 |
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 | 12:26 |
=== 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 | ||
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:15 |
larsu | seb128: turns out Radiance has totally different colors... | 14:16 |
larsu | but meh, works in both now | 14:16 |
seb128 | great | 14:16 |
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:17 |
larsu | seb128: which ones? I only see them in the session menu, and those are colored darkly for me | 14:18 |
seb128 | larsu, the messaging menu status | 14:20 |
larsu | seb128: indeed! | 14:21 |
larsu | weird, should be the same code | 14:21 |
larsu | I'll look into it | 14:21 |
larsu | but ups person was just here bringing me a laptop. So might take a bit ;) | 14:22 |
seb128 | larsu, have fun! | 14:24 |
didrocks | pitti: I'm a little bit more lost with Lennart's answer, though | 14:29 |
didrocks | on to why tmp.mount is pulled in sometimes then | 14:30 |
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:36 |
didrocks | pitti: I'm a little bit afraid about the answer on dependency | 14:37 |
flexiondotorg | Laney, Do you have a sec to give me a nudge in the right direction? | 14:38 |
desrt | Laney: i mean like, wtf? | 14:39 |
desrt | no sendmmsg on solaris? | 14:40 |
desrt | erm. sparc. | 14:40 |
* didrocks maintained some sparc machines at previous job | 14:40 | |
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:41 |
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:42 |
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:43 |
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:44 |
desrt | would be nice if the builder stuff put the uname in the log along with all of the other envvars and such | 14:46 |
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:56 |
didrocks | pitti: so, won't fix it for vivid? | 14:57 |
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:58 |
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? | 14:59 |
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:00 |
Laney | desrt: not sure, one sec | 15:54 |
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:55 |
desrt | ya... so there's the issue | 15:56 |
desrt | i guess you could hack that test out if you're on sparc? :/ | 15:56 |
desrt | presumably this is for sid... which would have a new enough kernel, for sure | 15:57 |
desrt | *shrug* this is the price of having wildly mismatched libc and kernel versions | 15:58 |
Laney | I'm asking #debian-sparc to see what's up | 16:03 |
Laney | flexiondotorg: you rang? | 16:03 |
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:04 |
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:35 |
ubot5 | Ubuntu bug 1427182 in ubuntu-mate "ubuntu-mate-settings package needs updating" [Critical,New] | 16:36 |
Laney | ok, will look when I get a chance | 16:38 |
=== dpm_ is now known as dpm | ||
attente_ | seb128: can we top-approve and merge https://code.launchpad.net/~attente/maliit/1245925/+merge/250311? | 17:24 |
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:25 |
attente_ | seb128: will do | 17:28 |
seb128 | attente_, thanks | 17:28 |
=== alan_g is now known as alan_g|EOD | ||
tmpRAOF | OK. What stupid piece of software has decided that it owns <ctrl>-<alt>-<space>? | 22:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!