| === c74d3 is now known as c74d | ||
| biezpal | guys, we need to create additional users to Snappy Ubuntu. How we should do this in proper way? | 04:37 |
|---|---|---|
| dholbach | good morning | 07:00 |
| fgimenez | good morning dholbach and all | 07:01 |
| dholbach | hey fgimenez | 07:02 |
| === chihchun_afk is now known as chihchun | ||
| === erkules_ is now known as erkules | ||
| ogra_ | grumble ... ubuntu-fan ... grumble | 08:43 |
| JamesTait | Good morning all; happy Milk Chocolate Day! 😃 | 08:54 |
| davmor2 | ogra_: You know when you add the grumbles you sound less of a fan and more of a stalker right ;) | 09:10 |
| ogra_ | heh | 09:10 |
| === kickinz1|afk is now known as kickinz1 | ||
| ogra_ | hmpf ... i dont et it | 11:46 |
| ogra_ | *get | 11:46 |
| Chipaca | ogra_: ? | 11:47 |
| ogra_ | buildin an armhf rootstock rootfs always fails with dependency issues | 11:47 |
| ogra_ | and its the same missing deps no matter what release i use | 11:47 |
| ogra_ | amd64 vivid is up to now the only one i manaed to get to build | 11:48 |
| ogra_ | wily fails there too | 11:48 |
| ogra_ | (though not dep issues) | 11:48 |
| Chipaca | ogra_: is it bad that i don't know what rootstock is in this context? (i assume you're not building a social investment society) | 11:52 |
| ogra_ | http://paste.ubuntu.com/11953230/ i really dont know what to make out of that ... it is using the stable archive | 11:52 |
| ogra_ | oh | 11:52 |
| ogra_ | perhaps it should also use -updates | 11:52 |
| ogra_ | Chipaca, a rootfs builder tool ... project-rootstock-ng on launchpad | 11:53 |
| Chipaca | ogra_: otherwise, check with barry maybe? he's usually ontop of python weirdness :) | 11:53 |
| ogra_ | well, this is vivid ... we build regular snappy imaes from it :) | 11:53 |
| ogra_ | *images | 11:53 |
| ogra_ | rootstock uses exactly the same setup as the livefs builders so theoretically there is no reason for it to fail if the official images build | 11:55 |
| * ogra_ tries adding -updates to the sources.list | 11:57 | |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | OOOOH ! | 11:59 |
| * ogra_ slaps forehead | 11:59 | |
| ogra_ | the snappy livecd-rootfs comes from the PPA | 11:59 |
| ogra_ | so indeed i'm missing all the hacks | 12:00 |
| ogra_ | hmpf, adding -updates doesnt change a thing | 12:08 |
| longsleep | ogra_: hey - any news about getting a stable snappy 15.04 with the uboot.env changes? | 12:16 |
| ogra_ | longsleep, rsalveti wanted to release it last night, seems that didnt happen | 12:17 |
| ogra_ | not sure why | 12:17 |
| longsleep | ogra_: ok thanks - i will keep monitoring then :) | 12:17 |
| jdstrand | sergiusens: /var/lib/apparmor/clicks and /var/lib/snappy/apparmor are different. basically, /var/lib/snappy/... is where we want to go and I started to go there with seccomp. /var/lib/apparmor/... is where we want to move from and we'll do that when click-apparmor is gone | 12:29 |
| ogra_ | jdstrand, is anyone from the security team looking into the libstagefright issue on the phone (sorry for the echan) | 12:30 |
| ogra_ | sounds pretty serious even for us | 12:30 |
| Chipaca | elopio: you around? | 12:30 |
| elopio | Chipaca: o/ | 12:30 |
| elopio | how can I help you? | 12:31 |
| Chipaca | elopio: integrations test asplode nicely in wily | 12:31 |
| Chipaca | elopio: here i was all excited because they should finally work again (because networking is working \o/) | 12:31 |
| Chipaca | very disappointed; i thought i'd be able to convert "made integration tests work again on wily" into "get bottle of aged rum from elopio" | 12:32 |
| elopio | Chipaca: I'm not sure if I should be happy or sad. | 12:32 |
| elopio | Chipaca: throw the log at us. fgimenez is using wily, so he should be able to tell what's going on. | 12:32 |
| Chipaca | http://pastebin.ubuntu.com/11953399/ | 12:32 |
| elopio | I'm just running in vivid, and it works. | 12:32 |
| elopio | Chipaca: your udf failed | 12:33 |
| rsalveti | ogra_: waiting to see if we could get any update from utlemming | 12:34 |
| rsalveti | but will release it later today | 12:34 |
| utlemming | rsalveti: huh? | 12:34 |
| Chipaca | elopio: yep | 12:34 |
| elopio | Chipaca: this would increase your chances of getting aged rum: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1473333 | 12:34 |
| ubottu | Launchpad bug 1473333 in goget-ubuntu-touch (Ubuntu) "exits with zero on error" [Undecided,Confirmed] | 12:34 |
| rsalveti | utlemming: hey :-), what I asked you yesterday: | 12:35 |
| Chipaca | utlemming: it's all your fault, see? | 12:35 |
| rsalveti | <rsalveti> utlemming: we're just finishing the testing phase for our current alpha image (image 9), and that will be migrated to stable | 12:35 |
| rsalveti | <rsalveti> or latest edge (132) | 12:35 |
| jdstrand | ogra_: not to my knowledge. tyhicks, do you know? ^ | 12:35 |
| Chipaca | :-p | 12:35 |
| rsalveti | <rsalveti> utlemming: can you run your usual testing scenarios over it and see if there is any issue with the cloud targets? | 12:35 |
| utlemming | rsalveti: ah, okay | 12:35 |
| utlemming | rsalveti: sorry, I didn't see the request, doing it now | 12:35 |
| rsalveti | utlemming: no worries, thanks | 12:35 |
| Chipaca | elopio: maybe i should just rerun it :) | 12:36 |
| elopio | Chipaca: the same udf command works for me. fgimenez: ^ can you give it a try? | 12:36 |
| Chipaca | elopio: fgimenez: the re-run has gotten further | 12:37 |
| fgimenez | elopio: Chipaca yep on it, anyway that error may disappear eventually | 12:37 |
| fgimenez | Chipaca yep here it's working fine | 12:38 |
| elopio | so blame sergiusens, that's good B-) | 12:38 |
| Chipaca | \o/ then | 12:38 |
| Chipaca | but it's not being able to ssh in | 12:38 |
| fgimenez | Chipaca: that's probably because ens3 is down | 12:39 |
| Chipaca | fgimenez: that's what i fixed :) | 12:39 |
| fgimenez | Chipaca: then it must be something else :) | 12:39 |
| fgimenez | Chip | 12:40 |
| fgimenez | Chipaca: you can try to create the image, launch it with kvm and run the tests passing ip and port | 12:41 |
| elopio | Chipaca: you fixed it, but udf is deploying yesterday's rolling edge | 12:41 |
| elopio | Chipaca: go run _integration-test/main.go --ip localhost --port 8022. | 12:41 |
| elopio | and we will know if rolling edge works until later. :( | 12:42 |
| Chipaca | elopio: um | 12:42 |
| Chipaca | ah | 12:43 |
| Chipaca | elopio: i'm guessing it copies in snappy after ? | 12:43 |
| elopio | Chipaca: yes. Some discussion in here: https://trello.com/c/VUKDVa97/106-generate-an-image-with-snappy-from-a-branch | 12:44 |
| utlemming | rsalveti: I'm seeing an image with a serial of 132 | 12:45 |
| rsalveti | utlemming: right, that's the one we're going to promote to stable | 12:45 |
| rsalveti | unless we find yet another bug | 12:45 |
| elopio | Chipaca: and note that there's one failover test that regressed, so the suite will fail. | 12:46 |
| elopio | https://bugs.launchpad.net/snappy/+bug/1476129 | 12:47 |
| ubottu | Launchpad bug 1476129 in Snappy "automatic reboot fails with rc.local crash" [Undecided,New] | 12:47 |
| elopio | fgimenez: all my refactor branches are updated. What's missing I think is to give a better name to common.go like basetest.go, but I'm not sure if go test would try to run it. | 12:50 |
| fgimenez | elopio: ok i'll take a look, there are more failover tests that are not working because of the new location of the kernel files, i'll put hands on that too | 12:52 |
| elopio | fgimenez: oh, that's sad. | 12:52 |
| elopio | we are so close to be in-sync, but things keep falling appart. Thanks fgimenez. | 12:52 |
| ogra_ | rsalveti, so latest rootstock should theoretically be able to build core for vivid and wily ... but .... bug 1450980 | 12:53 |
| Chipaca | pitti: you around? | 12:53 |
| ubottu | bug 1450980 in debootstrap (Ubuntu) "Python 3.4.3 package fails to install with deboostrap on armhf" [High,Confirmed] https://launchpad.net/bugs/1450980 | 12:53 |
| * elopio goes offline now. Telegram if you need me. | 12:53 | |
| Chipaca | elopio: i *think* you meant to thanks fgimenez for keeping things in sync, but it reads like you're blaming him for things falling apart :) | 12:53 |
| rsalveti | ogra_: =\ | 12:53 |
| ogra_ | there is a workaround mentioned, trying that now | 12:54 |
| elopio | Chipaca: ok, to be clearer, I blame everybody except fgimenez ;) | 12:55 |
| fgimenez | elopio: i want my part of blame too! :) | 12:55 |
| ogra_ | oooh, that looks a lot better ! | 12:58 |
| pitti | hey Chipaca; yes, back from holidays | 12:59 |
| Chipaca | pitti: welcome back! | 13:00 |
| pitti | thanks! | 13:00 |
| Chipaca | pitti: i'm fighting with network-online.target; a service has it as a requires: and after: dependency, and it's still started before a network interface comes up | 13:00 |
| Chipaca | pitti: i'm starting to suspect either i'm misunderstanding something deeper, or something's broken in snappy wrt systemd & networking | 13:01 |
| Chipaca | (btw, dunno if you remember but udevadm failed to bring up the network after adding a hotplug file to interfaces.d; had to systemctl restart networking) | 13:02 |
| pitti | Chipaca: do you have a journalctl from the full boot? that shows the sequence of ifup-wait-all-auto.service, network-online.target, and your service | 13:02 |
| ogra_ | onions ... so tiring ... | 13:02 |
| * ogra_ yawns | 13:02 | |
| pitti | ogra_: ? | 13:02 |
| Chipaca | pitti: how do i get that? | 13:02 |
| ogra_ | pitti, rootstock uses three chroots wrapped into each other to fake a real livefs builder ... ultra boring to watch it :) | 13:03 |
| pitti | Chipaca: "sudo journalctl > /tmp/journal.txt", and scp/pastebin that | 13:03 |
| ogra_ | onion model :) | 13:03 |
| pitti | or just "sudo journalctl | pastebin -" if you have something like that installed | 13:03 |
| Chipaca | pitti: http://paste.ubuntu.com/11953525/ | 13:06 |
| utlemming | rsalveti: things look good for all the clouds | 13:07 |
| rsalveti | utlemming: great | 13:07 |
| pitti | Chipaca: so ifup-wait-all-auto.service is done at line 676, network-online.target is done at 735 | 13:07 |
| pitti | Chipaca: what's your service? | 13:07 |
| ogra_ | can clouds roll back ? | 13:07 |
| Chipaca | pitti: webdm | 13:07 |
| Chipaca | pitti: how is network-online done, if the network is not online? | 13:08 |
| pitti | Chipaca: erk, cloud-init runs afterwards, and calls ifupdown stuff | 13:08 |
| ogra_ | yeah, we should realyl get rid of it | 13:08 |
| ogra_ | the three to fix things it does for use all have equivalents in the distro we could use instead | 13:09 |
| pitti | Chipaca: may it be that there isn't actually an /etc/network/interfaces at boot, or cloud-init creates that? | 13:09 |
| ogra_ | s/fix/five/ | 13:09 |
| Chipaca | pitti: just to be clear, there is no configured network; it should not start at all :) | 13:09 |
| pitti | in general, I really recommend not running cloud-init on every boot, unless you have a very good reason to | 13:09 |
| pitti | Chipaca: aah | 13:09 |
| pitti | Chipaca: well, our ifup-wait-all-auto.service only waits until all configured interfaces are up | 13:09 |
| pitti | and as there are none, it succeeds immediately then | 13:10 |
| Chipaca | oh | 13:10 |
| Chipaca | daaaaamn | 13:10 |
| Chipaca | ok, let's see if i tell it there's a fake one | 13:10 |
| pitti | so you need some other service that hooks into network-online.target and waits until you configure your network | 13:10 |
| Chipaca | that might be a good option still | 13:10 |
| pitti | we can't make the default distro ifup-wait-all-auto.service not fire at all in this case | 13:11 |
| Chipaca | understood | 13:11 |
| pitti | as you can also use NetworkManager, connman, networkd, or something else | 13:11 |
| Chipaca | pitti: the "no network configured" thing is me trying to fake bug 1466672 | 13:11 |
| ubottu | bug 1466672 in Snappy trunk "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672 | 13:11 |
| pitti | Chipaca:if cloud-init brings up the network, then perhaps it could order itself before network-online.target? | 13:12 |
| pitti | Chipaca: also: | 13:12 |
| pitti | dhclient[895]: can't create /var/lib/dhcp/dhclient.leases: Permission denied | 13:12 |
| Chipaca | pitti: that was me running dhclient by hand | 13:12 |
| ogra_ | wow | 13:12 |
| pitti | ah, ok | 13:12 |
| Chipaca | without sudo | 13:12 |
| Chipaca | :) | 13:12 |
| pitti | ok, I ignore this then :) | 13:12 |
| Chipaca | ogra_: de-panic :) | 13:12 |
| ogra_ | not panicing :) | 13:13 |
| * ogra_ is just bored ... watching rootstock ... waiting | 13:13 | |
| pitti | Chipaca: it looks like cloud-init also calls ifup -a | 13:13 |
| Chipaca | pitti: thank you; i have plenty of things to poke for now then :) i'll pester you again if i run out again | 13:13 |
| pitti | with some errors, but did that actually work? | 13:13 |
| pitti | i. e. after it's done, do you have network? | 13:13 |
| Chipaca | pitti: i have no idea :) | 13:13 |
| pitti | Chipaca: well, wait until cloud-init is done, and check "ip a" and "ip route"? | 13:14 |
| Chipaca | pitti: sorry, to be clear, in this case no it did not do anything | 13:14 |
| pitti | Chipaca: and of course if it wrote something sensible into /etc/network/interfaces | 13:14 |
| Chipaca | pitti: because i manually disabled networking by moving a file away from interfaces.d | 13:14 |
| Chipaca | pitti: but i think your general question is whether that is the thing that actually brings up the network | 13:14 |
| Chipaca | pitti: i will know shortly :) | 13:14 |
| pitti | Chipaca: ok, so it's not cloud-init then; I guess you have something else that writes /e/n/i then? | 13:15 |
| pitti | or is supposed to | 13:15 |
| Chipaca | pitti: snappy firstboot writes a file to interfaces.d | 13:15 |
| pitti | Chipaca: that finishes on line 742, so indeed after network-online.target | 13:16 |
| pitti | Chipaca: so if you order that Before=network.target, that might help | 13:16 |
| pitti | Chipaca: i. e. it should write /e/n/i.d/ early, and then the ifup-wait-all-auto.service magic should kick in | 13:17 |
| ogra_ | update-initramfs: Generating /boot/initrd.img-3.19.0-25-generic | 13:17 |
| ogra_ | /bin/df: Warning: cannot read table of mounted file systems: No such file or directory | 13:17 |
| ogra_ | Warning: root device does not exist | 13:17 |
| ogra_ | Unable to abort; system will probably be broken! | 13:17 |
| ogra_ | GEEZ !" | 13:17 |
| * pitti tosses a /proc mount to ogra | 13:17 | |
| ogra_ | could we make update-initramfs warnings a little less scary | 13:17 |
| ogra_ | pitti, thats expected, it is run by live-build in that context | 13:17 |
| Chipaca | pitti: i tried ordering firstboot before network-pre, but it didn't work | 13:18 |
| ogra_ | but update-initramfs is full of such warnings about trivial bits that sound like the end of the world | 13:18 |
| Chipaca | pitti: however you weren't here to pester :) so maybe i should retest that later | 13:18 |
| Chipaca | pitti: this is with the same config as just now, but with a (fake) entry in interfaces.d: http://paste.ubuntu.com/11953575/ | 13:21 |
| Chipaca | pitti: interesting things are, for a start, a "sh segmentation fault" | 13:22 |
| Chipaca | and that ifup-wait-all-auto failed, but network-online succeeded | 13:22 |
| pitti | Chipaca: right, that times out after 2 mins; I did that to do the same as what we did under upstart, i. e. block the boot for at most 2 mins on ifup | 13:22 |
| pitti | ifquery[535]: segfault at 1 ip 0000000000403187 sp 00007ffd59263e90 error 4 in ifup[400000+d000] | 13:23 |
| pitti | go, ifupdown! | 13:23 |
| ogra_ | lol | 13:23 |
| ogra_ | that might explain the 30sec delay during boot :) | 13:24 |
| Chipaca | pitti: to be fair, i did just tell it to try to bring up ens42 | 13:24 |
| ogra_ | pitti, seems to not be 2min in the new world | 13:24 |
| pitti | 13:16:29 localhost.localdomain systemd[1]: Starting Wait for all "auto" /etc/network/interfaces to be up for network-online.target... | 13:25 |
| pitti | 13:18:29 localhost.localdomain systemd[1]: Failed to start Wait for all "auto" /etc/network/interfaces to be up for network-online.target. | 13:25 |
| pitti | looks like 2 mins to me :) | 13:25 |
| ogra_ | well, my BBB sits for 30-40sec | 13:25 |
| Chipaca | ogra_: this is so big a mess, i suggest we take a look at some point | 13:26 |
| ogra_ | +1 | 13:26 |
| Chipaca | not right now tho :) | 13:26 |
| ogra_ | haha | 13:26 |
| ogra_ | ogra@anubis:~/Devel/branches/project-rootstock-ng$ ls -l out-20150728 | 13:26 |
| ogra_ | insgesamt 218368 | 13:26 |
| ogra_ | -rw-r--r-- 1 root root 188192 Jul 28 15:26 build-20150728-armhf.log | 13:26 |
| ogra_ | -rw-r--r-- 1 root root 163712102 Jul 28 15:26 ubuntu-core.device.tar.gz | 13:26 |
| ogra_ | -rw-r--r-- 1 root root 8217 Jul 28 15:26 ubuntu-core.manifest | 13:26 |
| ogra_ | -rw-r--r-- 1 root root 59685713 Jul 28 15:26 ubuntu-core.rootfs-armhf.tar.gz | 13:26 |
| ogra_ | HOORAY !!!! | 13:27 |
| * ogra_ dances | 13:27 | |
| Chipaca | pitti: so, um, what do i do if i want to start a service after the network is up? so it works in the "network device is there but cable not plugged in" case | 13:27 |
| * pitti hugs ogra | 13:27 | |
| * ogra_ hugs pitti | 13:27 | |
| ogra_ | so now on to a wily build ... if that works too i'll declare rootstock ready for usage :) | 13:28 |
| pitti | Chipaca: can you please clarify? if there's no cable, you're technically never online | 13:28 |
| Chipaca | pitti: in that case, the service shouldn't start. It should start after a cable is plugged in (stopping if unplugged would be a bonus) | 13:28 |
| pitti | Chipaca: right now we delay network-online.target for up to 2 mins on /e/n/i coming up (mimicking what we did in upstart); apparently that was the right thing for desktop/server, but maybe not for snappy | 13:29 |
| pitti | Chipaca: so I guess we need a different "implementation" of n-o for that, i. e. not ifup-wait-all-auto.service | 13:29 |
| Chipaca | pitti: i'm not so sure; i'd like to be able to getty in even if the network is disconnected, for example | 13:30 |
| pitti | for a start, an infinite timeout | 13:30 |
| pitti | Chipaca: yes, getty doesn't need n-o, so that's always possible; ideally very few services are requires/after n-o | 13:30 |
| pitti | n-o.target is really mostly a hack for legacy software which doesn't know how to listen to networking changes itself | 13:30 |
| Chipaca | ah, ok | 13:30 |
| Chipaca | hey, i could just say "bug in webdm" and see what rsalveti says :) | 13:31 |
| pitti | but we can certainly write an implementation that makes n-o go up an down while some ifupdown interface is up | 13:31 |
| rsalveti | Chipaca: I'd probably say just fix webdm then :P | 13:31 |
| Chipaca | rsalveti: wfm, but i can see many other, lesser, app developers blaming snappy and not their code :) | 13:32 |
| rsalveti | sorry, need to read the entire backlog for context | 13:32 |
| Chipaca | rsalveti: bottom line is: my sneaky plan of making it work by hanging off of network-online.target will not work unless we rewrite stuff (and depart from what works for the rest of ubuntu) | 13:33 |
| * ogra_ thinks we should just go back to upstart :P | 13:34 | |
| Chipaca | or forwards to systemd-networkd! | 13:34 |
| kgunn | Jul 28 13:34:08 localhost kernel: [ 228.622474] audit: type=1400 audit(1438090448.373:13): apparmor="STATUS" operation="profile_load" profile="unconfined" name="mir_system-compositor_snap1.1" pid=1068 comm="apparmor_parser" | 13:35 |
| kgunn | jdstrand: so got to the point of final testing.... | 13:35 |
| pitti | Chipaca: yeah, for use cases like that it'd certainly be more practical to "eternally" delay n-o; we can't do that on desktop/server where networks can be brought up by other means, but if ifupdown/snappy-firstboot is the only thing that configures it we can be stricter | 13:36 |
| kgunn | and just happened to lock at the syslog, i don't have any "unconfined" in my profiles so why does it say that ^ | 13:36 |
| pitti | ogra_: FWIW, upstart has exactly the same behaviour :) | 13:36 |
| kgunn | jdstrand: could it be that at one point, an unconfined template was used ? e.g. it's not specified by keyword "unconfined" | 13:36 |
| kgunn | but the structure ? | 13:37 |
| ogra_ | pitti, yeah, but i know from the top of my head how to work around it in upstart :P | 13:37 |
| Chipaca | so, another thing i could do, is add a wait to the service itself | 13:37 |
| ogra_ | systemd isnt injected enouh in my cortical system yet :) | 13:37 |
| ogra_ | Chipaca, sleep 30 | 13:38 |
| ogra_ | :P | 13:38 |
| Chipaca | ExecStartPre=wait4tehnetworz | 13:38 |
| Chipaca | pitti: would that work? | 13:38 |
| pitti | ogra_: don't let it -- it's not designed for human brains :) | 13:39 |
| pitti | Chipaca: sure; although, that's conceptually a bit broken | 13:39 |
| Chipaca | pitti: tell me more | 13:39 |
| ogra_ | pitti, but it fits into lennarts ! | 13:39 |
| pitti | Chipaca: I'd suggest, if you have a thing like this, rather stick it in ifup-wait-all-auto.service | 13:39 |
| pitti | ogra_: obviously :) | 13:40 |
| pitti | Chipaca: well, you can eternally wait in ExecStartPre= if you also disable the unit timeout | 13:40 |
| Chipaca | ah. forgot about that pesky timeout thing :) | 13:40 |
| pitti | Chipaca: but it's still not very elegant; for such long (potentially indefinite) waits it's better to put that waiting logic into a separate unit (ifup-wait-all-auto.service *cough*), and order yourself after it | 13:40 |
| pitti | Chipaca: well, TimeoutStartSec=0 :) (but then real hangs won't ever be detected) | 13:41 |
| Chipaca | pitti: i'm reticent to modifying ifup-wait-all-auto.service though | 13:41 |
| pitti | Chipaca: it could also be a new one, like ifupdown-wait-online.service | 13:41 |
| pitti | Chipaca: there's no harm in making network-online.target wait for both | 13:41 |
| pitti | Chipaca: on a desktop it e. g. waits for ifup-wait-all-auto.service and NetworkManager-wait-online.service | 13:42 |
| Chipaca | pitti: and how is that difference sorted? | 13:42 |
| pitti | Chipaca: so, for experimentation: fine to put it into ExecStartPre= | 13:42 |
| pitti | Chipaca: (and disable the timeout) | 13:42 |
| pitti | that might be simplest for iterating on the logic of wait4tehnetworz | 13:42 |
| pitti | Chipaca: but once you do have a wait4tehnetworz, let's rather put that into a new ifupdown-wait-online.service which is Before=network-online.target | 13:43 |
| pitti | Chipaca: difference? | 13:43 |
| Chipaca | pitti: wait4tehnetworz is just “while [ "$(GET "http://start.ubuntu.com/connectivity-check.html" | md5sum | cut -d\ -f1)" != "4589f42e1546aa47ca181e5d949d310b" ]; do sleep 1; done”, for example | 13:46 |
| Chipaca | (possibly not *actually* in sh) :) | 13:46 |
| jdstrand | kgunn: that is not a denial, that is a profile load. That log entry is completely normal. it is saying an unconfined process (ie, apparmor_parser, snappy, whatever) loaded the profile | 13:46 |
| Chipaca | pitti: difference == how to ship one config for desktop and a different one for server (and now a different one for snappy) | 13:46 |
| Chipaca | i don't know how that part of the system is glued up | 13:46 |
| pitti | Chipaca: ah, just ship it in the snappy package, together with a /lib/systemd/system/network-online.target.wants/ symlink | 13:47 |
| pitti | Chipaca: I don't think you actually need to disable ifup-wait-all-auto.service -- your's should be stricter in all cases | 13:48 |
| Chipaca | gotcha | 13:48 |
| pitti | Chipaca: i. e. I don't see a case where ifup-wait-all-auto.service would still wait while your's would alreaydy succeed | 13:48 |
| Chipaca | now i understand what the symlinks are for :-D | 13:49 |
| pitti | Chipaca: shipping the symlink is the same as adding an [Install] section and calling systemctl enable (teh latter just creates that symlink) | 13:49 |
| * pitti needs to run to the grocery store, back in 30 | 13:49 | |
| kgunn | jdstrand: i realize that's not a denial, my point is...i'm going thru the process of making sure the mir snap and client are confined | 13:56 |
| kgunn | and wondering, if i've made it all confined why is it saying unconfined....so you say the process that started it is | 13:57 |
| kgunn | which i guess would be the launching script that's part of the snap ? | 13:57 |
| beuno | kgunn, I think he's saying that by design, unconfined processes start apps and services | 13:59 |
| beuno | so it's an ignorable log entry | 14:00 |
| kgunn | beuno: that was my other thot, thanks for confirmation | 14:00 |
| jdstrand | kgunn: what is saying unconfined exactly? the log entry you pointed to doesn't say anything about the mir process or the client process | 14:01 |
| jdstrand | kgunn: it is only saying that the profile was loaded by an unconfined process (ie, when you ran apparmor_parser, or when you installed the snap) | 14:01 |
| jdstrand | kgunn: like beuno said, you can ignore it | 14:02 |
| kgunn | jdstrand: got it, so pid 1068 was the unconfined thing | 14:02 |
| jdstrand | kgunn: if you want to know if the mir and client processes are confined, you can use 'sudo aa-status' or 'ps Z' | 14:02 |
| kgunn | ta | 14:03 |
| jdstrand | kgunn: 1068 was ultimately apparmor_parser, yes | 14:03 |
| kgunn | jdstrand: thanks, i think i'm actually done with mods to aa and seccomp to get the mir svr and client app to run confined | 14:05 |
| kgunn | altho i'm sure you or designate will need to take a look | 14:06 |
| kgunn | and tell me to "improve" potentially :) | 14:06 |
| jdstrand | kgunn: great! yeah, whenever you upload ping me and I'll look at it. at this point I imagine we are getting to the point of just filing bugs | 14:07 |
| kgunn | cool | 14:07 |
| kgunn | just doing some clean testing to make sure i'm all good | 14:08 |
| Chipaca | pitti: for the record, a delayed network-online results in no gettys for 2m | 14:38 |
| pitti | Chipaca: hmm, that's bad; so we block user-sessions on that? /me checks | 14:39 |
| pitti | ah, we had bug 1425376 earlier due to that | 14:40 |
| ubottu | bug 1425376 in systemd (Ubuntu) "Ubuntu Core provides no console login prompt if network is unavailable" [Undecided,Fix released] https://launchpad.net/bugs/1425376 | 14:40 |
| pitti | ah, so we block network.target, which is really bad | 14:40 |
| Chipaca | pitti: it does give me a nice red ascii throbber to look at on console though :) | 14:41 |
| Chipaca | pitti: this is bad news for my wait4networz service, which ... um ... waits for the networz | 14:44 |
| * Chipaca should trademark that | 14:45 | |
| Chipaca | pitti: but that bug says it's fixed released; am i missing something? | 14:49 |
| pitti | Chipaca: yes, it is, I just remembered that we had such a case before | 14:49 |
| pitti | so we need to find out why network.target is blocked on getting online | 14:49 |
| pitti | apparently something orders itself after network-online.target but before network.target, and we need to LART it | 14:50 |
| davmor2 | Chipaca: yeap but no wonder your network is down. I mean there are always casualties in worz | 14:50 |
| * Chipaca deploys networz on davmor2 | 14:50 | |
| pitti | ah, could be /etc/init.d/networking | 14:51 |
| * davmor2 plays c6 and sinks Chipaca's battle ship | 14:52 | |
| * Chipaca sneaks a spy into davmor2's capital and sets off a nuke | 14:52 | |
| Chipaca | pitti: fwiw ifup-wait-all-auto bailed as expected | 14:53 |
| davmor2 | Chipaca: Thanks Wolverhampton really need a facelift | 14:53 |
| Chipaca | who says wars don't settle arguments | 14:54 |
| ogra_ | Chipaca, that is because you dont use ifup-wait-all-auto-do-no-bail | 14:54 |
| Chipaca | ogra_: --pretty-please | 14:55 |
| davmor2 | No no worz alway settle arguments the issue is in war no one remembers the argument that triggered it so they keep resetting the argument ;) | 14:55 |
| ogra_ | :) | 14:55 |
| pitti | Chipaca: btw, in case it's any easier, you can run stuff from /etc/network/if-up.d/, which are called when (any) interface gets connected | 14:56 |
| pitti | Chipaca: if you have a journalctl from that boot with the stalled getty, I'd be interested | 14:57 |
| pitti | Chipaca: (also, stalled -- talking to other folks) | 14:57 |
| Chipaca | pitti: how can i get journalctl from a stalled boot? | 14:57 |
| Chipaca | given no network & no getty | 14:57 |
| pitti | Chipaca: you could boot with systemd.debug-shell, and ctrl+alt+f9 | 14:58 |
| Chipaca | that was it | 14:58 |
| Chipaca | yep | 14:58 |
| pitti | Chipaca: or disable your new unit, and just let the standard stuff time out after 2 mins | 14:58 |
| Chipaca | pitti: i don't know how do disable my new unit :) | 14:58 |
| pitti | Chipaca: or just plug in ethernet after 2 mins :-) I'm merely interested what's (not) starting until the network comes up | 14:58 |
| pitti | Chipaca: remove the symlink | 14:58 |
| Chipaca | pitti: with no network and no getty | 14:59 |
| pitti | ah | 14:59 |
| Chipaca | :) | 14:59 |
| pitti | well, debug shell it is then, I figure :) | 14:59 |
| pitti | Chipaca: but it does sound like bug 1425376 is back? | 14:59 |
| ubottu | bug 1425376 in systemd (Ubuntu) "Ubuntu Core provides no console login prompt if network is unavailable" [Undecided,Fix released] https://launchpad.net/bugs/1425376 | 14:59 |
| Chipaca | pitti: if it ever truly went away, yes | 15:00 |
| Chipaca | i've seen this spinner before, didn't realise it was a bug | 15:00 |
| kgunn | jdstrand: so here's my "confined" attempt | 15:02 |
| Chipaca | pitti: http://paste.ubuntu.com/11954006/ | 15:02 |
| kgunn | https://code.launchpad.net/~kgunn72/mir/snappy-packaging-with-secprofile/+merge/266111 | 15:02 |
| kgunn | jdstrand: so dunno if that's for you or tyler feel free to change | 15:02 |
| kgunn | also do you want snaps built ? | 15:02 |
| jdstrand | kgunn: I don't need snaps built | 15:03 |
| Chipaca | why are we running cloud init on *every* boot? isn't it a firstboot thing? | 15:03 |
| pitti | Chipaca: oh, cloud-init | 15:03 |
| Chipaca | sergiusens: do you know^? | 15:03 |
| pitti | Chipaca: right, cloud-init is indeed blocking gettys, and it takes effing long | 15:03 |
| kgunn | jdstrand: ok, to test you can follow the "snappy gui anyone" blog | 15:03 |
| Chipaca | pitti: cloud init depends on network-online afaik | 15:03 |
| kgunn | the one step not to forget is the "export LC_ALL=C.UTF-8" ;) | 15:04 |
| jdstrand | kgunn: ok. I probably won't get to this immediately, but will soon | 15:04 |
| pitti | Chipaca: right, and blocks user sessions | 15:04 |
| jdstrand | tyhicks: there is already a card for this. I'll assign it to me since I looked at the others | 15:04 |
| Chipaca | yes, requires: network-online | 15:04 |
| kgunn | jdstrand: no worries, i just didn't want to drop our responsibility of following up :) | 15:04 |
| pitti | Chipaca: so if there's no network, cloud-init will block | 15:04 |
| Chipaca | lurvely | 15:04 |
| tyhicks | ogra_: are you saying that we use stagefright on our phones? | 15:04 |
| jdstrand | tyhicks: see #phablet | 15:05 |
| ogra_ | tyhicks, seems we dont use it but there are ~30 .so files in the android container under /system/lib | 15:05 |
| pitti | Chipaca: OOI, what do you use cloud-init for? | 15:06 |
| ogra_ | accordin to jhodapp they are not used by anything though | 15:06 |
| pitti | Chipaca: with the r/o file system it can't actually do much, can it? | 15:06 |
| tyhicks | ogra_: thanks | 15:06 |
| Chipaca | pitti: I don't know what we use it for, exactly :-) | 15:06 |
| Chipaca | pitti: i'm hoping sergiusens knows | 15:06 |
| sergiusens | Chipaca: cloud-init runs on every boot | 15:08 |
| ogra_ | yeah :/ | 15:08 |
| sergiusens | Chipaca: pitti that is the way of cloud-init, I was told it should be this way; maybe smoser or utlemming can expand | 15:08 |
| tyhicks | jdstrand: ack - thanks for taking the review | 15:08 |
| sergiusens | cloud-init does not run through the whole thing on every boot though | 15:08 |
| sergiusens | it has run-once's | 15:08 |
| pitti | right, but it blocks the boot on network-online.target, that's the main problem | 15:09 |
| pitti | i. e. if you aren't online, it stalls the boot | 15:09 |
| sergiusens | pitti: Chipaca wrt what we use it for, it's used for the cloud and btw https://trello.com/c/W5WiZQM7/117-core-config-for-cloud-init | 15:10 |
| Chipaca | sergiusens: any ideas as to where to put http://pastebin.ubuntu.com/11954094/ so we can ship it in the snappy package easily? | 15:26 |
| kgunn | Chipaca: hey there, i've recently tried to confine the mir snap, i wanted to grab olli's qml app and run on top...see if i get any sec issues compared to my qt clock ref | 15:35 |
| kgunn | where would i find that snap ? | 15:35 |
| Chipaca | kgunn: i think ted has a snap built with the qml snapcraft plugin | 15:36 |
| Chipaca | kgunn: otherwise chinstrap.canonical.com/~ories/public_html/digital_sign_deb2snap_tree.tar.bz2 is ollie's (old) thing | 15:37 |
| Chipaca | kgunn: but you probably meant the qml snapcraft route | 15:37 |
| kgunn | Chipaca: yeah, preferably latest/greatest | 15:37 |
| Chipaca | kgunn: um, s.public_html/.. | 15:37 |
| Chipaca | ted might not be here though | 15:38 |
| Chipaca | 1 sec | 15:38 |
| Chipaca | kgunn: this is snapcraft with the qml plugin (not merged yet): https://code.launchpad.net/~ted/snapcraft/qml | 15:38 |
| Chipaca | kgunn: this is a snapcract project that uses it: https://code.launchpad.net/~ted/+junk/photoviewer | 15:39 |
| kgunn | ta | 15:39 |
| Chipaca | kgunn: um. there's also the snapcraft ppa | 15:42 |
| Chipaca | kgunn: because without a patched libxkbcommon some things will fail | 15:42 |
| kgunn | ah-ha | 15:42 |
| Chipaca | kgunn: if you're in wily, you already have the patch | 15:43 |
| Chipaca | kgunn: which we successfully upstreamed, btw :) https://github.com/xkbcommon/libxkbcommon/pull/25 | 15:44 |
| Chipaca | where's golang-uboot-go-dev supposed to be at? | 15:46 |
| Chipaca | sergiusens: ogra_: any idea? ^ | 15:47 |
| ogra_ | never heard of it | 15:47 |
| Chipaca | ogra_: it's mvo's uboot-go, packaged | 15:47 |
| Chipaca | it's a build dependency | 15:47 |
| ogra_ | ah | 15:47 |
| Chipaca | but it doesn't exist | 15:47 |
| ogra_ | well, he didnt want to include it anyway | 15:47 |
| ogra_ | the binary is like 2MB or so | 15:48 |
| ogra_ | so dont bother for now | 15:48 |
| ogra_ | he can handle it when coming back | 15:48 |
| Chipaca | ogra_: but i can't dpkg-buildpackage without it :-. | 15:48 |
| ogra_ | hmm | 15:48 |
| ogra_ | why would he include uboot-go after telling me it is to big for inclusion | 15:49 |
| Chipaca | ogra_: i'm not sure what binary you mean, btw | 15:49 |
| ogra_ | the uboot-go binary | 15:50 |
| Chipaca | ogra_: we need it because bootloader_uboot uses uboot-go/uenv | 15:50 |
| ogra_ | no, it doesnt | 15:50 |
| Chipaca | yes it does :) | 15:50 |
| ogra_ | it uses fw_setenv/fw_printenv | 15:50 |
| ogra_ | mvo explicitly kept uboot-go out | 15:50 |
| ogra_ | at least he told me so | 15:50 |
| Chipaca | well ... it's there on trunk | 15:51 |
| ogra_ | hmm | 15:51 |
| * Chipaca does a bzr pull just in case | 15:51 | |
| ogra_ | i only ever worked with the fw_* tools | 15:52 |
| Chipaca | there's no fw_ in snappy | 15:52 |
| ogra_ | its seeded | 15:52 |
| ogra_ | uboot-tools or some such | 15:52 |
| Chipaca | ogra_: this uboot-go is the thing that mvo wrote that parses uenv.txt | 15:52 |
| Chipaca | ogra_: and writes it out without causing reallocations | 15:53 |
| ogra_ | ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ dpkg -S $(which fw_printenv) | 15:53 |
| ogra_ | u-boot-tools: /usr/bin/fw_printenv | 15:53 |
| Chipaca | ogra_: sure, but nowhere in snappy do we call out to fw_ | 15:53 |
| ogra_ | uboot-go is plain go to eventually replace the fw_ tools | 15:53 |
| ogra_ | but today we definitely use fw_* | 15:53 |
| Chipaca | no we don't -- not in trunk | 15:53 |
| ogra_ | well, thats all i know | 15:54 |
| Chipaca | not from snappy | 15:54 |
| Chipaca | :-( | 15:54 |
| ogra_ | http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1183 | 15:54 |
| ogra_ | thats the only code i know ... beyond that mvo threw some revisions of a uboot-go binarry over the fence to me to test it for him ... but with the comment that this wont be used yet because it is to big | 15:55 |
| ogra_ | (and afaik uboot-go doesnt use the config from that above merge at all) | 15:56 |
| ogra_ | probably longsleep remembers more | 15:57 |
| sergiusens | Chipaca: ogra_ https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=uboot&field.status_filter=published&field.series_filter= | 15:58 |
| ogra_ | ah, look | 15:58 |
| sergiusens | ogra_: as a separate binary maybe, but it is used within snappy itself | 15:58 |
| ogra_ | well, he told me it wouldnt be used | 15:58 |
| sergiusens | ogra_: in summary, mvo was lazy to dput to the archive or maybe it's stuck in new | 15:59 |
| ogra_ | (i actually thought he exec()s fw_*) | 15:59 |
| sergiusens | ogra_: nope, he uses the lib, which is fine, doesn't make for a bigger binary | 15:59 |
| ogra_ | yeah | 15:59 |
| sergiusens | ogra_: btw, what is your g+ exit strategy? | 15:59 |
| ogra_ | i have none yet | 16:00 |
| ogra_ | lets see how it changes | 16:00 |
| * ogra_ will react on the go ... they dont publish actual plans, do they ? | 16:00 | |
| ogra_ | (apart from ... "we'll split everything out") | 16:00 |
| longsleep | ogra_: what would i have to remember? | 16:03 |
| longsleep | ogra_: reading backlog now | 16:03 |
| Chipaca | and now tests under dpkg-buildpackage fail in very weird ways | 16:03 |
| Chipaca | siiigh | 16:03 |
| ogra_ | longsleep, seems all solved ... (what was up with uboot-go) | 16:03 |
| longsleep | ogra_: all right | 16:03 |
| longsleep | ogra_: so whats the result of your discussion, fw_* is used or the go tool? | 16:08 |
| * longsleep has used both | 16:09 | |
| ogra_ | seems snappy internally doesnt use fw_* | 16:09 |
| longsleep | yeah that was what i had remember from last week as well - i think the fw_* tools were just for us to test stuff, but snappy internally was using the go library? | 16:10 |
| longsleep | seems that is the conclusion you reached as well? | 16:10 |
| ogra_ | yeah, thats apparently the bit i missed | 16:11 |
| longsleep | well i did not check the go code what it actually does | 16:11 |
| ogra_ | itr is the conclusion Chipaca reached by reading the code :) | 16:11 |
| longsleep | ah great - so the fw_* tools could go away in favor of the uboot-go commandline tool eventually | 16:12 |
| Chipaca | longsleep: i think they're still used to build the image though | 16:12 |
| Chipaca | that is, used from livecd or whatever it's called | 16:12 |
| longsleep | oh ok | 16:12 |
| Chipaca | which might be where the confusion comes from | 16:12 |
| longsleep | what does the livecd builder do with it? | 16:12 |
| Chipaca | snappy uses a go lib, because it's more careful about some things that cause corruption | 16:12 |
| Chipaca | but livecd-rootfs uses the fw_ tools still, presumably because there's no benefit to using a (rather massive) binary at that point | 16:13 |
| Chipaca | longsleep: um. Dark magic, if you ask me. :-) | 16:13 |
| ogra_ | no, nothing uses it | 16:13 |
| ogra_ | we could unseed it | 16:13 |
| longsleep | +1 - what could it be used for | 16:14 |
| ogra_ | we use mkenvimage or what it is called during oem snap creation from the u-boot upstream tree | 16:14 |
| ogra_ | and then dont touch the env file anymore | 16:14 |
| longsleep | right thats what i do when building the oem snap as well | 16:15 |
| ogra_ | ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ apt-cache show u-boot-tools|grep ^Installed | 16:15 |
| ogra_ | Installed-Size: 203 | 16:15 |
| ogra_ | its not like it takes any space though | 16:15 |
| longsleep | fw_* writes or reads env files, so why that would be required doring rootfs build i cannot see | 16:15 |
| longsleep | ogra_: right | 16:15 |
| longsleep | ogra_: problem is that people might use the tools and eventually corrupt their env file (remember the 4 vs 5 byte header?) | 16:16 |
| ogra_ | otoh people might use them to debug stuff without trashing the file :) | 16:16 |
| longsleep | ogra_: i mean the scary configuration file the fw_ tools needs is reason enough to get rid of them :) | 16:16 |
| === debian is now known as Guest79970 | ||
| * ogra_ doesnt see an urgent reason to drop the tools | 16:17 | |
| Chipaca | sergiusens: poke (again) :) | 16:17 |
| longsleep | yeah they do not hurt | 16:17 |
| ogra_ | they should be dropped once we do a general cleanup though ... one where every byte counts :) | 16:18 |
| ogra_ | for the moment i'd leave them there | 16:18 |
| Chipaca | pitti: in snappy we're using dh_systemd_enable; how do i add something to wants using that? | 16:41 |
| Chipaca | pitti: never mind, thank you :) | 16:41 |
| Chipaca | i should take a break | 16:41 |
| Rlyeh | Hi | 17:20 |
| Rlyeh | Guys, where is "ubuntu-core" config file? I just can't find config file to change! | 17:20 |
| Rlyeh | Since "ubuntu-core" isn't a snap, ther is no any 'package.yaml ' | 17:21 |
| beuno | Rlyeh, what are you trying to change? | 17:21 |
| Rlyeh | Timezone :( | 17:22 |
| beuno | Rlyeh, you change it through the command line | 17:22 |
| ogra_ | you should be able to change that via the snappy config command | 17:22 |
| Rlyeh | "snappy config ubuntu-core" ? It just return vealues | 17:23 |
| Rlyeh | How can I do that? | 17:24 |
| ogra_ | bug 1472788 has some hints irc | 17:26 |
| ubottu | bug 1472788 in Snappy "snappy config does not work from stdin" [Undecided,New] https://launchpad.net/bugs/1472788 | 17:26 |
| Rlyeh | This means it's not possible to change "ubuntu-core" config file? | 17:28 |
| beuno | Rlyeh, it's a read-only files system :) | 17:28 |
| beuno | it takes config via a command line | 17:28 |
| Rlyeh | I knew that, but didn't thought "ubuntu-core" is read-only too! | 17:29 |
| Rlyeh | So, I can't change the timezone? :( | 17:30 |
| ogra_ | Rlyeh, did you read the bug ? | 17:30 |
| ogra_ | it has an example how to change the timezone | 17:31 |
| Rlyeh | No, in time, i'm using xchat on my BBB using debian, It's too slow to open a browser, but I'll check it on my PC | 17:32 |
| Rlyeh | Thank you all :) | 17:32 |
| longsleep | What is wrong when my snappy just says 'Invalid package on system' ? | 17:34 |
| longsleep | a colleague of mine just has that problem | 17:35 |
| ogra_ | good question | 17:35 |
| ogra_ | Rlyeh, snappy config ubuntu-core - <(echo -e 'config:\n ubuntu-core:\n timezone: Europe/Berlin\n') | 17:35 |
| ogra_ | Rlyeh, that sets it to berlin for me | 17:35 |
| longsleep | i cant even 'snappy list' | 17:35 |
| ogra_ | wow | 17:35 |
| longsleep | He was even using a pre built image Run vagrant init http://cloud-images.ubuntu.com/snappy/15.04/core/stable/current/core-stable-amd64-vagrant.box | 17:36 |
| Rlyeh | Thank you ogra, very much :) | 17:37 |
| ogra_ | longsleep, broken clock or something ? | 17:40 |
| * ogra_ has seen weird behavior when the clock was massively off | 17:40 | |
| longsleep | no that does not seem to be it | 17:40 |
| longsleep | i can reproduce | 17:40 |
| longsleep | hold on | 17:40 |
| longsleep | mhm or not :/ | 17:41 |
| longsleep | something is strange there | 17:42 |
| longsleep | (amd64)root@ubuntu-core-stable-3:~# date | 17:42 |
| longsleep | -su: /bin/date: Input/output error | 17:42 |
| longsleep | wtf? | 17:42 |
| ogra_ | disk screwed up ? | 17:43 |
| ogra_ | (dmesg ? ) | 17:43 |
| longsleep | mhm he deleted and reinstalling already | 17:43 |
| longsleep | lets see if he breaks it again | 17:44 |
| longsleep | mhm looks like it works now - disk must have been broken | 17:48 |
| elopio | I'm back. | 19:55 |
| elopio | mterry: are you happy with this one? https://code.launchpad.net/~elopio/snapcraft/fix1476452-python_log/+merge/265354 | 19:55 |
| mterry | elopio, ah nice, missed your comment | 19:57 |
| mterry | elopio, I'm in the middle of something now but will re-review | 19:57 |
| elopio | mterry: ok, thanks. | 19:57 |
| === blr_ is now known as blr | ||
| mterry | elopio, looking at your branch -- now some things are bold that weren't before | 20:45 |
| mterry | elopio, look at the diff in LP and you can see some things were just print() lines before | 20:46 |
| mterry | elopio, specifically when we ran a subcommand, it would not be bold | 20:46 |
| mterry | elopio, and a couple tiny other places | 20:46 |
| mterry | elopio, what's the cleanest way to distinguish there? Use another logger command than info? | 20:46 |
| === nyx_ is now known as moonwalk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!