| niemeyer | mwhudson: Heya | 00:42 |
|---|---|---|
| mwhudson | niemeyer: hi | 00:42 |
| niemeyer | mwhudson: We have very good coverage on assertions on the system design doc | 00:42 |
| mwhudson | ah yes, i've seen that i think | 00:42 |
| niemeyer | mwhudson: Do you have a moment to chat about the upcoming image? | 00:42 |
| mwhudson | niemeyer: it's been kept up to date as the implementation has happened? | 00:43 |
| mwhudson | niemeyer: sure | 00:43 |
| niemeyer | mwhudson: Yeah, I think it's quite precise stlil | 00:43 |
| mwhudson | cool, i shall re-read it then | 00:43 |
| niemeyer | mwhudson: There might be a couple of minor assertions missing there, but otherwise it's good | 00:43 |
| mwhudson | niemeyer: chat here or some kind of voip? | 00:43 |
| niemeyer | mwhudson: We'd like to finish our pending activities for RTM by EOD tomorrow, so that we can cook a candidate image by Monday | 00:44 |
| niemeyer | mwhudson: Here is fine to start, we can jump on a call if we need more bandwidth | 00:44 |
| niemeyer | mwhudson: So I'd like to sync with you regarding open points on your end | 00:45 |
| mwhudson | niemeyer: that would be great, i've been feeling a bit disconnected | 00:45 |
| mwhudson | well not disconnected, just a bit unsure of some things | 00:45 |
| niemeyer | mwhudson: Yeah, the usual problem of living on different sides of the world | 00:46 |
| mwhudson | that and coming in late to a fast moving project :) | 00:46 |
| niemeyer | mwhudson: We've had a few network-related branches landing recently | 00:46 |
| mwhudson | yes | 00:46 |
| niemeyer | mwhudson: INdeed | 00:46 |
| niemeyer | mwhudson: I've been very far from that work, so I'm not sure what your plans for it are | 00:47 |
| niemeyer | mwhudson: is it working already? | 00:47 |
| mwhudson | niemeyer: more or less, it works fine in kvm | 00:47 |
| mwhudson | niemeyer: the ui does not let you configure wlan interfaces, but if you inject an ifupdown config to make that work, it shouldn't get in the way | 00:48 |
| niemeyer | mwhudson: Cool, that's a start | 00:48 |
| niemeyer | mwhudson: How do you mean? wlan feels like the basic stuff | 00:49 |
| mwhudson | niemeyer: netplan only just gained support for wlan, and we haven't written the ui yet | 00:50 |
| mwhudson | niemeyer: nothing fundamental, just lack of time | 00:50 |
| niemeyer | mwhudson: Ok.. hmm | 00:52 |
| niemeyer | mwhudson: So is there anything pending that we need to do today to have a proper image on Monday? | 00:52 |
| mwhudson | i can hack like crazy and see what i can get done in the 3 hours of work i have left in the week ... | 00:52 |
| mwhudson | niemeyer: not that i am aware of | 00:52 |
| mwhudson | niemeyer: on the networking side | 00:53 |
| mwhudson | niemeyer: on the user side, there was some confusion about whether cloud-init should accept the traditional cloud-init syntax for creating users | 00:53 |
| niemeyer | mwhudson: Something you'd like to be tested during the next month as we put those images to run | 00:53 |
| niemeyer | mwhudson: Yeah, I've seen the bug # | 00:54 |
| mwhudson | niemeyer: sorry, is that a question? | 00:54 |
| niemeyer | mwhudson: Yeah, sorry, it was part of the previous one | 00:54 |
| mwhudson | the biggest open bits are around user management but that's not happening for RTM aiui | 00:55 |
| niemeyer | mwhudson: re. the cloud-init feature, I'm not sure.. one alternative would be to teach it to talk to snapd and call create-user | 00:55 |
| niemeyer | mwhudson: Yeah, there's an open point I noted down today for GA.. we still need to associated the system user created with a snapd user | 00:56 |
| mwhudson | niemeyer: well it should likely be able to do that, sure, but that's not what i meant by "accept the traditional cloud-init syntax for creating users" | 00:56 |
| niemeyer | mwhudson: Ah? | 00:57 |
| mwhudson | which is username/password/ssh key, not email for use with sso | 00:57 |
| mwhudson | niemeyer: yes, snapd user tied to system user and some way for console-conf to tell that this has happened | 01:01 |
| niemeyer | mwhudson: Ideally we'd also put that under the same system | 01:01 |
| niemeyer | mwhudson: So we have a single path to create ubuntu core users, and the outcome is always the same | 01:02 |
| niemeyer | (owner semantics, credentials for snapd, etc) | 01:02 |
| mwhudson | niemeyer: that certainly makes sense | 01:04 |
| niemeyer | mwhudson: Cool.. so for RTM, if you have any critical changes you'd like to see tested in the candidate image, today or your Monday should be fine, and we'll try to get the changes in on time | 01:07 |
| niemeyer | mwhudson: Post RTM, let's nail down networking and those credentials/ownership details | 01:08 |
| mwhudson | niemeyer: ack. how should i provide any such fixes? upload to ppa:canonical-foundations/ubuntu-image and email canonical-snapcraft@ ? | 01:08 |
| niemeyer | Yeah, or push a PR to snapd, if that's the case | 01:17 |
| niemeyer | mwhudson: ^ | 01:17 |
| mwhudson | niemeyer: talking of which! https://github.com/snapcore/snapd/pull/1830 | 01:18 |
| mup | PR snapd#1830: firstboot: only configure en* interfaces by default <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1830> | 01:18 |
| niemeyer | mwhudson: LGTM | 01:22 |
| niemeyer | mwhudson: As a minor, would be nice to fix indentation on this file | 01:22 |
| niemeyer | mwhudson: I'd suggest 4 spaces consistently | 01:22 |
| niemeyer | mwhudson: one space makes a bit too hard on the eye | 01:23 |
| niemeyer | mwhudson: and the first level is using 2 | 01:23 |
| mwhudson | niemeyer: fair enough, fixing | 01:24 |
| === King_InuYasha is now known as Son_Goku | ||
| niemeyer | mwhudson: Much nicer, thank you | 02:06 |
| mwhudson | ah haha can i customize the kernel command line of a snappy image? | 02:51 |
| mwhudson | /etc/default/grub is read only... | 02:51 |
| mup | PR # closed: snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652, snapcraft#652 | 03:09 |
| === chihchun_afk is now known as chihchun | ||
| justinmcp_ | where can I read about assertions? | 04:01 |
| lpotter | hmm.. I think the qmake snapcraft plugin should include g++ build package | 04:10 |
| lpotter | oh man, cleanbuild can be painful | 05:23 |
| mvo | pitti: good morning! latest yakkety adt in snapd is failing because it runs out of diskspace (the container). is that a known issue? http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd/yakkety/amd64 | 05:36 |
| mvo | pitti: and one more question - the new autopkgtest tests we have are based on spread. this is a little bit unusual as it usually drives the testsuite over ssh on a different host, for adt I point the test simply to localhost, but it still needs to connect via ssh (because that is how spread works). in my adt local vm this is all working great, however in the dc I get failures to connect to localhost | 05:38 |
| pitti | mvo, jdstrand: networkd is supposed to send the hostname on a DHCP request, so if the server keeps a hostname -> IP mapping that shold work; but if it relies on the client to save the previous lease, we don't do that across reboots right now | 05:42 |
| pitti | mvo, jdstrand: if that's needed, please file a bug (but why bother..) | 05:43 |
| mup | PR snapd#1830 closed: firstboot: only configure en* and eth* interfaces by default <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1830> | 05:43 |
| pitti | mvo: disk space failure is known, bug 1619285 | 05:44 |
| mup | Bug #1619285: cc_growpart fails on yakkety <cloud-utils:Fix Committed> <cloud-init (Ubuntu):Confirmed> <cloud-utils (Ubuntu):Confirmed> <util-linux (Ubuntu):Confirmed> <https://launchpad.net/bugs/1619285> | 05:44 |
| pitti | mvo: we'll do a mass-retry after this is fixed, s_moser is working on it | 05:44 |
| pitti | mvo: hm, sshd should be running in the instances, that's how we connect to it after all | 05:45 |
| mvo | pitti: "Discarding adhoc:ubuntu-16.04-64, cannot connect: cannot connect to adhoc:ubuntu-16.04-64: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain", would love to play with it some more, works in my local adt qemu. and its really cool, we run 85 integration spread tests now in there which much more than with the old system, I'm super keen to land this but I need some test uploads to a real | 05:48 |
| mvo | adt to figure out why its not wokring just now. ideas appreciated (or a wiki page), I had hoped I could use yakkety but... | 05:48 |
| mup | PR snapd#1821 closed: ensure snapd.refresh.service waits for snapd.firstboot.services <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1821> | 05:49 |
| pitti | mvo: Changing password for ubuntu. | 05:51 |
| pitti | chpasswd: (user ubuntu) pam_chauthtok() failed, error: | 05:51 |
| pitti | mvo: and that's not just it? | 05:51 |
| mvo | pitti: where do you see that? that may well be it | 05:52 |
| pitti | mvo: anyway, if this happens with the current -proposed package, I can start a test manually with --shell and give you ssh access to the instance so that you can poke aroud | 05:52 |
| pitti | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/s/snapd/20160901_214402@/log.gz | 05:52 |
| pitti | mvo: the i386 snapd failure | 05:52 |
| pitti | mvo: amd64 runs into the growpart failure, the i386 one got further | 05:52 |
| pitti | mvo: well, where did *you* see it? | 05:52 |
| mvo | pitti: yay, I think this gives me enough, I will try some more yakkety, I had no idea that i386 would work, as long as I have one working, its all good | 05:53 |
| mvo | pitti: thank you | 05:53 |
| pitti | mvo: so, I'm just saying don't do five uploads to debug this, the latency will kill all of however much patience you still have left :) | 05:54 |
| mvo | pitti: heh, ok! *maybe* its just a single one, this log gives me some clues | 05:55 |
| mvo | pitti: should I add "breaks-testbed" because of the modifications I make? | 05:56 |
| pitti | mvo: irrelevant for the infra, but a nice warning for people trying to run it locally, yes | 05:56 |
| mvo | ta | 05:56 |
| pitti | mvo: well, actually not irrelevant if you have more than one test (this decides whether the testbed gets reset in between tests) | 05:56 |
| mvo | pitti: its just a single (large test) currently | 05:57 |
| * mvo adds it | 05:58 | |
| mvo | pitti: thanks a bunch for your help, much appreciated | 05:59 |
| pitti | mvo: no worries; please let me know if you need ssh to a testbed instance | 06:00 |
| mvo | ogra_: can you please check if you have the system-boot partition on your pi2, i.e. if it shows up with ls -l /dev/disk/by-label ? its not there on amd64 so firstboot breaks in different ways | 06:12 |
| om26er | how to install lxd on all-snap image ? | 06:34 |
| ogra_ | mvo, nope | 06:40 |
| mvo | ogra_: its not there? | 06:40 |
| ogra_ | no | 06:40 |
| mvo | ogra_: then firstboot fails for this reason | 06:40 |
| mvo | ogra_: easy enough to fix, I can push a new gadget, we had the same issue on amd64 | 06:40 |
| mvo | ogra_: a world of pain | 06:40 |
| ogra_ | filesystem-label: system-boot | 06:41 |
| ogra_ | it is in gadget.yaml | 06:41 |
| mvo | ogra_: yeah but that is not the partition label | 06:41 |
| ogra_ | well, it uses an msdos table ... not sure we even planned for partition labels there | 06:42 |
| mvo | ogra_: no idea either, I wonder if http://paste.ubuntu.com/23123142/ helps | 06:42 |
| ogra_ | (that might need more code in u-image) | 06:42 |
| mvo | ogra_: I can look at the old u-d-f code | 06:42 |
| mvo | ogra_: I checked, there is code in u-i for setting the fs-label, I just suspect its the wrong one | 06:42 |
| ogra_ | yeash, that smells like it should help | 06:42 |
| om26er | I can see lxd here: https://uappexplorer.com/app/lxd.stgraber but can't install, am I missing something ? | 06:42 |
| mvo | ogra_: I push it, what could possibly go wrong | 06:43 |
| ogra_ | heh, indeed | 06:43 |
| === ogra_ is now known as ogra | ||
| mvo | meh, store and bzr out of sync! | 06:45 |
| om26er | stgraber, around ? Can you tell if I can currently install lxd on all-snap image ? | 06:46 |
| om26er | (on a RPi) | 06:46 |
| dholbach | hey hey | 07:02 |
| mup | PR snapd#1831 opened: interfaces: modem-manager: ignore camera <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/1831> | 07:18 |
| mup | PR snapd#1831 closed: interfaces: modem-manager: ignore camera <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1831> | 07:26 |
| zyga | o/ | 07:41 |
| === ant_ is now known as Guest84579 | ||
| zyga | ogra: hey, do you remmember the /etc/os-release thing | 08:06 |
| ogra | zyga, see my bug comments :P | 08:06 |
| ogra | (i linked all related bugs) | 08:08 |
| zyga | ogra: ah, I see now; too bad we cannot use variant | 08:08 |
| zyga | ogra: but whatever works :) | 08:08 |
| ogra | well, i guess we can just use variant | 08:08 |
| ogra | i personally find it cleaner ... | 08:09 |
| ogra | it sounds like the natural field to use for this | 08:09 |
| ogra | what worries me more is how we can mangle it in a clean way ... | 08:10 |
| ogra | technically the change needs to be in base-files | 08:10 |
| ogra | instead of being a hack in the build system | 08:10 |
| ogra | i'm not sure how we should do that | 08:10 |
| zyga | yep, I don't know either | 08:11 |
| zyga | update-alternatives perhaps? | 08:11 |
| ogra | uh | 08:11 |
| zyga | or dpkg-divert something | 08:11 |
| ogra | pitti, as somone who has touched base-files often ... any idea how we could cleanly mangle the content of os-release without evil hacks ? | 08:11 |
| mup | PR snapd#1768 closed: many: automatically restart all-snap devices after os/kernel updates <Critical> <Reviewed> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1768> | 08:12 |
| ogra | zyga, well, then a sed or mv/cp is as good ... given we dont use dpkg at all on the aime | 08:12 |
| ogra | s/aime/img/ | 08:12 |
| zyga | ogra: you are right | 08:13 |
| mvo | ogra: talked to steve, my changes to the gadget were incorrect, I fixed it now in the u-i code | 08:13 |
| ogra | dpkg-divert really only makes sense regarding debs ... | 08:13 |
| mvo | ogra: new ubuntu-image snap is uplaoded | 08:16 |
| ogra | oh, its in the store already ? | 08:16 |
| ogra | hah | 08:16 |
| * ogra grabs | 08:16 | |
| mvo | yep | 08:16 |
| mvo | only tested on kvm so far and need to go and work on snapd code next | 08:17 |
| ogra | error: cannot fetch and check prerequisites for the model assertion: account-key [Jv8_JiHiIzJVcO9M55pPdqSDWUvuhfDIBJUS-3VW7F_idjix7Ffn5qMxB21ZQuij] not found | 08:17 |
| ogra | hmpf | 08:18 |
| mvo | ogra: yeah, one sec | 08:19 |
| mvo | ogra: export UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 | 08:20 |
| ogra | moves on | 08:20 |
| ogra | mvo, did you already publish teh new gadget ? http://paste.ubuntu.com/23123319/ ... | 08:21 |
| mvo | ogra: sorry, now | 08:23 |
| pitti | ogra: I don't actually know much about base-files, but WDYM with "mangle"? | 08:24 |
| ogra | hmm, does u-image cache something ? | 08:24 |
| ogra | still the same | 08:24 |
| ogra | pitti, Bug #1619420 | 08:25 |
| mup | Bug #1619420: snappy removal of dpkg-query breaks lsb_release --all <cloud-init:New> <Snappy:New> <https://launchpad.net/bugs/1619420> | 08:25 |
| ogra | and bug 1481086 | 08:25 |
| mup | Bug #1481086: Need API/cli method to know if "is_snappy" <Snappy:Triaged> <https://launchpad.net/bugs/1481086> | 08:25 |
| ogra | mvo, didnt change :/ | 08:26 |
| ogra | mvo, also, any reason why you reverted the README change in the gadget ? | 08:28 |
| mvo | ogra: sounds like a mistake | 08:28 |
| ogra | ah, yeah, it was in the "merge from steve" merge :) | 08:28 |
| mvo | ogra: yeah, that probably confuse dme, sorry, shall I fix or will you? | 08:28 |
| mvo | ogra: I uploaded a new rev24 of the pi2 snap, jsut to be sure | 08:29 |
| ogra | i can fix it, but i still get the same u-image error | 08:29 |
| * ogra retries once again | 08:29 | |
| mvo | ogra: seems to be ok here, maybe a store delay? | 08:30 |
| ogra | seems to work now | 08:30 |
| ogra | at least it sits silent there | 08:30 |
| ogra | aaaand ... i got an image ... | 08:30 |
| * ogra dd's | 08:30 | |
| mvo | ogra: it does? my latest snap should have proper progress | 08:30 |
| ogra | well, for the downloads | 08:31 |
| ogra | everything after is still quiet | 08:31 |
| ogra | (the image creation itself) | 08:31 |
| mvo | aha, ok | 08:31 |
| mvo | thats fine | 08:31 |
| mvo | was worried for a second | 08:31 |
| ogra | ogra@anubis:~/datengrab/images/snappy$ ls -l u-image-pi2.img | 08:32 |
| ogra | -rw-r--r-- 1 root root 4000000000 Sep 2 10:29 u-image-pi2.img | 08:32 |
| ogra | the size is really funny | 08:32 |
| mvo | we probably need something slightly smaller | 08:32 |
| ogra | yup, i have a bug open for that | 08:32 |
| mvo | iirc we reduced it in u-d-f because some usb sticks are not up to it | 08:33 |
| mvo | aha, yeah, we can make it a lot smaller indeed :) | 08:33 |
| ogra | Bug #1619362 | 08:33 |
| mup | Bug #1619362: images should not be largely bigger than the actual content <Ubuntu Image:Incomplete> <https://launchpad.net/bugs/1619362> | 08:33 |
| ogra | 300MB should be enough | 08:33 |
| ogra | (effectively i'd like u-i to just compute the content, add a few MB wiggle room and roll that .. | 08:34 |
| ogra | ) | 08:34 |
| ogra | as long as we resize on first boto we can be as small as the content | 08:34 |
| ogra | *boot | 08:34 |
| * ogra tries conv=sparse for dd ... according to steve that should not write the zeros | 08:35 | |
| ogra | woah | 08:36 |
| ogra | and he seems to be right ... that was a fast dd | 08:36 |
| mvo | ogra: yeah, I meant to add this to godd automatically but ENOTIME :/ | 08:36 |
| * ogra boots | 08:37 | |
| ogra | reading /kernel.img | 08:37 |
| ogra | ** Unable to read file /kernel.img ** | 08:37 |
| ogra | reading /initrd.img | 08:37 |
| ogra | nope ... :( | 08:37 |
| mvo | ogra: uh, that is worse than before | 08:37 |
| ogra | yeah... waiting til i get a uboot prompt | 08:37 |
| mvo | ogra: maybe I did a incorrect uboot.env from a wrong uboot.in? | 08:37 |
| mvo | ogra: I think I regenerated it, maybe using the wrong readme? could you double check that maybe? | 08:38 |
| ogra | http://paste.ubuntu.com/23123371/ filesystem looks fine | 08:39 |
| mvo | ogra: yeah, I'm sure the env is wrong for some reaon | 08:40 |
| ogra | no snap_kernel and snap_core in the env | 08:40 |
| ogra | sounds more like u-i than the default env | 08:41 |
| ogra | all other defaults are correct | 08:41 |
| mvo | ogra: hm, hm ok | 08:49 |
| mup | PR snapd#1802 closed: image,overlord/boot,snap: metadata from asserts for image snaps <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1802> | 08:58 |
| ogra | WOAH | 08:59 |
| ogra | i just wanted tzo check the vars on yesterdays dragonboard image | 09:00 |
| ogra | snap_kernel=dragonboard-kerne.snap | 09:00 |
| ogra | how the heck did that boot at all ?!?! | 09:00 |
| * ogra reboots the board | 09:01 | |
| ogra | hmm, despite the mangled value it seems to use the correct one on boot | 09:01 |
| ogra | how weird is that | 09:01 |
| ogra | snap_kernel=dragonboard-kernel_7.snap | 09:02 |
| ogra | hmm ... now it is correct | 09:02 |
| ogra | probably a serial tty glitch then | 09:03 |
| ogra | U-Boot> setenv snap_kernel pi2-kernel_11.snap | 09:08 |
| ogra | U-Boot> setenv snap_core ubuntu-core_424.snap | 09:08 |
| ogra | mvo, boots fine with that ^^^ | 09:08 |
| ogra | bah, still the cloud-init failures | 09:10 |
| * ogra goes to make coffee ... that'll take 10-15min til cloud-init gives up | 09:11 | |
| ogra | ogra@localhost:~$ snap list | 09:20 |
| ogra | No snaps are installed yet. Try 'snap install hello-world'. | 09:20 |
| ogra | ogra@localhost:~$ | 09:20 |
| ogra | mvo, in that regard nothing changed ^^^ | 09:20 |
| mvo | ogra: what is the systemctl status snapd.firstboot output? | 09:24 |
| ogra | give it a bit, i just rebooted | 09:24 |
| ogra | oh come on cloud-init | 09:25 |
| ogra | sigh | 09:25 |
| ogra | this is such a pain :/ | 09:26 |
| mvo | ogra: yeah, I think I will merge the branch from cyphermox into my snap | 09:29 |
| mvo | ogra: its just terrible otherwise | 09:29 |
| ogra | mvo, http://paste.ubuntu.com/23123469/ | 09:29 |
| ogra | nothing exciting | 09:29 |
| mvo | ogra: hm, snap changes? | 09:30 |
| mvo | ogra: and snap change 1 ? | 09:30 |
| ogra | ogra@localhost:~$ snap changes | 09:30 |
| ogra | error: no changes found | 09:30 |
| ogra | ogra@localhost:~$ snap change 1 | 09:30 |
| ogra | error: cannot find change with id "1" | 09:30 |
| ogra | and i guess if i greop for the model assertion error ... i will find the same thing | 09:31 |
| mvo | ogra: oh, yeah, I suspect that is the case | 09:31 |
| ogra | ogra@localhost:~$ sudo grep model /var/log/syslog | 09:31 |
| ogra | Sep 2 08:31:11 localhost kernel: [ 0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1 | 09:31 |
| ogra | Sep 2 08:31:12 localhost snap[2612]: error: need a model assertion | 09:31 |
| ogra | yeps | 09:31 |
| mvo | ogra: we are close to having a real model assertion | 09:31 |
| ogra | but first things first ... whatever sho7uld set snap_kernel and snap_core failed to do so | 09:31 |
| ogra | this only booted because i manually tweaked them | 09:32 |
| ogra | sigh ... and the user isnt in adm ... thats also painful | 09:32 |
| ogra | mvo, ARGH ! | 09:40 |
| ogra | http://paste.ubuntu.com/23123498/ | 09:41 |
| ogra | kernel is gone ... | 09:41 |
| ogra | i assume the vfat we create with u-i is different from what u-d-f did create | 09:41 |
| mvo | ogra: its gone now? | 09:45 |
| mvo | ogra: was it there before? | 09:45 |
| mvo | ogra: and vanished on boot? | 09:45 |
| ogra | i booted it a few times, yes | 09:45 |
| ogra | looks like something did an fsck | 09:45 |
| ogra | and moved the files to fsck000X.rec | 09:45 |
| ogra | i bet it doesnt get along with "pi2-kernel_11.snap/" not being 8+3 | 09:46 |
| ogra | for whatever reason | 09:47 |
| ogra | so i assume u-i creates the wrong type of vfat | 09:47 |
| mvo | uh, the fsck ones are indeed terrible | 09:47 |
| mvo | ogra: thats alarming | 09:47 |
| ogra | well, good that we hit it now :) | 09:48 |
| ogra | i ran the former u-d-f image for about a month ... with at least one reboot per day (for the new ubuntu-core) ... so i know the u-d-f setup was 100% robust | 09:48 |
| ogra | there must be something different in the vfat creation | 09:49 |
| mvo | ogra: let me fix that | 09:51 |
| ogra | +1 | 09:51 |
| mvo | ogra: I think (because the filesystem is small) it was auto-selecting fat16 | 09:52 |
| mvo | ogra: if you can boot it, there should be a way to verify | 09:52 |
| ogra | well, its an SD :) | 09:52 |
| mvo | ogra: heh, ok | 09:53 |
| ogra | Gerät Boot Start Ende Sektoren Größe Id Typ | 09:53 |
| ogra | bah | 09:53 |
| ogra | Gerät Boot Start Ende Sektoren Größe Id Typ | 09:53 |
| ogra | /dev/sdc1 * 2048 264191 262144 128M c W95 FAT32 (LBA) | 09:53 |
| ogra | /dev/sdc2 264192 61315071 61050880 29,1G 83 Linux | 09:53 |
| ogra | hmm | 09:53 |
| mvo | hm indeed | 09:54 |
| ogra | the start byte is different when i compare to an SD from u-d-f | 09:56 |
| ogra | 2048 vs 8192 | 09:56 |
| abeato | ogra, do you know if anybody has snapped x11 for rpi? | 09:56 |
| ogra | abeato, wont happen i guess | 09:56 |
| ogra | mvo, didnt you add some magic math to u-d-f back then for exactly that ? | 09:57 |
| ogra | i remember something like that | 09:57 |
| ogra | abeato, Mir and XMir is the answer ... | 09:57 |
| ogra | we wont allow plain X11 afaik | 09:57 |
| abeato | ogra, sure, but we do not have those yet, isn't it? | 09:58 |
| abeato | (snapped) | 09:58 |
| ogra | we do have mir | 09:58 |
| ogra | but we dont have images with graphics drivers | 09:58 |
| abeato | ogra, hmm, will that happen any time soon for rpi? | 09:59 |
| ogra | between RTM and GA | 09:59 |
| abeato | ogra, git it, thanks | 10:00 |
| abeato | *got it :p | 10:00 |
| ogra | mvo, i actually think it is the mkfs.vfat call that might differ in u-i | 10:05 |
| ogra | cmd := []string{"mkfs.vfat", "-F", "32", "-n", string(part.label)} | 10:05 |
| ogra | thats what u-d-f has | 10:05 |
| ogra | oh, and | 10:05 |
| ogra | if size != "512" { | 10:05 |
| ogra | cmd = append(cmd, "-s", "1") | 10:05 |
| ogra | } | 10:05 |
| ogra | cmd = append(cmd, "-S", size, dev) | 10:05 |
| ogra | it computes the exact sector size | 10:06 |
| ogra | (and hands it over to mkfs) | 10:07 |
| mvo | ogra: oh, interessting | 10:07 |
| ogra | i have a suspicion that we use something less reliable in u-i | 10:08 |
| ogra | like mtools instead of mkfs | 10:08 |
| ogra | (because the former doesnt need root) | 10:08 |
| mvo | ogra: u-i also uses mkfs.vfat | 10:10 |
| ogra | but with different options i guess | 10:10 |
| mvo | ogra: but different parameters, let me try settings -s1 | 10:10 |
| ogra | func sectorSize(dev string) (string, error) { | 10:11 |
| ogra | out, err := exec.Command("blockdev", "--getss", dev).CombinedOutput() | 10:11 |
| ogra | if err != nil { | 10:11 |
| ogra | that is what it uses to determine the size | 10:11 |
| joc_ | has there already been landings on master of snapd to prevent or change method for installing local unasserted snaps? | 10:11 |
| mvo | ogra: I think its ok to always force -s1 aiui if size is 512 -s1 is also used (implicitely) | 10:12 |
| ogra | blockdev --getss .... | 10:12 |
| mvo | sergiusens: do you remember why vfat -s1 was used? | 10:12 |
| mvo | sergiusens: in u-d-f? | 10:12 |
| ogra | mvo, note -s != -S | 10:13 |
| joc_ | ah, i found --force-dangerous, dont worry :) | 10:13 |
| ogra | -s SECTORS-PER-CLUSTER | 10:13 |
| ogra | Specify the number of disk sectors per cluster. Must be a power of 2, i.e. 1, 2, 4, 8, ... 128. | 10:13 |
| ogra | -S LOGICAL-SECTOR-SIZE | 10:13 |
| ogra | Specify the number of bytes per logical sector. Must be a power of 2 and greater than or equal to 512, i.e. 512, 1024, 2048, 4096, 8192, | 10:13 |
| ogra | 16384, or 32768. | 10:13 |
| ogra | we always append -S | 10:14 |
| mup | PR snapd#1832 opened: Added time-date-control interface for org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832> | 10:14 |
| ogra | and if != 512 we *also* append "-s 1" | 10:14 |
| mvo | ogra: oh, indeed | 10:14 |
| mvo | hm, leaving that out for now then | 10:15 |
| mvo | ogra: not even sure that will work on a file | 10:16 |
| ogra | ogra@anubis:~/datengrab/images/snappy$ sudo blockdev --getss /dev/sdc1 | 10:16 |
| ogra | 512 | 10:16 |
| ogra | ogra@anubis:~/datengrab/images/snappy$ sudo blockdev --getss /dev/sdc1 | 10:16 |
| ogra | 512 | 10:16 |
| ogra | they are both identical | 10:16 |
| ogra | (thats u-i vs u-d-f image) | 10:16 |
| ogra | hmm | 10:16 |
| ogra | though i should probably check *before* and fsck ran | 10:17 |
| * ogra re-flashes the u-i image | 10:17 | |
| ogra | s/and/any/ | 10:18 |
| ogra | yeah, stays 512 | 10:19 |
| mvo | ogra: do we have that candidate snap for ubuntu-core? or should I try to set it? | 10:31 |
| Son_Goku | morning! | 10:32 |
| ogra | just try to set it from this mornings build i guess | 10:32 |
| ogra | mvo, 421-426 | 10:33 |
| mvo | Son_Goku: hey, good morning. thanks for your mail, my world is terrible busy right now but I get back to you once we have finished our images deadlines | 10:33 |
| Son_Goku | images? | 10:34 |
| ogra | yes | 10:34 |
| Son_Goku | what images? | 10:34 |
| * Son_Goku is missing context | 10:34 | |
| ogra | snappy images :) | 10:35 |
| Son_Goku | ah | 10:35 |
| ogra | ubuntu-core + kernel snap + gadget snap ... | 10:35 |
| mvo | on real devices like pi2 etc | 10:35 |
| ogra | or pc's | 10:35 |
| ogra | :) | 10:35 |
| Son_Goku | ~_~ | 10:38 |
| Son_Goku | right, the thing I can't really do anything with at the moment | 10:38 |
| ogra | why not ? | 10:38 |
| * ogra runs a bunch of servers using these images(15.04 still though) | 10:38 | |
| ogra | and i'll convert this http://www.grawert.net/watchthesun/ to snap once we have finalized series 16 images :) | 10:39 |
| ogra | (and the rest of my house control) | 10:39 |
| Son_Goku | well, firstly, being Ubuntu is a bit of a problem (I'd like to have snappy Fedora/CentOS systems) | 10:39 |
| Son_Goku | second, even if I was okay with Ubuntu, I'm not okay with an EOL Ubuntu | 10:40 |
| ogra | series 16 will not be EOL before 2018 | 10:40 |
| ogra | long term we will also have phone and desktop images | 10:41 |
| ogra | (for now the focus is IoT, embedded, cloud and headless) | 10:41 |
| * ogra notes that people never recognize how old snappy actually is ... or that you can buy devices with it preinstalled since years :) | 10:43 | |
| ogra | every time i see a flatpack vs snaoppy discussion i see people claiming that snappy is something new ... it's three years old ... it just didnt get used on classic installs before :) | 10:44 |
| === hikiko is now known as hikiko|ln | ||
| sergiusens | mvo a review for Colin, I can maybe even fetch it | 10:46 |
| * sergiusens waves good morning | 10:46 | |
| ogra | moin | 10:46 |
| ogra | mvo, so did you do any changes regarding the vfat that i could try ? | 10:47 |
| ogra | else i'll move on to fiddle withj the pi3 gadget and later with the dragonboard | 10:47 |
| jgdx | using the gtk3 launcher, I get could not find or load the Qt platform plugin "xcb". Any suggestions? | 10:51 |
| mvo | ogra: not yet, sorry | 10:54 |
| mvo | ogra: I get the feeling pi2 is not going to happen today | 10:54 |
| mvo | ogra: just too many issues | 10:54 |
| ogra | mvo, well, we have time til friday, no ? | 10:55 |
| mvo | ogra: today is friday, no? | 10:55 |
| ogra | mvo, i mean next week ... i understood jamiebennett's mail that we postpone by a week | 10:56 |
| ogra | (which is actually wed. not fri, but definitely next week) | 10:56 |
| jamiebennett | ogra: A week from the original RTM which is Wed | 10:57 |
| ogra | right | 10:57 |
| jamiebennett | ogra: But of course we need to test before that | 10:57 |
| ogra | indeed | 10:57 |
| ogra | i'd say fri. is more realistic anyway :) ... | 10:57 |
| ogra | in any case though ... we need to fix the pi probs and also need dragonboard images | 10:58 |
| ogra | both are rtm targets | 10:58 |
| jamiebennett | ogra: So image spinning on Monday, testing and bug fixing Tues | 10:58 |
| ogra | jamiebennett, right ... the issue today is that pi2 images eat themselves after reboot ... the vfat gets trashed | 10:59 |
| jamiebennett | ouch | 10:59 |
| ogra | and we dont really knwo why | 10:59 |
| mvo | I really want an iamge (pc at least) today | 10:59 |
| ogra | we have working pc images, dont we ? | 10:59 |
| ogra | (apart from known cloud-init issues etc) | 10:59 |
| sergiusens | ogra mvo cannot find the MP, but most of the vfat logic comes from learnings of ubiquity | 11:00 |
| mvo | ogra: I mean end-to-end, with model assertion, snap asseritons | 11:01 |
| mvo | ogra: we have something that boots right now, thats all | 11:01 |
| ogra | mvo, well, then we need approval to postpone arm ... | 11:01 |
| ogra | i can surely get a dragonboard and pi3 gadget ready in time ... but if we dont fix the other bugs that wont help | 11:02 |
| sergiusens | ogra mvo and first partition we put at 8192 (it used to be 4096) to take into account most of those raw partition writes some devices use; 8192 was a recomendation from lool | 11:02 |
| mvo | ogra: well, like jamiebennett said, next week is fine for arm, its just that if we don't have a fully working pc image today, I think its going to be difficult for arm | 11:02 |
| mvo | ogra: arm needs everything thta pc needs plus more | 11:02 |
| jamiebennett | ack | 11:02 |
| ogra | also, what makes you sure the vfat corruption wont happen on x86 ? | 11:02 |
| mvo | ogra: same deal, we write much less to it | 11:02 |
| mvo | ogra: but yeah, same concern | 11:02 |
| ogra | right | 11:02 |
| sergiusens | I would really partition those vfats like we did in u-d-f | 11:03 |
| ogra | sergiusens, yeah | 11:03 |
| sergiusens | maybe cjwatson can review ubuntu-image? | 11:03 |
| ogra | did he review udf ? :) | 11:03 |
| ogra | we really only need to make it identical | 11:03 |
| sergiusens | ogra s512 and all that magic logic comes from his review | 11:03 |
| ogra | ah ! | 11:03 |
| sergiusens | ogra I started with that? :-) | 11:04 |
| sergiusens | ogra Colin's learnings from ubiquity ;-) | 11:04 |
| ogra | well, what i definitely see is that the two vfats start at different bytes on the different SD cards here | 11:04 |
| ogra | start byte -> 2048 vs 8192 | 11:05 |
| ogra | inspecting them beyond that doesnt reveal any differences | 11:05 |
| sergiusens | ogra might be some broken magic on ubuntu-image? | 11:06 |
| === drizztbsd is now known as timothy | ||
| ogra | it seems to use the same mkfs.vfat command | 11:06 |
| sergiusens | joc_ hey, mind looking at this https://github.com/snapcore/snapcraft/pull/771/files and maybe trying to build plainbox with it? | 11:09 |
| cjwatson | sergiusens: well, I know how partitioning works in general but I know absolutely nothing about the logic that ubuntu-image is seeking to apply | 11:09 |
| cjwatson | 8192*512 == 4MiB which I would agree is most likely to be aligned on suitable boundaries | 11:10 |
| ogra | 274 if part.filesystem is FileSystemType.vfat: # pragma: nobranch | 11:10 |
| ogra | 275 run('mkfs.vfat {}'.format(part_img)) | 11:10 |
| ogra | woah ... | 11:10 |
| ogra | so i'm wrong | 11:10 |
| cjwatson | (1MiB is a bit more typical but even a few years ago I was hearing rumblings about some media using 4MiB) | 11:10 |
| ogra | we run mkfs.vfat totalyl witrhout any options | 11:10 |
| ogra | while we apply a good bunch in u-d-f | 11:10 |
| sergiusens | cjwatson thanks, it seems ogra found the culprit ;-) | 11:10 |
| cjwatson | mkfs.vfat at least used to require some moderately exotic options to get things right | 11:11 |
| ogra | yes | 11:11 |
| ogra | and in u-d-f we use them ... | 11:11 |
| joc_ | sergiusens: thanks for heads up, i might ask one of the other checkbox devs to try as i'm a bit deep in to some snapd stuff right now | 11:12 |
| cjwatson | -F fat32 plus an -S option set to the logical sector size of the device in question, IIRC | 11:12 |
| === chihchun is now known as chihchun_afk | ||
| ogra | yep | 11:12 |
| cjwatson | and maybe -n | 11:12 |
| ogra | plus -s 1 of the sector size isnt 512 or some such | 11:12 |
| ogra | and yes, -n | 11:12 |
| ogra | s/of/if/ | 11:12 |
| === Guest84579 is now known as antdillon | ||
| ogra | http://paste.ubuntu.com/23123789/ is the code we use in u-d-f | 11:14 |
| ogra | (sectorSize is the return value of blockdev --getss) | 11:15 |
| ogra | oh man ... and looking at line 22 in that paste i guess we can be happy that it never hit that code path :P | 11:16 |
| ogra | "mkfs.ext4", "-F", "-L", string(part.label), dev .... | 11:17 |
| ogra | (i doubt -F works without value) | 11:17 |
| ogra | oh | 11:18 |
| ogra | heh | 11:18 |
| ogra | thats ext4 | 11:18 |
| sergiusens | !! | 11:18 |
| ogra | ignore my babbling :P | 11:18 |
| mup | PR snapd#1806 closed: overlord/devicestate: set device registration URLs <Critical> <Reviewed> <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1806> | 11:30 |
| mup | PR snapd#1822 closed: snapd.refresh.service: require snap.socket and /snap/*/current <Reviewed> <Created by stolowski> <Conflict> <https://github.com/snapcore/snapd/pull/1822> | 11:30 |
| mup | PR snapd#1824 closed: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1824> | 11:30 |
| cjwatson | Right, I believe the account-key work is now code-complete and "just" needs four layers of stuff to be reviews/fixed/landed/deployed | 11:31 |
| cjwatson | *reviewed | 11:31 |
| === hikiko|ln is now known as hikiko | ||
| cjwatson | (remaining snapd/asserts fixes for checking account-key-request; snap-assertions-service endpoint to do likewise; software-center-agent changes to account-key endpoint to use that; snapcraft PR to add register-key) | 11:34 |
| sborovkov | jamiebennett: ping | 11:39 |
| jamiebennett | sborovkov: Sorry, was at lunch, around now | 12:10 |
| sborovkov | jamiebennett: Hello. Who can I ask about store issue? Can't install snap on classic again from our store. I am logged in with snap login and have correct variable in /etc/environment :( | 12:12 |
| jamiebennett | sborovkov: What do you mean by "Can't install snapp", is the snap available with a snap find? | 12:12 |
| sborovkov | jamiebennett: No. snap find --private is not working as well. Snap is published in our store and it was working before. With snap intsall --devmode --edge screenly-client | 12:15 |
| jamiebennett | sborovkov: and what does snap --version say? | 12:16 |
| sborovkov | jamiebennett: 2.14.1 | 12:17 |
| sborovkov | I tried proposed when the latest stable was not working | 12:17 |
| sborovkov | nothing changed | 12:17 |
| jamiebennett | so you have the latest and now it breaks your store, nothing else changed? If not then maybe mvo knows of a recent change that may have affected this | 12:18 |
| jamiebennett | let me look at the code | 12:18 |
| jamiebennett | sborovkov: what was the last working snapd version you tried? | 12:19 |
| sborovkov | I am pretty sure 2.11 was working | 12:20 |
| sborovkov | I reflashed after that because my SD card broke. And after apt upgrade I was not able to install snap from the screenly store anymore | 12:20 |
| sborovkov | I saw some that there were some commits related to getting store id. May be it broke during that. But that's just guessing. | 12:22 |
| sergiusens | joc_ where does plainbox live? | 12:23 |
| jamiebennett | sborovkov: I'm looking into it now, will get back to you shortly | 12:23 |
| Son_Goku | ogra, well, snappy as it exists today didn't exist more than a year or so | 12:24 |
| sborovkov | jamiebennett: thanks | 12:24 |
| jamiebennett | sborovkov: have you tried snap revert ubuntu-core to see if a previous snapd works? | 12:25 |
| cyphermox | ogra: hey, u-i work needed? | 12:25 |
| mvo | sborovkov: what env var are you using? UBUNTU_STORE_ID? | 12:26 |
| ogra | cyphermox, not atm, no | 12:26 |
| joc_ | sergiusens: lp:checkbox | 12:26 |
| popey | sergiusens: can you help me with fixing a snap where there is a dupe between two parts? | 12:26 |
| sergiusens | popey ok | 12:27 |
| sborovkov | mvo: yes | 12:27 |
| popey | sergiusens: ok, lemme prep | 12:27 |
| sergiusens | popey but I have father and son time starting in 3 minutes (aka baby sitting) | 12:27 |
| sborovkov | jamiebennett: Oh, no I did not try that. I checked apt cache for previous versions but did not think of that | 12:27 |
| sergiusens | so I might take a bit | 12:27 |
| joc_ | sergiusens: you might be most interested in this project though https://code.launchpad.net/~checkbox-dev/plainbox-provider-snappy/+git/packaging/+ref/master | 12:28 |
| popey | sergiusens: http://paste.ubuntu.com/23123924/ | 12:28 |
| sborovkov | jamiebennett: what would be the syntax to get 2.11? | 12:28 |
| sergiusens | joc_ whatever is needed to build the snap ;-) | 12:29 |
| jamiebennett | sborovkov: just snap revert ubuntu-core until you get there | 12:29 |
| popey | sergiusens: ok, run that, it fails - minetest and minetestgame parts both have a minetest.conf.example in them, which fails to snapcraft, so I added line 31/32 to exclude it, but that fails with:- | 12:29 |
| popey | Stepping over existing file for organization 'games/minetest_game' | 12:29 |
| popey | [Errno 2] No such file or directory: '/home/alan/Development/Snappy/github_snappy_playpen/snappy-playpen/minetest/parts/minetestgame/install/*' | 12:29 |
| popey | which I don't get? | 12:29 |
| jamiebennett | sborovkov: try each version as you revert though, maybe we can pinpoint the exact release | 12:29 |
| joc_ | sergiusens: yep that last repo has the yaml to look at then | 12:30 |
| joc_ | sergiusens: hopefully spineau will be here soon as he was most recently looking at building plainbox using the python3 plugin | 12:30 |
| sergiusens | joc_ oh, it is not yet? then great ;-) | 12:31 |
| joc_ | sergiusens: nope currently we are pulling it from pypi | 12:31 |
| sergiusens | joc_ the python plugin rewrite I did is a bit special wrt filesets because it doesn't mix stage-packages and pypi/pip ones | 12:31 |
| sergiusens | oh, pulling from pypi and using it locally should be almost the same thing | 12:32 |
| sborovkov | jamiebennett: Wait how does that work? snap list tells me there are no installed snaps. snap revert ubuntu-core tells me there is no revision to revert to. I guess I am doing something wrong? | 12:32 |
| joc_ | sergiusens: yeah this was what was need to fix our weird repo layout problem https://github.com/snapcore/snapcraft/pull/751 | 12:32 |
| mup | PR snapcraft#751: python3 plugin: run setup.py in source subdir if such option exists <Created by yphus> <https://github.com/snapcore/snapcraft/pull/751> | 12:32 |
| sergiusens | popey does this work '*': 'games/minetest_game/' ? I have a bug to implement that iirc | 12:32 |
| jamiebennett | sborovkov: snap install ubuntu-core | 12:33 |
| popey | sergiusens: it used to. | 12:33 |
| mvo | sborovkov: silly question (sorry if its obvious), but since you added it to the environment did you restart snapd since changing /etc/environment? | 12:33 |
| jamiebennett | sborovkov: but wait | 12:33 |
| popey | sergiusens: something changed in 2.14 (copy -> dump i think) which broke it all | 12:33 |
| mvo | sborovkov: I looked at the code and it appears to be ok, let me dig some more | 12:33 |
| jamiebennett | sborovkov: that won't help | 12:33 |
| sborovkov | mvo: Yes, system was restarted few times since then | 12:33 |
| jamiebennett | sborovkov: mmm | 12:33 |
| sborovkov | mvo: May be I can enable some logging? | 12:33 |
| sborovkov | SNAPD_DEBUG_HTTP or something like that? | 12:34 |
| sergiusens | joc_ oh I missed that one, it is fixed here too btw https://github.com/snapcore/snapcraft/pull/771/files | 12:34 |
| jamiebennett | sborovkov: actually try snap install ubuntu-core | 12:34 |
| sergiusens | along with a bunch of other things | 12:34 |
| mvo | sborovkov: yes, if you set this to "7" it should print something | 12:34 |
| jamiebennett | sborovkov: then snap revert it | 12:34 |
| mvo | sborovkov: sudo systemctl stop snapd.service snapd.socket to stop the existing one | 12:35 |
| mvo | sborovkov: and sudo /lib/systemd/systemd-activate -E SNAPD_DEBUG=1 -l /run/snapd.socket -l /run/snapd-snap.socket /usr/bin/snapd to see the output | 12:35 |
| mvo | sborovkov: uh, add a -E with the debug env here :) | 12:35 |
| sborovkov | mvo: Did not it print info to state.json and syslog before? or did that change | 12:35 |
| mvo | sborovkov: and another -E with the UBUNTU_STORE_ID | 12:35 |
| sborovkov | ok, going to get logs and the start reverting | 12:35 |
| mvo | sborovkov: yeah, syslog will also have it | 12:36 |
| popey | sergiusens: never mind, I'll grab you next week :) | 12:36 |
| spineau | o/ | 12:37 |
| mvo | sborovkov: just double checked, the logging should hopefully be sufficient | 12:37 |
| ogra | argh ! | 12:38 |
| ogra | so i tried my third ubuntu-image change now always ending with corrupt fs | 12:38 |
| * ogra slaps mvo | 12:38 | |
| ogra | source: https://github.com/mvo5/ubuntu-image.git | 12:38 |
| ogra | tsk | 12:38 |
| * ogra fixes snapcraft.yaml to use source: . | 12:39 | |
| joc_ | hey spineau, sergiusens just pointed this out: | 12:39 |
| mvo | ogra: you can just run via sudo ./ubuntu-image | 12:39 |
| spineau | sergiusens: hello, I'll test your PR (https://github.com/snapcore/snapcraft/pull/771/files) and see if we can still use plainbox and if it solves our issue to use it from source. | 12:39 |
| mvo | ogra: no need to snap it all | 12:39 |
| ogra | oh, that finds all the modules? | 12:39 |
| spineau | sergiusens: probably not today but on my todo for Monday | 12:40 |
| mvo | ogra: yes | 12:40 |
| ogra | ah, k | 12:40 |
| mvo | ogra: just make sure you have a snapd that is sufficiently new, maybe from the ppa | 12:40 |
| ogra | and i was wondering why my changes had no effect at all | 12:40 |
| mvo | ogra: but for the fs tests I think its ok | 12:40 |
| mvo | ogra: but you do see fs corruption constantly? | 12:40 |
| joc_ | spineau: yeah apparently 771 should fix the issue in your PR 751 | 12:41 |
| ogra | mvo, but source: https://github.com/mvo5/ubuntu-image.git inside the snapcraft.yaml that is in https://github.com/mvo5/ubuntu-image.git it pretty redundant :) | 12:41 |
| mvo | ogra: fair enough | 12:41 |
| ogra | mvo, yes, after second or third reboot | 12:41 |
| ogra | - run('mkfs.vfat {} {}'.format(fslabel, part_img)) | 12:41 |
| ogra | + run('mkfs.vfat -F 32 -S 512 -s 1 -n {} {}'.format(fslabel, part_img)) | 12:41 |
| spineau | joc_: excellent. thanks | 12:41 |
| ogra | thats what i'm trying to try | 12:42 |
| ogra | hmm | 12:42 |
| ogra | i shoudl drop -s 1 again ... that was just out of desparation | 12:42 |
| * ogra does so and rolls a new image | 12:42 | |
| sborovkov | mvo: https://paste.kde.org/piqe5px4r/805roo Did 2 installations attempts. Before the second one I logged in again... Since I remember it timing out before. So just in case. not that it made a difference | 12:43 |
| sborovkov | JamieBennett: mvo: I also can't install ubuntu-core before I remove UBUNTU_STORE_ID=screenly from /etc/environment. But I guess that's expected since my store does not have it? | 12:45 |
| JamieBennett | sborovkov, right | 12:45 |
| * ogra would add the env var to snapd's systemd unit instead ... | 12:45 | |
| ogra | saves you the reboot | 12:45 |
| sborovkov | JamieBennett: mvo: Haha. It's working now. | 12:46 |
| JamieBennett | sborovkov, what did you do? | 12:46 |
| sborovkov | after installing ubuntu-core | 12:46 |
| sborovkov | I switched back to my store | 12:46 |
| sborovkov | and it started installing it! | 12:46 |
| zyga_ | jdstrand, tyhicks: is there any other (easier) way to check that a given directory is a mount point (bind mount to be precise) than to parse /proc/self/mountinfo? | 12:46 |
| === zyga_ is now known as zyga | ||
| mvo | sborovkov: d'oh - thank you | 12:46 |
| mvo | sborovkov: that is an interessting bug | 12:46 |
| JamieBennett | mvo, right | 12:47 |
| sborovkov | Yeah, it was working before | 12:47 |
| mvo | sborovkov: the "can not find snap" error is real, but it refers to ubuntu-core :( | 12:47 |
| JamieBennett | mvo, seems you can't see snaps in a custom store if you don't have ubuntu-core installed? | 12:47 |
| JamieBennett | mvo, ah | 12:47 |
| sborovkov | oh, now it's clear yeah | 12:47 |
| sborovkov | too bad there is no name | 12:47 |
| mup | PR snapd#1833 opened: many: spell --force-dangerous as just --dangerous, devmode should imply it <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1833> | 12:47 |
| mvo | sborovkov: yeah, definitely another silly UI bug | 12:48 |
| JamieBennett | sborovkov, your paste includes a password, best to change that now ;) | 12:48 |
| sborovkov | JamieBennett: oops | 12:49 |
| JamieBennett | sborovkov, mvo actually it does show the missing snap name | 12:49 |
| JamieBennett | Sep 2 12:39:52 ubuntu /usr/lib/snapd/snapd[4979]: logger.go:66: DEBUG: > "GET /api/v1/snaps/details/ubuntu-core? | 12:50 |
| sborovkov | JamieBennett: mvo: One more question. I noticed that snap login would time out after some time. Is there some recommended way I can stay logged in? Also. Since my snap is in --devmode it would not get updated automatically? Should I just add cronjob to periodically do snap refress --devmode --edge screenly-client? | 12:51 |
| JamieBennett | sborovkov, we use macaroons for store login that expire after a set amount of time | 12:52 |
| mvo | I think the timeout is a bug, matiasb_ knows more | 12:53 |
| JamieBennett | sborovkov, for refreshing cron would work, yes | 12:54 |
| matiasb_ | sborovkov, mvo, since 2.13 I think, auth refresh is in place and that should handle automatic refresh of macaroons in the background | 12:55 |
| mvo | niemeyer: did we decide against automatic refresh of --devmode snaps? or is the fact thta this is not happening yet a bug? | 12:55 |
| sborovkov | understood, thanks guys | 13:03 |
| ogra | pitti, i'm going mad here ... can i somehow teach netplan to not set the NIC up tio get a different IP at every reboot ? | 13:16 |
| * ogra tries to do scripted reboots via ssh ... that behaviour is rather counter-productive if you need to do 50 reboots | 13:17 | |
| ogra | GRRRRR | 13:18 |
| ogra | error: bad user result: cannot create user "ogra@ubuntu.com": Get | 13:18 |
| ogra | https://login.ubuntu.com/api/v2/keys/ogra%40ubuntu.com: dial tcp: lookup | 13:18 |
| ogra | login.ubuntu.com on [::1]:53: read udp [::1]:33128->[::1]:53: read: | 13:18 |
| ogra | connection refused | 13:18 |
| ogra | whyx is *everything* broken today | 13:18 |
| ogra | yeah, crap ... doesnt look like i can get console-conf out of this | 13:20 |
| cyphermox | ogra: pi2? | 13:21 |
| ogra | yeah | 13:21 |
| cyphermox | yeah, nuke sit0 | 13:21 |
| cyphermox | I'll patch this in console-conf, it's annoying | 13:21 |
| ogra | well, i didnt need to do that the last 20 boots | 13:21 |
| ogra | and a hard reset worked (apart from the fact that i have nearly seen all my 254 free IP adresses my dhcp server provides) | 13:22 |
| ogra | and indeed i get a new ssh key every boot | 13:23 |
| ogra | mvo, no go ... no matter what mkfs.vfat options i use ... it reliably eats itself on second reboot | 13:24 |
| ogra | i have tried all combos now ... it must be the img creation itself that interferes somehow | 13:24 |
| ogra | not just the missing filesystem options | 13:25 |
| * ogra is desparate | 13:25 | |
| ogra | and i'm convinced this will bite us on all vfats | 13:25 |
| Kaleo | jdstrand, we have an app in a snap connected to the home interface which requests a thumbnail of an image in the home folder to the thumbnailer service via dbus, the thumbnailer service uses aa_query_label to verify that the app has indeed the rights to read that file and it returns a non 0 value indicating that the app does not have access | 13:25 |
| ogra | even on grub based ones | 13:25 |
| Kaleo | jdstrand, any idea what might cause that? | 13:25 |
| ogra | (even if it will take longer til it shows up there) | 13:25 |
| mvo | ogra: we talked about it in the meeting just now, can we remove the ubuntu user | 13:26 |
| ogra | mvo, well ... that makes debugging rather hard when doing bringup atm ... | 13:27 |
| ogra | but technically we can indeed | 13:27 |
| ogra | (i guess we still need to create empty extrausers files) | 13:27 |
| ogra | mvo, though i dont really see alöl this as releasable if we dont find the cause for the vfat stuff ... i doubt grub images will be any more reliable | 13:28 |
| ogra | it will just show up later since we write to the fat less | 13:28 |
| ogra | but after all all vfats are created the same | 13:29 |
| ogra | which makes it very likely they will all expose the same corruption | 13:29 |
| ogra | sooner or later | 13:29 |
| ogra | mvo, also ... since the IP changes every boot, how do you find the IP for your login when you can only log in via ssh now | 13:30 |
| ogra | (wont really affect kvm where you can use localhost indeed) | 13:31 |
| notadeveloper_ | hi ogra | 13:32 |
| notadeveloper_ | is there a video support for raspi on snappy core | 13:33 |
| notadeveloper_ | rasp pi 3 | 13:33 |
| ogra | not yet, no | 13:33 |
| notadeveloper_ | video playback | 13:34 |
| cyphermox | maybe libaa? :) | 13:34 |
| ogra | we dont ship it ... so only in devmode :) | 13:34 |
| cyphermox | oh, right | 13:34 |
| ogra | but yeah, libaa could work :) | 13:35 |
| ogra | you just have to go very far away from your screen :) | 13:35 |
| niemeyer | mvo: We explicitly decided against the refresh | 13:37 |
| niemeyer | mvo: Sorry, ECONTEXT probably... responding to that earlier question about refreshes in devmode | 13:38 |
| mup | PR snapd#1834 opened: many: mostly work to support ABA upgrades <Created by chipaca> <https://github.com/snapcore/snapd/pull/1834> | 13:38 |
| mvo | niemeyer: yeah, thats fine, it was a question from a user who was wondering about it | 13:39 |
| mvo | niemeyer: I remembed this too, but wanted to confirm | 13:39 |
| niemeyer | mvo: This was an alternative to another behavior that was discussed in that same meeting in Heidelberg | 13:39 |
| niemeyer | mvo: The idea was taking it out of devmode on update | 13:39 |
| niemeyer | mvo: Which felt very awkward to me.. so between that and blocking the update, I voted for the latter | 13:40 |
| mvo | niemeyer: indeed, I remember now | 13:41 |
| notadeveloper_ | just to make sure | 13:43 |
| notadeveloper_ | is there a video support for raspi on snappy core | 13:43 |
| notadeveloper_ | video playback | 13:43 |
| ogra | no | 13:43 |
| mup | PR snapd#1835 opened: Support noneSecurityTag keyed snippets in udev backend <Created by jocave> <https://github.com/snapcore/snapd/pull/1835> | 13:43 |
| notadeveloper_ | only webplayback | 13:43 |
| joc_ | niemeyer: hi, thanks for getting the PR that you took over in last night, i think that ^ might be needed however | 13:44 |
| ogra | notadeveloper_, cyphermox was joking ... libaa translates your video into ascii to play it in a terminal | 13:44 |
| niemeyer | sborovkov: The notes slightly above are context for why the refreshes don't happen in devmode | 13:45 |
| niemeyer | joc_: Heya, thanks, looking | 13:45 |
| * ogra cries a little | 13:48 | |
| niemeyer | joc_: reviewed | 13:55 |
| joc_ | thx | 13:56 |
| plars | Is there a way to use conditionals in the snapcraft.yaml? For instance, I have a dependency I need for build-packages on x86 (gcc-multilib) that doesn't exist on arm64. We already avoid building that piece on arm64, but snapcraft still tries to install the build-package and fails | 13:58 |
| === bull is now known as bulldog | ||
| bulldog | hello from bulldog | 13:59 |
| bulldog | :) | 13:59 |
| ogra | mvo, http://paste.ubuntu.com/23124139/ ... this is the first boot !! | 14:00 |
| bulldog | guys updates on snapcraft-gui plz check it out here https://github.com/keshavbhatt/snapcraft-gui#screenshot | 14:00 |
| bulldog | ogra, hi :) | 14:01 |
| niemeyer | joc_, _morphis; How's the outlook for all these interfaces? Do we need anything pending other than that branch? | 14:02 |
| ogra | mvo, it seems to actually fall over on . and .. | 14:02 |
| bulldog | mhall119, popey , guys check out the implemented features here feedback plz https://github.com/keshavbhatt/snapcraft-gui#current-task | 14:02 |
| ogra | ?!? | 14:03 |
| niemeyer | Sorry, I know we have things up for review.. are they ready? | 14:03 |
| ogra | Bad short file name (.). | 14:03 |
| morphis | joc_: for serial-port and hidraw joc_ put everything up afaik | 14:03 |
| ogra | Bad short file name (..). | 14:03 |
| ogra | this is just insane ! | 14:03 |
| morphis | niemeyer: ^^ | 14:03 |
| joc_ | niemeyer: i haven't managed to confirm everything works yet, need to confirm the udev rules do what expected | 14:03 |
| mvo | ogra: hm, did you try to use the options from u-d-f? this did not make a difference when building pi2 images? | 14:04 |
| niemeyer | bulldog: Wow, nice.. hadn't seen that | 14:04 |
| bulldog | niemeyer, thanks :) | 14:04 |
| ogra | mvo, right ... i tried with onlöy -F 32 ... i tried with any combo of -F 32 and -S 512 ... and even with -s 1 | 14:04 |
| ogra | no change | 14:04 |
| ogra | and look at the fsck output above | 14:05 |
| niemeyer | ogra: Haha, that's great | 14:05 |
| bulldog | niemeyer, its not fully ready yet but everything is coming so fast in few days it will able to snap out packages :) | 14:05 |
| ogra | niemeyer, well, it makes *all* images eat the vfat at some point | 14:05 |
| ogra | niemeyer, if we dont get that fixed, i'd say forget about any release | 14:05 |
| mvo | ogra: so -F 32 -S 512 -s 1 (what u-d-f is doing) did not help | 14:05 |
| ogra | mvo, right | 14:05 |
| ogra | mvo, but i totally dont get how i can have . and .. in a vfat dir at all | 14:06 |
| ogra | (or why systemd would choke on it) | 14:06 |
| ogra | (well, actually fsck.fat) | 14:06 |
| mvo | ogra: yeah, its fsck | 14:06 |
| ogra | mvo, i dont think u-d-f actually uses -s 1 | 14:07 |
| ogra | given that the size is actualyl 512 | 14:07 |
| ogra | so that code wont kick in | 14:07 |
| ogra | (but i tested both ) | 14:08 |
| bulldog | no one wana contribute in snapcraft gui , damn but am not giving up this early :D | 14:09 |
| ogra | mvo, i wonder if it is actually not the filesystem but actually the files ... since we use mtools to copy them | 14:10 |
| ogra | 330 run('mcopy -s -i {} {} ::'.format(part_img, sourcefiles), | 14:10 |
| ogra | 331 env=dict(MTOOLS_SKIP_CHECK='1', PATH=os.environ["PATH"])) | 14:10 |
| ogra | MTOOLS_SKIP_CHECK='1' ... i wonder what check that actually skips :P | 14:11 |
| ogra | aha | 14:12 |
| ogra | All the Mtools commands perform a few sanity checks | 14:12 |
| ogra | before going ahead, to make sure that the disk is indeed an MS-DOS disk (as opposed to, say an ext2 or MINIX disk). These checks may reject par‐ | 14:12 |
| ogra | tially corrupted disks, which might otherwise still be readable. To avoid these checks, set the MTOOLS_SKIP_CHECK environmental variable or the | 14:12 |
| ogra | corresponding configuration file variable (see section global variables) | 14:12 |
| * ogra drops that and builds an image ... lets see if it errors | 14:13 | |
| ogra | hmm, no errors with it dropped | 14:15 |
| === kyle is now known as Guest73706 | ||
| Guest73706 | Is there a list of currently supported distros? Roadmap for support? especially Linux Mint | 14:32 |
| === matiasb_ is now known as matiasb | ||
| ogra_ | Guest73706, if you use an ubuntu kernel on mint i dont see a reason why it wouldnt work | 14:38 |
| ogra_ | zyga, ^^^ your area :) | 14:39 |
| ogra_ | (as long as it is 16.04 based at least) | 14:40 |
| mvo | ogra_: no errors means no more fsck errors? | 14:41 |
| ogra_ | mvo, no, i was hoping about errors from mcopy ... whoever did put MTOOLS_SKIP_CHECK='1' there must have had a reason | 14:41 |
| ogra_ | wow | 14:44 |
| ogra_ | the output of fsck is different every time | 14:45 |
| ogra_ | http://paste.ubuntu.com/23124260/ vs http://paste.ubuntu.com/23124139/ | 14:46 |
| sborovkov | mvo: Just one more question. Were there some breaking changes after snapcraft's updates? I have snap built from today in store. Previous version is from few weeks ago. If I unpublish only the latest revision I can't install snap from store as well. (I would check with sideloading, but it's not working on classic) | 14:47 |
| zyga | Guest73706: hey, can you please repeat the question | 14:48 |
| mvo | sborovkov: snapcraft is something that sergiusens known more about | 14:48 |
| ogra_ | zyga, <Guest73706> Is there a list of currently supported distros? Roadmap for support? especially Linux Mint | 14:48 |
| mvo | sborovkov: so you unpublished a version and the previous one is not found? | 14:49 |
| sborovkov | yes, I unpublished revision. After that snap install says snap not found. As soon as I publish it again it gets installed | 14:49 |
| mvo | sborovkov: the store UI can be slightly confusing sometimes, can you doublle check that its published in a channel? there is a "overview" link. | 14:49 |
| mvo | sborovkov: but there is a previous version that it should find and its in the right channel :/ ? is that what you are saying? | 14:49 |
| sborovkov | mvo: Yes. In the UI it shows the latest revision as not published (with the hand showing that it's ok. previous one is green and shown as published when I click on details) | 14:52 |
| Pharaoh_Atem | zyga: have you tested my SELinux module yet on Fedora 24? | 14:52 |
| zyga | Guest73706: hey, currently various distros are supported, I believe mint works (just not the last stable version but the one under development now) | 14:52 |
| zyga | Pharaoh_Atem: no, still stuck with mount namespace sharing | 14:52 |
| mvo | sborovkov: nessita may be able to help here, this sounds like the store is not quite correct | 14:53 |
| Guest73706 | great to hear! So for status, I would look under mint's development tracking or snappy's? | 14:54 |
| zyga | Pharaoh_Atem: I need some time to breathe but that's not likely to happen this week | 14:54 |
| zyga | Pharaoh_Atem: I wish I had 48 hours a day | 14:54 |
| sborovkov | nessita: Hello, any ideas about why what I descibed above is happening? Is it a bug or expected behavior? | 14:54 |
| mup | PR snapd#1833 closed: many: spell --force-dangerous as just --dangerous, devmode should imply it <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1833> | 14:57 |
| nessita | sborovkov, hi, what package is this? | 14:57 |
| zyga | Guest73706: I think mint inherits snappy from ubuntu, just try the latest version of mint | 14:58 |
| zyga | Guest73706: it it doesn't work I'd love to know | 14:58 |
| Guest73706 | awesome, thanks! | 15:00 |
| sborovkov | nessita: well, it's in private store | 15:02 |
| sborovkov | nessita: sorry, had to reboot my pc. My keyboard went crazy. It's for my package in our store. I can give any info I can. Just ask whatever that will be helpful :) | 15:03 |
| ogra_ | zyga, will be interesting if it actualyl works with all the hackery mint does :) | 15:03 |
| ogra_ | (i.e. i have seen releases where they patched libc but kept the package name identical and such) | 15:03 |
| zyga | ogra_: that shouldn't matter | 15:04 |
| ogra_ | (... and the version so it pretended to be ours) | 15:04 |
| ogra_ | zyga, haha ... ask xnox ... he had his share of fun with mint hacked libs :) | 15:04 |
| ogra_ | (as well as i did) | 15:04 |
| zyga | ogra_: well, it doesn't matter what glibc you have, that is my point | 15:05 |
| ogra_ | zyga, if essential functions are patched to work completely different it does :) | 15:05 |
| tyhicks | zyga: I don't know of an easier way to check if a path is a mount point | 15:06 |
| zyga | ogra_: like? | 15:07 |
| zyga | tyhicks: that's okay, | 15:07 |
| zyga | tyhicks: if you want, I have something to pre-review | 15:07 |
| zyga | tyhicks: and perhaps a bug in apparmor | 15:07 |
| ogra_ | zyga, dunno :) | 15:07 |
| tyhicks | zyga: show me what you got | 15:07 |
| zyga | tyhicks: OK | 15:08 |
| tyhicks | zyga: fyi, Jamie is out today | 15:08 |
| tyhicks | (security Jamie) | 15:08 |
| mup | PR snapd#1822 closed: snapd.refresh.service: require snap.socket and /snap/*/current <Reviewed> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1822> | 15:10 |
| zyga | tyhicks: yep, I know | 15:11 |
| tyhicks | ok | 15:11 |
| nessita | sborovkov, what's the package id? is in the URL in the myapps.developer.ubuntu.com site | 15:14 |
| sborovkov | nessita: bvBwbB7aeomIdJxpQh9lakQByyJtyKXp | 15:17 |
| nessita | sborovkov, thanks, let me check | 15:19 |
| zyga | tyhicks: ok, let me push my branch now, sorry, I took a moment to add various notes | 15:19 |
| tyhicks | no problem | 15:21 |
| zyga | tyhicks: pushed | 15:21 |
| zyga | er | 15:21 |
| zyga | hmmm | 15:21 |
| zyga | still pushing | 15:21 |
| nessita | sborovkov, so your revno 9 is ready to be published, but right now is not published in the store (see the thumbs up next to the #9 to the left, vs the green boxes for the other revnos) | 15:21 |
| nessita | sborovkov, also, if you check https://myapps.developer.ubuntu.com/dev/click-apps/5407/configurations/ (private URL only you and me can access) you can see the revision summary for your package | 15:22 |
| nessita | sborovkov, does that match your expectations? | 15:22 |
| tyhicks | zyga: pushed where? | 15:23 |
| zyga | tyhicks: sorry, back to the main repo, I had to fiddle with keys and tokens | 15:24 |
| zyga | it's there now | 15:24 |
| zyga | tyhicks: https://github.com/snapcore/snap-confine/tree/ns-sharing | 15:24 |
| mup | PR snapd#1836 opened: overlord/state: fix for reloaded task/change crashing on Set if checkpointed w. no custom data yet <Created by pedronis> <https://github.com/snapcore/snapd/pull/1836> | 15:25 |
| mup | PR snapd#1837 opened: [WIP] Add refresh-control header to snap-declaration assertion <Created by ralsina> <https://github.com/snapcore/snapd/pull/1837> | 15:25 |
| zyga | tyhicks: configure it ./configure --prefix=/usr --libexecdir=/usr/lib/snapd/ --enable-nvidia-ubuntu --enable-maintainer-mode | 15:25 |
| zyga | tyhicks: and give it a try (read it as well :) | 15:25 |
| zyga | tyhicks: this is my main priority so I'll be here in case you figure anything out | 15:25 |
| sborovkov | nessita: I unpublished latest revision. Since revision 8 is published should not it get installed? | 15:25 |
| zyga | tyhicks: if you want a quick cut-to-the-chase https://github.com/snapcore/snap-confine/compare/ns-sharing?expand=1#diff-c3983658fdc823eef69accc8537b27f0R243 | 15:26 |
| nessita | sborovkov, for arch armhf and channels beta and edge, yes. Is that not working for you? | 15:26 |
| zyga | tyhicks: I use a hat to confine the child process | 15:26 |
| zyga | tyhicks: pehrpas overkill, perhaps not | 15:26 |
| sborovkov | nessita: nope. says snap not found. As soon as I publish revision 9 - I can install it again without any issues. But not rev 8 | 15:27 |
| nessita | sborovkov, also are you trying to install with snapd? let me confirm if snapd works with the non default store | 15:27 |
| nessita | sborovkov, are you exporting the proper env vars to use your private store? | 15:28 |
| sborovkov | nessita: Yup. Because it works when revision 9 is published. | 15:28 |
| nessita | sborovkov, ok, and how are you trying to install revno 8? (just asking the basic to troubleshoot without missing anything) | 15:29 |
| sborovkov | With the same command snap install --devmode --edge screenly-client. Since it's the latest published I expect it to be installed | 15:29 |
| sborovkov | did not try specifying specific revision | 15:29 |
| nessita | sborovkov, that sound correct, let me debug more | 15:29 |
| tyhicks | zyga: to get rid of that denial, you need to make this change: https://paste.ubuntu.com/23124379/ | 15:31 |
| tyhicks | zyga: if you want background reading: https://lists.ubuntu.com/archives/apparmor/2010-July/000110.html | 15:32 |
| zyga | tyhicks: ! :) | 15:33 |
| zyga | thanks! trying | 15:33 |
| nessita | sborovkov, is not showing up for me neither, searching more | 15:34 |
| zyga | tyhicks: cool, that changes the denial but I can work with the rest | 15:35 |
| tyhicks | ok | 15:35 |
| zyga | now I get: Sep 02 17:35:29 xenial-server kernel: audit: type=1400 audit(1472830529.357:78): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/hello-world.mnt" pid=43833 comm="ubuntu-core-lau" srcname="/" flags="rw, bind" | 15:36 |
| zyga | failed mntpnt (mount point?) match | 15:36 |
| tyhicks | yes | 15:37 |
| tyhicks | zyga: try dropping that trailing '/' on the following rule | 15:37 |
| tyhicks | mount options=(rw bind) -> /run/snapd/ns/*.mnt/, | 15:37 |
| tyhicks | zyga: I don't think that'll do it but lets just rule it out | 15:37 |
| zyga | ha, it did! | 15:38 |
| tyhicks | "yay" | 15:38 |
| tyhicks | that's a bug | 15:39 |
| tyhicks | minor but annoying | 15:39 |
| zyga | tyhicks: pushed the fix | 15:39 |
| zyga | tyhicks: is it? this is a bind mount for a file, it actually looks consistent | 15:39 |
| tyhicks | oh | 15:39 |
| tyhicks | right | 15:39 |
| tyhicks | I wasn't thinking that it was a file bind mount | 15:40 |
| tyhicks | so that makes sense | 15:40 |
| nessita | sborovkov, so the package is private, have you run snap login in that box? | 15:40 |
| zyga | tyhicks: ok, I need to make one simple change in main | 15:40 |
| zyga | tyhicks: but this might actually pass spread now | 15:40 |
| tyhicks | ok, I'll sit tight | 15:41 |
| sborovkov | nessita: yes, I did | 15:41 |
| sborovkov | nessita: rev 9 is also private, so I would not be able to install it without that | 15:42 |
| zyga | tyhicks: actually, to help me out, would you mind reviewing mountinfo.[ch] | 15:42 |
| zyga | tyhicks: I can propose that separately as it is isolated | 15:42 |
| nessita | sborovkov, what channel was 9 in? | 15:42 |
| sborovkov | nessita: beta, edge | 15:43 |
| nessita | sborovkov, I need some time to debug this by issuing the requests myself, could you file a bug please? https://bugs.launchpad.net/software-center-agent/+filebug | 15:43 |
| nessita | sborovkov, please make the bug private | 15:44 |
| sborovkov | nessita: sure | 15:44 |
| tyhicks | zyga: looking at it now | 15:44 |
| sborovkov | nessita: How do I make it private though? is this option going to appear after I click 'Submit bug report'? | 15:46 |
| abeato | ogra_, , can I create an arm image to run inside kvm with u-d-f? | 15:47 |
| ogra_ | nope | 15:47 |
| abeato | only rpi then, right? | 15:47 |
| ogra_ | cyphermox, can you set Bug #1619718 to critical | 15:51 |
| mup | Bug #1619718: ubuntu-image created vfat eats itself after a while <Ubuntu Image:New> <https://launchpad.net/bugs/1619718> | 15:51 |
| ogra_ | (i can not set bug status on u-image) | 15:51 |
| ogra_ | mvo, ^^^ | 15:51 |
| mvo | ogra_: I can't either | 15:52 |
| ogra_ | i added a snappy task now :) | 15:52 |
| mup | Bug #1619718 opened: ubuntu-image created vfat eats itself after a while <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1619718> | 15:53 |
| zyga | tyhicks: I'll open a pull request for mountinfo | 15:54 |
| sborovkov | nessita: https://bugs.launchpad.net/software-center-agent/+bug/1619719 | 15:54 |
| zyga | tyhicks: https://github.com/snapcore/snap-confine/pull/123 | 15:55 |
| tyhicks | zyga: it is looking good so far | 15:55 |
| mup | PR snap-confine#123: Add mountinfo module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/123> | 15:55 |
| zyga | tyhicks: I'll work on tests, I've updated ns-sharing branch to actually do what I intended in main | 15:55 |
| zyga | tyhicks: but let's take it slow and focus on mountinfo now | 15:55 |
| tyhicks | ok | 15:55 |
| zyga | I'll write a few unit tests for all the mountinfo functions | 15:55 |
| ogra_ | mvo, bug 1619721 for the randomly changing IP | 15:57 |
| mup | Bug #1619721: IP changes with every reboot <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619721> | 15:57 |
| mup | Bug #1619721 opened: IP changes with every reboot <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619721> | 15:59 |
| * zyga could use coverage reports here hmmm | 16:01 | |
| qengho | ogra_: what address? v6 link local? v4 DHCP-assigned? Something else? | 16:04 |
| ogra_ | qengho, ipv4 ... | 16:05 |
| ogra_ | but it desont make a difference, i did about 50-100 image installs today ... even with v6 it randomly changes | 16:05 |
| ogra_ | (well, even with v6 configured the v4 one randomly changes i should say) | 16:06 |
| ogra_ | mvo, do you need a bug for snap_kernel and snap_core not being set or do you already know wnat to do ? | 16:07 |
| ogra_ | *what | 16:07 |
| qengho | What is DHCP doing now? discover,offer,nak,offer? | 16:07 |
| pstolowski | jdstrand, hey! can you take a look at the apparmor policy of this new interface when you have a moment? https://github.com/snapcore/snapd/pull/1832 | 16:08 |
| mup | PR snapd#1832: Added time-date-control interface for org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832> | 16:08 |
| ogra_ | qengho, http://paste.ubuntu.com/23124588/ | 16:09 |
| ogra_ | thats the whole day for this MAC on my DHCP server | 16:09 |
| ogra_ | at least for the boots when it was connected :) | 16:10 |
| mvo | ogra_: I need to debug it | 16:10 |
| ogra_ | do you need a report ? | 16:11 |
| mup | PR snapd#1836 closed: overlord/state: fix for reloaded task/change crashing on Set if checkpointed w. no custom data yet <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1836> | 16:12 |
| qengho | ogra_: So, the DHCP client doesn't have a previous address to suggest to the DHCP server to assign, perhaps. Not retained across boots? | 16:15 |
| ogra_ | qengho, well, it worked before nplan ... this pi2 has 192.168.2.29 since 15.04 days ... it only doesnt work with the new images using nplan and console-conf only | 16:16 |
| ogra_ | (if i had not overwritten the SD i could actually show you :) that it gets the same IP again) | 16:17 |
| ogra_ | mvo, Bug #1619729 for you then | 16:22 |
| mup | Bug #1619729: ubuntu-image (or snapd) does not set snap_kernel and snap_core anymore in created images <Snappy:New for mvo> <Ubuntu Image:New> <https://launchpad.net/bugs/1619729> | 16:22 |
| * ogra_ feels exhausted and breaks | 16:23 | |
| mup | Bug #1619729 opened: ubuntu-image (or snapd) does not set snap_kernel and snap_core anymore in created images <Snappy:New for mvo> <Ubuntu Image:New> <https://launchpad.net/bugs/1619729> | 16:23 |
| zyga | tyhicks: I've added a few tests | 16:29 |
| zyga | tyhicks: any feedback so far? | 16:29 |
| tyhicks | zyga: I was just about to ask for a test that had two or more optional fields and see that you added one :) | 16:29 |
| zyga | tyhicks: yep, and fixed a missing space there | 16:29 |
| zyga | tyhicks: it's a shame the kernel doesn't produce json | 16:30 |
| zyga | tyhicks: one thing I'm not doing is un-escaping parsed strings | 16:30 |
| zyga | tyhicks: but for what we are doing this is *not* required as there are no spaces or special characters allowed | 16:30 |
| tyhicks | zyga: there are spaces and special characters allowed in the mount src and dst | 16:31 |
| tyhicks | you end up with something like this: | 16:31 |
| zyga | yes but those are escaped and just looke escaped in the strings we read | 16:31 |
| tyhicks | 46 26 0:20 /baz /dev/shm/foo\040bar rw,nosuid,nodev shared:4 - tmpfs tmpfs rw | 16:31 |
| zyga | but for those that we care about (actively look at) this is not the case | 16:31 |
| tyhicks | (that's for "/dev/shm/foo bar") | 16:31 |
| zyga | tyhicks: it will parse OK | 16:31 |
| tyhicks | ok | 16:31 |
| zyga | tyhicks: we only look for /run/snapd/ns which is a constant | 16:31 |
| tyhicks | I haven't got to how the mountinfo is used yet | 16:32 |
| tyhicks | it took me a while to get through the parsing function | 16:32 |
| mup | PR snapd#1838 opened: overlord: introduce AuthContext.DeviceSessionRequest with support in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/1838> | 16:32 |
| tyhicks | it is complicated but I don't have a better suggestion at this time | 16:32 |
| zyga | tyhicks: yes, the parsing is dense | 16:32 |
| sborovkov | nessita: ping | 16:40 |
| zyga | tyhicks: thank you! | 16:53 |
| zyga | tyhicks: I can make a small PR on top, for the ns-sharing APIs | 16:53 |
| zyga | tyhicks: if you are available for reviewing that | 16:53 |
| zyga | tyhicks: I'll take a break now | 17:02 |
| zyga | tyhicks: I'll send a chain of PRs | 17:02 |
| zyga | tyhicks: if you are available, I would really love to get this reviewed | 17:02 |
| * zyga -> off for some time | 17:02 | |
| sborovkov | nessita: so do you want me to leave everything as is so you could test, or can I upload new revisions? I am going offline soon, so in case you need me to leave everything as is for now pleas write there. I won't be doing anything till Sunday I think | 17:03 |
| tyhicks | zyga: thank you! | 17:13 |
| tyhicks | zyga: I need to focus on the udisks2 backend code this afternoon but I'll be up for a distraction | 17:14 |
| popey | using cmake in snapcraft when building foo which depends on libbar, is there some way I can tell foo to look for libbar in the stage dir? is there an env variable for $SNAPCRAFT_STAGE or something? | 17:40 |
| popey | for some reason foo isn't finding libbar... which I'm building from scratch because there's no package | 17:41 |
| sergiusens | popey hey, forgot about your problem, so where are you at, I can help onw | 17:47 |
| sergiusens | now | 17:47 |
| popey | which one? | 17:47 |
| popey | 😃 | 17:47 |
| popey | ^ this one is more fun :) | 17:47 |
| sergiusens | popey there is a var, called $SNAPCRAFT_STAGE actually (it's an envvar in master) in the current release it is a replacement in snapcraft.yaml | 17:48 |
| popey | so my foo which has a -DTELL_ME_WHERE_LIBBAR_IS= I could set it =$SNAPCRAFT_STAGE/usr/lib/blah ? | 17:48 |
| sergiusens | popey yes! | 17:49 |
| popey | excellent, will try that | 17:49 |
| popey | thanks | 17:50 |
| sergiusens | popey like this https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/stage_env/snapcraft.yaml | 17:51 |
| popey | perfect, will try that | 17:51 |
| popey | sometimes, lxd chooses perfect names | 17:53 |
| popey | $ snapcraft cleanbuild | 17:53 |
| popey | Creating snapcraft-loudly-major-grouse | 17:53 |
| sergiusens | popey it just knows what you are up to at times ;-) | 17:59 |
| popey | :) | 17:59 |
| popey | sergiusens: ok, got time for the other issue from earlier? | 17:59 |
| sergiusens | josepht about https://github.com/snapcore/snapcraft/pull/773, do you think that is a reasonable request | 17:59 |
| mup | PR snapcraft#773: parser - Handle project name and version variables <Created by josepht> <https://github.com/snapcore/snapcraft/pull/773> | 17:59 |
| mup | PR snapd#1839 opened: interface: network_manager: enable resolvconf <Created by tonyespy> <https://github.com/snapcore/snapd/pull/1839> | 17:59 |
| sergiusens | popey is the current cmake one solved? and sure, tell me more | 17:59 |
| popey | not yet, it takes an age to build :) | 17:59 |
| popey | it may be a known bug if so, which one.. lots of snappy-playpen examples broke in the copy->dump change | 18:00 |
| popey | sergiusens: http://paste.ubuntu.com/23125014/ | 18:01 |
| popey | results in:- [Errno 2] No such file or directory: '/home/alan/Development/Snappy/github_snappy_playpen/snappy-playpen/minetest/parts/minetestgame/install/*' | 18:01 |
| popey | used to work with copy plugin, all the examples which use copy, broke when we switched to dump | 18:01 |
| sergiusens | popey it is not a blind one off replacement though | 18:05 |
| sergiusens | popey line 26 certainly will not work and there is a bug for that :-) | 18:05 |
| popey | ah | 18:06 |
| sergiusens | popey inidividual file listing is required, this will get fixed in 2.17 (next week) | 18:06 |
| popey | suh-weet! | 18:07 |
| popey | got the bug number handy? | 18:07 |
| sergiusens | popey https://bugs.launchpad.net/snapcraft/+bug/1616459 | 18:07 |
| mup | Bug #1616459: dump plugin not a full super-set to the now deprecated copy plugin <Snapcraft:New> <https://launchpad.net/bugs/1616459> | 18:07 |
| popey | magic, ta | 18:07 |
| popey | btw, i love snapcraft cleanbuild | 18:08 |
| popey | its so handy | 18:08 |
| elopio | sergiusens: josepht: I think the MissingPackageError should come from the pull method of each source class. | 18:08 |
| sergiusens | popey wait til 2.16, with --debug you get a shell into the env on errors ;-) | 18:09 |
| popey | woot | 18:12 |
| popey | into the lxd container? | 18:12 |
| popey | double woot | 18:12 |
| mvo | ogra_: I did a new ubuntu-core build that should contian the new "ubuntu" user-less core | 18:12 |
| mvo | ogra_: just fyi | 18:12 |
| ogra_ | mvo, ok | 18:16 |
| ogra_ | i'll play around with ti tommorrow | 18:16 |
| ogra_ | *it | 18:16 |
| josepht | sergiusens: I think that's perfectly reasonable. I'll get it updated | 18:24 |
| josepht | elopio: I think that's a good idea. I'll update the PR. | 18:24 |
| sergiusens | elopio +1 | 18:26 |
| === sabdfl__ is now known as sabdfl | ||
| elopio | I'm full of good ideas this week! Sadly it's already friday, I can't make any promises for next week ^_^ | 18:27 |
| sabdfl | hi folks, how do we handle conditional-start situations with snaps | 18:27 |
| sabdfl | for example, i havev a VPN service, and i want to start and run if there are VPNs configured, but if not then its OK to quit | 18:28 |
| sabdfl | the init system isn't going to know if there are VPNs configured | 18:28 |
| sabdfl | i assume i have a wrapper script which decides if it should exec the daemon | 18:30 |
| sergiusens | sabdfl we have the same problem with "only start if networking is there"; in any case we do need more language to hook into init | 18:30 |
| sabdfl | but if it doesn't exec the daemon, and it exits, won't the init system restart it? | 18:30 |
| sergiusens | sabdfl wrappers are what people are using, but what if a VPN is configured on a running system after your snap decided not to start? | 18:30 |
| sabdfl | i guess one could watch config | 18:31 |
| sabdfl | in future well have config hooks | 18:31 |
| sabdfl | we'll, sorry | 18:31 |
| sergiusens | sabdfl in systemd RemainAfterExit= Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. | 18:32 |
| sergiusens | sabdfl and a Restart= condition of on-failure should be good | 18:33 |
| sergiusens | maybe the RemainAfterExit is not needed at all with Restart=on-failure | 18:34 |
| Hakase | hello there :) | 18:36 |
| Hakase | anyone here ? | 18:37 |
| elopio | Hakase: hello, welcome. | 18:38 |
| Tester2009 | hello | 18:44 |
| mup | PR snapd#1838 closed: overlord: introduce AuthContext.DeviceSessionRequest with support in devicestate <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1838> | 18:49 |
| mup | PR snapd#1840 opened: many: use symlinks instead of wrappers <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1840> | 19:12 |
| sabdfl | elopio, Hakase didn't have much to say :) | 19:22 |
| jonsnow | Hi. Is there a way to host a private snappy store ? | 19:22 |
| elopio | he seemed nice though, I hope he comes back... :'( | 19:23 |
| elopio | jonsnow: something like this? https://insights.ubuntu.com/2016/06/24/howto-host-your-own-snap-store/ | 19:27 |
| jonsnow | elopio: yes perfect, thanks :) | 19:31 |
| jonsnow | any plan to support OS X ? (snaps) | 19:32 |
| elopio | jonsnow: are you offering to make the port? :) | 19:32 |
| elopio | the first step is to support things without systemd. But from that to conquer the world there are still plenty of steps. | 19:33 |
| sergiusens | elopio what does Not this last one. mean? | 19:45 |
| elopio | sergiusens: it means that on the release notes for 2.16 you added the commit for the release notes for 2.16. | 19:46 |
| sergiusens | elopio I think I see what you are getting at | 19:47 |
| sergiusens | elopio and we've been doing that forever, and will keep doing it until we get the packaging split in place | 19:47 |
| sergiusens | elopio I pasted the link to the package builds | 19:48 |
| elopio | really? it's the first time I see it. Let me try to understand where is it coming form | 19:48 |
| elopio | from | 19:48 |
| elopio | sergiusens: I find disturbing the inconsistency in the use of the final period in sentences. Am I being too weird? | 19:49 |
| elopio | sergiusens: let me get lunch and a little rest first, and then I'll run and document the tests. +1 on your changelog pr. | 19:51 |
| mup | PR snapd#1791 closed: asserts: support checking account-key-request assertions <Created by cjwatson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1791> | 19:51 |
| === drizztbsd is now known as timothy | ||
| mup | PR snapd#1793 closed: asserts: initial support to generate/sign snap-build assertions <Created by caio1982> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1793> | 20:26 |
| mup | PR snapd#1841 opened: store: switch device session to use device-session-request assertion <Created by matiasb> <https://github.com/snapcore/snapd/pull/1841> | 20:33 |
| sergiusens | elopio any updates on QA? | 21:31 |
| * zyga returns to fix a few typos | 23:16 | |
| Son_Goku | ? | 23:17 |
| zyga | hey! | 23:17 |
| zyga | just a few typos, I read my pull requests and saw them | 23:17 |
| zyga | I had to get away from my compuer for a while to vent my mind and give my body some exercise | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!