/srv/irclogs.ubuntu.com/2015/10/29/#snappy.txt

sergiusenselopio, hmm00:00
sergiusenselopio, do you have ntfs-3g installed on vivid?00:02
sergiusenselopio, and wily00:02
elopiosergiusens: yes, on both.00:02
elopiofailed again on vivid. Trying on wily.00:02
elopiotedg: where can I find your ginac example?00:03
sergiusenselopio, can you open a bug for the ntfs thing?00:12
elopiosergiusens: yes. still trying to understand what it's trying to install on vivid.00:12
elopiosergiusens: https://bugs.launchpad.net/snapcraft/+bug/151116100:30
ubottuLaunchpad 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
sergiusenselopio, care to try this http://paste.ubuntu.com/12995475/00:36
sergiusenselopio, that function still seems to have legacy from the whole return True/False era; not going to fix that now though...00:37
elopiosergiusens: that fails the same.00:44
sergiusenselopio, really?00:44
elopioreally00:46
sergiusenselopio, can you apply this //paste.ubuntu.com/12995549/00:46
sergiusensI eventually forgot to add the command line switch for that to show :-/00:46
elopiosergiusens: paste.ubuntu.com/12995571/00:49
elopiosergiusens: 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
sergiusenselopio, ok, I fix the wrong location :-)00:51
sergiusenselopio, https://code.launchpad.net/~sergiusens/snapcraft/1511161/+merge/27607502:08
tedgelopio: http://pastebin.ubuntu.com/12862605/02:55
tedgI should probably put that in a gist, that's what the cool kids do.02:59
tedghttps://gist.github.com/ted-gould/304a3a828baaaaed272f03:00
* tedg is bad ass with color highlighting03:01
sergiusenstedg, 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
pittiChipaca:  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
pittiChipaca: 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
pittiChipaca: or e. g a firewall would say "I need to run *before* starting any services on the network" (Before=network-pre.target)07:22
Chipacapitti: i need to run before the network is started, but after the filesystem is mounted07:32
pittiChipaca: so sounds like Before=network.target then07:34
pittiChipaca: if your service has DefaultDependencies=no (i. e. early boot), then also After=local-fs.target07:35
pittibut services without that (i. e. the implied DefaultDependencies=yes) always have local-fs.target already07:35
Chipacapitti: won't that get me in a race with networking.service?07:36
pittiChipaca: oh, you need to run before that too? well, then you need DefaultDependencies=no, Before=network-pre.target07:38
pittiChipaca: I'd really stick to targets; note that networking.service is just ifupdown, that might change etc.07:39
Chipacapitti: i'll give that a try, thank you very much!07:41
Chipacabut after breakfast. first things first :)07:41
pittiChipaca: man systemd.special explains these targets and what they do, btw07:41
pittiChipaca: absolutely! :)07:41
mvoChipaca: 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 them07:59
mvoChipaca: have not looked in detail yet, just wanted to share it for now08:00
dholbachgood morning08:04
mvofgimenez: 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
mvohey dholbach08:04
fgimenezmvo, hey, of course helps thx! :) btw, could you add me to the team, pls?08:06
Chipacamvo: thank you for the heads up. I'm still in why-does-the-bbb-not-have-ipv4 mode here.08:07
fgimenezogra_, rolling/edge 212 boots ok but ens3 is down on first boot08:19
Chipacafgimenez: yeh, that's probably my fault08:21
Chipacabut figuring it out on the bbb first08:22
fgimenezChipaca, ah ok :)08:22
clobranomvo: thank you for the branch on github08:29
mvoclobrano: your welcome!08:31
guest123124error while executing external command kpartx -ds personal_x86.img: device-mapper: remove ioctl on loop0p5 failed: Device or resource busy08:41
guest123124loop deleted : /dev/loop008:41
guest123124got this error while flashing ubuntu personal08:41
fgimenezmvo, thx! :)08:43
fgimenezmvo, 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.0408:54
mvofgimenez: interessting, that hasn't changed :/ or it should not09:00
mvoelopio, 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_error09:01
mvoelopio, 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 know09:02
fgimenezmvo, ok thanks a lot09:03
mvoyour welcome!09:04
fgimenez_mvo, you can execute the suite with go run _integration-tests/main.go -release 15.0409: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 -port09:11
fgimenez_create the image with udf :)09:11
Chipacaogra_: how do I edit the kernel commandline on bbb?09:18
ogra_fw_printenv |grep ^mmcargs09:18
ogra_sudo fw_setenv mmcargs setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot} foobar"09:19
ogra_oh, except ... quoting09:19
Chipacagot it, thanks09: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 btw09:20
Chipacammcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}09:20
Chipacathat's what i have09:21
ogra_yeah, mine is from RPi09:21
ogra_rootfstype is nonsense, we need to clean that up some point09:21
Chipacaah, ok09:22
ogra_on the BBB you can obviously also use optargs instead of mmcargs09:23
ogra_(the default vars come from upstream, we only add the snappy bits)09:24
Chipacapitti: with before:networking-pre i'm still not running it early enough it seems09:35
Chipacapitti: but i can't see what it is that i need to run earlier than09:36
pittiChipaca: networking.service has After=network-pre.target, so that really ought to work09:36
pittiChipaca: what is "it" and how does it fail?09:36
Chipacapitti: on first boot, we create a file for the first ethernet device, to be brought up by ifup09:37
pittiChipaca: does the service get run and the file created? any dependency cycles in journalctl perhaps?09:38
pittiChipaca: did you set DefaultDependencies=no?09:38
Chipacapitti: without defaultdependencies i'd get a cycle09:38
Chipacawithout DefaultDependencies=false i mean09:38
pittiright, I expect that09:38
Chipacabut now no, no cycle, firstboot process is run09:38
Chipacai even added a before: wait-for-ifup-whateveritscalled09:39
Chipacabecause that was started at the same time09:39
Chipacaand no09:39
pittithat runs after ifup@.service, so even later09:39
pittis/run/finishes/, sorry09:39
Chipacawell, but ifup@.service isn't running? or isn't in the logs09:40
pittibut please don't add deps to that, it's just an "internal" helper unit to implement network-online.target09:40
Chipacaok, let me remove that, and i'll show you the boot graph09:40
pittiChipaca: 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
Chipacapitti: i'm listening :)09:41
pittiChipaca: first -- is that the problem?09:41
Chipacapitti: I don't know enough to know whether that is a consequence of the problem, or a cause of it09:42
Chipacapitti: that happens, certainly09:42
pittiChipaca: 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
Chipacapitti: firstboot unit runs. ifup@ doesn't get run.09:42
pittiactually, /etc/init.d/networking should then still bring it up, so that's a bit strange09:42
Chipacapitti: i have ipv609:42
Chipacapitti: but not ipv409:42
pittiChipaca: does networking.service run?09:43
Chipacapitti: yes09:43
Chipacalet me double-check that actually09:43
pittibecause that should "mop up" things that ifup@.service didn't catch09:43
Chipacano, networking.service is not in journalctl09:43
pittiChipaca: so, I know why ifup@ didn't run, but I can't explain why networking.service didn't bring up the eth09:43
pittiChipaca: 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
pittiChipaca: nah, not "Description=" :)09:44
ChipacaOct 29 09:35:50 localhost.localdomain systemd[1]: Starting LSB: Raise network interfaces....09:45
pittithat sohuld run ifup -a09:45
pittidoes that run after your firstboot thingy?09:45
Chipacayes09:45
Chipacaand then after that runs i have09:46
Chipacaa bit of dhcp, and09:46
ChipacaOct 29 09:35:57 localhost.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready09:46
pittiso dhclient ran, but didn't give you an IPv4 address?09:46
Chipacacorrect09:46
pittiwow; I don't have the slightest idea about that then09:47
Chipacabut only on first boot09:47
Chipacafrom then on, ipv4 comes up fine09:47
pittisudo journalctl -u networking.service should have the dhclient output, what did it say?09:47
Chipacanothing about dhcp09:48
Chipacalet me pastebin09:48
Chipacapitti: http://paste.ubuntu.com/12997839/09:48
pittiChipaca: 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
pittiit seems this doesn't actually start anything, it seems to think that they are already up for some reason09:52
pittiChipaca: also, something to try: to your firstboot, add Before=systemd-udev-trigger.service09:52
pittiChipaca: that should hopefully make ifup@*.service start on firstboot09:52
pittithat doesn't explain why /etc/init.d/networking didn't bring them up, of course09:53
Chipacarebooting with those changes, plus systemd.log_level=debug in commandline09:55
Chipacaah, and this is still the last wily, I could bump it to xenial if it makes a difference09:55
Chipacapitti: just to keep things interesting, now it came up with no ipv6 either09:57
pittiChipaca: I suppose ipv6 is just the fe80: LL address?09:57
pittior do you actually get a DHCP address for it?09:57
Chipacafe80::d25f:b8ff:fea3:907f09:58
Chipacawhich afaik is not ll09:58
pittiChipaca: 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 did09:58
pittiChipaca: that's LL09:58
pittife80:<some hash of the MAC>09:58
Chipacaoh09:59
Chipacad'oh09:59
pitticurious where that comes from, of course09:59
pittiyou don't have networkd enabled/configured or something such?09:59
pittiif neither networking.servcie nor ifup@ up the interface, then what does10:00
JamesTaitGood morning all; happy Thursday, and happy Internet Day! 😃10:00
pittiChipaca: btw, you coudl probably make all of this a lot simpler10:00
pittiChipaca: let your network config thing run later (no DefaultDependencies), create your interfaces.d snippet and just call ifup <yournewinterface>10:01
pittiChipaca: but anyway, for the sake of understanding what on earth happens there, let's finish this :)10:01
Chipacapitti: networking service now failed to start10:02
Chipacapitti: so i probably bungled an edit10:02
Chipacapitti: http://paste.ubuntu.com/12997894/10:02
Chipacapitti: but i'm not seeing the error10:03
pittiChipaca: grep -r . /run/network/ || true10:03
pittiChipaca: if the script is set -e10:03
pittiChipaca: if there are no files, grep exits with 110:03
Chipacaah! right10:03
Chipacapitti: where would i see this output btw?10:03
pittiChipaca: but that already tells us that there's no /ifstate10:03
pittiChipaca: should be in the journal, or systemctl status -l networking10:04
Chipacai can't see the ####s there10:04
pittiChipaca: sure -- the command is just "echo" :) # is a comment10:04
Chipacaanyway, adding the ||true and rebooting10:04
pittiech '###'10:05
Chipacaaugh!10:05
Chipacastupid me is stupid :)10:05
ogra_blame the weather10:05
pittiChipaca: of all the --- ____ **** etc. chars you could have picked you got the wrong one :)10:05
Chipacapitti: i nearly went with ****10:05
pittibut yeah, shell is fun, isn't it10:05
Chipacapitti: that's my usual :)10:05
pittiChipaca: that will actually do a glob10:05
Chipacaexactly10:06
Chipacai caught myself :)10:06
pittiChipaca: so you might see "bin" or "usr" or whatever comes first in / :)10:06
Chipacaogra_: i'll blame you instead. it's shell, afterall.10:06
ogra_oh, ok, sorry for breaking :)10:06
pittiwe didn't get rid of shell in shappy yet? :-)10:06
ogra_luckily not10:07
Chipaca... yet10:07
Chipaca]:D10:07
ogra_glue is glue :P10:07
pittiof all programming languages this is probably the most error-pone10:07
Chipacafirst, init=/snappy10:07
Chipacathen, the world10:07
pittialmost as error p*r*one than my spelling, of course10:07
ogra_but also the easiest to learn which gets you lots of free contributions of more broken code :)10:08
pittiogra_: I was about to say PHP *cough* *cough*10:08
* Chipaca twiddles his thumbs while the bbb recreates the universe10:09
pittiChipaca: ugh, poor you -- this doesn't reproduce in a VM?10:09
Chipacapitti: nope10:09
* ogra_ doesnt want the universe to depend on a single BBB10:09
Chipacapitti: http://paste.ubuntu.com/12997933/10:11
Chipaca>>>>> Parsing file /etc/network/interfaces.d/eth0 <<<<<<10:11
ChipacaW10:11
ChipacaT10:11
Chipaca<expletive>10:12
pittiChipaca: i. e. it sees /etc/network/interfaces.d/eth0 but doesn't see any contents or so?10:12
pittiChipaca: could that be a missing fsync, i. e. the file is still in write cache?10:12
pittiI mean, other processes see that cache too, but who knows10:13
pittiChipaca: oh -- is your firstboot thing Type=oneshot? And/or, did it actually *finish* before networking.service? Can you pastebin the full journal?10:13
Chipacapitti: it does the whole sync/rename/sync directory dance10:14
pittiChipaca: ok -- le journal entier, s'il te plaît10:14
pittiChipaca: (silly question, but /etc/network/interfaces.d/eth0 looks alright after boot?)10:15
Chipacaallow-hotplug eth010:15
Chipacaiface eth0 inet dhcp10:15
pittiaah!10:15
pittithat explains why /e/i/networking doesn't do it10:15
pittithat only does "auto" interfaces10:15
Chipacahmm10:16
pittiChipaca: "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
pittiChipaca: so allow-hotplug is only caught by ifup@.service10:16
Chipacathat's ok, though, that's what we want10:16
pittiChipaca: and that gets triggered very early on via udev rules, at which point your firstboot didn't run yet10:16
pittiChipaca: do you? I think you want "auto" there, there is little reason to not use it10:17
Chipacaauto introduces a huge boot delay if the cable isn't plugged in10:17
pittiChipaca: for ifup@ via udev rules you need to run before systemd-udev-trigger.service10:17
pittiChipaca: ah, ok -- you don't want that?10:17
ogra_no10:17
pittiI was specifically asked to implement that10:17
ogra_we want allow-hotplug10:17
ogra_else if you have no cable connected it will wait for the timeout10:18
pittithat'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 interfaces10:18
pittiok then10:18
pittiso that means /etc/init.d/networking is out of the game10:18
Chipacawell10:18
pittiwhich already explains a lot of the above confusion :)10:18
Chipacawe do have services that don't get along with hotplug10:19
ogra_well, a drone might only have a wired connection while you maintain it ... but not while you fly it10:19
ogra_if it reboots while flying or some such you want it to do that before it hits the ground ;)10:19
pittiChipaca: things like ssh ship an /etc/network/if-up.d/ script to reload/restart themselves10:19
pittiwhich is utterly "erks", but oh well10:19
ogra_and not have it wait 3min for a cable connection10:19
pittiIP_FREEBIND!10:19
pittiogra_: oh, I'm absolutely on your side10:20
ogra_i think the master plan is still to use systemds network management or nm10:20
ogra_in the longer term10:20
Chipacapitti: so, looking at http://people.canonical.com/~john/bbb.svg10:20
ogra_which should make dynamic services work10:20
pittiI didn't *like* this "block boot for 2 mins", but I was asked to do that to mirror what we did before10:21
ogra_yeah10:21
Chipacapitti: systemd-udev-trigger comes up very early, before mounts10:21
Chipacapitti: i suspect it's not going to like me saying i want to go before that and after mount10:21
pittiChipaca: yeah; it's not that easy to run stuff before that10:22
pittiChipaca: IMHO it's much simpler (and much more parallel) to just call ifup after you created the definition10:22
Chipacaok, fair enough, i'll do that10:22
Chipacapitti: you do now know why things were weird, then, no more debugging needed?10:22
pittiChipaca: so from the mysteries above the one thing which isn't clear to me yet is what brought up eth0 and assigned an IPv6LL address10:23
Chipacadhcp10:23
Chipaca(why? oh i have no idea)10:23
pittiChipaca: 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
Chipacahere, let me pastebin the journal10:23
Chipacapitti: http://paste.ubuntu.com/12998003/10:24
Chipacapitti: if you look for ipv6 in there10:25
pitti(OTP, brb)10:25
pittiChipaca: 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 surprise10:28
Chipacaup10:29
Chipacadown in the vm10:29
Chipacaup in bbb10:29
Chipacapitti: well, that worked10:31
Chipacalet me check journal just in case10:31
ChipacaOct 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 connected10:34
Chipacapitti: what does that ^ mean?10:34
Chipaca(everything else seems correct)10:34
pittiChipaca: presumably that dbus isn't running at that time yet10:35
pittiChipaca: but that's a debug message; still running with "debug"?10:36
Chipacayes10:36
Chipacakernel options go in firmware10:36
Chipacaso ¯\_(ツ)_/¯10:36
pittiChipaca: pronounce that quickly ten times in a row10:36
Chipaca:shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg:10:36
Chipacadammit10:37
* pitti feels the rhythm & beat10:37
Chipacaobviously :shrug with another : turns into ¯\_(ツ)_/¯10:37
Chipacabut not :shurg:10:38
Chipacaweird, that10:38
Chipaca:)10:38
Chipacaanyway10:38
Chipacapitti: 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
pittiChipaca: please drop the before=udev-trigger, indeed10:41
pittiChipaca: defaultdeps=no and after=local-fs.target still sound fine, and do keep the before=network-pre.target too10:41
ChipacaAfter=local-fs.target10:41
ChipacaBefore=network-pre.target10:41
ChipacaDefaultDependencies=false10:41
Chipacais what i have now10:41
pittiI mean, it's first boot, so it's not a biggie if that takes .5 seconds longer, but *shrug*10:41
pittiChipaca: LGTM10:42
Chipacaoh, that's a good point, is there a systemd idiom for "don't run if this file exists"?10:42
pittiChipaca: oh, you want that, right10:42
pitti[Unit]10:42
Chipacafirstboot itself checks, but why even start it :)10:42
pittiConditionPathExists=!/path/to/file10:42
Chipacanice10:43
pittiChipaca: perhaps you also want ConditionPathExistsGlob=!/etc/network/interfaces.d/*10:43
pittiChipaca: see man systemd.unit, there's a bunch of them10:43
pittithere's even a ConditionFirstBoot=, but that doesn't really work for us yet10:43
Chipacathanks10:44
pitti(that means "/etc is empty")10:44
pittiChipaca: yeah, more efficient than starting a program just to determine that you don't need it10:44
Chipacai'll just leave it at stamp for now10:45
Chipacaas creating that iface is not the only thing it does10:46
* Chipaca reboots to test10:46
Chipacaanyway, pitti, i've stolen enough of your time already :) thanks a bunch10:46
pittiChipaca: ah, that sounds fine; I thought you wanted to do FileExists=/etc/network/interfaces.d/eth0, which would be a bit pointless10:47
pittiChipaca: if you have some "first-boot ran" stamp, then do use that of course10:47
Chipacapitti: it's not always eth0, is where the fun started :)10:47
pittiChipaca: right, that's what I meant10:48
Chipacabut yeh, we've got a stamp file for this10:48
pittibut yeah, networkd :)10:48
Chipacapitti: networkd?10:50
pittiI thought Mark wanted to move to that at some point10:50
Chipacaah. well, it's on there, isn't it?10:50
pittior to a different naming schema for interfaces10:51
pittior both10:51
pittiChipaca: right, but we currently use ifupdown10:51
Chipaca:)10:51
pitti[Match]10:52
pittiName=en* eth*10:52
pittidone10:52
Chipacapitti: how well does that play with networkmanager?10:53
pittiChipaca: same way ifupdown does -- not at all10:53
pittii. e. you need to pick one network management thingy for each interface10:53
pitti(and ideally for the whole system, otherwise it's too confusing)10:53
Chipacapitti: 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
Chipacawhich is the same but different10:58
pittiChipaca: right; if we want to pick one particualr interface, the Name= thing woudl be the same as with ifupdown10:58
pittiChipaca: but if we are going to have NetworkManager on snappy, why not use that for eth as well then?11:00
Chipacapitti: because it's a .snap, not part of the base11:00
Chipacapitti: well --- having said that11:01
pittiah, ok; so not "on" snappy, just "for" snappy11:01
Chipacait would be easy to turn off this thing11:01
Chipacasnappy config lets you write an empty file to interfaces.d, and that would sort that out11:01
Chipacabut a bit more code would be needed11: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 config11:03
ogra_*some way11:03
Chipacaogra_: that's doable11:05
Chipacaogra_: although not from the package itself11:05
Chipacait's package+config doable11:05
Chipacaogra_: from u-d-f, if you want to preload n-m, just create an empty file in interfaces.d11:07
Chipacacreate empty file -> via snappy config11:07
Chipacaogra_: if you install it after, use snappy config to overwrite the eth file with an empty one11:07
Chipacaogra_: done11:08
ogra_i dont want an empty one11:08
ogra_NM will mangae that file11:08
ogra_i think we need a way for snaps to turn off core features they deliver themselves11:08
ogra_look at bug 1504657 and longsleep's comments ... same thing11:10
ubottubug 1504657 in ubuntu-core-config (Ubuntu) "ntp servers should be configurable on snappy" [Medium,Confirmed] https://launchpad.net/bugs/150465711:10
ogra_he might ship ntpd inside a spreedbox snap ... which would then want to disable timesyncd11:10
Chipacaogra_: good point11: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
Chipacaactually, i'd be happier if all these were snaps :)11:12
Chipacaogra_: because different partition11:12
ogra_hmpf11:13
Chipacaogra_: only rename is atomic :-(11:13
Chipacaand even then you need to sync the dir11:13
ogra_i wonder why everything else gets along without atomic writing .... on the phone we have exactly three files in /etc/writable11:13
Chipacaprobably because i wasn't looking :D11:14
ogra_in snappy we'll have 10-20 soon if it goes on at this pace11:14
Chipacaogra_: probably because most of them are small enough, and written to sporadically enough, that crashes due to this are impossible to reproduce11:15
Chipacaogra_: so you'll find that sometimes things won't work, and try again, and they will, and shrug your shoulders and move on11:16
ogra_hmm11:16
ogra_the problem with the setup we use now is that these files will never be upgraded11:17
ogra_i.e. if the tool needs new options they wont show up, the setup completely works around system-image11: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
Chipacafgimenez_: you know the "bbb only has ipv6 on first boot" bug, and the "kvm has no network on first boot" bug?11:18
Chipacaogra_: 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 this11:19
ogra_which is why we generally dont really use /etc/writable on the phone11:20
fgimenez_Chipaca, there's one for the bbb ipv6 issue, not sure about kvm one, let me check11:20
ogra_exccept for files where we know no new upstream options will show up11: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 config11:21
Chipacaogra_: why? that's the bit i don't follow11:21
Chipacaahhh11:21
Chipacai got you now11:21
ogra_beacuse files in /etc/writable come from snappy only11:21
ogra_and are never synced with the upstream version again11:21
ogra_(i.e. on upgrades)11:22
fgimenez_Chipaca, https://bugs.launchpad.net/snappy/+bug/150332911:22
ubottuLaunchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Critical,Confirmed]11:22
Chipacaogra_: you mean when updating, if the new watchdog grows more options, 3-way-diff a la dpkg is a no-go, etc11:22
ogra_right, it simply doesnt happen ... your local config will override  it forever11:22
Chipacaogra_: now everything you said makes sense :)11:22
Chipacaagreed, but that to me means11:23
ogra_the system-image writable thing cares for syncing11:23
Chipacathe config should be generated from snappy based on stuff snappy tracks11:23
Chipacathen when things change, snappy can have the smarts to update the config with sane defaults11:23
Chipacawith no chance of the user/owner/etc breaking the config, as it'd get stomped on every time11:23
Chipacahmm11: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 minimal11:24
ogra_that way we could use the system-image setup again11:24
Chipacaogra_: system-image is going away though11:25
ogra_not the mounting functions11:25
ogra_unless we really fgo for overlayfs and leave the phones behind11:25
zygapindonga: hey11:29
pindongahey11:29
pindongaso, I'm running snapcraft again from scratch11:30
pindongaI'll let you know in a sec how it goes11:30
zygapindonga: okay :)11:30
longsleepAnyone 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
Chipacalongsleep: ubuntu-core is a bit special and different wrt config11:41
Chipacalongsleep: but i can give you a link11:41
Chipacalongsleep: https://github.com/ubuntu-core/snappy/blob/master/coreconfig/config.go11:41
longsleepChipaca: 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
Chipacalongsleep: it's special in that it's handled internally by snappy11:42
Chipacalongsleep: other than that, it's the same, really :)11:42
longsleepChipaca: so one could say it as virtual snap right?11:42
Chipacalongsleep: something like that :)11:42
longsleepChipaca: ok great thanks11:42
Chipacamvo: when core becomes a snap, do we move the config to a hook in the snap itself?11:43
sergiusensChipaca, 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.sh11:43
Chipacasergiusens: no, i don't. have a link?11:43
mvoChipaca: maybe, I have no plan for this yet11:44
sergiusensChipaca, https://code.launchpad.net/~sergiusens/snapcraft/1501222/+merge/27608911:44
mvoChipaca: it would make sense plus we move snappy into a snap11:44
sergiusensChipaca, sorry, sent it in private as I felt like writing in spanish :-P11:44
* sergiusens thinks we need #snappy-es :-)11:44
ogra_mvo, that sounds awfully recursive :) snappy ships snappy in a sap11:45
Chipacasergiusens: gah, and i have too many channels open, never saw your pm11:45
ogra_*snap11:45
sergiusensChipaca, yeah, I'm thinking of using telegram more these days for private messages, but then notifications don't work for you :-P11:45
sergiusensChipaca, which brings to mind, you should use the ubuntu push notifications, I've heard they were implemented by a very good dev ;-)11:46
Chipacasergiusens: notifications work for telegram!11:46
sergiusensChipaca, oh, I thought they weren't working for you on the desktop11:46
Chipacasergiusens: it's just some of the group chats i've disabled them for11:46
sergiusensoh, goodie11:47
Chipacasergiusens: ah, well, sometimes when pulseaudio is having a bad day, yes11:47
sergiusens:-)11:47
pindongazyga, wow, this time after a second snapcraft clean and full run it seems to have worked!11:48
Chipacapindonga: snapcraft working? surely you jest!11:49
pindongaChipaca, I wish I was :)11:49
Chipaca:)11:49
pindongaChipaca, I think it's one of these pieces of software that work with quantum mechanics11:49
pindongathey only seem to work when smart people are watching me11:49
Chipacapindonga: you should get sergiusens to watch you instead11:50
* Chipaca runs for the hills11:50
* sergiusens read that11:50
* Chipaca runs faster11:50
sergiusenspindonga, can I see your yaml?11:50
Chipacasergiusens: at least buy him dinner first11:51
pindongasergiusens, it worked , but sure, if you like :)11:51
sergiusenspindonga, right, I want to know how it failed to make it easier11:51
ogra_"can i see your yaml"  ... this has turned into a nasty channel over time11:51
pindongalet me paste your a few things11:51
ogra_everyone wants to see each others yaml !11:51
pindongasergiusens, http://pastebin.ubuntu.com/12998485/11:54
Chipacaogra_: it's called freiyamlkultur11:55
ogra_lol11:55
Chipacaogra_: you wouldn't understand11:55
longsleepogra_: 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 master11:56
longsleepogra_: right, in spreed-webrtc the real ini config is the master and is used to generate yaml on read11: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 yet11: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
longsleepyeah, for now i chose python3 to create the config hooks11:58
ogra_yeah, i didnt want to ship python in my snap :)11:58
longsleepi am using python3 from the system - i figured that is safe enough for now12:00
ogra_until we drop it, yeah12:00
zygapindonga: :)12:06
zygapindonga: magic12:06
zygapindonga: I'm glad I could help12:06
sergiusenspindonga, zyga ah flexget has a strange setup.py12:10
pindongahow so?12:13
sergiusenspindonga, https://github.com/Flexget/Flexget/blob/develop/setup.py12:13
pindongaoh, right12:14
sergiusensnot saying wrong, just strange ;-)12:14
pindonganot setuptools based12:14
sergiusenspindonga, right, so you don't get your requirements installed by default12:14
pindongaright, but that failure was ok, easy to understand and fix12:15
pindongathe first failure was odd12:15
pindongabefore I had to run snapcraft clean12:15
sergiusenspindonga, that is a bug; mind logging it?12:16
pindongaI'll try to reproduce it , then yes!12:16
sergiusenspindonga, I bet if you run snapcraft all --force without cleaning again the error will show12: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 rootfs13:09
ogra_i think we are currently doing it pretty wrong13: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
jdstrandpindonga: 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 checks13:33
pindongajdstrand, what minecraft?  I see no minecraft ;-)13:34
jdstrandpindonga: thanks! :)13:34
longsleepI just noticed that autopilot fails to start when bootup without network in 15.04/edge (added bug #1511374)13:37
ubottubug 1511374 in Snappy "snappy.autopilot service fails to start when no network connection" [Undecided,New] https://launchpad.net/bugs/151137413:37
jdstrandChipaca: hi! I know you told me before, but I can't seem to find it.... how do I workaround bug #1509451 ?13:41
ubottubug 1509451 in Snappy "snappy update is not updating snappy-debug" [Critical,Fix committed] https://launchpad.net/bugs/150945113:41
jdstrandChipaca: before I uninstalled and installed. I'm hitting this on another package and would prefer not to do that with this one13:41
Chipacajdstrand: from memory,13:42
Chipacajdstrand: for i in $( grep -L ^channel: /var/lib/snappy/meta/*.manifest ); do echo -e "\nchannel: stable" | sudo tee -a $i; done13:43
pindongaso, I managed to build my snap pkg using snapcraft, but it fails review in the store13:43
pindongapackage contains external symlinks: /tmp/clickreview-kb8ua64p/usr/lib/python2.7/site-packages lint_external_symlinks13:43
pindongais there a way to fix this via snapcraft itself?13:43
sergiusenspindonga, 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
jdstrandChipaca: yes, that worked. thanks!13:46
jdstrandChipaca: also, what is the deal with git vs bzr. should we only be using git now?13:47
Chipacajdstrand: yes13:47
jdstrandok13:47
Chipacajdstrand: bzr is so 200813:47
ogra_and rock solid :P13:47
jdstrandbut it is so under my fingers13:47
Chipacajdstrand: yeah :(13:48
Chipacajdstrand: still, it's proving to be less of a pain than i remembered it to be13:49
Chipacai guess the last time i looked was 1.4something-era?13:49
sergiusensChipaca, the git cli improved a lot13:49
sergiusensChipaca, and github is what really makes git easy to use13:49
jdstrandcurious on why git support in lp wasn't chosen13:50
longsleepChipaca: 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
Chipacalongsleep: i still need to look up that about validation13:51
Chipacalongsleep: do you have anything you can point me at wrt that?13:51
longsleepChipaca: sure - https://marc.info/?l=openbsd-tech&m=142356166731390&w=213:51
longsleepChipaca: also a nice read is https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html13:52
longsleepChipaca: also agl from Google has some nice writeups about this how its done in Chrome OS13:52
Chipacajdstrand: thoughts on that?13:53
longsleepChipaca: here it is, part of a larger discussion: https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/oj2xXq3CF0E/f7BtsfkVhe8J13:54
longsleepChipaca: I think bug #1504657 is pretty critical, especially as systemd is using google timeservers by default13:55
ubottubug 1504657 in ubuntu-core-config (Ubuntu) "ntp servers should be configurable on snappy" [Medium,Confirmed] https://launchpad.net/bugs/150465713:55
Chipacalongsleep: not in ubuntu13:56
longsleepChipaca: oh really? I was trying to find a patch for that but could not find it13:56
ogra_systemd onbly uses google servers for its test13:56
Chipacalongsleep: it's a compile-time setting, and /etc/systemd/timesyncd.conf shows you the compile-time defaults, commented out13:56
* Chipaca wrote that filepath from memory, and that's not a good memory13:56
longsleepChipaca: ok then, that is slightly better then13:56
ogra_the actual server used in packages is supposed to be picked by the distros13:56
jdstrandogra_: 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
Chipacantp.ubuntu.com13:57
Chipacais what's built in13:57
ogra_jdstrand, yeah, it should be ntp.ubuntu.com for us13:57
longsleepChipaca: do you have a link to the patching?13:57
ogra_right13:57
ogra_longsleep, only LFS wouold use the google servers :)13:58
jdstrandChipaca: I think it is premature to make tlsdate or openntpd (the OpenBSD version)13:58
jdstrandthe default13:58
longsleepjdstrand, 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 synchronization13:59
jdstrandlongsleep: I agree it should be disableable13:59
Chipacayep, and ogra's already looked into it13:59
Chipacaand shouted at me because of the issues each new thing we add to writable brings14:00
longsleepok cool14:00
* ogra_ hugs Chipaca 14:00
* Chipaca hugs ogra_ back14:00
ogra_i didnt shout :)14:00
ogra_I NEVER SHOUT !!!!14:00
jdstranddo note, for the moment the templated policy will block setting the time14:00
=== chihchun is now known as chihchun_afk
ogra_time is overrated anyway ...14:01
* ogra_ is more for space than for time14:01
Chipacajdstrand: did i ever tell you about the switch from @snapd to /run/snapd.socket?14:01
jdstrandno14:01
jdstrandChipaca: is that live in 15.04 or just for rolling?14:01
jdstrandChipaca: ie, I need to know where to upload the change14:02
longsleepjdstrand: 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 features14:03
Chipacajdstrand: ok. No big deal, as the only people using it right now are unconfined, but yes i'll get you that info14:03
Chipacaah, good point14:03
Chipacajdstrand: just rolling :)14:03
jdstrandlongsleep: 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 freeze14:04
longsleepjdstrand: ok great, thanks for confirming14:04
Chipacaogra_: i know you didn't shout, i lied. In my defence, it was for effect (?)14:04
ogra_and til then leave it untouched14:04
ogra_Chipaca, being the #1 drama queen in the company i think i can appreciate fishing for effect :)14:04
jdstrandlongsleep: 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
jdstrandit would still trigger a manual review14:05
longsleepjdstrand: ah that sounds great14:05
jdstrandbut, 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 accepted14:06
longsleepBtw, 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
tedgIt 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
longsleeptedg: 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
tedglongsleep: Probably not a good optimization overall, fights against the design of the system for a minimal gain.14:15
sergiusenslongsleep, what binary is that and maybe doing ipc is better if it is home grown14:15
jdstrandlongsleep: you can make it work by adjusting the framework snaps framework-policy to allow the writes you need14:15
longsleepsergiusens: in that case - openssl14:15
* sergiusens runs away from openssl14:16
sergiusens:-)14:16
jdstrandlongsleep: just like you added an 'ix' rule to the policy, you would add file rules14:16
sergiusensI'll defer14:16
longsleepjdstrand: yes thats possible, though i am wondering if there might be a better solution14:16
longsleepwithout having to ship openssl in essentially all the snaps14:17
jdstrandlongsleep: well, given the contraint that it must write to the framework snap's dir, no.14:17
longsleepsergiusens: ok, i lied - its actually libressl14:17
jdstrandlongsleep: but, a framework shipping binaries is problematic14:18
jdstrandlongsleep: if the framework uses shared libs, the calling snap won't have those, so you need to deal with that14:18
longsleepjdstrand: 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 nods14:18
longsleepjdstrand: snapcraft creates a wrapper script which sets the ld paths14:18
jdstrandlongsleep: yes, but not for external snaps14:19
longsleepjdstrand: external snaps? what does that mean?14:19
jdstrandlongsleep: ie, it will work fine from the shell and from within the snap itself14:19
jdstrandbut another snap won't be able to use that wrapper14:19
longsleepoh14:19
jdstrandlongsleep: snap foo ships libressl, ship bar uses it14:19
longsleepthats bad then for the stdout apprach as well14:19
jdstrandanything in foo can use it fine14:20
jdstrandbar won't because bar's SNAP_ directories are set to its own paths14:20
jdstrandit can be made to work by shipped a different wrapper that hard codes /apps/foo/current/... in LD_LIBRARY_PATH14:21
longsleepjdstrand: why not? when i call /apps/libressl/bin/libressl-openssl i was assuming that the wrapper script sets it again14:21
jdstrandbut like I said, this is all rather ugly. frameworks aren't really meant for this14:21
jdstrandlongsleep: look at /apps/libressl/bin/libressl-openssl14:22
jdstrandlongsleep: it is using SNAP_APP_PATH14:22
jdstrandanything in foo will have a SNAP_APP_PATH that is /apps/foo/...14:22
longsleepjdstrand: mhm hold on - i think it is setting it14:22
jdstrandanything in bar will have a SNAP_APP_PATH that is /apps/bar14:22
longsleepjdstrand: see http://paste.ubuntu.com/12999228/ thats the wrapper script as generated14:23
longsleepi did not test to run this from another snap, but i think it should just work14:23
longsleepmaybe i am missing something14:24
jdstrandlongsleep: snapcraft did not create that14:24
jdstrandlongsleep: that is what is in /apps/bin14:24
longsleepjdstrand: uhm ok - what created it then?14:24
jdstrandlongsleep: snappy install14:24
longsleepah14:24
jdstrandlongsleep: but that isn't what I'm talking about14:24
jdstrandapps cannot call things in /apps/bin14:25
longsleepi see14:25
jdstrandcause that requires calling the privileged launcher to setup a sandbox14:25
jdstrandno sandbox within a sandbox is allowed14:25
jdstrand(it can't work for a lot of reasons)14:25
jdstrandlongsleep: what I'm saying is you ship another wrapper14:26
longsleepgot 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
jdstrandeg, foo ships /apps/foo/current/bin/libressl.external14:26
longsleepok14:26
jdstrandthe bar uses /apps/foo/current/bin/libressl.external14:26
jdstrand/apps/foo/current/bin/libressl.external hardcodes LD_LIBRARY_PATH/whatever else to use /apps/foo/current/usr/lib/...14:27
longsleepjdstrand: and that wraper i would create manually14:27
longsleep=r14:27
longsleep+r14:27
jdstrandyou adjust foo's framework-policy to allow executing /apps/foo/current/bin/libressl.external, etc14:27
jdstrandlongsleep: you would have to14:27
longsleepjdstrand: got it - great thanks!14:28
jdstrandbar depends on the foo framework and adds foo's framewrok-policy cap to its caps14:28
longsleepyeah - 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
jdstrandlongsleep: 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 socket14:29
longsleepjdstrand: all right, i might try that then and see how it goes :)14:30
longsleepjdstrand: is there some example for this somewhere?14:30
jdstrandlongsleep: 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 process14:30
jdstrandlongsleep: no, it isn't the snappy way :)14:31
jdstrandit 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 debs14:32
jdstrandlongsleep: another thought, you might find it easier if the framework snap's binaries that you expose in framework-policy are statically linked14:33
longsleepjdstrand: yeah i get that - though i still feel the need to share some things wto avoid duplicating so much.14:33
longsleepjdstrand: true, libressl is easy to link statically.14:33
longsleepothers might be not so easy14:33
jdstrandI 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 it14:34
longsleepjdstrand: 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
longsleepjdstrand: or where do you suggest to put the socket files?14:35
jdstrandlongsleep: by definition apps are isolated from each other, so no, there is no shared dir for that sort of thing14:36
jdstrandlongsleep: a framework can simply expose it via framework-policy14:36
=== Guest42341 is now known as francksolo
jdstrandapps within the same snap are free to use and access SNAP_APP_DATA_PATH14:36
jdstranda framework snap would put a named socket in its SNAP_APP_DATA_PATH and have framework-policy allow access to it14:37
longsleepjdstrand: 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
longsleepjdstrand: i tried to put it in /tmp earlier until i discovered that this folder is per process14:37
jdstrandthere are also abstract sockets-- but those are mediated too (same process as for named sockets)14:37
jdstrandlongsleep: oh, use, to have it removed on reboot. there is a path in /run that is app specific14:38
* jdstrand fins it14:38
jdstrandfinds*14:38
longsleepjdstrand: 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
longsleepjdstrand: I think sockets or anything else which is used for IPC should be there and not in SNAP_APP_DATA_PATH14:39
longsleepjdstrand: cool thanks - i will try that asap14:40
jdstrandI'm not sure the launcher is creating /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/ though. if not that is a bug14:40
jdstrandlongsleep: you can also use an abstract socket14:40
jdstrandcreate it as @<pkgname>_... and processes within the same snap can use it14:41
jdstrand(we have this rule for that: unix peer=(label=@{APP_PKGNAME}_*),)14:41
longsleepjdstrand: That works with the normal c level socket code? I want to avoid patching upstream code.14:42
* longsleep does no nothing about abstract sockets14:42
* longsleep reads about it now14:42
jdstrandabstract sockets are something that is available to standard Linux and all major languages on Linux support it, yes14:43
jdstrandlongsleep: man unix14:43
jdstrandit requires patching the code though, but in a minor way14:44
longsleepjdstrand: ok - i will investigate on this. Thanks for all your help an suggestions!14:44
jdstrandnp14:44
elopioI hurt my back yesterday. As of today, I'm officially old.14:48
jdstrandlongsleep: 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 snappy14:49
elopioChipaca: what do you do to test your first boot branch? unpack the .img and overwrite some files there?14:50
longsleepjdstrand: yeah - i agree on the idea. Though in some situations it might be overkill and sharing a binary might be much easier.14:50
Chipacaelopio: that would work. On the other hand, mvo just went ahead and merged it :)14:50
elopioChipaca: I saw that. I was just wondering how to avoid waiting until a new image is generated.14:51
jdstrandlongsleep: I agree there might be times, particularly with a static binary or shell script14:52
longsleeplongsleep: I will for sure make a snap with a IPC service to check it out and get some ideas.14:52
Chipacaelopio: you could boot, remount rw, replace snappy and the firstboot .service files, remove the eth file and the firstboot stamp file, and reboot14:56
elopioah, there's a firstboot stamp file. That will be handy.15:00
mvoChipaca, elopio: I'm not sure I follow, but would it help if I create a new image for you guys?15:01
elopiomvo: yes, please.15:01
Chipacaelopio: /var/lib/snappy/firstboot/stamp15:01
mvoelopio: a 16.04 image I presume?15:09
elopiomvo: rolling, please.15:09
jdstrandChipaca: fyi, upload snapd.socket change15:19
jdstranduploaded*15:20
Chipacajdstrand: muchas gracias15:20
ogra_mvo, hmm, looks like two image builds of wily you did exploded15:29
mvoogra_: yes15:29
mvoogra_: I just asked in #launchpad15:30
ogra_ah, k15: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 refused15:30
ogra_gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused15:31
ogra_gpg: no valid OpenPGP data found.15:31
ogra_yeah, looks like some bad network connection15: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 edge15:31
ogra_was that a concious decision or just an oversight ?15:32
mvoogra_: I don't know why they are disabled, not done by me15:32
ogra_ah, k15:33
mvoogra_: I wish we had a easier way to track this :/15:33
ogra_yes15:33
mvoi.e. why stuff happened in the shared account15:33
ogra_well, usually it has a bzr record ... crontab is a bit special though15:33
ogra_(since there are often temporary changes)15:34
* mvo nods15:34
longsleepWe 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 #151143515:36
ubottubug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Undecided,New] https://launchpad.net/bugs/151143515:36
Chipacalongsleep: looking15:38
mvoelopio: 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 test15:45
kyrofaHey 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
kyrofaogra_, so many...15:48
ogra_really ?15:48
kyrofaogra_, http://lxr.free-electrons.com/source/fs/squashfs/Kconfig15:48
ogra_wow, that grew quite a lot ...15:49
kyrofaogra_, 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 you15:49
ogra_just check on a desktop in /boot/config-* ...15:49
kyrofaogra_, ah, so the config is the same?15:49
ogra_the kernel is the same15:49
kyrofaOkay good deal15:49
kyrofaogra_, thank you!15:50
fgimenez_Chipaca, about the login test https://github.com/ubuntu-core/snappy/compare/master...fgimenez:cli-login-test15:55
fgimenez_Chipaca, you can try it with go run _integration-tests/main.go -snappy-from-branch -filter loginSuite.* -revision 20815:55
rickspencer3if 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
longsleepChipaca: 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 package16:01
longsleepChipaca: i suggest to make things like that non fatal16:02
Chipacalongsleep: agreed, especially given that the error is essentially invisible, and all that'll happen is that you won't get an eth device or whatever16:03
Chipacaoh, wait16:03
Chipacayes you do16:03
elopiorickspencer3: take a look at examples/gopaste. Just instead of git:... use lp:...16:03
Chipacalongsleep: what's the consequence of the failure you're seeing?16:03
rickspencer3elopio, I think I tried that, do you have a link where I can see the examples?16:03
Chipacafgimenez_: what am I looking at here?16:04
Chipacafgimenez_: this is whaty i get; http://pastebin.ubuntu.com/12999856/16:04
elopiorickspencer3: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/gopaste/snapcraft.yaml16:04
fgimenez_Chipaca, you should first get the branch with the changes, https://github.com/fgimenez/snappy/tree/cli-login-test16:06
fgimenez_or apply the diff to master16:06
Chipacaahh :)16:06
rickspencer3elopio, ok, thanks, but I meant an example that uses launchpad16:07
fgimenez_yep, sorry for not being clear :)16:07
elopiorickspencer3: we don't have an example that uses both go and launchpad16:07
elopiorickspencer3: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/libpipeline/snapcraft.yaml16:07
longsleepChipaca: 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
rickspencer3elopio, ok, that shows that source: uses the same syntax as bzr for lp:~ blah blah blah16:09
rickspencer3which is groovy, but it doesn't for me with Go16:09
* rickspencer3 files bug16:09
Chipacalongsleep: thank you. Please do also file a bug for the "any config makes firstboot fail" bug16:10
Chipacalongsleep: you only see that failure because you're actively searching for it, yes?16:10
elopiorickspencer3: thanks. I only see a piece of code that's different in the go plugin, that might be the problem.16:10
elopioI'll take a look.16:10
longsleepChipaca: Well, no - its not that i am searching for bugs :)16:10
Chipacalongsleep: i mean, the system boots and works as you'd expect?16:11
francksolo:'( you people broke personal16:11
longsleepChipaca: 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
longsleepChipaca: not sure what else might be not applied if the service fails like this16:11
francksoloogra_, the mouse input doesn't register :))16:11
ogra_francksolo, you are aware that this is the snappy channel  ?16:12
francksoloogra_, i can click on the login input 4 ever and nothing16:12
ogra_we dont do personal16:12
Chipacalongsleep: once one config fails, all configs that come later won't be applied16:12
francksoloogra_, 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
Chipacafrancksolo: only snappy ubuntu core is supported16:12
Chipacafrancksolo: snappy personal is a sporadic experiment16:12
longsleepChipaca: ok that makes sense, so s comes before u, means ubuntu-core config will also not be applied16:13
francksolooooooo but the ubuntu roadmap graph16:13
ogra_snappy personal will surely exist one day ... but that day is far out16:13
ogra_francksolo, you mean the phone roadmap ?16:13
francksolo:'(16:13
Chipacalongsleep: from looking at the code i would say the order is the one you defined in the oem yaml16:13
ogra_pocket desktop is different from "personal snappy PC image"16:13
francksoloogra http://i.imgur.com/plQvwch.jpg16:14
Chipacafrancksolo: that very thin line is where we are now16:14
francksoloso.. desktop next is dead, personal is nowhere :(16:14
francksolo:'( x1000016:15
Chipacafrancksolo: "desktop next is dead"?16:15
Chipacasigh16:15
francksoloyep, 40416:15
Chipacafrancksolo: you probably want dpm16:15
longsleepChipaca: the other bug also added as #151144816:15
Chipacaunless i've got my faces wrong16:15
longsleepbug #151144816:15
ubottubug 1511448 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains config for snaps not preinstalled, built-in" [Undecided,New] https://launchpad.net/bugs/151144816:15
ogra_francksolo, as you can see the merge only happens in 16.10 (or even after)16:15
Chipacalongsleep: much appreciated sah16:16
ogra_francksolo, for 16.04 ubuntu personal isnt a thing16:16
francksoloyeah.. but i need somehing to play with until 16.10 :D16:16
elopioyes, this is busted.16:16
* francksolo n4 or the pd 16:17
ogra_francksolo, just install 15.10 and install the Mir session16:17
francksolo15.10 is dead16:17
francksolofor unity8 (you will not get updates)16:18
francksolovivid or xenial16:18
francksoloogra_, unity8 mir session is nice but it's not desktop next16:19
ogra_well, then take a n4 and install all the bits you need16:19
francksoloyou can't install apps from the store16:19
francksoloogra_, yeah16:19
ogra_though thats more appropriate for #ubuntu-touch :)16:20
francksolonah :D i like this channel more16:20
* francksolo #snappy is fantastic16:20
francksolook. sorry for spam :D16:20
kyrofafrancksolo, 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, no16:21
ogra_kyrofa, it was disabled16:21
kyrofaogra_, ah, I didn't realize that16:21
ogra_the iage we had was just a proof of concept ... it wasnt supposed to even persist that long16:21
ogra_*image16:21
ogra_non-phone-personal images will be a thing in 16.10 ... but not before16:22
Chipacafgimenez_: do you know how i can merge your repo to mine in git?16:24
* Chipaca habla poco git16:24
longsleepChipaca: git pull --no-ff git@github.com:some.git somebranch16:27
Chipacalongsleep: m'kay ...16:28
* Chipaca tries16:28
longsleepChipaca: 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 continue16:29
elopiosergiusens: tedg: please put this one high on your backlog: https://bugs.launchpad.net/snappy/+bug/151144716:31
ubottuLaunchpad bug 1511447 in Snappy "snapcraft stage does not work with Go and Launchpad" [Undecided,Confirmed]16:31
rickspencer3elopio, 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/151144716:32
ubottuLaunchpad bug 1511447 in Snappy "snapcraft stage does not work with Go and Launchpad" [Undecided,Confirmed]16:32
elopiorickspencer3: it's not you, it's us :)16:32
rickspencer3very rarely the case, but ... sure ;)16:33
Chipacafgimenez_: now i'm getting http://pastebin.ubuntu.com/13000131/16:33
Chipacafgimenez_: 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
Chipacafgimenez_: right. If you really need to test that, you're going to need something that looks a lot more like a terminal :)16:36
Chipacafgimenez_: how's it being run now?16:36
Chipacafgimenez_: you exec.Command("snappy", "login") ?16:37
fgimenez_Chipaca, :) yes, including the loginName, in setupInteractiveCmd16:38
fancycodeHi, 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 chec16:51
fancycodek in snapp.go and rebuilt the tool)16:51
Chipacafancycode: yeah, bug in u-d-f16:52
Chipacafancycode: i think sergiusens knows about it, but check with him just in case16:53
ChipacaFacu found it the other day16:53
Chipacaat least, that's when i found out about it16:53
Chipacafgimenez_: so16:53
fancycodeAnother 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
longsleepfancycode: I just added bug #1511464 for this16:57
ubottubug 1511464 in Snappy "/etc/modules-load.d missing from writable-paths, used by snappy firstboot " [Undecided,New] https://launchpad.net/bugs/151146416:57
fancycodelongsleep: thanks16:57
ogra_longsleep, no, it isnt missing from writable paths ...16:57
longsleepogra_: no? its not in my writable-paths16:58
ogra_it is another one of these "snappy atomic write" issues that forces us away from using writable paths at all16:58
ogra_hmm, i thought i added it to rolling16:58
longsleepah rolling16:58
longsleepwe are using 15.04/stable for now16:58
ogra_still16:58
Chipacafgimenez_: http://pastebin.ubuntu.com/13000343/16:59
Chipacafgimenez_: you need an actual tty, e.g. via a pty16:59
ogra_all config options that snappy uses use that atomic write and are thus not working with writable paths16:59
Chipacafgimenez_: that ^ is how you'd go about that16:59
Chipacafgimenez_: (the io.Copy is me just being lazy at the end; a second f.Read() works)16:59
Chipacafgimenez_: the \n after the password is very important :) otherwise it hangs forever, as expected17:00
longsleepogra_: ok, but writing to /etc/modprobe.d works just fine from firstboot - or is there some other mechanism involved there?17:00
Chipacafgimenez_: github.com/kr/pty is already packaged in ubuntu, fwiw17:00
Chipacafgimenez_: golang-pty-dev17:00
ogra_longsleep, not from snappy config17: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 it17:01
fgimenez_Chipaca, swordfish, the better marxist password ever :D17:01
ogra_which kind of defeats the purpose of writable-paths being bind mounts17:01
fancycodesergiusens: 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
longsleepogra_: 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 there17:02
Chipacaogra_: 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 sausage17:04
Chipacai hear tofu sausages are not completely horrible17: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 though17:05
sergiusensfancycode, the oem snap should be arch all though17:05
Chipacaogra_: 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 landing17:06
sergiusensfancycode, or we need to add yet another switch to u-d-f to query the store for it beating the purpose17:06
Chipacaogra_: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001102.html17:06
fancycodesergiusens: sorry, the oem snap result is arch all, however inside it specifies oem -> hardware -> architecture: armhf17:07
ogra_now ... if my firefox wouldnt totally act up17:07
ogra_grrr17:07
Chipacaogra_: lynx -dump ftw ;)17:08
ogra_heh17:08
ogra_https://launchpadlibrarian.net/223054208/ubuntu-core-config_0.6.15%2Bppa24_0.6.15%2Bppa25.diff.gz17:09
ogra_so this definitely landed in 15.0417:09
Chipacafgimenez_: 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
Chipacaogra_: ah, yes, the problem is the atomic17:10
ogra_so yeah, another atomic write17:10
Chipacayeh17:10
ogra_Chipaca, right, i was just not sure it had landed in 15.0417:10
longsleepcat /etc/system-image/writable-paths |grep modules17:10
longsleep(i see nothing)17:10
ogra_especially because longsleep calims he doesnt have the dir in writavble-paths17:10
Chipacamaybe longsleep is using ancient software17:10
Chipacalike pre-last-week17:11
longsleepmaybe17:11
Chipaca:)17:11
longsleepactually it might be true again :D17:11
ogra_hah17:11
longsleepbut fancycode is not using ancient software17:11
ogra_well, it wont fix you :)17:11
longsleepi current have ubuntu-core         2015-10-13 19617:11
ogra_the dir is writable but the tool cant write17:11
longsleepwhich might be a little old17:11
ogra_ancient17:12
longsleepbut fancycode has 9 (stable) and also does not see the patch you linked17:12
ogra_weird, iirc the release was held back for it to land17:13
Chipacalongsleep: i suspect the preinstalled codepath has a lot less testing than we'd like. I'll have to dig into that.17:14
Chipacalongsleep: tomorrow or maybe next week...17:14
Chipacalongsleep: how urgent is this for you?17:14
fancycodeI'm running ubuntu-core-config 0.6.15+ppa2417:14
longsleepChipaca, ogra_ reason is that 9/stable has 0.6.15+ppa24 and the patch is for 0.6.15+ppa2517:14
fancycodeso that's one version too old then, right?17:14
ogra_yeah17:14
ogra_the release was on the 23rd17:14
ogra_the patch only landed on the 27th17:15
Chipaca/o\17:15
longsleepok so its already fixed and the next release will have it - all good then17:15
longsleepChipaca: got me again, i am running  0.6.15+ppa22 :D17:15
fgimenez_Chipaca, works like a charm thanks! :)17:17
longsleepChipaca: If it eventually works then its fine. So next week no problem.17:19
Chipacalongsleep: wrt that package in oem, you're getting it preinstalled from the store, or from local fs?17:22
longsleepChipaca: local fs17:22
Chipacalongsleep: in other words, is it right to be 'sideload'17:22
Chipacaah, ok17:22
Chipacaphew :)17:22
longsleepChipaca: yes it is sideloaded17:22
longsleepChipaca: its not found in the store, because the package is armhf only and u-d-f does not find those17:23
Chipacagaarhgh17:23
Chipacalongsleep: sorry :(17:23
fancycodeChipaca: that's most likely also because I'm building on an amd64 host, maybe can try on an armhf tomorrow17:24
longsleepChipaca: well - fancycode is having all the fun with it :)17:24
fancycodelongsleep: haha :-/17:24
Chipacayes, it's because u-d-f is not calling SetArch before installing17:25
Chipacait's a silly fix, but somebody needs to do it :)17:25
fancycodeChipaca: is that "SetArchitecture" from snappy/arch.go?17:26
Chipacayep17:26
fancycodeok, I might be able to take a look tomorrow17:27
longsleepogra_: So i guess you can close bug #1511464 as you already fixed it and it will be released eventually.17:27
ubottubug 1511464 in Snappy "/etc/modules-load.d missing from writable-paths, used by snappy firstboot " [Undecided,New] https://launchpad.net/bugs/151146417:27
ogra_longsleep, no, it isnt fixed17:28
ogra_i mean, it is in writable-paths ... but wont be usable yet17:28
ogra_we'll have a discussion about a proper fix tomorrow17:28
longsleepogra_: ok great17:29
Chipacalongsleep: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001124.html17:52
john-mcaleelyogra_, 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-mcaleelymaybe that already works?18:09
ogra_yeah, it does18:10
john-mcaleelyyay!18:10
john-mcaleelymust play more with mine, I guess18: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 enable18:10
john-mcaleelysure, that's cool18:11
pindongasergiusens, is there a way to exclude files in the snap stage, or just to include?19:06
pindonga(in snapcraft)19:06
sergiusenspindonga, get snapcraft 0.4 (apt update) and then run 'snapcraft help plugins'19:09
sergiusenspindonga, shorter answer is with a preceding '-'19:09
pindongaack19:10
pindongatx19:10
=== davidcalle|afk is now known as davidcalle
pindongasergiusens, the bug you asked: https://bugs.launchpad.net/snapcraft/+bug/151144020:41
ubottuLaunchpad bug 1511440 in Snapcraft "python based package created using external symlink" [Undecided,New]20:42
* pindonga just noticed the title was wrong and updated it20:42
tedgWhat is the bazaar plugin to do fastimport/export ?20:50
rickspencer3so, I want to make a snap that is not a service, but runs like an app20:52
rickspencer3i.e. you ssh in and run a command20:52
rickspencer3anyone have an example of snapcraft doing that?20:52
tedgrickspencer3: binaries is the header20:52
rickspencer3binaries instead of services?20:52
rickspencer3that sounds easy20:52
tedghttps://gist.github.com/ted-gould/304a3a828baaaaed272f20:52
rickspencer3hey tedg, this snaps up no problem, but ...21:18
tedgHeh, then my job is done :-)21:19
rickspencer3but then when I use it in the kvm instance, it says it can't find zork?21:19
rickspencer3http://pastebin.ubuntu.com/13002903/21:19
tedgLike literally zork?21:19
rickspencer3tedg, mind taking a quick look?21:19
rickspencer3yeah21:19
tedgOh, I see. I was confused :-)21:19
rickspencer3yeah, well, without the link, it was a pretty confusing question ;)21:19
tedgrickspencer3: Is there a zork1.zork in /apps/bin ?21:20
rickspencer3no21:20
rickspencer3tedg, no21:21
rickspencer3is that what I need?21:21
rickspencer3make a bash file and put it there?21:21
tedgHmm, yeah, but snappy should build it for you.21:21
tedgIs there a "binaries" in /apps/zork1/current/meta/package.yaml ?21:21
rickspencer3um21:22
rickspencer3tedg, yes21:22
rickspencer3it has the exec like I wrote it in snapcraft.yaml21:23
rickspencer3and a ... name:zork21:23
rickspencer3well .. name: zork21:23
tedgYeah, that seems right. It should be roughly your snapcraft.yaml without the "parts" section.21:23
rickspencer3tedg, but I never made an actual file called "zork" anywhere21:24
tedgrickspencer3: I don't think it'll be "zork", but it'll be "zork1.zork" ($pkg.$bin)21:25
rickspencer3tedg, ok, so I did zork1.zork, and got an error like: binary must be inside /apps/zork1.sideload/ or /oem/zork1.sideload21:26
tedgI think that snappyd is the person that is supposed to create that script.21:27
tedgHmm, sorry rickspencer3 I'm not sure what could be up there.21:29
tedgSnappy should be making the shell script wrapper based on the binaries21:29
rickspencer3tedg, I think my VM is not up to date on snappy21:30
rickspencer3maybe if I force it to the last stable 15.04 release?21:30
tedgSure, you shouldn't have to force it, it should upgrade itself unless you turned that off.21:31
tedgsudo snappy upgrade to upgrade21:31
tedgsnappy list should show your version.21:31
tedgubuntu-core                   2015-10-23 9            ubuntu21:31
rickspencer3tedg, well, it keeps telling me that it is going to reboot later :)21:33
tedgHeh21:34
rickspencer3hmmm21:35

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!