[02:33] <lotuspsychje> good morning to all
[02:37] <Bashing-om> shift change !
[02:37] <lotuspsychje> Bashing-om: greetings mate
[02:37] <lotuspsychje> 4h37 early morning here :p
[02:39] <OerHeks> Sorry, i am late
[02:39] <OerHeks> :-D
[02:40] <lotuspsychje> OerHeks: morning mate :p
[02:40] <OerHeks> hi lotus and Bashing-om
[02:40] <lotuspsychje> awake, or still awake?
[02:41] <OerHeks> still away i am afraid
[02:41] <Bashing-om> lotuspsychje: A big hello to you also. be 9h39 here ( 2139 : 16:39 GMT +1 DST ) // In the winding down process for me .
[02:41] <lotuspsychje> ouch OerHeks  :p
[02:41] <OerHeks> awake*
[02:41] <lotuspsychje> !life
[02:41] <OerHeks> today i got devoiced in #debian, prompted an ubuntu wiki :-D
[02:41] <Bashing-om> Har har ^^
[02:42] <lotuspsychje> OerHeks: explain?
[02:42] <OerHeks> someone had trouble playing dvd's, and i didn'tnotice i was in #debian
[02:42] <lotuspsychje> omg
[02:42] <OerHeks> yeah, that channel is not alright
[02:42] <lotuspsychje> i had something likewise the other day in ##cars
[02:43] <lotuspsychje> asked a car question...and got banned lol
[02:44] <OerHeks> hmm 7.5 near Santa Cruz Islands
[02:44] <Bashing-om> OerHeks: 'devoiced' meaning you are no longer allowed to communicate ? YUK !
[02:44] <lotuspsychje> quake?
[02:44] <OerHeks> not the sun-eruptions, but the black spots on the sun cause lots of disturbance
[02:44] <OerHeks> jups
[02:45] <lotuspsychje> the world is trembling, and heating up extremely
[02:45] <OerHeks> http://quakes.globalincidentmap.com/
[02:45] <lotuspsychje> 45+ degrees in some counties
[02:46] <OerHeks> I think there is going to be an other iceage, heating up should also quicky go down
[02:46] <Bashing-om> famines and wars have already begun, people have got to eat .
[02:48] <lotuspsychje> yeah ice age, readed an article on that once
[03:25] <Bashing-om> Done for this session, Yall take care .
[03:25] <OerHeks> :-)
[03:26] <lotuspsychje> nite Bashing-om
[03:26] <Bashing-om> see ya in my 'morning' .. later.
[08:33] <lordievader> Good morning.
[10:50] <BluesKaj> Hiyas all
[11:41] <lotuspsychje> good afternoon
[11:42] <lotuspsychje> !14.10
[11:42] <BluesKaj> hey lotuspsychje
[11:42] <lotuspsychje> hi BluesKaj
[18:19] <OerHeks> 9.10 man man man
[18:47] <BluesKaj> OerHeks,  think has an old pc at least he gpu is
[18:47] <BluesKaj> the
[18:48] <OerHeks> Yes, that is true, but we need not to help with this.
[18:48] <OerHeks> also when someone has flash issues, i say flash is dead :-D
[19:11] <BluesKaj> OerHeks,  i nhope you're righjt about "flash is dead", it's been such a pita over the yrs
[19:13] <BluesKaj> 'scuse my spelling , but I'm a bit excited about my daughter sending pics on her trip on the camino in Spain...we were worried about her since we haven't heard from her in a week
[19:13] <OerHeks> If a browser activly blocks it, my idea is that this will not go undone, even when adobe makes a safe version.
[19:13] <OerHeks> yeah, did she survive the 40'C ??
[19:14] <OerHeks> or was it below that prediction
[19:14] <BluesKaj> it was rainy the first day
[19:14] <OerHeks> oehhh swell
[19:14] <BluesKaj> seems ok now
[19:15] <OerHeks> nice to hear that man!
[19:16] <OerHeks> But about the flash issue, one thing that could happen is that MS goes on with flash, while apple and us go the open drm road. also ATI comes with drivers supporting drm routines, i understand
[19:17] <OerHeks> cookies need to go too
[19:35] <BluesKaj> my understanding is that MS wants HTML5 implemented as soon as possible, they aren't flash fans either
[19:36] <BluesKaj> OerHeks, it will be interesting to see how the new MS browser "Edge" handles web video.
[19:37] <BluesKaj> on W10
[23:50] <OerHeks> EriC^^, if we were in business, you just earned $250 :-D
[23:50] <OerHeks> data recovery
[23:50] <EriC^^> lol :D


[01:33] <mpeaton> just installed 14.04, getting an error.
[01:33] <mpeaton> E: The package lists or status file could not be parsed or opened.
[02:02] <mpeaton> sudo rm /var/lib/apt/lists/* -vf
[02:02] <mpeaton>  fixed it
[06:36] <jhenke> hi, I have a problem with the 14.04 ubuntustudio 64bit iso. When I try to boot from it, it ends up in an error "initramfs" no live file system found. I already downloaded the iso twice, once direct, once via torrent. I use the exact same settings to run Xubuntu and it works like a charm, so I rule out problems with the system settings. Are there known prolem with ubuntu studio on uefi systems?
[15:05] <OvenWerk1> jhenke: I am sorry but I personally have had no problems. So long as you can see the boot screen you "should" be good.
[15:08] <jhenke> OvenWerk1 thanks for the reply, but it does not reall help me, could it be that the image is not including some kernel modules other flavours do?
[15:08] <OvenWerk1> My mother board allows me to boot the ISO as either efi or bios style... whichever way you boot is the way it will install.
[15:08] <OvenWerk1> That part is not really any different.
[15:08] <jhenke> I tried to run in Hyper-V, which works with Ubuntu and Xubuntu images
[15:08] <jhenke> but not with with UbuntuStudio
[15:09] <OvenWerk1> The only difference between the two is that the kernel has one setting changed
[15:09] <jhenke> which one?
[15:10] <OvenWerk1> Our ISO is based on xubuntu
[15:10] <OvenWerk1> preempt
[15:10] <jhenke> I know, that's why I find it strange that it does not work
[15:11] <OvenWerk1> I did purposely not install the efi on this computer, but I did on my sons... but then his is kubuntu too.
[15:12] <OvenWerk1> Give me a minute and I will boot efi on this machine.
[15:12] <jhenke> okay
[15:15] <OvenWerk1> Ok, I am now running in the live session booted from the uefi boot
[15:15] <OvenWerk1> So I am assuming you got to the grub screen anyway.
[15:15] <jhenke> hmm okay that narrows it down to a possible problem with the hypervisor
[15:15] <jhenke> yes I get the selection for live session or installing
[15:16] <jhenke> but either choice leads to the mentioned (initramfs): no live file system found problem
[15:16] <OvenWerk1> Personally I always choose live session even when installing
[15:16] <OvenWerk1> So I am no help then.
[15:17] <OvenWerk1> The other way of putting studio on is to install xubuntu and install ubuntustudio-installer and go from there
[15:20] <jhenke> not really a solution, if possible I would like to make it work, also for others that are trying the same thing
[15:20] <OvenWerk1> Makes good sense
[15:21] <jhenke> I am somehow tempted to think some required kernel module is missing in the studio image
[15:22] <jhenke> for this use case
[15:22] <OvenWerk1> Are using a real DVD? or a memstick?
[15:23]  * OvenWerk1 hasn't made a dvd for ages
[15:23] <jhenke> as it is a VM, I boot straight off the iso file
[15:24] <OvenWerk1> OK. I haven't tried any of those.
[15:24] <jhenke> but I made sure the file is not damged, downloaded it again via torrent after the prolbem appeared
[15:24] <OvenWerk1> Checking the md5sum should be enough
[15:25] <jhenke> well the torent did that
[15:26] <OvenWerk1> Ya, I use zsync for the same reason
[15:26] <jhenke> I rule out file corrpution for that reason
[15:29] <OvenWerk1> So grub boots, then starts the kernel running, and the kernel then mounts the ISO and grabs the initramfs and mounts it as a memdrive. It sounds like the kernel is looking for the ISO image in the wrong place.
[15:30] <jhenke> or it cannot access the image for some reasons
[15:30] <OvenWerk1> Ya
[15:34] <OvenWerk1> I am sorry but you are out of my knowlage area. You need someone with better vm understanding.
[15:34] <jhenke> which comes back to my original idea, is studio including all kernel modules the other falvours do?
[15:35] <OvenWerk1> As far as I know yes, even the non-free stuff like vnidia. zequence would be the person to ask though. as he does that kernel.
[15:36] <OvenWerk1> (can't spell right... nvidia)
[15:37] <OvenWerk1> I don't think it is the kernel, I think it may be the way that grub creates the commandline.
[15:37] <jhenke> okay, I am just needing the hyper-v modules
[15:37] <jhenke> well it is strange that I do see the boot screen (plymoth) but then end up in the error
[15:38] <jhenke> so I do not even have a terminal to check dmesg
[15:38] <OvenWerk1> plymouth is not loaded till after the initramfs as far as I know.
[15:39] <OvenWerk1> I think it is on that filesystem
[15:39] <jhenke> I did see the studio image though, but could also be that my memory playes tricks and it was before grub
[15:40] <OvenWerk1> As soon as you see that screen you should be able to hit esc and bump out of plymouth to consol
[15:41] <OvenWerk1> When I booted efi I had no image at all before grubs boot screen
[15:41] <OvenWerk1> When I boot non-efi there is a boot image, but that is not grb.
[15:42] <jhenke> UEFI is a bit special in the grpahics I know
[15:43] <OvenWerk1> non-efi uses syslinux to start.
[15:43] <jhenke> I just try it again
[15:44] <jhenke> okay so I am in grub
[15:44] <OvenWerk1> Have you tried starting with nomodesset? (
[15:44] <jhenke> trying live session now
[15:44] <OvenWerk1> F6 I think
[15:45] <OvenWerk1> Well I don't know on the efi grub
[15:45] <jhenke> okay long balck screen now the studio boot logo
[15:46] <jhenke> takes a long time
[15:46] <OvenWerk1> I was going to say that was normal, but I am used to starting from a slow memstick
[15:47] <OvenWerk1> How much memory do you assign to the VM session?
[15:50] <OvenWerk1> If you have got the studio spinning logo then I don't think nomodeset will help.
[15:50] <jhenke> intially, just now 512MB yesterday 1024MB, but it should be able to allocate up to 4GB
[15:51] <jhenke> the VM has balloning, i.e. the vm can get more memory from the host on request
[15:51] <OvenWerk1> I am just guessing in the dark :)
[15:53] <jhenke> I am getting this: https://www.taujhe.de/images/UbuntuStudio_error.png
[15:55] <jhenke> and it takes unusally long until it get's there
[15:55] <OvenWerk1> So initramfs in loading fine, then tries to mount the filesystem in memory and that appears to fail so when it looks for it to swroot, it is not there.
[15:56] <jhenke> I am also not getting any console there
[15:56] <jhenke> it seems completely locked
[15:56] <jhenke> CTRL+ALT+Fx does not bring any luck :(
[15:57] <OvenWerk1> In the old days that would be a kernel panic.
[15:57] <jhenke> sadly I cannot access the kernel log either... :(
[15:59] <OvenWerk1> As soon as the spinning logo shows, if you hit esc you should get logging to screen.
[15:59] <OvenWerk1> It may not be very informative logging :( but some.
[15:59] <jhenke> I think that did not work, but I try again
[16:00] <jhenke> does not work
[16:00] <OvenWerk1> does VM allow you to examine the running system from outside at all? Like look at what it has mounted or mountable?
[16:01] <jhenke> no, I really get the feeling that the Hyper-V kernel modules are not laoded
[16:01] <jhenke> (which includes the lack of keyboard input, as you need a kernel module for that under UEFI)
[16:02] <jhenke> you are using 3.13 for trusty, right?
[16:03] <OvenWerk1> uname -a
[16:03] <OvenWerk1> Linux music 3.13.0-24-lowlatency #46-Ubuntu SMP PREEMPT Thu Apr 10 19:40:23 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[16:04] <jhenke> hmm
[16:07] <OvenWerk1> a search for "hyper" on /lib/modules/ gives:/lib/modules/3.13.0-24-lowlatency/kernel/drivers/video/hyperv_fb.ko
[16:07] <OvenWerk1> /lib/modules/3.13.0-24-lowlatency/kernel/drivers/hid/hid-hyperv.ko
[16:07] <OvenWerk1> /lib/modules/3.13.0-24-lowlatency/kernel/drivers/input/serio/hyperv-keyboard.ko
[16:08] <jhenke> okay, the question now, are they included in the live image and also loaded correctly
[16:08] <OvenWerk1> there is also a hyperv folder with a net driver in it
[16:08] <jhenke> yeah that seems to be correct
[16:09] <OvenWerk1> Ok, I am at my time limit I have to play some music this morning so I have to go.
[16:10] <jhenke> OvenWerk1 okay, thanks for your answers
[16:10] <OvenWerk1> sorry they were not more helpful
[16:10] <jhenke> and your time, have fun with the musci tommorw
[16:11] <jhenke> don't worry I know it is a specific problem
[16:12] <jhenke> maybe somebody else here has an idea, I keep ideling here, so any ideas are appreciated
[21:12] <rhizo> Hi folks
[21:53] <dreamy_> is this a musicians room?
[21:55] <shostak> No idea, I'm a musician at least.


[22:10] <wgrant> lifeless: Those translations timeouts are quite impressive
[22:11] <wgrant> lifeless: 280 repetitions of various stats queries
[22:11] <wgrant> Not a clever page :/
[22:16] <czajkowski> wgrant: morning
[22:17] <wgrant> Morning czajkowski


[00:54] <Terces> no idea if I'm right here, but I am trying to install ubuntu core on my raspberrypi 3 and am having problems
[00:54] <Terces> I go through all the configuration screens, and at the end it tells me I can login through ssh, but it doesn't accept my password
[00:58] <Terces> I've gone through the steps several times so far and always the same problem.
[01:17] <mup> PR snapcraft#1030 closed: tests: fix broken delta upload unit test <Created by shawn111> <Closed by shawn111> <https://github.com/snapcore/snapcraft/pull/1030>
[02:37] <mup> PR snapd#2574 closed: interfaces/docker-support: allow /run/shm/aufs.xeno for 14.04 (LP: #1654590) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2574>
[02:44] <mahendrunitin> Hi all... can anybody point to the file which has the function that verifies the signature of a snap downloaded from the store ?
[02:45] <mahendrunitin> like when i say snap install <>
[02:45] <mahendrunitin> snapd must download the snap from the store and verify the signature before installing it.
[04:19] <mup> Bug #1639646 changed: Unable to login for first time <Snappy:Expired> <https://launchpad.net/bugs/1639646>
[05:21] <mup> PR snapd#2563 closed: cmd/snap-confine: small tweaks to seccomp support code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2563>
[05:21] <mup> PR snapd#2564 closed: cmd/snap-confine: build non-installed libsnap-confine-private.a <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2564>
[05:43] <mup> PR snapd#2575 opened: cmd: move snap-discard-ns to dedicated directory <Created by zyga> <https://github.com/snapcore/snapd/pull/2575>
[06:15] <mup> Issue snapd#2576 opened: snap-confine cannot be setuid root on openSUSE <Created by zyga> <https://github.com/snapcore/snapd/issue/2576>
[06:38] <mup> PR snapd#2577 opened: tests: improve cleanup for c-unit-tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2577>
[07:15] <mup> PR snapd#2577 closed: tests: improve cleanup for c-unit-tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2577>
[07:56] <mup> Issue snapd#2578 opened: race condition when executing interfaceManagerSuite.TestConnectTaskCheckAllowed <Created by zyga> <https://github.com/snapcore/snapd/issue/2578>
[08:04] <melvster> hi all in the tour it says to type 'snap info'
[08:04] <melvster> but that gives me
[08:04] <melvster> error: unknown command "info", see "snap --help"
[08:05] <melvster> snapcraft v 2.24
[08:05] <melvster> any ideas if snap info still works?
[08:56] <mup> PR snapd#2579 opened: many: auto-connect plugs and slots symmetrically <Created by zyga> <https://github.com/snapcore/snapd/pull/2579>
[09:06] <mup> PR snapd#2560 closed: snap: fix missing sizes in `snap info <remote-snap>` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2560>
[09:30] <mup> PR snapd#2580 opened: cmd/snap: fix internal naming in snap connect <Created by zyga> <https://github.com/snapcore/snapd/pull/2580>
[09:35] <mup> PR snapd#2581 opened: debian: remove trusty specific bits <Created by mvo5> <https://github.com/snapcore/snapd/pull/2581>
[09:45] <mup> PR snapd#2582 opened: tests: restore the missing initialization of iface manager causing race <Created by stolowski> <https://github.com/snapcore/snapd/pull/2582>
[09:52] <longsleep> Hi folks, i need to somwhere store the mac address on first boot of a snappy device. In classic ubuntu i have systemd service writing to uEnv.txt. With snappy now it would be awesonme if there would be an easy way to add a setting to uboot.env from the prepare-device hook. Anyone has a suggestion?
[09:55] <longsleep> zyga: Btw i still cannot run any command from a snap because of bind-mount permission denied on current edge. What is the state of the apparmor change you proposed in december to snap-confine?
[09:57] <mup> PR snapd#2583 opened: debian: merge feature/clean-rules-14.04 changes back to 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2583>
[10:19] <mup> PR snapd#2584 opened: snap: use "size" as the json tag in snap.ChannelSnapInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2584>
[10:25] <ogra_> longsleep, hmm, why do you need to store it ?
[10:25] <ogra_> (no way to get it from ROM ?)
[10:28] <longsleep> ogra_: the Kernel usually generates the mac address by md5(serial), but the serial on this particular kernel is always 0, thus i disabled it and always randomize it if a mac address was not passed by kernel commandline
[10:28] <ogra_> hmm, and you have no way to set a persistent serial ?
[10:28] <ogra_> we do something similar on the dragonboard
[10:29] <ogra_>           mkdir -p $(DESTDIR)/firmware/wlan; \
[10:29] <ogra_>           ln -s /run/macaddr0 $(DESTDIR)/firmware/wlan/; \
[10:29] <longsleep> ogra_: yeah, sure i could change the kernel to use the serial number from cmdline, but i did what was easiest :)
[10:29] <ogra_> thats from the dragonboard kernel snap
[10:30] <longsleep> ogra_: when is that run?
[10:30] <ogra_> at kernel snap build time
[10:31] <ogra_> (there are other bits i'm just looking up, one sec)
[10:31] <zyga> longsleep: hmm, can you please refresh my memory
[10:32] <ogra_> longsleep, http://paste.ubuntu.com/23769615/ is the matching initrd bit that reads the serial and turns it into a mac
[10:32] <longsleep> zyga: sure, you had some branch on github for snap-confine chaning something how apparmor is used
[10:32] <zyga> longsleep: and refer to a bug if you can
[10:33] <ogra_> longsleep, indeed that only works if your firmware can use /lib/firmware/wlan
[10:33] <zyga> longsleep: I have plenty of such branches, do you remember the specific one?
[10:33] <longsleep> zyga: sure, i have this problem http://paste.ubuntu.com/23769518/ and you had me try a branch on github snap-confine, the branch is gone due to the snapd merge - let me see if i can find the link
[10:34] <longsleep> ogra_: yeah, also the mac address is for ethernet, not for wlan
[10:34] <zyga> longsleep: hmmm, that's odd
[10:34] <zyga> longsleep: which version are you on?
[10:34] <longsleep> zyga: the bug i added then is https://bugs.launchpad.net/snap-confine/+bug/1645457
[10:34] <mup> Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457>
[10:34] <zyga> ah
[10:35] <zyga> on 3.10 you say
[10:35] <zyga> longsleep: thanks, I'll check what I can do
[10:35] <zyga> longsleep: I think it may require 3.10 specific code
[10:35] <longsleep> zyga: yeah but i got the aa backported, lxd and stuff works
[10:35] <zyga> okay
[10:35] <zyga> hmmm
[10:35] <zyga> is that the m10?
[10:35] <longsleep> zyga: it was this branch https://github.com/snapcore/snap-confine/tree/use-aa-support
[10:36] <longsleep> zyga: m10?
[10:36] <ogra_> heh
[10:36] <zyga> longsleep: m10 tablet
[10:36] <longsleep> zyga: nah, Pine64
[10:36] <zyga> longsleep: ok
[10:36] <ogra_> zyga, m10 is my domain ;)
[10:36] <ogra_> (starting with the image this week)
[10:36] <longsleep> zyga: you had my try the use-aa-support branch which worked, but branch is gone now
[10:36] <longsleep> s/my/me
[10:37] <zyga> longsleep: that branch was merged
[10:37] <zyga> longsleep: which version of snapd are you using?
[10:37] <longsleep> zyga: root@localhost:~# snap version
[10:37] <longsleep> snap    2.20
[10:37] <longsleep> snapd   2.20
[10:37] <longsleep> series  16
[10:38] <zyga> longsleep: ok, let me investigate
[10:38] <longsleep> i build a new image yesterday from edge channel
[10:40] <longsleep> zyga, ogra_ so the snap-confine issue and the non-persisting ethernet mac are the only two issues - if those are fixed i finally can try to publish pine64 gadget and kernel snap
[10:40] <ogra_> longsleep, i see you mention uEnv.txt above, you are aware that we dropped support for that quite a while ago ?
[10:41] <ogra_> snapd expects uboot.env
[10:41] <longsleep> ogra_: sure, i not use it on snappy
[10:41] <ogra_> ah, k
[10:41] <ogra_> (just wanted to make sure)
[10:41] <longsleep> ogra_: thats what i asked if there is a way to add additional stuff to uboot.env in some hook
[10:41] <longsleep> ogra_: of course i could make it load both, but i would rather avoid that
[10:42] <ogra_> you can add a systemd unit in the gadget ;)
[10:42] <ogra_> calling fw_setenv to set a variable in uboot.env
[10:43] <longsleep> ogra_: yeah - something like that - i would prefer it to run it in tge perpare-device hook though
[10:43] <longsleep> ogra_: that hook is run on the device on first boot right?
[10:44] <ogra_> i think so ... though thats kind of mvo land
[10:45] <longsleep> ogra_: do you know if fw_setenv is atomic? What happens on powerof while it writes?
[10:46] <ogra_> hmm, not sure ... it is designed for mtd devices and just toggles bytes ... moght not be atomic at all since it directly writes on the low level
[10:47] <ogra_> *might
[10:47] <zyga> longsleep: where do you plan to publish the gadget?
[10:47] <longsleep> ogra_: in any case the file is writting on vfat - so whenever this file changes it might become broken i would guess
[10:48] <ogra_> longsleep, but i think uboot.env itself is handled atomic
[10:48] <longsleep> zyga: the gadget snap you mean? Ubuntu store - where else would i publish it?
[10:48] <mvo> longsleep: iirc I looked at this and its writing in place
[10:48] <ogra_> due to the "CONFIG_REDUNDANT_ENVIRONMENT" option
[10:48] <zyga> longsleep: and the source?
[10:49] <longsleep> zyga: well i have it all in my building gear at https://github.com/longsleep/build-pine64-image/tree/master/snappy
[10:50] <zyga> longsleep: did you consider splitting those so that the gadget is separate
[10:50] <longsleep> mvo: mhm yeah - which is bad - but i guess you so far did not have issues people turning off their devices while that file gets written
[10:50] <zyga> longsleep: e.g. look at https://github.com/snapcore/pi3-gadget
[10:51] <ogra_> longsleep, well, no file gets written ... the window in which changes happen is very small since fw_setenv only toggles the byxtes directly
[10:51] <longsleep> zyga: no - it needs binary blobs from the general repository - i would have to copy those then too
[10:51] <zyga> longsleep: so blobs need to be in two places?
[10:51] <ogra_> longsleep, due to the uboot.env setup the filesystem isnt involved at all
[10:52] <zyga> longsleep: (same blobs?)
[10:52] <longsleep> zyga: if they are two repos yes
[10:52] <zyga> longsleep: which blobs are that?
[10:52] <longsleep> zyga: i need those blobs to build classic images as well
[10:52] <longsleep> zyga: boot0 and bl31
[10:52] <longsleep> zyga: also u-boot needs to be built first
[10:53] <longsleep> zyga: with the building gear in the larger repository
[10:53] <zyga> longsleep: too bad, it would be great if we could build a hub (on github) with community gadgets and kernels
[10:53] <longsleep> zyga: all the blobs are in https://github.com/longsleep/build-pine64-image/tree/master/blobs
[10:53] <ogra_> longsleep, the worst thing that can happen to you is that the variable holding the mac will contain garbage
[10:53] <ogra_> the env file should stay readable and rthe device should stay bootable
[10:54] <longsleep> ogra_: really? so it appends bytes only?
[10:54] <ogra_> it toggles them
[10:54] <ogra_> the file size never changes
[10:54] <longsleep> ogra_: ah sure
[10:54] <longsleep> ogra_: i remember now
[10:54] <longsleep> ogra_: the size is fixed - thanks for remembering me
[10:54] <ogra_> so on that side you should eb safe
[10:55] <ogra_> *be
[10:55] <ogra_> and for the firstboot job... as i said, mvo should be able to help
[10:56] <longsleep> zyga: yeah - i am not sure about how feasible that is as the gadget and kernel snaps usually require extra stuff like bootloaders and device trees
[10:56] <zyga> longsleep: two ways of doing that: building everything in the repo or commiting binaries into the repo and just using snapcraft to pull it from other places
[10:56] <zyga> longsleep: you can build many things in the gadget snap
[10:56] <longsleep> zyga: but i agree that a central place to find stuff would be great, but i think the store would be better suited and have meta data to point to the source repo
[10:57] <ogra_> longsleep, our gadgets moved to https://github.com/snapcore/ and are fully built by snapcraft now
[10:57] <ogra_> you can easily add a makefile part to build your upstream uboot
[10:57] <zyga> longsleep: yeah but github org to hold this would look nice even if store supports this
[10:58] <longsleep> zyga: yes
[10:58] <ogra_> zyga, i think we need an example gadget that builds from upstream uboot trees ...
[10:58] <longsleep> ogra_: why only the gadget snaps? what about kernel snaps?
[10:58]  * ogra_ adds to TODO
[10:58] <zyga> longsleep: I poked the kernel team about this
[10:58] <zyga> longsleep: they were supposed to evaluate this
[10:58] <zyga> longsleep: I didn't hear back yet
[10:58] <ogra_> longsleep, the kernel snaps are maintained by the kernel team now
[10:58] <ogra_> longsleep, and they have their own workflow not using github
[10:58] <zyga> longsleep: I'd love the kernel team to take this decision and help them along the way
[10:59] <longsleep> ogra_: right, thats possible for things which actually have a sane kernel
[10:59] <zyga> ogra_: (just keeping a mirror on github would be 100% better though)
[10:59] <ogra_> since they have a centra git server since forever where akll their trees live
[10:59] <ogra_> zyga, sure
[10:59] <ogra_> zyga, but dont forget that the official kernel snaps are always built from debs, so that wont help external users much
[11:00] <zyga> ogra_: sure, but it would help in visibility
[11:00] <zyga> ogra_: and unofficial snaps won't be this way
[11:00] <ogra_> indeed
[11:00] <zyga> ogra_: I bet more and more people will use sources to build the kernel
[11:00] <zyga> ogra_: and those examples will be valuable
[11:00] <ogra_> i hope all external people will ;)
[11:01] <ogra_> the use of debs is really a special case
[11:01] <zyga> indeed
[11:01] <longsleep> zyga: to build everything with snapcraft, it would need to build atf (bl31) from a git tree, u-boot from a git tree, some tools, then combine u-boot a device tree and bl31, and then use blob boot0 and the resulting combined u-boot-with-dtb-and-atf binary
[11:01] <zyga> longsleep: you still build those, right?
[11:01] <ogra_> longsleep, well, you can start with a tree with prebuilt binaries
[11:01] <ogra_> and then piece by piece add parts that build the stuff
[11:02] <zyga> yes, exactly!
[11:02] <longsleep> zyga, ogra_: the rest of my classic ubuntu build gear builds those
[11:02] <ogra_> longsleep, https://github.com/snapcore/pi3-gadget
[11:02] <ogra_> thats what we do here
[11:02] <longsleep> ogra_: ah ok, prebuilt folder
[11:02] <ogra_> right
[11:02] <longsleep> ogra_: sure i can do that
[11:02] <ogra_> over time this will go away
[11:02] <zyga> longsleep: start prebuilt, over time you can use launchpad to build your snap
[11:02] <zyga> longsleep: and this lets people report bugs nicely
[11:02] <zyga> longsleep: repo == bugs
[11:05] <longsleep> zyga: yeah sure i think about it once things start working :)
[11:05] <zyga> woot, great :)
[11:05] <longsleep> mvo: Quick question, the prepare-device hook of the gadget snap is run on first boot on the device?
[11:06] <longsleep> zyga: so any clue about the apparmor issue?
[11:07] <zyga> longsleep: not yet
[11:08] <longsleep> zyga: just fyi - i compared kernel patches for aa to the ones from roseapple pi and they seem to be the same, not sure if they copied from me or something though :)
[11:08] <zyga> longsleep: maybe from the ref 3.10 kernel with ubuntu aa?
[11:08] <mvo> longsleep: yes, pedronis implemented the prepare-device hook and its used in production
[11:09] <longsleep> zyga: yeah - maybe - so i think the same issue shold be on roseapple pi as well - if not then something else is a miss on my kernel tree
[11:10] <ogra_> i think ondra worked on that one, he might know
[11:29] <mup> PR snapd#2585 opened: debian: move systemd files out of ./debian and into ./data/systemd <Created by mvo5> <https://github.com/snapcore/snapd/pull/2585>
[11:31] <longsleep> This reminds me, i still cannot register a key with snapcraft: Key registration failed: The account-key-request assertion is not valid.
[11:32] <mup> PR snapd#2582 closed: tests: restore the missing initialization of iface manager causing race <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2582>
[12:15] <mardy> kyrofa: when running snapcraft from master on a project of mine, I key a KeyError on build-attributes
[12:15] <mardy> kyrofa: is this a known bug?
[12:17] <mup> PR snapd#2586 opened: daemon: make 201 and 202 responses have a Location header as per doc <Created by chipaca> <https://github.com/snapcore/snapd/pull/2586>
[12:40] <shuduo> ppisati: hi
[12:51] <mup> PR snapcraft#1034 closed: rust plugin: respect fetch parameters <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1034>
[12:57] <mardy> kyrofa: pls ignore my message above, the error was mine (launching snapcraft/main.py instead of the bin/snapcraft wrapper)
[12:58] <mup> Issue snapd#2578 closed: race condition when executing interfaceManagerSuite.TestConnectTaskCheckAllowed <Created by zyga> <Closed by stolowski> <https://github.com/snapcore/snapd/issue/2578>
[13:04] <longsleep> ogra_: to build the gadget snap with snapcraft.yaml i need hook support which has been merged 4 days ago .. is there a ppa for snapcraft where i can get that / nightly builds or something?
[13:04] <ogra_> longsleep, i think sergiusens has one, yes
[13:05] <ogra_> (now dont ask me where :P)
[13:05] <longsleep> ogra_: mhm the one i found has not seen updates since a while
[13:06] <ogra_> well, wait for sergiusens, if there is one he will know where
[13:06] <ogra_> but its python, i bet you could just branch it from github and run ./snapcraft or some such
[13:46] <mup> PR snapd#2584 closed: snap: use "size" as the json tag in snap.ChannelSnapInfo <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2584>
[14:21] <jdstrand> roadmr: hi! one more small commit to support the new 'daemon: notify': can you pull r816?
[14:21] <roadmr> jdstrand: sure! btw we haven't really deployed the laste few changes :/ sorry about that, we should have a deployment this week I reckon
[14:21] <roadmr> (but hey, they look great on staging ;)
[14:22] <jdstrand> hehe
[14:22] <jdstrand> thanks!
[14:26] <popey> sergiusens: I'm building a python app snap, but it needs a parameter after "python3 setup.py ", I don't think we support that (yet?). Any plan to? Should I file a bug?
[14:47] <mup> PR snapd#2587 opened: interfaces/mount: add snippet types <Created by zyga> <https://github.com/snapcore/snapd/pull/2587>
[14:51] <mup> PR snapd#2580 closed: cmd/snap: fix internal naming in snap connect <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2580>
[15:00] <mup> PR snapd#2588 opened: cmd/snap: add shell completion to connect <Created by zyga> <https://github.com/snapcore/snapd/pull/2588>
[15:11] <zyga> Son_Goku: hey
[15:11] <Son_Goku> zyga: hi
[15:11] <zyga> Son_Goku: I put together a wiki page that describes distro status
[15:11] <zyga> Son_Goku: and file a few more bugs describing where we are on blockers
[15:11] <Son_Goku> oh?
[15:12] <zyga> Son_Goku: I replied to the thread you just replied to
[15:12] <Son_Goku> I'm guessing you saw my reply to the email
[15:12] <Son_Goku> have you? I don't see it...
[15:12] <zyga> yes, though i worked on the wiki for a few days now
[15:13] <Son_Goku> ah, apparently it's not in the ML yet
[15:14] <zyga> Son_Goku: https://github.com/snapcore/snapd/wiki/Distributions
[15:15] <zyga> Son_Goku: can you check if the status describing fedora is accurate?
[15:15] <Son_Goku> for CentOS, it's "EPEL7"
[15:16] <zyga> ah, can you correct that
[15:16] <zyga> sorry, I always get that wrong :)
[15:17] <Son_Goku> fixed
[15:19] <zyga> thanks :)
[15:21] <mup> PR snapd#2589 opened: tests: test for auto-aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2589>
[15:21] <Son_Goku> playing whack-a-mole with snapd is exhausting though
[15:22] <Son_Goku> zyga: oh, and openSUSE supports both apparmor and selinux
[15:23] <Son_Goku> apparmor is just the default there
[15:24] <Son_Goku> there's also go bindings to libselinux, I think
[15:24]  * ogra_ recommends a whack-a-mole script
[15:24] <Son_Goku> you would :P
[15:24] <ogra_> :)
[15:27] <zyga> Son_Goku: that field describes what is available in snapd, not the distro
[15:27] <Son_Goku> ah
[15:27] <Son_Goku> well, you have "dependencies" listed
[15:27] <Son_Goku> oh, you already pulled in libselinux go bindings into snapd?
[15:30] <Son_Goku> anyway, bbs, have to go to work
[15:37] <kyrofa> elopio, are we still publishing daily builds of snapcraft to a PPA?
[15:48] <mup> PR snapcraft#1040 opened: [WIP] Run the rust test in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1040>
[15:52] <jdstrand> zyga: hey, looking at https://github.com/snapcore/snapd/wiki/Distributions you list Elementary in 'Linux Distributions' but not under 'Support Matrix'. I'm not sure if 'Support Matrix' is supposed to have everything, but if not, 'Support Matrix' should probably say 'Ubuntu 16.04 LTS and Ubuntu derivatives' (or something)
[15:54] <jdstrand> zyga: also, bug #1653487 is addressed (seccomp) for 14.04
[15:54] <mup> Bug #1653487: seccomp argument filtering not working on trusty amd64 <verification-done> <libseccomp (Ubuntu):Fix Released> <libseccomp (Ubuntu Trusty):Fix Committed by jdstrand> <https://launchpad.net/bugs/1653487>
[15:55] <jdstrand> I'll update the wiki for that seccomp
[15:56] <longsleep> kyrofa: i am looking for daily snapcraft builds too, did you find them?
[15:57] <kyrofa> longsleep, heh, I was asking for you
[15:57] <kyrofa> But he must not be in just yet
[15:57] <kyrofa> longsleep, have you tried running snapcraft from source, as ogra_ suggested?
[15:58] <longsleep> kyrofa: no - i have not - thats a bit too cutting edge and i would rather wait before merging my pr to build the gadget snap with snapcraft until there is a package available
[15:59] <longsleep> kyrofa: in the past i was using https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily - but that is not updated since a while
[15:59] <kyrofa> longsleep, fair enough. I'll continue to look into why that's no longer updated
[16:00] <longsleep> kyrofa: nice thanks!
[16:01] <longsleep> kyrofa: any chance you know something about snapcraft key registration too? i have an issue there and i cannot register any key with my account
[16:01] <kyrofa> longsleep, maybe, what's happening?
[16:02] <longsleep> kyrofa: take a look here: http://paste.ubuntu.com/23770867/
[16:03] <longsleep> kyrofa: i looked a bit at the data, and seems that the remote API returns this error message - so i figured there might be a problem with my account or something
[16:04] <kyrofa> longsleep, huh, yeah no kidding. cprov, any idea what "Key registration failed: The account-key-request assertion is not valid" might imply?
[16:10] <zyga> jdstrand: hey
[16:11] <zyga> jdstrand: it's not supposet do have everything (as it says just above the table); I like the derivatives idea, I'll try to do something like that
[16:11] <zyga> jdstrand: oh, nice, does it mean 14.04 is good now?
[16:11] <zyga> jdstrand: thanks!
[16:11] <zyga> jdstrand: btw, long time no see
[16:12] <zyga> jdstrand: I was busy with some other things but this and next week my focus is to complete mount namespace mutation for existing mount namespaces
[16:12] <zyga> jdstrand: so connect/disconnect will go and change what is there in practice without restarting apps
[16:12] <zyga> jdstrand: I've started some work towards that, if you want I can sync with you on this
[16:13] <jdstrand> zyga: you'd have to talk to tvoss for the most up to date info, but aiui, installing snapd on 14.04 desktop is fixed in ppa (and likely moving to trusty-proposed), but there remains a cgmanager issue (ie, if it is installed, systemd (and therefore snapd) fails to start
[16:13] <jdstrand> zyga: at some point a sync would be good, but I'm still trying to clear my plate to help you with snap-confine testsuite
[16:13] <zyga> jdstrand: I see, I'll wait until it is out of proposed
[16:14] <tvoss> zyga: let me know if you need anything specifically
[16:14] <zyga> jdstrand: thanks!, after your earlier suggestion only i386 is failing
[16:14] <jdstrand> cool
[16:14] <zyga> jdstrand: I'll try to fix the remaining issue, I think it is well undertood now :)
[16:14] <zyga> tvoss: monitor the issue and update the wiki once it is green :)
[16:15] <tvoss> zyga: works for me
[16:15] <jdstrand> zyga: oh, you don't need me to help for i386? ok, then I'll not plan on looking at it unless you come back
[16:16] <zyga> jdstrand: so far no, I just need a second to tweak one more thing and it should land
[16:16] <zyga> jdstrand: I will come around to it in a few hours today
[16:16]  * zyga documents live modificationto mount namespaces now
[16:26] <kyrofa> davidcalle, you around?
[16:39] <mup> Bug #1655060 opened: snapcraft doesn't support the dbus daemon type <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1655060>
[17:01] <zyga> jdstrand: my initial idea on how to implement modification of the mount namespace: https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces
[17:04] <mup> PR snapd#2550 closed: interface hooks: connect plug slot hooks (step 2) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2550>
[17:12] <mup> PR snapcraft#1041 opened: Document `notify` daemon type <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1041>
[17:15] <jdstrand> zyga: ok, thanks
[17:15] <jdstrand> tvoss: fyi, I merged the docker aufs change last night
[17:18] <elopio> nessita or ev: could you please allow Matthew from matrix to use the synapse snap name?
[17:20] <zyga> jdstrand: what does that bring?
[17:20] <zyga> jdstrand: I'm not sure I recall
[17:20] <nessita> elopio, checking!
[17:21] <nessita> elopio, did he fill name request/dispute?
[17:22] <elopio> nessita: he said: i mailed ubuntu-folks for guidance on killing off the previous snap, or getting control of it so i could replace it with the proper one
[17:22] <elopio> I'm not sure if it was through the form. Should I tell him to fill it?
[17:22] <nessita> elopio, the only snap I see is matrix-synapse owned by kyrofa
[17:23] <nessita> well, name, not snap yet
[17:23] <elopio> nessita: I think it was reserved because there is a deb binary called synapse
[17:23] <nessita> elopio, then can you please ask him to file a name dispute?
[17:23] <elopio> yes, I'm trying
[17:24] <nessita> thanks!
[17:26] <lazyPower> When i declare a bin as a daemon, is snappy creating an intermediary systemd unit file on my snaps behalf?
[17:27] <ogra_> yes
[17:28] <lazyPower> ah found it in /etc/systemd/system, thanks
[17:30] <lazyPower> say i'm using a snap in a juju charm, I suppose I just stuff the generated config bits I need the snap to read from in /var/snap/$snap/common and inform the systemd service it needs to restart?
[17:31] <jdstrand> zyga: what does what bring? the docker fix? it was a trivial policy update to the docker-support interface since trusty mounts shm on /run instead of /dev
[17:31] <zyga> jdstrand: ah, I see
[17:38] <tvoss> thx for the update
[17:58] <BrownMit> Good afternoon folks, I have a kind of weird situation with snap on a couple of my Ubuntu servers.  Google has not been helpful so I'm hoping someone here can help me out.  On most of my ubuntu servers (16.04.1) I have no issues with snap.  However, on two servers, it works but I can only seem to find a subset of the available applications.  For example, "snap find vlc" reports error: no snaps found for vlc
[18:00] <ogra_> BrownMit, "snap version" would be interesting ... and "snap list|grep core" ...
[18:01] <BrownMit> ~> snap version
[18:01] <BrownMit> snap    2.20.1ubuntu1
[18:01] <BrownMit> snapd   2.20.1ubuntu1
[18:01] <BrownMit> series  16
[18:01] <BrownMit> ubuntu  16.04
[18:02] <ogra_> the same on all servers ?
[18:02] <BrownMit> ~> snap list|grep core
[18:02] <BrownMit> core  16.04.1  712  canonical  -
[18:02] <ogra_> same question ...
[18:02] <BrownMit> yes to snap version
[18:02] <BrownMit> on one server snap cdore is at rev 714
[18:03] <ogra_> thats a different arch i guess
[18:03] <BrownMit> ahhhhhh
[18:03] <ogra_> i think vlc is only available on amd64 … so that might explain why you dont find it there
[18:03] <BrownMit> and that would be it
[18:04] <ogra_> :
[18:04] <ogra_> :)
[18:04] <BrownMit> yup, those are my only 32 bit implementations
[18:04] <BrownMit> thank you!!!
[18:04] <ogra_> np :)
[18:21] <mup> PR snapd#2589 closed: tests: test for auto-aliases <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2589>
[18:50] <anewman> Hi all. I'm looking to build a snap that has a user-extensible plugin interface with no build process (so perl scripts for plugins). Is there a good snap in existence I can use as a model for this?
[18:50] <anewman> In short, should plugins end up in data or should they be separate snaps?
[18:51] <kyrofa> mhall119, I seem to remember you having similar experience with geany and its plugins
[18:53] <mhall119> kyrofa: I did! anewman I have an example that might help you, let me get a link
[18:53] <anewman> Thanks!
[18:54] <mhall119> anewman: so here's the snapcraft.yaml for the app (geany): https://github.com/ubuntu/snappy-playpen/blob/geany/geany/snapcraft.yaml
[18:54] <mhall119> it will use a local directory called "plugins" to be the mount-point for the sharing
[18:55] <mhall119> so /snap/geany/current/plugins
[18:55] <mhall119> upstream geany provides the plugins all from one project, so I was able to built a single geany-plugins snap that has them all
[18:55] <mhall119> which is this: https://github.com/ubuntu/snappy-playpen/blob/geany/geany-plugins/snapcraft.yaml
[18:56] <anewman> alright, that makes sense to me.
[18:56] <mhall119> so in the first I define a "plug" using the content interface, with the target of ${SNAP}/plugins/
[18:56] <anewman> And one assumes that a less monolithic plugin set could end up with a set of package-plugin-pluginname snaps?
[18:56] <kyrofa> mhall119, how would you have done that if the plugins weren't all available in one package?
[18:57] <mhall119> anewman: when I did this work, that wasn't possible, but it might be now
[18:57] <anewman> Alright, interesting. Because I wouldn't want to have to whitelist the plugins in the head package.
[18:57] <mhall119> kyrofa: zyga and I discussed it, and the plan was to allow snap-namespaced mount points under the target itself
[18:57] <mhall119> IIRC
[18:57] <kyrofa> mhall119, i.e. the plug could be connected to multiple slots?
[18:58] <mhall119> kyrofa: no, the geany snap would provide one plug, that could be connected to multiple slots
[18:59] <kyrofa> mhall119, haha, isn't that what I just said?
[18:59] <kyrofa> mhall119, do you know of a bug that represents that?
[18:59] <mhall119> I thought you meant multiple slots per snap, so slot-a, slot-b, slot-c, etc
[18:59] <kyrofa> Nah, same page
[19:00]  * mhall119 checks
[19:02] <mhall119> kyrofa: I can't find one, I'm not sure we ever made a bug for it
[19:03] <kyrofa> mhall119, alright. zyga, did that plan ever progress?
[19:03] <mhall119> we discussed it in den haag
[19:04] <mhall119> is zyga in cape town this week?
[19:05] <kyrofa> Probably. You might consider making a bug for him, he has a lot going on
[19:31] <kyrofa> mhall119, does bug #1655125 properly describe the issue?
[19:31] <mup> Bug #1655125: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125>
[19:31] <mup> Bug #1655125 opened: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125>
[19:44] <zyga> mhall119: I'm not in cape town
[19:45] <zyga> mhall119: there's ongoing work on the "overmount" interface, I'm not sure that's what you were discussing but that helps people with some bits
[19:55] <kyrofa> zyga, does that cover bug #1655125?
[19:55] <mup> Bug #1655125: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125>
[19:57] <zyga> kyrofa: no
[19:57] <zyga> kyrofa: this is more store side and assertion work
[19:57] <zyga> kyrofa: if feels in scope but not in the list of things I'm going to focus on this week
[19:57] <zyga> kyrofa: this week it is https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces
[19:58] <kyrofa> zyga, ah, excellent
[20:06] <mwhudson> zyga: hey, should we request removal of the snap-confine source package from debian unstable?
[20:06] <mwhudson> zyga: it isn't going to get autoremoved because it built on lots of arches where snapd does not
[20:08] <mwhudson> aiui
[20:15] <mup> PR snapcraft#1042 opened: Add documentation for hooks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1042>
[20:29] <zyga> mwhudson: hey
[20:29] <zyga> mwhudson: I think this is sensible, unless mvo disagrees
[20:29] <zyga> mwhudson: what does that do to snapd source package, nothing I presume?
[21:36] <davidcalle> kyrofa: around now
[21:41] <mup> Bug #1607748 changed: Ability to use two registered names for the same snap <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1607748>
[21:41] <mup> PR snapd#2590 opened: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2590>
[21:43] <davidcalle> kyrofa: now that I've seen two examples, it's a bit more clear how to use scriptlets, now I'm mostly curious about 1) when do scriptlets run and if the install one is the only one supported atm 2) dash or bash? 3) any restrictions or notable boundaries on what can happen there? 4) where can I find the list of snapcraft specific env vars ($SNAPCRAFT_*)?
[21:43] <mwhudson> zyga: yeah, no impact on anything else i think
[21:46] <kyrofa> davidcalle, sure! (1) should be answered by https://github.com/snapcore/snapcraft/blob/master/snapcraft/__init__.py#L228, I think?
[21:47] <kyrofa> davidcalle, (2) /bin/sh, so dash in most cases I suspect
[21:47] <kyrofa> (3) no known restrictions
[21:48] <kyrofa> davidcalle, (4) there's actually no list, but they're SNAPCRAFT_PROJECT_NAME, SNAPCRAFT_PROJECT_VERSION, SNAPCRAFT_STAGE, and SNAPCRAFT_PART_INSTALL
[21:53] <jdstrand> diddledan: hi! fyi, https://github.com/snapcore/snapd/pull/2590 has the xdg-open fix
[21:53] <mup> PR snapd#2590: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2590>
[21:55] <davidcalle> kyrofa: do you know the use case for project_version?
[21:56] <kyrofa> davidcalle, I assume so that you can use it in `source` URLs
[21:59] <davidcalle> kyrofa: got it, thanks
[22:02] <Pharaoh_Atem> zyga: why does classic mode depend specifically on /snap?
[22:06] <diddledan> thanks jdstrand