| sergiusens | elopio, hmm | 00:00 |
|---|---|---|
| sergiusens | elopio, do you have ntfs-3g installed on vivid? | 00:02 |
| sergiusens | elopio, and wily | 00:02 |
| elopio | sergiusens: yes, on both. | 00:02 |
| elopio | failed again on vivid. Trying on wily. | 00:02 |
| elopio | tedg: where can I find your ginac example? | 00:03 |
| sergiusens | elopio, can you open a bug for the ntfs thing? | 00:12 |
| elopio | sergiusens: yes. still trying to understand what it's trying to install on vivid. | 00:12 |
| elopio | sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1511161 | 00:30 |
| ubottu | Launchpad bug 1511161 in Snapcraft "java-hello-world example fails to snap on vivid: Operation not permitted: '/home/elopio/workspace/canonical/snapcraft/trunk/examples/java-hello-world/parts/local/install/sbin/mount.ntfs'" [Undecided,New] | 00:30 |
| sergiusens | elopio, care to try this http://paste.ubuntu.com/12995475/ | 00:36 |
| sergiusens | elopio, that function still seems to have legacy from the whole return True/False era; not going to fix that now though... | 00:37 |
| elopio | sergiusens: that fails the same. | 00:44 |
| sergiusens | elopio, really? | 00:44 |
| elopio | really | 00:46 |
| sergiusens | elopio, can you apply this //paste.ubuntu.com/12995549/ | 00:46 |
| sergiusens | I eventually forgot to add the command line switch for that to show :-/ | 00:46 |
| elopio | sergiusens: paste.ubuntu.com/12995571/ | 00:49 |
| elopio | sergiusens: I need to go, my girlfriend is waiting me for dinner. I'll be back and test for a one and two more hours, so send me an email if you need something else. | 00:50 |
| sergiusens | elopio, ok, I fix the wrong location :-) | 00:51 |
| sergiusens | elopio, https://code.launchpad.net/~sergiusens/snapcraft/1511161/+merge/276075 | 02:08 |
| tedg | elopio: http://pastebin.ubuntu.com/12862605/ | 02:55 |
| tedg | I should probably put that in a gist, that's what the cool kids do. | 02:59 |
| tedg | https://gist.github.com/ted-gould/304a3a828baaaaed272f | 03:00 |
| * tedg is bad ass with color highlighting | 03:01 | |
| sergiusens | tedg, or on the parts wiki ;-) | 03:31 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| pitti | Chipaca: if you really want to wait for a particular interface you can After/Before=ifup@enXXX.service; but please don't do that :) | 07:21 |
| pitti | Chipaca: what's your use case? Normally a service would say "I need to run after the network is up" (After=network-online.target) | 07:21 |
| pitti | Chipaca: or e. g a firewall would say "I need to run *before* starting any services on the network" (Before=network-pre.target) | 07:22 |
| Chipaca | pitti: i need to run before the network is started, but after the filesystem is mounted | 07:32 |
| pitti | Chipaca: so sounds like Before=network.target then | 07:34 |
| pitti | Chipaca: if your service has DefaultDependencies=no (i. e. early boot), then also After=local-fs.target | 07:35 |
| pitti | but services without that (i. e. the implied DefaultDependencies=yes) always have local-fs.target already | 07:35 |
| Chipaca | pitti: won't that get me in a race with networking.service? | 07:36 |
| pitti | Chipaca: oh, you need to run before that too? well, then you need DefaultDependencies=no, Before=network-pre.target | 07:38 |
| pitti | Chipaca: I'd really stick to targets; note that networking.service is just ifupdown, that might change etc. | 07:39 |
| Chipaca | pitti: i'll give that a try, thank you very much! | 07:41 |
| Chipaca | but after breakfast. first things first :) | 07:41 |
| pitti | Chipaca: man systemd.special explains these targets and what they do, btw | 07:41 |
| pitti | Chipaca: absolutely! :) | 07:41 |
| mvo | Chipaca: just fyi, there seems to be some race in one of the priv tests, I sometimes get test failures in travis and a rebuild fixes them | 07:59 |
| mvo | Chipaca: have not looked in detail yet, just wanted to share it for now | 08:00 |
| dholbach | good morning | 08:04 |
| mvo | fgimenez: hey, good morning. would it help you if I import the branches of lopio into git so that you can continue with your workflow of review/merge? or is this already on the radar (not want to push, just want to help :) | 08:04 |
| mvo | hey dholbach | 08:04 |
| fgimenez | mvo, hey, of course helps thx! :) btw, could you add me to the team, pls? | 08:06 |
| Chipaca | mvo: thank you for the heads up. I'm still in why-does-the-bbb-not-have-ipv4 mode here. | 08:07 |
| fgimenez | ogra_, rolling/edge 212 boots ok but ens3 is down on first boot | 08:19 |
| Chipaca | fgimenez: yeh, that's probably my fault | 08:21 |
| Chipaca | but figuring it out on the bbb first | 08:22 |
| fgimenez | Chipaca, ah ok :) | 08:22 |
| clobrano | mvo: thank you for the branch on github | 08:29 |
| mvo | clobrano: your welcome! | 08:31 |
| guest123124 | error while executing external command kpartx -ds personal_x86.img: device-mapper: remove ioctl on loop0p5 failed: Device or resource busy | 08:41 |
| guest123124 | loop deleted : /dev/loop0 | 08:41 |
| guest123124 | got this error while flashing ubuntu personal | 08:41 |
| fgimenez | mvo, thx! :) | 08:43 |
| fgimenez | mvo, i'm getting a lot of "another snappy is running, try again later" errors running the test suite on kvm, both for rolling and 15.04 | 08:54 |
| mvo | fgimenez: interessting, that hasn't changed :/ or it should not | 09:00 |
| mvo | elopio, fgimenez: https://github.com/mvo5/snappy/tree/from-bzr/integration-fix-rollback, https://github.com/mvo5/snappy/tree/from-bzr/expose-bug1498293-boot-try, https://github.com/mvo5/snappy/tree/from-bzr/integration-tests-verbosity-flag, https://github.com/mvo5/snappy/tree/from-bzr/result_on_error | 09:01 |
| mvo | elopio, fgimenez: all imported now into git, feel free to fork and hack away. if they are good to go I can also create pull requests from them of course, just let me know | 09:02 |
| fgimenez | mvo, ok thanks a lot | 09:03 |
| mvo | your welcome! | 09:04 |
| fgimenez_ | mvo, you can execute the suite with go run _integration-tests/main.go -release 15.04 | 09:10 |
| fgimenez_ | mvo, rolling has no ens3 up now, you can create the image with , run an instance with kvm, enable ens3 from the console and execute the suite with -ip and -port | 09:11 |
| fgimenez_ | create the image with udf :) | 09:11 |
| Chipaca | ogra_: how do I edit the kernel commandline on bbb? | 09:18 |
| ogra_ | fw_printenv |grep ^mmcargs | 09:18 |
| ogra_ | sudo fw_setenv mmcargs setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot} foobar" | 09:19 |
| ogra_ | oh, except ... quoting | 09:19 |
| Chipaca | got it, thanks | 09:19 |
| ogra_ | sudo fw_setenv mmcargs 'setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot} foobar"' | 09:20 |
| ogra_ | (else the curly brackets get swallowed) | 09:20 |
| ogra_ | works the same on RPi btw | 09:20 |
| Chipaca | mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype} | 09:20 |
| Chipaca | that's what i have | 09:21 |
| ogra_ | yeah, mine is from RPi | 09:21 |
| ogra_ | rootfstype is nonsense, we need to clean that up some point | 09:21 |
| Chipaca | ah, ok | 09:22 |
| ogra_ | on the BBB you can obviously also use optargs instead of mmcargs | 09:23 |
| ogra_ | (the default vars come from upstream, we only add the snappy bits) | 09:24 |
| Chipaca | pitti: with before:networking-pre i'm still not running it early enough it seems | 09:35 |
| Chipaca | pitti: but i can't see what it is that i need to run earlier than | 09:36 |
| pitti | Chipaca: networking.service has After=network-pre.target, so that really ought to work | 09:36 |
| pitti | Chipaca: what is "it" and how does it fail? | 09:36 |
| Chipaca | pitti: on first boot, we create a file for the first ethernet device, to be brought up by ifup | 09:37 |
| pitti | Chipaca: does the service get run and the file created? any dependency cycles in journalctl perhaps? | 09:38 |
| pitti | Chipaca: did you set DefaultDependencies=no? | 09:38 |
| Chipaca | pitti: without defaultdependencies i'd get a cycle | 09:38 |
| Chipaca | without DefaultDependencies=false i mean | 09:38 |
| pitti | right, I expect that | 09:38 |
| Chipaca | but now no, no cycle, firstboot process is run | 09:38 |
| Chipaca | i even added a before: wait-for-ifup-whateveritscalled | 09:39 |
| Chipaca | because that was started at the same time | 09:39 |
| Chipaca | and no | 09:39 |
| pitti | that runs after ifup@.service, so even later | 09:39 |
| pitti | s/run/finishes/, sorry | 09:39 |
| Chipaca | well, but ifup@.service isn't running? or isn't in the logs | 09:40 |
| pitti | but please don't add deps to that, it's just an "internal" helper unit to implement network-online.target | 09:40 |
| Chipaca | ok, let me remove that, and i'll show you the boot graph | 09:40 |
| pitti | Chipaca: oh, so the problem isn't that your firstboot unit runs too late, but that ifup@.service does *not* run on first boot? | 09:40 |
| pitti | (I could explain that) | 09:40 |
| Chipaca | pitti: i'm listening :) | 09:41 |
| pitti | Chipaca: first -- is that the problem? | 09:41 |
| Chipaca | pitti: I don't know enough to know whether that is a consequence of the problem, or a cause of it | 09:42 |
| Chipaca | pitti: that happens, certainly | 09:42 |
| pitti | Chipaca: but I mean, your firstboot unit runs and creates /e/n/i, but ifup@ doesn't get run and you have no network? | 09:42 |
| Chipaca | pitti: firstboot unit runs. ifup@ doesn't get run. | 09:42 |
| pitti | actually, /etc/init.d/networking should then still bring it up, so that's a bit strange | 09:42 |
| Chipaca | pitti: i have ipv6 | 09:42 |
| Chipaca | pitti: but not ipv4 | 09:42 |
| pitti | Chipaca: does networking.service run? | 09:43 |
| Chipaca | pitti: yes | 09:43 |
| Chipaca | let me double-check that actually | 09:43 |
| pitti | because that should "mop up" things that ifup@.service didn't catch | 09:43 |
| Chipaca | no, networking.service is not in journalctl | 09:43 |
| pitti | Chipaca: so, I know why ifup@ didn't run, but I can't explain why networking.service didn't bring up the eth | 09:43 |
| pitti | Chipaca: if you grep, search for "Description=LSB: Raise network interfaces" | 09:44 |
| Chipaca | (BeagleBoneBlack)ubuntu@localhost:~$ sudo journalctl | grep "Description=LSB: Raise network interfaces" | 09:44 |
| Chipaca | (BeagleBoneBlack)ubuntu@localhost:~$ | 09:44 |
| pitti | Chipaca: nah, not "Description=" :) | 09:44 |
| Chipaca | Oct 29 09:35:50 localhost.localdomain systemd[1]: Starting LSB: Raise network interfaces.... | 09:45 |
| pitti | that sohuld run ifup -a | 09:45 |
| pitti | does that run after your firstboot thingy? | 09:45 |
| Chipaca | yes | 09:45 |
| Chipaca | and then after that runs i have | 09:46 |
| Chipaca | a bit of dhcp, and | 09:46 |
| Chipaca | Oct 29 09:35:57 localhost.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready | 09:46 |
| pitti | so dhclient ran, but didn't give you an IPv4 address? | 09:46 |
| Chipaca | correct | 09:46 |
| pitti | wow; I don't have the slightest idea about that then | 09:47 |
| Chipaca | but only on first boot | 09:47 |
| Chipaca | from then on, ipv4 comes up fine | 09:47 |
| pitti | sudo journalctl -u networking.service should have the dhclient output, what did it say? | 09:47 |
| Chipaca | nothing about dhcp | 09:48 |
| Chipaca | let me pastebin | 09:48 |
| Chipaca | pitti: http://paste.ubuntu.com/12997839/ | 09:48 |
| pitti | Chipaca: could you set VERBOSE in /etc/default/networking (or change the default in /etc/init.d/networking), and add "grep -r . /run/network/" to the start) part of /etc/init.d/networking? | 09:51 |
| pitti | it seems this doesn't actually start anything, it seems to think that they are already up for some reason | 09:52 |
| pitti | Chipaca: also, something to try: to your firstboot, add Before=systemd-udev-trigger.service | 09:52 |
| pitti | Chipaca: that should hopefully make ifup@*.service start on firstboot | 09:52 |
| pitti | that doesn't explain why /etc/init.d/networking didn't bring them up, of course | 09:53 |
| Chipaca | rebooting with those changes, plus systemd.log_level=debug in commandline | 09:55 |
| Chipaca | ah, and this is still the last wily, I could bump it to xenial if it makes a difference | 09:55 |
| Chipaca | pitti: just to keep things interesting, now it came up with no ipv6 either | 09:57 |
| pitti | Chipaca: I suppose ipv6 is just the fe80: LL address? | 09:57 |
| pitti | or do you actually get a DHCP address for it? | 09:57 |
| Chipaca | fe80::d25f:b8ff:fea3:907f | 09:58 |
| Chipaca | which afaik is not ll | 09:58 |
| pitti | Chipaca: no, wily should be fine; note that one change was debugging why networking.service doesn't call ifup -a; if you do the Before=udev-trigger, then neworking.service will almost surely not do anything because ifup@ already did | 09:58 |
| pitti | Chipaca: that's LL | 09:58 |
| pitti | fe80:<some hash of the MAC> | 09:58 |
| Chipaca | oh | 09:59 |
| Chipaca | d'oh | 09:59 |
| pitti | curious where that comes from, of course | 09:59 |
| pitti | you don't have networkd enabled/configured or something such? | 09:59 |
| pitti | if neither networking.servcie nor ifup@ up the interface, then what does | 10:00 |
| JamesTait | Good morning all; happy Thursday, and happy Internet Day! 😃 | 10:00 |
| pitti | Chipaca: btw, you coudl probably make all of this a lot simpler | 10:00 |
| pitti | Chipaca: let your network config thing run later (no DefaultDependencies), create your interfaces.d snippet and just call ifup <yournewinterface> | 10:01 |
| pitti | Chipaca: but anyway, for the sake of understanding what on earth happens there, let's finish this :) | 10:01 |
| Chipaca | pitti: networking service now failed to start | 10:02 |
| Chipaca | pitti: so i probably bungled an edit | 10:02 |
| Chipaca | pitti: http://paste.ubuntu.com/12997894/ | 10:02 |
| Chipaca | pitti: but i'm not seeing the error | 10:03 |
| pitti | Chipaca: grep -r . /run/network/ || true | 10:03 |
| pitti | Chipaca: if the script is set -e | 10:03 |
| pitti | Chipaca: if there are no files, grep exits with 1 | 10:03 |
| Chipaca | ah! right | 10:03 |
| Chipaca | pitti: where would i see this output btw? | 10:03 |
| pitti | Chipaca: but that already tells us that there's no /ifstate | 10:03 |
| pitti | Chipaca: should be in the journal, or systemctl status -l networking | 10:04 |
| Chipaca | i can't see the ####s there | 10:04 |
| pitti | Chipaca: sure -- the command is just "echo" :) # is a comment | 10:04 |
| Chipaca | anyway, adding the ||true and rebooting | 10:04 |
| pitti | ech '###' | 10:05 |
| Chipaca | augh! | 10:05 |
| Chipaca | stupid me is stupid :) | 10:05 |
| ogra_ | blame the weather | 10:05 |
| pitti | Chipaca: of all the --- ____ **** etc. chars you could have picked you got the wrong one :) | 10:05 |
| Chipaca | pitti: i nearly went with **** | 10:05 |
| pitti | but yeah, shell is fun, isn't it | 10:05 |
| Chipaca | pitti: that's my usual :) | 10:05 |
| pitti | Chipaca: that will actually do a glob | 10:05 |
| Chipaca | exactly | 10:06 |
| Chipaca | i caught myself :) | 10:06 |
| pitti | Chipaca: so you might see "bin" or "usr" or whatever comes first in / :) | 10:06 |
| Chipaca | ogra_: i'll blame you instead. it's shell, afterall. | 10:06 |
| ogra_ | oh, ok, sorry for breaking :) | 10:06 |
| pitti | we didn't get rid of shell in shappy yet? :-) | 10:06 |
| ogra_ | luckily not | 10:07 |
| Chipaca | ... yet | 10:07 |
| Chipaca | ]:D | 10:07 |
| ogra_ | glue is glue :P | 10:07 |
| pitti | of all programming languages this is probably the most error-pone | 10:07 |
| Chipaca | first, init=/snappy | 10:07 |
| Chipaca | then, the world | 10:07 |
| pitti | almost as error p*r*one than my spelling, of course | 10:07 |
| ogra_ | but also the easiest to learn which gets you lots of free contributions of more broken code :) | 10:08 |
| pitti | ogra_: I was about to say PHP *cough* *cough* | 10:08 |
| * Chipaca twiddles his thumbs while the bbb recreates the universe | 10:09 | |
| pitti | Chipaca: ugh, poor you -- this doesn't reproduce in a VM? | 10:09 |
| Chipaca | pitti: nope | 10:09 |
| * ogra_ doesnt want the universe to depend on a single BBB | 10:09 | |
| Chipaca | pitti: http://paste.ubuntu.com/12997933/ | 10:11 |
| Chipaca | >>>>> Parsing file /etc/network/interfaces.d/eth0 <<<<<< | 10:11 |
| Chipaca | W | 10:11 |
| Chipaca | T | 10:11 |
| Chipaca | <expletive> | 10:12 |
| pitti | Chipaca: i. e. it sees /etc/network/interfaces.d/eth0 but doesn't see any contents or so? | 10:12 |
| pitti | Chipaca: could that be a missing fsync, i. e. the file is still in write cache? | 10:12 |
| pitti | I mean, other processes see that cache too, but who knows | 10:13 |
| pitti | Chipaca: oh -- is your firstboot thing Type=oneshot? And/or, did it actually *finish* before networking.service? Can you pastebin the full journal? | 10:13 |
| Chipaca | pitti: it does the whole sync/rename/sync directory dance | 10:14 |
| pitti | Chipaca: ok -- le journal entier, s'il te plaît | 10:14 |
| pitti | Chipaca: (silly question, but /etc/network/interfaces.d/eth0 looks alright after boot?) | 10:15 |
| Chipaca | allow-hotplug eth0 | 10:15 |
| Chipaca | iface eth0 inet dhcp | 10:15 |
| pitti | aah! | 10:15 |
| pitti | that explains why /e/i/networking doesn't do it | 10:15 |
| pitti | that only does "auto" interfaces | 10:15 |
| Chipaca | hmm | 10:16 |
| pitti | Chipaca: "auto" works for both cold and hotplug in Ubuntu; stgraber told me that several things in Ubuntu (ifenslave and what not) never learned about "allow-hotplug" | 10:16 |
| pitti | Chipaca: so allow-hotplug is only caught by ifup@.service | 10:16 |
| Chipaca | that's ok, though, that's what we want | 10:16 |
| pitti | Chipaca: and that gets triggered very early on via udev rules, at which point your firstboot didn't run yet | 10:16 |
| pitti | Chipaca: do you? I think you want "auto" there, there is little reason to not use it | 10:17 |
| Chipaca | auto introduces a huge boot delay if the cable isn't plugged in | 10:17 |
| pitti | Chipaca: for ifup@ via udev rules you need to run before systemd-udev-trigger.service | 10:17 |
| pitti | Chipaca: ah, ok -- you don't want that? | 10:17 |
| ogra_ | no | 10:17 |
| pitti | I was specifically asked to implement that | 10:17 |
| ogra_ | we want allow-hotplug | 10:17 |
| ogra_ | else if you have no cable connected it will wait for the timeout | 10:18 |
| pitti | that's what we did in upstart for years, and apparently we wanted that behaviour in systemd too to work with services which don't get along with hotplugged interfaces | 10:18 |
| pitti | ok then | 10:18 |
| pitti | so that means /etc/init.d/networking is out of the game | 10:18 |
| Chipaca | well | 10:18 |
| pitti | which already explains a lot of the above confusion :) | 10:18 |
| Chipaca | we do have services that don't get along with hotplug | 10:19 |
| ogra_ | well, a drone might only have a wired connection while you maintain it ... but not while you fly it | 10:19 |
| ogra_ | if it reboots while flying or some such you want it to do that before it hits the ground ;) | 10:19 |
| pitti | Chipaca: things like ssh ship an /etc/network/if-up.d/ script to reload/restart themselves | 10:19 |
| pitti | which is utterly "erks", but oh well | 10:19 |
| ogra_ | and not have it wait 3min for a cable connection | 10:19 |
| pitti | IP_FREEBIND! | 10:19 |
| pitti | ogra_: oh, I'm absolutely on your side | 10:20 |
| ogra_ | i think the master plan is still to use systemds network management or nm | 10:20 |
| ogra_ | in the longer term | 10:20 |
| Chipaca | pitti: so, looking at http://people.canonical.com/~john/bbb.svg | 10:20 |
| ogra_ | which should make dynamic services work | 10:20 |
| pitti | I didn't *like* this "block boot for 2 mins", but I was asked to do that to mirror what we did before | 10:21 |
| ogra_ | yeah | 10:21 |
| Chipaca | pitti: systemd-udev-trigger comes up very early, before mounts | 10:21 |
| Chipaca | pitti: i suspect it's not going to like me saying i want to go before that and after mount | 10:21 |
| pitti | Chipaca: yeah; it's not that easy to run stuff before that | 10:22 |
| pitti | Chipaca: IMHO it's much simpler (and much more parallel) to just call ifup after you created the definition | 10:22 |
| Chipaca | ok, fair enough, i'll do that | 10:22 |
| Chipaca | pitti: you do now know why things were weird, then, no more debugging needed? | 10:22 |
| pitti | Chipaca: so from the mysteries above the one thing which isn't clear to me yet is what brought up eth0 and assigned an IPv6LL address | 10:23 |
| Chipaca | dhcp | 10:23 |
| Chipaca | (why? oh i have no idea) | 10:23 |
| pitti | Chipaca: it's clear why networking.service didn't bring it up, and why ifup@ didn't run (as udev rules run much earlier than your firstboot thing) | 10:23 |
| Chipaca | here, let me pastebin the journal | 10:23 |
| Chipaca | pitti: http://paste.ubuntu.com/12998003/ | 10:24 |
| Chipaca | pitti: if you look for ipv6 in there | 10:25 |
| pitti | (OTP, brb) | 10:25 |
| pitti | Chipaca: is/was the device actually up? or did it merely get a default address assigned by the kernel, but was down? | 10:28 |
| pitti | "down" would be expected; "up" would be a surprise | 10:28 |
| Chipaca | up | 10:29 |
| Chipaca | down in the vm | 10:29 |
| Chipaca | up in bbb | 10:29 |
| Chipaca | pitti: well, that worked | 10:31 |
| Chipaca | let me check journal just in case | 10:31 |
| Chipaca | Oct 29 10:30:37 localhost.localdomain systemd[1]: ubuntu-snappy.firstboot.service: Failed to send unit change signal for ubuntu-snappy.firstboot.service: Transport endpoint is not connected | 10:34 |
| Chipaca | pitti: what does that ^ mean? | 10:34 |
| Chipaca | (everything else seems correct) | 10:34 |
| pitti | Chipaca: presumably that dbus isn't running at that time yet | 10:35 |
| pitti | Chipaca: but that's a debug message; still running with "debug"? | 10:36 |
| Chipaca | yes | 10:36 |
| Chipaca | kernel options go in firmware | 10:36 |
| Chipaca | so ¯\_(ツ)_/¯ | 10:36 |
| pitti | Chipaca: pronounce that quickly ten times in a row | 10:36 |
| Chipaca | :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: | 10:36 |
| Chipaca | dammit | 10:37 |
| * pitti feels the rhythm & beat | 10:37 | |
| Chipaca | obviously :shrug with another : turns into ¯\_(ツ)_/¯ | 10:37 |
| Chipaca | but not :shurg: | 10:38 |
| Chipaca | weird, that | 10:38 |
| Chipaca | :) | 10:38 |
| Chipaca | anyway | 10:38 |
| Chipaca | pitti: should i move firstboot away from being so early in the boot, now that you know more about what it does/needs/wants to do? | 10:38 |
| pitti | Chipaca: please drop the before=udev-trigger, indeed | 10:41 |
| pitti | Chipaca: defaultdeps=no and after=local-fs.target still sound fine, and do keep the before=network-pre.target too | 10:41 |
| Chipaca | After=local-fs.target | 10:41 |
| Chipaca | Before=network-pre.target | 10:41 |
| Chipaca | DefaultDependencies=false | 10:41 |
| Chipaca | is what i have now | 10:41 |
| pitti | I mean, it's first boot, so it's not a biggie if that takes .5 seconds longer, but *shrug* | 10:41 |
| pitti | Chipaca: LGTM | 10:42 |
| Chipaca | oh, that's a good point, is there a systemd idiom for "don't run if this file exists"? | 10:42 |
| pitti | Chipaca: oh, you want that, right | 10:42 |
| pitti | [Unit] | 10:42 |
| Chipaca | firstboot itself checks, but why even start it :) | 10:42 |
| pitti | ConditionPathExists=!/path/to/file | 10:42 |
| Chipaca | nice | 10:43 |
| pitti | Chipaca: perhaps you also want ConditionPathExistsGlob=!/etc/network/interfaces.d/* | 10:43 |
| pitti | Chipaca: see man systemd.unit, there's a bunch of them | 10:43 |
| pitti | there's even a ConditionFirstBoot=, but that doesn't really work for us yet | 10:43 |
| Chipaca | thanks | 10:44 |
| pitti | (that means "/etc is empty") | 10:44 |
| pitti | Chipaca: yeah, more efficient than starting a program just to determine that you don't need it | 10:44 |
| Chipaca | i'll just leave it at stamp for now | 10:45 |
| Chipaca | as creating that iface is not the only thing it does | 10:46 |
| * Chipaca reboots to test | 10:46 | |
| Chipaca | anyway, pitti, i've stolen enough of your time already :) thanks a bunch | 10:46 |
| pitti | Chipaca: ah, that sounds fine; I thought you wanted to do FileExists=/etc/network/interfaces.d/eth0, which would be a bit pointless | 10:47 |
| pitti | Chipaca: if you have some "first-boot ran" stamp, then do use that of course | 10:47 |
| Chipaca | pitti: it's not always eth0, is where the fun started :) | 10:47 |
| pitti | Chipaca: right, that's what I meant | 10:48 |
| Chipaca | but yeh, we've got a stamp file for this | 10:48 |
| pitti | but yeah, networkd :) | 10:48 |
| Chipaca | pitti: networkd? | 10:50 |
| pitti | I thought Mark wanted to move to that at some point | 10:50 |
| Chipaca | ah. well, it's on there, isn't it? | 10:50 |
| pitti | or to a different naming schema for interfaces | 10:51 |
| pitti | or both | 10:51 |
| pitti | Chipaca: right, but we currently use ifupdown | 10:51 |
| Chipaca | :) | 10:51 |
| pitti | [Match] | 10:52 |
| pitti | Name=en* eth* | 10:52 |
| pitti | done | 10:52 |
| Chipaca | pitti: how well does that play with networkmanager? | 10:53 |
| pitti | Chipaca: same way ifupdown does -- not at all | 10:53 |
| pitti | i. e. you need to pick one network management thingy for each interface | 10:53 |
| pitti | (and ideally for the whole system, otherwise it's too confusing) | 10:53 |
| Chipaca | pitti: right. Which means ifupdown gives us a way to say "we'll bring up just the first ethernet differently, just so you can then install network manager for the rest", whereas networkd makes that "all ethernet devices are networkd-managed" | 10:57 |
| Chipaca | which is the same but different | 10:58 |
| pitti | Chipaca: right; if we want to pick one particualr interface, the Name= thing woudl be the same as with ifupdown | 10:58 |
| pitti | Chipaca: but if we are going to have NetworkManager on snappy, why not use that for eth as well then? | 11:00 |
| Chipaca | pitti: because it's a .snap, not part of the base | 11:00 |
| Chipaca | pitti: well --- having said that | 11:01 |
| pitti | ah, ok; so not "on" snappy, just "for" snappy | 11:01 |
| Chipaca | it would be easy to turn off this thing | 11:01 |
| Chipaca | snappy config lets you write an empty file to interfaces.d, and that would sort that out | 11:01 |
| Chipaca | but a bit more code would be needed | 11:02 |
| ogra_ | well ... given that NM will want to manage eth0 too we need somw wa for the nm snap to tell snappy to not apply the config | 11:03 |
| ogra_ | *some way | 11:03 |
| Chipaca | ogra_: that's doable | 11:05 |
| Chipaca | ogra_: although not from the package itself | 11:05 |
| Chipaca | it's package+config doable | 11:05 |
| Chipaca | ogra_: from u-d-f, if you want to preload n-m, just create an empty file in interfaces.d | 11:07 |
| Chipaca | create empty file -> via snappy config | 11:07 |
| Chipaca | ogra_: if you install it after, use snappy config to overwrite the eth file with an empty one | 11:07 |
| Chipaca | ogra_: done | 11:08 |
| ogra_ | i dont want an empty one | 11:08 |
| ogra_ | NM will mangae that file | 11:08 |
| ogra_ | i think we need a way for snaps to turn off core features they deliver themselves | 11:08 |
| ogra_ | look at bug 1504657 and longsleep's comments ... same thing | 11:10 |
| ubottu | bug 1504657 in ubuntu-core-config (Ubuntu) "ntp servers should be configurable on snappy" [Medium,Confirmed] https://launchpad.net/bugs/1504657 | 11:10 |
| ogra_ | he might ship ntpd inside a spreedbox snap ... which would then want to disable timesyncd | 11:10 |
| Chipaca | ogra_: good point | 11:12 |
| ogra_ | Chipaca, oh, and another thing ... why cant the atomic write use /tmp (the above will force me to add another link to /etc/writable, this is getting really awkward) | 11:12 |
| Chipaca | actually, i'd be happier if all these were snaps :) | 11:12 |
| Chipaca | ogra_: because different partition | 11:12 |
| ogra_ | hmpf | 11:13 |
| Chipaca | ogra_: only rename is atomic :-( | 11:13 |
| Chipaca | and even then you need to sync the dir | 11:13 |
| ogra_ | i wonder why everything else gets along without atomic writing .... on the phone we have exactly three files in /etc/writable | 11:13 |
| Chipaca | probably because i wasn't looking :D | 11:14 |
| ogra_ | in snappy we'll have 10-20 soon if it goes on at this pace | 11:14 |
| Chipaca | ogra_: probably because most of them are small enough, and written to sporadically enough, that crashes due to this are impossible to reproduce | 11:15 |
| Chipaca | ogra_: so you'll find that sometimes things won't work, and try again, and they will, and shrug your shoulders and move on | 11:16 |
| ogra_ | hmm | 11:16 |
| ogra_ | the problem with the setup we use now is that these files will never be upgraded | 11:17 |
| ogra_ | i.e. if the tool needs new options they wont show up, the setup completely works around system-image | 11:17 |
| ogra_ | (where we have sync and transition options) | 11:17 |
| ogra_ | (i.e. we are doing a three way merge but ignore upstream to turn it into a two way one) | 11:18 |
| Chipaca | fgimenez_: you know the "bbb only has ipv6 on first boot" bug, and the "kvm has no network on first boot" bug? | 11:18 |
| Chipaca | ogra_: i'm afraid i don't know enough to be helpful :-( glad to learn if you need help though :) | 11:19 |
| ogra_ | well, there is no solution to this | 11:19 |
| ogra_ | which is why we generally dont really use /etc/writable on the phone | 11:20 |
| fgimenez_ | Chipaca, there's one for the bbb ipv6 issue, not sure about kvm one, let me check | 11:20 |
| ogra_ | exccept for files where we know no new upstream options will show up | 11:20 |
| ogra_ | (hostname, timezone and localtime are single option config files) | 11:20 |
| ogra_ | if we use watchdog.conf and watchdog grows a new option it will never show up in the config | 11:21 |
| Chipaca | ogra_: why? that's the bit i don't follow | 11:21 |
| Chipaca | ahhh | 11:21 |
| Chipaca | i got you now | 11:21 |
| ogra_ | beacuse files in /etc/writable come from snappy only | 11:21 |
| ogra_ | and are never synced with the upstream version again | 11:21 |
| ogra_ | (i.e. on upgrades) | 11:22 |
| fgimenez_ | Chipaca, https://bugs.launchpad.net/snappy/+bug/1503329 | 11:22 |
| ubottu | Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Critical,Confirmed] | 11:22 |
| Chipaca | ogra_: you mean when updating, if the new watchdog grows more options, 3-way-diff a la dpkg is a no-go, etc | 11:22 |
| ogra_ | right, it simply doesnt happen ... your local config will override it forever | 11:22 |
| Chipaca | ogra_: now everything you said makes sense :) | 11:22 |
| Chipaca | agreed, but that to me means | 11:23 |
| ogra_ | the system-image writable thing cares for syncing | 11:23 |
| Chipaca | the config should be generated from snappy based on stuff snappy tracks | 11:23 |
| Chipaca | then when things change, snappy can have the smarts to update the config with sane defaults | 11:23 |
| Chipaca | with no chance of the user/owner/etc breaking the config, as it'd get stomped on every time | 11:23 |
| Chipaca | hmm | 11:24 |
| ogra_ | in general i wonder if we cant edit the file in /tmp and then mv it or some such ... while thats a bit less reliable it will really only be minimal | 11:24 |
| ogra_ | that way we could use the system-image setup again | 11:24 |
| Chipaca | ogra_: system-image is going away though | 11:25 |
| ogra_ | not the mounting functions | 11:25 |
| ogra_ | unless we really fgo for overlayfs and leave the phones behind | 11:25 |
| zyga | pindonga: hey | 11:29 |
| pindonga | hey | 11:29 |
| pindonga | so, I'm running snapcraft again from scratch | 11:30 |
| pindonga | I'll let you know in a sec how it goes | 11:30 |
| zyga | pindonga: okay :) | 11:30 |
| longsleep | Anyone can tell me where to find all possible config options for ubuntu-core? Or maybe a link to the config hook would be awesome. | 11:40 |
| Chipaca | longsleep: ubuntu-core is a bit special and different wrt config | 11:41 |
| Chipaca | longsleep: but i can give you a link | 11:41 |
| Chipaca | longsleep: https://github.com/ubuntu-core/snappy/blob/master/coreconfig/config.go | 11:41 |
| longsleep | Chipaca: that would be aweseome - i also would like to understand what and why ubuntu-core is special so the code should help a lot thanks! | 11:41 |
| Chipaca | longsleep: it's special in that it's handled internally by snappy | 11:42 |
| Chipaca | longsleep: other than that, it's the same, really :) | 11:42 |
| longsleep | Chipaca: so one could say it as virtual snap right? | 11:42 |
| Chipaca | longsleep: something like that :) | 11:42 |
| longsleep | Chipaca: ok great thanks | 11:42 |
| Chipaca | mvo: when core becomes a snap, do we move the config to a hook in the snap itself? | 11:43 |
| sergiusens | Chipaca, mind looking at that review from earlier? | 11:43 |
| ogra_ | if you look for a config handler, here is a shell variant :) http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/config.sh | 11:43 |
| Chipaca | sergiusens: no, i don't. have a link? | 11:43 |
| mvo | Chipaca: maybe, I have no plan for this yet | 11:44 |
| sergiusens | Chipaca, https://code.launchpad.net/~sergiusens/snapcraft/1501222/+merge/276089 | 11:44 |
| mvo | Chipaca: it would make sense plus we move snappy into a snap | 11:44 |
| sergiusens | Chipaca, sorry, sent it in private as I felt like writing in spanish :-P | 11:44 |
| * sergiusens thinks we need #snappy-es :-) | 11:44 | |
| ogra_ | mvo, that sounds awfully recursive :) snappy ships snappy in a sap | 11:45 |
| Chipaca | sergiusens: gah, and i have too many channels open, never saw your pm | 11:45 |
| ogra_ | *snap | 11:45 |
| sergiusens | Chipaca, yeah, I'm thinking of using telegram more these days for private messages, but then notifications don't work for you :-P | 11:45 |
| sergiusens | Chipaca, which brings to mind, you should use the ubuntu push notifications, I've heard they were implemented by a very good dev ;-) | 11:46 |
| Chipaca | sergiusens: notifications work for telegram! | 11:46 |
| sergiusens | Chipaca, oh, I thought they weren't working for you on the desktop | 11:46 |
| Chipaca | sergiusens: it's just some of the group chats i've disabled them for | 11:46 |
| sergiusens | oh, goodie | 11:47 |
| Chipaca | sergiusens: ah, well, sometimes when pulseaudio is having a bad day, yes | 11:47 |
| sergiusens | :-) | 11:47 |
| pindonga | zyga, wow, this time after a second snapcraft clean and full run it seems to have worked! | 11:48 |
| Chipaca | pindonga: snapcraft working? surely you jest! | 11:49 |
| pindonga | Chipaca, I wish I was :) | 11:49 |
| Chipaca | :) | 11:49 |
| pindonga | Chipaca, I think it's one of these pieces of software that work with quantum mechanics | 11:49 |
| pindonga | they only seem to work when smart people are watching me | 11:49 |
| Chipaca | pindonga: you should get sergiusens to watch you instead | 11:50 |
| * Chipaca runs for the hills | 11:50 | |
| * sergiusens read that | 11:50 | |
| * Chipaca runs faster | 11:50 | |
| sergiusens | pindonga, can I see your yaml? | 11:50 |
| Chipaca | sergiusens: at least buy him dinner first | 11:51 |
| pindonga | sergiusens, it worked , but sure, if you like :) | 11:51 |
| sergiusens | pindonga, right, I want to know how it failed to make it easier | 11:51 |
| ogra_ | "can i see your yaml" ... this has turned into a nasty channel over time | 11:51 |
| pindonga | let me paste your a few things | 11:51 |
| ogra_ | everyone wants to see each others yaml ! | 11:51 |
| pindonga | sergiusens, http://pastebin.ubuntu.com/12998485/ | 11:54 |
| Chipaca | ogra_: it's called freiyamlkultur | 11:55 |
| ogra_ | lol | 11:55 |
| Chipaca | ogra_: you wouldn't understand | 11:55 |
| longsleep | ogra_: In your crazy config.sh for irc proxy, you are storing a yaml file separatly from the real config. Is that the suggested approach? I am currently processing existing config in both directions without storing the yaml. | 11:55 |
| ogra_ | longsleep, no idea whats the suggested approach, thats what i picked, one of the configs needs to be the master | 11:56 |
| longsleep | ogra_: right, in spreed-webrtc the real ini config is the master and is used to generate yaml on read | 11:56 |
| ogra_ | you could surel also do it the other way round, but i want to reflect the implementation state in the snap, not all bip.conf options are handled yet | 11:56 |
| ogra_ | there is one issue with shell here ... at least with my approach of using eval ... you cant use dashes in options (shell doesnt allow vars to have them) | 11:57 |
| longsleep | yeah, for now i chose python3 to create the config hooks | 11:58 |
| ogra_ | yeah, i didnt want to ship python in my snap :) | 11:58 |
| longsleep | i am using python3 from the system - i figured that is safe enough for now | 12:00 |
| ogra_ | until we drop it, yeah | 12:00 |
| zyga | pindonga: :) | 12:06 |
| zyga | pindonga: magic | 12:06 |
| zyga | pindonga: I'm glad I could help | 12:06 |
| sergiusens | pindonga, zyga ah flexget has a strange setup.py | 12:10 |
| pindonga | how so? | 12:13 |
| sergiusens | pindonga, https://github.com/Flexget/Flexget/blob/develop/setup.py | 12:13 |
| pindonga | oh, right | 12:14 |
| sergiusens | not saying wrong, just strange ;-) | 12:14 |
| pindonga | not setuptools based | 12:14 |
| sergiusens | pindonga, right, so you don't get your requirements installed by default | 12:14 |
| pindonga | right, but that failure was ok, easy to understand and fix | 12:15 |
| pindonga | the first failure was odd | 12:15 |
| pindonga | before I had to run snapcraft clean | 12:15 |
| sergiusens | pindonga, that is a bug; mind logging it? | 12:16 |
| pindonga | I'll try to reproduce it , then yes! | 12:16 |
| sergiusens | pindonga, I bet if you run snapcraft all --force without cleaning again the error will show | 12:17 |
| ogra_ | mvo, would you mind if we moved the installation of the linux package and the creation of the device tarballs after the rootfs creation in livecd-rootfs ? (i,e, from a hook into live-build/auto/build) | 13:08 |
| ogra_ | that way we dont need to wipe all that stuff from /boot and can also create multiple tarballs fr different subarches without tainting the rootfs | 13:09 |
| ogra_ | i think we are currently doing it pretty wrong | 13:09 |
| ogra_ | (and it makes rpi device tarball creation really hard) | 13:10 |
| ogra_ | similar to how we do it for the phone device tarballs (or for the ac100 images in the past) | 13:12 |
| jdstrand | pindonga: hi! you still have minecraft 0.1 in the store that is pending review. do you need it reviewed or do you plan to remove it? | 13:33 |
| * pindonga checks | 13:33 | |
| pindonga | jdstrand, what minecraft? I see no minecraft ;-) | 13:34 |
| jdstrand | pindonga: thanks! :) | 13:34 |
| longsleep | I just noticed that autopilot fails to start when bootup without network in 15.04/edge (added bug #1511374) | 13:37 |
| ubottu | bug 1511374 in Snappy "snappy.autopilot service fails to start when no network connection" [Undecided,New] https://launchpad.net/bugs/1511374 | 13:37 |
| jdstrand | Chipaca: hi! I know you told me before, but I can't seem to find it.... how do I workaround bug #1509451 ? | 13:41 |
| ubottu | bug 1509451 in Snappy "snappy update is not updating snappy-debug" [Critical,Fix committed] https://launchpad.net/bugs/1509451 | 13:41 |
| jdstrand | Chipaca: before I uninstalled and installed. I'm hitting this on another package and would prefer not to do that with this one | 13:41 |
| Chipaca | jdstrand: from memory, | 13:42 |
| Chipaca | jdstrand: for i in $( grep -L ^channel: /var/lib/snappy/meta/*.manifest ); do echo -e "\nchannel: stable" | sudo tee -a $i; done | 13:43 |
| pindonga | so, I managed to build my snap pkg using snapcraft, but it fails review in the store | 13:43 |
| pindonga | package contains external symlinks: /tmp/clickreview-kb8ua64p/usr/lib/python2.7/site-packages lint_external_symlinks | 13:43 |
| pindonga | is there a way to fix this via snapcraft itself? | 13:43 |
| sergiusens | pindonga, quick way, in snapcraft.yaml, for the part using python2 add 'snap: -usr/lib/python2.7/site-packages' and log a bug with a reproducer :-) | 13:46 |
| jdstrand | Chipaca: yes, that worked. thanks! | 13:46 |
| jdstrand | Chipaca: also, what is the deal with git vs bzr. should we only be using git now? | 13:47 |
| Chipaca | jdstrand: yes | 13:47 |
| jdstrand | ok | 13:47 |
| Chipaca | jdstrand: bzr is so 2008 | 13:47 |
| ogra_ | and rock solid :P | 13:47 |
| jdstrand | but it is so under my fingers | 13:47 |
| Chipaca | jdstrand: yeah :( | 13:48 |
| Chipaca | jdstrand: still, it's proving to be less of a pain than i remembered it to be | 13:49 |
| Chipaca | i guess the last time i looked was 1.4something-era? | 13:49 |
| sergiusens | Chipaca, the git cli improved a lot | 13:49 |
| sergiusens | Chipaca, and github is what really makes git easy to use | 13:49 |
| jdstrand | curious on why git support in lp wasn't chosen | 13:50 |
| longsleep | Chipaca: do you have any thoughts on ntp configuration in snappy? Is there anything planned to get rid of systemd ntp client and have snappy use a ntp client which can validate the time? | 13:50 |
| Chipaca | longsleep: i still need to look up that about validation | 13:51 |
| Chipaca | longsleep: do you have anything you can point me at wrt that? | 13:51 |
| longsleep | Chipaca: sure - https://marc.info/?l=openbsd-tech&m=142356166731390&w=2 | 13:51 |
| longsleep | Chipaca: also a nice read is https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html | 13:52 |
| longsleep | Chipaca: also agl from Google has some nice writeups about this how its done in Chrome OS | 13:52 |
| Chipaca | jdstrand: thoughts on that? | 13:53 |
| longsleep | Chipaca: here it is, part of a larger discussion: https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/oj2xXq3CF0E/f7BtsfkVhe8J | 13:54 |
| longsleep | Chipaca: I think bug #1504657 is pretty critical, especially as systemd is using google timeservers by default | 13:55 |
| ubottu | bug 1504657 in ubuntu-core-config (Ubuntu) "ntp servers should be configurable on snappy" [Medium,Confirmed] https://launchpad.net/bugs/1504657 | 13:55 |
| Chipaca | longsleep: not in ubuntu | 13:56 |
| longsleep | Chipaca: oh really? I was trying to find a patch for that but could not find it | 13:56 |
| ogra_ | systemd onbly uses google servers for its test | 13:56 |
| Chipaca | longsleep: it's a compile-time setting, and /etc/systemd/timesyncd.conf shows you the compile-time defaults, commented out | 13:56 |
| * Chipaca wrote that filepath from memory, and that's not a good memory | 13:56 | |
| longsleep | Chipaca: ok then, that is slightly better then | 13:56 |
| ogra_ | the actual server used in packages is supposed to be picked by the distros | 13:56 |
| jdstrand | ogra_: I think it is using debian time servers though. that should be changed to ubuntu (but obviously not just for snappy) | 13:57 |
| ogra_ | (and afaik all distros that ship systemd use their own setting here) | 13:57 |
| Chipaca | ntp.ubuntu.com | 13:57 |
| Chipaca | is what's built in | 13:57 |
| ogra_ | jdstrand, yeah, it should be ntp.ubuntu.com for us | 13:57 |
| longsleep | Chipaca: do you have a link to the patching? | 13:57 |
| ogra_ | right | 13:57 |
| ogra_ | longsleep, only LFS wouold use the google servers :) | 13:58 |
| jdstrand | Chipaca: I think it is premature to make tlsdate or openntpd (the OpenBSD version) | 13:58 |
| jdstrand | the default | 13:58 |
| longsleep | jdstrand, Chipaca - i agree with that statement, thats why i ask for a way to disable timesyncd in snappy (by config) and by that make it possible for snaps to provide time synchronization | 13:59 |
| jdstrand | longsleep: I agree it should be disableable | 13:59 |
| Chipaca | yep, and ogra's already looked into it | 13:59 |
| Chipaca | and shouted at me because of the issues each new thing we add to writable brings | 14:00 |
| longsleep | ok cool | 14:00 |
| * ogra_ hugs Chipaca | 14:00 | |
| * Chipaca hugs ogra_ back | 14:00 | |
| ogra_ | i didnt shout :) | 14:00 |
| ogra_ | I NEVER SHOUT !!!! | 14:00 |
| jdstrand | do note, for the moment the templated policy will block setting the time | 14:00 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | time is overrated anyway ... | 14:01 |
| * ogra_ is more for space than for time | 14:01 | |
| Chipaca | jdstrand: did i ever tell you about the switch from @snapd to /run/snapd.socket? | 14:01 |
| jdstrand | no | 14:01 |
| jdstrand | Chipaca: is that live in 15.04 or just for rolling? | 14:01 |
| jdstrand | Chipaca: ie, I need to know where to upload the change | 14:02 |
| longsleep | jdstrand: templated policy means when running unconfined or with an own policy it should work to set the time from a snap right? | 14:03 |
| ogra_ | jdstrand, i think 15.04 is done and wont change much wrt features | 14:03 |
| Chipaca | jdstrand: ok. No big deal, as the only people using it right now are unconfined, but yes i'll get you that info | 14:03 |
| Chipaca | ah, good point | 14:03 |
| Chipaca | jdstrand: just rolling :) | 14:03 |
| jdstrand | longsleep: templated policy means the default policy and shipped policy groups. running unconfined would work. using security-policy would work. | 14:03 |
| * ogra_ expects us to move stable over to 16.04 after feature freeze | 14:04 | |
| longsleep | jdstrand: ok great, thanks for confirming | 14:04 |
| Chipaca | ogra_: i know you didn't shout, i lied. In my defence, it was for effect (?) | 14:04 |
| ogra_ | and til then leave it untouched | 14:04 |
| ogra_ | Chipaca, being the #1 drama queen in the company i think i can appreciate fishing for effect :) | 14:04 |
| jdstrand | longsleep: I am actually revamping security-override to make it more relevant on snappy, so it will be easier to say 'give me the default policy, but with this one extra thing' | 14:05 |
| jdstrand | it would still trigger a manual review | 14:05 |
| longsleep | jdstrand: ah that sounds great | 14:05 |
| jdstrand | but, it will mean that it opens the possibility for a time server with an addition for changing the time to be more easily reviewed and accepted | 14:06 |
| longsleep | Btw, i have another interesting use case for the problem that one snap cannot write to another snap. I have used a framework snap to provide a binary. Now that binary is executed from another snap. Execution works fine, though the runtime environment of that binary is not allowed to store or write files into the environment of the calling snap. Any ideas / thoughts on such a use case? | 14:11 |
| tedg | It seems like the framework shouldn't provide a binary that's expected to be used by other snaps. That binary should be included in those other snaps and communicate with the framework via IPC. | 14:13 |
| longsleep | tedg: yeah i know that this is the indended behavior, though i thought i try to avoid having to ship the very same binary in 20 snaps. | 14:14 |
| tedg | longsleep: Probably not a good optimization overall, fights against the design of the system for a minimal gain. | 14:15 |
| sergiusens | longsleep, what binary is that and maybe doing ipc is better if it is home grown | 14:15 |
| jdstrand | longsleep: you can make it work by adjusting the framework snaps framework-policy to allow the writes you need | 14:15 |
| longsleep | sergiusens: in that case - openssl | 14:15 |
| * sergiusens runs away from openssl | 14:16 | |
| sergiusens | :-) | 14:16 |
| jdstrand | longsleep: just like you added an 'ix' rule to the policy, you would add file rules | 14:16 |
| sergiusens | I'll defer | 14:16 |
| longsleep | jdstrand: yes thats possible, though i am wondering if there might be a better solution | 14:16 |
| longsleep | without having to ship openssl in essentially all the snaps | 14:17 |
| jdstrand | longsleep: well, given the contraint that it must write to the framework snap's dir, no. | 14:17 |
| longsleep | sergiusens: ok, i lied - its actually libressl | 14:17 |
| jdstrand | longsleep: but, a framework shipping binaries is problematic | 14:18 |
| jdstrand | longsleep: if the framework uses shared libs, the calling snap won't have those, so you need to deal with that | 14:18 |
| longsleep | jdstrand: i could do most of the stuff with stdout with openssl and have the calling environment pipe it to a file. Unfortunatly not all commands get that right. | 14:18 |
| * jdstrand nods | 14:18 | |
| longsleep | jdstrand: snapcraft creates a wrapper script which sets the ld paths | 14:18 |
| jdstrand | longsleep: yes, but not for external snaps | 14:19 |
| longsleep | jdstrand: external snaps? what does that mean? | 14:19 |
| jdstrand | longsleep: ie, it will work fine from the shell and from within the snap itself | 14:19 |
| jdstrand | but another snap won't be able to use that wrapper | 14:19 |
| longsleep | oh | 14:19 |
| jdstrand | longsleep: snap foo ships libressl, ship bar uses it | 14:19 |
| longsleep | thats bad then for the stdout apprach as well | 14:19 |
| jdstrand | anything in foo can use it fine | 14:20 |
| jdstrand | bar won't because bar's SNAP_ directories are set to its own paths | 14:20 |
| jdstrand | it can be made to work by shipped a different wrapper that hard codes /apps/foo/current/... in LD_LIBRARY_PATH | 14:21 |
| longsleep | jdstrand: why not? when i call /apps/libressl/bin/libressl-openssl i was assuming that the wrapper script sets it again | 14:21 |
| jdstrand | but like I said, this is all rather ugly. frameworks aren't really meant for this | 14:21 |
| jdstrand | longsleep: look at /apps/libressl/bin/libressl-openssl | 14:22 |
| jdstrand | longsleep: it is using SNAP_APP_PATH | 14:22 |
| jdstrand | anything in foo will have a SNAP_APP_PATH that is /apps/foo/... | 14:22 |
| longsleep | jdstrand: mhm hold on - i think it is setting it | 14:22 |
| jdstrand | anything in bar will have a SNAP_APP_PATH that is /apps/bar | 14:22 |
| longsleep | jdstrand: see http://paste.ubuntu.com/12999228/ thats the wrapper script as generated | 14:23 |
| longsleep | i did not test to run this from another snap, but i think it should just work | 14:23 |
| longsleep | maybe i am missing something | 14:24 |
| jdstrand | longsleep: snapcraft did not create that | 14:24 |
| jdstrand | longsleep: that is what is in /apps/bin | 14:24 |
| longsleep | jdstrand: uhm ok - what created it then? | 14:24 |
| jdstrand | longsleep: snappy install | 14:24 |
| longsleep | ah | 14:24 |
| jdstrand | longsleep: but that isn't what I'm talking about | 14:24 |
| jdstrand | apps cannot call things in /apps/bin | 14:25 |
| longsleep | i see | 14:25 |
| jdstrand | cause that requires calling the privileged launcher to setup a sandbox | 14:25 |
| jdstrand | no sandbox within a sandbox is allowed | 14:25 |
| jdstrand | (it can't work for a lot of reasons) | 14:25 |
| jdstrand | longsleep: what I'm saying is you ship another wrapper | 14:26 |
| longsleep | got it - so to be in line with the framework concept, i would have the libressl snap create some IPC interface and have the other snaps call that. | 14:26 |
| jdstrand | eg, foo ships /apps/foo/current/bin/libressl.external | 14:26 |
| longsleep | ok | 14:26 |
| jdstrand | the bar uses /apps/foo/current/bin/libressl.external | 14:26 |
| jdstrand | /apps/foo/current/bin/libressl.external hardcodes LD_LIBRARY_PATH/whatever else to use /apps/foo/current/usr/lib/... | 14:27 |
| longsleep | jdstrand: and that wraper i would create manually | 14:27 |
| longsleep | =r | 14:27 |
| longsleep | +r | 14:27 |
| jdstrand | you adjust foo's framework-policy to allow executing /apps/foo/current/bin/libressl.external, etc | 14:27 |
| jdstrand | longsleep: you would have to | 14:27 |
| longsleep | jdstrand: got it - great thanks! | 14:28 |
| jdstrand | bar depends on the foo framework and adds foo's framewrok-policy cap to its caps | 14:28 |
| longsleep | yeah - so is that a way how frameworks "could" be used or should i better investigate a more general approach on sharing binaries between snaps? | 14:29 |
| jdstrand | longsleep: it can be made to work, but you'll see that it is not 'the snappy way'. the 'snappy way' is create a service that apps can consume via network, dbus or unix socket | 14:29 |
| longsleep | jdstrand: all right, i might try that then and see how it goes :) | 14:30 |
| longsleep | jdstrand: is there some example for this somewhere? | 14:30 |
| jdstrand | longsleep: it is the only way to share binaries in the traditional sense of executing them. a service could be in place to do it though. eg, setup a socket then pipe commands over it for the server to process | 14:30 |
| jdstrand | longsleep: no, it isn't the snappy way :) | 14:31 |
| jdstrand | it is important to keep in mind that frameworks are not meant as a general purpose way to ship libraries (and by extension binaries). it is a different paradigm than debs | 14:32 |
| jdstrand | longsleep: another thought, you might find it easier if the framework snap's binaries that you expose in framework-policy are statically linked | 14:33 |
| longsleep | jdstrand: yeah i get that - though i still feel the need to share some things wto avoid duplicating so much. | 14:33 |
| longsleep | jdstrand: true, libressl is easy to link statically. | 14:33 |
| longsleep | others might be not so easy | 14:33 |
| jdstrand | I believe tedg can comment on duplication. I'll just say that it the issue is understood and that people are thinking about how to improve it | 14:34 |
| longsleep | jdstrand: btw, you mentioned unix sockets, i have another snap providing one - problem is that there was no non persistent location which i could use in the past like /run or something. Do you know if that has changed? | 14:35 |
| longsleep | jdstrand: or where do you suggest to put the socket files? | 14:35 |
| jdstrand | longsleep: by definition apps are isolated from each other, so no, there is no shared dir for that sort of thing | 14:36 |
| jdstrand | longsleep: a framework can simply expose it via framework-policy | 14:36 |
| === Guest42341 is now known as francksolo | ||
| jdstrand | apps within the same snap are free to use and access SNAP_APP_DATA_PATH | 14:36 |
| jdstrand | a framework snap would put a named socket in its SNAP_APP_DATA_PATH and have framework-policy allow access to it | 14:37 |
| longsleep | jdstrand: yes that is what i meant. That is a persistent location. There should be a temporary location similar to that so apps from the same snap can access the socket. | 14:37 |
| longsleep | jdstrand: i tried to put it in /tmp earlier until i discovered that this folder is per process | 14:37 |
| jdstrand | there are also abstract sockets-- but those are mediated too (same process as for named sockets) | 14:37 |
| jdstrand | longsleep: oh, use, to have it removed on reboot. there is a path in /run that is app specific | 14:38 |
| * jdstrand fins it | 14:38 | |
| jdstrand | finds* | 14:38 |
| longsleep | jdstrand: yeah i mentioned this a couple of months back, i lost track of it - maybe someone has added it in the meantime. | 14:39 |
| jdstrand | /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/* | 14:39 |
| longsleep | jdstrand: I think sockets or anything else which is used for IPC should be there and not in SNAP_APP_DATA_PATH | 14:39 |
| longsleep | jdstrand: cool thanks - i will try that asap | 14:40 |
| jdstrand | I'm not sure the launcher is creating /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/ though. if not that is a bug | 14:40 |
| jdstrand | longsleep: you can also use an abstract socket | 14:40 |
| jdstrand | create it as @<pkgname>_... and processes within the same snap can use it | 14:41 |
| jdstrand | (we have this rule for that: unix peer=(label=@{APP_PKGNAME}_*),) | 14:41 |
| longsleep | jdstrand: That works with the normal c level socket code? I want to avoid patching upstream code. | 14:42 |
| * longsleep does no nothing about abstract sockets | 14:42 | |
| * longsleep reads about it now | 14:42 | |
| jdstrand | abstract sockets are something that is available to standard Linux and all major languages on Linux support it, yes | 14:43 |
| jdstrand | longsleep: man unix | 14:43 |
| jdstrand | it requires patching the code though, but in a minor way | 14:44 |
| longsleep | jdstrand: ok - i will investigate on this. Thanks for all your help an suggestions! | 14:44 |
| jdstrand | np | 14:44 |
| elopio | I hurt my back yesterday. As of today, I'm officially old. | 14:48 |
| jdstrand | longsleep: one more item for food for thought> there is a coupling between an app and its depenedent framework regardless. with a service and IPC protocol (network, unix, dbus) the coupling is limited to the protocol itself. if you introduce binaries and shared libraries, there is a much tighter coupling that would likely be brittle. this is something snappy attempts to solve, which is part of why doing the shared binaries approach is not the snappy | 14:49 |
| elopio | Chipaca: what do you do to test your first boot branch? unpack the .img and overwrite some files there? | 14:50 |
| longsleep | jdstrand: yeah - i agree on the idea. Though in some situations it might be overkill and sharing a binary might be much easier. | 14:50 |
| Chipaca | elopio: that would work. On the other hand, mvo just went ahead and merged it :) | 14:50 |
| elopio | Chipaca: I saw that. I was just wondering how to avoid waiting until a new image is generated. | 14:51 |
| jdstrand | longsleep: I agree there might be times, particularly with a static binary or shell script | 14:52 |
| longsleep | longsleep: I will for sure make a snap with a IPC service to check it out and get some ideas. | 14:52 |
| Chipaca | elopio: you could boot, remount rw, replace snappy and the firstboot .service files, remove the eth file and the firstboot stamp file, and reboot | 14:56 |
| elopio | ah, there's a firstboot stamp file. That will be handy. | 15:00 |
| mvo | Chipaca, elopio: I'm not sure I follow, but would it help if I create a new image for you guys? | 15:01 |
| elopio | mvo: yes, please. | 15:01 |
| Chipaca | elopio: /var/lib/snappy/firstboot/stamp | 15:01 |
| mvo | elopio: a 16.04 image I presume? | 15:09 |
| elopio | mvo: rolling, please. | 15:09 |
| jdstrand | Chipaca: fyi, upload snapd.socket change | 15:19 |
| jdstrand | uploaded* | 15:20 |
| Chipaca | jdstrand: muchas gracias | 15:20 |
| ogra_ | mvo, hmm, looks like two image builds of wily you did exploded | 15:29 |
| mvo | ogra_: yes | 15:29 |
| mvo | ogra_: I just asked in #launchpad | 15:30 |
| ogra_ | ah, k | 15:30 |
| mvo | <mvo> hm, I get build failures in the livefs build for https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image with "?: keyserver.ubuntu.com: Connection refused". or is that a red herring? | 15:30 |
| ogra_ | ?: keyserver.ubuntu.com: Connection refused | 15:30 |
| ogra_ | gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused | 15:31 |
| ogra_ | gpg: no valid OpenPGP data found. | 15:31 |
| ogra_ | yeah, looks like some bad network connection | 15:31 |
| ogra_ | mvo, btw, why are the dailies disabled for 15.04 ? | 15:31 |
| ogra_ | i thought we ant to get security and SRU fixes automatically into 15.04 edge | 15:31 |
| ogra_ | was that a concious decision or just an oversight ? | 15:32 |
| mvo | ogra_: I don't know why they are disabled, not done by me | 15:32 |
| ogra_ | ah, k | 15:33 |
| mvo | ogra_: I wish we had a easier way to track this :/ | 15:33 |
| ogra_ | yes | 15:33 |
| mvo | i.e. why stuff happened in the shared account | 15:33 |
| ogra_ | well, usually it has a bzr record ... crontab is a bit special though | 15:33 |
| ogra_ | (since there are often temporary changes) | 15:34 |
| * mvo nods | 15:34 | |
| longsleep | We just found a critical issue with ubuntu-snappy.firstboot.service - it fails to run when the a preinstalled snap is configured (Oct 29 15:26:16 localhost.localdomain snappy[808]: config failed with: 'aa-exec: ERROR: profile 'spreed-webrtc.sideload_snappy-config_IENQKIBcWPBJ' does not exist) - anyone can tell me if that is an error on our end? I added bug #1511435 | 15:36 |
| ubottu | bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Undecided,New] https://launchpad.net/bugs/1511435 | 15:36 |
| Chipaca | longsleep: looking | 15:38 |
| mvo | elopio: a new image of rolling finished building 1min ago :) needs to get imported into the system-image server now, then its ready for you to test | 15:45 |
| kyrofa | Hey ogra_ do you know what kernel config we're using for squashfs? | 15:47 |
| ogra_ | there are kernel configs for squashfs (beyond turning it on/off in the kernel ?) | 15:47 |
| kyrofa | ogra_, so many... | 15:48 |
| ogra_ | really ? | 15:48 |
| kyrofa | ogra_, http://lxr.free-electrons.com/source/fs/squashfs/Kconfig | 15:48 |
| ogra_ | wow, that grew quite a lot ... | 15:49 |
| kyrofa | ogra_, they aren't required, but I thought maybe we were tuning the cache size for embedded platforms? | 15:49 |
| ogra_ | no, i dont, but the kernel config file should tell you | 15:49 |
| ogra_ | just check on a desktop in /boot/config-* ... | 15:49 |
| kyrofa | ogra_, ah, so the config is the same? | 15:49 |
| ogra_ | the kernel is the same | 15:49 |
| kyrofa | Okay good deal | 15:49 |
| kyrofa | ogra_, thank you! | 15:50 |
| fgimenez_ | Chipaca, about the login test https://github.com/ubuntu-core/snappy/compare/master...fgimenez:cli-login-test | 15:55 |
| fgimenez_ | Chipaca, you can try it with go run _integration-tests/main.go -snappy-from-branch -filter loginSuite.* -revision 208 | 15:55 |
| rickspencer3 | if I have my Go code in launchpad, how do I go about telling snapcraft how to go get it? Or is that not supported/possible? | 15:59 |
| longsleep | Chipaca: the firstboot service is very picky - it also fails with things like: main.go:57: DEBUG: [/usr/bin/snappy firstboot] failed: configuring an invalid snappy package | 16:01 |
| longsleep | Chipaca: i suggest to make things like that non fatal | 16:02 |
| Chipaca | longsleep: agreed, especially given that the error is essentially invisible, and all that'll happen is that you won't get an eth device or whatever | 16:03 |
| Chipaca | oh, wait | 16:03 |
| Chipaca | yes you do | 16:03 |
| elopio | rickspencer3: take a look at examples/gopaste. Just instead of git:... use lp:... | 16:03 |
| Chipaca | longsleep: what's the consequence of the failure you're seeing? | 16:03 |
| rickspencer3 | elopio, I think I tried that, do you have a link where I can see the examples? | 16:03 |
| Chipaca | fgimenez_: what am I looking at here? | 16:04 |
| Chipaca | fgimenez_: this is whaty i get; http://pastebin.ubuntu.com/12999856/ | 16:04 |
| elopio | rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/gopaste/snapcraft.yaml | 16:04 |
| fgimenez_ | Chipaca, you should first get the branch with the changes, https://github.com/fgimenez/snappy/tree/cli-login-test | 16:06 |
| fgimenez_ | or apply the diff to master | 16:06 |
| Chipaca | ahh :) | 16:06 |
| rickspencer3 | elopio, ok, thanks, but I meant an example that uses launchpad | 16:07 |
| fgimenez_ | yep, sorry for not being clear :) | 16:07 |
| elopio | rickspencer3: we don't have an example that uses both go and launchpad | 16:07 |
| elopio | rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/libpipeline/snapcraft.yaml | 16:07 |
| longsleep | Chipaca: well, i am not sure about the consequence - we are experimenting with providing config and snaps via oem snap and i am reporting issues which appear. | 16:08 |
| rickspencer3 | elopio, ok, that shows that source: uses the same syntax as bzr for lp:~ blah blah blah | 16:09 |
| rickspencer3 | which is groovy, but it doesn't for me with Go | 16:09 |
| * rickspencer3 files bug | 16:09 | |
| Chipaca | longsleep: thank you. Please do also file a bug for the "any config makes firstboot fail" bug | 16:10 |
| Chipaca | longsleep: you only see that failure because you're actively searching for it, yes? | 16:10 |
| elopio | rickspencer3: thanks. I only see a piece of code that's different in the go plugin, that might be the problem. | 16:10 |
| elopio | I'll take a look. | 16:10 |
| longsleep | Chipaca: Well, no - its not that i am searching for bugs :) | 16:10 |
| Chipaca | longsleep: i mean, the system boots and works as you'd expect? | 16:11 |
| francksolo | :'( you people broke personal | 16:11 |
| longsleep | Chipaca: except that the stuff i wanted to test from the OEM snap (config, and snap) did not work yes. | 16:11 |
| ogra_ | francksolo, ? | 16:11 |
| longsleep | Chipaca: not sure what else might be not applied if the service fails like this | 16:11 |
| francksolo | ogra_, the mouse input doesn't register :)) | 16:11 |
| ogra_ | francksolo, you are aware that this is the snappy channel ? | 16:12 |
| francksolo | ogra_, i can click on the login input 4 ever and nothing | 16:12 |
| ogra_ | we dont do personal | 16:12 |
| Chipaca | longsleep: once one config fails, all configs that come later won't be applied | 16:12 |
| francksolo | ogra_, isn't personal snappy based? | 16:12 |
| ogra_ | (well, there was a one shot experimental image to test the build infrastructure, but thats about it) | 16:12 |
| Chipaca | francksolo: only snappy ubuntu core is supported | 16:12 |
| Chipaca | francksolo: snappy personal is a sporadic experiment | 16:12 |
| longsleep | Chipaca: ok that makes sense, so s comes before u, means ubuntu-core config will also not be applied | 16:13 |
| francksolo | oooooo but the ubuntu roadmap graph | 16:13 |
| ogra_ | snappy personal will surely exist one day ... but that day is far out | 16:13 |
| ogra_ | francksolo, you mean the phone roadmap ? | 16:13 |
| francksolo | :'( | 16:13 |
| Chipaca | longsleep: from looking at the code i would say the order is the one you defined in the oem yaml | 16:13 |
| ogra_ | pocket desktop is different from "personal snappy PC image" | 16:13 |
| francksolo | ogra http://i.imgur.com/plQvwch.jpg | 16:14 |
| Chipaca | francksolo: that very thin line is where we are now | 16:14 |
| francksolo | so.. desktop next is dead, personal is nowhere :( | 16:14 |
| francksolo | :'( x10000 | 16:15 |
| Chipaca | francksolo: "desktop next is dead"? | 16:15 |
| Chipaca | sigh | 16:15 |
| francksolo | yep, 404 | 16:15 |
| Chipaca | francksolo: you probably want dpm | 16:15 |
| longsleep | Chipaca: the other bug also added as #1511448 | 16:15 |
| Chipaca | unless i've got my faces wrong | 16:15 |
| longsleep | bug #1511448 | 16:15 |
| ubottu | bug 1511448 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains config for snaps not preinstalled, built-in" [Undecided,New] https://launchpad.net/bugs/1511448 | 16:15 |
| ogra_ | francksolo, as you can see the merge only happens in 16.10 (or even after) | 16:15 |
| Chipaca | longsleep: much appreciated sah | 16:16 |
| ogra_ | francksolo, for 16.04 ubuntu personal isnt a thing | 16:16 |
| francksolo | yeah.. but i need somehing to play with until 16.10 :D | 16:16 |
| elopio | yes, this is busted. | 16:16 |
| * francksolo n4 or the pd | 16:17 | |
| ogra_ | francksolo, just install 15.10 and install the Mir session | 16:17 |
| francksolo | 15.10 is dead | 16:17 |
| francksolo | for unity8 (you will not get updates) | 16:18 |
| francksolo | vivid or xenial | 16:18 |
| francksolo | ogra_, unity8 mir session is nice but it's not desktop next | 16:19 |
| ogra_ | well, then take a n4 and install all the bits you need | 16:19 |
| francksolo | you can't install apps from the store | 16:19 |
| francksolo | ogra_, yeah | 16:19 |
| ogra_ | though thats more appropriate for #ubuntu-touch :) | 16:20 |
| francksolo | nah :D i like this channel more | 16:20 |
| * francksolo #snappy is fantastic | 16:20 | |
| francksolo | ok. sorry for spam :D | 16:20 |
| kyrofa | francksolo, you can't make a personal image from ubuntu-device-flash? | 16:20 |
| ogra_ | then you have to start talking about headless stuff :) | 16:20 |
| ogra_ | kyrofa, no | 16:21 |
| ogra_ | kyrofa, it was disabled | 16:21 |
| kyrofa | ogra_, ah, I didn't realize that | 16:21 |
| ogra_ | the iage we had was just a proof of concept ... it wasnt supposed to even persist that long | 16:21 |
| ogra_ | *image | 16:21 |
| ogra_ | non-phone-personal images will be a thing in 16.10 ... but not before | 16:22 |
| Chipaca | fgimenez_: do you know how i can merge your repo to mine in git? | 16:24 |
| * Chipaca habla poco git | 16:24 | |
| longsleep | Chipaca: git pull --no-ff git@github.com:some.git somebranch | 16:27 |
| Chipaca | longsleep: m'kay ... | 16:28 |
| * Chipaca tries | 16:28 | |
| longsleep | Chipaca: usually you create a local branch frist and merge there for review and local changes and then merge into that local branch, review and fix up and then merge that fixed up branch to whatever branch you want to continue | 16:29 |
| elopio | sergiusens: tedg: please put this one high on your backlog: https://bugs.launchpad.net/snappy/+bug/1511447 | 16:31 |
| ubottu | Launchpad bug 1511447 in Snappy "snapcraft stage does not work with Go and Launchpad" [Undecided,Confirmed] | 16:31 |
| rickspencer3 | elopio, I assume I am doing something wrong, but I logged a bug anyway, if you want to take a look: https://bugs.launchpad.net/snappy/+bug/1511447 | 16:32 |
| ubottu | Launchpad bug 1511447 in Snappy "snapcraft stage does not work with Go and Launchpad" [Undecided,Confirmed] | 16:32 |
| elopio | rickspencer3: it's not you, it's us :) | 16:32 |
| rickspencer3 | very rarely the case, but ... sure ;) | 16:33 |
| Chipaca | fgimenez_: now i'm getting http://pastebin.ubuntu.com/13000131/ | 16:33 |
| Chipaca | fgimenez_: is that what you wanted me to see and look at? | 16:33 |
| fgimenez_ | Chipaca, yes, that "inappropriate ioctl for device" and "broken pipe" | 16:34 |
| === davidcalle is now known as davidcalle|afk | ||
| Chipaca | fgimenez_: right. If you really need to test that, you're going to need something that looks a lot more like a terminal :) | 16:36 |
| Chipaca | fgimenez_: how's it being run now? | 16:36 |
| Chipaca | fgimenez_: you exec.Command("snappy", "login") ? | 16:37 |
| fgimenez_ | Chipaca, :) yes, including the loginName, in setupInteractiveCmd | 16:38 |
| fancycode | Hi, I'm building an image using a custom oem and additional built-in snaps. The oem snap specifies "architecture: armhf" but the architecture of the additional snaps is checked against the architecture of my host machine ("amd64") so "ubuntu-device-flash" fails with "package's supported architectures (armhf) is incompatible with this system (amd64)". Is there a way to specifiy the arch as parameter to "ubuntu-device-flash"? (for now I removed the chec | 16:51 |
| fancycode | k in snapp.go and rebuilt the tool) | 16:51 |
| Chipaca | fancycode: yeah, bug in u-d-f | 16:52 |
| Chipaca | fancycode: i think sergiusens knows about it, but check with him just in case | 16:53 |
| Chipaca | Facu found it the other day | 16:53 |
| Chipaca | at least, that's when i found out about it | 16:53 |
| Chipaca | fgimenez_: so | 16:53 |
| fancycode | Another thing: I added "load-kernel-modules: [X, Y]" to the ubuntu-core conf in my oem snap, now the firstboot service fails with "/usr/bin/snappy[799]: main.go:57: DEBUG: [/usr/bin/snappy firstboot] failed: open /etc/modules-load.d/ubuntu-core.conf.tmQQxGVXiMGK: read-only file system". Anything I need change in my snap? | 16:56 |
| longsleep | fancycode: I just added bug #1511464 for this | 16:57 |
| ubottu | bug 1511464 in Snappy "/etc/modules-load.d missing from writable-paths, used by snappy firstboot " [Undecided,New] https://launchpad.net/bugs/1511464 | 16:57 |
| fancycode | longsleep: thanks | 16:57 |
| ogra_ | longsleep, no, it isnt missing from writable paths ... | 16:57 |
| longsleep | ogra_: no? its not in my writable-paths | 16:58 |
| ogra_ | it is another one of these "snappy atomic write" issues that forces us away from using writable paths at all | 16:58 |
| ogra_ | hmm, i thought i added it to rolling | 16:58 |
| longsleep | ah rolling | 16:58 |
| longsleep | we are using 15.04/stable for now | 16:58 |
| ogra_ | still | 16:58 |
| Chipaca | fgimenez_: http://pastebin.ubuntu.com/13000343/ | 16:59 |
| Chipaca | fgimenez_: you need an actual tty, e.g. via a pty | 16:59 |
| ogra_ | all config options that snappy uses use that atomic write and are thus not working with writable paths | 16:59 |
| Chipaca | fgimenez_: that ^ is how you'd go about that | 16:59 |
| Chipaca | fgimenez_: (the io.Copy is me just being lazy at the end; a second f.Read() works) | 16:59 |
| Chipaca | fgimenez_: the \n after the password is very important :) otherwise it hangs forever, as expected | 17:00 |
| longsleep | ogra_: ok, but writing to /etc/modprobe.d works just fine from firstboot - or is there some other mechanism involved there? | 17:00 |
| Chipaca | fgimenez_: github.com/kr/pty is already packaged in ubuntu, fwiw | 17:00 |
| Chipaca | fgimenez_: golang-pty-dev | 17:00 |
| ogra_ | longsleep, not from snappy config | 17:00 |
| fgimenez_ | Chipaca, great thanks a lot, i'll try it, should it be added to the dependencies? | 17:01 |
| ogra_ | longsleep, snappy configs atomic write actually requires that we re-locate the whole dir and link it or re-loactae the whole file and link it | 17:01 |
| fgimenez_ | Chipaca, swordfish, the better marxist password ever :D | 17:01 |
| ogra_ | which kind of defeats the purpose of writable-paths being bind mounts | 17:01 |
| fancycode | sergiusens: I found a bug in u-d-f where the architecture of built-in oem snaps is checked against the arch of the host instead of the oem snap, causing "package's supported architectures (armhf) is incompatible with this system (amd64)". Chipaca told me you might know about it? | 17:01 |
| longsleep | ogra_: ok - so what should we do then - to load kernel modules on boot? | 17:02 |
| ogra_ | longsleep, hack it into the buuld system to force moving of the dir to a writable location and then create a ton of links for all files in there | 17:02 |
| Chipaca | ogra_: i've got too much on my plate today, but tomorrow morning maybe we have a chat about writable paths a bit? figure out if we can have the pig and the sausage | 17:04 |
| Chipaca | i hear tofu sausages are not completely horrible | 17:04 |
| ogra_ | Chipaca, yeah, that would help ... i mean, i dont mind dropping writable-paths if we find anything better .... the current situation starts to get awkward though | 17:05 |
| sergiusens | fancycode, the oem snap should be arch all though | 17:05 |
| Chipaca | ogra_: fwiw by the pig and the sausage i mean atomic writes and 3-may merges on update. Which is which I don't know :) | 17:05 |
| ogra_ | Chipaca, hmm, though i'm a bit confused, i thought it worked in 15.04 ... | 17:05 |
| ogra_ | iirc it was even actually tested when landing | 17:06 |
| sergiusens | fancycode, or we need to add yet another switch to u-d-f to query the store for it beating the purpose | 17:06 |
| Chipaca | ogra_: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001102.html | 17:06 |
| fancycode | sergiusens: sorry, the oem snap result is arch all, however inside it specifies oem -> hardware -> architecture: armhf | 17:07 |
| ogra_ | now ... if my firefox wouldnt totally act up | 17:07 |
| ogra_ | grrr | 17:07 |
| Chipaca | ogra_: lynx -dump ftw ;) | 17:08 |
| ogra_ | heh | 17:08 |
| ogra_ | https://launchpadlibrarian.net/223054208/ubuntu-core-config_0.6.15%2Bppa24_0.6.15%2Bppa25.diff.gz | 17:09 |
| ogra_ | so this definitely landed in 15.04 | 17:09 |
| Chipaca | fgimenez_: wrt dependencies, yes, if you go with this solution it should be added to the dependencies.tsv (and to debian/control's build-dependens if/when we run integration suite from buildpackage) | 17:09 |
| Chipaca | ogra_: ah, yes, the problem is the atomic | 17:10 |
| ogra_ | so yeah, another atomic write | 17:10 |
| Chipaca | yeh | 17:10 |
| ogra_ | Chipaca, right, i was just not sure it had landed in 15.04 | 17:10 |
| longsleep | cat /etc/system-image/writable-paths |grep modules | 17:10 |
| longsleep | (i see nothing) | 17:10 |
| ogra_ | especially because longsleep calims he doesnt have the dir in writavble-paths | 17:10 |
| Chipaca | maybe longsleep is using ancient software | 17:10 |
| Chipaca | like pre-last-week | 17:11 |
| longsleep | maybe | 17:11 |
| Chipaca | :) | 17:11 |
| longsleep | actually it might be true again :D | 17:11 |
| ogra_ | hah | 17:11 |
| longsleep | but fancycode is not using ancient software | 17:11 |
| ogra_ | well, it wont fix you :) | 17:11 |
| longsleep | i current have ubuntu-core 2015-10-13 196 | 17:11 |
| ogra_ | the dir is writable but the tool cant write | 17:11 |
| longsleep | which might be a little old | 17:11 |
| ogra_ | ancient | 17:12 |
| longsleep | but fancycode has 9 (stable) and also does not see the patch you linked | 17:12 |
| ogra_ | weird, iirc the release was held back for it to land | 17:13 |
| Chipaca | longsleep: i suspect the preinstalled codepath has a lot less testing than we'd like. I'll have to dig into that. | 17:14 |
| Chipaca | longsleep: tomorrow or maybe next week... | 17:14 |
| Chipaca | longsleep: how urgent is this for you? | 17:14 |
| fancycode | I'm running ubuntu-core-config 0.6.15+ppa24 | 17:14 |
| longsleep | Chipaca, ogra_ reason is that 9/stable has 0.6.15+ppa24 and the patch is for 0.6.15+ppa25 | 17:14 |
| fancycode | so that's one version too old then, right? | 17:14 |
| ogra_ | yeah | 17:14 |
| ogra_ | the release was on the 23rd | 17:14 |
| ogra_ | the patch only landed on the 27th | 17:15 |
| Chipaca | /o\ | 17:15 |
| longsleep | ok so its already fixed and the next release will have it - all good then | 17:15 |
| longsleep | Chipaca: got me again, i am running 0.6.15+ppa22 :D | 17:15 |
| fgimenez_ | Chipaca, works like a charm thanks! :) | 17:17 |
| longsleep | Chipaca: If it eventually works then its fine. So next week no problem. | 17:19 |
| Chipaca | longsleep: wrt that package in oem, you're getting it preinstalled from the store, or from local fs? | 17:22 |
| longsleep | Chipaca: local fs | 17:22 |
| Chipaca | longsleep: in other words, is it right to be 'sideload' | 17:22 |
| Chipaca | ah, ok | 17:22 |
| Chipaca | phew :) | 17:22 |
| longsleep | Chipaca: yes it is sideloaded | 17:22 |
| longsleep | Chipaca: its not found in the store, because the package is armhf only and u-d-f does not find those | 17:23 |
| Chipaca | gaarhgh | 17:23 |
| Chipaca | longsleep: sorry :( | 17:23 |
| fancycode | Chipaca: that's most likely also because I'm building on an amd64 host, maybe can try on an armhf tomorrow | 17:24 |
| longsleep | Chipaca: well - fancycode is having all the fun with it :) | 17:24 |
| fancycode | longsleep: haha :-/ | 17:24 |
| Chipaca | yes, it's because u-d-f is not calling SetArch before installing | 17:25 |
| Chipaca | it's a silly fix, but somebody needs to do it :) | 17:25 |
| fancycode | Chipaca: is that "SetArchitecture" from snappy/arch.go? | 17:26 |
| Chipaca | yep | 17:26 |
| fancycode | ok, I might be able to take a look tomorrow | 17:27 |
| longsleep | ogra_: So i guess you can close bug #1511464 as you already fixed it and it will be released eventually. | 17:27 |
| ubottu | bug 1511464 in Snappy "/etc/modules-load.d missing from writable-paths, used by snappy firstboot " [Undecided,New] https://launchpad.net/bugs/1511464 | 17:27 |
| ogra_ | longsleep, no, it isnt fixed | 17:28 |
| ogra_ | i mean, it is in writable-paths ... but wont be usable yet | 17:28 |
| ogra_ | we'll have a discussion about a proper fix tomorrow | 17:28 |
| longsleep | ogra_: ok great | 17:29 |
| Chipaca | longsleep: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001124.html | 17:52 |
| john-mcaleely | ogra_, are there plans for snappy on the raspberry pi to expose things like the SPI bus in the connector to app snaps? | 18:09 |
| john-mcaleely | maybe that already works? | 18:09 |
| ogra_ | yeah, it does | 18:10 |
| john-mcaleely | yay! | 18:10 |
| john-mcaleely | must play more with mine, I guess | 18:10 |
| ogra_ | you might need to adjust bits in config.txt for finer grained stuff, but in general everything you might want should be there or easy to enable | 18:10 |
| john-mcaleely | sure, that's cool | 18:11 |
| pindonga | sergiusens, is there a way to exclude files in the snap stage, or just to include? | 19:06 |
| pindonga | (in snapcraft) | 19:06 |
| sergiusens | pindonga, get snapcraft 0.4 (apt update) and then run 'snapcraft help plugins' | 19:09 |
| sergiusens | pindonga, shorter answer is with a preceding '-' | 19:09 |
| pindonga | ack | 19:10 |
| pindonga | tx | 19:10 |
| === davidcalle|afk is now known as davidcalle | ||
| pindonga | sergiusens, the bug you asked: https://bugs.launchpad.net/snapcraft/+bug/1511440 | 20:41 |
| ubottu | Launchpad bug 1511440 in Snapcraft "python based package created using external symlink" [Undecided,New] | 20:42 |
| * pindonga just noticed the title was wrong and updated it | 20:42 | |
| tedg | What is the bazaar plugin to do fastimport/export ? | 20:50 |
| rickspencer3 | so, I want to make a snap that is not a service, but runs like an app | 20:52 |
| rickspencer3 | i.e. you ssh in and run a command | 20:52 |
| rickspencer3 | anyone have an example of snapcraft doing that? | 20:52 |
| tedg | rickspencer3: binaries is the header | 20:52 |
| rickspencer3 | binaries instead of services? | 20:52 |
| rickspencer3 | that sounds easy | 20:52 |
| tedg | https://gist.github.com/ted-gould/304a3a828baaaaed272f | 20:52 |
| rickspencer3 | hey tedg, this snaps up no problem, but ... | 21:18 |
| tedg | Heh, then my job is done :-) | 21:19 |
| rickspencer3 | but then when I use it in the kvm instance, it says it can't find zork? | 21:19 |
| rickspencer3 | http://pastebin.ubuntu.com/13002903/ | 21:19 |
| tedg | Like literally zork? | 21:19 |
| rickspencer3 | tedg, mind taking a quick look? | 21:19 |
| rickspencer3 | yeah | 21:19 |
| tedg | Oh, I see. I was confused :-) | 21:19 |
| rickspencer3 | yeah, well, without the link, it was a pretty confusing question ;) | 21:19 |
| tedg | rickspencer3: Is there a zork1.zork in /apps/bin ? | 21:20 |
| rickspencer3 | no | 21:20 |
| rickspencer3 | tedg, no | 21:21 |
| rickspencer3 | is that what I need? | 21:21 |
| rickspencer3 | make a bash file and put it there? | 21:21 |
| tedg | Hmm, yeah, but snappy should build it for you. | 21:21 |
| tedg | Is there a "binaries" in /apps/zork1/current/meta/package.yaml ? | 21:21 |
| rickspencer3 | um | 21:22 |
| rickspencer3 | tedg, yes | 21:22 |
| rickspencer3 | it has the exec like I wrote it in snapcraft.yaml | 21:23 |
| rickspencer3 | and a ... name:zork | 21:23 |
| rickspencer3 | well .. name: zork | 21:23 |
| tedg | Yeah, that seems right. It should be roughly your snapcraft.yaml without the "parts" section. | 21:23 |
| rickspencer3 | tedg, but I never made an actual file called "zork" anywhere | 21:24 |
| tedg | rickspencer3: I don't think it'll be "zork", but it'll be "zork1.zork" ($pkg.$bin) | 21:25 |
| rickspencer3 | tedg, ok, so I did zork1.zork, and got an error like: binary must be inside /apps/zork1.sideload/ or /oem/zork1.sideload | 21:26 |
| tedg | I think that snappyd is the person that is supposed to create that script. | 21:27 |
| tedg | Hmm, sorry rickspencer3 I'm not sure what could be up there. | 21:29 |
| tedg | Snappy should be making the shell script wrapper based on the binaries | 21:29 |
| rickspencer3 | tedg, I think my VM is not up to date on snappy | 21:30 |
| rickspencer3 | maybe if I force it to the last stable 15.04 release? | 21:30 |
| tedg | Sure, you shouldn't have to force it, it should upgrade itself unless you turned that off. | 21:31 |
| tedg | sudo snappy upgrade to upgrade | 21:31 |
| tedg | snappy list should show your version. | 21:31 |
| tedg | ubuntu-core 2015-10-23 9 ubuntu | 21:31 |
| rickspencer3 | tedg, well, it keeps telling me that it is going to reboot later :) | 21:33 |
| tedg | Heh | 21:34 |
| rickspencer3 | hmmm | 21:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
