[00:05] <mup> Bug #1617509 changed: Nothing happens when the connection goes down in the middle of an install <Snappy:Invalid> <https://launchpad.net/bugs/1617509>
[01:34] <slangasek> 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] <slangasek> 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] <mup> Bug #1577520 changed: Support setpriority <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1577520>
[02:39] <mup> PR snapcraft#783 opened: Add an integration test for autotools <Created by elopio> <https://github.com/snapcore/snapcraft/pull/783>
[04:12] <mup> Bug #1617231 changed: subiquity kills serial console after regular update <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1617231>
[04:12] <mup> Bug #1617236 changed: console-conf falls over trying to create already existing logdir <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1617236>
[04:15] <mup> PR snapcraft#784 opened: Support globbing for organize <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/784>
[04:18] <mup> PR snapcraft#783 closed: Add an integration test for autotools <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/783>
[04:18] <mup> Bug #1600166 changed: Snap rely on dns-masq running on 127.0.0.1 instead of /etc/resolv.conf <Snappy:Expired> <https://launchpad.net/bugs/1600166>
[05:40] <mup> Bug #1621745 opened: snapd package is missing dependency on grub-common for grub-editenv <Snappy:New> <https://launchpad.net/bugs/1621745>
[06:30] <dholbach> hey hey
[06:36] <mup> PR snapd#1878 opened: snap: add `snap download --assertion model/16/canonical/pc-amd64` support <Created by mvo5> <https://github.com/snapcore/snapd/pull/1878>
[06:40] <mup> PR snapd#1868 closed: overlord/snapstate: support revert flags <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1868>
[06:42] <mvo_> 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] <pitti> 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] <pitti> mvo_: but that's exactly the same setup script that autopkgtest-buildvm-ubuntu-cloud uses (with the qemu runner)
[06:48] <pitti> [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] <pitti> mvo_: that sounds like a network/proxy error?
[06:49] <pitti> mvo_: I can start a test manually and then give you ssh to that instance if you want
[06:50] <mvo_> 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
[07:15] <pitti> mvo_: so that "cannot fetch assertion" is unrelated/
[07:15] <pitti> ?
[07:17] <shuduo> 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] <mvo_> 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
[07:39] <mup> PR snapd#1879 opened: Systemd on trusty is different <Created by vosst> <Conflict> <https://github.com/snapcore/snapd/pull/1879>
[07:40] <mup> Bug #1621769 opened: impossible to create a model assertion compatible with both snapd 2.13 and 2.14 <Snappy:New for mvo> <https://launchpad.net/bugs/1621769>
[08:47] <mup> Bug #1575914 changed: snaps using home interface have full access to SNAP_USER_DATA of other snaps <apparmor> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <snapd (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1575914>
[08:59] <abeato> 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] <ogra_> shuduo, there is no local setup, you can only log in via ssh
[09:02] <ogra_> abeato, i dont think thats easy beyond manually remounting before installing the snap ... file a bug please
[09:04] <abeato> ogra_, will do, to which project?
[09:04] <ogra_> see topic :)
[09:04] <abeato> ack
[09:07] <shuduo> 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?
[09:08] <ogra_> 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] <Son_Goku> ugh
[09:08] <bulldog> guys i gave sudo snap install game-2048 , then i aborted it with sudo snap abort 179 ,
[09:08] <Son_Goku> I hate the world right now
[09:08] <bulldog> but it downloaded whole package
[09:08] <Son_Goku> I should *not* be awake this early
[09:08] <ogra_> Son_Goku, coffee++
[09:09] <bulldog> is it normal ?? i think it should be aborting process right when user req
[09:09] <bulldog> ogra_,
[09:09] <bulldog> hi
[09:10] <bulldog> 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] <bulldog> are things out of control ???
[09:11] <shuduo> ogra_: but /etc/network/interfaces.d/ is empty
[09:11] <ogra_> shuduo, right, you need to create a config file for the device
[09:12] <bulldog> ogra_, you ignoring me  :D ??
[09:12] <shuduo> 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] <ogra_> bulldog, i have no answer for you ... better ask the channel, thats a question for the core team
[09:12] <bulldog> ok bro ,
[09:13] <ogra_> shuduo, that sounds like snapd did not start ...
[09:16] <shuduo> ogra_: syslog is: ...Sep  9 09:13:52 localhost systemd[1]: snapd.service: Unit entered failed state.
[09:17] <shuduo> Sep  9 09:13:52 localhost systemd[1]: snapd.service: Failed with result 'exit-code'.
[09:17] <shuduo> Sep  9 09:13:53 localhost systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
[09:17] <shuduo> Sep  9 09:13:53 localhost systemd[1]: Stopped Snappy daemon.
[09:17] <shuduo> Sep  9 09:13:53 localhost systemd[1]: snapd.service: Start request repeated too quickly.
[09:17] <shuduo> Sep  9 09:13:53 localhost systemd[1]: Failed to start Snappy daemon.
[09:17] <shuduo> Sep  9 09:13:53 localhost systemd[1]: snapd.socket: Unit entered failed state.
[09:17] <shuduo> ogra_: so i can't rollback if snapd can't start, right?
[09:17] <ogra_> right
[09:17] <ogra_> but you said you rolled your own image ?
[09:17] <ogra_> did ouy use ubuntu-image and wheer did you get the model assertion for it ?
[09:17] <shuduo> ogra_: yes, just this afternoon
[09:18] <ogra_> without signed model assertion it cant work (and afaik we dont have them for normal users yet)
[09:18] <shuduo> ogra_: no, i don't know ubuntu-image already ready to be used. is it ready? i still use u-d-f
[09:19] <ogra_> sudo snap install ubuntu-image --devmode --edge
[09:19] <ogra_> ;)
[09:19] <ogra_> 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] <bulldog> where snaps are temporarily stored while they are being downloaded by snap install command ??
[09:22] <bulldog> anyone ??
[09:23] <shuduo> 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] <bulldog> yes i was right , packages are fully downloaded before the abort , what a serious kind of bug lol
[09:25] <ogra_> sudo ubuntu-image -c $channel $model-assertion -o $image-name
[09:26] <ogra_> you can build with unsigned model assertion, but then the system wont know about the basic snaps (gadget, kernel, os)
[09:26] <bulldog> 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] <ogra_> exporting UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 adds the override
[09:26] <shuduo> ogra_: but i am not able to generate image as no way to get model-assertion right now, right?
[09:26] <mup> Bug #1621800 opened: Cannot install snap on RPi due to small tmpfs in /tmp <Snappy:New> <https://launchpad.net/bugs/1621800>
[09:27] <ogra_> shuduo, slangasek posted two to the device mailing list yesterday
[09:27] <ogra_> shuduo, http://people.canonical.com/~vorlon/amd64-generic-model.assertion
[09:27] <ogra_> adjust the package names ...
[09:30] <shuduo> ogra_: okay. but only amd64 and pi2. customer want it for dragonboard...
[09:30] <ogra_> thats why i said you need to adjust it :)
[09:31] <ogra_> the image wont be much usable though ... sice snapd wont have a basic setup
[09:32] <ogra_> shuduo, why do you actually need to roll your own, are the officially released images from wednesday not enough ?
[09:33] <shuduo> ogra_: got it. seems i have to give an very old image to customer
[09:33] <shuduo> ogra_: do you mean the image hosted on people.c.c/~mvo/all-snaps/16?
[09:34] <ogra_> no, i mean the ones that were officially announced on the mailing list on wed.
[09:34] <shuduo> ogra_: let me check.. which mailing list?
[09:35] <ogra_> https://lists.ubuntu.com/archives/snapcraft/2016-September/001036.html
[09:35] <ogra_> you really should be sunbscibed to it ...
[09:36] <ogra_> and since yesterday it seems we are singeling out device stuff into https://lists.snapcraft.io/mailman/listinfo/devices
[09:39] <shuduo> ogra_: thanks a lot. i did subscribe snapcraft mailing list, but be filtered automatically so no show in inbox...
[09:41] <abeato> ogra_, I do not find an easy way to remount /tmp, any suggestions?
[09:42] <bulldog> bug https://bugs.launchpad.net/snappy/+bug/1621805  sudo snap abort change id wont abort snap install process before downloading full package
[09:42] <mup> Bug #1621805:  sudo snap abort change id wont abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
[09:46] <ogra_> abeato, "sudo umount /tmp" ?
[09:47] <ogra_> (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] <liuxg> 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] <mup> Bug #1621805 opened:  sudo snap abort change id wont abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
[09:47] <ogra_> liuxg, because your snap was not signed by the store ...
[09:48] <ogra_> youi need to use the new --dangerous option
[09:48] <abeato> 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] <liuxg> ogra_, I am installing it by sideload.
[09:48] <ogra_> (or --force-dangerous, not sure which one is currently the default)
[09:48] <ogra_> abeato, if you umount it will use the SD
[09:48] <liuxg> ogra_, so this was changed again :(
[09:49] <ogra_> abeato, no need to mvoe it anywhere
[09:49] <ogra_> *move
[09:49] <abeato> ogra_, maybe, but it complains it is read only :/
[09:49] <ogra_> oh crap
[09:49] <liuxg> ogra_,  thanks for your tip. --force-dangerous is the right option for it.
[09:50] <ogra_> liuxg, only for a few days ... it will become --dangerous
[09:51] <liuxg> 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] <abeato> ogra_, 'sudo mount -t tmpfs -o size=600M /tmp' will help for the moment
[09:51] <ogra_> can you note that in the bug ?
[09:54] <abeato> ogra_, sure
[09:54] <ogra_> thx
[09:54] <ogra_> not sure hwo we can solve that ...
[09:54] <mup> PR snapd#1870 closed: store: ensure the payment methods method handles auth failure <Created by pete-woods> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1870>
[09:54] <ogra_> *how
[09:55] <ogra_> we dont want to wear out the SD and we dont want all your RAM being eaten by a /tmp mount either
[09:55] <ogra_> snapd probably needs to learn to not use /tmp
[09:55] <ogra_> and have its own tmpdir for downloading/installing
[09:56] <shuduo> ogra_: i notice the beta image is hosted in ubuntu-snappy. i thought we already abandoned snappy ... :)
[09:56] <morphis> ogra_: ping
[09:56] <ogra_> well, ask mvo_ why he put it there :)
[09:57] <ogra_> i would have put it under ubuntu-core :)
[09:57] <ogra_> morphis, i'm actively talking here... no need to ping me, just ask ;)
[09:58] <morphis> ogra_: but that gives you the freedom to respond when you have time :-)
[09:58] <ogra_> haha
[09:58] <mvo_> ogra_, shuduo: mostly because of the symetry with 15.04 but I'm fine if we decide to put it somewhere else
[09:58] <morphis> ogra_: so quick thing, which initramfs are you using for Ubuntu Core?
[10:01] <ogra_> morphis, whatever update-initramfs generates when the initramfs-tools-ubuntu-core from the PPA is in place
[10:01] <morphis> I see
[10:02] <morphis> ogra_: you use that one in dragonboard too?
[10:02] <ogra_> (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] <ogra_> on the official images we use the initrd created by the kernel snap builds
[10:03] <ogra_> (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] <Gerry_> Hi I am just struggling to make my first snap using a program I wrote in Java can anybody help me
[10:11] <ppisati> $ sudo snap install --force-dangerous blabla.snap
[10:11] <ppisati> error: unknown flag `force-dangerous'
[10:11] <ogra_> are you on snapd from proposed already ?
[10:11] <ppisati> what am i missing?
[10:12] <ogra_> then you just want --dangerous
[10:12] <ppisati> $ snap list
[10:12] <ppisati> Name         Version     Rev  Developer  Notes
[10:12] <ppisati> hello-world  6.3         27   canonical  -
[10:12] <ppisati> pc           16.04-0.8   9    canonical  -
[10:12] <ppisati> pc-kernel    4.4.0-36-2  19   canonical  -
[10:12] <ppisati> snapweb      0.20        11   canonical  -
[10:12] <ppisati> ubuntu-core  16.04.1     524  canonical  -
[10:12] <mup> PR snapcraft#785 opened: Check if option is url for pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/785>
[10:12] <ogra_> right, try --dangerous
[10:12] <ppisati> it worked
[10:13] <ogra_> indeed :)
[10:13] <ppisati> but now is treating me for a forced reboot
[10:14] <ogra_> because you also gotr a new ubuntu-core i bet
[10:14] <ogra_> or did you install a kernel snap ?
[10:14] <ppisati> uhm nope
[10:14] <ppisati> yep
[10:14] <ppisati> i guess that was it
[10:14] <ogra_> yeah
[10:14] <ppisati> anyhow, everything works
[10:14] <ogra_> yay
[10:14] <ppisati> actually this morning i tried building an image following slangsek instruction on the ml
[10:15] <ppisati> using ubuntu-image
[10:15] <bulldog> ogra_, when you go for sleep man ???
[10:15] <ppisati> and after the reboot (without being able to install mu kernel snap)
[10:15] <ogra_> bulldog, not at noon :P
[10:15] <ppisati> snapd didn't start anymore
[10:15] <bulldog> i see you everytime here
[10:15] <ppisati> i guess i'll have to try again
[10:15] <ogra_> ppisati, i guess you would need an official assertion
[10:16] <Gerry_> apps:  pdfHighlighter: command: pdfHighlighter  parts: pdfHighlighter0.0.7 plugin: jdk source: pdfHighlighter0.0.7.jar
[10:16] <bulldog> Gerry_, use pastebin
[10:16] <ogra_> Gerry_, here is a snap that uses a jar https://github.com/ogra1/jtiledownloader
[10:17] <Gerry_> ok sorry thank you
[10:17] <bulldog> Gerry_, https://github.com/keshavbhatt/snapcraft-gui/
[10:18] <bulldog> built-in pastebin to paste your current opened snapcraft.yaml
[10:21] <mup> Bug #1619721 changed: /etc/machine-id changes with every reboot <Snappy:Fix Released> <nplan (Ubuntu):Invalid> <https://launchpad.net/bugs/1619721>
[10:21] <ogra_> ogra@pi3:~$ snap list ubuntu-core
[10:21] <ogra_> Name         Version  Rev  Developer  Notes
[10:21] <ogra_> ubuntu-core  16.04.1  526  canonical  -
[10:21] <ogra_> ogra@pi3:~$ sudo snap refresh ubuntu-core --edge
[10:21] <ogra_> error: cannot refresh "ubuntu-core": snap "ubuntu-core" has no updates available
[10:21] <ogra_> ogra@pi3:~$
[10:21] <ogra_> mvo_, ^^^ shouldnt that work ?
[10:21] <ogra_> (edge has 549 for armhf)
[10:21] <shuduo> 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] <bulldog> sergiusens, https://bugs.launchpad.net/snappy/+bug/1621805
[10:25] <mup> Bug #1621805:  sudo snap abort change id wont abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
[10:25] <mvo_> ogra_: should work, maybe there really are no upgrades?
[10:26] <ogra_> mvo_, there is 549 in front of me :)
[10:26] <mvo_> shuduo: thanks, I guess people will weight in then at some point :)
[10:26] <mvo_> ogra_: when did you hit "publish"?
[10:26] <mvo_> ogra_: like - how many minutes ago?
[10:26] <ogra_> it was auto-published around 6am european time (daily build)
[10:27] <mvo_> ogra_: oh
[10:28] <ogra_> 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] <ogra_> (but that would mean we cant do updates at all for these images, since beta != stable)
[10:29] <ogra_> do you know if snapd checks fior that field somehow ?
[10:47] <Gerry_> Sorry for my mistakes in advance I am a beginner http://pastebin.com/FBny8NPq
[10:47] <mup> PR snapd#1880 opened: asserts: use gpg --fixed-list-mode to be compatible with both gpg1 and gpg2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/1880>
[10:49] <ogra_> Gerry_, check the indendation in my snapcraft.yaml, make yours look the same ... yaml is very picky about that
[10:50] <Gerry_> ok thank you
[10:57] <mup> Bug #1621800 changed: Cannot install snap on RPi due to small tmpfs in /tmp <Snappy:Confirmed> <https://launchpad.net/bugs/1621800>
[11:11] <shuduo> 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] <ogra_> shuduo, nope, it has bugs and currently doesnt start properly
[11:14] <ogra_> (but since the snap is pre-installed some auto-update will auto-fix it ;) )
[11:15] <shuduo> ogra_: got it. so "snap find *" is only way to list all available snaps, right?
[11:15] <ogra_> no, there is no way to list all snaps anymore
[11:15] <shuduo> ogra_: even later snapweb?
[11:16] <ogra_> oh, no idea how snapweb will present them
[11:16] <ogra_> but snap find wont
[11:18] <shuduo> 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] <bulldog> there is no way :D
[11:18] <bulldog> i was looking for it too
[11:19] <ogra_> 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] <ogra_> vila, https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
[11:34] <ogra_> there you go :)
[11:35] <ogra_> from https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
[11:35] <ogra_> err
[11:35] <ogra_> https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel
[11:35] <vila> ogra_: Thanks ! Looking
[11:36] <ogra_> added the link to the bug as well
[11:41] <ogra_> mvo_, i filed bug 1621843 for the above
[11:41] <mup> Bug #1621843: no way to switch ubuntu-core to --edge on images <Snappy:New> <https://launchpad.net/bugs/1621843>
[11:42] <mup> Bug #1621843 opened: no way to switch ubuntu-core to --edge on images <Snappy:New> <https://launchpad.net/bugs/1621843>
[11:47] <vila> ogra_: ok, it's in the code I suspected by via a different path
[11:47] <vila> ogra_: do you control the branch url used ?
[11:50] <vila> 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] <ogra_> vila, i do control the branch, but snapcraft does the pull ... i dont control anthing around this bit
[11:51] <vila> ogra_: how to you specify the branch to snapcraft is what I meant
[11:51] <ogra_> i'm not sure snapcraft will recognize this as bzr branch
[11:52] <ogra_> vila, http://bazaar.launchpad.net/~snappy-dev/pi2-kernel-snap/trunk/view/head:/snapcraft.yaml
[11:52] <ogra_> everything else is snapcraft magic
[11:52] <ogra_> if i just add a https:// to the source: option i doubt snapcraft will get along
[11:53] <vila> ogra_: why wouldn't it ?
[11:53] <ogra_> how would it know this is a bzr tree ?
[11:53] <vila> ogra_: lp hosts bzr and git branches
[11:53] <ogra_> yes, i think git on lp uses a special nomenclature to tell them apart
[11:54] <ogra_> in snapcraft
[11:54] <ogra_> like git+ssh:// or so
[11:54] <ogra_> (i never used lp git from snapcraft yet)
[11:54] <vila> ogra_: can you just try while I look at snapcraft ? ;)
[11:55] <qengho> source-type: bzr   ?
[11:55] <ogra_> hmmm ... these aare the official kernels i wouldnt like them to explode ...
[11:55] <ogra_> but i can perhaps set a test branch up
[11:55] <vila> ogra_: you lost me, they do explode right now no ?
[11:55] <ogra_> qengho, is that plugin independent ?
[11:55] <cjwatson> right, just use source-type: git and source: https://, if it's a public branch
[11:55] <ogra_> vila, no, they dont becaause we apply the patch to snapcraft
[11:56] <ogra_> ok, let me try source-type and https then
[11:56] <qengho> ogra_: yes, modulo plugin overrides.
[11:57] <vila> cjwatson: ha, you're there great. Is using no_proxy an option in this context ?
[11:58] <cjwatson> 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] <ogra_> hmm, how do i make it not use the PPA snapcraft without removing the package now ...
[11:58] <ogra_> i guess i have to :/
[11:59]  * ogra_ feels a bit uneasy ripping apart the workign build system on a friday afternoon ... 
[12:00] <vila> cjwatson: no_proxy=launchpad.net will affect only launchpad branches right ?
[12:01] <ogra_> ok, patched snapcraft removed, kernel snap changed
[12:01]  * ogra_ waits for the auto-build to start now
[12:01] <vila> 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] <cjwatson> rather no_proxy=bazaar.launchpad.net I guess
[12:02] <vila> cjwatson: yes, sorry ;-)
[12:02] <cjwatson> but might be worth a try, in the snapcraft Bazaar class or so
[12:03] <vila> cjwatson: but this is specific to running on the launchpad builders no ? Or do you mean you use a special version there ?
[12:03] <cjwatson> 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] <vila> haaaaaa
[12:03] <vila> the root cause seems to the '\n' in the Basic header...
[12:04] <cjwatson> 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] <vila> in httplib.py : _is_illegal_header_value = re.compile(r'\n(?![ \t])|\r(?![ \t\n])').search
[12:11] <cjwatson> vila: ah, so maybe just that the user/password combination is too long?
[12:11] <vila> cjwatson, beat me to it ;-)
[12:12] <vila> max supported length is 57
[12:12] <vila> cjwatson: Including 'Basic :'
[12:13] <cjwatson> vila: so just raw.encode('base64').strip() -> base64.b64encode(raw) would fix it then
[12:14] <vila> cjwatson: yes, in the mean time, can you use shorter user/pass ? :)
[12:14] <cjwatson> not easily
[12:14] <cjwatson> I mean, I don't think that would be any quicker a fix :)
[12:14] <vila> oh fixing is easy, getting bzr delivered and used there.... may be longer than using short user/pass is what I meant ;)
[12:15] <cjwatson> they're not that huge anyway
[12:15] <vila> sure, just big enough that nobody ever reported the issue ;)
[12:15] <cjwatson> username is the build cookie, password is a uuid
[12:16] <cjwatson> well, build cookie plus a timestamp
[12:16] <vila> do you have an example ?
[12:16] <cjwatson> 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] <cjwatson> just drop it into the same PPA
[12:16] <vila> haaaa, here we go :)
[12:17] <vila> err, but that would fix only ogra's use case right ?
[12:17] <ogra_> 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] <cjwatson> yeah, but there are only a handful of people affected by this
[12:17] <ogra_> (preferablly before EDO :) )
[12:17] <cjwatson> so we can test it in ogra_'s PPA, then SRU
[12:17] <cjwatson> that would be good enough
[12:18] <vila> ogra_: yeah, no pressure ;-)
[12:18] <ogra_> heh
[12:18] <vila> ok, let me prepare something then
[12:18] <cjwatson> vila: example username is SNAPBUILD-4665-1473322419
[12:19] <cjwatson> vila: example password is output of uuid.uuid4().hex
[12:20] <vila> cjwatson: ack, that's 6 too much (from some manual try ;)
[12:20] <vila> cjwatson: uuid.uuid4().hex[:-10] ? ;-)
[12:21] <vila> ok, ok, kidding, back to preparing a patch ;)
[12:21] <cjwatson> changing the proxy requires a production deployment via IS, changing what bzr does can be done without IS involvement using a PPA ;-)
[12:22] <cjwatson> (actually it could be changed for everyone via the snappy-dev/tools PPA)
[12:22] <ogra_> we dont really use that PPA for anything... ITYM snappy-dev/image
[12:23] <cjwatson> no, I meant what I said
[12:23] <cjwatson> lpnet-lazr.conf:tools_source: deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu %(series)s main
[12:23] <cjwatson> I told the snappy-dev team that we were doing this, ages ago :)
[12:23] <ogra_> hmm, nobody told me then ...
[12:23] <cjwatson> I'm pretty sure I did!
[12:23] <cjwatson> Let me check logs
[12:24] <cjwatson> ah, no, I talked about it with sergiusens
[12:24] <ogra_> we actually need to get rid of all PPAs for the sable builds within the next weeks
[12:24] <cjwatson> and sergiusens was the one who asked us to use that PPA
[12:24] <ogra_> *stable
[12:24] <cjwatson> this has nothing to do with image builds, it's the PPA we use for all snap builds on Launchpad
[12:25] <cjwatson> 2015-09-22.log:17:53 <cjwatson> sergiusens: are you saying that Launchpad should switch to using ppa:snappy-dev/tools rather than ppa:snappy-dev/snapcraft-daily?
[12:25] <cjwatson> 2015-09-22.log:18:00 <sergiusens> 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] <ogra_> well, then it has to do with the image builds too :)
[12:25] <cjwatson> 2015-09-22.log:18:03 <sergiusens> 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] <ogra_> since kernel and rootfs are both snaps built on lp nowadays
[12:25] <cjwatson> I'd regard ppa:snappy-dev/tools as a bit of infrastructure
[12:25] <cjwatson> just like the PPA that launchpad-buildd comes from
[12:26] <ogra_> well, sounds like i should perhaps use that PPA for livecd-rootfs then
[12:26] <cjwatson> so I don't think you need to remove it for the purposes of Ubuntu policies, by the same argument that launchpad-buildd isn't in the Ubuntu archive
[12:26] <cjwatson> that probably wouldn't work, ppa:snappy-dev/tools isn't used for livefs builds
[12:26] <ogra_> yeah
[12:27] <mup> PR snapd#1881 opened: cmd/snap: i18n option descriptions <Created by chipaca> <https://github.com/snapcore/snapd/pull/1881>
[12:27] <ogra_> well, ... i have a snap that uses a Makefile from snapcraft.yaml that in trun installs livecd-rootfs and calls lb build
[12:27] <ogra_> (and lb config etc ...)
[12:28] <ogra_> so it isnt actually a live build ... it is a live build inside a snap
[12:29] <ogra_> vila, and here is the failed build using https:// and source-type: bzr ...
[12:29] <ogra_> though i guess thats moot now
[12:29] <ogra_> https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/4734
[12:30] <vila> ogra_: yes, sorry, I asked before getting to the bottom of it, thanks for the try
[12:31] <vila> ogra_: the irony is that the '\n' in the bug subject  is hidden by the right side boxes  on https://bugs.launchpad.net/bzr/+bug/1606203 here...
[12:31] <mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Bazaar:In Progress by vila> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1606203>
[12:32] <vila> yeah, good mup, you show it !
[12:32] <ogra_> just get an 21:9 screen and expense it !
[12:33] <zyga> ogra_: I need nvidia GPU to test some stuff, do I get to expense one too? :)
[12:33] <zyga> ogra_: (even low end, just modern)
[12:33] <ogra_> zyga, wel,, dont you actully need multiple ?
[12:33] <cjwatson> vila: thanks for spotting the intervening \n there, I dug through that traceback a few times and got the wrong end of the stick
[12:34] <ogra_> to verify the breakage as well
[12:34] <zyga> ogra_: I have one old one
[12:34] <zyga> ogra_: and I think the problems are only with old and most recent nowadays
[12:34] <ogra_> and indeed you need multiple monitors to make sure the cards actually work :)
[12:34] <zyga> ogra_: the core snap is 74M big, can we make it thinner?
[12:34] <ogra_> zyga, once slangasek tells me i can drop grub from the rootfs ...
[12:35] <ogra_> then it will be around 50-60
[12:35] <zyga> ogra_: well, you have my blessing :)
[12:35] <ogra_> yeh, but i cant break kvm images now that we released them
[12:35] <cjwatson> vila: and yeah, fair call on adding a bzr task, my apologies
[12:35] <ogra_> so i need to wait for steves ok
[12:36] <vila> cjwatson: no worries, the urllib2 tracebacks have always been a pain and I knew the proxy support was tested in the field back in the days and covered heavily by tests.  Congrats on finding the length issue in any case ;)
[12:36] <ogra_> funny how grub became a pain on snappy images and uboot is so easy now
[12:37] <ogra_> but we admittedly dont use it as it was initially intended (for general ubuntu)
[12:39] <bulldog> #1621805
[12:39] <mup> Bug #1621805: sudo snap abort <change-id> won't abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
[12:41] <bulldog> zyga,  popey , mhall119 , please check this out  https://launchpad.net/bugs/1621805
[12:41] <mup> Bug #1621805: sudo snap abort <change-id> won't abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
[12:45] <popey> bulldog: abort isn't usually used like that, you could CTRL+C the running "snap install" rather than abort it from another window
[12:45] <bulldog> popey, ctrl+c wont stop the command
[12:46] <popey> yes it does
[12:46] <popey> I just tested it
[12:46] <popey> popey@localhost:~$ sudo snap install shadowsocks
[12:46] <popey> [/] Download snap "shadowsocks" (8) from channel "stable"^C
[12:46] <bulldog> command is queued in snap changes , and you have to abort them
[12:46] <ogra_> popey, snap and snapd operate async ...
[12:46] <bulldog> ctrl+c will cancel in frontend but commnad working in backend
[12:46] <popey> oh, so it does, my bad
[12:47] <ogra_> if you stop snap that might not stop snapd's operation
[12:47] <bulldog> yeah
[12:47] <bulldog> so its a bug.
[12:47] <ogra_> or a design decision :)
[12:47] <popey> yeah
[12:47] <ogra_> you need input from someone from the core team
[12:47] <bulldog> idk why once will support that design
[12:47] <bulldog> lol
[12:47] <ogra_> which all got the bug by mail, so just be patient
[12:48] <bulldog> hmm
[12:48] <ogra_> (it usually doesnt really help to ping random people about a bug unless you know that the person you ping will actually work on it)
[12:48] <bulldog> popey,  see /tmp the snap file with download progress whould be there
[12:48] <popey> bulldog: yes, i see
[12:49] <popey> (this doesn't feel urgent to me)
[12:49] <popey> but it's filed, so we'll let the devs deal with it
[12:49] <bulldog> ogra_, i was trying to confirm the bug actually
[12:50] <bulldog> popey, if you think its a bug please put a affects you in the bug page
[12:51] <bulldog> i encountered with this when i was implementing install from store feature in snapcraft-gui ,
[12:53] <ahasenack> how is that snapd postinst bug, can we deploy xenial images again?
[12:53] <ogra_> "that snapd postinst bug" ...
[12:53] <ogra_> can you be more specific ?
[12:54]  * ogra_ hasnt had any snapd postinst bug here 
[12:54] <ahasenack> really?
[12:54] <ogra_> (on two xenial machines)
[12:54]  * ahasenack fetches it
[12:55] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
[12:55] <mup> Bug #1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades <oil> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1621336>
[12:55] <ogra_> oh, cloud
[12:55] <ogra_> you should just have mentioned that and i'd had kept quiet ;)
[12:55] <ahasenack> juju deployed workloads essentially
[12:55] <bulldog> is there a way to find the size of snap package user wana install on system before hitting up he install command ???
[12:56] <ahasenack> looks still unassigned
[12:56] <ogra_> bulldog, there might be something in tehstore api
[12:56] <bulldog> ogra_,  i mean is there a command in snap yet
[12:56] <bulldog> ??
[12:56] <ogra_> nah, you are expected to use the store api for such stuff i think
[12:56] <bulldog> find should do that ,
[12:57] <bulldog> like snap find vlc , should also output snap package size .
[12:57] <ogra_> nah, it should only show if the package exists and the short description
[12:58] <ogra_> you likely mean an equivalent to apt-cache show
[12:58] <ogra_> but i doubt that will happen any time soon
[12:58] <ogra_> (simply because there is a lot other stuff on the plate before)
[13:00] <zbenjamin> do desktop files go into <snap>/setup/gui or <snap>/gui ?
[13:00] <zbenjamin> ogra_: ^ i'm sure you know :D
[13:01] <sergiusens> cjwatson fwiw, the PPA is not needed for snapcraft anymore. I recall that conversation though
[13:01] <cjwatson> sergiusens: yeah, it's not needed right now but the flexibility is useful
[13:01] <ogra_> zbenjamin, in your branch they go into $snap/setup/gui iirc
[13:01] <zbenjamin> ogra_: ok, and in the snap itself?
[13:02] <sergiusens> So thanks to vila I am killing the snapcraft hack for proxies.
[13:04] <vila> sergiusens: yeah, that sounds better, thank
[13:04] <ogra_> sergiusens, well, thanks anyway for taking it into account ...
[13:04] <vila> sergiusens: so the issue is a real (but uncommon) one: long user/pass generated in the lp setup
[13:06] <vila> ogra_, cjwatson : minimal patch available at ... ha, lp timing out :-}
[13:06] <jdstrand> roadmr: hi! at your convenience (ie, not urgent), can you pull r740 of the review tools?
[13:06] <ogra_> lol
[13:06] <sergiusens> Lol
[13:06] <vila> https://code.launchpad.net/~vila/bzr/1606203-long-auth/+merge/305328
[13:06] <roadmr> jdstrand: good morning! absolutely, I'll put it in the pipeline (but not smoke it)
[13:06] <jdstrand> hehe, thanks! :)
[13:07] <ogra_> vila, still "updating diff" ... i guess it does that via DHL
[13:08] <cjwatson> vila: wretched branch scanner.  could you force a rescan?
[13:08] <cjwatson> vila: http://people.canonical.com/~cjwatson/lp-rescan-branch -> "lp-rescan-branch lp:~vila/bzr/1606203-long-auth"
[13:09] <vila> cjwatson: yeah, I have that one installed locally from your last reference ;)
[13:13] <vila> cjwatson: branch.unscan(rescan=True) -> [u'v.ladeuil+lp@free.fr-20160909125940-4bhgpwoenpjal97c', None] Is the None expected there ?
[13:13] <vila> the revid is the right one, ran the script thrice already
[13:13] <vila> hehe, here it goes ;)
[13:18] <ogra_> geez ... how big is bzr ? ... bzr branch runs since 5min already
[13:18] <zyga> ogra_: snap install it ;0
[13:18] <ogra_> :P
[13:19] <cjwatson> vila: yes, the None is the previous scanned ID
[13:19] <cjwatson>         return (self.last_mirrored_id, old_scanned_id)
[13:20] <vila> cjwatson, ogra_ : the MP is updated now
[13:20] <cjwatson> yup, second run is normally enough
[13:20] <ogra_> yeah ... branching here since a while
[13:21] <ogra_> oh, bah ... no debian dir ?
[13:21] <ogra_> how do i build a source deb to push to the PPA ?
[13:21] <vila> right, was wondering, that's the upstream branch, what's the process ...yeah that ;)
[13:21] <cjwatson> just grab the source package from the archive
[13:21] <ogra_> funnily the upstream branch has an apport dir ...
[13:22] <ogra_> could as well have a debian dir then
[13:22] <cjwatson> you'd want that anyway in case the archive happens to have some extra patches
[13:22] <ogra_> yeah ... resorting to the archive package
[13:22] <vila> ogra_: soft dependency on apport, hysterical
[13:22] <ogra_> vila, sure, but apport is ubuntu specific ... as is the debian dir
[13:23] <ogra_> so it could have both .... seems inconsequent to only have apport there
[13:23] <vila> ogra_: agreed
[13:23] <vila> ogra_: but we don't rewrite history ;-)
[13:23] <ogra_> heh
[13:23] <ogra_> no, we repeat it :P
[13:24]  * ogra_ refrains from more political comments on IRC today :)
[13:24] <vila> :-X
[13:24] <ogra_> and indeed colin is right ... there is a bunch of patches
[13:28] <vila> ogra_: reduced when releasing 2.7, will check in a min but I doubt any of them conflict
[13:30] <pitti> mvo_: the snapd.boot-ok bug, is that on someone's high prio radar?
[13:30] <pitti> smoser: ^
[13:30] <mvo_> pitti: what was the bugnumber again?
[13:30] <smoser> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
[13:30] <mup> Bug #1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades <oil> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1621336>
[13:30] <vila> ogra_: yeah, nothing should conflict
[13:31] <pitti> ... that
[13:31] <vila> pitti: o/
[13:31] <pitti> people are coming up with increasingly embarrassing workarounds :)
[13:32] <pitti> ça va vila
[13:32] <smoser>   - "echo snapd hold | dpkg --set-selections"
[13:32] <ogra_> oh how i hate packages that need all their build-deps installed to roll a source pakcage ... grrr
[13:33] <vila> pitti: something like that yes ;-)
[13:34] <vila> pitti: trying to help ogra_ but not sure I'm succeeding ;-)
[13:34] <ogra_> vila, well, package uploaded to the PPA ... lets see
[13:34] <ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[13:35] <ogra_> i'll trigger a kernel snap once it fully landed
[13:35] <vila> ogra_: ack, sorry for the hassle :-}
[13:36] <ogra_> vila, less hassle than having to patch snapcraft every week
[13:36] <ogra_> :)
[13:36] <ogra_> and lots better than having to carry a hack in snapcraft for sergiusens
[13:36] <mup> PR snapcraft#781 closed: Workaround bzr with auth proxies <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/781>
[13:38] <vila> ?!? how did mup do that ? 8-)
[13:39] <ogra_> vila, niemeyer swings his wand and it magically does it
[13:39] <sergiusens> It was me
[13:39] <vila> sergiusens: well done, you got me there ;-)
[13:40] <ralsina> Hi, anyone knows what is "error: cannot find signatures with metadata for snap "nikola_7.8.0_amd64.snap"
[13:40] <ralsina> " when trying to install a snap I just built?
[13:41] <vila> sergiusens: just a heads-up, SRU'ing bzr will take a while, ogra_ is using a shortcut by building it in its own ppa
[13:41] <ogra_> ralsina, --force-dangerous (or if you are already on the snapd version from xenial-proposed, just --dangerous)
[13:41] <ralsina> uo--dangerous it is, thanks!
[13:41] <ralsina> ogra_: ^
[13:41] <vila> cjwatson: shortest path for SRU is via debian right ?
[13:41] <ogra_> for SRU ? i doubt that
[13:42] <ogra_> xenial-proposed ... debian is good to get it into yakkety (which you need for the SRU)
[13:42] <vila> hmm, last one came from there IIRC (or I'm confused which is not hard in this area ;)
[13:43] <ogra_> last one came from doko
[13:43] <vila> ogra_: right, so next step on the SRU road is debian, correct ?
[13:43] <ogra_> into xenial-proposed apparently
[13:43] <ogra_> yes, debian for yakkety and xenial-proposed for xenial
[13:43] <vila> ogra_: from debian IIRC (paramiko breaking compat)
[13:43] <ogra_> well, the changelog doesnt look like it came via debian into xenial-proposed
[13:44] <cjwatson> vila: no, shortest path for SRU is to get it into yakkety first (doesn't have to be via Debian, depends what's reasonable), then cherry-pick to xenial-proposed
[13:44] <vila> hmm, weird, pretty sure the original fix was by jelmer
[13:44] <cjwatson> yeah, it's in sync at the moment so might as well put it in Debian
[13:45]  * vila nods
[13:45] <vila> faster than releasing 2.7.1
[13:45] <ogra_> my PPA package was actually against xenial-updates ... https://launchpadlibrarian.net/283497088/bzr_2.7.0-2ubuntu1_2.7.0-2ubuntu2+ppa1.diff.gz ... iis clearly from doko
[13:45]  * vila mumbles pqm... lucid chroot.. grumble
[13:45] <ogra_> (see how i got both, dokos and my patch)
[13:45] <cjwatson> vila: do you have direct upload access or do you need a sponsor?  I see you're already in Uploaders
[13:46] <vila> cjwatson: very freshly in uploaders, still need sponsor (and even guidance for that matter ;-/)
[13:46] <cjwatson> send me a debdiff and I'll help
[13:47] <cjwatson> i.e. debdiff bzr_2.7.0+bzr6619-1.dsc bzr_2.7.0+bzr6619-2.dsc
[13:48] <ogra_> for xenial-proposed you can just fish debian/patches/20_1606203-long-auth.patch out of my PPA package
[13:49] <ogra_> (and add a line for it to debian/patches/series)
[13:51] <vila> cjwatson, ogra_ : thanks, shuffling through my notes to find how I did it last time
[13:56] <bulldog> bye
[13:56] <mup> PR snapd#1851 closed: interfaces: serial-port use udevUsbDeviceSnippet <Created by jocave> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1851>
[14:26] <zyga> jdstrand: hey, a small detour
[14:26] <zyga> jdstrand: I'd like to land this small change https://github.com/snapcore/snap-confine/pull/129
[14:26] <mup> PR snap-confine#129: Improve detection of nvidia driver on Ubuntu <Created by zyga> <https://github.com/snapcore/snap-confine/pull/129>
[14:39] <tenaciousmv> hi, i had a question about the node plugin. Is there support for installs from npm-shrinkwrap.json and deps from github (vs npm)?
[14:39] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/1882
[14:39] <mup> PR snapd#1882: interfaces/builtin: tweak opengl interface <Created by zyga> <https://github.com/snapcore/snapd/pull/1882>
[14:40] <mup> PR snapd#1882 opened: interfaces/builtin: tweak opengl interface <Created by zyga> <https://github.com/snapcore/snapd/pull/1882>
[14:41] <jdstrand> zyga: , ack +1
[14:48] <ogra_> oh come on ...
[14:48]  * ogra_ notes the bzr upload in the PPA is still not published 
[14:51] <mup> PR snapcraft#786 opened: Add `snapcraft list-keys` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/786>
[15:02]  * ogra_ slowly grows more gray while hair waiting for the publisher ... 
[15:05] <sergiusens> tenaciousmv not anything explicitly supported. If it is not invasive, mind adding support for it?
[15:05] <tenaciousmv> looking at the code, it seems to just call npm install, so it should be supported out of the box
[15:05] <tenaciousmv> but i was hitting some issues
[15:06] <tenaciousmv> i'll dig a bit
[15:06] <zyga> jdstrand: thank you
[15:14] <mup> PR snapd#1882 closed: interfaces/builtin: tweak opengl interface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1882>
[15:18] <vila> cjwatson: sorry for delay something like https://pastebin.canonical.com/165172/ ?
[15:20] <cjwatson> vila: seems OK but maybe add (LP: #1606203) to the changelog?  (I can do that for you if you agree)
[15:20] <mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Bazaar:In Progress by vila> <Snapcraft:Invalid by sergiusens> <https://launchpad.net/bugs/1606203>
[15:20] <vila> cjwatson: yes please !
[15:21] <cjwatson> ok, will test-build locally and upload if it works
[15:21] <cjwatson> vila: oh, I'm also deleting a spurious "." line from the patch
[15:22] <vila> cjwatson: thanks !
[15:22] <sergiusens> SamYaple_ hey there, did you have a change to look at the `--no-compile` branch comment we talked about yesterday?
[15:22] <vila> cjwatson: ha, I thought that was necessary when the description was longer than one line... not sure where I got that from ;)
[15:24] <sergiusens> vila you might be mixing it with debian/copyright
[15:25] <ogra_> rather debian/control
[15:25] <ogra_> (there you add a dot to separate two paragraphs)
[15:26] <ogra_> oh come one publisher ... its more than 1.5h
[15:26] <vila> I should just write one line descriptions and be done ;)
[15:27] <vila> ogra_: isn't the publisher just after the hour (a few mins) ?
[15:28] <ogra_> well, it seems to go slower recently
[15:28] <ogra_> especially for PPA builds
[15:28] <mup> PR snapd#1883 opened: cmd/snap,image: teach snap download to download also assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1883>
[15:29] <SamYaple_> sergiusens: i have not run it with the environment variable you suggested yet, but that shouldn't have a bearing on the patch. we still don't want to be compiling anyway (for speed purposes if nothing else)
[15:34] <mup> PR snapd#1884 opened: tests: get the gadget name from snap list <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1884>
[15:47] <zyga> jdstrand: I'd like to merge https://github.com/snapcore/snap-confine/pull/129
[15:47] <mup> PR snap-confine#129: Improve detection of nvidia driver on Ubuntu <Created by zyga> <https://github.com/snapcore/snap-confine/pull/129>
[16:29] <mup> PR snapd#1885 opened: tests: add upower-observe spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1885>
[16:37] <akash> hello all i just installed ubuntu core on a nuc and saw per documentation that the command is 'snappy' not snap? is that correct?
[16:38] <kyrofa> akash, it depends on which version of ubuntu you're using
[16:38] <kyrofa> akash, 15.04 or 16
[16:39] <akash> okay im on 15.04 it looks like
[16:40] <kyrofa> akash, then yes, it's snappy
[16:40] <akash> should i be on 16 to be consistent with docs? - for example im not able to execute snapcraft at command for example
[16:41] <akash> ive been referring to this doc : https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
[16:41] <akash> and for example on 15.04 those commands for snap or snapcraft dont work
[16:41] <kyrofa> akash, that's up to you. 16 is still in development, but it's definitely newer. You can still use snapcraft to build snaps for 15.04, but you need snapcraft 1.x for that which is only available on trusty through wily
[16:42] <kyrofa> If you're using xenial, might as well use 16 so you can test your snaps locally
[16:42] <slangasek> ogra_: you can drop grub from the rootfs any time the snappy team is happy that you no longer need u-d-f compatibility :)
[16:43] <ogra_> well, there are instructions for model assertion creation upcoming i heard ... and all supported images can be built with u-image now ...
[16:44] <ogra_> i'll probably wait til the instructions get promoted though ...
[16:44] <ogra_> slangasek, dont we need anything from it for fwupdate ?
[16:44] <slangasek> yes, for my part, I know of no blockers for dropping grub from the rootfs
[16:44] <ogra_> ok
[16:44] <ogra_> perfect
[16:44] <slangasek> fwupdate> should not need to talk to grub at all, it only talks to uefi
[16:44] <ogra_> ok
[16:45] <ogra_> i wasnt sure
[16:45] <slangasek> fwupdate definitely doesn't care what bootloader your os uses :)
[16:45] <ogra_> cool
[16:46] <ogra_> elopio, i'll roll a linux-generic-armhf kernel snap on the weekend ... that should be a good base for a beaglebone img
[16:47] <ogra_> (i have seen your mail, even though i didnt answer yet :) )
[16:51] <ogra_> finally !! bzr published ...
[16:51]  * ogra_ pokes a kernel build 
[16:56] <balloons> zyga, where did we land on the SRU for snap-confine/
[17:08] <ogra_> vila, cjwatson FYI ... https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/4746 ... bzr fix works fine
[17:35] <vila> ogra_: Yeeees ! Thanks for the feedback and sorry for the hassle (noob error, according to https://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/2363.4.5 almost 10 years ago, never reported before)
[17:35] <ogra_> hah
[17:36] <vila> The guy probably haven't finished reading RFC 2616 by the time... not to mention python 101 ;)
[17:36] <ogra_> well, my python wouldnt be much better, so no worries :)
[17:39] <ogra_> vila, and also ... who would be insane enough to create passwords with more than 5 chars anyway !
[17:40] <ogra_> :)
[17:40] <vila> ogra_: yeah, says a lot about what happened in the last 10 years :-) :--} :-D
[17:40] <ogra_> definitely :)
[17:48] <qengho> elopio: Will you please try chrome-test with  --disable-gpu  and tell me if it's better?
[17:48] <mup> PR snapcraft#779 closed: Do not compile pyc files when installing with pip <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/779>
[18:02] <qengho> jdstrand: Too bad "snap remove" doesn't mv ~/snap/pkgname to ~/.Trash/snap/ .
[18:03] <jdstrand> hey, yeah-- it totally could
[18:03] <jdstrand> qengho: I mean I had to jump through some major hoops to ensure I didn't lose my sideloaded snap's data
[18:06] <ogra_> eeek !
[18:06] <ogra_> qengho, if ever then not ~/.Trash please :)
[18:06] <akash> so i have gotten a little further per 15.04 on ubuntu core, and wondering how to get snapcraft actually installed. any ideas?
[18:08] <ogra_> (i.e. dont use a hidden dir so that people wonder why their disk is full with all snaps removed :P )
[18:08] <qengho> ogra_: of course I mean whatever XDG defines these days for trash.
[18:08] <akash> there is no apt-get on core, and hence my question, and all commands as mentioned before are snappy <command>
[18:08] <ogra_> akash, first of all, you really want 16.04
[18:10] <akash> ogra_ okay i was told snapcraft only works from trusty-wily is that correct?
[18:10] <ogra_> no it isnt
[18:10] <ogra_> for 16.04 core (which you should definitely use) you need the 16.04 snapcraft
[18:11] <ogra_> for pre-16.04 ubuntu-core the 16.04 snapcraft wornt work though
[18:11] <akash> ahhh okay very helpful
[18:11] <akash> let me give that a shot
[18:12] <ogra_> ah, i just saw the backlog ...
[18:12] <ogra_> we dotn have 16.04 NUC images, but we do have 16.04 x86 images i would expect to work http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ ...
[18:13] <ogra_> (you have to try)
[18:14] <akash> okay...and per the documentation - https://developer.ubuntu.com/en/snappy/start/intel-nuc/ it looks like it might be outdated
[18:14] <akash> if a person goes through that...they will undoubtedly hit same issues. i can file a bug to update docs
[18:14] <ogra_> well, 16.04 isnnt released yet
[18:14] <akash> as those commands simply dont work for 15.04
[18:14] <akash> on the NUC
[18:15] <ogra_> once it is the docs will point to 16.0 4
[18:15] <akash> okay sounds good. - currently pointer is here - http://snapcraft.io/docs/core/usage?utm_source=developer.ubuntu.com&utm_medium=devportal&utm_term=snaps%20snapcraft%20tour&utm_content=redirect&utm_campaign=duc_snappers
[18:19] <mup> PR snapd#1886 opened: tests: fix spread tests on yakkety <Created by mvo5> <https://github.com/snapcore/snapd/pull/1886>
[18:22] <mup> PR snapd#1883 closed: cmd/snap,image: teach snap download to download also assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1883>
[19:15] <mup> PR snapcraft#786 closed: Add `snapcraft list-keys` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/786>
[19:18] <mup> PR snapcraft#782 closed: Fix gulp plugin's npm install prefix <Created by AlexandreAbreu> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/782>
[19:18] <mup> PR snapcraft#784 closed: Support globbing for organize <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/784>
[19:19] <jdstrand> zyga: hey, fyi, adding 'unsafe' to the policy is still not in a PR. did you queue that up somewhere?
[19:54] <mup> PR snapcraft#787 opened: Release changelog for 2.17 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/787>
[20:18] <cjwatson> vila: bzr tests failed when I tried to test-build that, I'm afraid - running it again so that it actually saves the build log and then I'll send it to you
[20:26] <slangasek> ogra_: is http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ubuntu-core-16-pi3.img.xz corrupted?  I can't unxz it
[20:26] <slangasek> unxz: ubuntu-core-16-pi3.img.xz: Unexpected end of input
[21:14] <mup> PR snapd#1887 opened: cmd/snap: tweak help of 'snap download' <Created by pedronis> <https://github.com/snapcore/snapd/pull/1887>
[21:46] <akash> using snapcraft and when issuing a snapcraft stage im getting this message: The 'pull' step of 'glue' is out of date. Please clean that part's 'pull' step in order to rebuild
[21:46] <akash> whats the proper resolution steps to this ?
[22:05] <akash> sorted it out...syntax issue
[22:09] <cjwatson> vila: moving my ~/.bazaar/ aside helped a little (some of the test suite isn't properly isolated and doesn't like create_signatures = always in there), but I still get http://people.canonical.com/~cjwatson/tmp/bzr_2.7.0+bzr6619-2_amd64.build
[22:09] <cjwatson> (too large for pastebin, apparently)
[22:24] <vila> cjwatson: sry, was out. Looking. Can you file a bug for that isolation issue ? Shouldn't be hard to fix.
[22:30] <vila> cjwatson: doh, the test has a comment: # Diff returns '2' on Binary files., your failure suggests diff returned 1 ?
[22:34] <cjwatson> vila: added a note to my to-do list to file that, can't do it now.  It does indeed appear to return 1 but I can't immediately reproduce it in the 30 seconds I have available to try diff by hand.  Maybe an environment issue of some kind, I don't know, see if you can reproduce it in a sid sbuild environment?
[22:34] <vila> I didn't earlier :-/
[22:35] <cjwatson> vila: oh, diffutils 1:3.5-1 changelog
[22:35] <akash> hoping someone can help out with a novice question - once a snap is created how does one test it? i wrote one in snapcraft and now id like to see if it works or not
[22:35] <cjwatson>   * Exit status of diff for binary files that differ is now 1, not 2,
[22:35] <cjwatson>     as mandated by POSIX. Closes: #737180.
[22:35] <mup> Bug #737180: gnome-panel crashed with SIGSEGV in _panel_applet_frame_update_flags() <apport-crash> <i386> <natty> <gnome-panel (Ubuntu):Invalid> <https://launchpad.net/bugs/737180>
[22:36] <cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737180
[22:36] <cjwatson> that's pretty clear
[22:36] <vila> cjwatson: doh
[22:40] <vila> cjwatson: and this remain dormant between 2014-02 and 2014-08-31.... amazing
[22:44] <vila> cjwatson: the test doesn't cover any code relying on that behavior.
[22:45] <vila> err, typo above, dormant  2014-02 and 201*6*-08-31 i.e. 10 days ago.... amazing
[23:17] <cjwatson> vila: OK, https://bugs.launchpad.net/bzr/+bug/1622039 and https://bugs.launchpad.net/bzr/+bug/1622044
[23:17] <mup> Bug #1622039: Fails to build with diffutils 3.5 <Bazaar:New> <https://launchpad.net/bugs/1622039>
[23:17] <mup> Bug #1622044: create_signature=always causes test suite failure <Bazaar:New> <https://launchpad.net/bugs/1622044>
[23:34] <vila> cjwatson: excellent, thanks ! I need to sleep so won't followup right now. But as soon as I can.