[00:05] Bug #1617509 changed: Nothing happens when the connection goes down in the middle of an install === karlthane_ is now known as karlthane [01:34] ogra_: so do you have currently-working model assertions somewhere? The parser behavior changed in 2.14.2 and now required-snaps "must be a list of strings", which apparently precludes an empty list [01:40] pedronis: it seems this is your commit, 6717dd8, which breaks compatibility with what I understood to be the defined fields for the model assertion. This seems like a pretty major regression to me, if a well-defined model assertion is now being rejected because particular fields are not yet implemented in snapd? [02:35] Bug #1577520 changed: Support setpriority [02:39] PR snapcraft#783 opened: Add an integration test for autotools === chihchun_afk is now known as chihchun [04:12] Bug #1617231 changed: subiquity kills serial console after regular update [04:12] Bug #1617236 changed: console-conf falls over trying to create already existing logdir [04:15] PR snapcraft#784 opened: Support globbing for organize [04:18] PR snapcraft#783 closed: Add an integration test for autotools [04:18] Bug #1600166 changed: Snap rely on dns-masq running on 127.0.0.1 instead of /etc/resolv.conf [05:40] Bug #1621745 opened: snapd package is missing dependency on grub-common for grub-editenv [06:30] hey hey [06:36] PR snapd#1878 opened: snap: add `snap download --assertion model/16/canonical/pc-amd64` support [06:40] PR snapd#1868 closed: overlord/snapstate: support revert flags [06:42] pitti: good morning! is the autopkgtest environment configured differently when it comes to starting services? I am looking at the autopkgtest failure for snapd right now and it seems like the tests that start a systemd service are failing in strange ways. or is this just coincidence? is there a way to see how the test environment s confingured? so that I can try to replicate it ? [06:47] mvo_: it's a standard cloud image with lots of fat removed: https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed#n215 [06:47] mvo_: but that's exactly the same setup script that autopkgtest-buildvm-ubuntu-cloud uses (with the qemu runner) [06:48] [Kerror: cannot fetch assertion snap-revision [9gsl0jLoeOoWE-84XWtLy5Msk7w3hd-EXGsIvnGgDnH35YaSA5KIwUrvBXrEGHp_]: Get http://localhost:11028/assertions/snap-revision/9gsl0jLoeOoWE-84XWtLy5Msk7w3hd-EXGsIvnGgDnH35YaSA5KIwUrvBXrEGHp_: net/http: request canceled (Client.Timeout exceeded while awaiting headers) [06:48] mvo_: that sounds like a network/proxy error? [06:49] mvo_: I can start a test manually and then give you ssh to that instance if you want [06:50] pitti: hm, hm, if its the same as the qemu, let me try this once more, I had successful runs in that environment, let me try it once more === shuduo-afk is now known as shuduo [07:15] mvo_: so that "cannot fetch assertion" is unrelated/ [07:15] ? [07:17] ogra_: hi, i'm booting a latest image i generated by u-d-f with edge channel on dragonboard. i see console-conf is working and registered with my launchpad account as username.it's wonderful. but i can't login with my password. may i know it's expected and how i can login? [07:29] pitti: no, its a real error but three are a total of 4 failures so instead of waiting for adt on the servers (which may take a long time before it gets a chance to run) I will ensure its all passing locally and add some debug output too === seb128_ is now known as seb128 [07:39] PR snapd#1879 opened: Systemd on trusty is different [07:40] Bug #1621769 opened: impossible to create a model assertion compatible with both snapd 2.13 and 2.14 [08:47] Bug #1575914 changed: snaps using home interface have full access to SNAP_USER_DATA of other snaps [08:59] ogra_, how can I modify rpi3 image so tmp is storage instead of tmpfs? I run out of free space when isntalling a big snap [09:02] shuduo, there is no local setup, you can only log in via ssh [09:02] abeato, i dont think thats easy beyond manually remounting before installing the snap ... file a bug please [09:04] ogra_, will do, to which project? [09:04] see topic :) [09:04] ack [09:07] ogra_: great. i can ssh login w/o password now. :) BTW, I see a bug is tracking console-conf do not support SSID input. then mah i know how to config WiFi? === bull_ is now known as bulldog [09:08] shuduo, for the moment, ssh in through a USB NIC ... then set up a config in /etc7network/interfaces.d/$devicename for the wifi [09:08] ugh [09:08] guys i gave sudo snap install game-2048 , then i aborted it with sudo snap abort 179 , [09:08] I hate the world right now [09:08] but it downloaded whole package [09:08] I should *not* be awake this early [09:08] Son_Goku, coffee++ [09:09] is it normal ?? i think it should be aborting process right when user req [09:09] ogra_, [09:09] hi [09:10] why abort process won't stop process , i was aborting a install process and it didnt did anything before the full package download [09:10] are things out of control ??? [09:11] ogra_: but /etc/network/interfaces.d/ is empty [09:11] shuduo, right, you need to create a config file for the device [09:12] ogra_, you ignoring me :D ?? [09:12] ogra_: one more thing, my system seems got an OS update. then afer i reboot it, snap list got error: error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused [09:12] bulldog, i have no answer for you ... better ask the channel, thats a question for the core team [09:12] ok bro , [09:13] shuduo, that sounds like snapd did not start ... [09:16] ogra_: syslog is: ...Sep 9 09:13:52 localhost systemd[1]: snapd.service: Unit entered failed state. [09:17] Sep 9 09:13:52 localhost systemd[1]: snapd.service: Failed with result 'exit-code'. [09:17] Sep 9 09:13:53 localhost systemd[1]: snapd.service: Service hold-off time over, scheduling restart. [09:17] Sep 9 09:13:53 localhost systemd[1]: Stopped Snappy daemon. [09:17] Sep 9 09:13:53 localhost systemd[1]: snapd.service: Start request repeated too quickly. [09:17] Sep 9 09:13:53 localhost systemd[1]: Failed to start Snappy daemon. [09:17] Sep 9 09:13:53 localhost systemd[1]: snapd.socket: Unit entered failed state. [09:17] ogra_: so i can't rollback if snapd can't start, right? [09:17] right [09:17] but you said you rolled your own image ? [09:17] did ouy use ubuntu-image and wheer did you get the model assertion for it ? [09:17] ogra_: yes, just this afternoon [09:18] without signed model assertion it cant work (and afaik we dont have them for normal users yet) [09:18] ogra_: no, i don't know ubuntu-image already ready to be used. is it ready? i still use u-d-f [09:19] sudo snap install ubuntu-image --devmode --edge [09:19] ;) [09:19] but you will need a model assertion, else snapd will refuse to work ,,, and we dont really have a way for users to sign their own afaik [09:21] where snaps are temporarily stored while they are being downloaded by snap install command ?? [09:22] anyone ?? [09:23] ogra_: i install ubuntu-image, but i can't find how to generate a ubuntu core image for dragonboard with its help output [09:25] yes i was right , packages are fully downloaded before the abort , what a serious kind of bug lol [09:25] sudo ubuntu-image -c $channel $model-assertion -o $image-name [09:26] you can build with unsigned model assertion, but then the system wont know about the basic snaps (gadget, kernel, os) [09:26] snap which are being downloaded by snap install command are stored in /tmp and i can see 3 63mb game-2048 packaged which snap downloaded even i passed the abort command [09:26] exporting UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 adds the override [09:26] ogra_: but i am not able to generate image as no way to get model-assertion right now, right? [09:26] Bug #1621800 opened: Cannot install snap on RPi due to small tmpfs in /tmp [09:27] shuduo, slangasek posted two to the device mailing list yesterday [09:27] shuduo, http://people.canonical.com/~vorlon/amd64-generic-model.assertion [09:27] adjust the package names ... [09:30] ogra_: okay. but only amd64 and pi2. customer want it for dragonboard... [09:30] thats why i said you need to adjust it :) [09:31] the image wont be much usable though ... sice snapd wont have a basic setup [09:32] shuduo, why do you actually need to roll your own, are the officially released images from wednesday not enough ? [09:33] ogra_: got it. seems i have to give an very old image to customer [09:33] ogra_: do you mean the image hosted on people.c.c/~mvo/all-snaps/16? [09:34] no, i mean the ones that were officially announced on the mailing list on wed. [09:34] ogra_: let me check.. which mailing list? [09:35] https://lists.ubuntu.com/archives/snapcraft/2016-September/001036.html [09:35] you really should be sunbscibed to it ... [09:36] and since yesterday it seems we are singeling out device stuff into https://lists.snapcraft.io/mailman/listinfo/devices [09:39] ogra_: thanks a lot. i did subscribe snapcraft mailing list, but be filtered automatically so no show in inbox... [09:41] ogra_, I do not find an easy way to remount /tmp, any suggestions? [09:42] bug https://bugs.launchpad.net/snappy/+bug/1621805 sudo snap abort change id wont abort snap install process before downloading full package [09:42] Bug #1621805: sudo snap abort change id wont abort snap install process before downloading full package [09:46] abeato, "sudo umount /tmp" ? [09:47] (reboot after you installed the snap since everything that was in tmp will be gone after the umount, you dont want to keep running like that) [09:47] why do I get the error "error: cannot find signatures with metadata for snap "hello_1.0_amd64.snap" when installing my snap on Ubuntu desktop 16.04? [09:47] Bug #1621805 opened: sudo snap abort change id wont abort snap install process before downloading full package [09:47] liuxg, because your snap was not signed by the store ... [09:48] youi need to use the new --dangerous option [09:48] ogra_, not enough, I cannot remove /tmp after that to link it to another place. Anyway, mounting it as a bigger tmpfs now [09:48] ogra_, I am installing it by sideload. [09:48] (or --force-dangerous, not sure which one is currently the default) [09:48] abeato, if you umount it will use the SD [09:48] ogra_, so this was changed again :( [09:49] abeato, no need to mvoe it anywhere [09:49] *move [09:49] ogra_, maybe, but it complains it is read only :/ [09:49] oh crap [09:49] ogra_, thanks for your tip. --force-dangerous is the right option for it. [09:50] liuxg, only for a few days ... it will become --dangerous [09:51] ogra_, it is too bad that we change the format frequently. developers need to follow very closely. I think it is good for the command to give us the correct tips for use. [09:51] ogra_, 'sudo mount -t tmpfs -o size=600M /tmp' will help for the moment [09:51] can you note that in the bug ? [09:54] ogra_, sure [09:54] thx [09:54] not sure hwo we can solve that ... [09:54] PR snapd#1870 closed: store: ensure the payment methods method handles auth failure [09:54] *how [09:55] we dont want to wear out the SD and we dont want all your RAM being eaten by a /tmp mount either [09:55] snapd probably needs to learn to not use /tmp [09:55] and have its own tmpdir for downloading/installing [09:56] ogra_: i notice the beta image is hosted in ubuntu-snappy. i thought we already abandoned snappy ... :) [09:56] ogra_: ping [09:56] well, ask mvo_ why he put it there :) [09:57] i would have put it under ubuntu-core :) [09:57] morphis, i'm actively talking here... no need to ping me, just ask ;) [09:58] ogra_: but that gives you the freedom to respond when you have time :-) [09:58] haha [09:58] ogra_, shuduo: mostly because of the symetry with 15.04 but I'm fine if we decide to put it somewhere else [09:58] ogra_: so quick thing, which initramfs are you using for Ubuntu Core? [10:01] morphis, whatever update-initramfs generates when the initramfs-tools-ubuntu-core from the PPA is in place [10:01] I see [10:02] ogra_: you use that one in dragonboard too? [10:02] (we generate two ... one without any modules when ubuntu-core is built ... the other in exactly the same way during the kernel snap build (which then potentially includes some selected modules) [10:03] on the official images we use the initrd created by the kernel snap builds [10:03] (this will eventually change and we'll split the two ... modules will go into their own, shipped by the kernel, all scripts will come from the generic one) [10:04] Hi I am just struggling to make my first snap using a program I wrote in Java can anybody help me [10:11] $ sudo snap install --force-dangerous blabla.snap [10:11] error: unknown flag `force-dangerous' [10:11] are you on snapd from proposed already ? [10:11] what am i missing? [10:12] then you just want --dangerous [10:12] $ snap list [10:12] Name Version Rev Developer Notes [10:12] hello-world 6.3 27 canonical - [10:12] pc 16.04-0.8 9 canonical - [10:12] pc-kernel 4.4.0-36-2 19 canonical - [10:12] snapweb 0.20 11 canonical - [10:12] ubuntu-core 16.04.1 524 canonical - [10:12] PR snapcraft#785 opened: Check if option is url for pip [10:12] right, try --dangerous [10:12] it worked [10:13] indeed :) === chihchun is now known as chihchun_afk [10:13] but now is treating me for a forced reboot [10:14] because you also gotr a new ubuntu-core i bet [10:14] or did you install a kernel snap ? [10:14] uhm nope [10:14] yep [10:14] i guess that was it [10:14] yeah [10:14] anyhow, everything works [10:14] yay [10:14] actually this morning i tried building an image following slangsek instruction on the ml [10:15] using ubuntu-image [10:15] ogra_, when you go for sleep man ??? [10:15] and after the reboot (without being able to install mu kernel snap) [10:15] bulldog, not at noon :P [10:15] snapd didn't start anymore [10:15] i see you everytime here [10:15] i guess i'll have to try again [10:15] ppisati, i guess you would need an official assertion [10:16] apps: pdfHighlighter: command: pdfHighlighter parts: pdfHighlighter0.0.7 plugin: jdk source: pdfHighlighter0.0.7.jar [10:16] Gerry_, use pastebin [10:16] Gerry_, here is a snap that uses a jar https://github.com/ogra1/jtiledownloader [10:17] ok sorry thank you [10:17] Gerry_, https://github.com/keshavbhatt/snapcraft-gui/ [10:18] built-in pastebin to paste your current opened snapcraft.yaml [10:21] Bug #1619721 changed: /etc/machine-id changes with every reboot [10:21] ogra@pi3:~$ snap list ubuntu-core [10:21] Name Version Rev Developer Notes [10:21] ubuntu-core 16.04.1 526 canonical - [10:21] ogra@pi3:~$ sudo snap refresh ubuntu-core --edge [10:21] error: cannot refresh "ubuntu-core": snap "ubuntu-core" has no updates available [10:21] ogra@pi3:~$ [10:21] mvo_, ^^^ shouldnt that work ? [10:21] (edge has 549 for armhf) [10:21] mvo_: i don't mind where they are :) just curious that since marketing team asked me "don't mention snappy any more. official name is ubuntu core." [10:23] * ogra_ doesnt mind either as long as people can download them somewhere :) [10:25] sergiusens, https://bugs.launchpad.net/snappy/+bug/1621805 [10:25] Bug #1621805: sudo snap abort change id wont abort snap install process before downloading full package [10:25] ogra_: should work, maybe there really are no upgrades? [10:26] mvo_, there is 549 in front of me :) [10:26] shuduo: thanks, I guess people will weight in then at some point :) [10:26] ogra_: when did you hit "publish"? [10:26] ogra_: like - how many minutes ago? [10:26] it was auto-published around 6am european time (daily build) [10:27] ogra_: oh [10:28] hmm, though i had to add that silly "grade: stable" stuff ... even for edge builds ... i wonder if snapd chokes on that now [10:28] (but that would mean we cant do updates at all for these images, since beta != stable) [10:29] do you know if snapd checks fior that field somehow ? [10:47] Sorry for my mistakes in advance I am a beginner http://pastebin.com/FBny8NPq [10:47] PR snapd#1880 opened: asserts: use gpg --fixed-list-mode to be compatible with both gpg1 and gpg2 === hikiko is now known as hikiko|ln [10:49] Gerry_, check the indendation in my snapcraft.yaml, make yours look the same ... yaml is very picky about that [10:50] ok thank you [10:57] Bug #1621800 changed: Cannot install snap on RPi due to small tmpfs in /tmp [11:11] ogra_ mvo_ does snapweb work well as webdm did before? i flashed a snapdragon beta image and connect to network via usb-ethernet adapter. but i can't see IP:4200 show store from other computer's browser. [11:14] shuduo, nope, it has bugs and currently doesnt start properly [11:14] (but since the snap is pre-installed some auto-update will auto-fix it ;) ) [11:15] ogra_: got it. so "snap find *" is only way to list all available snaps, right? [11:15] no, there is no way to list all snaps anymore [11:15] ogra_: even later snapweb? [11:16] oh, no idea how snapweb will present them [11:16] but snap find wont [11:18] ogra_: i heard of that be designed when i was heidelberg, but wonder why it be designed so. i wonder output a full list then grepping is much helpful for mass devices management [11:18] there is no way :D [11:18] i was looking for it too [11:19] shuduo, afaik there will be pagination or some such in the future ... but currently there is no way and i'm not sure its a GA target [11:34] vila, https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz [11:34] there you go :) [11:35] from https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz [11:35] err [11:35] https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel [11:35] ogra_: Thanks ! Looking [11:36] added the link to the bug as well [11:41] mvo_, i filed bug 1621843 for the above [11:41] Bug #1621843: no way to switch ubuntu-core to --edge on images [11:42] Bug #1621843 opened: no way to switch ubuntu-core to --edge on images [11:47] ogra_: ok, it's in the code I suspected by via a different path [11:47] ogra_: do you control the branch url used ? [11:50] ogra_: as in, can you try replacing 'lp:~snappy-dev/kernel-snap-makefile/trunk' with 'https://code.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk bee' ? [11:50] vila, i do control the branch, but snapcraft does the pull ... i dont control anthing around this bit [11:51] ogra_: how to you specify the branch to snapcraft is what I meant [11:51] i'm not sure snapcraft will recognize this as bzr branch [11:52] vila, http://bazaar.launchpad.net/~snappy-dev/pi2-kernel-snap/trunk/view/head:/snapcraft.yaml [11:52] everything else is snapcraft magic [11:52] if i just add a https:// to the source: option i doubt snapcraft will get along [11:53] ogra_: why wouldn't it ? [11:53] how would it know this is a bzr tree ? [11:53] ogra_: lp hosts bzr and git branches [11:53] yes, i think git on lp uses a special nomenclature to tell them apart [11:54] in snapcraft [11:54] like git+ssh:// or so [11:54] (i never used lp git from snapcraft yet) [11:54] ogra_: can you just try while I look at snapcraft ? ;) [11:55] source-type: bzr ? [11:55] hmmm ... these aare the official kernels i wouldnt like them to explode ... [11:55] but i can perhaps set a test branch up [11:55] ogra_: you lost me, they do explode right now no ? [11:55] qengho, is that plugin independent ? [11:55] right, just use source-type: git and source: https://, if it's a public branch [11:55] vila, no, they dont becaause we apply the patch to snapcraft [11:56] ok, let me try source-type and https then [11:56] ogra_: yes, modulo plugin overrides. [11:57] cjwatson: ha, you're there great. Is using no_proxy an option in this context ? [11:58] vila: it might work in this specific case but it would break attempts to fetch from a bzr branch not hosted on LP; I initially thought that was unlikely but then somebody turned up with a real-world example ... [11:58] hmm, how do i make it not use the PPA snapcraft without removing the package now ... [11:58] i guess i have to :/ [11:59] * ogra_ feels a bit uneasy ripping apart the workign build system on a friday afternoon ... [12:00] cjwatson: no_proxy=launchpad.net will affect only launchpad branches right ? [12:01] ok, patched snapcraft removed, kernel snap changed [12:01] * ogra_ waits for the auto-build to start now [12:01] cjwatson: can you give me some hints about the setup used here ? I see 'https_proxy=https://snap-proxy.launchpad.net:3128 http_proxy=http://snap-proxy.launchpad.net:3128' and 'Revoking proxy token' but I don't get what bzr is seeing exactly [12:02] rather no_proxy=bazaar.launchpad.net I guess [12:02] cjwatson: yes, sorry ;-) [12:02] but might be worth a try, in the snapcraft Bazaar class or so [12:03] cjwatson: but this is specific to running on the launchpad builders no ? Or do you mean you use a special version there ? [12:03] vila: the environment variables are filtered in the log to avoid leaking secrets, so it's actually going to be http_proxy=http://user:password@snap-proxy.launchpad.net:3128 [12:03] haaaaaa [12:03] the root cause seems to the '\n' in the Basic header... [12:04] vila: we don't use a special version; I guess we could set this in launchpad-buildd, I'm not sure which is more/less evil as a workaround [12:04] in httplib.py : _is_illegal_header_value = re.compile(r'\n(?![ \t])|\r(?![ \t\n])').search === hikiko|ln is now known as hikiko [12:11] vila: ah, so maybe just that the user/password combination is too long? [12:11] cjwatson, beat me to it ;-) [12:12] max supported length is 57 [12:12] cjwatson: Including 'Basic :' [12:13] vila: so just raw.encode('base64').strip() -> base64.b64encode(raw) would fix it then [12:14] cjwatson: yes, in the mean time, can you use shorter user/pass ? :) [12:14] not easily [12:14] I mean, I don't think that would be any quicker a fix :) [12:14] oh fixing is easy, getting bzr delivered and used there.... may be longer than using short user/pass is what I meant ;) [12:15] they're not that huge anyway [12:15] sure, just big enough that nobody ever reported the issue ;) [12:15] username is the build cookie, password is a uuid [12:16] well, build cookie plus a timestamp [12:16] do you have an example ? [12:16] getting bzr delivered and used there is trivial actually - ogra_ is using a patched snapcraft at the moment, would be very easy to use a patched bzr instead [12:16] just drop it into the same PPA [12:16] haaaa, here we go :) [12:17] err, but that would fix only ogra's use case right ? [12:17] cjwatson, well, i just removed the patched snapcraft on vila's request :P ... so yeah, if i need anything patched it would be good to land it there [12:17] yeah, but there are only a handful of people affected by this [12:17] (preferablly before EDO :) ) [12:17] so we can test it in ogra_'s PPA, then SRU [12:17] that would be good enough [12:18] ogra_: yeah, no pressure ;-) [12:18] heh [12:18] ok, let me prepare something then [12:18] vila: example username is SNAPBUILD-4665-1473322419 [12:19] vila: example password is output of uuid.uuid4().hex [12:20] cjwatson: ack, that's 6 too much (from some manual try ;) [12:20] cjwatson: uuid.uuid4().hex[:-10] ? ;-) [12:21] ok, ok, kidding, back to preparing a patch ;) [12:21] changing the proxy requires a production deployment via IS, changing what bzr does can be done without IS involvement using a PPA ;-) [12:22] (actually it could be changed for everyone via the snappy-dev/tools PPA) [12:22] we dont really use that PPA for anything... ITYM snappy-dev/image [12:23] no, I meant what I said [12:23] lpnet-lazr.conf:tools_source: deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu %(series)s main [12:23] I told the snappy-dev team that we were doing this, ages ago :) [12:23] hmm, nobody told me then ... [12:23] I'm pretty sure I did! [12:23] Let me check logs [12:24] ah, no, I talked about it with sergiusens [12:24] we actually need to get rid of all PPAs for the sable builds within the next weeks [12:24] and sergiusens was the one who asked us to use that PPA [12:24] *stable [12:24] this has nothing to do with image builds, it's the PPA we use for all snap builds on Launchpad [12:25] 2015-09-22.log:17:53 sergiusens: are you saying that Launchpad should switch to using ppa:snappy-dev/tools rather than ppa:snappy-dev/snapcraft-daily? [12:25] 2015-09-22.log:18:00 cjwatson, eventually yes; but all new development (daily builds even) are in ppa:snappy-dev/tools-proposed ; we are stable enough again to start using that instead if you want [12:25] well, then it has to do with the image builds too :) [12:25] 2015-09-22.log:18:03 cjwatson, don't switch then, I'll copy to daily, the final location will be ppa:snappy-dev/tools which is the same ppa we have for everything else [12:25] since kernel and rootfs are both snaps built on lp nowadays [12:25] I'd regard ppa:snappy-dev/tools as a bit of infrastructure [12:25] just like the PPA that launchpad-buildd comes from [12:26]