User1: has anyone built snaps with private git/npm dependencies?
User2: Bug #1595987 changed: udev denials  <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1595987>
User3: User4 ping
User4: User3 hi
User4: User3 sounds like you know more about wifi details than me, do you want to submit a probert pr?
User3: User4 I could but not real soon
User2: PR snapd#1994 opened: snap: add `snap known --store` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1994>
User3: User4 but I think using something like https://pypi.python.org/pypi/libnl/ to talk with the kernel would be a good thing
User4: User3 huh hadn't seen that one
User3: User4 however I think for the short term not breaking when the error occurs and requesting CONFIG_CFG80211_WEXT enabled in the kernel is a good start
User4: User3 i guess the patch i added is at least better than doing nothing
User3: yeah
User3: User4 but we shouldn't close the bug with this
User4: exactly
User4: netlink is so very ... the sort of api a kernel developer would think of, i guess
User3: yeah
User4: while RTA_OK(hdr, remaining):
User4: also it's 1930 here and i'm going to try not to work every evening this week :-)
User3: User4 yeah, I agree with that!
User3: User4 just one last question
User4: heh
User3: User4 I am currently hitting the problem that I can't enter @ anymore in the "Profile setup" screen
User3: User4 this is on the edge channel
User4: User3 !
User3: on beta it works still
User4: User3 it worked on an image i made today
User4: 738
User3: hm
User4: on a dragonboard
User3: then it must be my keyboard or so
User3: this is on a pi3
User4: User3 over serial or usb?
User4: i know some keymap related stuff was added to the image recently
User4: but i didn't think we were doing anything with that yet
User3: its over a usb keyboard plugged into the dongle
User3: and having the pi on a hdmi screen
User4: yeah, that's the setup i was using
User3: then it seems to be a image problem
User2: PR snapd#1995 opened: interfaces/builtin: fix resolvconf permissions for network-manager interface <Created by morphis> <https://github.com/snapcore/snapd/pull/1995>
User3: User11 ping
User5: good mornign
User5: *morning
User6: hey hey
User7: hey dholbach, zyga
User7: User6 snap-codelabs is available FYI
User6: wow wow wow
User6: nice work didrocks
User6: mhall119_, User10 ^
User7: User6 based on mhall119_ first snapcraft.yaml, but quite tweaked to make it lightweight then :)
User6: well done!
User6: didrocks, hum, which port does it listen on?
User7: User6 see the snap long description :) 8123
User6: ah yes, of course
User6: great
User8: recently, I use nodejs to compile some project, in some cases, if I add some modules, the compilation fails. I am not sure whether this is related to our nodejs plugin or not. thanks
User3: User9 I've updated https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 , can you have another look?
User9: User3 I already did some minutes ago
User9: User3 as I said, this is fine for a PoC in a PPA, but this is not a "solution"
User9: packaging a leaf application might have this namespacing, but if you want to provide OS components as snaps they can't have the same restrictions
User9: the idea was to isolate stuff, not hardcode alternate names for snap OS parts in a hundred places (plus breaking third-party stuff which we can't control)
User3: User9 there needs to be a lot more love happening but I still think if netplan is included on ubuntu core it shouldn't come with not functional support for backends
User3: User9 I totally agree with that
User3: User9 but that is what is giving today with snaps and netplan is included as a first class citizen on Ubuntu Core so it should take care about what it supports today and ask for changes those things solved
User3: User9 I see the risk that somebody doesn't know about that patch included in the ppa and then just release a new upstream release and overrides everything
User10: User7 tried to find it on my pi, and it can't find codelabs, is that because it's amd64 only?
User3: ogra_, User20 so are you guys accepting not-upstream-patches for the netplan debian package in the ppa which ends up in the OS snap? not sure how the maintenance goes here but there needs be some ensurance that those changes are not overriden by anyone trying to bring in a new release from upstream netplan
User11: morphis_, wll, they need to be gone from the PPA and landed in -updates before november
User3: User9 ^^
User7: User12 yeah, I didn't build armhf binary (yet)
User12: ok
User11: if you guys think thats manageable, sure, lets have it in the PPA til then... the inal release must come from -updates
User11: *final
User12: User7 I can build it on my pi here if you want, where's the branch?
User9: well, then you move it from being your responsibility to fix snaps to being my responsibility to ever get rid of this :)
User3: User11 the thing is pitti does not agree with https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 and does not want it in netplan upstream
User9: and it's certaily not the only place that calls nmcli, like netplan isn't the only package that expects NetworkManager.service or bluez.service or cups.service or whatnot
User11: right, so the quetion is if it can be a distro patch in xenial ...
User3: User11 so if we can't keep the netplan package in the ppa after the final release then then this needs to be considered differently
User11: or if you guys find a proper solution before nov.
User9: yes, a distro patch in the xenial backport would be more bearable
User11: we will keep it in the PPA, but th btea and stable images wont use the PPA
User9: although it's still completely wrong
User9: this has to be fixed properly anyway at some point..
User3: User11 what do you mean by beta images?
User7: User12 it's not just a question of snapcraft snap unfortunatly, you need to have a go env ready
User7: User12 I guess it's quicker if I do it, one sec
User9: User11 ok, I'll start putting together a NetworkManager SRU for the netplan support patches then
User11: morphis_, https://wiki.ubuntu.com/QATeam/OSSnapPromotion
User9: User11 I guess you currently have that in the PPA? (which one is that?)
User11: eventually only edge will use the PPA
User11: all other channels come from proposed or updatess later
User11: (later = by release)
User9: not in https://launchpad.net/~snappy-dev/+archive/ubuntu/image
User3: User11 so the current beta images don't use the ppa?
User11: pitti, we have "a" netplan there
User2: PR snapd#1996 opened: daemon: add the actual ssh keys that got added to the create-user response <Created by mvo5> <https://github.com/snapcore/snapd/pull/1996>
User7: User12 can I fake a snapcraft snap on some arch?
User12: User7 when you say "long description" for the port number, where's that?
User9: User11 right, but netplan does not work with xenial's NM
User12: User7 dunno
User11: morphis_, currently they do, but we are workibng on getting all the PPA changes into -updates before release
User12: User7 I just have classic on my pi, so can use it to snapcraft things, works fine
User7: User12 I think nothing apart from uappexplorer exposes it
User12: oh, okay
User7: User12 hum, ok, so, I will need you :)
User7: I can give you the binary
User3: ogra_, User9 good then lets keep the patch as a distro one even for -updates
User11: morphis_, see the wikipage ... within the next two-three weeks wthis will be implemented
User3: User9 I know that there will be a discussion to allow snaps shipping things like "nmcli" so they end up with a prefix "network-manager."
User12: User7 i installed it, and see nothing on that port
User7: User12 http://localhost:8123?
User12: yes
User7: weird, did it work for you dholbach?
User11: pitti, well, i guess it works with the snapped NM ...
User6: didrocks, yes
User12: ignore me didrocks
User12: pilot error
 * didrocks ignores popey FOREVER!!! :)
User12: \o/
User7: ;)
User7: User12 so, git clone that branch: https://github.com/ubuntu/codelabs
User12: works now :)
User3: User11 it does
User7: I'll give you a binary to replace
User7: phew!
User9: morphis_, User11 ah, ok; so you don't actually need these patches in xenial-updates then, it seems?
User9: the NM ones, I mean
User11: we dont ?
User3: User9 no, for the snap we don't need the nm patches in the deb package
User11: ah, right ... i guess we dont use the deb for packaging the snap
User3: User9 we're not using the deb package for the snap at all
User13: btw, will you guys open source build server for snappys? currently it's a bit problematic building snaps for different platforms
User3: User13 you can already build snaps on launchpad for any architecture
User13: oh
User13: didn't know
User7: User12 take this binary and replace the one in the root dir with it: http://didrocks.fr/temp/codelabs
User7: User12 then, you should be able to build the snap
User7: (for armhf)
User13: User3 care to share link
User12: User7 ok
User3: User13 push a branch and look for a "Create snap package" on the overview site
User3: User13 like here: https://code.launchpad.net/~morphis/+junk/pi2-kernel-snap
User11: dz0ny_, upload your tree (bzr or git) to launchpad ... then you can pick "create snap"
User12: User7 what about "server" in that same directory, also an amd64 binary
User13: ah thx
User7: User12 silly me
User7: I didn't copy the right bin
User12: lulz
User3: User11 so can you upload a new netplan package then to the ppa if I give you one?
 * ogra_ grins about mwhudson and cyphermox playing pingpong with bug 1621550
User2: Bug #1621550: Snappy should detect when running in KVM, specify correct ssh connection line <Snappy:New> <subiquity (Ubuntu):Triaged by cyphermox> <https://launchpad.net/bugs/1621550>
User11: morphis_, sure, who will work on getting it into update ? you or pitti ?
User11: *updates
User7: User12 so, the one you want is http://didrocks.fr/temp/server :)
User7: I didn't recompile the other one, it's not shipped in the snap
User7: (it's only to build the metadata)
User3: User11 don't know, I just care to have it in the beta image we're doing for our customer this week at the moment :-)
User12: :)
User3: User9 can you take the -updates one?
User11: morphis_, well, i care to not lose it once we turn off the PPA :)
User3: yeah
User9: User3 that's backport netplan with that PR?
User3: yes
User11: well, preferably get the one from the PPA into updates
User11: not ure if there are other changes
User11: *sure
User11: (i didnt put it thre)
 * pitti creates an SRU bug
User3: User9 thanks!
User11: ppisati, so i see an oops on the pi3 ... sadly only in the combo of having console=tty0 and HDMI enabld but i think it is somehow related to the wifi card
User11: i wonder if it is the same thing i saw on the bbb
User14: User11 can fill a bug with the cmdline used to provoke this?
User11: i can even give you an image that expoes it ... as long as you dont plug in a wire on first boot ... but it scrolls offscreen and there is no wayx to get proper logs before the user is set up ... which need working network
User11: *needs
User11: the pi3 image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has it ..
 * ogra_ files bug
User9: User3 tracking in bug 1627641
User2: Bug #1627641: Backport netplan to xenial <network-manager (Ubuntu):Fix Released> <nplan (Ubuntu):Fix Released> <network-manager (Ubuntu Xenial):Triaged by pitti> <nplan (Ubuntu Xenial):Triaged by pitti> <https://launchpad.net/bugs/1627641>
User11: ppisati, bug 1627643
User2: Bug #1627643: oops on pi3 (seemingly wlan related) <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1627643>
User3: User9 ok, are you going to create a deb package with that patch now too?
User3: just that we do not do the same work twice
User9: User3 yes; we eventually want to use netplan for cloud-images etc. as well, so at some point we'll need them; and I'd rather have the integration tests actually succeed
User9: User3 (they cannot work without the NM patches)
User3: User9 ok, can you hand that package to ogra_ then so that we can include it in the ppa real soon?
User2: Bug #1627643 opened: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1627643>
User9: User3 why? AFAIK snappy edge is built with -proposed enabled, so it would suffice to just have it there? (which we can do today still)
User9: User3 I suppose you just backported Read-config-from-run.patch and Read-system-connections-from-run.patch (I'm not aware of anything else that's needed, but I'll verify with nplan's test/integration.py)
User11: pitti, no, we turned off proposed (it caued skews)
User11: *caused
User9: but if you aren't going to use the NM distro package, why do you need it in the PPA then?
User11: we need it on the image
User11: which means in the ubuntui-core snap
User9: oh, nplan doesn't backport as-is, need a pep8 fallback for pycodestyle
User9: still confused -- if you use an NM snap, you won't need the xenial-updates NM package with the /run patches in the snappy PPA
User9: and if you use the distro package, then why bother with the snap and that ugly nplan patch?
User11: no, i will need the xenial-updatess nplan
User9: oh, this was about nplan, not NM
User11: regarding NM we only care about the snap ... and that nplan doesnt break it when users install it by accident i guess
User11: break it -> the NM deb of xenial
User14: User11 i guess that is a 4.4 kernel, right?
User11: ppisati, whatever is recent in xenial, yeah
User11: 4.4.0-1023-raspi2
User14: User11 k
User9: erk, NM is stuck in xenial-proposed (v-failed), pinging Aron
User3: User9 as, those two patches are what we did
User3: User9 in edge later today is fine through -proposed but we need it in beta by the end of the week
User3: User9 if that is doable with the SRU, then I am fine, if not lets use the ppa
User9: User3 oh, please do use the PPA; I just wanted to start the process for SRUing now
User3: User9 ok, we can take the package you push to -proposed and copy it to the ppa
User9: User3 there is a NetworkManager stuck in xenial-proposed (verification-failed), so we can't get NM into -proposed today
User3: ok
User3: User9 can you ping me once the package is in -proposed?
User9: User3 sure; I also subscribed you to the bug so you get updates from that too
User3: awesome!
User2: Bug #1624490 changed: Snap access to /dev/uinput <hardware> <snapd-interface> <uinput> <Snappy:New> <https://launchpad.net/bugs/1624490>
User2: PR snapd#1997 opened: tests: added install_local function <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1997>
User11: morphis, http://ubunt.eu/zQa7Xs definitelly needs aethercast so you can have it fly while working ;)
User15: Hello. Anyone knows what's going on with ubuntu store? I can't submit any new snaps. getting unrecoverable error. And bunch of 503 when navigating the page.
User16: User15 There was a network issue recently, but if that was it it should be recovering now.
User15: understood, thanks.
User17: random thinking which I'm sure has already been considered, but I wanted to mention it anyway: gui snaps can only display text using fonts installed in the snap when it was built from what I can tell with unofficial-hexchat. would be nice to share fonts between system and snaps
User3: User9 looks like we should just update the exiting netplan package in the ppa rather than integrating recent new changes
User18: jdstrand, hey! can you have another look at https://github.com/snapcore/snapd/pull/1832 ?
User2: PR snapd#1832: interfaces/builtin: support time and date settings via 'org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832>
User19: User18 yes
User7: User12 did you build the armhf snap for me to upload?
User7: I wonder if I can't otherwise, cheat with snapcraft ;)
User12: User7 I did, but I moved location and can't ssh to the pi now :)
User12: damn firewalls!
User7: haha! Who did this! :)
User7: User12 can wait tomorrow then, no worry ;)
User12: ta
User12: it installed but I didnt get an open port and didn't have time to check logs before I left, will take a look later
User7: oki!
User20: Ã¶kt
User20: User9 hi! it looks like we may need sysfsutils as a snapd dependency
User20: User9 and therefore make it part of main, so that we can setup bits in /sys at boot time. or is there a different way to ensure /sys values are set on boot?
User9: User20 I'm sorry, do you REALLY mean sysfsutils?
User20: User9 maybe, so let me start differently. we need something that can set values in /sys
User9: User20 this is really not what you are looking for
User20: User9 oh, ok - glad I talked to you :)
User20: User9 what am I looking for?
User9: User20 man sysctl.d :)
User9: User20 *phew* :)
User20: User9 the man page talks about /proc/sys - it seems like we need /sys however. sorry, I'm sort of the messanger here only, zyga is working on gpio bits and we need to set some bits in /sys to control the right gpio
User9: User20 oh yes, that's sysctls for /proc/sys, I thought that's what you actually  meant
User9: User20 otherwise you want udev rules
User20: User9 aha, thanks, udev rules because /sys is too dynamic for the approvach that sysfsutils took?
User20: User5 you probably find the above useful -^ :)
 * zyga looks
User9: User20 no, but sysfsutils was an evolutionary dead-end
User5: oh, interesting, thank you pitti!
User5: User9 was it related to libsys2
User9: User20 it's completely useless and does not give you anything that you cannot already do with udev rules or just shell scripts, except for being racy
User9: User20 and it has been abandoned like 10 years ago
User9: User20 hence me being incredulous, sorry :)
User5: it should be removed from the archive eventually :)
User20: User9 totally fine, I was earnest when I said "glad I talked to you" :)
User5: but I'm also glad we talked, this is much easier
User5: User9 so a design question I have, perhaps: if snapd would like to generate such .conf files, should they live in /etc (which the man page reserves for the administrator) or in /run (which would require snapd to start and write them before stuff that may depend on it would)
User5: User9 hold that, I just realized I skipped the most essential message about using udev rules
User5: User9 so this is all irrelevant, thanks
User9: User5 yeah, there's always those two last crappy rdepends which keep it alive (FSVO "live")..
User9: User5 I dislike autogenerated files in /etc, as /etc should really/ideally be "settings that the admin did", not something fixed or derived
User9: i. e. only "primary" configuration
User9: User5 so if these get derived from some other/primary config, putting them into /run is much better
User9: User5 it also eases your life as then it stays an internal implementation detail which you can change at any time
User21: User20 hi, i'm trying to compile nextcloud snap target armhf on pc. then snapcraft --target-arch armhf complains "copy" plugin don't support cross compile. you have helped me on snapcraft 1.x. may i know any  solution for 2.x?
User9: User5 with /etc it never goes away and you need to deal with it on upgrades
User2: PR snapd#1998 opened: debian: re-add golang-github-gosexy-gettext-dev  <Created by mvo5> <https://github.com/snapcore/snapd/pull/1998>
User5: User9 is there a nice place we could put files in /run for udev to pick up?
User9: User5 /run/udev/rules.d/ ?
User5: User9 thanks, I see
User9: User5 but, maybe we sohuld take a step back and clarify what you want to do
User5: User9 right now I'm not going to change that but it seems like something we may want to explore down the line
User9: User5 i. e. which kind of sysfs attrs do you want to change, and at which point in time
User5: User9 well snapd has a way to influence various bits of the kernel
User5: User9 here we specifically want to export a GPIO pin to userspace
User9: User5 I mean, in the simplest case snapd could just open()/write() the attributes at startup and be done with it
 * ogra_ wonders if you rather want a snippet in /etc/sysctl.d in your package
User5: User11 no, because this is dynamic and it depends on interfaces
User11: ah, that GPIO thing again
 * ogra_ remembers we talked abot it before
User9: User5 that doesn't sound like you would need to do that super-early in the boot sequence?
User5: User9 currently when an interface needs to use udev rules we just write them to /etc/udev.d/snap.* and reload udev
User11: but yeah, why not just write to /sys then ?
User9: User5 if you need to apply that to "any future hotplugs", then yes, let snapd put udev rules into /run/udev/rules.d/
User5: User9 well, before any snap apps start
User11: without udev
User9: future hotplug events, I figure
User5: User9 I don't know if GPIO is very hotpluggable
User9: if that's a thing, write temp udev rules, then trigger those in snapd, and let the rules take care of future events
User5: User9 this is more about having a way to influence bits in sysfs
User3: User5 what is the problem with the current implementation of the GPIO iface in snapd?
User5: User3 it doesn't work across reboots, it writes to sysfs whenever you ask for a snippet
User3: right
User3: User5 should we add something like InitializeIfaceConnectionOnSnapdStartup()
User3: for an interface?
User5: User3 for this case we should use udev rules for that
User5: User3 everything else is persistent already
User3: how would udev rules apply to to sysfs nodes for GPIO's?
User5: User3 'echo' :)
User5: User3 udev can just run any command
User9: User3 erk, no
User3: User5 sure but you need an event, right?
User9: ATTR{yourattrname}="value"
User9: yeah, you need to "coldplug" (udevadm trigger) them after writing to apply to existing devices
User5: User9 we already do that
User9: "udevadm trigger --subsystem-match=gpio" or something suhc
User5: User9 well, we do a generic one
User11: dont ... that eats resources ... limit it to the subsystem
User5: User11 we don't know this
User11: :)
User5: User11 we cannot limit anything at this time
User11: now you do :)
User11: hmm
User22: Hey! I have a newbie problem in a quick python3-app snap I'm creating
User5: User11 no, we don't know this in snapd, the udev code doesn't know what snippets are doing
User5: User11 we'd have to provide richer data
User5: User11 or parse existing data
User11: but your interface does, doesnt it ?
User5: User11 no
User5: User11 interface has no way to tell
User11: if i'm the gpio interface i know i want to act on gpio's ...
User5: User11 the author might but the interface API would have to be changed in a somewhat major way to convey that today
User9: or run it before systemd-udev-trigger.service, but then it must run really early, without many assumptions
User5: User11 it's not something that's easy to change
User5: User11 then you have to combine the  changed subsystems
User5: User11 and in the end you might save some memory/whatever or get it wrong :/
User5: User11 that's not something for this release
User7: User22 hey, what's up with it?
User11: ok ok
User11: :)
User2: PR snapcraft#828 opened: yaml xpath for errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/828>
User22: My snap is a standard python3 plugin-based snap, it installs some modules and a python script to /usr/bin/ as expected, but... after installing the snap and trying to run it, I em getting an 'exec: <command here>: not found'
User22: Even though when checking the /snap installation place, the script is in the usr/bin/ directory as expected, also the wrappers *should* set the PATH correctly
User22: But still, the launcher cannot find the script
User7: interestingâ¦ You should have a .wrapper script that the script in /snap/bin points to, correct?
User7: this is just shell, you can open it and look at what's added to your env
User22: Yes, examined the wrapper and everything seems to be ok there
User7: PATH is set?
User7: to your $SNAP/usr/bin ?
User22: I examined all the scripts that are executed on the way and it should be all good, with PATHs being set etc. but it doesn't seem to work
User7: you can try:
User7: snap run --shell <your command>
User22: Oh
User7: you will then be dropped in a shell, with the snap parameter
User7: just before the wrapper is run
User11: also ... snap install hello-world ...
User7: and maybe poke from there?
User22: Yeah, hello-world works fine
User11: then you can use helo-world.env to get info about the default vars
User22: Just my snap has some issues with the paths
User11: or hello-world.sh to spawn a shell inside the snap env
User22: Oh, ok, thanks for the pointers, let me dig further then
User22: :)
User11: :)
User7: I guess snap run --shell will land him in the right context for his snap, with his code nearby and such ;)
User11: all that new-world stuff ... pfft :P
User3: User9 did you upload a new netplan package already somewhere?
User22: User7 this is really strange, I checked the environment variables when in --shell and the $SNAP variable is set correctly, I also hacked inside an echo $PATH right before the exec part in the final wrapper and the PATH also seems to be set correctly
User9: User3 no, I didn't; still working on that networkd regression; but netplan itself needs no change other than adjusting the Breaks:
User3: User9 I am going to create just an updated nplan package over the one we already have in ppa to cause no big regressions
User22: User7 and the /snap/landing-team-tools/x1/usr/bin dir has the binary as required, doing a simple PATH=/snap/landing-team-tools/x1/usr/bin:$PATH image-info (which is the command name) works in the same shell
User2: PR snapd#1999 opened: daemon: add REST API behind `snap get` <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1999>
User22: Let me try removing setting the LD_LIBRARY_PATH in the wrapper script
User22: hm, yeah, it seems that setting the LD_LIBRARY_PATH seems to somehow break the exec line, making it not find the binary
User9: User3 sure; as I said, go wild with the PPA for now
User3: aye
User7: User22 interestingly weird
User11: asac, *sniff*
User9: User3 I just figured out the necessary networkd fix (the previous one was a red herring)
User9: User3 however, with LP (and other caonical services) being down I can't update/upload anything :(
User3: User9 yeah!
User5: oh, launchpad is down
User23: Trying to create a snap, but after all of my parts finish priming, snapcraft just exists saying "[Errno 21] Is a directory: '/home/dev/swv/prime/.'" (where my snapcraft.yaml is in /home/dev/swv/)
User23: I've got three different custom plugins in this snap, though. This project does not go into a snap without a fight.
User23: But none of those plugins do anything unusual except during the build step
User11: slangasek, i assume you have seen my comment on bug 1627146 ?
User2: Bug #1627146: ubuntu-image creates 'small' ext4 filesystems, which take forever to resize <Ubuntu Image:Fix Committed by vorlon> <https://launchpad.net/bugs/1627146>
User24: I sure wish something would warn me that my snap has a vulnerability in OpenSSL that was fixed today.
User24: My snap was uploaded from a recipe in Launchpad. It could fire off builders, and then email me a link to upload the builder results to Edge channel, and another to upload to Stable channel.
User24: I wonder how hard it would be to write a snap scanner that looked for patterns that suggest a vulnerable version of dependency. Like a virus-scanner pattern searcher.
User25: User11 yep - sorry, didn't get it fixed over the weekend because of final beta trubs, but will get that sorted today
User11: no hurry ... i run my own ubuntu-image meanwhile ...
 * slangasek nods
User11: just wanted to make sure you didnt miss it
User2: PR snapd#1963 closed: daemon, overlord, store: add ReadyToBuy API to snapd <Reviewed> <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1963>
User2: PR snapd#1847 closed: many: discard preserved namespace after removing snap <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1847>
User2: PR snapcraft#829 opened: sources: fix type when calling with depth <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/829>
User2: PR snapcraft#830 opened: python plugin: only replace proper shebangs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/830>
User2: PR snapcraft#831 opened: 'sign-build' implementation <Created by cprov> <https://github.com/snapcore/snapcraft/pull/831>
User2: Bug #1627813 opened: AppArmor denies access to /etc/ld.so.preload on armhf <Snappy:New> <https://launchpad.net/bugs/1627813>
User26: Is there an online interface for the snap store where we can find snaps? It seems each developer sees his own or we have to use snapweb which doesn't list everything
User2: PR snapcraft#795 closed: WIP: snap-build generation and pushing support <Created by caio1982> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/795>
User27: ogra_, I'm confused. Why does this https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ recommend downloading ubuntu classic for rpi? Isn't that supposed to be a snappy page?
User27: ogra_, it's causing questions like this: https://raspberrypi.stackexchange.com/questions/55516/snappy-ubuntu-core-lose-ethernet-connection-after-updating
User11: kyrofa, because we still dont have official series 16 images ... though the betas might soon be good enough to replace that text
User11: (wasnt my choice btw)
User27: ogra_, yeah I figured it wasn't your choice, just that you knew the story behind it ;)
User11: it is a few months old when we had no images at all
User27: ogra_, might be handy to spell out somewhere "these are not ubuntu core images!"
User27: Right
User11: well, i think such pages should slowly start pointing to the betas ... i guess with the next beta release they might be good enough (the dailies have surely a lot bugs fixed now)
User2: PR snapcraft#830 closed: python plugin: only replace proper shebangs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/830>
User2: PR snapd#1922 closed: tests: use apt as compatible with trusty <Reviewed> <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1922>
User2: PR snapcraft#828 closed: yaml xpath for errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/828>
User28: Hi
User29: I just discovered Ubuntu Core, I would like to know which one is appropiate Ubuntu Core/Desktop/Server?
User29: I want to program soft real time application using boost library
User27: Guest8706, on what hardware will the program run?
User29: anyone could help me? Thank you!
User29: mini-PC
User27: Guest8706, will it be headless? Or do you need a graphical interface?
User29: industrial PC
User29: for testing and validation ghapical interface would be useful but not main requirement
User29: It would control cameras and laser, so sync is realy important
User27: Guest8706, how do you envision updating it?
User27: Guest8706, also, is this a one-off for your own use, or a product you intend on providing to others?
User29: a product, for selling to another company
User29: is a critical system, so we would not perform many updates
User29: kyrofa, what do you recommend?
User27: Guest8706, will it be connected to the internet?
User29: VPN
User27: Guest8706, what I'm really asking it, say you DO need to update it. Will it be able to retrieve the update via the internet, or will the user need to sideload it somehow?
User29: It would be installed outside and connected by fiber optic to the local network
User29: second option I guess
User27: Guest8706, and last question: you say soft real time, i.e. you don't expect a real-time kernel?
User29: real time is desirable, but I think I would think LinutRT or similar, is that ok?
User29: So I need to be able to control priorities of threads
User29: and make sure main process run smoothly
User29: but I think I dont need a RT OS
User29: One of my doubts is, Would i be able to use the same libraries? i.e boost library
User29: I mean when using Core version
User27: Guest8706, oh sure, the only thing special about ubuntu core is that you'd be required to use snaps
User27: Guest8706, are you familiar with snaps?
User29: Not at all
User27: Guest8706, they're a new packaging format that bundle their dependencies and are transactionally updated (i.e. can rollback upon failure)
User27: Guest8706, they're also strictly confined, which means they're more secure, but can also cause some challenges when creating the snap if your software it used to being able to walk all over the system
User29: So, it could be more challeging to set up the system?
User27: Guest8706, it also automatically updates (including the snap you put on there for your stuff), but if the device isn't connected to the internet that's not much of a win
User27: Guest8706, are you familiar with debian packaging?
User29: yes
User27: Guest8706, particularly considering that being able to login and have a GUI would be useful to you, you might consider simply using ubuntu desktop
User27: Guest8706, if, however, security is important, you might consider ubuntu core
User29: ok, thank you Kyrofa
User27: But without the internet, some of the ubuntu core advantages are negated
User29: security is important but the local network would be "protected" and traffic limited so I guess it would be OK
User27: Note that, if you play with the snap packaging format and like it, ubuntu server, desktop, and core can all use it
User27: (as well as various other linux distributions)
User29: ok, where could i start?
User27: Guest8706, right here: http://snapcraft.io/
User29: I can create snaps and test them on Desktop?
User27: Guest8706, indeed
User29: I have been about 10 years without using Linux, I am getting old, everything seems more difficult now, :)
User29: Thank you very much for your help.
User27: Guest8706, of course!
User2: PR snapd#1995 closed: interfaces/builtin: fix resolvconf permissions for network-manager interface <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1995>
User2: PR snapd#1997 closed: tests: added install_local function <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1997>
User2: PR snapd#1998 closed: debian: re-add golang-github-gosexy-gettext-dev  <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1998>
User2: PR snapcraft#829 closed: sources: fix type when calling with depth <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/829>
User30: i am using the dump plugin to copy something into my snap; i set the source property (which must be a directory), but how do I set what files to be dumped? currently all files in that source directory is being copied into the snap
User30: (which I do not want)
User27: andywork, that's how the dump plugin works-- it dumps everything in the directory into the snap. If you want to blacklist things, you can use the `stage` and `snap` keywords in the YAML
User27: (or whitelist)
User31: andyrock like in the `assets` part here https://github.com/snapcore/snapcraft/blob/master/demos/gopaste/snapcraft.yaml#L20
User11: kyrofa, do you know whats the reason for this horrid complexity (vs having the simple copy plugin syntax we had before)
 * ogra_ never understood what was wrong with the copy plugin or why we had to drop it
User30: kyrofta, User31 thanks, I'll take a look
User2: Bug #1627860 opened: run fail at missing folder /lib/modules (eg. on a virtual host) <Snappy:New> <https://launchpad.net/bugs/1627860>
User2: PR snapcraft#810 closed: nodejs plugin: Add mechanism to run ânpm runâ commands <Created by RAOF> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/810>
User2: PR snapd#1999 closed: daemon: add REST API behind `snap get` <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1999>
User2: PR snapd#1996 closed: daemon: add the actual ssh keys that got added to the create-user response <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1996>
User2: Bug #1627893 opened: A daemon is denied to write to the home directory <Snappy:New> <https://launchpad.net/bugs/1627893>
User2: PR snapd#2000 opened: snap, daemon, store: pass through screenshots from store <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2000>
snappy
Ubuntu IRC