#snappy 2016-01-25
<asac> cd /2
<JamesTait> Good evening all!  Have a rotten Monday, and a terrible Opposite Day! ð
<NoiZeR> Hello, I have a short question about Snappy. Is it possible to make a UI or open a webbrowser on a Raspberry PI with Ubuntu Snappy?
<zyga> NoiZeR: if you want to create a single function device with the webbrowser or custom UI embedded right in then yes
<lool> ogra_: hey
<lool> ogra_: just received a dragonboard, but no power supply; some websites suggest it's a 5V one, but I see 6.5V-18V next to the power socket, what do you use?
<kyrofa> Good morning
<zyga> lool: I'd love to know as well, reading 96boards forum seems to suggest you want a >> 5V PSU
<zyga> lool: there's a recommended modular adapter there (available on farnell)
<zyga> lool: but I'd love to know what orga uses before I buy one
 * lool goes scouting in his ton of power adapters
<zyga> NoiZeR: if you want to build a fixed function device then you have to provide everything: display system, application, etc
<zyga> NoiZeR: if you want you application to live among others then perhaps what you are after is ubuntu personal, not core
<zyga> NoiZeR: then you can open the web browser that you don't ship; you can see ubuntu touch for how that works
<asac> lool: is there a good tool that copies a kernel modules dependencies?
<asac> or do i have to parse Modules.dep myself?
<asac> e.g. i have built 1000 modules and want to get all modules i need for iwlwifi :)
<asac> ppisati: ?
<lool> asac: isn't there some modules_install target you can call?
<lool> or a builtin kernel function to generate an initrd?
<asac> yes, but that installs all
<asac> i couldnt find a filter target
<asac> err flag/parameter
<lool> zyga: got it booting with an universal power adapter (and old one I had lying around here)
<ppisati> asac: nope AFAIK
<zyga> lool: universal but >> 5V?
<lool> was a bit of a gamble that it worked properly and I wasn't sure of the power tip it had, but it worked
<lool> zyga: 12V yeah
<zyga> lool: I have a programmable PSU, I just have to make the right cable
<lool> specs say 7V or so at least
<zyga> lool: but I'd rather use a generic adapter because the programmable one is a bit noisy
<zyga> right
<zyga> ok
<lool> yeah; I'd also rather have a real power adapter; amazon didn't feature any with small connectors, only universal ones
<zyga> actually, I should just check that the board works with the big programmable unit
<lool> or larger ones
<zyga> lool: I have a link, one sec
<lool> now on to snappy image
<lool> the official one is https://www.arrow.com/en/products/wm24p-12-a-ql/autec-power-systems#page-1
<zyga> lool: http://es.farnell.com/ideal-power/25hk-ab-120a250-cp/fuente-alim-ext-plg-in-2-5a-12v/dp/2334605?ost=25HK-AB-120A250-CP&selectedCategoryId=
<jdstrand> mvo_ (and perhaps henrix since he uploaded it): hi! I noticed that linux-raspi2 in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages is (way) out of date
<jdstrand> sbeattie: fyi ^
<zyga> lool: thanks
<mvo_> jdstrand: *urgh*
<mvo_> jdstrand: so a new stable update
<jdstrand> mvo_: sounds like it, yes. but, before you do that, give me a couple of hours-- I'm checking if other things on the stable image are up to date
<mvo_> jdstrand: ta!
<diwic> I'm trying to build a debian package as a snap
<diwic> is there a plugin for that?
<diwic> or does my question just show that I don't understand a thing :p
<kyrofa> Hey diwic
<kyrofa> diwic, you're using snapcraft I assume?
<diwic> kyrofa, yes
<diwic> the "master"/16.04 version
<kyrofa> diwic, there's not a plugin dedicated to such a thing. In fact, depending on what you're trying to do, repackaging a .deb may not work quite as well as using the source. But you can use the `stage-packages` keyword on any of the plugins (e.g. the nil plugin if you truly only want to repackage the .deb)
<diwic> kyrofa, I suppose I want to rebuild the package for the target architecture, or...?
<kyrofa> diwic, yeah Snapcraft doesn't support cross-compiling right now
<kyrofa> diwic, so you need to run it on the target arch
<diwic> kyrofa, in this case, both are amd64
<diwic> as I'm trying with a KVM image
<kyrofa> diwic, oh, then no problem. Perhaps I misunderstood your question?
<diwic> kyrofa, well, I've been asked to make an (pulse)audio snap, and I know very little about snappy and snapcraft - i e, not much more than the official documentation, tutorials etc
<diwic> kyrofa, I do know a lot about pulseaudio though :-)
<kyrofa> diwic, well, you came to the right place :)
<kyrofa> diwic, so the shortest path to success you see is repackaging the .deb for pulse?
<diwic> kyrofa, well, the other option would be to start with upstream sources, but then I lose all the ubuntu patches to pulseaudio, and I don't want that
<kyrofa> diwic, another option is to begin a fork containing the necessary patches
<diwic> kyrofa, sounds troublesome to maintain?
<diwic> at least in the long run
<lool> ogra_: image worked, thanks!
<asac> lool: do you know what script in initramfs tools or on livecd rootfs does that module filterling/mangling?
<lool> asac: not sure what you mean wih mangling/filtering?
<lool> asac: initramfs-tools will call into shell code plugins which can do whatever they want
<lool> there is config in /etc, but the plugins are in /usr/share/initramfs-tools IIRC
<lool> each plugin might run stuff or declare some binaries to be copied
<diwic> kyrofa, but sure, we have the patches in a git tree, and so that could be the base recipe if repackaging the .deb (or actually, a few debs) is very difficult
<asac> lool: well, i want the code that picks the modules you configure and finds the dependencies to ensure all is in thhat is nererded
<asac> needed
<kyrofa> diwic, it might not be. Can you explain the large picture of what the .snap will be doing?
<asac> righht. wantg the code thatg explodes the wanted list ... to the minimal list needed (e.g. expand dependencies)
<asac> sorry for bad typing... have a big bandaid on finger as i cut it badly the other day
<diwic> kyrofa, it mediates access to sound card(s) and enables apps to play back audio through the PulseAudio API.
<kyrofa> diwic, I know what pulse is-- I'm asking what the purpose of the .snap is. You know you can't really share pulse among multiple .snaps, right?
<kyrofa> diwic, .snaps include their dependencies
<diwic> kyrofa, well, you know this better than me, but suppose we package skype as a .snap. Skype would then include the libpulse package because that's its dependency, but the pulseaudio daemon would still be unpackaged.
<diwic> kyrofa, so we need a "framework" snap for the pulseaudio daemon.
<kyrofa> diwic, ideally you'd have it in the same .snap as Skype (you can have multiple binaries/services in the same .snap)
<diwic> kyrofa, also, the skype snap would be confined - the pulseaudio framework snap has access to the sound card
<asac> lool: ok seems its using modprobe --show-depends feature
<asac> i will play with thast
<diwic> kyrofa, and third, maybe more than one snap wants to play back audio at the same time (e g, while you're playing a game, a messaging snap wants to play back a "new message" sound)
<kyrofa> diwic, I suggest you avoid frameworks for now, and begin following the capability discussion in 16.04. Frameworks as they are in 15.04 will be going away
<kyrofa> diwic, right now, 15.04 is really focused on single-use devices
<kyrofa> diwic, but 16.04 will include the ability to share things like that
<diwic> kyrofa, okay, and if I want to work on the 16.04 version of snappy, then... ?
<kyrofa> diwic, it's under pretty heavy development right now, but the image you want is here: http://people.canonical.com/~mvo/all-snaps/
<diwic> kyrofa, okay. Thanks
<asac> lool: ok cool... guess thats one way forward for nowe: http://paste.ubuntu.com/14663595/
<kyrofa> elopio, want to standup real quick?
<lool> does anyone have issue with dragonboard wifi?
<lool> it seems to be losing a ton of packets and is dog slow
<elopio> kyrofa: yes, on my way.
<zyga> what's the best place to ask question about the fan (fan networking)
<zyga> I'd like to use it but I cannot get routing to work and I just basically need someone to tell me what I'm doing wrong
<kyrofa> elopio, 1 second, need more coffee
<kyrofa> I'm so tired of shoveling snow...
<tedg> kyrofa: Time to invest in a flame thrower
<kyrofa> tedg, hahaha
<NoiZeR> Hello, how to compile your snapps for a raspberry pi. Does i need to do it on ubuntu mate. Or can I cross develop on Ubuntu Virtual machine on my desktop?
<kyrofa> elopio, ping
<kyrofa> NoiZeR, Snapcaft doesn't support cross-compiling right now, so you'll need to do it from the pi itself
<kyrofa> NoiZeR, you can do that a number of ways. Running ubuntu mate is one, running regular-old ubuntu it another, and running a cutting-edge not-yet-released Ubuntu Core that can enable classic mode is yet another
<NoiZeR> @kyrofa I cant get Snapcraft installed on my Ubuntu Mate :s
<kyrofa> NoiZeR, how come?
<kyrofa> NoiZeR, what errors are you encountering?
<nothal> NoiZeR: No such command!
<elopio> kyrofa: pong
<kyrofa> elopio, I wanted to get your opinion on this. Checkout this paste: http://pastebin.ubuntu.com/14664502/
<JamesTait> mvo_, ping
<kyrofa> elopio, intuitively, would you say the documentation directory would be included in the final .snap, or not?
<kyrofa> elopio, oh oops. Let me try that again: http://pastebin.ubuntu.com/14664508/
<NoiZeR> @kyrofa I cant install the snapyy tools :s
<nothal> NoiZeR: No such command!
<kyrofa> NoiZeR, no @ sign necessary :)
<elopio> kyrofa: I would say it won't be included, but just because I read the docs about filesets.
<elopio> the first time I saw the two - - I didn't know what to think.
<NoiZeR> kyrofa so i try to install the snappy tools but it stuck just there what can I do about it?
<kyrofa> elopio, agreed. And that directory isn't contained within stage. However, such a YAML results in an error upon snap complaining about not being able to find stuff within the documentation directory
<kyrofa> elopio, I think that's a bug
<kyrofa> elopio, since I can't think of a single time I'd want or way to exclude something from staging but including it in the .snap
<elopio> kyrofa: I agree.
 * zyga pushed https://github.com/ubuntu-core/snappy/pull/374
<zyga> this completes the internal API for skills (sans security)
<zyga> and will open up the REST API work
<zyga> and finally, security
<zyga> :)
<kyrofa> elopio, alright, thanks :)
<mvo> JamesTait: pong (but about to leave to play hockey)
<JamesTait> mvo, just a quick question: do snaps still use meta/package.yaml or is it now meta/snap.yaml? (Looking at the Trello card for supporting snappy yaml)
<JamesTait> Also, field or ice? ð
<kgunn> @snapcraft2 i dig the "progress info"
<nothal> kgunn: No such command!
<kyrofa> NoiZeR, what process are you following to install snappy-tools?
<ogra_> asac, there is code in update-initramfs that reads /etc/initramfs-tools/modules (and there is also the "MODULES=list" option that you can hand over a list of modules you want in the initrd)
<pindonga> elopio, squashed the commits on my PR: https://github.com/ubuntu-core/snapcraft/pull/197
<pindonga> not sure why coveralls is not detecting the coverage
<pindonga> since I did add the necessary tests
<elopio> pindonga: coveralls tends to lie. We just ignore it when it's being crazy.
<pindonga> ok, I leave it up to you for review then
<pindonga> :)
<pindonga> delegate as you see fit
<elopio> it shows that the coverage for the main file in the integration tests went down. Which doesn't matter, because you added coverage on your unit tests.
<elopio> so it's just making a crazy merge of both.
<pindonga> I also added an integration test for main
<pindonga> but coveralls didn't notice
<elopio> pindonga: twice as crazy then. It's just a guide, we don't reject branches just because it says so.
<pindonga> kk
<elopio> pindonga: we met a little late on friday and discussed a little about your vendor approach. Sergio wanted to take a look, but he's traveling today.
<pindonga> ok
<pindonga> happy to modify things if a better approach is known
<pindonga> though now that I squashed commits it'll be harder to undo :/
<elopio> pindonga: the only thing we agreed to was to move the examples tests from travis to jenkins, so now the xenial execution of the other tests is ready
<elopio> the rest is pending sergio's approval.
<pindonga> ack
<kyrofa> jdstrand, FYI I think ppa16 fixes an issue elopio ran into with mosquitto. But definitely appreciated! You take such good care of us
<ubuntu_geek> hi is any one here
<ubuntu_geek> ??
<ubuntu_geek> I need detailed steps to build Ubuntu Core from scratch
<ubuntu_geek> someone answer me please
<kyrofa> ubuntu_geek, what are you wanting to accomplish? i.e. why do you want to do that?
<ubuntu_geek> well, i have i386 CPU and need to try snappy
<ubuntu_geek> but there is no snappy image for i386
<ubuntu_geek> so i have to generate that image myself using "ubuntu-device-flash"
<ubuntu_geek> but that package is only on ubuntu 15.04
<ubuntu_geek> I have 12.04
<ubuntu_geek> so I thought why not building 15.04 Core then install ubuntu-device-flash package to use it for generating snappy image
<ubuntu_geek> <kyrofa> are you still there??
<kyrofa> ubuntu_geek, ah, you don't need Ubuntu Core to use ubuntu-device-flash
<kyrofa> ubuntu_geek, you just need a more recent version of Ubuntu
<kyrofa> ubuntu_geek, use at least 14.04 if not later
<ubuntu_geek> I'm accessing internet with 3G connection that have data cap
<ubuntu_geek> so downloading Ubuntu Core with about 80 MB not like Ubuntu ISO with 1 GB
<ubuntu_geek> that's why I need Ubuntu Core
<ubuntu_geek> can you help me please ?
<ubuntu_geek> <kyrofa>
<ubuntu_geek> <kyrofa> you don't want to answer me, thanks anyway
<kyrofa> ubuntu_geek, hey, wait a sec, I've got several things going on at once and I'm not always looking at IRC
<ubuntu_geek> <kyrofa> I'm Here
<kyrofa> ubuntu_geek, however, I'm afraid you may be out of luck. I actually don't know how to build it from src, especially on such an old installation
<ubuntu_geek> no I don't to build it from src
<kyrofa> ubuntu_geek, what is your definition of "scratch" then?
<ubuntu_geek> I just need install Rootfs and grub and linux kernel
<ubuntu_geek> like minimal instalation
<ubuntu_geek> *installation
<kyrofa> ubuntu_geek, yeah it doesn't work that way, sorry
<ubuntu_geek> can you explain?
<ubuntu_geek> https://wiki.ubuntu.com/Core/InstallationExample
<ubuntu_geek> this is an example but it should be used for VM not real machine
<ubuntu_geek> I need similar thing but for real machine
<kyrofa> ubuntu_geek, I'll need to refer you to ogra_, he knows a lot more here than me
<ubuntu_geek> ok, I'll appreciate it
<jdstrand> kyrofa: ah, right. you're welcome :)
#snappy 2016-01-26
<liuxg> elopio, ping
<zyga> good morning
<LefterisJP> morning
<NoiZeR> morning
<JamesTait> Good morning all!  Happy Tuesday, and happy Australia Day! ð
<mvo> kgunn: hey, if I can help with updating your mir snap, please do let me know
<asac> mvo: do i name the vmlinuz just like that in a snap or shall i append the -KERNELVERSION?
<asac> same for system.map etcv.
<mvo> asac: sorry, I disconnected, it has to be named vmlinux and initird.img for now, but that is a bug
<diwic> I've defined a git URL in "parts: pulseaudio: source:", but when I run "snapcraft pull", it does not seem to download anything. Help? (I'm using 16.04 version of snapcraft.)
<asac> mvo: vmlinux or vmlinuz?
<mvo> asac: vmlinuz
<mvo> asac: sorry
<asac> mvo: can you look into this one: https://people.canonical.com/~asac/kernel-snap-example_0_amd64.snap
<asac> and tell me beyond not appending the version is missing?
<asac> (ignore the odd initrd name)
<mvo> asac: sure, I check after lunch
<diwic> found it
<mvo> asac: from a quick look it looks great, I can give it a test in a vm next. you can use symlinks for the vmlinuz, its just needed right now so that grub can find it
<dholbach> kyrofa: thanks for the reviews
<dholbach> (https://github.com/ubuntu-core/snapcraft/pull/256 has the fix you were asking for)
<kyrofa> dholbach, thanks for the fixes :)
<kyrofa> dholbach, for what it's worth, snappy logs <package name>.<service name> doesn't seem to work for me on 15.04. Is that a 16.04 thing?
<dholbach> https://github.com/ubuntu-core/snapcraft/pull/242 is updated now too
<dholbach> kyrofa: this was part of the 15.04 appdev manual - let me check
<kyrofa> dholbach, yeah sanity check me there. I may be being stupid
<kyrofa> dholbach, https://github.com/ubuntu-core/snapcraft/pull/261 is a good-looking doc, though I wonder if it actually belongs in snappy instead of snapcraft. Thoughts?
<dholbach> kyrofa: what works for me in rolling/edge is: sudo snappy service logs shout (for shout.sergiusens)
<dholbach> let me check for 15.04
<kyrofa> dholbach, ah indeed-- but no .servicename eh?
<kyrofa> dholbach, that works on 15.04 as well
<dholbach> kyrofa: I thought about it too, but thought that if we split up our docs into "what's interesting for app developers?" and "what's general/structural information?" and "what does a device builder need to know?" ... I feel it belongs in the app context
<dholbach> kyrofa: yep - looks like it... ok, let me fix that
<kyrofa> dholbach, good deal, you're the pro there
<dholbach> kyrofa: but if we were to move the doc I guess that'd be fine with me too
<dholbach> it's just how I tried to explain the situation to myself ;-)
<kyrofa> dholbach, heh, I really just want what is most clear to developers. And you're right-- they're probably using snapcraft to make the .snap, so why not have general .snap development guides there?
<kyrofa> dholbach, of course, once you have the syncing all done to developer.ubuntu.com, it matters less
<dholbach> if we want, we can still go and split it up or move it elsewhere - I'm happy to do that if we have concensus
<kyrofa> dholbach, no I'm happy with that :)
<dholbach> cool
<diwic> awe_, so I was wondering about the autotools plugin - two questions:
<kyrofa> dholbach, snappy-debug has been around for a while now. Any idea when it'll actually include gdb, strace, ltrace, etc.?
<dholbach> jdstrand: ^ do you know if this coming soon or who might be working on it?
<diwic> awe_, 1) I have build headers installed on my local development machines, but not all dev headers are (yet) in "stage-packages".
<diwic> awe_, this seems to have the surprising result that ./configure detects them but gcc does not?
<awe_> hmmm, that sounds odd; probably something wrong in your Makefile.in
<kyrofa> diwic, dev headers don't need to be in stage-packages
<diwic> kyrofa, where should they be, then?
<awe_> kyrofa, build-packages instead?
<kyrofa> awe_, indeed. diwic snapcraft will use your system-installed packages for building, but you need to make sure stage-packages sets it up for run-time
<awe_> kyrofa, nobody's ever truly explained the diff between the two.  I use build-packages for build tools ( eg. pkg-config ) and stage-packages for dev-headers
<awe_> and I also build in a lxc container
<awe_> that I can reset to it's initial state
<awe_> so that I know my dependencies are correct
<dholbach> kyrofa: thanks for the reviews - I'll check if there's any other new content to add to snapcraft :-)
<kyrofa> diwic, so put mylib-dev in build-packages, and mylib in stage-packages
<diwic> kyrofa, ok
<kyrofa> dholbach, I'm loving the docs!
<kyrofa> diwic, build-packages install on the host (and don't go into the .snap), stage-packages go into the .snap
<awe_> kyrofa, but if you put -dev in stage-packages, it automatically pulls in the lib, and then you can just not snap the dev headers
<diwic> 2) whenever you add or remove anything in stage- or build-packages, you have to manually remove parts/pulseaudio/state for the changes to take effect. Is this expected?
<awe_> stage-packages only go in the snap if you tell them to...
<awe_> diwic, did you try using snapcraft clean?
<kyrofa> awe_, hmm... stage-packages go into the snap unless you filter them out somehow with the stage/snap keywords
<awe_> instead?
<awe_> kyrofa, which I'm currently doing...
<awe_> so I guess it's a style thing
<kyrofa> awe_, I suppose :P
<awe_> but your approach makes sense
<diwic> awe_, *testing* hmm, that works too, but that re-clones the git repo too
<awe_> I'm not sure if there's a way to clean the build w/out clobbering the source(s)
<awe_> seems like you figured out a way to cheat by manually removing the file
<diwic> I mean, there is code to check if there's a git repo and if so update it (rather than wipe and clone), when is that code supposed to be run?
<awe_> diwic, I'm not sure...  you could check the snapcraft source directly; it's all-python
<diwic> awe_, already hacked it ;-)
<awe_> ;D
<diwic> awe_, the git server I'm working against (just as a test) didn't support --depth=1 so I had to remove that
<kyrofa> diwic, I've never heard of that. What software is running on the server?
<diwic> kyrofa, no idea - git://anonscm.debian.org/pkg-pulseaudio/pulseaudio.git is the URL I'm currently testing with
<diwic> (again - might change that to something else later, this is just to get started)
<jdstrand> dholbach: I don't, no. mvo may have more info
<dholbach> mvo: ^ kyrofa asked earlier: snappy-debug has been around for a while now. Any idea when it'll actually include gdb, strace, ltrace, etc.?
<dholbach> thanks jdstrand
<diwic> awe_, 3) I was also wondering about https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/autotools.py#L85 - it ends with '--prefix=', looks weird
<diwic> awe_, what is the prefix set to and how?
<kyrofa> diwic, huh, looks like other people have hit that as well, and no one seems to know why. Perhaps you should use a snapshot .tar.gz from gitweb
<kyrofa> diwic, https://anonscm.debian.org/gitweb/?p=pkg-pulseaudio/pulseaudio.git
<awe_> diwic, I guess it depends on how self.options.configflags is initialized
<awe_> I'll check when I do my next build
<awe_> I'm in the middle of a change right now
<diwic> sure
<awe_> that said, my builds were working fine last night
<kyrofa> diwic, --prefix= means "no prefix". You can still set the prefix in the configflags though
<diwic> kyrofa, ok
<kyrofa> diwic, autotools takes the last one
<awe_> guess that explain that; thanks kyrofa
<kyrofa> awe_, hey, any time :)
<diwic> kyrofa, anyhow, so now I need to add --disable-A,  --disable-B,  --disable-C etc in configflags in order for it to skip that dependency (otherwise it'll find it as it is installed on the system)
<awe_> are you asking how to do this?
<awe_> configflags:
<kyrofa> diwic, yeah, should be easy with configflags
<diwic> awe_, I'm asking whether this is actually the desired behaviour? It seems less error prone if the part being built did *not* find system-installed headers
<awe_> http://pastebin.ubuntu.com/14671891/
<diwic> awe_, and it seems even stranger that configure finds them but not gcc
<awe_> well.. you are running configure right?
<awe_> again, that's probably because the Makefile.in is wrong
<awe_> gcc only finds what you tell it
<diwic> awe_, you have to excuse me for thinking the problem is snappy rather than Makefile.in
<awe_> diwic, it's new, and it's changing rapidly.  It *might* be a snapcraft thing, but off the top of my head, it sounds more like a Makefile.in thing
<diwic> awe_, based on the fact that snappy is very new and Makefile.in/pulseaudio is several years old, builds on many architectures and autogenerated by autotools
<awe_> sure, but you'll need to dig in and see what's really happening
<diwic> awe_, yeah
<awe_> if it is a snapcraft bug, then please report it!  ;)-
<awe_> I noticed yesterday that snapcraft --help seems to be broken in 2.0
 * awe_ needs to check if that's already been filed
<kyrofa> awe_ can you define "broken"?
<awe_> it generates a stacktrace
<kyrofa> awe_, *cough* sound broken
<awe_> http://pastebin.ubuntu.com/14671916/
<kyrofa> Ah, wait I think I read about that on the mailing list. Due to a lack of locale setting or something
<kyrofa> Definitely a bug that it's not handled in snapcraft, but you can work around it by setting your locale
<kyrofa> awe_, ^^
<awe_> kyrofa, thanks.  It's more of annoyance than anything else
<awe_> but I'll give that a try
<awe_> if/when I next need to refer to the help
<awe_> been grokin' the source instead
<kyrofa> awe_ are you running out of master? Or using 2.0.1 on xenial?
<awe_> the latter
<dholbach> kyrofa: I bet it's the â and â in the help text
<awe_> kyrofa, is it possible to add a multi-line description in snapcraft.yaml?  This seems to cause grief whenever I try to do so
<dholbach> changing them to " should probably make it work
<kyrofa> awe_ indeed, use YAML-foo!
<kyrofa> dholbach, brilliant! I'm trying to figure out how to UNset my locale to test :P
<awe_> ?
<kyrofa> awe_, heh, hold on
<kyrofa> awe_ https://stackoverflow.com/questions/3790454/in-yaml-how-do-i-break-a-string-over-multiple-lines
<kyrofa> awe_ does that help?
<kyrofa> awe_ it's just YAML, so anything YAML supports, snapcraft supports
<kgunn> so i just moved to snapcraft 2.0
<awe_> yes, of course it appears there are nine different ways to do it!  groan
<awe_> welcome to the party kgunn!
<kgunn> i used to be able to muck with my snap (fka apps) files
<kyrofa> awe_ hahaha
<kgunn> but now i can't
 * kgunn looks for disco ball
<kgunn> anyone know of a trick ?
<kyrofa> kgunn, I don't quite understand
<kyrofa> kgunn, can you define "muck"? :P
<kgunn> kyrofa: so i have a script a-la /snaps/app.sideload/bin/dostuff
<kgunn> i used to just stop my service
<kgunn> tweak it
<kgunn> but...it just refuses to become writable
<awe_> ah
<awe_> probably the change in file format of the snaps
<kyrofa> kgunn, yeah squashfs
<kgunn> yeah figure
<kgunn> but is there a trick to circumvent
<awe_> yea, but you need some squashfs foo, to be able to do so.. I looked at this yesterday, and decided it wasn't worth the trouble
<kgunn> lol
<kyrofa> kgunn, hmm.... not that I know of I'm afraid
<awe_> if you figure it out, please share the wealth
<kgunn> sure :)
<kyrofa> kgunn, I see guides for layering unionfs on top of squashfs to add write capabilities, which to me means squashfs just doesn't support writing
<kgunn> ack
<kyrofa> elopio, agh, sorry I'm late, got distracted
<mvo> dholbach: no really good idea at this point, hopefully soon when the store lands support for per-architecture snap
<awe_> kyrofa, seems on the "flow" style line wrapping methods are supported which strip any embedded new lines...
<mvo> dholbach: snaps
<mvo> dholbach: right now it would have to be a pretty big snap that is a bit tricky to build
<elopio> fgimenez: ping. Could you ssh?
<dholbach> kyrofa: ^ see what mvo said?
<kyrofa> dholbach, yeah, good info. I'm a little worried a developer might miss the "snappy-debug only includes security right now" note and wonder why he can't use strace after reading the docs
<kyrofa> dholbach, what do you think?
<asac> mvo: is there the notion of a type: in snap.yamnl still?
<asac> e.g. should snapcraft learn about type: kernel? etc.?
<mvo> asac: yes
<asac> mvo: did you take a look at the .sanp? i uploaded a new one
<dholbach> kyrofa: ok, let me change it a little bit
<asac> kyrofa: does snapcraft already allow me to use type: kernel ? e.g. in the yaml?
<asac> ../../bin/snapcraft clean
<asac> Issues while validating snapcraft.yaml: 'kernel' is not one of ['app']
<asac> ok seems not
<mvo> asac: should I test it?
 * asac checks and adds
<asac> mvo: well, the initrd has modules only
<asac> beyond that is there anything missing compared from what you added?
<mvo> asac: I think its fine, won't work right now because we don't have the generic-initrd yet, but that is something someone needs to work on soon
<kyrofa> asac, yeah I don't think so yet
<asac> mvo: lool is experimenting with how to concat those initrd
<asac> in the bootloaders
<asac> kyrofa: ok... i will incolude that in my mammoth patchset :)
<asac> was just a scheme patch
<mvo> asac: cool
<mvo> asac: accoridng to apw its really just "cat initird1 initird2> initrd.img" and the kernel will DTRT
<asac> lool: will you work on getting an indep initrd into OS snap from our builders?
<asac> yeah
<asac> but we prefer to not concat on disk
<asac> but rather from bootloader
<asac> e.g. have them load both files and just boot
<mvo> asac: if the boorloader supports it
<asac> thats what lool is testing now
<mvo> asac: I think for grub thats fine and we can do that
<asac> e.g. grub + u-boot
<asac> think both could work
<dholbach> kyrofa: updated - let me know if it's cleare now :)
<lool> (I'm installing the test machine ATM)
<asac> cool
<mvo> asac: but uboot seems to not support it, but that is ok because for uboot we need to extract the kernel and initird anyway so we might as well do more magic
<apw> they need to be next ot each other in memory and the right bracketing start,length passed to the kernel
<asac> uboot allows to load to raw mem position
<mvo> asac: trouble if of course rollback, once we combine them on disk everything becomes harder
<asac> so trick is to just load the two files neck to neck
<kyrofa> dholbach, ah, yeah that works :)
<asac> yeah
<mvo> asac: yeah, uboot is flexible enough for that
<lool> apw: is there an easy well to tell grub / u-boot to do this, or do we need to write all the tiny scripting logic to compute the addresses and kernel args?
<asac> uboot needs to have special boot partition anyway right?
<asac> or can we read squshfs etc. there?
<lool> no we cant
<mvo> asac: it has special handling
<lool> albeit there are patches to run grub-efi as a payload to u-boot now
<asac> right. so arm still needs to gert files put into special place
<apw> lool, can't say as i have ever looked at it, typically initrds are single things loaded and that sets the kernel data at the same time
<asac> we can as well concat them when doing that
<asac> but having them cleanly separate is surely better
<asac> guess also for trusted boot etc.
<asac> lool: grub allows just list of files for initrd
<asac> i found on some blog
<lool> apw: IIUC, the concatenation only works for init ramdisks, not initramfses; is there a big difference between the two we shoudl be worried about?
<asac> so just initrd list of files
<lool> asac: ah cool
<asac> uboot you have to somewaht load first, then parse the end address
<asac> and load second to that
<apw> lool, it only works for the initramfs format ones, ie the cpio.gz style ones, those can be concantenated and the kernel will unpakc them all into the kernel root ramdisk before entering it
<lool> apw: and are all kernel compression types supported, or only gz?
<lool> is it ok if we do gz?
<apw> lool, i believe its all of the initrd compression types which are enabled in your kernel config
<asac> lool: http://savannah.gnu.org/bugs/?35238
<asac> not sure how it was fixed
<asac> but seems it got fixed
<Sweet5hark> trying to setup a vagrant snappy image results in ssh timeout failure on "vagrant up" ...
<asac> apw: is it very dirty (or even breaks) to ship the full modules.dep if i only have a subset of the modules (e.g. ship the full in the initrd)?
<apw> asac, it is just a dependancy list, so i would expect that to be non-fatally "wrong"
<qengho> Are there xenial snappy test images for download? I can't find any.
<asac> ok here status quo ... https://github.com/asac/snapcraft/commits/kbuild-kernel-wip for those taht want to produce not-yet-booting kernel snaps
<apw> asac, though if the device dependant parts contain nonoverlapping subsets it is not clear how you can make a correct one in the generic bit anyhow, as it does not list the non-gneeric bits
<asac> https://github.com/asac/snapcraft/blob/kbuild-kernel-wip/examples/kernel/snapcraft.yaml
<apw> asac, or indeed visa-versa
<asac> apw: hmm. well its that i managed to filter the right modules out of my local build, just dont want to write code to remake a modules.dep with just that subset
<asac> e.g. i am using it from the right tree (not the generic one)
<asac> (if i understood your comment correctly)
<Sweet5hark> Showing the VM in the VirtualBox UI gives me a something apparently looping a kernel boot again and again. any hints?
<asac> utlemming: ^^
<asac> Sweet5hark: utlemming is vagrant/vbox expert... not sure if he is around today though
<NoiZeR> hello, im busy with compiling Boost on Ubuntu 14.04 LTS but does i need to compile it before i make a snap of it?
<utlemming> Sweet5hark: I've seen that once before and it was the CPU.
<utlemming> Sweet5hark: can you capture what happens immediately before reboot?
<NoiZeR> Or can i just install boost itself on snappy?
<Sweet5hark> utlemming: any hints on what to press to prevent the box from rebooting right away?
<asac> NoiZeR: you can use snapcraft to pull the binaries from archive
<asac> into your snaop
<NoiZeR> ok do you know where the binaries are?
<NoiZeR> asac see above
<kyrofa> elopio, would you mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/210 when you have a chance? I want one more pair of eyes
<asac> NoiZeR: dont know if i understand your question
<asac> do you know the ubuntu packages you want?
<asac> i would suggest to start with making a xenial chroot, and then use apt-cache search and apt-get isntall to find what you need
<asac> once you have the packages you can use stage-packages: field in snapcraft.yaml to ensure those get put into your snap
<asac> alongside with your app etc.
<NoiZeR> but i want that as framework because the C++ boost library needs to be available everywhere
<NoiZeR> asac
<NoiZeR> ps im a total noob on Snappy just started
<asac> NoiZeR: if you dont need have one runtime instance (e.g. a mediating service/agent) then dont feel bad about folks including copies in their snaps for now
<asac> make it easy to include it through having a snapcraft part etc.
<kyrofa> elopio, travis has been failing left and right yesterday and today
<kyrofa> elopio, hahaha, what is the standard on the copyrights? sergio told him to just make it 2016, I would have made it 2015-2016, and you said 2015, 2016
<elopio> kyrofa: you have to put every year the file was touched. And according to the fsf, if you use the - you have to documment that usage.
<elopio> so I prefer to use the ,
<elopio> but of course, nobody pays attention to fsf and this is just a nit.
<kyrofa> elopio, ah, excellent. I'll remember it!
<asac> two years use a , ... more years use a -
<asac> my 2c
<elopio> asac: https://www.gnu.org/licenses/gpl-howto.html
<kyrofa> elopio, for your admiration: http://pasteboard.co/15kdW9WN.jpg
<elopio> sixth paragraph
<elopio> kyrofa: wow.
<kyrofa> elopio, I don't need to work out for a week after that job
<elopio> here we have cozy 23 degrees C, with no clouds in the sky.
<elopio> kyrofa: did you do it all the way to the car?
<kyrofa> elopio, yeah
<elopio> I'm impressed.
<tedg> kyrofa: http://www.bbc.com/news/blogs-magazine-monitor-30119410
<tedg> kyrofa: I'm not saying living someplace with snow can kill you, the BBC is :-)
<kyrofa> tedg, haha
<mvo> JamesTait: hi, do you still need a meta/snap.yaml example snap?
<JamesTait> mvo, I believe I have one (shout.seriusens), thank you.
 * JamesTait can't type for toffee today.
<JamesTait> And I've now got the documentation for the internal snappy format, so I *think* that's everything I need to get started.  But I'll shout up if I find I'm missing anything.
<mvo> JamesTait: cool, http://people.canonical.com/~mvo/tmp/hello-world_3.0_all.snap is also one
 * JamesTait hugs mvo.
<JamesTait> Thank you very much - having a couple of package to test with will be a great help.
<mvo> JamesTait: I think for you and the metadata you need its almost identical to package.yaml, name, version are the same, vendor is no more, description comes from yaml instead of readme.md
<mvo> JamesTait: your welcome, shout if you need anything :)
<kyrofa> Well hey there sergiusens. I figured you'd be sleeping most of today
<asac> sergiusens: kyrofa: https://github.com/ubuntu-core/snapcraft/pull/257 is green now :)
<sergiusens> asac, bloody timing, I added some review comments :-P
<lool> asac: sorry took me a while to confirm, but it works
<fgimenez> elopio, disk space seems to be ok in the last server deployed http://paste.ubuntu.com/14672859/
<lool> asac: I cpio -i extracted snappy initrd, then split it into two dirs (moved lib/modules to a different one) then repacked
<lool> asac: one key thing to pay attention to is that xz compression doesn't work but lzma does
<sergiusens> kyrofa, I am super tired, but I also flew business (with a proper bed) so its not that bad
<lool> it's very similar but not identical
<lool> so just use "lzma" to compress
<elopio> fgimenez: great.
<lool> asac: I added break=top to cmdline to confirm that the initrd was fully populated, and then I completed a successful boot too
<kyrofa> sergiusens, well take it easy today :)
<lool> asac: next step is making sure our OS snap includes a generic initrd
<asac> lool: you know the magic cli arguments for xz initrd packgin?
<asac> just in case
<asac> lool: so you could load two files from bootloader?
<asac> and it was just one disk merged?
<lool> asac: find . | cpio -c -H newc
<lool> then lzma the result
<lool> (you can pipe it directly too)
<lool> probably better compression not to though
<lool> asac: I used the initrd part1.img part2.img syntax you mentioned
<lool> worked fine
<lool> didn't try with u-boot, probably need to compute offsets myself there
<lool> which wont be fun
<lool> there also seems to be some alignment constraints
<lool> apparently you can mix various types of compressions (or no compression) on the grub initrd line; not sure if this is a grub or linux thing though
<asac> hmm. guess grub might do the uncompressing then?
<asac> i would say its not good to mix :)
<lool> it might be linux
<asac> figuring that compression changes mid file? i doubt it :)
<asac> but you newver know
<lool> in fact, it's more likely linux as grub didn't bark at teh xz compression but linux failed to boot
<lool> as in it panicked
<fgimenez> elopio, i see that the build jobs are restricted by label in the config https://github.com/ubuntu-core/snappy-jenkins/blob/master/containers/jenkins-master/config/jobs/create-cloud-image-all-snaps/config.xml#L32
<asac> yeah
<asac> lool: so i could only use xz with funnny cli arguments
<asac> let me find them
<fgimenez> elopio, but not in the deployed server http://10.55.32.123:8080/job/create-cloud-image-vivid/configure
<lool> asac: it's not midfile, linux gets the cpio header from the first piece
<lool> it knows how long the initrd will be
<asac> lool: xz --check=crc32 --lzma2=dict=512KiB inputfile
<asac> thats how it works
<lool> yeah
<lool> lzma is simpler to type  :-)
<asac> otherwise it always panicked for me not being able to uncompress initrd
<asac> is it the same? no idea
<asac>  :)
<lool> lzma is what I used
<lool> it's lzmo compression anyway
<asac> rihht, but above also works
<asac> yeah
<asac> kind of
<asac> something is different afaik :)
<lool> perhaps I should test this on rpi2
<asac> not compression, but maybe contgainer
<asac> yeah do it
<asac> just two uinitrds and then load it with manual address offset for now
<lool> albeit if we're not doing squashfs loading there, there's no point in smarts to laod multiple initrds
<lool> we dont use uinitrd AFAIK
<asac> well, its good
<lool> just plain initrds
<asac> at least no need to add merge logic
<elopio> fgimenez: that makes no sense.
<asac> and if they are on disk
<asac> there migth be stuff with secure boot
<asac> as we can validate the signatures as they were shipped
<asac> lool: dunno... uboot needs to load initrd... thought it needs the mkimage  header
<asac> ifg not, then even easier i guess
<asac> maybe you can even do fatload file1 file2?
<asac> :)
<fgimenez> elopio, maybe we are creating the job before any slave with that label is available? that shouldn't be a problem imo...
<elopio> fgimenez: when that happens, the job config just prints a warning.
<lool> asac: as I said, it does not
<asac> lool: anyway, i was hoping for your magic to make the uboot script do rthe right thing :)
<elopio> but you can still create it. so weird...
<lool> we dont use the mkimage headers
<asac> e.g. address calc
<asac> good
<asac> but uImage?
<lool> fatload multiple args is quite certainly incorrect as the initrds need alignment
<lool> we dont use uimage
<asac> really? wow :)
<elopio> fgimenez: maybe canRoam needs to be false.
<lool> uimage is only required for flash baked u-boot payloads; if built with the right configs, u-boot will happilly start a regular initrd
<asac> guess that puts u-boot rquirement really high
<asac> like 2014 crack
<lool> just one config
<fgimenez> elopio, the rest of things seem to be in place, once the images and packages are built we are ready to go
<lool> it's mainly something that we need to make sure the boards enable
<elopio> I tried manually adding the label, and that value changes
<asac> right, which is the problem with putting sophisticated requirements on bootloaders :)
<asac> anyway, lets give it a go
<elopio> fgimenez: I'll made the change manually, and propose a branch for the next deploy.
<asac> if you can figure the offset calc in uboot.scr
<asac> you are my hero :)
<asac> and we can go directly to making the plat-indep[ initrd in OS snap
<lool> I wonder whether we'd be better off with using grub-efi on top of u-boot at this point
<lool> asac: I'll try to repro on snapdragon or on rpi2 tonight, just to make sure there's no arch specific support issue there, then we can see which bootloader path we take
<fgimenez> elopio, ok, leaving, have a great day
<asac> lool: i dont know... feels thats even more sophisticated
<asac> snapdragon has new uboot
<asac> try something with old too
<lool> asac: the thing with grub-efi is that it's a single thing to worry about enabling in u-boot, and hten we can use the same logic everywhere
<pindonga> elopio, kudos on the xenial mp! :)
<elopio> :D
<pindonga> elopio, can I ask you to lobby for my MP with sergiusens ? ;-)
<kyrofa> elopio, I'm trying to duplicate the lack of locale settings that causes snapcraft --help to barf a stacktrace on an lxc where it works fine
<kyrofa> elopio, help?
<kyrofa> sergiusens, you could probabyl answer that as well ^^
<elopio> kyrofa: take a look at the new .travis.yml
<elopio> create a lxc following the same steps, and it won't have the locales set.
<elopio> we need utf-8 to run some unicode tests, so I changed runtests.sh to set the language.
<elopio> remove that, run the tests, and you'll get an error.
<kyrofa> elopio, alright, thanks :)
<elopio> kyrofa: however, my theory is that the error came from the unicode copyright symbol on some files. That's fixed already.
<elopio> if my theory is correct, the unicode chars from the tests won't get imported, and you'll be able to run snapcraft in ascii.
<kyrofa> elopio, or the quotation marks (dholbach noticed those)
<elopio> hum, I didn't see them. Great we have more eyes :)
<kyrofa> elopio, I know you've reviewed https://github.com/ubuntu-core/snapcraft/pull/209 . Do you have a sec for a question on it?
<elopio> kyrofa: I just took a quick look and didn't fully understand the tests. What's your question
<elopio> ?
<kyrofa> elopio, yeah you had a good catch there
<kyrofa> elopio, so right now, the copy plugin follows symlinks and copies in the original file, so no symlinks end up in the .snap
<kyrofa> elopio, his change adds the ability to do the opposite, which is copy the symlinks themselves as leave them as links, even if they point outside the .snap. I think you and I agree that's not a good idea
<elopio> kyrofa: that would be when this PR lands, right?
<elopio> ah right, the default is true.
<elopio> kyrofa: yes, I would like us to help people building correct snaps.
<kyrofa> elopio, right. Thing is: if that PR gets fixed to prevent incorrect snaps, is there any downside to using symlinks all the time? i.e. why make it an option?
<elopio> kyrofa: hum, that question means we need a good integration test for this branch.
<elopio> I thought that you would have a link to a file, and you want both to end up in your snap.
<elopio> but I suppose there are times when you want to keep only the real file, and get rid of the link.
<kyrofa> elopio, ah, I was just thinking if the symlink pointed outside of the .snap, just copy the original
<kyrofa> elopio, since sometimes the link will be absolute
<elopio> kyrofa: that makes sense. If the real path is outside, copy the real, not the link.
<kyrofa> elopio, exactly. It'll take a custom copy function and some decent tests, but then we have the best of all worlds
<elopio> kyrofa: so that would be the default, and then you can override the behaviour with follow-symlinks: true | false ?
<kyrofa> elopio, we can support that... but can you think of any reason why a developer wouldn't want symlinks in the .snap?
<kyrofa> elopio, I can't, which begs the question: why add the option and incur the maintenance cost?
<elopio> kyrofa: I assumed this would be coming from an external repo that has symlinks for some reason.
<elopio> we should ask femdom for his usecase.
<kyrofa> Well, his use-case involves _wanting_ the symlinks. I'm asking: is there ever a reason to NOT want symlinks?
<elopio> kyrofa: right, I'm reading it on the bug now.
<elopio> kyrofa: I agree that your proposed solution is better than his.
<kyrofa> elopio, I'm under the impression that we didn't have symlinks in the first place to avoid the potential dangling link and just copying the original was the quickest path to that goal. I think if we eliminate that possibility symlinks will work for everyone
<elopio> kyrofa: what I don't like about this is that the snap repo won't have all the files it needs. It depends on the developer machine.
<elopio> but our goal is not to have reproducible builds. So I guess that's alright.
<kyrofa> elopio, well, only potentially, and it's that way now if the repo has symlinks pointing outside of the repo
<kyrofa> elopio, this proposal keeps everything the way it is now unless the symlink is pointing within the .snap already
<elopio> yes, it'll be better than it is now.
<kyrofa> Alright, thanks for your brain! I'll mull that over a little
<kyrofa> elopio, also, when you have a minute: https://github.com/ubuntu-core/snapcraft/pull/264
<kyrofa> elopio, integration test failures suck
<kyrofa> elopio, is there a way to get output from the build?
<kyrofa> elopio, from run_snapcraft, specifically
#snappy 2016-01-27
<elopio> kyrofa: there is now https://github.com/ubuntu-core/snapcraft/pull/266/files
<nhaines> So here's probably an annoying question.  What's the latest snappy image for a Raspberry Pi 2?
<nhaines> I'm going to sort of assume it's https://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz.
<fgimenez> good morning
<mvo> nhaines: thats the very latest 16.04 image, its a bit rocky at this point because we are adding lots of new features
<fgimenez> elopio, hey, still awake!? :) take a look at http://10.55.32.97:8080/log/all
<mvo> nhaines: if you prefer something stable to work with, the 15.04 rpi2 image is also available
<nhaines> mvo: I just got an RPi2 with a PyGlow module, and was hoping to play around with it.  :)
<mvo> nhaines: http://releases.ubuntu.com/vivid/ubuntu-15.04-snappy-armhf-raspi2.img.xz
<fgimenez> elopio, "Checking comment on PR #379 for job github-snappy-integration-tests-cloud"
<nhaines> mvo: is there no 15.10-based image?
<elopio> fgimenez: yes. Everything seems correct, except that m-o can't connect :(
<fgimenez> elopio, http://stackoverflow.com/questions/8378235/javax-net-ssl-sslexception-java-security-invalidalgorithmparameterexception-th maybe we are missing an ssl store
<nhaines> mvo: I'll skip the "why" and ask where I can sort of figure out where to look for up-to-date information.
<elopio> fgimenez: I installed the ca-certificates-java.
<elopio> still no luck.
<fgimenez> elopio, ok i'll take over from here, thx! and get some rest
<mvo> nhaines: here is a bit of background info on the 16.04 image state https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html
<mvo> nhaines: we only have 15.04 and 16.04 currently
<elopio> fgimenez: ok, I give up now anyway. The old jenkins doesn't have the java certs installed anyway and it works.
<fgimenez> elopio, maybe something is missing in trusty, i'll investigate. the current images have been built with the new keys, right?
<elopio> fgimenez: the rolling edge all snaps, yes.
<elopio> fgimenez: to generate the 15.04 we need snappy-cloud-image not to pass os, kernel and gadget parameters to udf
<fgimenez> elopio, ok, i'll rebuild that one and create a new floating ip and a testing project in github
<elopio> I guess we can make that the default is not to pass the parameters.
<fgimenez> elopio, that's already done iirc, let me check
<fgimenez> elopio, https://github.com/ubuntu-core/snappy-cloud-image/blob/master/pkg/image/image.go#L94
<elopio> fgimenez: for some reason that didn't work: http://162.213.35.179:8080/job/create-cloud-image-vivid/1/console
<fgimenez> elopio, ok i'll check that too
<nhaines> mvo: gotcha.  Will I be able to upgrade from 15.04 to 16.04, or will that require a reflash?
<mvo> nhaines: it will require a reflash. if you want to avoid that the 16.04 image is probably better but it under heavy development :)
<nhaines> mvo: finished flashing the 16.04 image, ran 'snappy enable-classic', then 'snappy shell classic', ran 'sudo apt install nethack-console'.  Worked but game not available.  Sad.  :)
<nhaines> Anyway, reflashing isn't currently a problem, so I'll manage either way.  Thanks for the help.  :)
<JamesTait> Good morning all!  Happy Wednesday, and happy Chocolate Cake Day! ð ð
<mvo> JamesTait: hey, good morning!
<mvo> JamesTait: how is the snap.yaml stuff going? I would love to upload the first snaps ;)
<JamesTait> Things are moving now I've managed to nail down the requirements.  I expect to have something to land and test on staging today.
<Mikaela> Now you made me want chocolate cake  :(
<ogra_> hmm, ubuntu_geek is gone
<asac> kyrofa: sergiusens: wdyt of http://paste.ubuntu.com/14678463/ (and then make plugins that support, honor those global flags)
<Sweet5hark> utlemming: so I tested the vagrant stuff on two machines and the "stable" image loops on both, so is pretty unusable ...
<Sweet5hark> utlemming: also both machines are very different (one intel i7 one amd opteron 6272 etc.) ...
<ogra_> asac, i dont like "+j_count = 0"
<asac> why?
<Sweet5hark> utlemming: the "edge" image seems to work though, so using that for now ...
<asac> <=0 -> use auto counrt
<asac> count :)
<ogra_> asac, it should check /proc/cpuinfo and default to the number of cores instead
<asac> ogra_: did you read the code?
<ogra_> meh
<asac> :)
<ogra_> didnt read to the end
<asac> search for it... its doing that
<asac> hehe
<ogra_> yeah
<ogra_> my head feels like wrapped in a 2m thick layer of cotton wool
<asac> without that its pretty sleep inducing to build a kernel :)
<ogra_> (hard to get through doors this way :P )
<ogra_> yeah, sorry
<asac> hehe
<asac> you went to the doc?
<asac> :)
<asac> or just bad day/headaches?
<didrocks> ogra_: give it one meter more and you will know my current state :)
<ogra_> just got up after a 12h flight :)
<dholbach> did you guys pick up the ubuflu?
<ogra_> at least i only cracked my back and didnt catch a cold or ubuflu as usual
<dholbach> I did /o\
<didrocks> dholbach: yeah, a little bit
<asac> pfft... 12h is easy :P
<didrocks> seb128 as well
<asac> ogra is getting old :)
<asac> lol
<asac> well, get some rest then
<ogra_> asac, well, over all it was a 17h tour
<ogra_> but yeah, getting old
<asac> better if you are available strong for less time its better than weak for long time :)
<ogra_> and i cant take much rest, so much to do
<ogra_> ... generic initrd ... all-snaps in livec-rootfs ... dragonboard images ... aall in the next 10 days
<ogra_> mvo, so for the initrd, when do you want to merge the two pieces ... during snap creation or earlier ?
<ogra_> (i assume we want to sign the file inside the snap )
<ogra_> s/ sign the file inside/ a signed file inside/
 * dholbach hugs didrocks, ogra_ and seb128
<dholbach> hope you're all better soon again
 * ogra_ hugs dholbach didrocks and seb128 
 * didrocks hugs dholbach, ogra_ and seb128 as well, (sharing germs!)
<didrocks> same for you :)
 * ogra_ puts up a virus scanner to catch the worse bits 
<dholbach> this is the infirmary :)
<asac> big ubuflu it seems :)
<sergiusens> asac, set verbose seems very specific to the system (it is different on others)
<sergiusens> asac, if you create a bug, I'm happy to look into it
<asac> sergiusens: not sure what you mean
<asac> lots of build systems have verbose flags to see the real command line
<asac> like V=1 etc.
<asac> sergiusens: look at this for an example with scons.py
<asac> sergiusens: https://github.com/asac/snapcraft/tree/multithread-and-verbose-infra
<sergiusens> dholbach, didrocks seb128 get better! And maybe ogra_ too
 * Sweet5hark stacks up on phone desinfectors ...
<sergiusens> didrocks, I have thought of a probably better way to do pkg-config without changing pkg-config, but by wrapping the call. I'll experiment and propose
<dholbach> thanks sergiusens
<didrocks> thanks sergiusens!
<ogra_> thanks sergiusens :)
<didrocks> sergiusens: ah, not uninteresting, yeah, wrapping would be less instrusive
<sergiusens> asac, I'm a bit skeptical about this, but we can explore
<sergiusens> didrocks, wow, get some rest, thoes double negatives are hard to follow ;-)
<didrocks> sergiusens: ahah, yeah, tireness is twisting my mind! :-)
<asac> sergiusens: what makes you think?
<asac> sergiusens: a) it surely needs  to be a global CLI option, no?
<ogra_> asac, are we philosophical today ?
<asac> b) bc, you want to be able to toggle this on and off from CLI and not hack on yaml to change behaviour
<sergiusens> asac, lets start with `snapcraft snap`, does it work with how you did it?
<asac> sergiusens: oi if you want to talk about how to implement the global option, then yeah lets talk
<sergiusens> asac, verbose makes sense to be global, the -j could be a yaml thing though (just because of what I mention before); if not you need to expose these globally
<pindonga> sergiusens, hi there... I was told you had some thoughts on the vendoring approach taken here? https://github.com/ubuntu-core/snapcraft/pull/197
<asac> sergiusens: so thats interesting question. think right now you can only change this if you run build explicitely
<asac> which could be fine if you think about it, but i would prefer if the option woudl be everywhere
<asac> sergiusens: no -j is not yaml
<asac> its cli
<asac> you want to toggle on/off for debugging etc.
<asac> at best all are global
<asac> felt bad to put it for top level options, but we could do that
<asac> thought maybe you know a trick how a command would still parse the options
<sergiusens> pindonga, I'm really not comfortable with vendoring; especially for things that the team is not upstream for
<asac> sergiusens: anyway, thanks for checking. what i want are those common.XXX functions that have the behaviour as its now for build, just better so it works for snap etc.
<asac> and default target
<pindonga> sergiusens, so what do you suggest we do? here's the problems I see
<asac> i can go and make plugisn that support these do it
<pindonga> 1. ssoclient is only provided as a package on xenial, thus depending on this will mean snapcraft will only work in xenial once this change lands
<sergiusens> pindonga, can't this land in xenial?
<sergiusens> pindonga, that is fine
<sergiusens> pindonga, xenial is the only target for snapcraft 2.0
<sergiusens> 2.x
<pindonga> 2. the upload also requires the storeapi code, which if not vendored will also require us to package/land click-toolbelt on xenial (same caveat)
<pindonga> also, packaging and getting this into ubuntu seems to be taking quite some time
<pindonga> and I fear we'll miss feature freeze
<sergiusens> pindonga, landing in ubuntu is part of the workflow though
<sergiusens> pindonga, maybe ask dholbach for help with packaging, I'm sure he is more than glad to help
<pindonga> sergiusens, ok
<pindonga> beuno, fyi... looks like we'll have to go the packaging route in the end
<dholbach> pindonga: what do you need to get into the distro?
<pindonga> dholbach, click-toolbelt
 * pindonga checks what the latest status of that was
<dholbach> r57?
<ogra_> sergiusens, oh, no LTS backports planned for snapcraft ?
<dholbach> there's no new changelog entry in debian/changelog in lp:click-toolbelt?
<pindonga> dholbach, yes, version 0.5.1
<dholbach> is this normally uploaded through auto-landing?
<pindonga> dholbach, this is a new package, hasn't reached the archive yet afaict
<dholbach> pindonga: so r57 == 0.5.1?
<pindonga> so no idea what to answer there
<pindonga> yes
<dholbach> ok ; isee
<dholbach> let me review it
<sergiusens> ogra_, yes, 16.04 LTS
<beuno> pindonga, sergiusens, I don't understand why it needs to be pacakged?
<sergiusens> ogra_, if it were written in go I'd be more confortable
<beuno> also, I wouldn't use the name click-toolbelt if we do
<beuno> it
<sergiusens> beuno, we have no guarantees of maintainership; and it is bad practice to vendor in the archive
<pindonga> beuno, in that case we'll have to split the storeapi code into a diff project and package that
<beuno> sergiusens, it
<pindonga> even more work
<NoiZeR> Hi, is it possible to use *.so files that are compiled on ubuntu lts 14.04 on a raspberry pi to make a snap and use them as a framework?
<sergiusens> beuno, if it is a fork; then it is missing tests which was said was not necessary
<sergiusens> beuno, this is just proper ubuntu work, nothing really out of the ordinary
<beuno> I don't understand, upload is a core part of snapcraft
<beuno> why would we want to have it separate?
<sergiusens> beuno, yeah, the libraries used though, that's different
<ogra_> sergiusens, hmm, that creates a gap ... most people will only upgrade once 16.04.1 comes out
<sergiusens> beuno, well, the conversation started with the fact that there are no tests as it is tested upstream, but if it indeed is a fork, then it is not vendored, but a fork
<sergiusens> and should have all the required tests
<pindonga> beuno, sergiusens what's vendored is the store api code (just so we don't have to duplicate the code in both places)
<pindonga> I could as easily do the latter removing one thing to vendor
<beuno> sergiusens, the old code is being deprecated
<pindonga> the other (ssoclient) would still be needed via dep (which is already in xenial)
<beuno> we're keeping it around so the phone can still upload clicks for a little while
<beuno> we're merging in that code into snapcraft, and killing off the other tool as soon as it's sensible
<sergiusens> beuno, as long as you maintain this part of the code
<kyrofa> Good morning
<beuno> sergiusens, by you, you mean all of us?
<beuno> I mean, this was suppose to be part of snapcraft
<NoiZeR> kyrofa hi i have an other question about snappy can you help me out a bit?
<beuno> and pindonga is pitching in so more things can be done on other bits
<kyrofa> NoiZeR, sure :)
<beuno> if there are concerns about code quality, we can surely split it up and land it in chunks
<sergiusens> beuno, if we are going to be upstream... https://github.com/ubuntu-core/snapcraft/pull/197/files#diff-175727a8f2ba0ea9e34a671983b5ad2dR36
<sergiusens> beuno, that is indeed wrong, why does it say `vendor`?
<NoiZeR> kyrofa so i uses a Raspberry Pi and i have some libs compiled on a Raspberry Pi with ubuntu 14.04 LTS but is it possible to make a snap of it en use it as a framework?
<beuno> sergiusens, because it hasn't been clear how to pull these things together
<NoiZeR> kyrofa it is an *.so file
<NoiZeR> kyrofa thx in advance xD
<beuno> sergiusens, dude, you're leading snapcraft. There was the store upload feature on the roadmap, and I volunteered to get someone to work on that code since we have some domain experts
<kyrofa> NoiZeR, potentially. Libraries still often need other libraries, which would also need to be included in the .snap
<beuno> I don't get why you'd want to try keep that split as a separate thing
<kyrofa> NoiZeR, why are you wanting to make a framework instead of a normal .snap, by the way?
<beuno> sergiusens, if you'd rather develop the feature yourself, pindonga has plenty of other things to work on
<sergiusens> beuno, I just said, remove `vendor` add tests and it is fine
<beuno> cool
<pindonga> ok
<sergiusens> beuno, I am worried that when snap-ids come all this code will be useless, that's why I am worried
<NoiZeR> kyrofa im making a system where users can make some application for my application. But they need the Library that is installed on the Raspberry Pi
<NoiZeR> kyrofa so the developers can make third party modules for the device
<beuno> sergiusens, I understand, we'll need to change quite a few tools around it
<beuno> sergiusens, nessita is currently planning that change
<beuno> sergiusens, I don't think the core of this will change (uploading)
<kyrofa> NoiZeR, alright. Note that frameworks are more for sharing some sort of service, not sharing libraries. Not to mention frameworks won't exist in 16.04 (they're being replaced with something else)
<asac> sergiusens: beuno: i feel that some coupling of store and snapcraft is unavoidable with the consequence that there will be changes that need invest on both sides... to ensure things move smoothly, couldnt you couple store and snapcraft through integration tests that run on landings on both sides. in this way if store wants to land changes that break snapcraft they will have to facilitate that the snapcraft change also happens?
<beuno> but there are plenty of things to add: assertions, name reservations, etc
<asac> and vv
<ogra_> NoiZeR, as i understand there are no framework snaps anymore ... but you can create library snaps that your app can consume (but nobody elses but your snaps will be able to use them, they are bound to teh developer)
<sergiusens> we have autopackage tests enabled; but the store does not land on ubuntu so it is up to the store to implement those testing hooks
<sergiusens> asac, ^
<kyrofa> NoiZeR, your users might be better served by your making some sort of snapcraft plugin to integrate your libs into their .snaps
<beuno> asac, I don't think we'd be breaking each other in this case, the server might change, and if it does the client has to regardless of where it lives
<kyrofa> NoiZeR, or just make a build system that makes it easy
<asac> sergiusens: if snapcraft already tests store interactions through autopackage tests on landings thats fine
<ogra_> yeah, what kyrofa said
<NoiZeR> kyrofa, a build system what do you mean with that?
<NoiZeR> kyrofa can you use snaps into snaps?
<asac> beuno: sure, just saying that snapcraft maintainer would feel less reluctant to land more code that couples store to snapcraft if i knew there are tests for the integration running in store landing process too...
<kyrofa> NoiZeR, is your library built by a build system? e.g. cmake, autotools, etc.?
<NoiZeR> cmake
<asac> (just my way to  say, i wouldnt hold back with more coupling just because something will change; we ahve to do it anyway so ratehr think how to make it efficient and not how can we wait longer)
<NoiZeR> kyrofa cmake and an other lib by qibuild but
<kyrofa> NoiZeR, cmake is good-- snapcraft supports cmake with a plugin
<NoiZeR> kyrofa but cmake needed qibuild so i need to install the python library aswel i think
<NoiZeR> kyrofa but how thats works i don't know. Just i know its needed to be installed with pip install qibuild
<beuno> asac, sure thing
<dholbach> pindonga: AFAICS the package is good to go, minor nits would be: the package description could be a bit longer, copyright in d/copyright could be extended to be 2013-2016, and there's no manpage for click-toolbelt - I didn't quite follow the discussion you had above about having a separate package or something.... do you know if everyone's happy with the name click-toolbelt and the placing of all bits in the code?
<dholbach> from a mere packaging POV I'm happy to upload if everything else is settled
<pindonga> dholbach, thanks but it looks like we won't need it after all
<pindonga> we're moving that code into snapcraft itself
<dholbach> ok...
<dholbach> let me know if I can be of any help
<kyrofa> NoiZeR, okay I'm not familiar with that... hold on
<kyrofa> NoiZeR, let me do some research into qibuild real quick :)
<NoiZeR> kyrofa np
<NoiZeR> kyrofa its with the NAO robot related
<kyrofa> NoiZeR, but my point is this-- your job would be easier if you focused on building your snap with snapcraft rather than bundling the .snap yourself
<kyrofa> NoiZeR, since .snaps must include their dependencies
<NoiZeR> kyrofa ok wait a sec :p So the i need to just add the library to my snaps and then it will work correctly? And can the other snapps uses this library?
<kyrofa> NoiZeR, each .snap will need to include your lib and its dependencies
<kyrofa> NoiZeR, this allows your lib to update without potentially breaking the user's snaps before they're ready for it, etc.
<NoiZeR> kyrofa but every snapp does need to get this library into there snap?
<NoiZeR> kyrofa or is it possible to share a coulple of library
<ogra_> NoiZeR, what exactly will your users do ?
<ogra_> do you expect them to build a snap themselves to make use of your project ?
<ogra_> (with an emphasis on *build* )
<NoiZeR> ogra_ yes So they need to make some snaps and the other snap need to call them
<ogra_> cut that sentencs at "and" :)
<ogra_> *sentence
<NoiZeR> _ogra so you can it sea like android is my snap and they will install some snapps and that are the apps
<ogra_> NoiZeR, they need to build something ... why not focus on that then insteasd of binary usage
<ogra_> provide them the easiest way to do that build step and you win
<NoiZeR> ogra_ what do you mean exactly with that?
<ogra_> make that build step bundle what they need ...
<ogra_> into their snap
<asac> dholbach: https://developer.ubuntu.com/en/snappy/ snappy log is broken here
<dholbach> what is broken?
<NoiZeR> ogra_ so that they always include the needed libraries?
<ogra_> NoiZeR, exactly
<NoiZeR> ogra_ ok but thats one solution but is there a way in the future to share libraries just like in a normal linux?
<ogra_> "a normal linux" ?
<NoiZeR> just lik i install the C++ library on my Ubuntu 14.04 and i can include the files (the library is en *.so file)
<NoiZeR> and some python stuff
<ogra_> you can make shared library snaps today ... but only shared for *your* snaps ....  i.e. they are bound to your account so you cant break our security model ... random dependencies like in other package managers wont be possible
<dholbach> asac: what is broken on thage page?
<kyrofa> ogra_, and you can't really do that today-- you'll be able to in 16.04
<dholbach> *that page?
<kyrofa> NoiZeR, so for 15.04, the real answer to your question is no. Snappy is a bit different from other packaging systems-- you can't share dependencies like that
<ogra_> kyrofa, heh, right, my brain is still in a different TZ from my body :)
<kyrofa> ogra_, ha! You home now?
<ogra_> yep
<kyrofa> ogra_, might take you a week man, sorry :P
<ogra_> but brain is still over the atlantic somewhere ... following up at snail speed
<ogra_> yeah
<NoiZeR> ogra_ so when i install all the apps as the same user it will work correctly
<NoiZeR> ?
<NoiZeR> with shared libaries?
<ogra_> right, so that you can use the sname libs from a single snap ...
<ogra_> but others wont be able to consume them
<asac> dholbach: the snappy logo doesnt load here
<asac> right on top right
<asac> its broken image
<asac> dholbach: do you see it?
<dholbach> you're right -I can see the problem too
<NoiZeR> ogra_ the account is that on the snap store that you mean or just a user on the device?
<ogra_> NoiZeR, snap store
<asac> dholbach: good :)
<dholbach> asac: it wasn't clear to me that "snappy log" was supposed to be "snappy logo" :)
<asac> yeah, typos ftw
<ogra_> NoiZeR, if any random person would be able to put libs there that any other random person can use, you would completely break the security model of app isolation ...
<dholbach> asac: https://assets.ubuntu.com/sites/ubuntu/latest/u/img/cloud/tools/snappy/snappy.png was dropped it seems
<dholbach> davidcalle: ^ better not to rely on assets
<ogra_> NoiZeR, and are security wise back to deb/rpm
<sergiusens> kyrofa, morning btw
<kyrofa> sergiusens, hey there :)
<asac> dholbach: hmm. will you check it out?
<dholbach> yes
<ogra_> NoiZeR, meaning to give *every* person in the app store root on your device ...
<asac> ok let me know. wanted to download it for a rpesentation
<asac> :")
<dholbach> asac: fixed
<asac> neat
<ogra_> NoiZeR, i.e. in the deb/rpm world *every* package maintainer has full root access to your system ... in snappy every store account has root inside their area of the system, but not in the system itself or in other accounts ... if lib snaps would allow cross account usage that woulod mean the provider of the lib has full root access to all snaps that consume it
<NoiZeR> ok I understand that
<asac> dholbach: there also exists an orange snappy logo somewhere
<asac> that has the word snappy printed
<asac> can you browse assets etc. to see if they are there?
<ogra_> NoiZeR, so in the case where your users have to build something from source anyway, just focus on making that step the best experience by providing a snapcraft plugin that automatically takes care for everything
<NoiZeR> ogra_ kyrofa thx for the help when i have some questions will ask them here
<ogra_> so the users can concentrate on their code
<ogra_> great, that is why we are here :)
<kyrofa> NoiZeR, sounds good :)
<kyrofa> ogra_, when will the dragonboard be here: https://developer.ubuntu.com/en/snappy/start/ ?
<ogra_> kyrofa, within the next 10 days i hope
<kyrofa> ogra_, awesome! I just received mine yesterday. Do you happen to have a writeup I can follow?
<ogra_> we need auto-builds first ...
<ogra_> kyrofa, http://people.canonical.com/~ogra/snappy/dragonboard/README
<ogra_> if you are on xenial the latest in-archive u-d-f shoudl work btw ... else you need to download the one from that dir
<kyrofa> ogra_, excellent, thank you!
<lool> ogra_: hey, did you have to patch snapdragon u-boot for things to work with snappy?
<ogra_> lool, http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files
<ogra_> only the config
<ogra_> there is also a README about all i had to do
<lool> ogra_: ok, CONFIG_SUPPORT_RAW_INITRD is what I suspected
<lool> ogra_: ah I didn't see the u-boot part in your original dragonboard README hence the Q
<ogra_> yeah, and support for our uboot.env
<Sweet5hark> so where is the snappy command docs? I see there is a "snappy man" command than dumps a raw manpage ... but "man" doesnt seem to be available or installable on snappy?
<ogra_> lool, yep, that work pre-dates snappy work
<ogra_> lool, afaik even linaro now uses my boot setup ;)
<ogra_> for normal linux
<lool> ogra_: cool
<lool> urgh CONFIG_SYS_REDUNDAND_ENVIRONMENT
<ogra_> yeah
<lool> redundan*d*
<ogra_> hehe
<lool> I wonder if it's a germanism
<ogra_> no idea who originally created the option
<sergiusens> asac, can you check my comment https://github.com/ubuntu-core/snapcraft/pull/257/files ?
<ogra_> BBB uses it which is why all other boards inherited it for having a working fw_setenv/printenv (and uboot-go) we use in snappy
<lool> ogra_: uboot-go?
<ogra_> (the option just adds a 4byte header to uboot.env ... not even sure why thats "redundant" in any way)
<sergiusens> ogra_, mvo asac lool so initrd and multiple kernel snaps; mvo is thinking we should create a full initrd on kernel snap build time; that seems hard to do for snaps that we don't control though (and becomes hard to maintain)
<lool> it's also a problem for lvm, crypto and stuff
<ogra_> sergiusens, well, i suppose we might want to sign the initrc file inside the snap
<ogra_> *initrd
<lool> besides, isn't there core snappy logic setting up writable bind mounts from initrd?
<ogra_> so you cant really assemble at snap install time
<sergiusens> ogra_, so if we ever update the OS, we will need to rebuild all the kernel snaps (or someone)
<mvo> sergiusens: I'm not sure I'm thinking this, this is what I'm doing currently, we discussed cat'ing multiple initirds
<ogra_> lool, we are at the step before running the initrd :)
<ogra_> sergiusens, ?
<ogra_> sergiusens, do you plan to ship any parts of that in the os snap ?
 * ogra_ wouldnt
<sergiusens> mvo, oh, sorry, this is based on a quick SCaLE conversation with ogra_
<mvo> ogra_: btw, did you had a chance to test http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz ?
<sergiusens> ogra_, so when talking to mvo half of the initrd would be in the OS snap; the other half in the kernel
<ogra_> my vision would be that we have a generic and a modules part ... and that we merge them at kernel snap creation time into one file we can sign
<mvo> sergiusens: no worries
<ogra_> mvo, not yet ... will do so beofre EOD
<mvo> ogra_: on a grub system we don't extract anything, we load directly from the squashfs
<mvo> ogra_: thanks!
<mvo> ogra_: so extracting and combining would be a step backward :(
<ogra_> sergiusens, mvo, yeah, i dont think that will fly nicely ... both parts should live in the kernel snap
<ogra_> the other option would be to merge them from the bootloader on the fly .... but that will likely result in very slow boots and probably also require quite some bootloader hackery
<mvo> maybe I'm missing something, but why would both parts live in the kernel snap? it seems if one is in the OS snap, that is ok? as long as it has no modules or other kernel dependant stuff ?
<ogra_> mvo, how would you boot that ?
<mvo> it seems like grub supports loading multiple initirds?
<ogra_> does uboot too ?
<ogra_> i never tried that
<mvo> ogra_: grub has a concept of multiple initirds, so grub would load both, never tried it either, I'm not saying it works, just that that looks like a really good option :)
<mvo> ogra_: uboot is a bit of a problem :(
<ogra_> that might result in horrid math stuff when you create a gadget to get all the load addresses right
<mvo> ogra_: but on the upside, on uboot we need to extract the files, so we can do merging with uboot
<lool> mvo: so cat-ing multiple initrds would work technically; is this the solution we want to implement for 16.04? we could
<mvo> ogra_: you mean horrible math for uboot?
<ogra_> yeah
<mvo> lool: at least on grub it sounds like the best option we have
<lool> mvo: we tested the multiple initrds yesterday, it works
<mvo> lool: \o/
<mvo> lool: you rock
<ogra_> where to load the bits so they dont overlaop and can be used as one file from ram etc etc
<lool> mvo: for u-boot, it's technically possible, but I personally would prefer if we did u-boot -> grub -> multiple initrds
<ogra_> eeek !
<mvo> ogra_: so for uboot we can extract+conact so that the bootloader does not have to do terrible math
<lool> or we just cat the initds together on disk since u-boot systems are handled specially anyway
<mvo> lool: yeah, I think the later is the better option
<lool> the good thing about u-boot -> grub is that it gives us squashfs again
<mvo> lool: ohhhh
<ogra_> lool, well, that gets us issues with signed initrds
<mvo> lool: thats very interessting
<ogra_> lool, why would you do uboot->grup and not just grub ?
<lool> it's a recent patchset from Linaro (end of Dec) that enables the EFI interface in u-boot for grub-efi to use
<mvo> ogra_: right, so if we have a signed kernel we can not concat, can we? because it has to be signed ? :(
<lool> ogra_: it's too much work for us
<ogra_> having two bootloaders sounds super awful
<lool> people could also do efi/tianocore instead of u-boot, but this is not our battle
<ogra_> lool, rhight, which is why i'D stay with uboot alone until we can do a full switch to grub
<lool> ogra_: there are always tons of firmware before us
<lool> the question is whether we want to support both u-boot and grub or only grub everywhere in some way
<mvo> if we get grubs multiple-initird + direct loading from squashfs blobs, that would be a big plus. even if it means two bootloaders
<lool> I prefer the latter (grub only interface for snappy)
<dholbach> kyrofa, sergiusens: are we going to add a new milestone for snappy?
<dholbach> err, snapcraft
<ogra_> it will be slow and error prone to chainload
<ogra_> not to mention the maintenance burden
<ogra_> supporting uboot in snappy seems like the smaller amount of work in the end
<mvo> ogra_: error prone in what way? I expect that nothing would ever update uboot, it would just be like a mbr. what kinds of errors will happen? or is it the grub part that is the concern? (sorry for these silly questions, trying to understand the concern better)
<sergiusens> dholbach, yeah, but given the semantic thing, not sure it should be 2.1 or 2.0.2 depending on what we have :-)
<lool> I haven't actually tested the grub-efi stuff though
<sergiusens> dholbach, I'll sort it out today
<mvo> lool: heh :)
<dholbach> sergiusens: cool
<mvo> ogra_: nevermind, maybe we should have a quick call at some point to discuss the various pros/cons
<ogra_> mvo, it is simply one layer more than needed ... it will at least be a lot slower to boot ... error prone just in the way of having to make sure the configs keep working together when something changes
<mvo> ogra_: *nod*
<mvo> ogra_: don't get me wrong, I'm not advocating it, just trying to explore the options and the various pluses/minuses
<ogra_> yeah, i get that
<ogra_> preferably we'd just have a postinst step in the os and kernel snaps that creates a merged file when either of them gets updated ...
<lool> finally found the thread again http://lists.denx.de/pipermail/u-boot/2015-December/239054.html
<ogra_> but if we sign the file at build time and require signed initrsds that will not work
<sergiusens> from a snapcraft PoV we can do either; a kernel plugin which downloads the generic initrd from the archive which we use, but that brings in update issues if the generic thing changes under us
<ogra_> well, its all a matter of signed or not signed ... if we dont require the initrd we boot to be signed we can easily merge at any point
<mvo> ogra_: exactly, this is why I like the idea about loading multiple-initirds via the bootloader. but I do get it that its horrid with uboot
<ogra_> mvo, well, its just a lot more work to do the math ... and it is board specific so porting gets a lot harder
<ogra_> once you have all the numbers it wont be much harder
<ogra_> but often porting to a new arm board even finding the right address and RAM sizes for booting with one initrd can be really hard
 * mvo nods
<ogra_> so we double up the hardest bit :)
<noizer_> kyrofa an other question ps im NoiZeR from before todauy
<noizer_> *today
<kyrofa> noizer_, sure
<noizer_> kyrofa can i mount the snappy sd card in an ubuntu system and then place the *.so files on it. Can the snaps then use the lib?
<asac> sergiusens: pushed updaetd rev with comment
<asac> sergiusens: not sure what mvos comment means
<asac> mvo: you say we should produce the complete initrd in kernel snap?
 * asac reads more backlog
<asac> mvo: so current plan is to make mmodules/firmware only initrd in kernel snap and general one in OS snap and concat them preferable at bootloader
<asac> this would be exactly waht we would i fiigure
<asac> you are hesitant to that approach?
<asac> maybe having a call would help
<asac> :)
<ogra_> asac, that approach means that porting is a lot harder
<ogra_> but in the light of signed initrds that might be the only workable one
<ogra_> if we dont sign or dont require them signed there are more options (and less harder ones)
<asac> bootloader requirement yet
<asac> i think we coudl still merge them on disk
<asac> for bootloaders that cant concat load
<ogra_> not if they need to be signed
<asac> sure not
<asac> but not all platforms will need signing for hardware assertions
<ogra_> so if we ever want to enforce them signed, merging at load time is the only option
<asac> surely i dont want to ship core logic like our general boot code etc. in the kernel snap
<asac> thats even worse imo :)
<asac> right. think we want merging at load time
<ogra_> thats what mvo and lool propose
<asac> what do they propose?
<asac> merge at load time? yes +1 on that
<ogra_> asac, it will just make porting to new arm HW a horror trip for most porters
<asac> new arm HW probably gets a recent uboot which should be ok... i am more worried about old hardware
<ogra_> usually upstreams dont even give you a load address for a single initrd
<ogra_> it is hard enough to find the right bits and pieces for one
<asac> sure
<asac> i am mostly interested if and when we would get the load concat feature for pi2, beagle and dragon
<ogra_> now you need to figure out two of them and your uboot version needs to be recent enough too
<asac> if thats soonish, then i am bullish going down that oath
<ogra_> that would rule aout about half of the boards we have community suported today
<asac> yes, as i said i would love to also see a on-disk on update merge option
<ogra_> not every board is mainline or even uses a uboot version from the last 12 months
<asac> but its tricky due to how kernel and OS can move independently
<ogra_> no, thats not the prob
<asac> sure it is... you need to regen the combination of both
<asac> so you can fall back
<ogra_> both can have postinst magic to merge if either changes
<asac> at least its not trivial
<asac> yes, but you have to keep the combination of before the update
<ogra_> but you break the file signature for signed initrd
<asac> so you cannot just use the kernel or OS path
<asac> but have to mix them
<asac> sure
<asac> thats just a feature problem, but i think mvo is resistant for the reason i mention
<ogra_> you have one initrd per installed snap
<ogra_> (that is ... two kernel snaps, two OS snaps... i.e. 4 initrds)
<ogra_> there is still the option i wanted to do initially :)
<ogra_> and simply not merge them at all
<ogra_> but loop mount and link the contents
<ogra_> all from inside the generic initrd
<dholbach> kyrofa: thanks for the reviews
<dholbach> as far as I could I fixed everything up
<kyrofa> dholbach, awesome! And no problem :) . I'm going back through it again real quick
<kyrofa> dholbach, almost there on the variables
<kyrofa> dholbach, I know it's tough to hit a moving target-- thanks for your efforts!
<dholbach> kyrofa: no worries - it's great to work with you guys as a team :)
<kyrofa> dholbach, agreed :)
<asac> hmm
<asac> so is lib/firmware in a versioned subdir or not?
<asac> i see both things on my desktop
<asac> but apparently only old stuff in /lib/firmware/VERSION
<ogra_> lib/firmware isnt
<ogra_> it comes from linux-image-extra
<ogra_> but there is a versioned subdir with the kernel specific FW
<asac> but why do i have stuff in unverseioned /lib/firmware?
<asac> hmm
<ogra_> thats plain FW
<asac> ok so what the kernel installs goes into a versioned dir?
<ogra_> not bound to the kernel version
<ogra_> right
<ogra_> lib/firmware/$kvers
<asac> not really
<ogra_> that has device trees and kernel specific FW files
<asac> so upstream firmeare_install creawtes stuff
<asac> without version
<asac> it does for modules
<asac> so i am confused what goes were
<ogra_> hmm, thats beyond me then ... afaik generic firmware comes from linux-generic-extra
<asac> i have something in my kernel firmware_install that is in /lib/firmware
<ogra_> and specific FW should end up in the versioned dir
<ogra_> ask the kernel team then
<asac> apw: where do we put firmware? what goes in unversioned dir and what goes in versioned subdir of /lib/modules?
<asac> when using install_firmware kernel target it installs it withyout any version dir
<asac> and part of the stuff it puts there is in our unversioned dir e.g. atmsar11.fw
<ogra_> in lib/modules the only bits you should have in the toplevel are the dependency files from depmod
<apw> asac, firmware which is in a linux-firmware is in an unversioned directory, stuff that comes out of the kernel source goes in a version specific directory
<asac> ok, do we carry a patch or something against upstream?
<apw> asac, we supply the path we want it installed to which we put the version number in
<asac> or is it user space tool outside kernel that knows that location and loads stuff?
<apw> asac, the debian package version number
 * ogra_ wonders what asac is after here 
<asac> ok. well, think for our smnap its fine to have it not versioned as its really independent anyway on FS
<asac> lets see what happens :)
<ogra_> asac, well, it really depends on the search paths in the different tools
<asac> just stick to whatever firmware_install spits out feels safe
<asac> right. i was wondering waht does the firmware searching
<asac> if its part of the kernel then its fine
<asac> otherwise have to check out
<ogra_> why would you change what we have ?
<asac> i am not changing anything
 * ogra_ tries to understand your target
<asac> i am building upstream kernel from source
<asac> into a snap
<ogra_> well, then just use make install with adjusted target dir and be done
<asac> so what loads the firmware :)?
<asac> i can do that
<asac> but only if it works :) ...
<asac> need to conf that whoever knows about search paths
<ogra_> heh, why wouldnt it
<asac> is in the OS
<asac> well, uif the kernel itself looks for it
<asac> then it would probably prefer to have it where it expects it \
<asac> e.g. maybe we patched the kernel or use special config when building the in archive kernels to adjust the search path
<ogra_> but make install should cover this
<ogra_> and afaik you can still run any ubuntu with a home built mainline kernel (if your config is fine indeed)
<ogra_> so userspace shouldnt matter much
<asac> ok so the kernel itself looks for the firmware in the path?
<asac> then its all fine without doing anything
 * asac keeps it :)
<ogra_> well, not the kernel but the respective drivers i think
<sergiusens> elopio, standup?
<ogra_> just boot it, i'm sure your drivers will complain if they cant find firmware :)
<asac> booting is for the weak :P
<ogra_> lol
<asac> knowing is better
<asac> i cant boot it as we still have to figure the initd story above
<asac> i am just getting ready to whatever there
<asac> well i can boot, but not simply by using udf etc.
<ogra_> you can always use the system-image way :)
<kyrofa> elopio, you up yet?
<asac> my initrd doesnt even have an init right now :)
<asac> guess showing how to include atmsar11.fw in the initrd is as good as any :)
<ogra_> for what is that ?
<asac> no idea :)
<ogra_> doesnt sound disk specific
<asac> just to show how you can use your snapcraft.yaml to select firmeware that goes into your initrd
<asac> of course not
<ogra_> and thats all you want from the initrd
<asac> if you have a better example out of what pops out of x86_64_defconfig let me know
<asac> let me give you the list to pick one from
 * asac waits for build to finish
 * asac thinks he would prefer to have 32 cores
<asac> ogra_: snapcraft-master/examples/kernel$ find parts/kernel/install/lib/firmware/ | pastebinit
<asac> http://paste.ubuntu.com/14679351/
<asac> tell me which fw is better to pick as an example :)
<asac> maybe the e100 stuff? :)
<asac> anyway, good for now
<asac> lool: i got firmware feature now too. whats next?
<asac> ogra_: if you want to play, check out: https://github.com/asac/snapcraft/blob/kbuild-kernel-wip/examples/kernel/snapcraft.yaml
<asac> but no init in initrd so dont hope too much :)
<lool> asac: I'm working on a snapcraft snippet for a partner right now; I want to test the grub-efi patchset on dragonboard next to confirm feasability of multi initrd
<asac> gotcha
<lool> but worst case, we just cat the initrds together on arm
<asac> right
<asac> but mvo hates that idea
<lool> cat-ing?
<asac> but guess thats what he has to get over with
<lool> it's not different to the copy we're doing today anyway
<mvo> hate is such a strong word :)
<lool> since we dont have squashfs loading on arm anyway
<mvo> if thats the way, thats the way
<asac> lool: its because of rollback and keeping the rightg initrd combos
<asac> with independent kernel and OS snap
<mvo> we need to keep all the previous cats around though so that we can rollback
<mvo> but that should be ok
<asac> its a bit tricky, but guess nothing mvo cant solve
<mvo> its just more book keeping
<lool> generally we need to agree on what happens to A/B with kernel and OS updates separate
<lool> I guess OS was never considered part of it
<asac> guess cat /path/to/os/version1/initrd /path/to/kernel/version2/initrd > boot/initrd-version1-version2
<asac> dang :)
<lool> but now that it contributes an initrd snippet, it should trigger an A/B switch, shouldn't it?
<mvo> asac: exactly
<asac> yeah we need to track latest OS and latest kernel and previous combo
<asac> for the bootloader now
<asac> long term i think snappy should have a tx log so you can stepwise go back and see exactly what combo of packages was installed
<asac> :P
<mvo> asac: indeed
<asac> but thats nerdy i figure without having more advanced usecases
<asac> but still would be great to know how snappy system evolved to its current state
<mvo> asac: I guess we agree that we explore grub multiple initrd and for uboot concat even though that means no signed initrds on uboot(?)
<asac> mvo: i would like to start with concat on arm yes
<asac> the option lool explores would be still nice
<asac> but as an option
<asac> and as a requirement if you want secure boot of course
<elopio> fgimenez: did you have luck with m-o?
<ogra_> asac, any reason to not just glob lib/* ?
<asac> for those that cant do it we can validate signatures in our concat code of both pieces and put the merge sig next to it
<asac> ogra_: sure, the idea is that you can explicitely pick what you want for the initrd ... into the main snap all that gets installed with firmware_install gets in
<asac> e.g. after initrd the whole list you have in paste is avail
<ogra_> lool, mvo, asac, why not loop mount an img file with modules and fw and create the right links instead of merging two files
<asac> well, we want to leverage the ability to use drivers from initrd
<asac> to mount the FS
<asac> i think
<ogra_> yes
<asac> if we dont want that we can avoid all of this alltogether
<asac> if you loop mount the toher initrd you need to have the driver for that place
<asac> which you might not have
<asac> at that stage
 * ogra_ would create a loop mountable file for lib/modules|firmware ... and simply have *all* modules available from the start ... then move mount that during boot to the rootfs lib/
<asac> where do you put that mountable file though?
<asac> point of initrd is taht it gest shovelled into mem magically
<asac> without drivers
<ogra_> and simply make sure the kernel has vfat and loop mount support (plus whatever fs is used inside the loop file)
<ogra_> asac, next to the initrd
<asac> right. if we want to put that requirement up (e.g.t hat you can mount boot without modules)
<ogra_> into /boot
<ogra_> which is guaranteed to be vfat
<asac> then we can just not do an initrd in kernel snap
<ogra_> which we always support in our kernel
<asac> but we said for now we want to explore if we can do it right
<pindonga> sergiusens, elopio, PR updated --> https://github.com/ubuntu-core/snapcraft/pull/197
<asac> *shrug*
<ogra_> i find that more "right" than merging two initrd halves :)
<asac> two initrd halves sounds right :P
<asac> hehe
<asac> you coudl get both from nfs
<ogra_> not to me :) ... but i'm not tied to the loop mount idea
<asac> nicely in uboot
<asac> or from the cloud of course
<ogra_> sure
<asac> i was hoping we woudl do somethign like that
<ogra_> but you have to do that on bootloader level anyway
<mvo> or from pxe
<asac> but i couldnt get clear enough buy in so i think for now its best to just do it
<asac> with modules in initrd
<asac> and concat
<asac> and optimize later
<ogra_> then you can as well just provide a tool that repackst the initrd on the fly
<ogra_> that would be way less complex and effectively the same as merging the files
<asac> not so sure... i cant figure what that would mean right now, but we have understood the merge in bootloader approach as well as merge on disk
<asac> so lets unblock and do it :)
<asac> and its only one mvo patch away
<asac> and of course we have to produce an indep initrd on builders somewhat
<asac> but i think lool/mvo know what to do there
<fgimenez> elopio, yes, it seem to be working now, after update-ca-certificates -f
<fgimenez> elopio, i'm finishing some tests and then i'll put this into the ubuntucore/jenkins-ubuntu container, so that the next deploy will include it
<asac> elopio: fgimenez: did you guys think about having good tests for our kernel auto rolblack feature?
<asac> think would be key to have a strong stoory there
<asac> like having a bunch of instrucmented kernel modules taht make stuff crash or loop infinite in certain ways at certain times of boot process and ensure that our auto rollback never breaks
<mvo> asac: we have tests for this in the integration suite that break the kernel snap
<mvo> asac: but more cases of course is always better
<asac> mvo: with reboots?
<mvo> asac: yes
<asac> i mean does that run on real hardware etc.?
<ogra_> asac, i can do the generic initrd within the next 2h ... thats just copy paste from code we use elsewhere
<asac> VM?
<mvo> asac: on kvm, but elopio was working on tests on the BBB too for the kernel/os (or was it rpi2?)
<ogra_> but i think having to define "modules and firmware that go into the kernel" vs "just having all of it available at any time" is the wrong approach
<asac> mvo: thats cool if we have... how do we break the kernel? i think we need 3 cases: kernel does not exist at all, kernel panics early but does not reboot, kernel panics but ddoes reboot, kernel just gets stuck forever never reaching health check
<ogra_> *that go into the initrd
<asac> ok 4:)
<ogra_> ... sorry
<asac> ogra_: we dont define what goes into kernel
<asac> we define what goes into kernel at initrd stage
<asac> after that all is available of course
<asac> just in case thats not understood
<ogra_> asac, yes, i corrected myself above
<ogra_> i think thats wrong
<asac> kk
<mvo> asac: yeah, I'm not sure which of those, I have a look now
<ogra_> all modules should always be available ... my loop mount way would provide that
<asac> you would need the kernel snap on th vfat
<asac> and just mount it
<asac> i dont think mvo wants that
<ogra_> the modules img
<asac> well, its close to the same
<ogra_> not the kernel snap :)
<mvo> well, I see a gap here when it comes to e.g. PXE booting
<asac> can just be the kernel snap i figure
<asac> right
<ogra_> mvo, why ?
<mvo> to support that our kernel would have to have all network drivers build-in
<ogra_> its just amnnother file you have to add to the PXE config
<ogra_> PXE already has to load initrd and kernel binaries
<ogra_> so you add a third file it loads to give you the modules img
<ogra_> the rest happens from the initrd
<mvo> and where will that file be stored, i.e.. how does the kernel/initrd access it?
<ogra_> in ram ?
<mvo> on the computer
<mvo> I get that
<ogra_> 8sure
<mvo> I mean, how does the kernel/initird access it? how is it availalbe to it?
<ogra_> how is the initrd available to the kernel in that setup ?
<ogra_> (you load it to ram and uncompress from there ... not much different to loop mount it from there if your kernel has the necessary bits included (which is has))
<mvo> ogra_: I know how inird works, but I do not know how you can load an image file into ram and tell the kernel to loop mount it from ram, that part is what I'm missing
<ogra_> me too, but i shouldnt be hard to figure out
<ogra_> PXE surely has the mechanics to get us that
<ogra_> (the load into ram part)
<mvo> ogra_: ok, it sounds a lot like a second initird to me :)
<ogra_> mvo, except that it is not ... because it is the same modules.img your booted system uses
<mvo> ogra_: the load to ram part I'm not worried about, sure, pxe can do that. the "how does the kernel get it from ram and mount it part" is what I'm not sure about. I'm sure its possible, I wonder it its straightforward
<ogra_> a second initrd is essentially what we do today (selection of modules included) just chopped into two parts
<mvo> ogra_: right, the model you propose is different, but conceptually it sounds a lot like a initird to me
<ogra_> what i'm proposing is to drop the duplication of modules altogether
<ogra_> and re-use the modules.img on the booted system
<mvo> ogra_: I think we agree on that
<mvo> ogra_: oh, sorry, now I see what you mean
<ogra_> so you dont have to define firmware or modules in the snapcraft.yaml like asac currently does
<ogra_> this model is easy to implement in the vfat case ... but yeah, it will need some research and coding for PXE ... in the end though, PXE should give us the img content *somewhere*
<asac> mvo: can you tell me what to do in the end?
<mvo> ogra_: its a very interessting idea. for pxe there are some more things to consider, the modules dir is ~200mb big, so a netboot would have to download that and put it into ram.
<asac> i think what ogra is proposing needs more thinking
<asac> but thats just me
<asac> if you feel comfortable to do that just tell me what the kernel snap should spit out/include\
<asac> and i can replace initrd with that
<asac> initrd-modules-only that is
<ogra_> mvo, yeah, one would hope that someone had thought about it by today, given i promote that setup since the last orlando UDS :P
<mvo> asac: well, the most simple way forward is that we require the kernel snap to be able to boot without loading modules. this way we can have the os snap provide the initird and we are unblocked and can research more options
<asac> if we do it we shouldnt spit out a separate modules.img
<asac> but just loop mount the kernel snap though
<asac> mvo: yes, but note that this is not true for the ubuntu packages
 * ogra_ wanted that setup for normal ubuntu installs since ages :P
<asac> so we deviate from ubuntu
<asac> for the snapcraft built ones
<mvo> ogra_: you mean the pxe case? or the how-to-get-from-ram-inito-a-mounted-dir thing?
<asac> that was another reason i didint like to do that in this step
<ogra_> mvo, the modules.img
<ogra_> in general
<ogra_> i had a long BOF session at the last orlando UDS where iheavily promoted it ... sadly it never happpened
<mvo> asac: right, I think this only works if we do the same to our kernel, i.e. move squashfs in instead of having it as a module
<mvo> ogra_: was anyone there against it?
<mvo> ogra_: or did it just not happen
<mvo> ?
 * ogra_ has a hard time to type ... the cats are so happy i'm back that i barely am allowed to use the kbd today 
<ogra_> mvo, the latter ...
<mvo> ok
<ogra_> even the kernel team was interested back then
<asac> mvo: i dont think our kernel te4am will put that requirement up
<ogra_> after a year or so i stopped pushing for it though ... and never got to it myself ... the idea is ages old though and could have been researched by today ... including PXE
<asac> they want nfs boot and friends
<asac> hence my hesitation
<asac> nfs using crazy wifi modules
<asac> etc.
<asac> it would mean to include almost all network and disk drivers in the kernel statically
<asac> e.g. no-fly
<ogra_> asac, well
<mvo> asac: right, multiple initird is my best answer then
<asac> basically all that is in current initrd
<ogra_> asac, today we include almost all network modules in the initrd
<asac> yes
<asac> all those would then go into the kernel statically
<asac> so its huge
<ogra_> you only move it around
<asac> no
<asac> if its module they dont get loade
<asac> d
<ogra_> sure
<asac> if its static its in the kernel all time
<ogra_> it gets loaded into ram with the initrd.img ... it wont be used later indeed
<asac> e.g. only what is needed vs all in ram
<asac> yep
<ogra_> but if you load a 19M kernel.img or a 19M initrd.img doesnt make much difference
<ogra_> both is bad
<kyrofa> sergiusens, this was our previous standup: "So do you know anything about that?" "No, we'll have to ask sergio." "Okay, have a good day!"
<sergiusens> pindonga, I'll look now
<sergiusens> kyrofa, lol
 * sergiusens reads the full backlog first
<mvo> ogra_: the initird is freeed again once the boot is complete, no?
<asac> yes
<ogra_> mvo, yes, indeed ...
<kyrofa> sergiusens, so it's a good thing ;)
<ogra_> but the loading will be the same, no matter where your modules live
<ogra_> s/modules/drivers/
<asac> sure, but the mem waste will be something i am sure some folks in kernel/foundations/server team will not take time to even consider to consider
<elopio> asac: on our suite we have a more or less generic way to break every snap. It would be great if you help us extend it with common ways to break a kernel update.
<ogra_> asac, there is no mem waste ... thats what i'm saying
<asac> elopio: right, see the four classes of issues i mentioned avbove
<ogra_> at most there is a move of the existing waste
<elopio> asac: and it currently works on rpi and kvm. And it will work on bbb as soon as its kernel works again.
<asac> if we have one instrumentation for each of that i would feel pretty good to start with
 * elopio reads back.
<asac> elopio: think it was somewhere close to where i highlighted you :)
 * asac realizes lots of lines were said here after
<mvo> asac: I think we have break systemd and break kernel, probably more
<mvo> asac: fgimenez and elopio did a really good job here, we even found kernel bugs this way :)
<asac> right, kernel has subclasses that i mentioned
<mvo> asac: yes, sorry for just glossing over this
<ogra_> there is a prob when the kernl doesnt actually panic though
<ogra_> and just hangs
<mvo> yep
 * ogra_ had that during dragonboard porting
<mvo> at least in this scenaro we get back to a good state once you power cycle
<elopio> asac: https://github.com/ubuntu-core/snappy/tree/master/integration-tests/tests Look at the ones starting with "failover". We have loops, crashes and empty files.
<elopio> Sadly all the ones that touch the kernel have open bugs :)
<ogra_> yeah
<asac> elopio: ok so we have all the cases i metioned? great!
<asac> elopio: now i would like to use those to make a demo out oof it (e.g. so folks can experience this themselves))
<asac> is that easy?
<asac> ok calls now
<asac> ttyl
<elopio> asac: it is. go run ./integration-tests/main.go -filter failoverSuite
<fgimenez> asac, if you have a running vm, "go run ./integration-tests/main.go -ip <vm_ip> -port <vm_port> -filter failoverSuite" makes clearer the failover working
<pindonga> sergiusens, thanks for the review... sorry I missed those vendor bits there, just pushed the fixes
<sergiusens> pindonga, no worries; I'm doing live testing now for the final bits
<sergiusens> elopio, help with figuring this out would be appreciated btw https://travis-ci.org/ubuntu-core/snapcraft/jobs/105199856 :-)
<elopio> sergiusens: merge with this one: https://github.com/ubuntu-core/snapcraft/pull/266
<Sweet5hark> sooo, how do I strace in snappy?
<ogra_> by using the snappy-debug snap i guess
<Sweet5hark> ogra_: how?
<ogra_> it should ship an strace binary
<qengho> Are there any snappy images that take the new package format?
 * ogra_ doesnt know "how" though ... in the past i used th hack up the wrapper script for such stuff ... but that isnt possible in the new world 
<ogra_> qengho, yeah http://people.canonical.com/~mvo/all-snaps/
<Sweet5hark> ogra_: sudo snappy install snappy-debug && strace yields comman not found
<Sweet5hark> and 'find /apps/ -name strace' doesnt enlight me either
<ogra_> well, it would be snappy-debug.strace ... but yeah, thats not there
<ogra_> so ignore me then (i dont use snappy-debug much anyway, someone who does might be better to answer this )
<kyrofa> ogra_, yeah, snappy-debug only includes the security tool right now
<ogra_> yeah
<sergiusens> ogra_, I would argue that one would enter the classic dimension and attach to a pid
<sergiusens> if more than attaching is required, I am not sure how to do this then :-)
<sergiusens> except by using the binary directly
<sergiusens> since snappy-debug does not provide strace itself
<kyrofa> Sweet5hark, any chance you're running an all-snaps image?
<kyrofa> qengho, can you define "new"? i.e. squashfs-based?
<NoiZeR_> Hi how can i deploy my snap that i made on Ubuntu 14.04 LTS deploy on my snappy OS
<ogra_> sergiusens, thats a pretty good idea .... we should have documentation for such stuff :)
<qengho> kyrofa: indeed.
<kyrofa> qengho, yes, but it's under heavy development right now. If you're okay with that, check out http://people.canonical.com/~mvo/all-snaps/
<ogra_> NoiZeR_, i usually scp it over and then use sudo snappy install --allow-unauthenticated /path/to/snap
<ogra_> scp it to /tmp or /home/ubuntu
<kyrofa> NoiZeR_, or use snappy-remote
<ogra_> yeah, if that still works
<kyrofa> ogra_, I don't recommend scping to /tmp as it's tmpfs right now.  You need that space to verify signatures :P
<kyrofa> ogra_, unless you're on rolling/all-snaps I guess
<NoiZeR_> i try to scp it
<Sweet5hark> kyrofa: please elaborate? I run the edge image in vagrant on amd64 ....
<Sweet5hark> kyrofa: (because the "stable" image was looping on two machines for me)
<kyrofa> Sweet5hark, if you're willing to be even more cutting-edge, use the amd64 image out of http://people.canonical.com/~mvo/all-snaps/ and you can use the "Classic Dimension." Are you familiar with that at all?
<kyrofa> Sweet5hark, then you can do as sergiusens recommended
<kyrofa> with strace
<Sweet5hark> kyrofa: nope, im not familiar with any of this ;)
<kyrofa> Sweet5hark, good, no problem!
<ogra_> kyrofa, ah, indeed, depends how big your snap is :) (i usually use ~/ anyway)
<kyrofa> Sweet5hark, if you use one of those images (which will become rolling eventually), you can use the classic dimension with snappy enable-classic, which allows you to use .debs and stuff. Good for prototyping
<sergiusens> ogra_, well https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md
<sergiusens> thank dholbach
<kyrofa> ogra_, yeah, true enough
<NoiZeR_> Wtf where can i drop files on snappy
<kyrofa> NoiZeR_, you mean with scp?
<NoiZeR_> i tried in /temp but he sais read only file system
<NoiZeR_> yes
<kyrofa> NoiZeR_, try the ubuntu user's home directory
<NoiZeR_> ok i pushed it on /home/ubuntu
<NoiZeR_> thx
<Sweet5hark> kyrofa: how do i best deploy that all-snaps image in vagrant/virtualbox?
<kyrofa> Sweet5hark, for vbox I suggest just downloading that amd64 image and converting it into a vdi
 * dholbach hugs sergiusens and kyrofa... and jdstrand! :)
 * ogra_ thanks dholbach 
<dholbach> I just extracted and updated the information from the the appdev manual :)
<dholbach> thanks for the reviews!
<kyrofa> dholbach, which is a magical mythical document
<kyrofa> Nice to get that stuff out there
<dholbach> I hope it will very soon be just part of the realm of magic, myths and fantasies :-)
<kyrofa> Sweet5hark, however, I'm not familiar enough with vagrant to help you much there, sorry :(
<kyrofa> dholbach, ha!
<dholbach> all right my friends - I call it a day - see you all tomorrow! :)
<kyrofa> Seeya dholbach :)
<kyrofa> Sweet5hark, does what I suggest for vbox make sense though?
<sergiusens> oh vagrant
<sergiusens> mvo, we might want to update utlemming on how to get the latest rolling stuff
<Sweet5hark> kyrofa: I hope so? I created a libreoffice snap with snapcraft, set up an snappy env with vagrant/edge, installed the snap and with some intermediate LD_LIBRARY_PATH hacking foo got it to at least spit out an answer to "libreoffice --help" ...
<kyrofa> Sweet5hark, ooo!
<sergiusens> kyrofa, ooo feels like open office, this is libre office being discussed :-P
 * kyrofa rolls his eyes
<Sweet5hark> kyrofa: everything beyond that ("libreoffice --cat" "libreoffice --convert-to pdf" for now) though returns RC 77 suggesting that libreoffice thinks it needs to restart and setup a profile in ~/.config/libreoffice or somesuch ...
<kyrofa> Sweet5hark, are you getting apparmor denials?
<Sweet5hark> kyrofa: and now I want to know about the nature of "somesuch" -- so strace and tools like that to see what libreoffice is doing would be helpful ...
<Sweet5hark> kyrofa: oh, ahem *cough*
<kyrofa> Sweet5hark, approximately a million of them, perhaps?
<Sweet5hark> a minor detail: Im sudoing/running as root for now because .... #YOLO
<Sweet5hark> kyrofa: were should I check for apparmor denials
<Sweet5hark> ?
<ogra_> Sweet5hark, you might want to tell libO to search for the profile under SNAP_APP_USER_DATA_PATH instead
<kyrofa> Sweet5hark, those are logged to syslog, but try running snappy-debug. First install it with `snappy install snappy-debug`
<kyrofa> Then run it with `snappy-debug.security scanlog` (use sudo if you're not su'd)
<kyrofa> Sweet5hark, it should spit all sorts of recommendations if you're getting denials. Look through there for the config files
<ogra_> Sweet5hark, well, you really dont want to sudo an app ... it will try to write stuff to /root most likely
<kyrofa> ogra_, not right now-- sudo still gets $HOME->/home/ubuntu
<ogra_> instead you want the right app wrappers to adjust paths and such for a normal user
<ogra_> your app will actually run as root anyway
<ogra_> kyrofa, weven after the command wrapper fired up as root and dumped all of env ?
<sergiusens> kyrofa, fyi I did this instead of the manual m https://github.com/ubuntu-core/snapcraft/pull/268
<kyrofa> ogra_, indeed, $HOME is real uid, not effective
<ogra_> ah, cool
<kyrofa> ogra_, so if you su, then what you say applies
<ogra_> right
<sergiusens> ogra_, don't spread old var names :-)
<Sweet5hark> ogra_:  Im happy when libreoffice runs as root for a start. once it does that, Ill care about the rest.
<ogra_> sergiusens, shhh
<ogra_> sergiusens, i simply dont have the new ones in my head yet :P
<NoiZeR_> kyrofa so i made a snap with this yaml file name: firstsnap
<NoiZeR_> version: 0.1
<NoiZeR_> # The vendor for the snap (replace 'Vendor <email@example.com>')
<NoiZeR_> vendor: Vendor <email@example.com>
<NoiZeR_> summary: test
<NoiZeR_> description: test
<NoiZeR_> icon:  icon.jpg
<NoiZeR_> parts:
<NoiZeR_>     cam:
<NoiZeR_>         plugin: python2
<NoiZeR_>         source: run.py
<ogra_> eek !
<NoiZeR_> but how can i run it?
<sergiusens> NoiZeR_, use paste.ubuntu.com please
<kyrofa> NoiZeR_, ugh, please pastbin
 * ogra_ points to paste.ubuntu.com
<NoiZeR_> kyrofa ok xD
<ogra_> NoiZeR_, not at all ...
<ogra_> you would have to define an "app" entry for that
<ogra_> to either have it run as a service or as executable app
<sergiusens> this is not the first time I see someone trying to put a file under source, not sure how to make it clear it is not the intended way
<kyrofa> ogra_, I think it's still safe to assume 15.04 here, no?
<sergiusens> we need a better error message there
<ogra_> kyrofa, well, it is probably safer to ask nowadays :)
<kyrofa> ogra_, touche
<NoiZeR_> ogra_ ok but what does i need to change then?
<ogra_> rolling is actually starting to get semi usable now :)
<NoiZeR_> http://pastebin.com/ycB5RGGP
<Sweet5hark> kyrofa: sooo, I ran "sudo snappy-debug.security scanlog" in one shell, which provides no output. then I ran my command in the other shell -- still no output.
<NoiZeR_> ogra_ kyrofa here is the pastbin
<ogra_> NoiZeR_, look at the snapcraft-examples ... there should also be apps among them
<kyrofa> Sweet5hark, huh, no denials eh? Check syslog just for sanity's sake real quick?
<Sweet5hark> kyrofa: nothing screaming at me from syslog -- last line is a cronjob note
<sergiusens> kyrofa, if Sweet5hark is running unconfined, that may be the issue
<kyrofa> sergiusens, oh, good point. Sweet5hark are you unconfined?
 * sergiusens reboots and will lose all backlogs; yay irc with no backend to support the backend
<Sweet5hark> kyrofa: elaborate?
<kyrofa> sergiusens, you need a bouncer
<sergiusens> kyrofa, that is the backend to support the backend ;-)
<kyrofa> sergiusens, :P
<kyrofa> Sweet5hark, have you done anything special regarding security policies?
<Sweet5hark> kyrofa: nope
<kyrofa> Sweet5hark, okay, then you're just not getting denials. That's okay, but I do agree then-- you need to resort to strace
<kyrofa> Sweet5hark, in which case I suggest you download that amd64 all snaps image
<kyrofa> Sweet5hark, do you know how to get that working in vbox?
<ogra_> why not kvm ?
<kyrofa> ogra_, he asked for vbox
<ogra_> (saves you from converting the img)
<ogra_> NoiZeR_, look at the snapcraft.yaml of the godd example for an executable app ... i think thats the most simple thing you can do
<ogra_> for a service look at the snapcraft.yaml of the shout example
<ogra_> you want the "apps:" entries
 * kyrofa thinks cmake printing 100% more than once is an oxymoronic feature designed specifically to tease
<pindonga> sergiusens, pushed fixes... didn't do anything about upload progress bar yet... I think that could be added later in a separate PR (as an improvement on top of this)
<sergiusens> pindonga, sounds good
<ogra_> ooooh !
<ogra_> http://www.cnx-software.com/2016/01/27/orange-pi-one-quad-core-arm-linux-development-board-launched-for-9-99/
<ogra_> someone needs to do a snappy image for that !
<kyrofa> sergiusens, does snapcraft 2.0 no longer have a force?
<sergiusens> kyrofa, we removed it to do it properly, remember?
<ogra_> kyrofa, i think sergiusens just forgot to build it with the --luke option :P
<sergiusens> kyrofa, as in, we still need to get together and design it
<kyrofa> ogra_, groan
<sergiusens> hah
<kyrofa> sergiusens, indeed, just double-checking. I was just taking a look at bug #1477904
<ubottu> bug 1477904 in Snapcraft "snapcraft.yaml needs to make all stages dirty (was: the can't add file without recreating entire package)" [High,Triaged] https://launchpad.net/bugs/1477904
<sergiusens> kyrofa, ah, you want to tackle that one? It is almost like auto-force :-P
<kyrofa> sergiusens, just marking steps dirty via modification times is easy... but is that the best way? If they just add one little unrelated bit to this copy plugin part down there, now I have to re-pull and build the linux kernel part I have at the top?
<kyrofa> sergiusens, can we be smarter about this?
<sergiusens> kyrofa, do you want to look at this one today? :-)
<sergiusens> if so, hangout time
<kyrofa> sergiusens, there are others I can look at as well-- I imagine you're a bit swamped
<sergiusens> kyrofa, I feel swamped, not sure that I am swamped :-P Yeah, better tomorrow as it is quite complex; I've been thinking about splitting into three parts; but better do it tomorrow, yeah
<kyrofa> sergiusens, yeah, sounds good :)
<kyrofa> sergiusens, we should start having planning meetings every once in a while
<kyrofa> sergiusens, this issue, --force, plugin api improvements, etc
<sergiusens> kyrofa, yeah, together with our bug triaging meetings ;-)
<sergiusens> heh
<sergiusens> let me set that up
<kyrofa> sergiusens, yeah, though I feel like we've gotten better about that
<sergiusens> kyrofa, so friday it is
<kyrofa> sergiusens, excellent, thank you :)
<pindonga> sergiusens, thanks so much for approving that PR!
<sergiusens> np, looked good, did what it said it would do; so thanks!
<mvo> sergiusens: yes, I was hoping to have ud-f- in the archive
<mvo> sergiusens: codereview *cough* ;)
<sergiusens> mvo, didn't I review already? In any case, I think simplestreams is on trusty
<sergiusens> elopio, ideas http://paste.ubuntu.com/14682191/ ?
<elopio> sergiusens: is that local?
<elopio> xenial?
<elopio> sergiusens: I had a similar problem, it didn't find fixtures. I worked it around with PYTHONPATH=/usr/lib/python3/dist-packages ./runtests.sh unit
<elopio> to me it seemed like python3.5 crazyness.
<sergiusens> elopio, k, yeah local on xenial
<sergiusens> elopio, kyrofa aside from requesting an integration tests, comments appreciated https://github.com/ubuntu-core/snapcraft/pull/270/files
<kyrofa> sergiusens, awesome!
<sergiusens> kyrofa, elopio and now we have an integration test
#snappy 2016-01-28
<vir17> does snapcraft create snappy apps for armhf architecture?
<elimisteve> ERROR: 'my-scope' is not a directory
<elimisteve> I'm getting ^that^ error when running 'snap build .'
<elimisteve> Any idea what that means? I have many things called 'my-scope' so it's hard to know where to look
<elimisteve> Excuse me, 'click build .' is the command that gave me that error
<elimisteve> Think I solved it. Asked here: http://askubuntu.com/questions/726536/error-building-click-package-with-click-build-is-not-a-directory
<elimisteve> Solved it and posted the answer here: http://askubuntu.com/a/726543/125596
<fgimenez> good morning
<JamesTait> Good morning all!  Happy Thursday, and happy Data Privacy Day! ð
<vir17> with snapcraft can I create snappy apps for armhf devices/
<vir17> ?
<mvo> JamesTait: good morning! how it the snap.yaml stuff going .) ?
<JamesTait> mvo, good morning! Almost there, I think, although it looks like the solution won't be quite as clean as I'd like (just due to the way the current code is structured).
<JamesTait> I'm just writing up a quick follow-up to my earlier mail and will add a couple of details to the Trello card for completeness and transparency.
<JamesTait> I'll propose a first cut to unblock you guys, and then see about cleaning it up.
<vir17> hi all, I need some help to create a snappy app for raspberry pi 2
<mvo> JamesTait: \o/
<vir17> i have a simple app written in python and when i use snapcraft it creates this output: test_0.1_amd64.snap
<vir17> how instead of an amd64 I can produce a armhf
<vir17> ?
<JamesTait> mvo, actually, I just realised - when you said "we need to support snappy 1.0 until 15.04 EOL", did you mean 15.10?  Because 15.04 EOL is next week.
<mvo> JamesTait: snappy has a bit more EOL
<mvo> JamesTait: until snappy 16.04 is there
<JamesTait> Ah, OK.  That makes more sense. âº
 * JamesTait tries to keep up.
<mvo> vir17: if its pure python you can set the the yaml to: architectures: [all]
<vir17> thank you mvo  i will try it
<Sweet5hark> Hi guys, sorry had to run yesterday. Installed the all-snaps image in the meantime, but cant find any starce in there too. Any hints?
<mvo> Sweet5hark: the best I can offer right now is to scp it in, we want htis to be part of the snappy-debug snap but its not quite there yet
<Sweet5hark> mvo: k
<Sweet5hark> mvo: thx
<diwic> how can I use "snappy try"? I'm on 16.04 so there's nothing in the snappy-dev/tools ppa
<diwic> and "snappy try" just responds "did you mean activate?"
<mvo> diwic: snappy try is not implemented yet, as a workaround you can just install it
<diwic> mvo, sorry if this is a newbie question, but how do I install a snap that's not in the store yet?
<diwic> (I just made the snap myself, and it's not ready for the store yet)
<vir17> and another newbie/stupid question from me, how do I run an application that I have install
<mvo> diwic: if you build it with snapcraft you should have a snap file, just scp it to the snappy system (or use snappy-remote) and then you can install it via "sudo snappy install ./path/to/snap.snap"
<mvo> vir17: it will generate a command with "snapname.binaryname", check /snaps/bin to see if its there. note that the metadata in meta/package.yaml must be there, i.e. you need to declare what binaries the snap has (or services)
 * mvo is away for some minutes
<diwic> mvo, snappy-remote seems not available for xenial, so I'm going to try the scp approach. thanks
<asac> mvo: lool: ok, so do we need a chat to decide what we do on kernel snap now?
<ogra_> asac, ah, that reminds me ... regarding the snapcraft.yaml you showed me yesterday ... how do you make sure the minimal requirements if the kernel config are fulfilled (apparmor, various cgroups and namespace settings etc)
<ogra_> do you have some config checker script ?
<asac> ogra_: no, but we have default configs later thaht you have to explicitely disable...for now its raw DIY :) ...
<ogra_> well, then you need at least a fat README that lists the required options ;)
<asac> think we would need default config options that are hard to disable + some patch checker or something to ensure all the right apparmor patches are in
<asac> yeah for sure
<ogra_> the kernel pacfkage has all this already
<asac> think thats polishing
<ogra_> i wonder if you could just steal it from there
<ogra_> well
<ogra_> creating a unusable kernel isnt fun
<asac> if you have pointers for the patch checking that would be cool
<ogra_> (missing apparmor patches and such cause snaps to become non-executable)
<asac> do you have the list handy? otherwise i am sure i will hit this convenience problem when we get to point where we want to boot it :)
<ogra_> asac, well, i only know the config file used for the config enforcer, probably ppisati can point to the right person to talk about the code
<asac> where is the config enforcer? is that a snappy specific one?
<ogra_> it usually lives in linux-source-$ver/debian.$subarch/config/annotations
<ogra_> (in the source package ... not sure where in git)
<asac> the linux-lts-vivid-3.19.0$ find debian/ | grep annotat
<asac> doesnt have that
<asac> will check a xenial one i guess
<ogra_> might be arm specific, not sure
<ogra_> its a loooong time i have built an x86 kernel :P
<ogra_> asac, i think in x86 kernels it is in debian.master/config/annotations
<vir17> when I run in a raspberry pi with ubuntu snappy "sudo snappy install" I have this error:  Signature verification failed: No signatures, or no origin signature. (exit code 10)
<kyrofa> Good morning
<vir17> anyone has a clue why this is happening?
<ogra_> vir17, are you properly on the network ?
<kyrofa> vir17, are you sideloading an app, or installing from the store?
<vir17> sideloading
<vir17> and i try both ssh and using a keyboard in the raspberry pi itself
<vir17> and I have the same error
<vir17> i can only install it with snappy remote
<vir17> but then there is nothing in the bin file
<vir17> to run the app
<kyrofa> vir17, are you using --allow-unauthenticated?
<vir17> no
<vir17> kyrofa: so it is: sudo snappy install [snappy app] --allow-unauthenticated  ?
 * ogra_ always puts it after "install" 
<kyrofa> vir17, indeed
<ogra_> no idea if adding at the end works too :)
<kyrofa> ogra_, heh, it does
<ogra_> clever go parser ;)
<diwic> hi, is rpath encouraged/discouraged in snap executables?
<kyrofa> diwic, indeed
<diwic> which one of them?
<kyrofa> diwic, since depending on the type it takes precedence over LD_LIBRARY_PATH
<kyrofa> diwic, dt
<diwic> I currently have a binary in /snap/pulseaudio.sideload/weirdcombinationofcharacters/bin and some libraries in /snap/pulseaudio.sideload/weirdcombinationofcharacters/lib
<diwic> how is the binary supposed to find its needed libraries?
<kyrofa> vir17, so here's the issue you ran into. Snappy checks the signature of all packages it installs to ensure it comes from a valid source. When you upload a package to the store it gets signed by the store, so Snappy verifies that signature. If however you're sideloading it, then it hasn't been signed at all. Make sense?
<kyrofa> diwic, when your snap is actually generated, the binary gets a wrapper generated for it
<kyrofa> diwic, within that wrapper, many lib directories are added to LD_LIBRARY_PATH. If you're using a non-standard one you may need to write a wrapper script for your binary
<vir17> kyrofa: yes it makes sense thank you
<kyrofa> diwic, trace through the process starting at the /apps/bin/<package name>.<binary name> script that was generated. You'll see what I'm talking about
<kyrofa> diwic, er... /snaps/bin on your version, sorry
<vir17> kyrofa:  another question, i cannot find it in apps/bin
<diwic> kyrofa, /snaps/bin is empty
<vir17> i suppose something is wrong with my yaml file isnt it
<kyrofa> diwic, did you declare your binary in the YAML?
<kyrofa> Ha, vir17 to you as well
<diwic> kyrofa, thanks, probably not, will check that next
<kyrofa> sergiusens, got some network issues there?
<sergiusens> kyrofa, no, I just connected to a VPN for a sec
<kyrofa> sergiusens, oh
<sergiusens> kyrofa, another draw back when using irc :-P
<vir17> kyrofa: no i am not 100% sure how I do this, i will try and come back
<sergiusens> kyrofa, can you review #270?
<kyrofa> vir17, check out some of the examples in snapcraft: https://github.com/ubuntu-core/snapcraft/tree/1.x/examples
<vir17> thank you :)
<kyrofa> sergiusens, yeah, just catching up on emails real quick
<kyrofa> vir17, any time!
<kyrofa> diwic, by the way, regarding the rpath, I meant DT_RPATH
<kyrofa> diwic, DT_RUNPATH would probably be fine
<diwic> ok
<kyrofa> diwic, and you can use DT_RPATH, just remember that it will override anything snappy tries to do for you, so you'd better get it right :P (this comes from experience)
<diwic> I found an RPATH entry inside the executable, will try to remove it
<kyrofa> diwic, what build system?
<diwic> autotools
<kyrofa> diwic, I _think_ --disable-rpath is standard there
<diwic> kyrofa, if I'm supposed to set a correct rpath, I need to know the correct path, right? I e, how would I figure out the final installation directory ( /snaps/pulseaudio.sideload/weirdcombinationofcharacters ) ?
<kyrofa> diwic, exactly
<kyrofa> diwic, you'd have to use $ORIGIN I suppose
<kyrofa> diwic, i.e. relative paths
<kyrofa> diwic, but try using --disable-rpath first and add the binary to the YAML. See if that fixes things
<diwic> kyrofa, ok, so now I got a wrapper (or actually two wrappers). Now to figure out why --disable-rpath actually didn't disable any rpath. Thanks so far!
<sergiusens> kyrofa, diwic during SCaLE with didrocks we found out that setting --prefix= (to nothing) libtool or some other tool enables RPATH
<sergiusens> diwic, try setting --prefix to something (reasonable)
<kyrofa> diwic, ah, too bad
<diwic> sergiusens, aha, interesting, what is something reasonable?
<sergiusens> diwic, --prefix=/ or --prefix=/usr
<kyrofa> diwic, just remember that the prefix will actually affect the placement within the .snap
<sergiusens> this can fail depending on the m4 macro's smarts though (from what I recall mterry mentioning)
<kyrofa> sergiusens, question for you regarding that. For instance, when building apache it takes its prefix and actually writes it all over the place-- shell scripts, config files, you name it. What I ended up doing is choosing a prefix of essentially REPLACEME and then as part of the build replaced all that stuff with the snappy environment variables
<kyrofa> sergiusens, that's nasty. How would you have tackled that?
<kyrofa> sergiusens, rather, I did the search/replace after install
<kyrofa> mvo, just got your email to the list. Is that stuff in rolling, or all snaps? I'm starting to get confused with our options here :P
<mvo> kyrofa: its on all snaps with the next update, just literally landed ~5min ago
<mvo> kyrofa: I'm preparing updates as we speak
<kyrofa> mvo, alright. Rolling has, uh, stopped rolling, has it not? I'm assuming all-snaps will be rolling eventually, correct?
<ogra_> diwic, the current install dir is always a link from /snaps/pulseaudio.sideload/current to /snaps/pulseaudio.sideload/weirdcombinationofcharacters ... and in a store snap (not sideloaded) it will actually be: /snaps/pulseaudio.$maintainer/$snap-version (with the "current" link pointing to it)
<ogra_> also there is an envv variable pointing to it at runtime
<mvo> kyrofa: yes it has, see https://lists.ubuntu.com/archives/snappy-devel/2016-January/001381.html
<mvo> kyrofa: the all-snap images are getting all the love now :)
<kyrofa> mvo, ah, right, I remember seeing that. So if I want to release a package for all snaps, do I target rolling in the store then?
<mvo> kyrofa: yes, rollling is fine
<mvo> kyrofa: the store does not parse snap.yaml yet but for snapcraft thats fine because it will generate compat package.yaml files
<kyrofa> mvo, okay. Will all snaps eventually become rolling, or are we moving away from that structure completely?
<mvo> kyrofa: all-snaps is rolling, the previous rolling just is not there anymore (sorry, I think that sounds confusing)
<sergiusens> kyrofa, once 16.04 is released I'm sure beuno will add the option (not sure everything in rolling will be auto moved/tagged for 16.04 as well)
<beuno> yeah, I think we'll add 16.04 soon
<ogra_> mvo, hmm, snappy lets me install old snaps on rolling ... but fails to actually install them
<ogra_> beuno, ^^
<ogra_> shouldnt they be hidden ?
<ogra_> http://paste.ubuntu.com/14688116/
<beuno> ogra_, they should, yes, we're sorting all of that out
<ogra_> ah, k
<mvo> ogra_: yes, its a known issue, I meant to write to all the developers but didn't yet because its actually two changes that are needed: the rebuild with squashfs and the convertion to snap.yaml
<ogra_> right
<mvo> ogra_: the best option (for now) is to unpublish on rolling
<ogra_> well, after all i need to snapcraftify all my snaps anyway
<ogra_> (again :P )
<kyrofa> mvo, okay so u-d-f can still use "rolling" and it'll be all-snaps? On xenial only, it sounds like?
<sergiusens> mvo, one question I forgot to ask; are all rolling apps all of the sudden broken due to the use of skills (migration-skill) instead of the known caps, security-<override,policy,template>?
<asac> mvo: lool: no answer :)?
<jdstrand> mvo: related question, has migration-skill landed on the image?
<sergiusens> jdstrand, from the latest email, it seems it has
<sergiusens> mvo, do we support the unversioned data path already? (ref email on list)
 * jdstrand is not caught up on email today
<noizer> Hi guys i packaged an example snap from the github snapcraft. the py2-project is the project but how does i start it?
<noizer> or run the snap
<kyrofa> noizer, it has a binary in there, right?
<kyrofa> That binary causes a script to be placed in /apps/bin (or /snaps/bin if you're on rolling)
<kyrofa> noizer, which is in your PATH
<kyrofa> noizer, so try running spongeshaker.sha3sum <some file>
<noizer> spongeshaker.sha3sum is not a command :s
<kyrofa> noizer, take a look in /apps/bin. What is there?
<kyrofa> sergiusens, how far off is clean build, you think?
<kyrofa> sergiusens, and what does it actually entail? (i.e. how would it work)
<noizer> kyrofa some helloworld things from the helloworld application
<noizer> but nothing from spongeshaker
<kyrofa> noizer, ah, have you installed it yet? I may have jumped the gun
<noizer> sudo snappy install --allow-unauthenticated /home/ubuntu/spongeshaker_0_armhf.snap
<noizer> that did i
<noizer> to install it
<kyrofa> noizer, hmm... what folders are contained within /apps?
<kyrofa> (and did the install actually succeed?)
<kyrofa> noizer, do you see it if you run `snappy list`?
<LefterisJP> hey guys, today my Raspberry PI has 5 times already rebooted due to snappy autopilot
<LefterisJP> is that normal?
<LefterisJP> (RaspberryPi2)ubuntu@localhost:~$
<LefterisJP> Broadcast message from root@localhost.localdomain (Thu 2016-01-28 14:00:35 UTC):
<LefterisJP>  
<LefterisJP> snappy autopilot triggered a reboot to boot into an up to date system -- temprorarily disable the reboot by running 'sudo shutdown -c'
<LefterisJP>  
<noizer> here you can see the output of snappy list
<noizer> kyrofa and hi exists in the dir /apps
<noizer> kyrofa
<noizer> http://pastebin.com/LkTP0mTH
<sergiusens> kyrofa, we just need to do it; maybe a week or two away
<sergiusens> kyrofa, I'm still too slow this week; juggling with all the changes that happened while away
<sergiusens> kyrofa, cleanbuild is basically lxd
<kyrofa> sergiusens, hey, you're fine man! I'm just asking if maybe we should just drop my go PR if that's close
<kyrofa> sergiusens, because that changes a lot of things
<sergiusens> kyrofa, the thing is, your PR will work for the simple case, but imagine building some lib; then have your go project build after that one
<kyrofa> sergiusens, yeah... I feel like the REAL FIX is cleanbuild
<kyrofa> sergiusens, drop it?
<sergiusens> kyrofa, I would argue that we sometimes do want to export vars ourselves from the system
<sergiusens> kyrofa, if not, we should clean all vars for everything before snapcraft runs at all
<kyrofa> sergiusens, fair point. Though isn't that what cleanbuild will essentially do?
<ogra_> LefterisJP, 5 times ? i'm sure there werent 5 images built. do you perhaps mean it warned you 5 times like above ? (it should start that 10min before it reboots every 2 mins so you have a chance to stop it with the command it tells you if you feel like)
<kyrofa> sergiusens, obviously it will do more as well. But no environment leakage, I mean
<kyrofa> noizer, something is weird there. Try uninstalling/reinstalling the spongeshaker package
<noizer> kyrofa does not work :s
<kyrofa> noizer, pastebin the logs
<noizer> kyrofa while installing?
<kyrofa> noizer, yeah, pastebin the result of installing
<LefterisJP> ogra_: so whenever there is a new image this message goes out as long as you have auto pilot config on?
<LefterisJP> ogra_: perhaps not 5, but 3 times definitely, and no I meant the actual restarting and installing a new version.
<noizer> kyrofa http://pastebin.com/Xaf3XGbe
<kyrofa> LefterisJP, did you verify that it was a new version each time? Or is it failing for some reason?
<kyrofa> noizer, wait... I thought you said it didn't work
<noizer> no no it worked the installation
<noizer> kyrofa but how can i start correctly the snap
<kyrofa> noizer, pastebin the result of `ls /apps` and `ls /apps/bin/`
<noizer> kyrofa http://pastebin.com/s80aA5Nj
<awe_> kyrofa, sergiusens, where there any changes to the ability to override plugins in snapcraft 2.0?  I used this to add a patching step to the autotools plugin, but snapcraft doesn't seem to be detecting and/or running my local plugin anymore
<LefterisJP> kyrofa: no I did not actually. Good point.
<ogra_> LefterisJP, weird ... and yes, autopilot runs every ten mins and checks for a new image ... if there is one, it notifies you for 10 mins a few times and then reboots if you dont intercept
<kyrofa> LefterisJP, I mean... still a problem... but yeah :P
<kyrofa> awe_ no I believe that should still be working
<awe_> kyrofa, ok... I'll poke at it some more and see if I can figure out what's going wrong
<kyrofa> awe_ we need to cover that in integration tests. I'll check it out right now as well
<sergiusens> awe_, no, there has been no changes; I just used it last week mself
<awe_> kyrofa, I know you mentioned that the --help was caused by a lack of LOCALE
<sergiusens> kyrofa, it is covered
<awe_> maybe that impacts plugins too?
<kyrofa> sergiusens, oh. Well then, ignore me!
<mvo_> sergiusens: unfortunately not yet
<awe_> anyways, I'll dig into it some more after our net/telephony mtg
<awe_> I hit this late last night, and took it as a sign to end my day
<awe_> ;)-
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/test_local_plugin.py
<sergiusens> mvo_, err, not yet to what? :-)
<kyrofa> sergiusens, thanks for the reference :)
<sergiusens> awe_, give me a `find . | pastebinit` and a `cat snapcraft.yaml | pastebinit` and I'll take a look
<mvo_> sergiusens: the data dir is not there yet
<mvo_> sergiusens: the fixed one
<sergiusens> mvo_, ah, k, thanks!
<awe_> sergiusens, ack... I have to dive into a patch quickly before my next meeting, so I'll get this for you a bit later
<LefterisJP> kyrofa: how can I verify that I am at the latest version? snappy info shows release: ubuntu-core/15.04/stable and snappy list shows: ubuntu-core  2016-01-20 6
<mvo_> sergiusens: it is on the todo though
<awe_> sergiusens, I want to make sure it's not my mistake first
<sergiusens> mvo_, as everything :-)
<awe_> :q!
<kyrofa> awe_, yeah ping us if you need us to take a look
<awe_> !$#%%! haven't done that in a while!  lol
<ubottu> awe_: I am only a bot, please don't think I'm intelligent :)
<kyrofa> Awww, awe_ be nice to ubottu
<sergiusens> awe_, heh, well the first thing to check is make sure your <plugin> ref is a file named parts/plugins/x_<plugin>.py (notice the underscore)
<kyrofa> sergiusens, is the x actually required?
<noizer> kyrofa how does i solve it?
<awe_> hmmmm; looks like my parts plugin dir got clobbered at some point
<sergiusens> kyrofa, to override, yes
<kyrofa> noizer, what version of snapcraft are you using?
<sergiusens> kyrofa, well, I think it is always required; just to note it is an extension and not an official one
<noizer> release: ubuntu-core/15.04/stable kyrofa
<kyrofa> sergiusens, what if its named something totally different, though?
<awe_> pretty sure I didn't do an rm -rf; but I'll take the blame for now, unless I can prove otherwise...
<kyrofa> sergiusens, ahh, okay
<ogra_> noizer, and you try to run a snapcraft 2.0 created snap on int ?
<sergiusens> kyrofa, oh, you can override or name it whatever you want
<ogra_> *it
<kyrofa> awe_ there are times when I must scold my fingers for typing rm -rf instead of cp
<awe_> haha, yea...
<ogra_> kyrofa, you could just set an alias from rm -rf to cp ... that would solve it :P
<kyrofa> ogra_, hahaha
<noizer> ogra kyrofa my  snapcraft where i build it is snapcraft 1.0
<sergiusens> dholbach, bah, that thunderbird conversation view wiped my reply as didrocks's email came in :-P
<kyrofa> sergiusens, I'm wondering now-- does snapcraft clean make sure no custom plugins are in parts before it blows it away?
<ogra_> noizer, ah, that should still work then
<vir17> I have a similar case like noizer I think , this pastebin (http://pastebin.com/gf2qF1g8)  included all my steps, I think I have something wrong with my .yaml files
<sergiusens> kyrofa, yup; it doesn't blow away the plugins dir, it only cleans up from defined parts and you can't name a part 'plugins'
<sergiusens> kyrofa, way ahead of you ;-)
<noizer> ogra_ kyrofa so i tought it too but what does go wrong?
<ogra_> vir17, you need to include python in your snap
<kyrofa> noizer, where are you getting the example you're snapping?
<ogra_> check the snapcraft-examples and take a look at the python2 example
<noizer> https://github.com/ubuntu-core/snapcraft/tree/master/examples ogra_ kyrofa
<didrocks> sergiusens: oh, you are using that plugin? How come did my answer wiped yours? :p
<kyrofa> sergiusens, ah, I believed in you. Just curious :)
<ogra_> noizer, these are most likely 2.0 examples ... a lot changed between 1.0 and 2.0
<kyrofa> noizer, exactly, what ogra said
<kyrofa> noizer, use the examples by doing this: `sudo apt-get install snapcraft-examples`
<noizer> ogra_ kyrofa ok where can i get the snappy then for snapcraft 2.0
<ogra_> (but 2.0 snaps wont run on 15.04 ... so try to grab the 1.0 examples package instead )
<sergiusens> didrocks, I was typing a reply within the same view and your email arrival updated the view and my reply went bye bye
<sergiusens> :-)
<kyrofa> sergiusens, ahh thunderbird
<ogra_> (or switch your target device install to 16.04 )
<sergiusens> ogra_, and now, no snaps will run on 16.04 ;-)
<ogra_> sergiusens, oh ?
<sergiusens> ogra_, look at snappy-devel@
<didrocks> sergiusens: urgh, I know why I'm not using that plugin then! (I remembered to have tried it some years ago, but was unconvinced :p)
<sergiusens> kyrofa, hey
<sergiusens> standup time
 * ogra_ wishes his mailserver wouldnt be so stuck :P
<kyrofa> sergiusens, oh oops
<ogra_> be agile !
<ogra_> :P
<vir17> ogra_: in order to include python all I have to do is to include "plugin: python2" in the .yaml file?
<ogra_> check the example for the exact syntax
<ogra_> there is a snapcraft.yaml in it
<vir17> ok
<noizer> kyrofa what is de difference between snapcraft 1.0 and 2.0
<ogra_> new features ... new yaml syntax ... and most important 2.0 uses squashfs files
<ogra_> all these bits are only supported in rolling (16.04)
<noizer> ok i think i will switch to it but what are squeashfs files? ogra_
<ogra_> it is a compressed readonly filesystem
<ogra_> saves a lot of diskspace and download time
<ogra_> (and you cant just mount it rw, so it adds extra security)
<alella> can  packages running on ubuntu 14  be compiled to run on snappy
<ogra_> alella, theoretically you could even run packages from last century inside a snap (snaps need to include their dependency chain)
<noizer> ogra_ so but is it possible to mount because for me i need to do that for installing main things
<ogra_> noizer, in 16.04 everything is a snap and snaps all ship suqashfs inside, so no, you wont be able to modify any of the writable bits anymore
<ogra_> 16.04 ships the classic dimension though, that gives you a rw container on top of the readonly fs for development etc
<noizer> so when i mount it on a other ubuntu system i cant do changes?
<didrocks> ogra_: the container is just for developping, right? It's not started at reboot (and so you can't have services running in it), or am I wrong?
<sergiusens> didrocks, it is the intended purpose
<alella> so if you a packaga designed for ubuntu 14 you cant  use snappy commands to compile for snappy
<ogra_> didrocks, right
<didrocks> ok, got it right then :)
<ogra_> it is good enough to run snapcraft in it :)
<ogra_> what else would anyone want anyway ;)
<didrocks> ;)
<ogra_> alella, snaps only contain binaries, you can put whatever you want into it
<ogra_> i bet you could even put some redhat 4.x binaries into one and make it run as long as you ship all linkedf libs inside :)
 * genii shivers in disgust
<ogra_> hahaha
<ogra_> yeah, scary example, i admit that
<ogra_> but technically it might work
<elopio> ogra_ could you tell me about pxe in uboot? will we be able to use it on rpi?
<ogra_> i cant tell you about PXE but we can surely support some kind of network boot (bootp or so)
<jdstrand> ogra_: it buys some security, perhaps. if you have the ability to remount, you have the ability to bind mount, so...
<ogra_> i think i didnt remove the netboot setup defaults from the uboot env
<jdstrand> (in fact, that is exactly how I am testing certain things on all snaps)
<ogra_> just intercept the boot in uboot and check with printenv
<jdstrand> actually, I think I used an overlay not a bind mount. still
<ogra_> jdstrand, well, it prevents me from hacking on my shell script wrappers directly on the running system
<jdstrand> overlayfs /snaps/bin
<jdstrand> hack away
<ogra_> sure i could do some overlay magic etc ... but ui cant modify the actual squashfs
<jdstrand> that is true
<jdstrand> and that is definitely an important quality for integrity
<ogra_> well, i can ... but only trhrough repacking
<ogra_> right
<ogra_> it is annoying in the develo0pment process though ...
<jdstrand> I realize I'm being pedantic
<jdstrand> it is
<ogra_> jdstrand, oh, btw ... does your ufw package do anything with bridging ?
 * ogra_ recently had someone asking if there was bridge support in snappy 
<jdstrand> I've wondered if we shouldn't just straight up have a tool to create a cow overlayfs on /snaps/foo, etc for this sort of thing
<ogra_> i assume ufw sits a layer above ?
<jdstrand> ogra_: not natively, no
<ogra_> yeah, thats what i suspected
<jdstrand> ogra_: there are hooks scripts that you can put whatever you want in them for bridges, qos, etc, but it is all on the admin
<ogra_> and packaging bridge tools might be a pain wrt securing it
<kyrofa> jdstrand, wait... can you use overlayfs to hack on the mounted squashfs snap? Or are you guys saying that's exactly what's NOT possible?
<elopio> pitti: is it possible to allow some autopkgtests to access the internet? or are there no exceptions, is it strictly blocked for everybody?
<ogra_> kyrofa, you can ... but you wont hack on the squashfs
<pitti> elopio: they can all access the internet, as long as they respect the $*_proxy env vars
<ogra_> only on the writable overlay
<pitti> elopio: and a lot of them actually do
<kyrofa> ogra_, right, so it doesn't actually save upon reboot. But it allows you to tinker anyway?
<ogra_> yeah
<jdstrand> kyrofa: let me give a concrete example. I have root on the device. I want to test the new ubuntu-core-security package before uploading it. I create a cow overlayfs so I can unpack my ubuntu-core-security deb in it and have the system see the update
<kyrofa> kgunn, ^^ you might like that
<jdstrand> kyrofa: the same thing could be done for an app snap (the above was for the os snap)
<kyrofa> jdstrand, interesting, I need to do some overlayfs research
<ogra_> note that we do not have it on all kernels (i thinnk)
<jdstrand> ogra_: that is probably true and if it isn't now, it will be for sure
<ogra_> yeah
<jdstrand> but, for working with vms or the bbb and rpi2, it should be fine
<ogra_> at least in xenial
 * jdstrand is assuming since bbb uses generic and rp2 a modern kernel, it is there
<jdstrand> I've only done it on amd64
<kgunn> yeah interesting
<jdstrand> one could do it with just a bind mount, but then you have to copy everything in
<vir17> ogra_: still no success, this is my new .yaml file http://pastebin.com/RfPVJn0f based on this one: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/py2-project/snapcraft.yaml   and these are the outputs of "ls /apps" and "ls/apps/bin" http://pastebin.com/XMJK272q
<jdstrand> kgunn: from my notes (I'm not a huge overlayfs user, but this worked for me)
<jdstrand> Say I want to update the templated policy on the device:
<jdstrand> $ mkdir /tmp/overlay /tmp/work
<jdstrand> $ sudo mount -t overlayfs -o lowerdir=/usr/share,upperdir=/tmp/overlay,workdir=/tmp/work overlayfs /usr/share
<jdstrand> $ sudo dpkg-deb -x ./tmp/ubuntu-core-security-seccomp_16.04.10_all.deb /
<jdstrand> $ sudo dpkg-deb -x ./tmp/ubuntu-core-security-apparmor_16.04.10_all.deb /
<jdstrand> that is how I tested an ubuntu-core-security update on all snaps
<kyrofa> jdstrand, excellent notes, thank you!
<elopio> pitti: I see. Our tests are timing out doing a git clone, so I could fix them with something like
<elopio> git config --global http.proxy $...
<elopio> right?
<pitti> elopio: no, the env vars should already be set in /etc/environment
<jdstrand> kyrofa: you're welcome :)
<pitti> elopio: didrocks' ubuntu-make tests use git clone as well and that works
<elopio> great, I'll check there.
<didrocks> elopio: confirming, I don't need to export any env variable (only for docker config, but that's different)
<elopio> didrocks: and do you clone git http: or with git: ?
<didrocks> elopio: the https:// scheme
<didrocks> the git one (ssh) isn't opened
<elopio> I can change the tests to use https instead of ssh, as sergiusens suggested.
<mvo_> ogra_: could you please remind me how the kernel (device) tarball is created on cdimage nowdays?
<elopio> I wanted to keep at least a test using the git protocol, but that's alright.
<sergiusens> ogra_, jdstrand so that is one of the things snappy try is supposed to bring to the table; from you dev area you could `snappy try DIR` and it would just put it in the right place, activate and you can play easily from your classic env
<ogra_> neat !
<mvo_> sergiusens: yeah, I think we will use something like jdstrand is doing with overlayfs for that
<jdstrand> I think that is where we may get into the issues of overlayfs and apparmor though
<jdstrand> snappy try could easily use a bind mount though
<sergiusens> mvo_, well if it is a first time snap, overlayfs won't exactly work, will it?
<jdstrand> that's another reason for a bind mount
<sergiusens> jdstrand, I think bind mounts are going to be straight forward as well
<jdstrand> just copy stuff in there
<mvo_> sergiusens: sorry, I was too terse, I was thinking that we use the overlay for /snaps/bin and bind mount the actual app dir
<sergiusens> ah
<mvo_> sergiusens: and services probably also as overlay
<sergiusens> mvo_, makes sense
<mvo_> sergiusens: to avoid leaving stale files around
<jdstrand> that should work fine
<noizer> kyrofa is snapcraft 2.0 and ubuntu LTS 16.04 already available for raspberry pi?
<kyrofa> noizer, yes, but it's still in development
<kyrofa> noizer, both, rather
<noizer> ok its not a stable version
<kyrofa> noizer, indeed
<noizer> kyrofa ok and what is the expected release date?
<kyrofa> noizer, 16.04 is actually a date
<kyrofa> noizer, April, 2016
<kyrofa> noizer, the previous version is wily, 15.10, released in October 2015. Make sense?
<vir17> Can anyone help me please, this is my .yaml file http://pastebin.com/RfPVJn0f based on this one: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/py2-project/snapcraft.yaml   and these are the outputs of "ls /apps" and "ls/apps/bin" http://pastebin.com/XMJK272q
<noizer> kyrofa but snapcraft 2.0 is much better i think?
<diwic> a few dependencies added and some files moved later - now pulseaudio does not complain about missing libraries any more, but it exits immediately with "Bad system call" instead.
<kyrofa> noizer, well, it's newer anyway. What feature are you looking for?
<diwic> any idea how to troubleshoot? gdb and/or strace does not seem available
<kyrofa> diwic, seccomp
<noizer> kyrofa none but i need to choose for my development
<kyrofa> diwic, are you familiar with snappy-debug?
<diwic> kyrofa, nope, but I tried to install it and installation failed
<kyrofa> noizer, 15.04 is stable right now, but it reaches end-of-life soon. rolling (what will become 16.04) is still in development, so it can break sometimes
<kyrofa> diwic, you're on rolling?
<noizer> ok and will snapcraft 1.0 apps work on snapcraft 2.0
<kyrofa> noizer, no, but the YAML changes aren't too bad
<diwic> kyrofa, the 16.04 image from ~two weeks ago
<noizer> kyrofa ok i will make my application then in snapcraft 2.0
<kyrofa> diwic, ah, yeah a new version on rolling was released that breaks things. Some packages need to be rebuilt
<lool> ogra_: hey
<kyrofa> diwic, so check /var/log/syslog for seccomp denials
<lool> I have this dragonboard u-boot tree from github, I've built u-boot there; can I just throw it on the SD card, or do I need to run the image tool first?
<kyrofa> diwic, are you familiar with seccomp filters? It's one of the confinement technologies used by snappy
<lool> (mkbootimg)
<lool> [264059.140132] mmcblk1: error -110 sending status command, retrying
<lool> uh
<lool> not happy  :-(
<ogra_> lool, i followed the docs in the tree ... one sec
<diwic> kyrofa, there is one, but I'm not sure how to interpret the numbers. syscall=135, which is "sys_personality" judging from a quick googling
<lool> ogra_: the last step is:
<lool> 5) run img.sh to wrap u-boot into fastboot compatible img
<lool> but wasn't sure if we need this
<lool> oh hey diwic!
<kyrofa> diwic, do you have scmp_sys_resolver on there?
<ogra_> lool, i think we do, i just followed the step by step guide
<kyrofa> diwic, you should be able to run `scmp_sys_resolver 135`
<diwic> kyrofa, it says "personality"
<noizer> kyrofa where can i download the development version of it?
<kyrofa> diwic, huh. No idea what that does :P
<diwic> hi lool
<kyrofa> diwic, but it's not in your seccomp profile
<kyrofa> jdstrand, is the personality syscall a security issue?
<kyrofa> I'm guessing yes
<jdstrand> kyrofa: I'd want to exercise caution with that one. tyhicks may have an opionion
<jdstrand> I need to step away for a little bit
<kyrofa> jdstrand, yeah the manpage is a little tough to understand, but it sounds iffy
<jdstrand> I'm mostly worried about exposing that part of the kernel to apps. eg, these different personalities that aren't used much might have future vulnerabilities
<jdstrand> but this is really to enable truly legacy binaries
<tyhicks> I don't know much personality(2) off the top of my head
<tyhicks> I'll have to look into it
<jdstrand> maybe there are other use cases...
<kyrofa> diwic, do you know why it's being used?
<LefterisJP> kyrofa: There it goes again, my system is going down for reboot
<LefterisJP> (for update)
<LefterisJP> how can I confirm it worked?
<kyrofa> LefterisJP, okay when it comes back up compare the version to what you saw last time
<LefterisJP> and version is?
<diwic> kyrofa, not yet, I'm trying to figure out how to change seccomp profile (if possible?) since there is no info about that in the snapcraft.yaml reference
<LefterisJP> snappy info?
<jdstrand> tyhicks: we don't have an explicit use case for it. it seems dodgy overall (not keen on how it would add to the attack surface). it does seem to only be for the process itself (the only thing going for it)
<tyhicks> the PER_SVR4 and PER_UW7 personalities look nasty since they allow page 0 to be memory mapped
<LefterisJP> or snappy list -v ?
<jdstrand> tyhicks: I suggest not getting distracted by it. we can investigate/add it at a later date if people need it
<jdstrand> (and people can use security-override today to workaround it)
<kyrofa> jdstrand, tyhicks thanks for the quick look guys-- sounds like we should avoid it if we can
<tyhicks> jdstrand: ok - my vote is 'no' until it becomes more of an issue down the road
<ogra_> lool, so i just checked ... i ran run.sh and then dd'ed it to the SD cards boot partition
<jdstrand> tyhicks: sounds fine. thanks for the quick glance
<kyrofa> diwic, check out some of the snapcraft examples-- the gopaste one has an override for a syscall
<ogra_> err
<ogra_> img.sh
<mvo_> ogra_: could you please remind me how the kernel (device) tarball is created on cdimage nowdays?
<kyrofa> LefterisJP, I think it was 6 according to you last paste? Which actually doesn't sound right
<kyrofa> LefterisJP, are you running 15.04?
<kyrofa> LefterisJP, or rolling?
<ogra_> mvo_, in a fresh chroot from live-build/auto/build after the rootfs was done
<mvo_> ogra_: thanks!
 * ogra_ digs up the line number
<ogra_> mvo_, 344 to 487
<mvo_> ogra_: heh, thanks :)
<mvo_> ogra_: the right file would have been enough but I'm of course thankful for every piece of info
<ogra_> heh
<ogra_> for that one we can just run mksquashfs
<ogra_> the rootfs will be a little trickier
<diwic> kyrofa, jdstrand, I believe I found the place in the PA code, it says "Maybe we're autospawned, try to clean up our environment as much as possible". I think I can comment it out since we won't autospawn on snappy
<mvo_> ogra_: yeah, I am looking at creating some manifest data for jdstrand right now
<ogra_> thanks to the fact that "-preinstalled" hardcodes tarball or ext2
<ogra_> ah
<diwic> I think it's trying to do restrict itself, i e increase security somehow
<kyrofa> diwic, I've had to do similar things to other codebases
<ogra_> mvo_, there is already a find call that dumps it to the log
<mvo_> ogra_: sweet
 * ogra_ tries to find the find
<mvo_> ogra_: all good
<mvo_> ogra_: no worries
<ogra_> 471         # dump the content list into the log
<ogra_> 472         echo "I: device tarball contents for $PREFIX.$tarname:"
<ogra_> 473         find . -type f
<ogra_> just redirect it to a .manifest file in parallel
<diwic> ok, need to EOD. Thanks kyrofa and others for all your help so far
<kyrofa> diwic, any time :)
<ogra_> diwic, thanks for pulse work !!!
 * ogra_ is fiddling with a mycroft snap ... urgently waiting for some audio love :)
<diwic> ogra_, heh, haven't got that far yet
<LefterisJP> kyrofa: 15.04
<kyrofa> LefterisJP, and you said an rpi2, right?
<LefterisJP> yeah still says 6
<LefterisJP> yes it's an rpi2
<kyrofa> LefterisJP, hmm... I'm on version 20 here
<kyrofa> LefterisJP, you've just left my realm of experience. I'll need to refer you to sergiusens or mvo_
<kyrofa> LefterisJP, I'm not sure how to debug the failed update
<sergiusens> kyrofa, LefterisJP that is an mvo_ or ogra_ topic, sorry
<LefterisJP> all right I am all ears if anyone can help. Good to know at least that the update is failing. That's progress already :)
<sergiusens> LefterisJP, maybe elopio or fgimenez can help as well
<LefterisJP> btw is any of you going to be in London next week?
<sergiusens> LefterisJP, is there anything interesting happening there?
<elopio> LefterisJP: are you in rpi2 snappy stable #6 and trying to update to #7?
<LefterisJP> elopio: I am in version #6 from what snappy list seems to tell me.
<LefterisJP> And the auto update kicks in
<mvo_> LefterisJP: sorry, I think I miss some context. so you have a 15.04 stable rpi2 and it fails to update?
<LefterisJP> and when it restarts I am still at the same version
<mvo_> LefterisJP: could you pastebin the exact error output?
<LefterisJP> ofc, but can you help me find it? Where should I look for the error output?
<elopio> LefterisJP: do you have a serial cable for that rpi2?
<LefterisJP> elopio: not on the ready but I can find one
<LefterisJP> can't I see something on the logs?
<camako> Is it possible to specify a particular version of a package in 'stage packages' section? Will something like "-libmypackage-dev (= version)" work?
<sergiusens> camako, no; we only support the latest in the archives
<elopio> LefterisJP: I'm flashing stable #6 to give it a try here.
<elopio> This is how I monitor the boot and reboot: http://elopio.net/blog/connecting-to-snappy-through-the-serial-console/
<elopio> and dmesg should have all the boot logs. But I think it doesn't keep the ones from the previous boot failure.
<LefterisJP> sergiusens: As for London, I am gonna be there in the canonical offices next week and heard some snappy core devs will be there so was wondering if I could meet some of you
<ogra_> looks like 6 was released on the 20th and 7 was released today ?
<LefterisJP> elopio: thanks. Nice link. Will also try to do that when I get the serial cable.
<ogra_> since when do we do weekly releases ?
<sergiusens> LefterisJP, wasn't aware of that, from whom may I ask?
<LefterisJP> sergiusens: Thibaut Rouffineau
<kyrofa> sergiusens, yeah I think his team is sprinting there
<sergiusens> LefterisJP, you might be able to go and  meet didrocks then
<LefterisJP> yeah it's some kind of sprint and I am gonna be there since it's a nice chance to meet some snappy people and get help with the framework snap we are working on
<didrocks> will be happy to chat with you LefterisJP :)
<LefterisJP> didrocks: sergiusens: nice :D, would be nice to put some faces on some nicks. Lurking in IRC and the developer lists is nice but has its limits
<sergiusens> LefterisJP, I have not been invited to that sprint; sort of glad since I would like to be grounded for a bit :-)
<sergiusens> mvo_, does the migration-skill support security-template and security-policy?
<mvo_> sergiusens: yes, all of the security stuff is supported 1:1, just a different place now
<sergiusens> mvo_, k, so files from -policy are used in the same way, good to know. I recall it in the code now
<sergiusens> thanks
<mvo_> sergiusens: yw
<LefterisJP> sergiusens: I know what you mean :)
<LefterisJP> elopio: Here is my dmesg output in case it can mean anything to you. I just noticed there are quite a few errors with the SD card. Could very well be related.
<LefterisJP> https://gist.github.com/LefterisJP/500f1907d9cae8471caf
<elopio> LefterisJP: update from 6 to 7 worked here.
<elopio> we'll need that serial log to understand what's failing during your reboot.
<LefterisJP> yeah I see. Then I guess I will need to order that cable. I don't have it after all. For the time being if I simply download and flash a newer raspberry pi image all should be good though I suppose.
<LefterisJP> elopio: ^
<kyrofa> sergiusens, if I want to test out the upload stuff on the staging server rather than actually doing an upload, do you know the URL off the top of your head?
<kyrofa> LefterisJP, yeah that'll work
<elopio> LefterisJP: yes, if you don't care about losing your work on that one.
<kyrofa> pindonga, actually my question might be better directed to you
<kyrofa> pindonga, if I want to test out the upload stuff, I figure I'd best do it on the staging server
<ogra_> mvo_, so i finally got around to try that all snaps dragonboard image ... hangs at the lk for me ....
 * ogra_ re-flashes the SD to make sure its not a flashing issue
<LefterisJP> elopio: yeah no worries about that, it's my testing Pi. Should get that cable though. I had communicated with Samsung's Artik via serial USB and assumed I could do the same with the Pi but it seems that I need the cable you mentioned.
<ogra_> lool, didnt you say mvo_'s all-snap image booted for you ?
<lool> ogra_: which one?
<lool> ogra_: I didn't try the dragonboard one, no
<ogra_> http://people.canonical.com/~mvo/all-snaps/
<ogra_> ah
<lool> I'm tring the efi v2 patchset on top of dragonboard u-boot right now
<lool> just trying to figure the right grub2 binary to load
<ogra_> well, perhaps we should first ahve a working image before modifying it :P
<ogra_> [260] ERROR: Could not do normal boot. Reverting to fastboot mode.
<ogra_> [270] Invalid partition index
<ogra_> [270] Invalid partition index
<ogra_> hmmm
<ogra_> i wonder if mvo_'s changes to my u-d-f patch caused that
<lool> ogra_: I had some SD errors on an SD here, and then it wouldn't boot on it anymore
<lool> I wrote a fresh image to a new SD and then it worked
<lool> might not be related but thought I'd mention it
<ogra_> yeah, unklikely to be related
<ogra_> the partition table looks fine
<ogra_> sadly it doesnt print much more than the above .... no actual reason mentioned .... grmbl
<pindonga> kyrofa, hi there
<pindonga> kyrofa, run it like this UBUNTU_STORE_API_ROOT_URL='https://myapps.developer.staging.ubuntu.com/dev/api' UBUNTU_STORE_UPLOAD_ROOT_URL='https://upload.apps.staging.ubuntu.com/' UBUNTU_SSO_API_ROOT_URL='https://login.staging.ubuntu.com/api/v2/' snapcraft upload
<kyrofa> pindonga, excellent, thank you!
<pindonga> let me know how it goes
<pindonga> sorry, the first one make sure it ends with / (ie, ../dev/api/)
<mvo_> ogra_: hm, I thought I did not really modify anything except for resolving conflcits. sad that it fails to boot now
<kyrofa> pindonga, how do I get a token for this? I'm getting "No valid creds"
<ogra_> yeah, i cant really get it past the little kernel, something is wrong with the partition ids ... i guess due to calling sgdisk differently after your change
 * ogra_ checks the tree
<mvo_> jdstrand: I'm making some progress on the manifest stuff, hopefulyl by tonight you have what you need
<kyrofa> Oh, login
<pindonga> kyrofa, right, snapcraft login
<pindonga> msg should be clearer about this possibly
<kyrofa> pindonga, indeed
<pindonga> kyrofa, unless you have 2fa enabled on your account when it asks you about OTP just press enter
<kyrofa> dholbach, hey what's the status of the auto document sync?
<dholbach> kyrofa: we're just deploying it on staging right now
<kyrofa> dholbach, woo hoo!
<dholbach> ran into some issues with juju and mojospec
<dholbach> so I hope it'll be done beginning of the week
<ogra_> mvo_, which dragonboard snap did you use ?
<ogra_> (bootloader etc)
<mvo_> ogra_: when I compare https://code.launchpad.net/~ogra/goget-ubuntu-touch/dragonboard/+merge/280320 with http://bazaar.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/revision/251 it looks like I call sgfisk the same way
<ogra_> mvo_, oh, i was referring to https://code.launchpad.net/+branch/~mvo/goget-ubuntu-touch/dragonboard
<mvo_> ogra_: I used what I got from linux-image4.2.0-2004 kernel snap and your gadget snap
<JamesTait> jdstrand, are you around?
<ogra_> i thought you landed that alongside
<ogra_> mvo_, that kernel wont work
<mvo_> ogra_: I don't think I merged that
<mvo_> ogra_: aha, thats good to know
<ogra_> yeah, i see that now
<lool> ogra_: so I have an updated u-boot for dragonboard, I've ran img.sh on it, it looks similar to the one I found in mmcblk1p7, but it seems boot goes straight to emmc, any idea what could be missing?
<ogra_> you need ppisatis kernel
<mvo_> ogra_: I need to leave for dinner now, if you could point me to the right kernel I can update the snap later
<ogra_> lool, you need the right UIDS on the partitions
<ogra_> it is very fragile :/
<ogra_> mvo_, right, the boot stalls on the bootloader with a partition error though
<ogra_> before u-boot
<ogra_> so there is something else
<dholbach> all right my friends - I call it a day - see you all tomorrow!
<ogra_> lool, see my scripts at http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files/5 ... the IDs are in http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/parts.txt (used as input for the partitioner script)
<lool> ogra_: I didn't touch the part table though
<ogra_> of the SD ?
<lool> yeah
<ogra_> hmm
<lool> I just overwrote u-boot payload
<lool> can I stop the boot somehow?
<ogra_> so the "boot" partition ? (not "aboot")
<lool> S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.0-00261
<ogra_> oh
<lool> [...]
<lool> Android Bootloader - UART_DM Initialized!!!
<lool> [0] [0] welcome to lk
<ogra_> actually ... on mvo_'s all-snaps image there isnt any boot partition ... hah
<lool> [90] [90] boot_verifier: Device is in ORANGE boot state.
<lool> [100] [100] Device is unlocked! Skipping verification...
<lool> [100] [100] Loading boot image (16521216): start
<jdstrand> mvo_: awesome, thanks!
<jdstrand> JamesTait: I am
<lool> but then it's [    0.000000] Linux version 3.10.49-g0b014e2-00001-gebe2063 (buildslave@aosp-x86-64-08) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #9 SMP PREEMPT Wed Dec 2 10:33:57 UTC 2015
<ogra_> lool, ok so that finds uboot and loads it it seems
<ogra_> hmm
<ogra_> oh
<lool> ogra_: [740] [740] Updating device tree: done
<lool> [740] [740] booting linux @ 0x80080000, ramdisk @ 0x82000000 (795398), tags/device tree @ 0x81e00000
<lool> [750] [750] Jumping to kernel via monitor
<ogra_> lool, did you set the dip switch to SD on the bottom of the board ?
<lool> yes
<ogra_> weird
<lool> ogra_: I was booting from SD, updated hte contents and ran "reboot"
<JamesTait> jdstrand, I might have figured out the problem, actually: does click-reviewers-tools currently handle squashfs snaps with just meta/snap.yaml?
<ogra_> lool, try re-powering ... might be it needs re-init
<jdstrand> ogra_: speaking of dragonboards-- I got one in the mail. I don't know what to do with it though (ie, to get it running). I don't need to today or next week even-- I assume instructions will come out sometime (or maybe I missed them already)?
<ogra_> for the Sd controller
<lool> I did try power cycling already  :-(
<ogra_> jdstrand, there are instructions already ... and an early image
<jdstrand> JamesTait: the review tools know about squashfs to some extent. they don't know about snap.yaml yet. those two things are what I will be focusing on
<ogra_> jdstrand, http://people.canonical.com/~ogra/snappy/dragonboard/README
<jdstrand> that doesn't surprise me at all
<jdstrand> thanks! :)
<ogra_> :)
<ogra_> lool, got a full log ?
<lool> ogra_: not really
<JamesTait> jdstrand, will that also encompass this error: "1 Warning: Unknown field 'daemon' snappy-systemd_package_yaml_unknown_key (server); 1 Fail: (NEEDS REVIEW) squashfs pkg lint_is_squashfs"?
<JamesTait> * These errors.
<lool> ogra_: ah I might miss your u-boot patch
<jdstrand> JamesTait: yes. the new snap.yaml is not supported yet
<jdstrand> but I'll get all working
<ogra_> lool, well, it should still go to uboot instead of the kernel
<JamesTait> mvo_, ^^
<JamesTait> Thanks, jdstrand.
<JamesTait> nessita, beuno too ^^
 * lool drops for dinner and will check again later
<jdstrand> I had a card on it-- and upped the priority when I saw it landed
<JamesTait> jdstrand, similar story here. âº
<kyrofa> pindonga, I can't seem to be able to login to staging
<beuno> JamesTait, ack
<jdstrand> heh
<kyrofa> pindonga, no 2fa there
<pindonga> kyrofa, be aware that staging sso is a separate db from prod
<pindonga> so your account may not exist there, or have a diff passwd?
<kyrofa> pindonga, yeah-- I can login online
<pindonga> k
<jdstrand> mvo_, sergiusens: iirc, snappy build is going away and everything is going to use snapcraft, correct?
<pindonga> does it give you any error msg?
<kyrofa> pindonga, just "login failed"
<kyrofa> pindonga, I use the same environment variables you gave me before with `snapcraft login`
<kyrofa> pindonga, is that the right way to authenticate for staging?
<pindonga> yes, should be
<pindonga> let me try it as well
<sergiusens> jdstrand, correct
<nessita> JamesTait, thanks. So we can land our work waiting for the new click-reviewer-tools and then do the cleanup
<jdstrand> sergiusens: ok, so two things: 1) I'm likely going to need to submit a patch to snapcraft to make sure it uses a particular set of options for mksquashfs (I'll submit that) so the store and snapcraft agree and 2) does snapcraft have a way to simply mksquashfs a directory?
<jdstrand> sergiusens: I'm not sure yet what those options are otherwise I'd give them to you
<JamesTait> nessita, indeed, it looks that way.  I just mangled the snap mvo_ gave me to also include a package.yaml, and the reviewers tools now handle it, but fails with the squashfs manual review and lack of a readme.md
<JamesTait> nessita, the click-reviewers-tools work will address both of those and the handling of snap.yaml
<kyrofa> jdstrand, yessir!
<jdstrand> sergiusens: the second question might be a nice thing to have so that everyone always uses the right options
<jdstrand> kyrofa: was that an answer to '2'?
<nessita> JamesTait, perfect. So you are a bit blocked now?
<pindonga> kyrofa, just logged in and uploaded a file successfully... checking your sso account now
<kyrofa> jdstrand, it was
<kyrofa> jdstrand, only 2.0 though
<jdstrand> excellent
<jdstrand> sure
<kyrofa> jdstrand, well, obviously
 * jdstrand nods :)
<kyrofa> jdstrand, yeah, just `snapcraft snap <directory>`
<JamesTait> nessita, my branch is ready for review, but might not make much sense without that update.
<nessita> JamesTait, if we land *and* deploy that we will block all squashfs uploads, correct?
<kyrofa> jdstrand, for your reference: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/commands/snap.py#L80
<jdstrand> handy
<jdstrand> kyrofa: thanks! :)
<kyrofa> jdstrand, obviously feel free to make a PR, but if you make a bug for it we can take of it too :)
<jdstrand> ack
<JamesTait> nessita, new squashfs uploads (without package.yaml) are blocked already.
<pindonga> kyrofa, ok, bug
<pindonga> am on it
<kyrofa> pindonga, ah, thank you! :)
<ogra_> mvo_, dd'ing my u-boot.img in place gets me gurther
<ogra_> *further
<pindonga> it's passing the otp even when empty
<pindonga> which causes sso to fail auth
<ogra_> so something is wrong with that u-boot binary
<nessita> JamesTait, ok, so we could move forward landing and eventually deploying that, correct?
<JamesTait> nessita, I think we're also depending on beowulf's icon_url piece, which I think is waiting until Monday?
<kyrofa> pindonga, ah, excellent
<JamesTait> If that's the case, maybe we should land this on Monday as well?
<nessita> JamesTait, not for this, no
<nessita> JamesTait, is independent, I think
<JamesTait> nessita, currently I'm unable to publish the package I just uploaded because it needs an icon.
<nessita> JamesTait, yeah, that is fine
<nessita> meaning is independant of your change
<JamesTait> OK, great! ð
<ogra_> mvo_, the next issue is that for some weird reason you added the uboot partition to the end of the disk ... the partition to load uboot.env from is hardcoded at build time in the dragonboard u-boot (and currently points to mmc 1:8 ... while the boot partition on your image is 1:9 ...)
<JamesTait> In which case I'll await a review of my branch and land it when we get approval, and I'm ready for something new.
<pindonga> kyrofa, sergiusens now that upload is part of snapcraft we might also need to update the examples; this is because the store will only accept a package icon if it's 256x256 px in size
<pindonga> the upload will get accepted, but the icon will not
<JamesTait> I should probably catch up on e-mails till my EOD in ~40 mins though. ð
<pindonga> ie, if you upload eg gopaste you'll see it there eventually but without the right icon
<kyrofa> pindonga, I'm writing an example doc for uploading right now
<kyrofa> pindonga, that's only for .pngs I assume?
<pindonga> yes, probably.. tbh don't know for sure if the store currently supports other icon formats
<kyrofa> pindonga, svgs
<kyrofa> pindonga, by the way I'm happy to fix that 2fa bug if you can point me in the right direction
<pindonga> almost there
<pindonga> I'll let you review it :)
<pindonga> + I introduced the bug so I feel responsible for fixing it
<pindonga> :)
<sergiusens> pindonga, kyrofa our solution could be to just remove all the icons ;-)
<kyrofa> sergiusens, I'm on board with that
<kyrofa> pindonga, haha, okay sounds good
<sergiusens> kyrofa, but they are examples, so we probably need an example with how to do it
<kyrofa> sergiusens, did forking turn into a boolean in package.yaml somewhere along the line?
<sergiusens> kyrofa, yeah
<sergiusens> kyrofa, package.yaml is going away in my skill migrationbranch though
<kyrofa> sergiusens, alrighty
<sergiusens> kyrofa, when you fix the upload stuff messages, can you silence the unit tests as well?
<kyrofa> sergiusens, yup
<sergiusens> kyrofa, thanks!
<pindonga> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/274
<kyrofa> pindonga, can you add a # to the bug ref in the commit? It _might_ work with git-dch, but all the man examples have the #
<pindonga> do I need to commit --amend or just update it in github ui?
<pindonga> updated in ui
<kyrofa> pindonga, you need to amend I'm afraid-- we need it in a commit
<pindonga> ack, doing so then
<kyrofa> pindonga, thanks :)
<nessita> sergiusens, hello! quick question, how can I build a snap without an icon? I'm using snapcraft from ppa:snappy-dev/tools and when running it complains: Issues while validating snapcraft.yaml: 'icon' is a required property
<pindonga> pushed
<kyrofa> nessita, you need snapcraft 2
<nessita> kyrofa, thanks for helping! any instructions where to get it from?
<kyrofa> pindonga, I don't see any changes...
<pindonga> ah
<kyrofa> nessita, that's the xenial release
<pindonga> bad push
<nessita> kyrofa, is there any way of getting it in willy?
<nessita> upgrading to xenial for this feels a bit overkill :-)
<kyrofa> nessita, not unless you feel like running from source-- pre-xenial is all Snapcraft 1.x
<nessita> kyrofa, I see, thanks
<kyrofa> nessita, what are you targeting?
<nessita> kyrofa, I'm working on the store and needed to debug issues when uploading a snap without icon
<nessita> kyrofa, so basically I need an iconless valid snap
<nessita> JamesTait, do you happen to have that? ^
<kyrofa> nessita, I'm not sure .snaps without icons are valid in 15.04
<JamesTait> nessita, I have a couple you could use.
<nessita> kyrofa, they are not, but I don't really need to target any specific snappy, my focus is the store
<nessita> JamesTait, highly appreciated!
<kyrofa> nessita, ah, I see. Yeah sorry about that. Running from source is pretty easy for what it's worth
<nessita> kyrofa, it is? anywhere I can read about how to?
<LefterisJP> https://github.com/ubuntu-core/snapcraft is the github repo
<kyrofa> nessita, yeah just don't use the upload stuff, it's prereqs aren't available pre-xenial. The rest should work though. Here's the general hacking guide: https://github.com/ubuntu-core/snapcraft/blob/master/HACKING.md
<kyrofa> nessita, but really, just clone is and run the bin/snapcraft script
<nessita> kyrofa, amazing! thank you
<kyrofa> nessita, check debian/control for all its deps. If you're running 1.0 you probably have most of them
<kyrofa> nessita, the master branch is 2.x, but not always released. I suggest `git checkout 2.0.1` to get the most recent release-worthy stuff
<nessita> kyrofa, super helpful, thank you (still cloning)
<kyrofa> nessita, note that 2.x generates .snaps that will only run on xenial. Not sure if that matters for the store stuff you're doing
<sergiusens> kyrofa, still need to update the integration tests and examples https://github.com/ubuntu-core/snapcraft/pull/275
<sergiusens> but it is a start
<sergiusens> need to run for a bit
<kyrofa> nessita, any time :) . Let me know if you need help with that
<kyrofa> sergiusens, sounds good!
<nessita> kyrofa, it does not matter, thanks, I'm just using them to upload to my local store
<kyrofa> nessita, whatever you do, don't install it using the setup.py
<kyrofa> Just use it straight out of the src
<nessita> yes, yes
<nessita> or install in a venv
<kyrofa> nessita, pssh, you know more about this stuff than I do. You'll be fine :P
<nessita> hunting for docopt now
 * nessita apt-get installs it
 * kyrofa goes to plug in the external monitor. If he drops that's why
<kyrofa> Hey! Still here
<pindonga> kyrofa, hey... looks like travis choke on that PR
<pindonga> what do we do about that?
<nessita> kyrofa, so! I ran snapcraft build with this output https://pastebin.canonical.com/148649/ but I don't have a .snap at sight
<kyrofa> pindonga, nah it's still going
<pindonga> do I need to re-push? is it possible to manually trigger a new job?
<kyrofa> pindonga, have faith
<pindonga> I mean, the static test suite failed
<pindonga> but bc of some lxc related issue
<kyrofa> pindonga, oh. So it did
<pindonga> ah, looks like it's restarting the job by itsel
<pindonga> itself
 * pindonga is new to these things
<pindonga> :)
<kyrofa> pindonga, I poked it
<pindonga> coo
<elopio> pindonga: is not automatic, there's a button.
<kyrofa> nessita, yeah things changed a bit
<kyrofa> nessita, run `snapcraft snap`
<nessita> ah!
<nessita> [Errno 2] No such file or directory: 'mksquashfs'
<nessita> installing!
<kyrofa> nessita, squashfs tools
<nessita> o/
<nessita> Snapped foobar_1.1_amd64.snap
<nessita> SUCCESS!
<kyrofa> Hey hey, there you go!
<nessita> and now the store chokes with it "The upload does not appear to be a valid click package" so this may be the fix we await from reviewer-tools
<nessita> kyrofa, thanks a lot for your help
<kyrofa> nessita, no problem, it's why I'm here :)
<kyrofa> elopio, git-dch does not seem to be in git-buildpackage in xenial. Do you know where it went?
<kyrofa> elopio, ahh, things were renamed to gbp it seems
<elopio> kyrofa: yes, same package, new name.
<pindonga> kyrofa, ok, looks like it's all green now
<kyrofa> pindonga, excellent, thanks for that :)
<mvo_> ogra_: oh, interessting - so there is a off-by-one error in the partition setup?
<mvo_> ogra_: one too many?
<mvo_> jdstrand: snappy build is goind away yes, we need to have something internal though for our build-in tests, so its going away and also not quite going away
<mvo_> jdstrand: looks like I missed all the action around the new snap.yaml :/ so click-reviewers-tools need an update too? will it just warn or outright reject the snap?
<vir17> is there a ready version of snappy for raspberry pi that uses snapcraft 2?
<kyrofa> vir17, yes indeed
<kyrofa> vir17, look here: http://people.canonical.com/~mvo/all-snaps/
<kyrofa> vir17, note that snappy and snapcraft are different though. You need to enable the classic dimension before you can use snapcraft on snappy
<kyrofa> vir17, do you know what I'm talking about?
<vir17> I think you talk about running snapcraft from snappy?
<vir17> or i am wrong?
<kyrofa> vir17, indeed. Were you wanting something else?
<vir17> I use another machine to create the apps
<vir17> apps that packed with snapcraft2 could not run in the older version of snappy
<kyrofa> vir17, correct. Yeah, you want that app-snaps image then
<kyrofa> vir17, do note that a snappy update today breaks .snaps created with snapcraft though. A fix will be out soon
<vir17> ok so it is safer to stay with the older version
<vir17> and with snapcraft 1
<vir17> ??
<kyrofa> vir17, for right now yes, but we're trying to stabilize soon
<vir17> :)
<vir17> I found it easier to follow the example in the new snapcraft
<vir17> this is the reason I asked
<kyrofa> vir17, which example?
<vir17> I had installed in my system the new snapcraft
<vir17> and the examples i tried to re-create didnt work for me
<vir17> so I thought I could try the new snappy
<kyrofa> Ah, okay
<vir17> I have to understand now what is wrong with my .yaml file
<vir17> because my app doesn't appear in the /apps/bin after a successful installation
<kyrofa> Hey pindonga, if you have a minute, would you mind looking this over? https://github.com/ubuntu-core/snapcraft/pull/277
<pindonga> sure
<kyrofa> vir17, you need to refer to the examples from the right release
<kyrofa> vir17, I suggest installing the snapcraft-examples package and using those
<vir17> I just install it to a spare raspberry pi running ubuntu mate
<kyrofa> pindonga, just make sure I didn't lie in there anywhere :P
<vir17> so I will try again
<vir17> :)
<mvo_> ogra_: is my gadget snap maybe wrong? I think I just took yours but: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/dragonboard/meta/package.yaml - i.e. might this explain the off-by-one issue?
<vir17> kyrofa:  if I have both the new snapcraft and snapcraft-examples in my system, how I can choose which version of snapcraft to use to pack my app?
<vir17> is it possible?
<kyrofa> vir17, I'm afraid having them both installed isn't possible
<vir17> i will use the raspberry pi then to pack my app
<vir17> thank you :0
<vir17> :)
<kyrofa> vir17, sure :)
<pindonga> kyrofa, comments added
<pindonga> do you need to me +1 somewhere?
<kyrofa> pindonga, no, that's exactly what I needed, thank you!
<kyrofa> pindonga, actually why don't you give it a thumbs up just in an overall comment, if you don't mind
<pindonga> k
<kyrofa> Alright now that I know that it's actually correct, elopio take a look at https://github.com/ubuntu-core/snapcraft/pull/277 when you have a minute
<elopio> kyrofa: reviewed. pindonga: I left in that PR some comments about possible bugs. Could you please check if you agree?
<pindonga> already replied :)
 * pindonga checks again, just in case
<pindonga> yep, all replied to
<vir17> kyrofa: are you still there
<vir17> ?
<kyrofa> vir17, I am
<kyrofa> elopio, pindonga thanks guys :)
<elopio> cool. thanks kyrofa for all the bugs.
<vir17> do you have any clue about this error: FileExistsError: [Errno 17] File exists: '/home/vir17/Desktop/serial-test4/parts/serialdev/build'
<vir17> this is my .yaml
<vir17> http://pastebin.com/mRbXAkb2
<kyrofa> vir17, well, your YAML looks fine for Snapcraft 1.0
<kyrofa> vir17, try running `snapcraft clean` and then run `snapcraft` again
<vir17> ok
<awe_> kyrofa, is there any documentation about how to build snaps on a device running snappy?  trying to figure out the best way to build my snap so it can be run on an ripi2?
<kyrofa> awe_ not that I know of but I can walk you through it
<awe_> i *just* got the latest rolling image up & running
<kyrofa> awe_ as soon as all-snaps is a bit more stable I think we'll have docs on it
<awe_> ok
<kyrofa> awe_ first question: which version of ubuntu core are you targeting?
<awe_> the latest rolling
<kyrofa> Excellent. Then all you need to do is enabled classic with `sudo snappy enable-classic`
<awe_> i have a snap built using snapcraft 2.0
<awe_> ok
<kyrofa> awe_ that command will setup the "Classic Dimension," allowing you to use .debs
<kyrofa> awe_ once that finishes, you'll be able to apt-get install snapcraft
<awe_> ok
<kyrofa> awe_ the rest should be easy
<awe_> and then what happens when i want to test?
<awe_> does that still all work as expected?
<awe_> eg. sudo snappy install
<awe_> ...
<awe_> or do i need to disable classic mode once i've finished building?
<kyrofa> awe_ good question, I haven't actually done it
<awe_> ;)-
<kyrofa> awe_ I actually ran into a make bug when I tried this last time-- make was segfaulting
<awe_> well, good thing i bought two new sd cards
<awe_> ;D
 * awe_ crosses his fingers
<kyrofa> awe_ so I ended up installing regular-old Ubuntu on there to build
<awe_> ah, ok
<awe_> well, let's try this out first
<awe_> maybe i'll get lucky
<kyrofa> awe_ keep that in mind-- if you hit some weird make segfaulting thing, other people have too
<kyrofa> elopio, I can't remember-- did you report that somewhere?
<vir17> kyrofa: the same thing happened again
<vir17> the complete log: http://pastebin.com/dWhUT36X
<awe_> so how involved is installing regular xenial on the ripi2?
<kyrofa> awe_ I actually did trusty (I was targeting vivid so that worked for me)
<kyrofa> awe_ there was a prebuilt image on the wiki I stole
<kyrofa> awe_ not sure about xenial
<awe_> k
<awe_> we'll see how classic goes then
<vir17> to give you more info, the app i try to build is just a simple python file http://pastebin.com/XphBGzUA
<elopio> kyrofa: https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1536727
<ubottu> Launchpad bug 1536727 in make-dfsg (Ubuntu) "make crashes in xenial lxc" [High,Confirmed]
<kyrofa> elopio, oh yeah. I confirmed it :P
<kyrofa> vir17, you aren't running snapcraft twice, are you?
<kyrofa> vir17, just snapcraft clean followed by snapcraft?
<vir17> yes
<kyrofa> vir17, after snapcraft clean, can you verify that the parts directory has been removed?
<kyrofa> elopio, is a OTP prompt of "One-time password (just press enter if you don't use 2FA):" too long?
<elopio> kyrofa: it's long, but better than OTP
<elopio> kyrofa: but now you introduced the word 2fa
<vir17> kyrofa: http://pastebin.com/4hxArVaj
<kyrofa> elopio, heh, I knew you'd pick on that
<elopio> what about "if you don't use it" ? Still confusing?
<vir17> i can snapcraft clean and restart the system to be sure
<kyrofa> elopio, yeah that brings up "What's a one-time password? Well, maybe I don't use it" :P
<kyrofa> vir17, looks like it's indeed gone. Can you push your entire project somewhere so I can take a look?
<elopio> I wouldn't mind making it even longer saying two-factor authentication. But then we might be making it more confusing.
<kyrofa> elopio, hrmm... so it sounds like the only good solution is to somehow detect if it's not necessary
<kyrofa> elopio, if you agree, I'll make that a separate bug
<vir17> ok I will send you the link in 1min, thank you :)
<elopio> kyrofa: well, that's the perfect solution. We can live with less than perfect for now.
<elopio> there should be a nice way to do it, because it's how it's done on the web. You hit log in, and if you have 2fa enabled the next page asks for it.
<elopio> here instead of clicking log in, we press enter after the password.
<kyrofa> elopio, agreed. I figure if we can change the prompt to something better that would be a decent intermediate step
<sergiusens> awe_, kyrofa in case it wasn't answered; you `sudo snappy enable-classic`; then you `snappy shell classic`; in there you apt all you want; you exit the shell or from a different login `snappy install *.snap`
<kyrofa> elopio, it's the "decent" bit that's difficult
<kyrofa> sergiusens, ah, thank you!
 * elopio leaves for lunch
<vir17> kyrofa: you can check here my entire project https://github.com/lmbn/serial/tree/master
<kyrofa> vir17, ah, run `snapcraft help python2`
<kyrofa> vir17, you're not using it quite right
<kyrofa> Nooooo ubuntu bring my mouse pointer back...
<vir17> kyrofa:  make sense now, I need a lot more parts to use python
<vir17> is this the only way?
<vir17> or I can do something else to make a snappy app with just the files I already have
<vir17> i mean if I run my code straight into the terminal
<vir17> the code is working
<vir17> can I create a snappy app out of it?
<kyrofa> vir17, it works on your terminal because you already _have_ all those dependencies
<kyrofa> vir17, but they need to be put into the .snap itself
<kyrofa> vir17, make sense?
<kyrofa> Alright, reaching EOD around here
<vir17> ok so in other words I need to include dependencies for all my imports (import serial, import time, import os)
<vir17> ?
<kyrofa> vir17, yes, but snapcraft will take care of that for you if you setup the part correctly. Reference the python2 example
<vir17> i will try then :) thank you again kyrofa
<kyrofa> Sure thing :) . Have a nice evening everyone!
<vir17> you too
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/275
<sergiusens> also wouldn't mind a review from jdstrand and mvo (not connected https://github.com/ubuntu-core/snapcraft/pull/275)
<kgunn> sergiusens: hey, so reading mvo's mail about additional changes coming like icon having to be in meta/icon etc
<kgunn> is that going to be pushed onto snapcraft2.0 ?
<jdstrand> I'll add it to my todo-- I may not get to it today though
<kgunn> or later....like a 3.0
<sergiusens> kgunn, it is already in snapcraft
<sergiusens> kgunn, but that is internal formatting
<jdstrand> I can also review after the fact. I quickly perused it and see you added the 4 directives under the migration-skill, which is good
<sergiusens> kgunn, from a snapcraft perspective you still do icon: path-to-icon
<kgunn> sergiusens: ah
<sergiusens> kgunn, and snapcraft puts everything in the right place
 * kgunn likes it when things get put in the right place magically
<awe_> thanks sergiusens!  it actually worked.  still need some tweaks to the snap to get things functional, but good progress!
<sergiusens> awe_, nice!
<noizer> Hi guys just a question the doc on de developer.ubuntu website is that for snapcraft 2.0 kyrofa
<noizer> kyrofa it is snapcraft 2.0 syntax on the dev site of ubuntu?
#snappy 2016-01-29
<wxl> hey folks can someone tell me how to generate an i386 image with ubuntu-device-flash? no matter what i do, i can't get it to wor
<wxl> k
<wxl> i'm trying sudo ubuntu-device-flash core 15.04 -o my-snappy.img --device generic_i386 --channel edge --enable-ssh
<wxl> i get a warning that "this option" should only be used to build azure images
<wxl> and then it starts downloading a generic-amd64
<wxl> and then says it failed to install (but i'm not trying to install it)
<fgimenez> good morning
<dholbach> good morning
<diwic> good morning!
<diwic> new day, new snappy questions :-)
<diwic> I'm wondering about XDG_RUNTIME_DIR - PulseAudio expects to be able to write to that directory. It currently points to /run/user/1000 where the snap cannot write.
<diwic> Should we 1) point XDG_RUNTIME_DIR to somewhere inside /snap/pulseaudio/current/ or 2) add some rule that allows PA to write to /run/user/1000 ?
<noizer> kyrofa is that the correct link to download the ubuntu 16.04 for Raspberry pi
<JamesTait> Good morning all!  Happy Friday, and happy Fun At Work Day! ð
<mvo> hey JamesTait, good morning! It looks like I missed some messages yesterday, anything important that I should reply to now .) ?
<JamesTait> Good morning, mvo!  I don't think there's any action on you at the moment.  I'm just cleaning up my branch and jd-strand is working on the click-reviewers-tools part.
<devil_> hi, can somebody clarify for me, if Snappy Personal is still happening?
<noizer> Hi i have a question for what should I use Docker on my snappy?
<mvo> JamesTait: cool, thanks
<noizer> Is it good for things like UWSGI and Nginx?
<ogra_> mvo, your gadget snap looks fine but i think something changed the order how/when partitions are created
<ogra_> mvo, what my code does it to append all partitions to the created image ... you have three partitions and left a gap at the start ... i append 4,5,6,7,8,9,10 (this is in partition numbering though, pyhsically they would be 1,2,3,4... and then tell sgdisk to sort the numbering by position in the end which should align the numbering to the physical position
<mvo> ogra_: oh, the new image has less partitions, its just boot and writable, no more a/b.
<ogra_> mvo, somehow "boot" with u-boot.img ends up at the last physical position now
<mvo> ogra_: what positition should this have?
<ogra_> the number shouldnt matter though
<ogra_> i pick up the last one and add +1
<mvo> ogra_: ok, let me look at this code again, maybe I get an idea
<ogra_> "boot" should be after "aboot" http://paste.ubuntu.com/14694737/
<ogra_> the u-boot binary currently expects top find its env on p8
<ogra_> mvo, the wrong position isnt the big issue here, it would still boot (though couldnt resize anymore due to writable not being at the end)
<ogra_> well, the wrong position of "boot" isnt the blocker
<ogra_> its still an issue :)
<mvo> ogra_: what is the blocker? the kernel?
<ogra_> mvo, no, the uboot binary is broken .... wheere did you get it ?
<ogra_> (if i dd mine in place i get a proper uboot shell)
<ogra_> heh, well, and yeah, the kernel too :P
 * ogra_ isnt awake yet
<ogra_> we need to fix all three
<mvo> ogra_: I thought I had it from your dragonboard oem snap, let me double check
<ogra_> well, if it is the same binary then something in the way it is written to disk is broken
<ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps$ md5sum ../oem-snap/snap/u-boot.img
<ogra_> aad77edcce10781ace7df4d4a104c891  ../oem-snap/snap/u-boot.img
<mvo> ogra_: I thikn its out of http://people.canonical.com/~ogra/snappy/dragonboard/dragonboard_0.1_all.snap
<ogra_> thats the md5 here
<mvo> ogra_: but let me check
<mvo> eh, sorry
<mvo> no, the right snap
<mvo> ogra_: md5 matches
<ogra_> then the way it gets written broke it i guess
<ogra_> cant imagine anything else
<mvo> ogra_: offset is correct? 3179520 ?
<ogra_> 3179520
<ogra_> yeah
<ogra_> the type GUID is also correct ... but the little kernel complains and stops the boot in the default image
<ogra_> as soon as i dd mine it boots fine (to the point where it cant find the uboot.env on partition 8)
<mvo> ogra_: ok, I look at u-d-f now. what is the correct kernel url?
<ogra_> let me check, ppisati said he has a new deb
<ogra_> https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.2.0-2009-generic-dragon410c_4.2.0-2009.9~15.10_arm64.deb
<ogra_> mvo, oh, but that needs another dtb (needs changing in package.yaml of the gadget and uboot.env)
<asac> mvo: lool: how is producing OS-type initrd going?
<asac> (good day :))
<mvo> asac: not at all on my side, busy with 4234324 other things :/
<ogra_> mvo, the dtb we need it apq8016-sbc
<ogra_> asac, mvo i'll do that
<ogra_> its essentially just copying the build script from the phone initrd package into the core one
<asac> great... i guess for now i would need a one off OS snap with such kernel-less initrd
<asac> cool
<ogra_> asac, i just want to get that dragonboard image to run first if possible
<asac> once we have that i think i can start poking on x86 with some help on how to hack grub bootconf
<asac> sure take your time
<ogra_> mvo, hmm, could it be that you made the gap at the start of the disk smaller when you dropped the 4th partition in u-d-f ?
<ogra_> that would explain why boot gets appended at the end
<ogra_> hmm, but looking at the numbers there seems to be enough space
<mvo> ogra_: with sudo DEBUG_DISK=1 i see http://paste.ubuntu.com/14694839/ which looks like the partitions are initialized in hte right order, the sorting looks suspicious
<ogra_> well, the sorting should just align the numbering with physical position
<ogra_> you would have tzo break before the sorting and check the image with sgdisk to see where they physically are
<ogra_> but i'm pretty sure boot is at the end already
<ogra_> i wonder if it would complain if there is already a boot partition ... could it be that you created it already when this runs ?
<mvo> ogra_: yeah, its all a bit myserious - just to double check what it should look like: *first* the rawPartitions and then ours? or *first* ours and then the raw ones?
<ogra_> mvo, how about a quick HO
<LefterisJP> hey guys if I want to have a python binary using PyYaml available in my pass what's the right way to go about it using snapcraft?
<LefterisJP> I have this:   mybinary:
<LefterisJP>     plugin: python2
<LefterisJP>     python-packages:
<LefterisJP>       - PyYAML
<LefterisJP> But where should I specify that this is only to be used by a simple python file which should go to the bin/ directory of the final snap?
<LefterisJP> It seems that the source attribute would expect a directory
<noizer> ogra_ for wat should i use docker on snappy?
<noizer> ogra_ or what is meant to be used?
<ogra_> mvo, the final order needs to be: all gadget partitions -> system-boot -> writable .... the creation order differs though
<ogra_> noizer, for whatever you like
<mvo> ogra_: sure, HO is fine.  so what ensures the final order?
<ogra_> i mean ... obviously for running apps in containers :)
<ogra_> mvo, the physical position ... that is what the sgdisk sorting uses afaik
<noizer> ogra_ but snaps ar already containered but for what is there than an advantage to use docker?
<ogra_> mvo, https://plus.google.com/hangouts/_/canonical.com/gadget
<ogra_> noizer, dunno, even more containment ?
<noizer> ogra_ ok
<noizer> :D
<noizer> ogra_ so when im making a docker vm on an other ubuntu then it can be ran on snappy?
<noizer> so its then mutch easier to port to other linux distro's?
<noizer> ogra_ how can i install snapcraft 2.0 on a raspberry pi
<ogra_> noizer, in xenial images you can enable the classic dimension and use a container
<noizer> Will it work on a Ubuntu Mate 16.04 ogra_
<noizer> ?
<ogra_> sure
<ogra_> but why not use it on your snappy directly ?
<noizer> hmmm but how can i develop easily on snappy?
<ogra_> read above
<ogra_> <ogra_> noizer, in xenial images you can enable the classic dimension and use a container
<noizer> Ok such as an user interface?
<noizer> or istn't that it?
<ogra_> sudo snappy enable-classic
<noizer> ok i will try it
<ogra_> ... that will create the container ...
<kyrofa> Good morning
<noizer> ok i will have a look
<noizer> OK i did that but what are the concrete difference between that oter?
<noizer> *other
<ogra_> noizer, so if you now run "snappy shell classic" you are in a normal ubuntu 16.04 and can use apt to install snapcraft and build your packages
<ogra_> noise][, the advantage is that this container is fully based on the readonly snappy rootfs, it only extends it by the missing pieces to get a normal apt based ubuntu
<ogra_> err
<ogra_> sorry
<ogra_> (didnt notice he left)
<sergiusens> good morning
<kyrofa> Morning sergiusens :)
<Lefteris`> morning
<ogra_> moin
<Lefteris`> hey guys how can I have a simple python binary which depends on a pypi package with snapcraft? The python plugin seems to expect you to give a directory and build a whole package.
<kyrofa> Lefteris`, I'm not super familiar with python packaging, but is that something you can use requirements.txt for?
<sergiusens> kyrofa, oh, git guy :-) Heeeeello
<kyrofa> sergiusens, what's up?
<sergiusens> kyrofa, how do you think this will merge https://github.com/ubuntu-core/snapcraft/pull/273 ?
<kyrofa> sergiusens, looks fine to me. Are you concerned because it's not rebased?
<sergiusens> kyrofa, nah, just wondering what will happen to the first commit which is already in master
<kyrofa> sergiusens, oh, I didn't notice that
<kyrofa> sergiusens, so he built this feature on another, eh?
<kyrofa> sergiusens, my initial reaction is to expect a conflict. But github isn't whining about it
<didrocks> it's the same commit id
<didrocks> so no conflict, it will be like if he forked later on
<didrocks> (basically, on the graph, there will be 2 "merges commit" with just one branch alongside)
<Lefteris`> kyrofa: I have a simply .py file that I want to be executable and part of my snap and depends on PyYaml. Any idea what's the best way to achieve this? From what I see in snapcraft, both requirements.txt and python-packages in yaml will work. Adding the dependency is not my problem. My problem is how to specify that my python file should be what I want as the final binary and depending on PyYaml.
<Lefteris`> I got this:   configurator:
<Lefteris`>     plugin: python2
<Lefteris`>     python-packages:
<Lefteris`>       - PyYAML
<Lefteris`> If I add the location of my python file as source then it says it expects a directory. So I assume it expects me to have a custom made python package with a setup.py as the source attribute. Can't I just give a simple python script in some way?
<sergiusens> didrocks, so if he would have created the PR in the future, it would only be one id?
 * sergiusens will just hit merge
<didrocks> sergiusens: exactly!
<kyrofa> sergiusens, indeed, tested locally as well
<kyrofa> Thanks didrocks :)
<didrocks> yw ;)
<sergiusens> didrocks, kyrofa seems to just be a presentation problem I guess
<sergiusens> well, I consider it a presentation problem, others might not ;-)
<kyrofa> sergiusens, yeah, I wish github would update
<sergiusens> or just tell me it is already in master, it is so smart about everything else :-P
<didrocks> yeah, github doesn't "refresh" the list of commits not included in master
<didrocks> it should IMHO, if the hash matches
<kyrofa> didrocks, nor the diff
<kyrofa> didrocks, agreed
<sergiusens> mvo, btw, mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/278
<kyrofa> didrocks, I see that change happening twice and my first conclusion is "conflict"
<didrocks> (but then, you need to ensure that the hash order is the same)
<sergiusens> kyrofa, but same id
<sergiusens> right
<didrocks> disclaimer: I'm probably lagging as being on 4G (in the TGV to Brussels)
<kyrofa> Lefteris`, sorry, I'm not ignoring you :)
<didrocks> you know, even if the hash is different, but the diff is the same, git is smart enough to do a silent reconciliation
<didrocks> (but then, you have an additional commit)
<kyrofa> didrocks, but the additional commit is gross :P
<didrocks> heh, yeah ;)
<kyrofa> Lefteris`, I think you need two parts here
<kyrofa> Lefteris`, one part that uses the python2 plugin and the requirements.txt, and another part that uses the copy plugin to put your script in the right place
<kyrofa> Lefteris`, then declare your script as the binary
<kyrofa> Lefteris`, make sense?
<Lefteris`> kyrofa: yeah it does make sense, and this is what I was doing right now, but seems kind of dirty
<Lefteris`> would be nice if we the python plugin could allow you to do that withou involving the copy plugin
<kyrofa> Lefteris`, yeah it's kinda made for a project with a setup.py or something
<kyrofa> Lefteris`, would that be easier? Have the setup.py install your script?
<diwic> Ok, I need pulseaudio to access /run/udev in order to scan for sound cards. I was trying by adding "security-overrides: read-paths: [/run/udev]" but it looks like this is not working, and that the feature might not even be implemented...?
<kyrofa> Lefteris`, otherwise, if we added the ability to place random scripts wherever, we just duplicated the copy plugin :P
<Lefteris`> kyrofa: hmmm maybe the copy plugin would make more sense, don't want to have separate directory and setup.py for no reason
<kyrofa> diwic, I think it's just security-override (singular)
<Lefteris`> let me try it out :D
<sergiusens> kyrofa, did you already fix this https://bugs.launchpad.net/snapcraft/+bug/1539247 ?
<ubottu> Launchpad bug 1539247 in Snapcraft "Snapcraft should support using the staging server in a developer-friendly way" [Undecided,New]
<kyrofa> sergiusens, no. That reflects the current state
<sergiusens> kyrofa, great, I wish it were automatic
<sergiusens> didrocks, what was the tool jono showed?
<diwic> kyrofa, right. It was right in the snap, I just made a typo on IRC
<sergiusens> the trello but for github
<kyrofa> sergiusens, it should be! Let's write a launchpad script and plug it into travis
<kyrofa> diwic, oh darn :P
<kyrofa> diwic, but I know read-paths works, since we have an example for it
<didrocks> sergiusens: ah, one sec, looking in my history
<kyrofa> diwic, https://github.com/ubuntu-core/snapcraft/blob/master/examples/mosquitto/snapcraft.yaml
<diwic> kyrofa, okay - how does wildcards work here? If I do /run/udev, does that include /run/udev/dir1/dir2/file3 ?
<kyrofa> diwic, no I don't believe so
<Lefteris`> sergiusens: could it be https://waffle.io/ ?
<kyrofa> diwic, you need some asterisks
<kyrofa> diwic, it's apparmor
<Lefteris`> This is what comes to my mind when I think of "trello for github"
<diwic> kyrofa, hmm, so if I want to give read access to /run/udev and everything below that?
<didrocks> sergiusens: yeah, it's waffle.io
<kyrofa> diwic, /run/udev/** I _think_
<didrocks> thanks Lefteris` :)
<diwic> kyrofa, thanks, will try
<kyrofa> sergiusens, or... you know... we could just use gitub
<kyrofa> Or even github
<diwic> kyrofa, and now that I've changed that, can I just write "stage" to parts/pulseaudio/state to avoid a full rebuild of PulseAudio ?
<diwic> or is there some smarter way?
<kyrofa> diwic, so you've completely build a .snap, and all you've changed is the YAML?
<sergiusens> kyrofa, with waffle.io ;-)
<kyrofa> sergiusens, oh... yeah that would be epic
<diwic> kyrofa, yes, I've just changed /run/udev to /run/udev/** in snapcraft.yaml
<kyrofa> sergiusens, although then my LP karma would start dropping
<kyrofa> sergiusens, what is the best solution in Snapcraft 2 for diwic's problem without --force?
<kyrofa> sergiusens, also, I vote we use waffle.io just because of firefly now
<kyrofa> diwic, trying to run build again won't hurt anything, but I imagine it will probably say "already built"
<sergiusens> kyrofa, edit the parts/<part-name>/state file I guess
<kyrofa> diwic, in which case you can at the very lease edit the... yeah
<kyrofa> diwic, open the parts/<part>/state file and change the state to "build" and run snapcraft snap again
<kyrofa> diwic, we're currently working on a --force option that will do that for you, but we're still in the design phase
<diwic> kyrofa, right, that's what I thought
<noizer> kyrofa and orga_ where can I find more information about the classic dimension or what is is the difference with the normal snappy?
<diwic> kyrofa, actually, I don't think I need to do that. Just running "snapcraft snap" will update snap/meta/*.yaml accordingly
<kyrofa> diwic, ah! Good catch!
<kyrofa> diwic, you just hit the special case of only modifying the YAML that gets directly copied to other YAML :P
<diwic> kyrofa, next question. How do I allow it to talk to the system dbus?
<sergiusens> kyrofa, are you getting rid of the roscore plugin today?
<diwic> I expect bluetoothd to be there, so can't do bluetooth audio without it
<kyrofa> diwic, last I knew that needed custom security policies... I'm honestly not sure how one is supposed to do that in 16.04. sergiusens?
<kyrofa> sergiusens, no I'm still on the store stuff. Why, you really want it gone eh?
<kyrofa> :P
<sergiusens> kyrofa, yeah, remove the qml one while at it ;-)
<kyrofa> sergiusens, I can do that. No replacement?
<kyrofa> sergiusens, bad enough to pause the store stuff for a little bit?
<sergiusens> diwic, I will invoke tyhicks if you need either a security-policy, security-template or security-override
<sergiusens> kyrofa, nah
<kyrofa> sergiusens, next task then, you got it :)
<diwic> thanks. I'll double check with awe when he gets online to make sure bluetoothd is where it's supposed to be
<sergiusens> kyrofa, just roscore, the qml thing is political at this point :-P
<kyrofa> sergiusens, hahaha
<sergiusens> kyrofa, it even depends on something we don't have
<kyrofa> sergiusens, that sounds problematic
<kyrofa> sergiusens, oh, mir?
<sergiusens> kyrofa, yeah ;-)
<kyrofa> sergiusens, duh
<noizer> ogra_ about the classic how can we see it in snappy
<kyrofa> sergiusens, yeah I agree with you though. The presence of the plugin indicates first-class support
<kyrofa> And... it's not
<ogra_> <ogra_> noizer, the advantage is that this container is fully based on the readonly snappy rootfs, it only extends it by the missing pieces to get a normal apt based ubuntu
<ogra_> you left to early :=
<ogra_> :)
<ogra_> noizer, just use "snappy shell classic"
<kyrofa> sergiusens, if a dev needs it they can include it in-tree
<ogra_> then you can spt-get update and apt-get install snapcraft and use it there
<ogra_> *apt-get
<kyrofa> sergiusens, anyway, let me know
<noizer> ogra_ ok then can i get there than an User interface so I can develop faster?
<ogra_> user interface ?
<ogra_> it gives you a place to build your snaps in
<noizer> ogra_ hmmm I now developing on lubuntu for Raspberry Pi but now i want to install it on snappy but how can i do that the easiest way
<ogra_> oh, you dont have a PC to work with ?
<sergiusens> command line user interfaces ftw :-)
<ogra_> :D
<noizer> ogra_ hahah ok thats hard then but can i develop on my lubuntu en scp it to the classic ubuntu
<ogra_> i usually develop in a bzr branch ... so i can push from the PC, pull from classic and then just run snapcraft snap, install and test the package
<ogra_> (such a process makes you automatically backup your code too :) )
<kyrofa> ogra_, and results in this https://xkcd.com/1296/
<ogra_> (indeed, if you prefer git thats the same )
<noizer> i uses git :p ok intresting but to make the yaml for the software thats a hard part i think
<ogra_> kyrofa, lol, yeah
<ogra_> making the yaml for the first time is hard ... but having a pretty giu around your editor wont change that ;)
<kyrofa> You'll get the hang of it noizer !
<ogra_> yeah
 * ogra_ hated yaml in the beginning .... after getting used to it i actually like it a lot
<noizer> hah thats a fact kyrofa ogra_
<noizer> ok i will try to push it to my ubuntu classic
<noizer> and hopefully it will work
<noizer> for snapcraft installation is it sudo apt-get install snapcraft
<noizer> but when i type it it fails
<noizer> should i need to add the ppa,
<noizer> ?
<kyrofa> noizer, how does it fail?
<noizer> kyrofa http://pastebin.com/KVNjkVnE
<kyrofa> noizer, do `sudo apt-get update` first
<diwic> btw. Can I change the contents of either one of the wrap scripts somehow? I e, to be able to start pulseaudio with some switches (such as --path-to-something=/snaps/pulseaudio/weirdcharacters/somewhere) ?
<diwic> or to set an environment variable
<kyrofa> diwic, you can pass those things in the binary/service exec line
<asac> sergiusens: so got a good idea how to make a nice global parallel and verbose option available? maybe just hook those to the top level main.py somehow?
<kyrofa> diwic, in the YAML
<diwic> kyrofa, but at that point I don't know the "weird characters"
<kyrofa> diwic, remember the environment variables though-- don't hard-code /snaps/etc.
<asac> e.g. not in build.py
<kyrofa> diwic, ah, you don't know the environment variables then!
<kyrofa> diwic, double-check-- you're on rolling?
<kyrofa> diwic, oh, /snaps, yes you are
<diwic> kyrofa, I am on 16.04. Say that I want to add one environment variable, e g XDG_RUNTIME_DIR=$SNAP/tmp/somedir
<kyrofa> diwic, so you can use the $SNAP environment variable, which will point to the /snaps/pulseaudio/version
<kyrofa> diwic, yeah, just put it on the command line like you would in the shell
<diwic> kyrofa, ok, so that will end up being a long line I expect, but that's ok :-9
<diwic> :-)
<kyrofa> diwic, the alternative is to write a shell script to be your binary instead, which is perfectly acceptable if you prefer it
<diwic> just three wrappers to start the executable ;-)
<kyrofa> diwic, welcome to Snapcraft. We wrap your wrappers so we can wrap them
<ogra_> its like christmas and your birthday at once !
<asac> sergiusens: think i would keep the getter/setter parts for those flags in common.py and just drop the build.py parts from my cleaned patches... in that way you can land the CLI wiring later. soudns good?
 * diwic renames it to wrapcraft
<asac> ppisati: where can i find the definite list of minimal patches and config flags that are super essential for a runnign snappy system?
<asac> "minimal and super essential"
<asac> lol
<ogra_> asac, no idea how recent that is http://people.canonical.com/~ppisati/snappy_config/#
<ogra_> asac, and wrt pathes ... "the latest apparmor" is a rule of thumb
<ogra_> *patches
<ppisati> asac: kernel version?
<asac> ppisati: 4.4?
<asac> or if we have a lookup table for each main version that would be nicer even
<asac> the latest apparmor is vague
<sergiusens> asac, making it global is easy
<noizer> ogra_ sorry for the many question but how do I instal it best NGinx and UWSGI?
<asac> for someone coming from outside
<asac> sergiusens: ok with you if i move it to main.py from build.py? think those flags could also be honoured by some other lifecycle rules
<asac> not all of course
<asac> buut install maybe could pick it up for some plugins
<asac> or even pull :)\
<kyrofa> sergiusens, did you annotate the 2.0.1 tag?
<ogra_> noizer, for what exactly ?
<ogra_> *for doing
<noizer> for running a webpage
<diwic> kyrofa, jftr, you can't put things like "XDG_RUNTIME_DIR=$SNAP/tmp pulseaudio" as your binary, "snapcraft snap" will fail with "file not found: XDG_RUNTIME_DIR=$SNAP/tmp"
<sergiusens> kyrofa, yes
<noizer> my snap exist about html page and some backend modules etc
<sergiusens> kyrofa, oh, annotate, no https://github.com/ubuntu-core/snapcraft/tags
<noizer> and running with flask ogra_
<vir17> hi guys, i need help for a .yaml file, after the yesterday failures I try today to create a simple first app (a python helloworld)  my code is here: https://github.com/lmbn/hellosnappy   and my .yaml file http://pastebin.com/j2hpwDri , what I dont know is what I have to add in my .yaml file so after the installation to have my app into "apps/bin" and run it  (sorry for the newbie question)
<ogra_> noizer, well, create a snapcraft.yaml that builds ngnix from source or use the copy plugin and ngnix as stage package to grab the deb binary (but then you might need to adjust the config to match all the changed paths)
<sergiusens> if it is just a webpage, write a simple server with go
<kyrofa> diwic, ah, right, I'm sorry I misled you! You'll have to create a wrapper script, then
<noizer> ogra_ sergiusens its not a simple webpage :s
<ogra_> noizer, right, what sergiusens said ... there is even an example webserver (in 5 lines or so)
<sergiusens> noizer, you said html, I replied in response to that ;-)
 * sergiusens goes for a quick run
<kyrofa> vir17, you need to specify `binaries` there somewhere
<noizer> sergiusens ok sorry :p
<kyrofa> vir17, like this: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/py2-project/snapcraft.yaml#L4
<noizer> ok i will try now to make my yaml file
<kyrofa> sergiusens, I need to babysit for a bit this morning, I'm afraid I need to miss standup, I'm sorry!
<diwic> kyrofa, actually XDG_RUNTIME_DIR is perhaps a bigger question; should we set that by default to something inside the snap or user? It seems reasonable for it to point to something writable by default IMO.
<ogra_> diwic, i think ted brought that up before .... thgere was a discussion somewhere
<ogra_> tedg i mean
<sergiusens> kyrofa, elopio let's just cancel and do the planning then
<kyrofa> sergiusens, okay, sounds good
<kyrofa> sergiusens, go for your run :)
<kyrofa> diwic, probably user-specific, so I suggest SNAP_USER_DATA
<diwic> ogra_, ok; I'm going to try to work around it for the time being, if you're aware that there's an issue
<ogra_> not on the level we have worked on yet .... i am awarwe it will be an issue in graphical envs and desktop context
<diwic> ok
<ogra_> IoT and server ... not so much
<ogra_> lets ask tedg once he is around what came out of that discussion
<ogra_> i know he started one
<mvo> ogra_: I think I know now now what is going on with sgdisk, when you tell it to create a partition with num 0 and start 0 it will find the first free partition and then looks for the first available sector in the largest free area on disk. this happens to be (by pure chance) that part *after* writable once we reach partition 7 :) so mystery solved, I will add the offset and we need to continue with that and force sgdisk to write to the numbers we
<mvo>  give it
<mvo> ogra_: that was hard work!
<ogra_> mvo, it was ! thanks so muchj !
<vir17> thanks kyrofa  i will try
<olli> hey ogra_, did you have a chance to work on that Pi2 bug for ectors?
<ogra_> olli, i worked on getting the dragonboard images ready, Pi2 firmware update is on my list
<ogra_> (i guess they are eaqually important :) )
<mvo> ogra_: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz should have the right layout now
<mvo> ogra_: would be nice to know if uboot is still broken
<ogra_> mvo, pulling now
<mvo> \o/
<olli> ogra_, thx!
<ogra_> mvo, u-boot still broken :/
<ogra_> mvo, eeek
<ogra_> and all bootloader partitions now have an x appended to the name
<mvo> ogra_: uff
<ogra_> gimme a sec ... the u-boot issue might actually be the naming issue
<ogra_> dding my uboot in place didnt work either until i dropped the x from bootx in the partition name
<ogra_> i'm just re-flashing from scratch to see if just fixing the name helps
<mvo> ogra_: wait, let me make a new image
 * ogra_ wants faster dd !!!
<mvo> ogra_: godd!
<mvo> ogra_: and a scandisk extreme
<ogra_> well, that wont make faster bytes i gues :)
<mvo> ogra_: let me make a new image
<ogra_> *guess
<mvo> ogra_: sure it will ;)
<mvo> ogra_: ok, maybe not, but *progressbar*
<ogra_> \o/
<ogra_> fixing the name is enough
<ogra_> bah
<ogra_> but i end up in an initrd shell now
<mvo> ogra_: oh, but the kernel boots? that is the wrong kernel :)
<ogra_> insmod: can't read './lib/modules/*/kernel/fs/squashfs/squashfs.ko': No such file or directory
<mvo> ogra_: still the old one from your dir, not the kernel from pablo
<ogra_> ah, i thought you used the arm64 one frrom the archive
<ogra_> mine should boot, but has obviously no squashfs enabled :)
<mvo> ogra_: I'm slow
<ogra_> so lets switch to paolos latest kernel and we should be golden
<ogra_> this looks very good already :D
<mvo> ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/20 is the new syntax, if you give the raw-partition a "pos" paramter it will put it there and all following right behind (unless you use pos again)
<mvo> ogra_: sweet, I will update the kernel snap next
<ogra_> mvo, but pos isnt required for all of them ? thats good then
<ogra_> mvo, dont forget you need to switcch to the other dtb
<ogra_> mvo, "apq8016-sbc"
<mvo> ogra_: yeah, pos is only needed for the first one if they are all aligned
<ogra_> great
<kyrofa> Chipaca, do you have any favorite python3 progress indicator libs? Or do you typically roll your own?
<sergiusens> kyrofa, if you pick the right implementation/module you don't need to worry about vte/vt sizes
<kyrofa> sergiusens, yeah that's exactly my concern
<kyrofa> sergiusens, researching options
<sergiusens> mvo, what was the pbar used for snappy when it was python?
<mvo> sergiusens: let me look
<mvo> sergiusens: and also look at your branch, sorry, full day
<mvo> sergiusens: I think it was a nice progress bar
<sergiusens> mvo, or point me to the sources, I can't find them; yeah iirc barry helped out on that so I guess it has good qa too :-)
<sergiusens> and indeed it worked nicely
<sergiusens> kyrofa, and this is for you http://whatthecommit.com/
<tedg> ogra_: I never got anywhere with it, replied on the mailing list, to silence.
<kyrofa> sergiusens, hahaha, awesome
<ogra_> tedg, well, now you have a companion in diwic :) perhaps you can revive the thread
<tedg> diwic: You should reply, see if you can get responses. :-)
<tedg> diwic: If you do, I have a bunch of other questions you can ask.
<mvo> sergiusens: I think it was python3-progressbar but I can't find the old python source right now :/ let me look harder
<mvo> sergiusens: yeah, python3-progressbar it is
<sergiusens> mvo, great, thanks
<sergiusens> mvo, do you have links to the old code anywhere btw?
<sergiusens> kyrofa, python3-progressbar
<kyrofa> sergiusens, I've read that SIGWINCH throws it off
<kyrofa> sergiusens, but I'm playing with it now
<mvo> sergiusens: I think it was mostly a frontend for click back in the day, here is the acquire bits https://code.launchpad.net/~mvo/click/progressmeter/+merge/243498
<mvo> are
<diwic> tedg, what mailing list
<diwic> ?
<tedg> diwic: I think that conversation was on snappy-devel
<diwic> ok
<mvo> ogra_: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz has an updated kernel now
<ogra_> pulling
<noizer> ogra_ can I scp it to the classic ubuntu?
<ogra_> it ?
<noizer> ogra_ some files
<ogra_> (and i dont know, you can surely scp from inside the classic container)
<ogra_> (or wget or whatever to pull stuff from somewhere remote)
<noizer> ok xD
<ogra_> reading canonical-dragon-linux.sideload_ILPMLfIRBYVH.snap/dtbs/msm8916-mtp.dtb
<ogra_> ** Unable to read file canonical-dragon-linux.sideload_ILPMLfIRBYVH.snap/dtbs/msm8916-mtp.dtb **
<ogra_> mvo, ^^^^
<ogra_> it needs a name change in the gadget/oem snap too
<mvo> ogra_: oh, yeah, I knew there was soemthing else
 * ogra_ adjusts the env manually
<wxl> where can i get the latest ubuntu-device-flash for trusty?
<ogra_> mvo, bah, that kernel is broken
<ogra_> ppisati, ^^^^
<ogra_> [    6.029908] mmc1: error -110 whilst initialising SD card
<ogra_> [    6.135706] mmc1: Reset 0x1 never completed.
<ogra_> hangs hard here
<ppisati> ogra_: which one did you use?
<ogra_> https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.2.0-2009-generic-dragon410c_4.2.0-2009.9~15.10_arm64.deb
<ogra_> the one you linked from your last mail
<ppisati> ogra_: ah, but that's bad & broken
<ogra_> ppisati, not in my kernel buiolds
<ogra_> oh, you mean that binary :)
<ogra_> yeah, obviously :)
<mvo> is there a right one somewhere?
<ogra_> mvo, well, given ppisati said it was uploaded i'd guess there is something in xenial-proposed we could fish out ?
<ogra_> (but likely also missing squashfs until paolo lands that change)
<mvo> ogra_: thats ok
<ppisati> https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.2.0-2011-generic-dragon410c_4.2.0-2011.11_arm64.deb
<ogra_> there you go :)
<ppisati> ogra_: in the archive is
<ppisati> linux-snapdragon
<mvo> ppisati: ta
<ogra_> mvo, we are >< *that* close :)
<ppisati> if you want i have a deb image too
<vir17> guys how can I fix this error: [Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'
<ppisati> http://people.canonical.com/~ppisati/ubuntu_embedded/ubuntu-embedded-16.04-dragon410c.img.xz
<vir17> ^^at snappy
 * ogra_ needs some food ... brb
<davmor2> snappy get ogra_ food......did it work?
<ogra_> Error: "get" no such command
<wxl> where would i file a bug against the snappy-dev ppa version of ubuntu-device-flash?
<ogra_> just file it in general and mention the ppa version you use
<wxl> k thx ogra_
<ogra_> whats the issue ?
<wxl> ogra_: can't build a generic_i386 image
<ogra_> hmm, not sure you can at all
<wxl> ogra_: is that new?
<ogra_> i386 isnt actually in focus
<wxl> i thought it was part of edge
<ogra_> well, we never tested it
<wxl> and for that matter that developer portal mentions using ubuntu-device-flash to get an i386 image
<ogra_> an i doubt anyone has it on the plan to test/try it at all
<wxl> it seems to suggest it's a supported possibility
<wxl> then i guess we should file a bug against the developer portal, hm?
<davmor2> ogra_: just remove the documentation bug fixed ;)
<ogra_> well, does your arch not support 46bit ?
<ogra_> err
<ogra_> 64
<wxl> ogra_: i have some machines that are i386 only, so i'd like to do some testing
<ogra_> davmor2, yeah, i guess thats in order unless we want to start doing i386 ...
<ogra_> up to now i386 hasnt been among the released and tested arches
<wxl> your buggy "code" is here in the first bullet point https://developer.ubuntu.com/en/snappy/start/#try-x86
<wxl> should you decide instead to support i386, let me know XD
<ogra_> well, we might "support" it, ... as in ... we do build the parts to assemble something ... but it definitely isnt in the list of tested or released arches
<mvo> ogra_: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz has an even more updated kernel now plus new dtb
<ogra_> ok.gimme a bit to finish eating
<mvo> sure
<kyrofa> sergiusens, how would you feel about handling a keyboard interrupt a bit nicer?
<noizer> ogra_ Hi i was testing snapcraft 2.0 but i tried to make a snap but it didn't work i typed just like in snapcraft 1.0 just snapcraft. but thats not the way anymore to make a snap
<kyrofa> noizer, `snapcraft snap`
<noizer> ok thx a lot
<sergiusens> kyrofa, I wouldn't mind
<kyrofa> sergiusens, I dunno... I feel like it might look a little more "polished"
<sergiusens> kyrofa, oh, I said yes, change ;-)
<kyrofa> sergiusens, hahaha
<sergiusens> kyrofa, 'cancelled by user input' or something; maybe with smarts later on to rollback to a last known good state
<kyrofa> sergiusens, okay :)
<kyrofa> sergiusens, agreed
<sergiusens> but the latter for later, we don't have the smarts for that
<elopio> fgimenez: https://github.com/go-check/check/pull/76
<ogra_> mvo, nope
<ogra_> ** Unable to read file canonical-dragon-linux.sideload_ILPOPIVJLVGO.snap/dtbs/msm8916-mtp.dtb **
<ogra_> reading canonical-dragon-linux.sideload_ILPOPIVJLVGO.snap/initrd.img
<elopio> fgimenez: sorry, one of your reviews was a push I did wrong. You were asking there for the logger tests. This is fully covered in run_tests.
<ogra_> mvo, seems it still uses the old uboot.env
<elopio> once we move the logger out of check.go, we can add lower level tests specific to that package.
 * ogra_ fixes by hand again
<ogra_> mvo, and smae kernel bug :(((
<ogra_> [    6.333797] mmc1: error -110 whilst initialising SD card
<ogra_> [    6.439615] mmc1: Reset 0x1 never completed.
<ogra_> and now paolo is gone ... :/
<mvo> ogra_: *gar* mkenv was missing, I updated the .in but not the .env
<ogra_> mvo, well, the kernel is broken anyway
<mvo> ogra_: hrm, hrm, ok
<ogra_> paolo has a img at people.canonical.com/~ppisati/ubuntu_embedded/ubuntu-embedded-16.04-dragon410c.img.xz i'll take a look if i can steal something from that
<ogra_> he said it would work
<ogra_> else i'mm just rebuild my own kernel with SQUASHFS=Y
<ogra_> *i'll
<ogra_> oh, wait, that could be a dtb issue ... i remember i had to fix something
<mvo> ogra_: a dtb issue in what way?
<ogra_> in that the SD controller was only initialized half
<mvo> ogra_: ok, I'm away for some minutes but if you have something, please ping me via tg
<ogra_> will do
<mvo> JamesTait: just curious what the state of the snap.yaml support is, sorry for naging
<ogra_> mvo, http://paste.ubuntu.com/14696129/
<JamesTait> mvo, it's landed in SCA trunk (within the last hour), should be on Staging for me to QA; after that, just needs the work in click-reviewers-tools.
<mvo> ogra_: oh, with that it works?
<ogra_> mvo, yeah, it should ... i'll try to just use my dtb, not sure how much it its tied to the kernel version
<JamesTait> mvo, jd-strand was looking at that, but he's off today, so it might not happen until Monday - it doesn't appear to be in the changelog for c-r-t trunk at least.
<mvo> JamesTait: hm, ok. is c-r-t a blocker? i.e. it will just mean we loose  the checks but for manual review it would be ok?
<mvo> JamesTait: or is this not the case?
<ogra_> WHEEEE !
<JamesTait> mvo, c-r-t currently doesn't understand snap.yaml, so squashfs snaps lacking package.yaml are assumed to be debclick packages.  c-r-t then barfs because DEBIAN/* files aren't present.
<ogra_> ubuntu@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 4.2.0-2011-generic-dragon410c #11-Ubuntu SMP Mon Jan 25 11:21:40 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
<ogra_> ubuntu@localhost:~$ snappy list
<ogra_> Name                   Date       Version      Developer
<ogra_> canonical-dragon       2016-01-29 ILPOPIQWILRE sideload
<ogra_> canonical-dragon-linux 2016-01-29 ILPOPIVJLVGO sideload
<ogra_> ubuntu-core-arm64      2016-01-29 ILPOPJFVLUfH sideload
<ogra_> mvo, ^^^
<ogra_> :D
<mvo> JamesTait: right, but that means it will warn, not block, right?
<mvo> ogra_: wooah!
<mvo> ogra_: what did you do?
<ogra_> replace the dtb and hack the uboot.env for the proper name
<mvo> JamesTait: what I am trying to get at is that it might be good enough for the few selected snaps we need to fix our unit tests to manually approve those :)
<JamesTait> mvo, with that, I don't think there's an option to manually approve - I think that option only appears where we have a "REDFLAG" error (like we get when the package is a squashfs), not a complete failure.
<mvo> JamesTait: aha, ok. then I misunderstood what is happening. thanks
<ogra_> mvo, http://people.canonical.com/~ogra/apq8016-sbc.dtb
<ogra_> grab that for the next image
<mvo> ogra_: yes sir
<ogra_> (and fix the uboot.env ;) )
<mvo> ogra_: uboot.env got fixed ages^Wminutes ago ;)
<ogra_> haha
 * ogra_ checks if wlan will work
<vir17> is there anything that I can do to allow the snappy to open tty ports?
<vir17> I get this error
<vir17>  [Errno 13] could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'
<ogra_> mvo, bah, crap, so polos kernel doesnt include the wlan driver or any of the firmware for it
<ogra_> no networking :/
<ogra_> vir17, is that *on* snappy or on your PC trying to talk to snappy via serial ?
<vir17> on snappy
<ogra_> mvo, oh !
<vir17> snappy try to talk to an arduino
<ogra_> mvo, whatever creates your kernel snap has never run depmod ... i cant load modules and i cant run depmod either because of the readonly squashfs
<ogra_> mvo, also you want all the firmware included in the kernel snap ... seems /lib/modules only has a few modules, there should be a few 100 MB of firmware files too
<ogra_> (from linux-firmware and if available linux-image-extra )
<mvo> ogra_: right, I think we can fix all this once the kernel hits the archive
<ogra_> mvo, well
<mvo> ogra_: this is more or less a hacked up kernel snap, the script is really build on top of what we get from the device tarball
<ogra_> i'm not sure paolo can actually include the wlan firmware
<ogra_> not sure about the licensing
<mvo> ogra_: thats fine, if its available in some package. or are you saying we can't have the firmware in the archive at all?
<ogra_> mvo, right
<mvo> ogra_: new image with your fix uploaded
<ogra_> trying
 * ogra_ sighs ... i went through all these issues in december ... but only write down stuff for half of them,
<ogra_> *wrote
<ogra_> vir17, and you try to use that devicfe as "ubuntu" user from commandline ?
<ogra_> or do you have a snap that tries to access it
<vir17> ogra_:  I have a snap that sends a command through serial
<vir17> tries to send a command
<ogra_> vir17, well, then you need to define the permission to access this device in your snapcraft.yaml first
<vir17> how I can do this?
<ogra_> snaps cant just access devices or any files outside their confined area
<vir17> is there any tutorial/documentation on how to do this?
<ogra_> this changed a lot recently, so ui dont know exactly .... you were able to run the hw-assign command before after installing the snap to prevent access
<ogra_> now there are capabilities and skills you need to define in the snapcraft.yaml ... but i didnt have any time to look into that yet
<vir17> ogra I cannot use now the hw-assign?
<ogra_> not in 16.04 ... it should still be in the old 15.04 images
<ogra_> (bot it is obsolete so better get familiar with the new way)
<ogra_> *but
<vir17> at the moment i have the old image
<ogra_> well, then hw-assign should work
<vir17> how the command was exactly
<vir17> snappy hw-assign?
<noizer> ogra_ ok i made a snap in the classic. How can i install it then on my snappy?
<ogra_> noizer, iirc /home/ubuntu is a shared dir
<ogra_> so exit the classic shell and you should see it
<ogra_> in the homedir
<noizer> oooh ok niceeee
<noizer> ogra_ what was the parameters to install the snaps?
<ogra_> --allow-unauthenticated
<vir17> ogra_: thanks it works now :)
<ogra_> :)
<vir17> in the new image when you said "try to use this device as "ubuntu" user"
<vir17> you mean with the classic shell
<vir17> ?
<ogra_> nope, just via ssh
<ogra_> or serial console
<vir17> serial console from snappy?
<ogra_> to snappy
<ogra_> mvo, works ! (execpt for thze missing modules.dep and wlan)
<vir17> ok, just asked to check if there is another to way to do what I am thinking
<vir17> snappy to talk to arduino
<ogra_> mvo, the modules.dep should really be fixed in any case ... you just need to run depmod with the right params before mksquashfs
<dholbach> all right my friends - I call it a day - see you all on Monday again - have a great weekend! :)
<ogra_> vir17, no,. that seems fine
<vir17> :0
<vir17> :)
<ogra_> dholbach, you too ... any enjoy the last bits of your jetlag ;)
<dholbach> hehe :)
<dholbach> will do
 * ogra_ too
<vir17> ogra_: should we expect new tutorials from the new image? because as you said it is good to start developing for the new snappy
<ogra_> there will be, yes
<vir17> :)
<ogra_> it is mainly all snapcraft nowadays though
<vir17> what do you mean?
<ogra_> well, all you need in the new world is snapcraft and a properly created snapcraft.yaml
<ogra_> (and snapcraft to build your snap indeed)
<ogra_> there is no extra tools like hw-assign anymore etc
<ogra_> the developer life turns into a single yaml file ;)
<mvo> ogra_: yeah, lets talk on monday
<vir17> hahaha
<vir17> sounds scary!
<vir17> hahhaha
<mvo> ogra_: ideally this would all be par tof the device.tar.gz like on the rpi2 and the bbb
<ogra_> mvo, yeah
<ogra_> mvo, mailed a status to the ML
<mvo> great
<kyrofa> sergiusens, elopio my wife isn't home yet-- can we push the planning back an hour?
<ogra_> hmm, no HDMI out ... i guess we need to fix that one too
<ogra_> oh !
<ogra_> there is ... but only for login indeed
<ogra_> great
<ogra_> lol... but no USB kbd without module support :P
<sergiusens> kyrofa, I don't mind, elopio ?
<kyrofa> Sorry guys
<sergiusens> kyrofa, no worries
<elopio> kyrofa: I can't an hour later. I need to pick up some sd cards before the store closes, and have a date to have lunch with my mother at that time.
<elopio> can you do the planning without me?
<kyrofa> sergiusens, elopio what if we do it on Monday this once?
<kyrofa> pindonga, do you know if the store supports chunked uploads?
<LefterisJP> guys I got a pretty basic question! So far I have been using an Ubuntu VM to develop for my Ubuntu core target machine. My host is ArchLinux. Is there any possible, conceivable way to build snaps (basically use snap and snapcraft tools) from another linux distro? It would save me from firing up a VM all the time I work on Ubuntu Core.
<sergiusens> kyrofa, elopio lets do it in 30 if possible and if not we'll see what to do
<ogra_> LefterisJP, why dont you just build *on* ubuntu-core instead ?
<ogra_> it has a mode for that
<LefterisJP> ? :o
<LefterisJP> first time I hear of that
<ogra_> sudo snappy enable-classic
<ogra_> snappy shell classic
<kyrofa> sergiusens, alright
<ogra_> and you are in a container that allows you to use apt and friends to build snaps
<LefterisJP> ok that's interesting
<LefterisJP> :)
<ogra_> then just apt-get update ... apt-get install snapcraft and you are ready to go
<ogra_> the homedir is shared so if you place your generated snaps in 7home/ubuntu in the container you will find them later in snappy
<ogra_> (for sideloading)
<LefterisJP> ok I am definitely gonna try that. But still the question stands, do you think it would be possible to try and port snappy tools to another distro?
<ogra_> not sure
<ogra_> it makes a lot of use of archive packages to get build dependencies in place etc
<ogra_> while i could imagine it wouldnt be to hard to port to debian, i think arch is a bit different
<kyrofa> LefterisJP, Snapcraft is just Python. If you get the right dependencies on arch there's no reason it shouldn't work
<ogra_> kyrofa, even the plugins that apt-get install build deps etc ?
<kyrofa> ogra_, oh yeah... that
 * ogra_ doubts it is that easy with a different package manager
<ogra_> debian will be an easy target to port to though
<kyrofa> LefterisJP, ignore me
<ogra_> non deb distros will surely be possible ... but will need a lot extra work
<core_t> what do you get if you #reinvent debian?
<LefterisJP> kyrofa: I know snapcraft is python, was talking about the rest. Well let's see .. for now will try the way ogra_ suggested but will also look into eventually allowing me to work from my host machine ... I would really love the convenience :)
<ogra_> LefterisJP, well, you should be able to use an ubuntu chroot on your host ... definitely more convenient than a vm
 * ogra_ calls it a day
<LefterisJP> hmm indeed, had done that for a previous job with Debian. Should set that up.
<LefterisJP> ogra_: good night!
<sergiusens> or lxc
<sergiusens> lxd (if you want to grab the tarball)
<kyrofa> sergiusens, elopio now does work by the way
<sergiusens> kyrofa, elopio lets do this then
<elopio> kyrofa: sergiusens: joining the call.
<LefterisJP> sergiusens: yeap, also good idea
<pindonga> kyrofa, don't think so, but let me check
<kyrofa> pindonga, how does the web interface display upload progress?
<pindonga> it's a streaming upload
<kyrofa> pindonga, hmm... I'm trying to figure out how to get upload progress out of the requests lib
<pindonga> but let me get you properly backed facts instead of spitting out buzz words :)
<pindonga> kyrofa, on the web ui we're using the YUI uploader component, which handles the progress itself (don't really know how)
<pindonga> but I'm getting you those answers
<pindonga> kyrofa, I guess you could do something like this: https://stackoverflow.com/questions/10525635/python-3-and-requests-with-a-progressbar#10576521
<pindonga> oh, but it looks like requests itself doesn't support upload streaming
<pindonga> https://stackoverflow.com/questions/13909900/progress-of-python-requests-pos
<sergiusens> ogra_, if still around, mind telling me what uname -m returns for the dragon?
<wxl> ok, so i tried ubuntu-device-flash to get an amd64 image and i get issues while partitioning
<wxl> well that's the incredibly verbose error
<wxl> $ sudo ubuntu-device-flash core --device generic_amd64 --channel ubuntu-core/15.04/edge --enable-ssh -o mysnappy.img
<ogra_> sergiusens, ubuntu@localhost:~$ uname -m
<ogra_> aarch64
<sergiusens> ogra_, thanks
<kyrofa> elopio, what changed to make the unit tests so noisy on master?
<elopio> kyrofa: um, I don't know. Let me give it a try.
<kyrofa> elopio, something to do with the loggers
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/282 if you want to take a look
<sergiusens> elopio, ^
<kyrofa> sergiusens, do you know what changed to make the test output so noisy? Something regarding the loggers?
<kyrofa> bisect to the rescue
<sergiusens> kyrofa, the landing of the tests for store uploads
<kyrofa> sergiusens, yeah I bisected to that, but I can't seem to figure out exactly what's causing it!
<sergiusens> those tests need to use the mocked loggers like the other test
<kyrofa> sergiusens, but I'm seeing Catkin logs and stuff
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/283 by the way. I can clean that up in another PR
<sergiusens> kyrofa, do something like this https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/tests/test_commands_build.py#L62
<kyrofa> sergiusens, there are indeed some of those, but the use the level of INFO. Does that set it for EVERYthing?
<sergiusens> no need to assign
<sergiusens> sorry baby in arms
<kyrofa> sergiusens, understood! I gotta run too :)
<bdmurray> How can I install a snap that I've created on my own?
<ogra_> snappy install --allow-unauthenticated /path/to/snap
<ogra_> +sudo
<bdmurray> ogra_: so just scp it over then?
<ogra_> yeah
<vir17> guys I am a little confused, I have a .csv file with some data inside and I want from a python script to read this data, how can I declare this inside the .yaml file?
<ogra_> there is a tool called snappy-remote that can do both, but i dont know in what shape it is (never used it)
<vir17> I suppose I have to put the file in the directory where the python code will be
<vir17> is "plugin:copy" something that I can use?
<ogra_> vir17, well, do you need to read the csv at package build time ?
<vir17> no, when the app will run in the snappy
<ogra_> yeah, then the copy plugin is the right thing
<vir17> ogra_:  thank you,  do you know also what is the correct declaration for plugin:copy ?
<vir17> how i am going to add the destination
<ogra_> http://paste.ubuntu.com/14708722/
<ogra_> that would make it copy myfile from the toplevel of the source dir into the toplevel of the snap dir
<vir17> thank you ogra_ much appreciated! :)
#snappy 2016-01-30
<bdmurray> ogra_: its taking quite some time for beaglebone to start running snappy. Are the lights indicative of anything?
<bdmurray> ssh'ing to the IP I get info about BeagleBone Debian Image
<sergiusens> kyrofa, https://bugs.launchpad.net/snapcraft/+bug/1539817
<ubottu> Launchpad bug 1539817 in Snapcraft "Unit tests are leaking messages" [Low,In progress]
<sergiusens> pindonga, kyrofa  https://github.com/ubuntu-core/snapcraft/pull/285
<r4space> Hi all - just trying to get into working on snappy.  I've found the remount approach to getting around the limited system write access, just wondering if that's the official advised approach for simple stuff like adding a new user (i get it that such actions wouldn't be normal for an IOT device just be nice for developing)?
<noizer_> Hi the documentation on de developer site is that for snapcraft 2.0 or 1.0?
#snappy 2016-01-31
<vir17> hi, anyone know how to install wireless in ubuntu snappy xenial?#
<ogra_`> vir17, everything you need should be there, just create a wlan0 (or however your device is called) file in /etc/network/interfaces,.d
<vir17> thank you ogra_`
<vir17> i suppose within classic shell?
<ogra_`> nope, directrly in snappy
<ogra_`> here is an example of the syntax http://people.canonical.com/~ogra/snappy/dragonboard/README
<vir17> perfect, I will try it
<vir17> :)
<vir17> and another stupid question
<vir17> i use touch to add wlan0 file
<vir17> but I dont know how to add data inside this file
<ogra_`> use vi :)
<vir17> i have nano instal
<vir17> but i get permission denied
<ogra_`> sudo vi /etc/network/interfaces.d/wlan0
<vir17> sorry nano is for classic
<anpok_> i now get signature verification failed when trying a install a snap.. even when using --allow-unauthenticated
<anpok_> s/a/to
<renat> Hi all! It's Renat from Screenly.
<renat> I need a help with snapcraft.
<renat> For the some reason, when it ask it to build for armhf acrh, - it builds for x86_64 arch.
<renat> It generates armhf snap, but inside there are x86 executables.
<renat> And I cannot execute them on the RaspberryPI=(
<anpok_> i guess I should rather ask .. how does snapcraft sign snaps?..
<anpok_> renat: hm i tinkered with cross compiling snaps.. but couldnt manage to solve the problem you describe..
<anpok_> maybe time for a bug report...
<renat> anpok_I don't need to cross-compile. It used to work as I rememeber. I just need to run a python script.
<anpok_> I am now building on one of my boards in a chroot env on a decent sata drive
<renat> anpok_ : Sign - you mean - install without --allow-unauthenticated ?
<anpok_> hm yeah that used to work
<anpok_> i updated to newest snapcraft and updated the system image today
<anpok_> now i get verification failed with exit status 14
<ogra_`> anpok_, snapcraft doesnt sign them at all, only the store does, if you have locally build snaps you always need (and needed) --allow-unauthenticated
<ogra_`> could it be that you used the snappy-remote script in the past (that sets the option by default when installing) ?
<anpok_> hm no only found out about snappy-remote today..
<anpok_> could it be that the snappy update failed
<ogra_`> snappy list would tell you
<anpok_> hm still the old one
<anpok_> i guess i need something newer than september 2015 to work with current snaps
<ogra_`> snapcraft 2.0 needs xenial/rolling
<ogra_`> only 1.0 works with 15.04
<renat> ogra_: hi! It's Renat from Screenly.
<renat> I have a question=)
<ogra_`> i see it above :)
<ogra_`> i dont think you can build armhf snaps on non armhf systems yet
<renat> Is it possible to build armhf snap on the amd64 ubuntu?
<anpok_> ogra_`: something like: release: ubuntu-core/15.04/edge
<ogra_`> anpok_, thats the non QAed build of 15.04 ... before it goes to the stable channel
<ogra_`> (and can only use snapcraft 1.0 binaries)
<renat> ogra_: understood. Thanks. So I need an other ubuntu. For example Trusty for Rpi.
<ogra_`> if you target xenial (16.04) then you can build on your snappy system
<ogra_`> the 16.04 images have the "classic dimension" ... i.e. a container thats shipped by default to enable you to use apt
<ogra_`> sudo snappy enable-classic
<ogra_`> snappy shell classic
<ogra_`> ...
<ogra_`> and you anc atp-get install what you need
<ogra_`> (i.e. snapcraft to do native armhf builds)
<ogra_`> note though that this obnly works in 16.04 images
<anpok_> ogra_`: is there an easy way to get to get to xenial?
<ogra_`> no
<ogra_`> well, as easy as re-flashing :)
<anpok_> hehe
<ogra_`> there is no update path
<anpok_> ok .. guess it is time to learn that
<ogra_`> just use ubuntu-device-flash to roll an up to date image :)
<anpok_> i guess I could reuse the device part from lemaker ..
#snappy 2017-01-23
<bso> Does anybody know how to upgrade snapd on Ubuntu Core 16.04.1?
<bso> I just installed Ubuntu Core 16.04.1, and it installed snapd 2.16.
<bso> I think the latest version of snapd is 2.25, but I don't know how to upgrade snapd on the Ubuntu Core system.
<stub> bso: The latest version of snapcraft is 2.25. Latest snapd is 2.20
<bso> @stub, oops, yes you are right. the latest snapd is 2.20.
<nothal> bso: No such command!
<bso> But, is there any way I can update snapd version on Ubuntu Core?
<bso> On Ubuntu desktop, I can do "sudo apt install snapd".
<bso> snapd itself is a part of core?
<bso> The core version is already 16.04.1
<stub> bso: snapd 2.20 is in xenial-updates, so you might need to enable that
<stub> I'm not sure about Core - I'm working with desktop stuff
<bso> @stub, could you elaborate how to enable xenial-updates?
<nothal> bso: No such command!
<stub> If you are running Ubuntu Desktop, top right icon and select 'system settings'.  Then 'Software and Updates'. Then the 'Updates' tab, which has a tick box for 'recommended updates'
<bso> I am on Ubuntu Core, not Ubuntu Desktop.
<stub> Yeah, I don't know Ubuntu Core sorry. Maybe editing /etc/apt/sources.list and following embedded comments, but I'm just guessing here.
<stub> You might need to wait for more of Europe to come online before you get an answer
<bso> @stub, Yup, I will wait for others to help me with Ubunto Core. Thanks.
<nothal> bso: No such command!
<nhaines> bso: we don't prefix nicknames with signs like @ or anything else in IRC.  That's more of a Twitter thing.
<nhaines> Of course, most bots don't use @ as a command prefix, either.  Usually ! or sometimes #.
<bso> nhaines, thanks for your advice. I am used to the @prefix habit. Sorry about that.
<nhaines> bso: no worries.  Not a problem at all except for the bit where it keeps setting off the bot.  ;)
<zyga> good morning
<longsleep> mcphail: Afaik the Nextcloud snap contains a web server which has the configuration to transparently proxy requests to the spreedme snap.
<mcphail> Hi longsleep. Unfortunately, I don't think it does. The only way I can see to get this working is to edit and recompile the nextcloud snap
<mcphail> I've got an idea for a patch to allow the admin to switch it on and off, though
<stub> I have a classic snap in the store that is published in stable and public, but not listed by 'snap find' and cannot be installed 'snap install --classic'. Name is 'wal-e', or wal-e.stub. What have I forgotten?
<Chipaca> stub: to update snapd?
<stub> I've got 2.20, and the machine was restarted fresh this morning
<stub> And I can install the snaps from a local .snap, just not from the store
<stub> Oh... juju-act is the same. Would the hypen be a problem?
<Chipaca> stub: installing classic from the store is a 2.21 feature
<stub> ok, that explains it then :)
<Chipaca> :-)
<Chipaca> stub: it's in -proposed afaik (but don't quote me on that :-) )
<stub> I need to wait for 2.21 in xenial (and hopefully trusty), since this is for charms
 * stub wonders if the snap-layer should be pulling in snapd from -proposed or a ppa
<__chip__> mwhudson, o/
<__chip__> mwhudson, is the go race detector expected to work in 1.7?
<aisrael> Is it possible to install snappy on centos7?
<ogra_> aisrael, https://github.com/snapcore/snapd/wiki/Distributions
<ogra_> only fedora currently
<aisrael> Thanks, ogra_!
<blu2> So, what happens if I installed too many snaps and have a small SDD? Any way to put snaps on another disk?
<__chip__> blu2, are you on classic, or is this a core system?
<blu2> this was just a thought I had on core
<blu2> because I'm 100% certain this will be a question in the future
<ToeiRei> Hi guys.
<__chip__> blu2, on core, there isn't currently a way of doing that
<__chip__> ToeiRei, o/
<blu2> __chip__: eventually?
<__chip__> blu2, it isn't planned, but should be straightforward if the need arises
<__chip__> there's nothing "special" about where snaps are stored
<ToeiRei> is there a way to work with core in a headless way?
<ToeiRei> because I'm in a bit of a dilemma
<__chip__> ToeiRei, depends what you mean by headless
<ToeiRei> __chip__, headless in terms of "no keyboard, no mouse, no screen"
<ogra_> ToeiRei, currently a console is a requirement for the initial setup of the installed image (network data, user account)
<__chip__> ToeiRei, serial?
<ogra_> can be serial though
<ToeiRei> I'm on a raspi 3 here with a remote user... who's tech skills are as good as the ones of a lipstick.
<__chip__> ToeiRei, I'm not sure where to begin to help you with that
<__chip__> ToeiRei, how did you get yourself into such a predicament?
<ToeiRei> my spouse spilled coffee...
<ToeiRei> so he went off for a new raspi and a new card and I'm sitting a few miles away
<ToeiRei> now I got ssh onto my trusty ol' laptop...
<ToeiRei> a card reader and some 'remote hands' with a *very* limited technical understanding
<ToeiRei> __chip__, does that help?
<ogra_> you either need a serial cable or a monitor/tv and keyboard ...
<__chip__> ToeiRei, I'm not familiar enough with the pi to know: is it like the bbb where you plug it in and you have serial-over-usb, or do you need to jtag?
<ToeiRei> wait a minute... you're about to tell me that I need to hook up a console to that thing for core?!?!?
<ogra_> __chip__, you need an ftdi cable
<__chip__> aww :-(
<__chip__> ToeiRei, only if you need to set up a user and the network
<ToeiRei> I mean... raspbian says 'do an empty file named ssh on /boot'
<ogra_> (like you do on the BBB in case you want to access the bootloader)
<__chip__> which is probably a 'yes' unless you're creating your own image
<__chip__> ToeiRei, well, the alternative is to ship a default user and then have botnets take down the world
<ToeiRei> __chip__, I like the 'ssh file' way of raspbian. Something like a bootloader param would have done the trick
<ogra_> ... and none of the current reference images does that ...
<ToeiRei> at least something
<ogra_> ToeiRei, how would that help if the device is not configured for the network
<ogra_> nor has any user account that could be used with ssh
<ogra_> ssh is on by default on ubuntu-core
<ToeiRei> dhcp does the trick
<ogra_> just doesnt help without IP
<ogra_> (or user)
<ToeiRei> ogra_, I have a dhcpd running.
<ToeiRei> in theory the sshd is running
<ToeiRei> and I can read its key
<ogra_> ToeiRei, well, that wont help you ... the image is set up in a way that you need to run a first boot setup wizard
<ToeiRei> that's so braindamaged for embedded.
<ogra_> you could create your own gadget snap and image to have a pre-created network config and user setup through cloud-init
<ToeiRei> nothing to be done remotely I suspect
<ogra_> the existing developer images have the firstboot setup as a req. simply because they are developer images :)
<ogra_> on an actual embedded image that runs i.e. some kiosk app or just some datas collection you would likely not even have a user at all and have your data logging or kiosk app included
<ogra_> (and manage themselves via browser or whatnot)
<ToeiRei> I know why I usually do not run any flavor of ubuntu in my environment. once more confirmed.
<ToeiRei> thanks
<ogra_> regarding developer images we simply expect developers tp work with them
<ogra_> *to
<ogra_> which requires a login ...
<ToeiRei> I don't even have spare monitors around due to laptops
<ogra_> a TV will do ;)
<ToeiRei> could you bring one over?
<ogra_> heh
<ToeiRei> I do not have any kind of an external monitor around
<ToeiRei> not even a f* tv set
<ogra_> well, then your only option is serial i fear ... which i'd expect an embedded developer to have around like i expect a carpenter to own a hammer
<ogra_> (probably to high expectations)
<ToeiRei> I just have no idea how to explain to my bf how to plug that in.
<ogra_> http://elinux.org/RPi_Serial_Connection perhaps ?
<ToeiRei> you need a pi hat for a serial connection afaik
<ogra_> no
<ogra_> you plug your FTDI serial cable directly into the headers on the board
<ToeiRei> usually I use raspi boards as remote cpus for networking tasks... so I usually do not need serial cables at all.
<om26er> elopio: Hello! around ?
<larryprice> i have a snap (libertine.canonical) pending manual review in upload because it's using the 'desktop' property... can this be worked around, or alternatively can the upload be canceled so i can revert the 'desktop' change?
<nickaww> Hi there, I'm trying to snap a game and I'm using the make plugin and artifacts keyword to copy all the files to the stage, but apparently wildcards are not supported on artifacts. How can I copy all the files without declaring every file and directory one by one?
<ogra_> look at the dump or copy plugins
<nickaww> yeah, I tried that, but dump/copy plugin can't access other parts
<ogra_> does your makefile have an install target ?
<ogra_> iirc that should just be used automagically
<nickaww> It does. But it doesn't install as conventions and I need all the files from the project
<ogra_> could you just add additional install lines ? like https://github.com/ogra1/nethack/blob/master/Makefile ?
<nickaww> Do you mean add new install entries for every file in the project?
<ogra_> no, for the whiole dirs
<ogra_> see the "doc" line in the above makefile
<ogra_> that puts the whole doc subdir into $DESTDIR
<kalikiana> ogra_: Is there a particular reason the makefile does the downloading? As opposed to letting snapcraft do it?
<nickaww> Well, I tried what you said about install directories. This is supposed to work, bot I will need to edit the Makefile every time I pull
<elopio> om26er: hello. I am around now.
<elopio> pachulo: pong. Where you looking for me? I was on vacations last week.
<om26er> elopio: Hey! can you tell which script is responsible for upload of snapweb to edge channel once a change is merged into master ?
<om26er> elopio: we need to run some tests every time a snapweb snap is published in edge.
<elopio> om26er: https://github.com/snapcore/snapweb/blob/master/.travis.yml#L50
<elopio> om26er: but if you have tests that need the edge package, my recommendation would be to just run them daily.
<ogra_> kalikiana, you mean the wget ?
<ogra_> kalikiana, a) that makefile predates the ability in snapcraft to do downloads itself ... b) if i would use a source: stanza it would try to use the upstream makefile and i couldnt do the patching or run the setup.sh script
<ogra_> kalikiana, in this case the makefile is rather a better shellscript though
<larryprice> jdstrand, thanks for taking a look at my mp friday evening - my snap is currently stuck pending manual review (due to the desktop property)... can that be worked around? i'll happily get a new version uploaded using the old setup/gui/*.desktop if you just want to cancel my pending uploads
<jdstrand> larryprice: I can approve it. the upcoming snapcraft 2.26 will keep that out of the snap.yaml so eventually this won't be an issue
<jdstrand> larryprice: I don't see it though. what is the snap name?
<larryprice> jdstrand, libertine (libertine.canonical)
<jdstrand> ah, ok. I've got it
<jdstrand> larryprice: done
<larryprice> jdstrand, thanks! we're also hoping to auto-alias the libertine-launch alias... not sure what the process is there
<jdstrand> larryprice: can you paste your snapcraft.yaml?
<jdstrand> larryprice: I can do it
<larryprice> jdstrand, https://paste.ubuntu.com/23852309/
<jdstrand> larryprice: updated the store:
<jdstrand> [
<jdstrand>   "libertine-launch",
<jdstrand>   "libertine-container-manager",
<jdstrand>   "libertine-manager-app"
<jdstrand> ]
<jdstrand> larryprice: note that r47 and r48 are approved but you need to release them
<larryprice> jdstrand, ok cool - should i switch back to old-style desktop files in my uploads until 2.26 is released?
<pachulo> welcome back elopio ! Yes, I wanted to talk with you about the help you offered me for writing tests for this: https://github.com/snapcore/snapcraft/pull/980
<elopio> oh, that's you. Sorry for the late reply...
<elopio> pachulo: a good way to start would be with some simple tests for the sources that don't support checksum
<jdstrand> larryprice: probably best if you don't want to ping a store reviewer, yes. aiui, serguisens was planning a 2.26 update sooner than later. he doesn't seem to be here atm
<jdstrand> kyrofa: do you know if 2.26 is coming out soon? ^
<elopio> oh, but I see you already added those, nice!
<rvr> zyga: ping
<elopio> pachulo: next, I would write a few tests for "invalid checksum format". But I need to catch up with a few things before helping you write that code.
<elopio> pachulo: I think those tests can live in snapcraft/tests/sources/test_checksum.py, because it's the same function you will be calling for all the different sources.
<pachulo> ok elopio , I write down your tips and will try to implement the simplest ones
<elopio> pachulo: and there are a few possible options. You can write a test that calls directly the verify_checksum function, with an invalid source_checksum paramter. Or you could fabricate a sources object, like you do on the tests for sources that can't have checksum like you did last week.
<elopio> pachulo: I think I would prefer the second option, because it tests the verify function in a bigger context. But the other one is not wrong, also good.
<elopio> pachulo: take a look at snapcraft/tests/test_tar.py, for example. From there you can get an idea of how to make a tar source object. Add an invalid checksum in there that will throw and exception, and you already know how to expect that exception in a test.
<elopio> ping me in case of doubt.
<elopio> oh, thanks a lot for working on this!
<rvr> zyga: I'm trying to execute spread tests in Debian, and found some issues along the way. fgimenez tells me you have done it, is that correct?
<pachulo> you're welcome elopio ! Just giving some of my time after years of sucking from FOSS!!
<elopio> :D
<rvr> Just opened an install issue with classic and Debian here https://github.com/snapcore/classic-snap/issues/7
<kyrofa> mcphail, yeah, `occ upgrade` always disables them. I have no idea why
<mcphail> kyrofa: yeah - spotted the bug on the tracker.
<kyrofa> jdstrand, I know he was planning on releasing soon, but he's out sick today I'm afraid
<mcphail> kyrofa: do you have plans for setting up apache config for spreed.me? I posted a bug about it
<kyrofa> mcphail, I wasn't really planning on it. I'd have to test to make sure it continued working every release
<kyrofa> And your proposal, while better than just having a proxy in there all the time, sounds a bit fragile
<kyrofa> mcphail, I think I'd rather support it more like this: https://github.com/nextcloud/nextcloud-snap/issues/172
<mcphail> Yes, a more robust method would be better. Not sure when one is going to arrive, though
<zyga> jdstrand: hello
<kyrofa> mcphail, indeed, which is why such things are in a bit of a holding pattern for the time being
<zyga> jdstrand: when would be a good time to sit together and look at snap-alter-ns
<kyrofa> mcphail, the challenge is that snaps can currently update from any revision to any other revision. Which means any temporary solution we come up with will have to have a migration path, and we'll have to maintain it forever
<zyga> jdstrand: doesn't have to be today
<stokachu> so i need a little help getting my systemd script to start
<stokachu> http://paste.ubuntu.com/23852922/
<stokachu> if i run the exec command directly then it all loads
<stokachu> actually no it doesnt
<stokachu> this command fails /usr/bin/snap run conjure-up.bridge
<jdstrand> zyga: not today, but a) is the kernel issue addressed and b) what do we need to look at together?
<stokachu> the ultimate goal is to just have the network interface and iptables rules persist through a reboot
<stokachu> here my snap files https://github.com/conjure-up/conjure-up-snap
<jdstrand> zyga: (not today cause I have a bunch of PR reviews to do that come in over the weekend/today
<jdstrand> )
<stokachu> the bridge file is pretty straight forward https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft/wrappers/bridge.start
<stokachu> though im not sure what snap run conjure-up.bridge file is being run? is that the command-bridge.wrapper?
<zyga> jdstrand: a) \o/ (great!) b) I think a hangout where I walk you through it and show what's missing would be more constructive
<zyga> jdstrand: I wrote lots of unit tests but I still have some blank spots
<zyga> jdstrand: and I need to write spread tests to actually see it work
<jdstrand> zyga: re 'a', that was a question-- is it addressed?
<zyga> jdstrand: ahhh
<zyga> jdstrand: too bad :(
<jdstrand> I mean, jjohansen may have found something, idk otoh, hence the question :)
<zyga> jdstrand: no, no change there (I need to sped more time to investigate as what I'm seeing made no sense)
<jdstrand> I think we should understand what is happening with the kernel as that may block the implementation
<zyga> jdstrand: but I don't think it affects us in alter-ns as alter itself is not confined
<zyga> jdstrand: I agree it would be good to get to the bottom of this
<zyga> jdstrand: I was coding all day to get to the point where the bulk of the code is in place and not scary
<zyga> jdstrand: I'll spend tomorrow landing bits upstream and checking what may be going on in the kernel
<zyga> (and I still have to write snapd changes)
<jdstrand> zyga: I was comfortable with the spec. if you want to do a PR and have me review, then I can decide if a hangout is needed
<zyga> jdstrand: I made a tiny change compared to the spec (and left a todo entry to update the wiki so that it stands out)
<zyga> jdstrand: it's not an error if a file is empty
<zyga> jdstrand: (the fstab-like file)
<zyga> jdstrand: we just carry on as if it were empty
<zyga> jdstrand: otherwise the design checks out
<zyga> er
<zyga> jdstrand: it's not an error fi the fstab-like file is *not present*, we just treat it as if it were *empty*
<zyga> (that's better)
<Guest55973> can anyone help with ubuntu snaoppoy
<Guest55973> ubuntu snappy
<ogra_> depends :)
<zyga> Guest55973: I think it's better to just ask your question :)
<Guest55973> what is the default pswrd for first boot ssh connection
<ogra_> there is none
<ogra_> it uses your ssh key that you uploaded for your ubuntu one account
<Guest55973> it said wrong passwrd
<ogra_> yes, because there is no password, it is locked down ... only key authentication is allowed by default
<Guest55973> i am putting ubuntu sso account username as both log in and pasword
<ogra_> well, that wont work
<ogra_> you need to have the secret ssh key for the public one that you uploaded to the SSO account on your local machine
<ogra_> then you will not even be asked for a password
<Guest55973> where do i have to enter that public key , ssh client or host? ?
<Guest55973> host isn't responding to any command
<ogra_> you dont have to enter it ... it gets downloaded from login.ubuntu.com when you run through the firstboot wizard
<ogra_> i.e. the thing you get on fist boot after the "please press enter" message ...
<ogra_> after setting up the network there it asks for your SSO account ... then it downloads the key from the SSO server and puts it in place on the machine
<Guest55973> didn't get it, so first i'll enter my host ip then log in as sso user and for pssword ... blank?
<ogra_> whats the hardware you are working on ?
<Guest55973> rasp 3
<ogra_> and what image did you use ? do you have the url you used for downloading it ?
<Guest55973> ubuntu core pi 3
<ogra_> from where ?  :)
 * ogra_ wants to make sure you have the correct image before we move on
<Guest55973> from the ubuntu.com
<ogra_> http://releases.ubuntu.com/ubuntu-core/16/
<ogra_> from there ?
<Guest55973> yes that is correct
<ogra_> ok
<ogra_> so this image runs a first-boot wizard you need to complete first
<ogra_> either via serial console or with a monitor and keyboard attached to the pi
<Guest55973> i have successfully installed the to raspberry i had no problem until that login and password thing came up
<ogra_> so you finished the wizard ?
<Guest55973> yes
<ogra_> it usually gives exact instructions for the ssh login
<ogra_> there is no password and if everything worked you should also not be asked for one when you ssh in
<Guest55973> as username@ipadress?
<ogra_> well, whatever was written on your screen (it shoudl still be there if you attach a monitor)
<ogra_> it prints the exact ssh command there
<Guest55973> what about client ? i am using putty for remote access
<ogra_> oh
<ogra_> i'm not sure how you add your secret key in putty ...
<ogra_> (the last time i used putty was 15y ago or so ... sorry )
<ogra_> (i didnt mean to scare him away though :P )
<zyga> ogra_: it's actually very very very hard :)
<zyga> ogra_: because putty uses some odd format for the key
<zyga> ogra_: so you need to convert them on command line with some unholly openssl command
<zyga> ogra_: then once you have the key in both formats it's not that hard, just double-click on the key file (it has to have some extension specific to putty)
<zyga> ogra_: then you get putty agent in the windows tray
<zyga> ogra_: but I didn't do that for a long time either
<zyga> ogra_: in case someone asks we should have an answer on the wiki (I bet lots of windows devs will come)
<zyga> jamiebennett: ^^
<ogra_> yeah, we need docs for this
<zyga> mhall119: ^^ where could we put this
<ogra_> https://help.ubuntu.com/community/SSH/OpenSSH/ConnectingTo
<ogra_> sadly that doesnt have any info about that key thing you mentioned
<larryprice> question about the d-bus interface... is it possible to connect to a snapped dbus interface from non-snap world, like just using dbus-send from the command line?
<ogra_> oh my
<ogra_> http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter8.html
<ogra_> thats like a whole book !
<ogra_> bah, and it doesnt talk about windows at all
<zyga> larryprice: yes
<zyga> larryprice: well, in theory :)
<zyga> larryprice: I didn't check if you can actually do that (if the rules allow unconfined processes to have access)
<zyga> larryprice: can you please find out and edit the wiki page at https://github.com/snapcore/snapd/wiki/Interfaces
<larryprice> zyga, in that case, it may be that my daemon isn't started automatically (a different issue)
<larryprice> zyga, sure - i'll pioneer this
<ogra_> __chip__, are you incognito recently ?
<__chip__> ogra_, i forgot to log off on the computer downstairs
<ogra_> ah
<zyga> larryprice: thank you
<zyga> larryprice: feel free to create a sub-page (look at the content interface)
<zyga> larryprice: thank you!
<kyrofa> jdstrand, two questions: 1) do you see anything wrong with the logic in bug #1658774, and 2) would you update the review tools as a result, or does it not matter?
<jdstrand> kyrofa: I have to step out right this second but will get back to you after I'm back
<kyrofa> jdstrand, no rush, thank you :)
<bso> Hi, does anybody know how to update snapd versions on Ubuntu Core?
<bso> I installed Ubuntu Core 16.04.1 and it came with snapd 2.16, but I would like to update it to the latest version.
<zyga> bso: it should happen automatically
<zyga> bso: try "sudo snap refresh"
<bso> zyga, it seems snapd is not a snap. I tried "sudo snap refresh", but it says everything is up to date.
<bso> "snap list" does not list snapd as one of the snaps.
<zyga> bso: that's correct, snapd is in the core snap
<zyga> bso: hmm
<zyga> bso: are you running snapd on classic ubuntu?
<bso> My core snap version is 16.04.1
<zyga> bso: or on ubuntu core image
<bso> No Ubuntu Core 16.04.1
<zyga> bso: can you tell me the output of "snap version" please
<bso> 2.16
<zyga> bso: is that the whole output?
<zyga> bso: how id you get your image?
<bso> Actually it has +<some additional string> after that. It is running an IoT device which is away from me at this moment.
<larryprice> zyga, good news - it seems that i can easily access the dbus apps from the rest of an unconfined system
<larryprice> zyga, however i'm having some trouble getting my simple daemon to auto-start on install... is there a good way to debug this?
<zyga> larryprice: not sure, what are yo seeing?
<zyga> *you
<zyga> bso: can you please pastebin the whole output
<zyga> bso: how did you obtain this image?
<zyga> Chipaca: ^^ (2.16 doesn't update, maybe side-loaded, maybe something else?)
<bso> zyga, I got it from https://developer.ubuntu.com/core/get-started/intel-joule
<bso> There is link to the image on that page.
<zyga> I see
<zyga> jamiebennett: ^^
<zyga> bso: so the core should update on its own, having said that 2.16 feels old (we are at 2.21 now) and I wonder if there is anything that would cause this to fail
<zyga> bso: if you run "snap list" what does it say about the core snap?
<zyga> bso: (or at that age, ubuntu-core)
<bso> core is 16.04.1
<larryprice> zyga, oho - looks like all the logs are going to syslog, i can visibly see the issue now
<zyga> does it mention anything in the notes?
<bso> I tried snap refresh core, but it says it is already up to date.
<bso> I will have to get the Joule board to read that again, but it is away from me at this moment. sorry.
<zyga> bso: thank you for reporting this, would you mind opening a bug on launchpad.net/snappy please?
<bso> I would like to update it to 2.21, but it seems I can't find a way.
<bso> zyga, sure I can do that soon. By the way, what is the usual way to update snapd on Ubuntu Core. Is it currently impossible?
<bso> "sudo apt install snapd" does not work on Ubuntu Core.
<zyga> bso: on core snapd updates automatically without human intervention
<zyga> bso: as soon as you boot the system it will update itself
<zyga> bso: (and everything else)
<bso> I see. Then, something is broken since snapd is not updated automatically somehow.
<bso> I will file a bug.
<zyga> bso: thank you
<zyga> ogra_: ^ do we generate up-to-date images for joule?
<jamiebennett> zyga: these images are coming from tuchuck it seems
<jamiebennett> Ideally we need them on cdimage
<jamiebennett> zyga: I think we need to talk to the people who are producing them for an update i.e. CE
<ogra_> jamiebennett, i have fresh ones from JohnAgosta ready ... gimme a bit
<jamiebennett> ogra_: that is fine but we need a regular cadence for these not one-shots
<ogra_> images that are built in a non standard way manually cant go on cdimage
 * zyga agrees with jamiebennett 
<ogra_> they usually go to http://people.canonical.com/~platform/snappy/
<ogra_> jamiebennett, well, they are one shots ... they have a lot of manual changes
<jamiebennett> ogra_: right but I would hate for them to go stale if we can help it
<ogra_> and dont use the standard build systems
<zyga> ogra_: what changes?
<ogra_> zyga, talk to the CE team
<jamiebennett> ogra_: can you kick off an internal mail to John and others to discuss Joule/Artik/NUC/... image production?
<ogra_> for nuc we could merge them and they know we take their changes happily if they are includeable
<ogra_> (i.e. for nuc you should noowadays take the generic amd64 images)
<ogra_> jamiebennett, will do ... for now i'll release the jule image though :)
<jamiebennett> ok
<mhall119> zyga: what "this" do you want to put somewhere?
<ogra_> bso, http://people.canonical.com/~platform/snappy/tuchuck/uc16-beta4/
<ogra_> there is a new joule image
<ogra_> *jule
<bso> orga_, thanks for the link
<zyga> mhall119: instruction on how to connect to a core device from windows using putty
<zyga> mhall119: with putty agent, keys and what not
<zyga> mhall119: it's not trivial
<JohnAgosta> ogra_, thnaks
<ogra_> np
<JohnAgosta> jamiebennett, we got behind in posting updates for Joule.  This is now a refresh...the image does require a new BIOS flash to v174
<ogra_> to late
<ogra_> (he just dropped off)
<JohnAgosta> ogra_, jamie is now offline but ^^ -- I am asking the marketing team to update the details on the website now
<JohnAgosta> ogra_, for the NUC, it now uses the standard x86 images as we moved all requirements directly into the standard image
<ogra_> JohnAgosta, yep, i know (i added a good bunch of the missing stuff that was missing) ;)
<JohnAgosta> :)
<stokachu> do we know when snapd 2.21 will make it out of proposed?
<ogra_> we should look if we can do the same for the other arches
<stokachu> need it for the --classic snap install
<ogra_> i'll start a ML thread tomorrow morning and we can discuss
<zyga> stokachu: soon (tm), not sure though
<stokachu> zyga, also if the snap is in the store as classic do i still need to pass --classic during snap install?
<stokachu> right now i do sudo snap install conjure-up --classic --edge
<zyga> stokachu: yes
<stokachu> ok
<zyga> stokachu: you always need to pass --classic as this informs the user that all of confinement is off
<stokachu> gotcha, makes sense
<larryprice> zyga, any experience launching snapped d-bus services as daemons? currently i just get complaints in syslog about no DISPLAY being set...
<mhall119> zyga: is connecting to Ubuntu Core different from connecting to classic Ubuntu?
<mhall119> or is it just pubkey auth rather that password auth that makes it difficult?
<zyga> larryprice: DISPLAY not set does not smell like a dbus service
<zyga> larryprice: are you using the session or system bus?
<zyga> larryprice: currently snappy doesn't support session services
<larryprice> zyga, right i was just reading up on that (we've been using session bus)
<zyga> mhall119: it is, because there's no password at all and you must use key auth
<zyga> mhall119: unless you know exactly how to do that in putty on windows it's not easy to do
<larryprice> zyga, the current alternative is to use system bus? or force users to launch the service manually in the bg for now, and switch over the daemon when the session stuff is ready
<zyga> larryprice: no, that's not an alternative, if you *must* be on the session bus the system bus is useless
<zyga> what are you trying to snap?
 * zyga should EOD
<zyga> it's late
<larryprice> zyga, currently snapping libertine and its tools, i have full control of the source
<larryprice> zyga, feel free to call it a day - thanks for all your help
<zyga> yeah, I should rest
<zyga> (in case anyone is interested) snap-alter-ns -- the thing that lets you alter a namespace as snaps execute (e.g. you can connect a content interface element to a running app) is here: https://github.com/snapcore/snapd/compare/master...zyga:snap-alter-ns-part1?expand=1
<zyga> the commit message there lists remaining issues
<zyga> but nothing major :)
<zyga> jdstrand, tyhicks: ^^
<zyga> (I'll make that a PR when a prerequisite is merged)
<stokachu> when can we ditch telling people to use 'sudo snap install..' rather than just 'snap install'?
<stokachu> to not use*
<zyga> stokachu: you can sudo snap login
<zyga> stokachu: then you can snap install AFAIK
<stokachu> zyga, ah ok
<azubieta> hello folks! I would like to implement an Snap Store! I was reading that it is a simple restful server, but which are the methods that i must implement in order to make it compatible with snapd?
<jdstrand> zyga: ack, I'll add it to my list. there are quite a few other reviews that are queued before it so not today. likely tomorrow
<jdstrand> kyrofa: I don't see anything wrong with your logic. there is no reason to include the symlinks since the libc libraries are already available to the snap
<kyrofa> jdstrand, excellent, thanks for taking a look! Want me to apply it to the review tools as well so you can remove that special case? Or should we keep that in place?
<jdstrand> kyrofa: I'll subscribe the bug and remove the special casing when it is released
<kyrofa> jdstrand, alright
<kyrofa> jdstrand, how do you keep track of all the bugs to which you're subscribed?
<kyrofa> I can barely keep up with snapd and snapcraft-- you must have far more than that
<kyrofa> I feel like I'm missing a trick
<jdstrand> kyrofa: I have procmail rules that make directly subscribed bugs hit my inbox
<jdstrand> and I know the feeling on that. I have a pretty big email queue to go through every day
<kyrofa> jdstrand, and ones you get because you're a member of some group?
<jdstrand> but them's the breaks on a busy project
<jdstrand> kyrofa: depends on the group. all snappy bugs happen to also hit my inbox
<jdstrand> that's a lot of bugs :)
<kyrofa> No kidding
<jdstrand> but I can't really see any other way to catch stuff
<kyrofa> Indeed. So really your response is "I put on my boots and wade through it" ? :P
<jdstrand> I obviously don't read every bug, but if it has something to do with the sandbox, interfaces, policy, review tools, etc, I read them
<kyrofa> Fair enough. I just need to factor that into my day a bit more, then
<jdstrand> eg, I don't read snapcraft bugs very closely, unless it has something to do with new yaml or something I'm personally interested in
<jdstrand> ie, I read all the subjects
<jdstrand> then decide
<jdstrand> it's not terrible to wade through
<kyrofa> mwhudson, any chance you could take a look at https://askubuntu.com/questions/875429/network-configuration-timed-out-in-ubuntu-core-16 ?
<mcphail> kyrofa: got the optional switch for apache working in the nexcloud snap, but have found spreedme's config too opaque to be useful! Think I might abandon this plan for now ;)
<kyrofa> mcphail, hahaha!
<kyrofa> Well, thanks for taking a crack at it :)
<mcphail> :)
#snappy 2017-01-24
<ses__> I am getting âcannot communicate with serverâ issue when trying to install. Anyone knows how to resolve this issue? snapd seems to be running
<ses__> sudo snap install --dangerous cwr_0.1_amd64.snap
<ses__> error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<thomi> ses__: what does "sudo systemctl status snapd.service" show?
<ses__> thomi: http://pastebin.ubuntu.com/23855366/
<thomi> https://wompwompwomp.com/ :(
<thomi> hmmm
<ses__> thomi: seems missing some text http://pastebin.ubuntu.com/23855373/
<thomi> in any case, "Active: inactive (dead) (Result: exit-code) since Mon 2017-01-23 17:31:11 PST; 24min ago" doesn't sound healthy
<thomi> I'm trying to recall where the logs are
<thomi> ses__: I don't suppose you recently ran snapd from source, and now are trying to run the system version?
<ses__> thomi: no
<ses__> thomi: I restarted the machine but still having the issue
<thomi> hmmm -  I'm not a snapd dev, and I'm not sure how to help you any more. I've encountered a similar issue once myself after running snapd from source. Since that doesn't match the situation you're in, I'm not sure what else to suggest
<thomi> This timezone isn't great for catching the snapd devs - you might want to consider mailing the snapcraft mailing list
<ses__> thomi: thanks
<ses__> thomi: what time are they usually here? Timezone?
<thomi> I believe they're mostly Europe/US - vague, I realise, sorry :D
<azubieta> Hello, I'm traying to setup a snap store based on https://github.com/noise/snapstore but i'm getting this error: error: cannot communicate with server: Post http://localhost/v2/snaps/foobar25: EOF when I try to install a package. Any ideas ?
<noise][> azubieta_: there a few things to be aware ofâ¦ first, there's a branch "metadata_tests" that I have yet to merge that updates support for the newer API endpoints
<azubieta_> noise: oh! so i must use the code from that branch instead ?
<noise][> however, even with that, newer snapd versions will not install local snaps from that store because they will lack the assertions to verify their authenticity. snapd allows you to snap install foo.snap âdangerous from a local file (sideloading) but does not allow it for a remote store install
<noise][> we have started discussing how to allow for different trust chains so your own store deployment can be trusted but we don't have firm plans or timeline for that currently
<azubieta_> noise: i would like to create a fulle functional, snapd compatible and opensource snap store, but according to what you say they don't allow it
<azubieta_> noise: besides your work is there another opensource project that i could check ?
<noise][> that's correct for right now - we will allow that but at the moment you would need to work around the assertions check by doing a download and install separately
<azubieta_> ok
<noise][> i.e nothing is stopping a solution that fetches the snap files from a server and then does "snap install <snap file> âdangerous", but we aim to support alternate stores directly in snapd
<mup> PR snapd#2666 closed: interfaces: add ability to set system time zone to timeserver_control interface <Created by justincan> <Closed by justincan> <https://github.com/snapcore/snapd/pull/2666>
<mup> PR snapd#2679 opened: Ubuntu/14.04 <Created by vosst> <https://github.com/snapcore/snapd/pull/2679>
<mup> PR snapd#2585 closed: debian: move systemd files out of ./debian and into ./data/systemd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2585>
<zyga> good morning
<niemeyer> Mornings
<mup> PR snapd#2666 closed: interfaces: add ability to set system time zone to timeserver_control interface <Created by justincan> <Closed by justincan> <https://github.com/snapcore/snapd/pull/2666>
<mup> PR snapd#2679 opened: Ubuntu/14.04 <Created by vosst> <https://github.com/snapcore/snapd/pull/2679>
<mup> PR snapd#2585 closed: debian: move systemd files out of ./debian and into ./data/systemd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2585>
<om26er> Hi! What endpoint does snap info call ?
<zyga> om26er: hey
<zyga> om26er: I think that's a question for chipaca
<zyga> om26er: I bet it also depends on the version of snapd as that area saw some development
<om26er> zyga: Ok, will ask him, I needed information about available revisions of snaps from different channel, I could use grep for that but was looking if there was cleaner way I could achieve that
<Chipaca> you called?
<zyga> Chipaca: hey
<zyga> 12:36 < om26er> Hi! What endpoint does snap info call ?
<zyga> :-)
<jibel> om26er, if you want info directly from the store you can always use something like : curl -s https://search.apps.ubuntu.com/api/v1/snaps/details/<SNAP>?channel=<CHANNEL> -H 'X-Ubuntu-Series: 16' -H 'X-Ubuntu-Architecture: <ARCH>'
<Chipaca> om26er, why do you ask?
<om26er> Chipaca: I need to get available revisions for a snap in different channels
<Chipaca> om26er, what for?
<om26er> Chipaca: for CI purpose whenever something is merged in snapweb master, it gets pushed to edge channel automatically, I need to check if the newly pushed snap is published before trying to install it and run tests on top of that.
<Chipaca> om26er, doesn't snapcraft already give you that info?
<Chipaca> or are these things disconnected? the pushing and the checking i mean
<Chipaca> om26er, the store is still working on exposing this information, so right now for 'snap info' i'm doing a separate (rather arcane) query just for that
<Chipaca> om26er, hitting /v2/find?name=foo on snapd will get you the channel map, if that's what you need
<om26er> Chipaca: I haven't looked at the output of snapcraft push, if it returns that result, we can probably use that as well.
<Chipaca> yes, snapcraft push returns the channel map
<Chipaca> from SCA
<Chipaca> snapd talks to CPI
<Chipaca> if you've already got snapcraft talking to SCA, that's better for this than having snapd talk to CPI for it
<Chipaca> om26er, let me kknow if that's covered what you need please
<Chipaca> om26er, please ACK so I can move on from this
<om26er> Chipaca: yes, one of our script uploads to the store through snapcraft, so will get the output from there.
<om26er> Chipaca: thanks for the info
<Chipaca> np
<om26er> jibel: yeah, just tried, that endpoint seems to work as well.
<stokachu> so ive got my snap working on 16.04 with a systemd script, 14.04 is throwing this error at me though http://paste.ubuntu.com/23857838/
<stokachu> do i have to define anything differently to get my systemd scripts working for 14.04 in a snap env?
<mhall119> sergiusens: what's the proper way for a snapcraft test case to handle downloading a source file?
<elopio> mhall119: unit test or integration test?
<mhall119> elopio: integration I would think?
<elopio> mhall119: for integration, you can probably put your source in people.ubuntu.com, write a real snapcraft.yaml that uses it, and call the pull command in the test.
<mhall119> ok, cool, thanks elopio
<elopio> mhall119: there is an ftp you can use as a guide in snapcraft/integration_tests/snaps
<mhall119> elopio: just found that one
<sergiusens> mhall119, for the unit test we create files on the fly
<ryebot> Is there a way to prevent the snap name prefix from being added to a snap command? For example, I have a snap with the name "cni-loopback" and the command "loopback". The generated command is "cni-loopback.loopback". Is there a way to make the command name simply "loopback"? (without renaming my snap to loopback)
<kyrofa> ryebot, support was recently added for command aliases
<kyrofa> ryebot, which essentially allows you to promote prefixed commands into the non-prefixed domain
<ryebot> kyrofa: excellent, I can google now, thank you :)
<ogra_> ryebot, https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/alias/snapcraft.yaml
<ogra_> there is an example
<kyrofa> ryebot, note that it requires snapd v2.20 or later
<ryebot> ogra_ kyrofa: you guys rock, thanks for the help!
<kyrofa> Any time :)
<ogra_> (sometimes we also roll ;) )
<kyrofa> When we eat too much
<ogra_> haha
<ryebot> XD
<cachio> niemeyer, hey, I was trying to import spread tests in our grafana instance, and I was wondering if should be make spread to export test results in a well know format so it is easy to import from anywhere?
<cachio> niemeyer, I can add a mp if you think it would be a good idea
<niemeyer> cachio: Yeah, that sounds nice for sure
<niemeyer> cachio: I suggest doing that as a small function which is run at the very end of the runner's life cycle
<niemeyer> cachio: We already have a stats type and value at hand, so it should be super easy to just take that as an argument and generate a file in a well known format based on an option which the runner already has easy access to
<cachio> niemeyer, ok, make sense, any preference with the output format?
<niemeyer> cachio: Are there a few options which grafana can already interpret, or is that manual anyway?
<cachio> niemeyer, the we run a tranlator to export it to grafana
<cachio> we already have for pyunit for example
<cachio> niemeyer, so I need then either to send from travis to grafana the resutls, or to import it from jenkins and send it to grafana
<cachio> niemeyer, should be easier if we could send directly from travis to grafana which is a production service hosted in prodstack
<niemeyer> cachio: If you need to manually parse and translate into grafana anyway, then I wouldn't worry about changing spread, at least I wouldn't begin there
<cachio> niemeyer, I already have the translation from xunit pyunit into grafana schema
<niemeyer> cachio: Yeah, xunit is probably a good choice
<cachio> niemeyer, ok, i'll implement that
<cachio> niemeyer, are you already sending spred results to any canonical service?
<niemeyer> cachio: Nope..
<AlbertA> ogra_: alecu: following up on the post to the snapcraft ML about GFX on pi3...
<AlbertA> it seems the latest snapd is no longer autoconnecting the mir-libs interface? at least that's what I'm seeing with ogra_'s latest image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ogra_> AlbertA, it does for me
<ogra_> i have to manually connect the mir interface, but mir-libs is autoconnected
<AlbertA> ogra_: alecu: mir-kiosk:mir-libs is autoconnected for you? and which snap version are you running?
<AlbertA> snap list
<AlbertA> Name        Version        Rev  Developer  Notes
<AlbertA> core        16.04.1        970  canonical  -
<AlbertA> mir-kiosk   0.1            20   canonical  -
<AlbertA> mir-libs    0.1            20   canonical  -
<AlbertA> pi2-kernel  4.4.0-1040-47  26   canonical  -
<ogra_> ogra@localhost:~$ snap version
<ogra_> snap    2.21+ppa215.5a5f1500-1
<AlbertA> pi3         16.04-0.5      14   canonical  -
<AlbertA> ogra_: oh but without --devmode ?
<ogra_> yep ... worked for me (i dont have any mir stuff on the current image though)
<ogra_> gimme a moment
<alecu> I found it odd that devmode is gone after disabling and reenabling a snap
<alecu> Finishing lunch, I'll try it in a few minutes
<ogra_> might be a feature ... not sure ...
<AlbertA> alecu: so in an any case, you can connect it manually - snap connect mir-kiosk:mir-libs mir-libs:mir-libs...then have to workaround a snap content i/f bug
<ogra_> zyga, niemeyer ^^^ if you dis/enable a snap devmode gets dropped, is that wanted ?
<ogra_> AlbertA, hmm, right, not connected here either now
<AlbertA> do: snap disable mir-kiosk; sudo /usr/lib/snapd/snap-discard-ns mir-kiosk; snap enable mir-kiosk
<AlbertA> ogra_: ok, I'll read the content i/f docs.. maybe something changed now
<ogra_> well, the namespace stuff landed and the gadget grew support for gpio interfaces in core
<ogra_> neither should have caused an issue though
<AlbertA> ogra_: yeah well just thinking maybe I'm missing a field or something when specifying the content i/f plug now
<ogra_> ogra@localhost:~$ snap interfaces|grep mir
<ogra_> :network                  mir-kiosk-apps,pulseaudio
<ogra_> :opengl                   mir-kiosk,mir-kiosk-apps,unity8-session
<ogra_> mir-kiosk:mir             mir-kiosk-apps
<ogra_> mir-libs:mir-libs         mir-kiosk-apps
<ogra_> -                         mir-kiosk:mir-libs
<ogra_> so mir-kiosk-apps autoconnect
<ogra_> mir-kiosk doesnt
<AlbertA> huh.... interesting.
<AlbertA> I'll take a look at that, I did change the snapcraft.yaml last time
<ogra_> ah
<AlbertA> I'll revert that change and republish
<Blu2> Will we ever see the promised snapped firefox?
<kyrofa> Blu2, I expect so, but it's not being done by us
<AlbertA> alecu: ogra_: ok a new revision of mir-kiosk was just pushed (rev 22 for armhf) that autoconnects fine
<AlbertA> to mir-libs
<alecu> Wonderful
<Blu2> kyrofa, I know, I was hoping somebody knew something about it here :)
<kyrofa> Blu2, not me anyway. That's all mozilla
<ogra_> AlbertA, thanks !
<Blu2> kyrofa, I thought they may be here in this chat
<kyrofa> Blu2, fair enough, they may be :)
<ses__> I am having issue communicating with the server during installation snapd seems to be running okay but have some issue. Anyone knows how to resolve this issue https://pastebin.ubuntu.com/23859088/
<ogra_> ses__, that doesnt seem to be running
<ogra_> Jan 24 09:02:11 me-vm systemd[1]: snapd.service: Start request repeated too quickly.
<ogra_> Jan 24 09:02:11 me-vm systemd[1]: Failed to start Snappy daemon.
<ses__> ogra_: https://pastebin.ubuntu.com/23859105/
<ogra_> well, systemd disagrees ... and you should also not see two snapd processes ... looks more like something hangs or respawns very fast
<ogra_> if you do the ps -A again i bet you see new pids
<ogra_> what are you running this on ? is that a native ubuntu install ?
<ses__> I see the same pids
<ses__> 16.04
<ogra_> using a normal ubuntu kernel ? (uname -a ? )
<ses__> apt install
<ses__> Linux me-vm 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<ogra_> looks ok
<ogra_> does snap list work ?
<ogra_> (if so, which core snap is installed ? )
<ses__> No it doesnât work
<ses__> Cannot communicate with the server
<ogra_> right ...
<ogra_> ls -l /snap/*core
<ogra_> does that return anything ?
<ses__> ogra_: yes. I see â1357 currentâ dirs
<ogra_> thats ok too
<ogra_> i wonder why it doesnt start ...
<ogra_> anything in syslog ?
<ses__> ogra_: there is something in syslog. Any key words I search for?
<zyga> ogra_: (as for devmode being dropped, probably not but not sure (I wish we would write design down)
<zyga> )
<zyga> I hate when I drop )
<ses__> ogra_: maybe this is relevant https://pastebin.canonical.com/176943/
<ogra_> zyga, btw, ses__ is the third person in 4 days that has a non-starting snapd
<zyga> ogra_: !!!!
<zyga> ogra_: can you tell me more?
<ogra_> ses__, hmm, do you have livepatch installed ?
<ses__> ogra_: yes, there was other people having the same issue last night in this channel.
<ses__> ogra_: I didnât install livepatch
<ogra_> ses__, ah, no, i was confused by the kernel messages in the paste
<ogra_> zyga, any idea ? https://pastebin.canonical.com/176943/
<ses__> ogra_: but I installed snapd yesterday
<ogra_> ses__, and you didnt have snapd installed before ?
<ses__> ogra_: first time installing it on a new machine
<ogra_> (you seemingly have /snap/ubuntu-core there instead of /snap/core ... that kind of indicates an older install )
<ogra_> (new installs should always get the core snap installed, not ubuntu-core anymore)
<zyga> looking
<zyga> bloody hell 2fa
<ogra_> heh
<ogra_> yeah
<ogra_> snapd[18866]: error: cannot patch system state from level 3 to 4: cannot get snap state    for "cwr": <nil>
<ogra_> seems the most relevant bit
<alecu> ogra_: AlbertA: with the latest mir-kiosk, I get the black screen and (laggy!) pointer on the raspi2. But, when I try to start the mir-kiosk-apps all of mir freezes on the second frame, just like what I saw yesterday on the raspi3
<zyga> ok logged in
<ogra_> alecu, disconnect/connect ?
<zyga> that bug is fixed in master I think
<ogra_> alecu, i usually need to do that once for the -apps
<zyga> and I think it was released in 2.21
<alecu> ogra_: after a disconnect and connect, yes.
<ogra_> zyga, "released"
<ogra_> zyga, us normal users all have 2.20 still
<zyga> upstream release
<zyga> blame the SRU process
<ogra_> 2.20.1ubuntu1 to be precise
<zyga> what can I do?
<ogra_> dunno
<alecu> ogra_: sorry, after a disable and enable of the snap package. Will try disconnect
<ogra_> zyga, trust your colleagues i was told :P
<pedronis> anyway that shows trying to use snapd before upgrading snapd
<zyga> ogra_: I trust all of my colleagues
<ogra_> alecu, yeah, that needs both ... disable, disconnect, connect, enable
<zyga> let's see when we can make it available to everyone
<ogra_> alecu, like the mir wiki describes
<ogra_> and at some point the content interface will just woork ;)
<ogra_> if you have the pointer on black screen mir itself is definitely running fine
<ogra_> my kodi snap is sadly currently broken (i tried to build the latest master which has the mir patches but also broken kodi ... ) ... so dont bother with that
<ses__> ogra_: is there anything I can now to go around this issue?
<ogra_> ses__, do you have many snaps installed already ?
<ogra_> i'd try to purge snapd and install it again
<ogra_> perhaps that helps ...
<ogra_> (but thats just ut of desparation ... )
<ses__> ogra_: should I also uninstall snap?
<ogra_> i know it works on all my xenial installs over here
<ogra_> snap is a commmand shipped by the snapd package
<ogra_> so purging snapd should be enough
<ogra_> and then just install t again
<ogra_> then try something from the store ... like snap install htop ... that should pull in the core snap alongside
<ogra_> once you knwo it works, you can start plying with your local snap that you tried to install before
<ses__> ogra_: ok, will do âsudo apt-get remove --purge snapdâ
<ogra_> sudo apt purge snapd ... less typing ;)
<ogra_> (same thing though)
<AlbertA> alecu: you will need --devmode
<AlbertA> alecu: I'm seeing some new syscalls with this driver, so I'll need to update the mir interface
<alecu> AlbertA: devmode for mir-libs, mir-kiosk and mir-kiosk-apps ?
<AlbertA> alecu: mir-kiosk and mir-kiosk-apps yeah
<AlbertA> the interesting part is that ps shows miral-kiosk as defunct but yet it still runs...
<ogra_> magic ;)
<ogra_> (also known as "the zombie apocalypse is near")
<alecu> AlbertA: ogra_: after installing both -kiosk and -kiosk-apps with devmode, it all seems to be working ok on the raspi 2.
<alecu> thanks a lot!!!
<kyrofa> alecu, "ok" = greater than a single frame?
<alecu> kyrofa: I get plenty of frames now :-)
<alecu> no end in sight
<kyrofa> alecu, I really wanted to reply to your email and say "stop moving the mouse!"
<alecu> lol :-)
<kyrofa> alecu, nice to see you around by the way!
<ogra_> alecu, awesome ... sorry that you had such a bumpy ride
<alecu> it's the early days of the raspi image... totally understandable.
<ryebot> kyrofa: I'm hitting some issue with the aliases, any idea what I might be doing wrong? https://gist.github.com/wwwtyro/aa34ccb81f6928f2bda37b32c7a00c1f
<kyrofa> ryebot, I know you need to enable them somehow (it's not done automatically without an assertion that happens store-side)
<kyrofa> ryebot, `snap alias` perhaps?
<ryebot> ah, okay
<ryebot> so it might not work if installed locally?
<kyrofa> ryebot, not work == not automatically enabled? Yes
<ryebot> kyrofa: gotcha, thanks. seems to work!
<ryebot> thanks again!
<kyrofa> ryebot, excellent! Of course
<kyrofa> jdstrand, how does one request aliases to be automatically granted? Is it all manual right now, or is there a process for it?
<jdstrand> kyrofa: it's manual
<stokachu> jdstrand, is there anyone familiar with systemd wrt 14.04 snaps?
<stokachu> jdstrand, trying to figure out why my snap is failing to install
<ogra_> ses__, did you get anywhere with reinstalling snapd ?
<jdstrand> stokachu: tvoss spearheaded the effort and I think slangasek may have poked at systemd, but perhaps ask your question here and maybe someone will know
<stokachu> jdstrand, thanks
<stokachu> it was basically this email https://lists.ubuntu.com/archives/snapcraft/2017-January/002706.html
<stokachu> it just seems to not find a systemd service file
<ses__> ogra_: I am trying it now. Distracted by other tasks
<ogra_> ah, no worries
<jdstrand> Main PID: 1548 (code=dumped, signal=SEGV)
 * ogra_ grins about stokachu's last paragraph in the mail ... getting rid of maintainer scripts are one of the reasons we started snaps :)
<stokachu> there is no snap.conjure-up.bridge.service in /etc/systemd/system
<stokachu> but that does exist in 16.04
<jdstrand> stokachu: if I had to guess, thinking it is a series 16 built snap with 14.04 libraries thing. this is probably related to the asciinema thread and friends that sergiusens is working on
<jdstrand> stokachu: if a service fails to start it fails the install and cleans up after itself
<stokachu> ah the email from mark?
<tvoss> o/
<stokachu> jdstrand, yea my snap never got installed b/c it hits that systemd error
<jdstrand> stokachu: that whole thread, yeah-- there are complexities with series 16 built stuff on a 14.04 system that aiui, aren't being handled all the time
<stokachu> ok yea, this looks like my systemd service file never makes it onto the system
<tvoss> jdstrand: the issue mostly evolves around snaps using classic confinement, though
<stokachu> tvoss, yea this is classic
<jdstrand> stokachu: you might try turning that into a command (comment out 'daemon: ...', then install, then do 'snap run --shell conjure-up.bridge' and see if you can't debug better
<tvoss> stokachu: how do you try to install the service file?
<stokachu> tvoss, https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml#L16-L20
<stokachu> jdstrand, ok i can try that
<tvoss> stokachu: do you have a snap handy for testing?
<stokachu> what if i run snapcraft on the 14.04 system and build from there?
<stokachu> tvoss, yea one sec
<stokachu> tvoss, actually you can do sudo snap install conjure-up --classic --edge
<stokachu> it's the same one i do for xenial that works
<stokachu> err snap download i guess
<jdstrand> stokachu: I'm not sure snapcraft is available for 14.04 yet (but I'm not tracking that work)
<tvoss> stokachu: let me clean up my testing environment
<kyrofa> stokachu, as it stands, snapcraft doesn't run on trusty
<kyrofa> (it has xenial-only deps)
<stokachu> jdstrand, kyrofa ah ok
<stokachu> didnt know if that would make a difference
<kyrofa> tvoss, is the core snap on trusty the same as on xenial (i.e. is it still really xenial?)
<kyrofa> Err, series 16 I guess
<tvoss> kyrofa: yup, it's a series 16 core
<kyrofa> tvoss, so we don't anticipate libc symbol issues if we build on xenial and run on trusty?
<kyrofa> I hit that back in the day, but it may have been before we actually had a core snap. Everything blurs together
<jdstrand> kyrofa: curious, with the lxc stuff, is snapcraft needed inside the container or can snapcraft from outside drive commands inside?
<jdstrand> err, lxd*
<tvoss> kyrofa: the assumption is to redirect everything to the core snap, and not pull in ABI from the host. classic is the exception here
<kyrofa> tvoss, indeed, okay, makes sense
<kyrofa> jdstrand, good question. I think the biggest requirement for it to be on the system is fetching stage packages
<kyrofa> It also uses the container's sources.list by default for build-packages
<stokachu> jdstrand, yea that asciinema thread is pretty much the same thing im hitting too it seems
<ses__> ogra_: I was able to install htop. I guess it is working but having issue installing my own snap âMount snap "cwr" (unset) (snap "cwr" requires consent to use classic confinement)â
<ogra_> ses__, sounds like you want --classic in your snap install command
<kyrofa> jdstrand, basically, every time snapcraft execs something else, we'd need to check to see if we need to exec in a container or on the host
<kyrofa> jdstrand, and how that happens depends on what command is being run. For fetching stage packages we use the python3 apt API, so that's a big one
<jdstrand> kyrofa: I don't know if this is at all helpful, but if the stage packages were broken out into a freestanding script, xenial host could copy stage-package script to trusty container, fetch stuff, then go from there. I suspect wanting lxd to build different series is interesting, but 14.04 is clearly the exception. series 18 would have snapcraft
<jdstrand> well, python3-apt should be in trusty
<kyrofa> jdstrand, yeah, but how do you use it if you're not in the container?
<jdstrand> it isn't terribly interesting so long as we have series 16 core on trusty though I think
<stokachu> so sergiusens mentioned having a python3 part, is that something I could do as a workaround for this issue?
<jdstrand> kyrofa: I figures start the conteriner, lxc push it, lxc exec it, etc
<jdstrand> kyrofa: but, I'm not saying you should do it. you guys have given this way more thought than I :)
<kyrofa> jdstrand, ah sorry, I was referring to python3-apt being in trusty, not the script
<kyrofa> jdstrand, yeah I think it really comes down to "snapcraft wasn't written that way." Not to say we won't get there eventually, it's just a question of the shortest path
<tvoss> stokachu: so start of the bridge service fails, with the executable segfaulting. For that, the snap is removed immediately
<tvoss> stokachu: and thus no service file :)
<stokachu> tvoss, so should i do jdstrand's suggestion and try to run it as a script?
<tvoss> stokachu: yup, that would be a good first step
<ses__> ogra_: used âclassic but got âerror: cannot find signatures with metadata for snap cwr_0.1_amd64.snap" ?
<stokachu> ok lemme try that
<ses__> ogra_: snapcraft.yaml https://pastebin.canonical.com/176952/
<stokachu> tvoss, jdstrand: so doing snap run --shell conjure-up.bridge starts my interface and applies the iptables rules
<kyrofa> ses__, you need --dangerous as well
<kyrofa> ses__, http://pastebin.ubuntu.com/ is your non-2fa-protected friend
<tvoss> stokachu: hmmm, that's funky
<jdstrand> stokachu: hmm. did you have to snap connect anything?
<tvoss> stokachu: would you mind trying to call conjure-up without snap run?
<stokachu> jdstrand, nah as long as lxd is installed on the host
<stokachu> http://paste.ubuntu.com/23859714/
<stokachu> thats from journalctl
<stokachu> lemme try running conjure-up
<jdstrand> oh duh, its classic
<ses__> kyrofa: sorry url autocomplete
<jdstrand> ses__: use --dangerous for your cannot find signatures error
<stokachu> conjure-up
<stokachu> Segmentation fault (core dumped)
<stokachu> :(
<tvoss> jdstrand: ^
<stokachu> Jan 24 20:30:50 darthbawlz kernel: [24152.656439] traps: conjure-up[3152] general protection ip:7f26c316a1ee sp:7ffe79c932e0 error:0 in libc-2.23.so[7f26c3027000+1bf000]
<stokachu> is in my syslog
<jdstrand> libc-2.23.so is xenial's libc. trusty's is libc-2.19
<stokachu> im guessing that gets pulled in during snapcraft build
<jdstrand> I don't have the details, but I remember that there were issues on xenial when snaps tried to use a  shipped libc instead of the system one
<jdstrand> if I were to guess, I'd guess this is the same issue. I think this is the thread I was mentioning before with the dynamic linker, etc
<jdstrand> I've not looked in the issue. others in this channel I believe are actively looking at it
<stokachu> ok, sounds like a decision needs to be made whether to use the system's libs in a classic snap?
<stokachu> strace shows this open("/snap/core/current/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
<jdstrand> stokachu: the only thing I can suggest otoh is adjust LD_LIBRARY_PATH or running your command with /lib/x86_64-linux-gnu/ld-2.19.so $SNAP/bin/your.executable ...
<jdstrand> actually
<jdstrand> you would want to do /snap/core/current/lib/x86_64-linux-gnu/ld-2.23.so ...
<stokachu> still segfaults it seems
<jdstrand> anyway, I suspect with effort, you'd be able to use the right set of libraries then take that into a wrapper script for your command
<stokachu> jdstrand, ok, but this is something that can be dealt with in snapcraft at some point?
<jdstrand> stokachu: that is what the thread is about
<stokachu> ok, thanks, at least it's a known issue
<jdstrand> and, aiui, people are trying to figure out how to make this work well for people. it is rough now
<stokachu> jdstrand, all good, it works fine on xenial. having trusty is just icing on the cake
<stokachu> jdstrand, tvoss thanks for looking into it
<jdstrand> stokachu: np. keep an eye on that thread and the other related threads on the snapcraft list and hopefully it'll get resolved soon
<stokachu> jdstrand, sounds good, will do
<mhall119> sergiusens: why does snapcraft require the core snap to be installed on the build-machine when using the classic interface?
<kyrofa> mhall119, so it can use its linker
<mhall119> ah, ok
<mhall119> makes it kind of hard to build in lxc then
<kyrofa> mhall119, indeed
<kyrofa> mhall119, or LP
<kyrofa> mhall119, it's a known issue
<mhall119> or on my host, until that update that converts me off ubuntu-core
<kyrofa> Ah, yes, that as well
<mhall119> kyrofa: ok, as long as it's on someone's list to fix, I'll wait patiently
<kyrofa> mhall119, yeah, it's very rough right now, we know
<kyrofa> Thanks for bearing with us!
<tvoss> stokachu: np
<tvoss> stokachu: you might want to watch https://bugs.launchpad.net/snapd/+bug/1657504
<stokachu> tvoss, thanks i subscribed to it
<ryebot> Is it possible for one snap to execute another snap binary in /snap/bin without using classic confinement?
<ryebot> e.g., using some interface?
<kyrofa> ryebot, I'm afraid not. Even if there were, there's no way for snap A to even know that snap B is installed (or request for it to be installed)
<ryebot> kyrofa: understood, thanks!
<kyrofa> ryebot, can you explain what you're trying to accomplish?
<ryebot> kyrofa: certainly: I'm wanting to snap up multiple CNI plugins, and they sometimes want to execute one another
<ryebot> They're pluggable, too, so I can't put them all in the same snap
<kyrofa> ryebot, CNI?
<ryebot> I /think/ I can do what I need with classically-confined snaps (barring dealing with possibly hardcoded plugin names!), but wanted to know if it was possible with strict confinement
<ryebot> yeah, Container Networking Interface, iirc
<ryebot> Basically, a bunch of binary files that sometimes call out to one another
<kyrofa> ryebot, within what execution context? i.e. what loads the plugins? (no idea what CNI is)
<ryebot> In our use case, kubernetes
<ryebot> (and other plugins, of course)
<kyrofa> ryebot, so is there a kubernetes snap, and you want to create snaps of its plugins?
<ryebot> We'll probably be making a kubernetes snap, and yes, it will need to call its plugins that we're hoping to deliver as snaps
<kyrofa> ryebot, bear with me, while I know what kubernetes is I've never used it. How does it "discover" plugins?
<ryebot> the node agent, kubelet, is started with a cli argument or env var that points to the directory which contains all the plugins
<ryebot> which looks like it's gonna be /snap/bin instead of the typical /opt/cni/bin (that's another thing I wasn't planning on bringing up yet!)
<kyrofa> ryebot, and it crawls the directory upon startup, thereby obtaining a list of plugins that are available?
<ryebot> As far as I understand, yes
<kyrofa> ryebot, it sounds like you need bug #1655125
<kyrofa> Hmm... the bot's gone
<kyrofa> https://bugs.launchpad.net/snappy/+bug/1655125 rather
<ryebot> cool, thanks, I'll take a look :)
<ryebot> I need to step into a meeting, thanks for your help, I'll be back to bug you more, I'm sure :D
<kyrofa> ryebot, please do add a comment a mark yourself affected if you agree
<ryebot> +1 will do!
<BLu2> weird, just had to reinstall hexchat snap, because it would keep crashing on start up
#snappy 2017-01-25
<tryubuntu> how we can run nodejs based application on ubuntu snap ? any link for how to translate nodejs app to snapcraft based app
<blumoon> does anyone know the correct usage for using config-flags with autotools plugin ?
<driftwoof> @any *
<nothal> driftwoof: No such command!
<zyga> re
<zyga> sorry, had a power failure last night and didn't realize my server was down
<oSoMoN> Mirv, would you mind reviewing https://github.com/ubuntu/snapcraft-desktop-helpers/pull/39 ?
<Mirv> oSoMoN: done, indeed it makes sense. I don't have commit rights though.
<oSoMoN> Mirv, thanks
<chihchun> barry: just wonder if autopkgtest of ubuntu-image 0.14 is broken at this moment?
<chihchun> barry: some tests are failing, not sure it's caused by build environment or its just does not work in this release? https://gist.github.com/chihchun/59c4845da7b493c0e26ccfe2b5224e08
<stokachu> what bugs are blocking snapd 2.21 from reaching updates?
<ogra_> none
<ogra_> the SRU was just set to verification-done
<stokachu> ok cool
<ogra_> next run of the SRU team should move it to updates
<stokachu> ogra_, perfect, thanks
 * stokachu getting anxious
<tito_> Hi folks; I've got a question regarding a snap packaging. It's quite simple, but I've not found the answer yet. How do you guys handle a configuration files of your software within your packages?
<tito_> as long as $SNAP root directory is read-only, how can I copy it (in the installation phase of snap app) to the writable directory, so end-user could modify the configuration file on his own?
<tito_> i
<tito_> is it even possible?
<zyga> tito_: hey
<zyga> tito_: it all depends on what kind of software stack are you dealing with
<zyga> tito_: on one extreme end there are pre-built debian packages that keep everything in /etc and have no way to look elsewehre
<ogra_> tito_, you can create configuration hooks in your snap that call scripts/tools in the backend to adjust app configuration and are managed via snap set/get commands
<ogra_> http://snapcraft.io/docs/build-snaps/hooks has some docs about this
<zyga> tito_: on the other extreme end you can have software that was built to understand snappy and the configure hook and read-only code / writable data
<zyga> tito_: most real software falls in the middle
<ogra_> yeah
<zyga> tito_: you can typicall pass configuration to daemons / services
<zyga> tito_: so even if the hard-coded defaults are in /etc/foo, you specifiy `foo -c $SNAP_DATA/foo.cfg`
<zyga> tito_: you can copy good defaults from your snap ($SNAP) to $SNAP_DATA on start-up (if they are missing)
<zyga> tito_: you can patch software to be smarted abotu all of this
<zyga> tito_: on top of that snappy supports per-snap configuration
<zyga> tito_: so you can give users unified way to configure something
<zyga> tito_: (unified across snaps)
<zyga> tito_: this translates to the configure hook
<tito_> correct
<zyga> tito_: that system is more complex but also ultimately better
<zyga> tito_: (I don't know if we have docs for that)
<tito_> zyga:
<tito_> ogra:
<tito_> thanks!: )
<tito_> so
<tito_> is it a good way to copy the configuration file
<tito_> to $SNAP_DATA
<tito_> in a command wrapper ?
<zyga> just copy it in a wraper
<zyga> yeah
<ogra_> right
<tito_> ok
<tito_> aha ok - so the last question then
<tito_> (for now :D)
<tito_> how do you deal with custom wrappers ?
<tito_> I am sure that I am doing it wrong
<tito_> but here are my steps:
<tito_> 1. normally,when snapcraft.yaml is done i perform: snapcraft command
<zyga> tito_: I copy them to /usr/bin and use them from snapcraft.yaml instead of my comman
<zyga> command*
<tito_> it creates all prime stuff etc
<tito_> then I modify the prime/command-wrapper
<zyga> tito_: no, don't edit snapcraft-generated wrappers, you will just waste your time
<tito_> and perform another snap packaging with: snapcraft snap prime/
<tito_> SUX right?
<zyga> tito_: as I said :)
<zyga> tito_: you can use a simple dump part
<zyga> tito_: that copies your wrapepr over
<zyga> tito_: or a simple makefile part
<zyga> tito_: (I prefer makefiles)
<tito_> so
<tito_> when I will eventually type on a ubuntu core system
<tito_> snap_name.command
<tito_> will it look first in usr/bin ?
<tito_> (For the wrapper)
<zyga> no
<tito_> hm
<zyga> it will look at snap.yaml
<zyga> and run that
<zyga> that will run the generated wrapper
<tito_> yes
<zyga> then that wrapper can run what you specified
<barry> chihchun_afk: 0.14 should pass its autopkgtests.  it did in zesty because it's in the main archive, and it actually does in x and y too because they're in proposed waiting for sru approval (but they pass their tests).  curious to hear more details about your failures
<zyga> just call it foo.wrapper
<tito_> and in that generated wrapper calls another one ?
<zyga> and expose it as "foo" app
<zyga> yep
<tito_> ok
<tito_> so another level of inception :D
<tito_> Ok ok
<tito_> now I get it
<zyga> deception ;)
<tito_> anyway - I like this stuff, great work
 * zyga gets back to content interface
<tito_> btw. ok last, really last question.
<tito_> Is it possible to update snapd over snap or it is "to core" in the OS ?
<zyga> hmm?
<zyga> we're planning to spit the core snap into a core snap and a base snap
<tito_> Why I am asking. I want to develop custom interface
<zyga> where >1 base is available
<tito_> and test it on the machine that is not my developer machine
<zyga> for that, the answer is: do it upstream
<zyga> you can easily test that, we have tools for it
<zyga> https://github.com/snapcore/snapd/pull/2709#pullrequestreview-18381601
<zyga> hmm
<zyga> bad link
<zyga> https://github.com/zyga/devtools
<zyga> tito_: ^^
<zyga> may be somewhat stale but still works ok
<zyga> should work ok
<zyga> tito_: once snapd and base snap are separate the process may change
<zyga> tito_: no ETA on that yet
<zyga> (but I like the ability to use other base snaps)
<zyga> e.g. debian base or fedora base
<zyga> (insert joke about fedora core)
<tito_> lol
<tito_> hey
<tito_> I will go over this thanks
<tito_> but when I think now
<zyga> good luck, ping if you get stuck
<tito_> about copying
<tito_> configuration stuff in a command wrapper
<tito_> then I think that it won't work
<tito_> eg,
<tito_> when user changes the copied configuration file
<tito_> it will be overwritten on a second command wrapper run
<tito_> right ? :D
<zyga> you can only copy it if it's not there, obviously
<tito_> GOOD ONE!
<zyga> and if you do it so that the config hook manages all the changes
<zyga> you can even do sensible updates with new revisions of your snap
<tito_> ok, thanks guys
<tito_> once again.
<zyga> ogra_: http://es.farnell.com/bitscope/bb01b/bitscope-blade-uno/dp/2546576
<zyga> ogra_: or maybe https://es.farnell.com/MarketingProductList?orderCode=2546576,2546577,2546578&COM=referral-handler&CMP=SOM-FACEBOOK-PRG-NPI-BITSCOPE-BLADE-TRANS-GBL
<zyga> ogra_: pi ... rack?
<zyga> ogra_: doesn't support pi 3 (probably just not tested) but supports pi2
<ogra_> well, you need a blade chassis for that
<ogra_> but yeah, pretty cool
<zyga> they have one
 * zyga looks
<zyga> https://es.farnell.com/MarketingProductList?orderCode=2546576,2546577,2546578&COM=referral-handler&CMP=SOM-FACEBOOK-PRG-NPI-BITSCOPE-BLADE-TRANS-GBL
<zyga> gah
<zyga> still wrong link
<zyga> ogra_: http://www.bitscope.com/product/blade/?p=about
<ogra_> yeah
<zyga> http://bitscope.com/product/blade/03.jpg
<zyga> ogra_: the money link is http://my.bitscope.com/store/?p=list&a=list&i=cat+3
<zyga> jdstrand: hey
<zyga> jdstrand: I was looking at raw-usb and I see it doesn't work unless your USB devices are on the PCI bus
<zyga> jdstrand: any objection to let it allow access to things like: /sys/devices/platform/soc/3f980000.usb/usb1/idVendor
<zyga> jdstrand: so e.g. /sys/devices/platform/soc/*.usb/usb[0-9]** r,
<alecu> zyga, ogra_: if you guys are thinking of making a beowulf cluster of raspis (or some such), you may be interested in the raspi compute module: http://arstechnica.com/information-technology/2017/01/raspberry-pi-upgrades-compute-module-with-10-times-the-cpu-performance/
<ogra_> yeah, i thought of that
<alecu> here's more info on the old one: https://www.raspberrypi.org/blog/raspberry-pi-compute-module-new-product/
<ogra_> when zyga showed the above :)
<ogra_> but for that you also need a case with slots and power supplies
<zyga> alecu: I'm well aware of those
<zyga> alecu: just hard to get and not as flexible for *testing* PI
<alecu> great :-)
<ogra_> i wonder if the blade setup doent come out cheaper in the end if you sum up all the bits you need
<alecu> ogra_: yeah, that's likely.
<zyga> blade also supports hats and allows for more flexible test setup
<zyga> compue feels like an embedded/cloud thing
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2716
<zyga> jdstrand: that's a one liner
<zyga> jdstrand: if you can review that quickly it would make it into the next release
<elopio> ogra_, kgunn : we were talking to Robert Wolff from linaro yesterday. He has a live show on thursdays, and he would like to talk about ubuntu core. Would you like to join him and show the dragonboard image and kiosk?
<ogra_> i havent used the dragonboard image as kiosk setup yet ... only pi
<elopio> ogra_: you can just present the image part. And leave the kiosk part to kgunn .
<ogra_> hmm ... k
<elopio> he apparently wants to do two or three separate shows.
<ogra_> when would that be (i assume not ad-hoc tomorrow ?)
<elopio> ogra_: he said february. The 2nd or 16th, I think.
<ogra_> that works
<elopio> and I'm not sure about the third show. Maybe we can talk about snapcraft, but that's not really related to the dragonboard. We would have to make something up.
<elopio> ogra_: great! I'll tell him. I can help you if you need something, and maybe kyrofa too (?).
<elopio> we can at least join the video conference and cheer you.
<ogra_> cool, just get me in the conversation loop
<elopio> yes. He said he will send more details on Friday. And he even mentioned about giving away some dragonboards with ubuntu core preinstalled to the attendees :)
<ogra_> whee !
<elopio> well, to a few attendees.
<elopio> ogra_: and what about making an ubuntu testing day with us on the 10th ? :D
<ogra_> elopio, sure
<elopio> ogra_: woohoo, you will get many new fans :) Please choose a time that's good for you on the 10th, and I will add it to the ubuntu on air calendar.
<ogra_> 14:00 UTC
<ogra_> (or later)
<elopio> ogra_: I think 14 it's too early for kyrofa. 16UTC ?
<ogra_> thats fine
<kyrofa> elopio, ogra_ yes thank you :P
<jdstrand> zyga: looking
<azubieta> noise][: I'm still working with your sample store, now i'm traying to use the download functionality but i'm getting the following error from the snapd: "error: Get : unsupported protocol scheme """
<azubieta> noise][: any ideas ?
<noise][> was that on doing 'snap install foo'? and what did you set for the URL in /etc/environment?
<azubieta> noise: my /etc/environment "SNAPPY_FORCE_CPI_URL=http://localhost/api/v1/"
<azubieta> noise][: and i was running snap download
<noise][> azubieta: is your snapstore running on port 80? default is 5000, i.e. SNAPPY_FORCE_CPI_URL=http://localhost:5000/api/v1/
<noise][> but as noted before, you will still get blocked after that when snapd tried to download and verify assertions for the local snaps ("error: cannot fetch snap signatures/assertions")
<azubieta> noise][: so i can't use the download command either ?
<noise][> it does successfully download the snap and then fail after trying to get the assertion
<azubieta> noise][: so i'll not get my file to later run snap install on it
<noise][> so e.g. this is working for me: snap download foobar25; snap install foobar25_1.snap --dangerous
<azubieta> noise][: mmm, which code are you using? the master branch on github ?
<noise][> metadata_tests branch
<noise][> i need to find a bit of time to get that merged
<azubieta> noise][: letme try with that
<mterry> niemeyer: hello, I'm trying to pick up the unity8 interface work that tedg started.  kgunn suggested to me that I try to land an incomplete version of it in snapd and iterate on it from there to at least drive down apparmor warnings, even if it doesn't work yet.  It seems that you folks generally prefer things to land only once they're complete, but I was
<mterry> curious if you had particular feelings on the above strategy in unity8's case.  The current WIP branch doesn't let apps run confined yet, but having it in trunk--even partially--might ease releasing our own apps that try to use it unconfined since it would be a known interface
<jdstrand> mterry: note that it being a known interface should not be a problem with the store. I have added a special case in the review tools so that the 'unity8' does not block approval
<mterry> jdstrand: ah cool, I thought we were able to land in edge only.  That's good news
<mterry> Well driving down warnings and getting wider testing are still reasons to maybe land a partial interface
<jdstrand> mterry: my two cents if niemeyer agrees> I would try to focus on slot side permanent policy and not do any policy for plugs. make it so you can run unity8 in strict mode so that your apparmor policy denials are gone
<mterry> But I don't know the side effects of updating an interface after the fact
<azubieta> noise][: it seems that my snap command is ignoring the port on the enviroment path and is giving my the following error: cannot find snap "bar": Get http://localhost/api/v1/snaps/details/bar?channel=: dial tcp [::1]:80: getsockopt: connection refused
<jdstrand> mterry (cc niemeyer): then we document that the interface allows unity8 to run but doesn't allow snaps to connect to it yet. this way, the interface offers no 'holes' in the security policy. you install it and apps in devmode
<mterry> jdstrand: the slot side policy, it looked to me like it's only used once there is at least one connection to a plug?
<jdstrand> mterry: there are slots and plugs and there is permanent and connected policy
<mterry> jdstrand: but OK that's good advice, I had been coming at the problem from the other side (the plug side)
<mterry> jdstrand: ah right that makes sense
<jdstrand> mterry: permanent slot policy is the policy that is needed for the snap to run at all. connected slot policy and connected plug policy are what are used to make snaps talk to each other
<mterry> jdstrand: well OK that's a strategy I can pursue.  Doesn't help the apps for a while, but I think getting closer to landing anything is good
<niemeyer> mterry: Heya
<niemeyer> mterry: We actually always land big changes in small chunks rather than at once
<zyga> jdstrand: thanks for the review :)
<noise][> azubieta: did you restart snapd after fixing the port in the config? (sudo service snapd restart)
<jdstrand> mterry: I suspect you would be able to easily add some connected policy for common cases
<jdstrand> mterry: eg, for say something simple like a calculator to run (ie, don't need the whole breadth of Touch policy)
<niemeyer> mterry: So polishing over time seems fine.. we should also have that strictly bound to unity8 itself via assertions, so the risk of creating problems by the organic landing is pretty much nil
<azubieta> noise][: yes! twice
<jdstrand> mterry: that would cut down the policy denials by a huge amount. then chip away at the various wervice sin followup PRs
<jdstrand> s/wervice sin/services in/
<jdstrand> zyga: np
<azubieta> noise][: "snap find bar" does work but "snap download bar" desen't
<jdstrand> mterry: by assertions, niemeyer is saying make the base declaration restricted such that a snap declaration is required to use the interface at all
<jdstrand> mterry: then in the store we say what snaps can connect to unity8
<mterry> niemeyer, jdstrand: OK.  So I'll work on a bare bones (maybe empty) starting unity8 interface (that is restricted by assertion) and work that to a landing (so we can remove jdstrand's special case in the store at least).  Then I can focus on the slot side, and eventually plug side over future PRs
<jdstrand> mterry: at a later date we lift the base declaration restriction when the interface is deemed 'safe'
<azubieta> noise][: by the way my "snap --version snap    2.20+git44.gdf4776c05 snapd   2.20+git44.gdf4776c05 series  16 debian  9"
<jdstrand> niemeyer: that's a nice idea for rolling out a partial interface btw
<zyga> jdstrand: please add this to your queue, unfinished but I'd like to see what you think: https://github.com/snapcore/snapd/pull/2718
<zyga> jdstrand: as well as (lower priority) https://github.com/snapcore/snapd/pull/2658
<jdstrand> zyga: the second is in the queue. thank you for letting me know its relative priority
 * jdstrand adds 2718
<zyga> jdstrand: thanks
<ahoneybun> mhall119: https://github.com/nickgermaine/Eden-Browser.git
<ahoneybun> that would be cool with sitter's new kde fw snap content
<azubieta> noise][: sorry i went offline, I was testing in another enviroment, I had to reboot the whole system in order to make it work now i'm getting the same error as you but the snap is being downloaded
<noise][> azubieta: great! i mean as far as things are at the moment at least :)
<azubieta> noise][: thanks !! I'll keep working on the store I'm considering make an interface for management with django
<kyrofa> mwhudson, console-conf is taking foreeeeevvvvvaaaar to contact the store on the dragonboard. What exactly is happening?
<mwhudson> kyrofa: i don't know!
<mwhudson> kyrofa: it doesn't happen all the time
<kyrofa> Oh you've experienced this as well?
<mwhudson> yes
<kyrofa> Huh.
<mwhudson> but never when i've got SNAPD_DEBUG_HTTP=4 or whatever it is set
<kyrofa> Interesting!
<mwhudson> kyrofa: as far as i can tell it's just the something in the networking stack being really slow
<kyrofa> I hate those turn on debugging -> problem goes away problems
<mwhudson> kyrofa: have a look in syslog/journalctl after it completes?
<kyrofa> mwhudson, sure thing
<mwhudson> (assuming it does, iirc it always does for me)
<mwhudson> can take 2-3 mins though
<kyrofa> Took me like 10. But yeah, for the second time, completes fine
<mwhudson> huh
<kyrofa> mwhudson, is the wifi useless for you, too?
<mwhudson> kyrofa: um, it kinda works sorta, i haven't pushed it a lot?
<mwhudson> i also haven't tried anything at all with it for a good few weeks
<kyrofa> mwhudson, whenever I made it "do" anything (enable classic, or apt update in classic) it just goes down. I reflashed to I could run console-conf again on my ethernet adapter instead
<mwhudson> kyrofa: hmm
<mwhudson> kyrofa: lovely lovely devboard experience i guess
<kyrofa> mwhudson, I see a LOT of these types of messages: /usr/lib/snapd/snapd[1510]: booted.go:81: cannot get info for "dragonboard-kernel": cannot find snap "dragonboard-kernel"
<kyrofa> Normal?
<ogra_> kyrofa, bug 1638537
<kyrofa> (just looking for out-of-the-ordinary things that could cause the slowness)
 * ogra_ tickles the bot
<kyrofa> ogra_, yeah it's been sad the last few days
<ogra_> its been sad forever
<kyrofa> ogra_, oh!
<ogra_> oh, i meant thee image, not the bot :)
<kyrofa> Well, "please press enter" actually came up pretty quick for me. Everything works fine until I enter my SSO email address and hit "go"
<ogra_> yeah
<ogra_> the press enter comes up fast since we started generating the pyc files at image creation
<kyrofa> Ahh, okay
<ogra_> but snapd is still eating the system
<mwhudson> also the dragonboard is ~10 times faster than a bbb :)
<ogra_> its all snappy and fast once it is through console-conf
<kyrofa> Yikes
<ogra_> mwhudson, i see it on all arm boards
<kyrofa> Wonder what snapd is doing
<ogra_> producing I/O :)
<kyrofa> Hahaha
<kyrofa> ogra_, is /etc/network writable?
<ogra_> hmm, might only be /etc/network/interfaces.d ... one sec
<kyrofa> Yeah that's really what I was asking-- can I still configure interfaces that way?
<ogra_> ogra@localhost:~$ grep network /etc/system-image/writable-paths
<ogra_> bah
<ogra_> sill yIRC
<ogra_> ogra@localhost:~$ grep network /etc/system-image/writable-paths
<ogra_> /etc/network/interfaces.d               auto                    persistent  transition  none
<ogra_> /etc/network/if-up.d                    auto                    persistent  transition  none
<ogra_> /etc/systemd/network                    auto                    persistent  transition  none
<ogra_> there we go
<pedronis> kyrofa: that message is because until we are first booted, the kernel and core refs in the boot loader env don't make sense to snapd yet... IÂ think we can avoid those though
<kyrofa> Oh! I didn't know that file existed, awesome
<ogra_> i'm about to move it one level up though
<kyrofa> pedronis, I was just trying to figure out what was causing the slowdown. Do you think that's it?
<pedronis> I don't know
<pedronis> just saying that for sure it will spam logs
<pedronis> which is bad anyway
<kyrofa> Indeed
<kyrofa> Well, the slowdown doesn't provide for the best out-of-the-box experience. https://bugs.launchpad.net/snappy/+bug/1638537 has no responses
<ogra_> there iis a trello card ... i guess an strace session is due
<ogra_> it could be related to netplan/console-conf updating the network but not really switching to the new config without reboot
<ogra_> you get an IP thats coming from networkd on boot before console-conf runs ... usually the system keeps that instead of downing/upping the interface
<ogra_> i could imagine that snapd gets confused by that or so
<ogra_> niemeyer, looks like mup dropped off here ...
 * ogra_ vanishes into the night again
#snappy 2017-01-26
<kyrofa> ogra_, I suppose you're long gone into the night?
<kyrofa> ogra_, when you get in tomorrow: how hard would it be to fix https://bugs.launchpad.net/snappy/+bug/1650207 ? No ROS stuff will build in classic mode
<kyrofa> Oh, it's writable in classic, handy
<stokachu> if i have an additional top level command 'conjure-down' for this do i need to register with the store to have that alias created?
<mhall119> ahoneybun: it would be better off with a Qt5 part, it doesn't need all of KDE
<mup> PR snapd#2666 closed: interfaces: add ability to set system time zone to timeserver_control interface <Created by justincan> <Closed by justincan> <https://github.com/snapcore/snapd/pull/2666>
<mup> PR snapd#2679 opened: Ubuntu/14.04 <Created by vosst> <https://github.com/snapcore/snapd/pull/2679>
<mup> PR snapd#2585 closed: debian: move systemd files out of ./debian and into ./data/systemd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2585>
<mup> PR snapd#2680 opened: interfaces: shutdown: also allow shutdown/reboot/suspend via logind <Created by morphis> <https://github.com/snapcore/snapd/pull/2680>
<mup> PR snapd#2681 opened: tests: only build test binaries if they are not present <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2681>
<diddledan> jdstrand: I may have an idea why other snaps than my own corebird-diddledan aren't able to launch URLs via xdg-open. I need to test it, but I did NOT build my snap with the snapd-glib interface but bundled glib into my snap directly
<zyga> o/
<zyga> diddledan: hey, I think this part is broken/needs love
<zyga> diddledan: it's on our roadmap but always has low priority and gets postponed
<zyga> mvo: ^^ FYI
<zyga> (snapd-xdg-open)
<diddledan> zyga: the confusing bit was my own snap works as it should, but jdstrand had noticed other snaps not working correctly which prompted questions as to what was different about my snap that made mine work
<zyga> diddledan: so to make it work you need two pieces
<zyga> diddledan: and because it has been a bit neglected we don't have a well designed responsiblity as to who owns them
<zyga> diddledan: on the desktop side you need snapd-xdg-open installed, in theory snapd should recommend that on the destkop
<zyga> diddledan: on the othoer hand, core snap (or ubuntu-core) should ship the shim xdg-open from snapd-xdg-open
<zyga> diddledan: AFAIK neither are true now
<zyga> diddledan: if you install snapd-xdg-open on your desktop manually
<zyga> diddledan: and build and install the shim in your snap manually
<zyga> diddledan: then I believe, apart from bugs in the actual shim, it should work
<zyga> diddledan: it's just not what we want people to have to go through :/
<diddledan> zyga: I only installed snapd-xdg-open. jdstrand tested on his system so it's not something specific to my system
<diddledan> zyga: as I say, corebird-diddledan WORKS CORRECTLY. it is OTHER snaps ON THE SAME SYSTEM WHERE MINE WORKS that fail
<diddledan> I wasn't shouting there, but wanted to highlight the important bits, sorry if it appears aggressive - wasn't meant to be
<zyga> diddledan: no, that's fine
<zyga> diddledan: if corebird works ok but others don't then I suspect they don't ship the shim
<diddledan> I don't ship the shim in mine
<diddledan> I did absolutely nothing special apart from installing snapd-xdg-open on the host
<zyga> diddledan: feels like magic, is there xdg-open in the core/ubuntu-core snap?
<diddledan> but even if it is in the core snap, that would suggest that other snaps should also work when they currently do not ON THE SAME SYSTEM
<diddledan> ok, the xdg-open shim is NOT in core NOR is it in corebird-diddledan
<diddledan> it doesn't exist
<diddledan> at all
<zyga> diddledan: as I said, this story is neglected, I may be missing something, those other snaps may have tried to make it work but did something that made it more roken
<zyga> *broken
<diddledan> yeah that's what we want to understand. the WHY
<diddledan> personally I'm happy that mine works. for the project it needs to be understood what is different
<zyga> diddledan: hmm
<zyga> diddledan: is your snap classic?
<zyga> diddledan: (it should never work then)
<zyga> diddledan: how do you observe it working?
<zyga> diddledan: (in any case, there's a well-known list of things to do to fix this)
<zyga> diddledan: do hello-xdg-open snap
<zyga> diddledan: I bet it won't work if you run xdg-open
<zyga> diddledan: maybe there's a dbus service that also opens URLs that is somehow allowed via unity
 * zyga has huge lag to IRC network
<diddledan> my snap is strict confinement
<diddledan> I observe it working by clicking links or other actions that open a url directly from corebird
<zyga> diddledan: and then your browser opens?
<zyga> diddledan: I don't have time to investigate this now
<zyga> diddledan: if you want to do that, I suggest stracing your application to see if it fork/execs something
<diddledan> yes it does
<diddledan> well blow me down. it's _stopped_ working now
<diddledan> I've not changed _anything_ and now it no longer works
<zyga> well, at least that is good
<zyga> it should not have worked
<zyga> did you run the app outside of confinement / sandbox by any chance
<zyga> e.g. running it directly from /snap/$SNAP_NAME/current/...
<diddledan> I'm unsure now
<zyga> well,
<zyga> do what I suggested
<zyga> you may get it to work for real then
<ogra_> hmm, still all bots gone
<niemeyer> mup: you ok?
<mup> niemeyer: I really wish I understood what you're trying to do.
<ogra_> bug 12345
<mup> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> <https://launchpad.net/bugs/12345>
<niemeyer> ogra_: mup back with its usual mood
<ogra_> yeah, looks fine
<mup> PR snapd#2724 opened: overlord,tests: have enable/disable affect security profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/2724>
<mup> PR snapd#2725 opened: overlord/ifacestate: use ParseConnRef <Created by zyga> <https://github.com/snapcore/snapd/pull/2725>
<mup> PR snapcraft#1079 opened: Add snapcraft plugin for Qt Build Suite (qbs) <Created by dpniel> <https://github.com/snapcore/snapcraft/pull/1079>
<mup> Bug #1659534 opened: userdel doesn't supports extrausers <Snappy:New> <shadow (Ubuntu):New> <https://launchpad.net/bugs/1659534>
<mup> PR snapd#2726 opened: interfaces: core-support: also allow enable/disable of a systemd unit <Created by morphis> <https://github.com/snapcore/snapd/pull/2726>
<mup> PR snapd#2725 closed: overlord/ifacestate: use ParseConnRef <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2725>
<zyga> kirkland: hey, any update on that bug?
<zyga> er
<zyga> kissiel: ^
<zyga> (sorry kirkland)
<kissiel> zyga: https://bugs.launchpad.net/snapd/+bug/1659272; nope; @ mtg
<mup> Bug #1659272: dbus access denied in nested python  <snapd:New> <https://launchpad.net/bugs/1659272>
<zyga> kissiel: thanks
<jdstrand> kyrofa: hi! remember the ca-certificates-java thing? I have an extra clue. if I build a snap that stage-packages openjdk-8-jre-headless and ca-certificates-java but doesn't have either of those installed on the system as debs, I get snapcraft creating a dangling symlink:
<jdstrand> /home/ubuntu/snappy-apps/minecraft-snap/parts/minecraft/install/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts will be a dangling symlink
<zyga> jdstrand: hey, morning :)
<jdstrand> kyrofa: if I use the same stage-packages but install the debs on the system, snapcraft finds it and uses the system one and the snap is fine:
<jdstrand> Copying needed target link from the system /etc/ssl/certs/java/cacerts
<jdstrand> hey zyga :) fyi 2718 and 2658 are at the top of my list today
<zyga> jdstrand: no worries, we're busy with a release :)
<zyga> jdstrand: the update-ns PR is does not need a deep review now (it should not land yet), I just wanted to get first impression
<zyga> *impressions
<jdstrand> ok
 * kirkland waves at zyga
<stokachu> slangasek, what day does the SRU team normally process verification-done bugs?
<stokachu> slangasek, or if you could flip the bit on snapd 2.21 so it'll make it into xenial-updates today that would be even better :)
<mhall119> rmescandon: ping, I saw that you have a Solr snap in the store, have you been in contact with the upstream to see if they will adopt it?
<rmescandon> mhall119, nope
<rmescandon> mhall119, https://issues.apache.org/jira/browse/SOLR-10044
<jdstrand> mhall119: hey, fyi, I issued snap declarations for dbus for two kde snaps and approved them, but they still need to be released (btw, why isn't apachelogger here?)
<rmescandon> mhall119, no problem in moving code to another organization/place if needed
<slangasek> stokachu: the SRU team releases SRUs Mon-Thu; I'll look at snapd now
<stokachu> slangasek, awesome ty!
<morphis> ogra_: how do I do a let n=n+1 with /bin/sh?
<ogra_> morphis, n=$((n+1))
<morphis> ok!
<morphis> ogra_: thanks
<ogra_> np :)
<mhall119> thanks rmescandon
<mhall119> thanks jdstrand
<ogra_> morphis, you kept "let n=n+1" in the upper function ...
<morphis> uups
<ogra_> also check if it works with non-integers ... i'm not sure it does
<ogra_> (or probably set wait_time=1 instead)
<ogra_> ogra@localhost:~$ n=$((n+0.1))
<ogra_> -bash: n+0.1: syntax error: invalid arithmetic operator (error token is ".1")
<ogra_> yeah
<morphis> ogra_: can you comment that in the MP?
<mup> PR snapd#2727 opened: overlord/ifacestate: register all security backends with the repository <Created by zyga> <https://github.com/snapcore/snapd/pull/2727>
<ogra_> morphis, oh, sorry, i mis-took wait_time for wait_attempts ... all good
<morphis> ok :-)
<ogra_> morphis, btw, probably good to bookmark this https://wiki.ubuntu.com/DashAsBinSh has all the POSIX vs bashism bits
<ogra_> (including let)
<morphis> ogra_: thanks
<Chipaca> morphis, o/
<Chipaca> morphis, dunno if my review made sense
<Chipaca> the `while $n -lt 10 $wait_attempts ! is_ssh_unit_enabled` line is fairly borked :-)
<morphis> Chipaca: thanks
<kyrofa> jdstrand, interesting-- the broken symlink is an absolute one, I assume?
<jdstrand> kyrofa: it points to /etc/ssl/certs/java, yes
<jdstrand> which doesn't exist in core
<jdstrand> the review tools notice that, but a locally installed snap user might not
<kyrofa> jdstrand, indeed... hmm. Perhaps the repo should be rewriting stage package symlinks
<mup> PR snapd#2728 opened: tests: add extra debugging to security-setuid-root test <Created by zyga> <https://github.com/snapcore/snapd/pull/2728>
<kyrofa> Hey ogra_, how hard of a bug is https://bugs.launchpad.net/snappy/+bug/1650207 ?
<ogra_> kyrofa, i landed a potential fix for it today ... not sure if mvo did re-build the edge core snap already since
<ogra_> there was a release going on today to i didnt touch the build button
<kyrofa> And will the fix mean that /etc/lsb-release is different in the core snap, or only in the classic shell?
<kyrofa> ogra_, awesome, thanks for working on that :)
<ogra_> kyrofa, in the classic shell
<kyrofa> ogra_, will it be exactly xenial's, then?
<ogra_> but the classic shell tarball is created during build of the core snap ;)
<ogra_> the classic snap just unpacks it
<ogra_> so the fix is in the core snap build itself
<kyrofa> I suppose that does make sense. So they're intrinsically tied, eh?
<ogra_> yes
<ryebot> Are there docs for the snapd-control interface?
<ogra_> the tarball contains all bits that we rip out during build :)
<ryebot> not a pressing thing, just curious about it
<kyrofa> ogra_, heh. So the /etc/lsb-release in the classic shell will be exactly xenial's?
<ogra_> if the fix works, yes
<kyrofa> ogra_, excellent, thanks for the update!
<ogra_> havent tested it yet ... i simply "dpkg -i" the original base-files package
<kyrofa> ryebot, what kind of documentation are you looking for?
<ogra_> (but i'm not 100% sure it will overwrite the modified lsb-release file ... thats up for testing still)
<ryebot> I just want to know what it can do, more or less
<kyrofa> ryebot, we have an Interfaces wiki: https://github.com/snapcore/snapd/wiki/Interfaces#snapd-control
<kyrofa> But it doesn't say much
<ryebot> Does it allow you to launch other snap's apps?
<kyrofa> ryebot, it allows the snap to talk to the snapd socket (install/update/remove snaps over REST API)
<kyrofa> ryebot, no
<mup> PR snapd#2729 opened: tests: use test snap <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2729>
<ryebot> okay, understood; thanks for the typically quick response :)
<kyrofa> ryebot, that interface is used for example by snapweb. Have you used that?
<ryebot> I have, yes
<ryebot> I was toying with the idea of writing a snap that hooked into custom urls to install/launch other snaps
<kyrofa> ryebot, that's a confined snap, but it allows you to search for/install snaps by talking to snapd. The only way it can talk to snapd like that is via the snapd-control interface
<ryebot> makes sense
<kyrofa> ryebot, I think such a utility would need to be outside confinement. It sounds like the snap-xdg-run utility that supports opening URLs from snaps
<kyrofa> (not sure that's actually what it's called... but it's something like that :P )
<ryebot> oh cool, thanks, I'll look into that
<kyrofa> ryebot, talk to jdstrand, he knows all
<ryebot> :D
<jdstrand> ryebot: snapd-control does not allow launching other snaps. nothing does in strict confinement atm. snapd-xdg-open allows running a url handler, but that isn't tied into snaps yet
<ryebot> that's understandable
<mvo> ogra_: not rebuild anything yet, feel free to do that
<jdstrand> ryebot: you are probably interested in https://bugs.launchpad.net/snappy/+bug/1639746
<mup> Bug #1639746: Snap launching other snaps <snapd-interface> <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1639746>
<ryebot> jdstrand: yep! just signed up, thanks :)
<jdstrand> ryebot: the point of confinement is that snaps can't interfere with each other. transitioning from one confinement to another while honoring that requirement is tricky
<kyrofa> ogra_, if you happen to get a new classic into edge, I'd be happy to test it
<ogra_> kyrofa, core you mean :)
<ogra_> it is all in core
<kyrofa> ogra_, well, both, right? :P
<ogra_> nope
<ryebot> jdstrand: yeah, no doubt
<kyrofa> ogra_, wait... how does the classic snap update?
<kyrofa> ogra_, so the classic snap literally installs and then unpacks something that core is holding onto?
<kyrofa> I thought you extracted that from core and put it into the classic snap, they were just released in lockstep
<ogra_> the classic snap unsquashes core ... then unpacks the tarball (from insiode core) on top
<ogra_> if classic gets updated nothing happens
<kyrofa> ogra_, what if I've already run that step? Will classic notice it's out of date?
<ogra_> no, we dont fiddle with developer chroots once they are created
<ogra_> its up to you to apt update/upgrade it then
<kyrofa> ogra_, ah interesting. So if I've already created that chroot, will an apt upgrade get me a new /etc/lsb-release?
<ogra_> nope
<kyrofa> ogra_, can I kill the chroot and re-create it, then?
<ogra_> apt-get install --reinstall base-files perhaps
<ogra_> yeah
<ogra_> that should work
<kyrofa> ogra_, where is it, so that I can kill it?
<ogra_> snap remove classic
<ogra_> ;)
<kyrofa> Oh, well.
<ogra_> its in the common dir of the classic snap
<kyrofa> ogra_, perfect, thank you. Okay so then: if you happen to publish a new core snap with this change, please let me know, I've got a dragonboard setup I can use to test it
<ogra_> ok
<kyrofa> ogra_, thanks for the explanation, I understand classic mode quite a lot more now
<ogra_> i just triggered a new core build ... in ~30min there should be a new one in edge
<stokachu> slangasek, thanks for the push to updates
<stokachu> question, I'm about to upload a new revision of my conjure-up snap that has a new binary called 'conjure-down' do I need to ask someone to register an alias to conjure-down?
<kyrofa> stokachu, good question. Do you already have an alias?
<kyrofa> stokachu, I mean, do your aliases already auto-connect?
<stokachu> kyrofa, not that i know of
<stokachu> so i have https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml
<kyrofa> Ah, then you don't need to talk to anyone. You can declare interfaces all day long, but snapd won't automatically enable them for you (or your users) without someone flipping a switch in the assertion store-side
<jdstrand> stokachu: you can have as many aliases as you want to declare. users manullay add them to the system so there is nothing to worry about on the store end. only if you weant the alias auto-added do you need to ask a reviewer to grant that to you
<kyrofa> Argh, not interfaces-- aliases
<kyrofa> I type that word too much
<jdstrand> man, I can't type
<stokachu> so i would like to have them auto connected, do i need to upload the snap with the alias defined beforehand?
<kyrofa> jdstrand, you always make me feel better
<jdstrand> kyrofa: thanks? :P
<kyrofa> jdstrand, :P
<jdstrand> stokachu: it doesn't matter
<kyrofa> I suspect just uploaded PERIOD so it has an ID
<stokachu> jdstrand, so i want to create the conjure-down alias for https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml#L15
<stokachu> my snap is already uploaded it just doesn't have that latest build
<jdstrand> stokachu: done
<stokachu> jdstrand, awesome ty!
<stokachu> now that 2.21 is in xenial-updates i can finally flip the switch to pure snap of conjure-up
<stokachu> well classic snap anyway
<stokachu> jdstrand, do i still need to add the aliases: [conjure-down] in my snapcraft?
<stokachu> snapcraft.yaml*
<jdstrand> stokachu: yes
<kyrofa> jdstrand, are aliases individually granted? Or do you just say "yes, this snap can automatically have any aliases it declares"?
<stokachu> perfect thanks
<mup> PR snapd#2730 opened: snap: be more helpful in the `snap install <already-installed>` error message <Created by mvo5> <https://github.com/snapcore/snapd/pull/2730>
<jdstrand> stokachu: you have to let snapd know what the aliases are. once it knows what they are, it looks at the snap declaration to see what to auto add
<stokachu> jdstrand, ack, makes sense ty
<niemeyer> jdstrand: ping
<jdstrand> niemeyer: hey
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Today we've been having a long debate about the configure script for core
<niemeyer> jdstrand: Lot's of back and forth on several details
<niemeyer> jdstrand: By now it's getting pretty obvious that we want direct systemctl access on it
<jdstrand> niemeyer: morphis let me in a few of those details
<jdstrand> niemeyer: I thought he was able to use dbus-send fine?
<niemeyer> jdstrand: I know you were against that, and I could see why.. wondering if some of your worries are relieved by having the interface as core-support
<niemeyer> jdstrand: No, that was the first impression, but it's actually very messy
 * jdstrand notes he say later commits to his hook
<niemeyer> jdstrand: We can't easily tell the result of the call.. the original hook was doing stop, but we really want stop+disable
<niemeyer> jdstrand: So there's a loop in there, which isn't nice because it's waiting regardless of knowing why
<niemeyer> etc etc
<niemeyer> jdstrand: So the proper thing to do was to wait for the job, as systemctl does, ...
<niemeyer> jdstrand: This is getting unwise to pursue, IMO
<jdstrand> niemeyer: from my perspective, the security policy is clean right now with core-support, and that was my primary concern. the fact that only core can use it is important, yes, but systemctl isn't written with mediation in mind, so I didn't like all the extra unrelated security policy
<jdstrand> niemeyer: if you want systemctl, then just put systemctl Uxr, in the policy
<jdstrand> niemeyer: then we aren't pretending anything with the confinement
<niemeyer> jdstrand: +1
<niemeyer> jdstrand: Given this is just an extension of snapd, I think that's okay
<jdstrand> 'Uxr' says systemctl can run unconfined
<niemeyer> jdstrand: It's not quite ideal, but an excellent start IMO
<niemeyer> jdstrand: The high-level goal of that one setting is precisely to have a properly abstracted way to enable and disable ssh in pure snap systems
<jdstrand> niemeyer: it is good for the configure hook. it is poor from a security policy perspecitve. it is acceptable based on base declaration restrictions
<niemeyer> jdstrand: If we render it technically flaky, or end up giving up altogether and putting the logic into the snapd binary proper, it won't be any better
<jdstrand> niemeyer: this achieves that goal, but does not restrict it to only that goal
<jdstrand> which is what I really didn't like
<niemeyer> jdstrand: It doesn't on itself, but arguably the configure of core, specifically, is bound to be doing system-level configuration on behalf of the user and of other snapd that have snapd access
<jdstrand> there are ways to do stopping/starting/disabling/enabling services properly, but that couldn't be implemented today
<jdstrand> niemeyer: that's why I said the base declaration makes it 'acceptable'
<niemeyer> jdstrand: Ok, thanks
<niemeyer> jdstrand: Let's move on with this then, and learn our lessons on the way
<jdstrand> niemeyer: can someone ping me on the updated PR if this is time-sensitive?
<niemeyer> jdstrand: It is time sensitive, and morphis plans to be doing work on it tomorrow morning
<niemeyer> (his)
<niemeyer> jdstrand: I'll mail him with the outcome of our conversation and one more detail today
<jdstrand> roadmr: hi! would you mind pulling r833 of the review tools. it isn't terribly urgent (next week would be 'ok'). sonner is better, but don't feel like you have to do extraordinary measures
<jdstrand> roadmr: also, I had the idea of shipping the review tools as a snap and floated that out to cprov. He loved it. that would allow staging to point at edge and prod stable and then no more pulls
<jdstrand> sergiusens: this also means snapcraft could call the review tools if the command was available (ie, the snap installed) and we'd never have to worry about an out of date deb
<jdstrand> sergiusens: ^
<jdstrand> sergiusens: you could finally run the review tools and have confidence that what they and the store report was the same
<roadmr> jdstrand: awesome idea on the snap!!!!
<cprov> jdstrand: yup, instead of channels we we actually need refresh-control server side, but having the review-tools as a snap will be definitely an improvement
<roadmr> jdstrand: having the service be mutable and update some component out-of-release-cycle sounds a bit scary, we try not to have mutable services, but totally worth a think. cprov this would be my main concern
<roadmr> (so don't think I'm opposed, on the contrary, but we need to consider implications)
<roadmr> jdstrand: also... sure, r833 coming up in a sec !
<jdstrand> roadmr: a nice property is that the review tools run confined
<jdstrand> moving to a snap is not super soon in the queue, but I'll let you guys know when it is then you can start using it whenever you want
<roadmr> thanks jdstrand ! yes, because it'll have implications on how the service is deployed and hosted. Weighing immutability vs. confination will make for a fun exercise
<jdstrand> roadmr: I was mostly saying that it is a benefit. wasn't arguing immutability
<roadmr> jdstrand: yes, I absolutely agree on the benefit of confination
<roadmr> jdstrand: hehe so again please don't take my ramblings as any sort of pushback, I think it's an awesome idea and once the snap is available I'm happy to push for that to be the way we use the tools. I'll find a way to deal with any other concerns
<jdstrand> sounds great :)
<mup> PR snapd#2717 closed: interfaces: builtin: mir: allow recv and send <Created by albaguirre> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2717>
<mup> PR snapcraft#1076 closed: autotools: extend Make plugin instead of repeating code <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1076>
<KristijanZic> Hello, got one question
<kyrofa> Hey there KristijanZic, fire away :)
<KristijanZic> Does snappy hard depend on Systemd? Could it be ported one day to BSD?
<KristijanZic> kyrofa: ^
<kyrofa> KristijanZic, at the moment yes, systemd is a hard dependency. But the spec doesn't require it
<kyrofa> KristijanZic, when one writes a snap that declares a service, the keys one uses to describe the service behavior (simple daemon, forking, etc.) would need to be satisfiable by the given system, and snapd would need to support it
<mup> PR snapcraft#1080 opened: python plugin: avoid the use of PYTHON* env vars <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1080>
<kyrofa> KristijanZic, as of right now, the only system supported is systemd
<kyrofa> KristijanZic, but that may be refactored at some point
<dstolfa> kyrofa, it would be beneficial to make it extensible so that other service management systems could easily be hooked in with a form of a plugin or something. Once they're stable enough, potentially upstreamed
<KristijanZic> kyrofa: ah, not what I was hoping for but I hope that gets redesigned.
<sergiusens> jamespage, stokachu, marcoceppi_ hey, mind testing this branch https://github.com/snapcore/snapcraft/pull/1080 ? It sort of solves the PYTHON* env var leaking but want to be sure it still works for you
<mup> PR snapcraft#1080: python plugin: avoid the use of PYTHON* env vars <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1080>
<KristijanZic> kyrofa, thanks! :)
<kyrofa> dstolfa, I wholeheartedly agree, but there's always work to be done. The question is the priority that should be associated to such work
<marcoceppi_> sergiusens: how do I test that branch? you got a snap ;)
<dstolfa> kyrofa, well, it could be done in a privsep way, that is separating the actual plugin that does it into different components, such as systemd, launchd, SMF, ..., and then have the standard functionality that it needs to provide. Somewhat similar to what the MAC framework does in FreeBSD. Now, that's probably not so much of an urgency, but I would be willing to write such a plugin once we have a service management system in place in FreeBSD(current w
<dstolfa> I believe that people would find use of it on Apple systems though, through launchd which can provide such behaviour
<sergiusens> marcoceppi_, from source right now; I intend to have a solid snap on classic thing going soon but this branch needs to get in first
<kyrofa> dstolfa, well, you're assuming that the REST of snapd's dependencies are available on such systems as well
<kyrofa> Which isn't necessarily the case
<marcoceppi_> sergiusens: I'll add it to my todo, won't have much time today
<kyrofa> dstolfa, I'm really talking about apparmor here
<dstolfa> kyrofa, I'm not aware of all the dependencies, is there a list somewhere?
<sergiusens> marcoceppi_, no problem, thanks
<kyrofa> dstolfa, the confinement tech isn't available everywhere
<kyrofa> dstolfa, in fedora they have selinux, for example
<dstolfa> Ah, well that's really just a form of access control, couldn't it be extensible?
<sergiusens> marcoceppi_, if not, give me your branch and tell me what to run to ensure it all works ok (to smoke it a bit)
<kyrofa> dstolfa, indeed, but you see how this blossoms
<dstolfa> That way, if someone wanted to, one could apply even things like grsec RSBAC to it
<dstolfa> kyrofa, well, it does. There is work to be done, but imo would be useful to do eventually, as the need arises :)
<kyrofa> dstolfa, right, I completely agree
<marcoceppi_> sergiusens: https://github.com/juju-solutions/charm-pkg it's here for now, need to move the snapcraft yaml into the project root now that I've removed all the weird workaround files
<marcoceppi_> sergiusens: once built and installed, try `charm version; charm create foobar; cd foobar; charm build`
<kyrofa> dstolfa, don't get me wrong, I think we can all agree we'd like to see snapd everywhere. But I'd rather have a good product in less places than a bad product everywhere because we devoted all our time to that
<marcoceppi_> sergiusens: if you get tracebacks, you know something went wonky
<dstolfa> The only requirement in doing so really, is just keeping the dependencies in check -- that is, not allowing dependencies to branch out too much, rather wrapping them so that it's an easier job later on.
<dstolfa> kyrofa, agreed there.
<marcoceppi_> sergiusens: just pushed up the latest changes
<dstolfa> Either way, be right back. Food :)
<sergiusens> marcoceppi_, thanks!
<mup> PR snapcraft#1081 opened: local source: preserve symlinks to directories <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1081>
<mup> PR snapd#2697 closed: cmd,snap,wrappers: systemd reload command support <Created by cyberb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2697>
<mup> PR snapd#2728 closed: tests: add extra debugging to security-setuid-root test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2728>
<mup> PR snapd#2696 closed: spread: set SNAPD_DEBUG=1 in the core snap as well <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2696>
<mup> PR snapd#2690 closed: daemon: add location header to reply for snap operations like install/remove <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2690>
<mup> PR snapcraft#1073 closed: project: snapcraft.yaml in a snap directory <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1073>
<sabdfl> evening
<qengho> o/
<mup> PR snapcraft#1082 opened: project: new plugin directory location <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1082>
#snappy 2017-01-27
<olympionex>  I'm having trouble running 'snap try' with snap/snapd vs 2.21 on 16.04.  The confinement is specified as classic and when I run 'snap try --classic' or 'snap try --devmode', I still get the error that it requires consent to use classic confinement
<telelaci> quit
<telelaci> exit
<telelaci> help
<telelaci> ?
<telelaci> shit
<mup> Bug #1659719 opened: ssh can't call a binary from a snap without the full path <Snappy:New> <https://launchpad.net/bugs/1659719>
<mup> Bug #1659724 opened: Feature request: give applications unrestricted access to d-bus services provided by the same snap <Snappy:New> <https://launchpad.net/bugs/1659724>
<ubuntunoddy> how to convert nodejs app to snap app
<mup> PR snapd#2729 closed: tests: use test snap <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2729>
<mup> PR snapd#2731 opened: store: always log retry summary when SNAPPY_TESTING is set <Created by mvo5> <https://github.com/snapcore/snapd/pull/2731>
<mup> PR snapd#2722 closed: tests: set SNAPPY_USE_STAGING_STORE in su call <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2722>
<mup> Bug #1659744 opened: Classic snaps 'not found' if --classic argument is missing <Snappy:New> <https://launchpad.net/bugs/1659744>
<mup> PR snapd#2732 opened: snapenv: do not append ":" to the SNAP_LIBRARY_PATH <Created by mvo5> <https://github.com/snapcore/snapd/pull/2732>
<mup> PR snapd#2733 opened: tests: make the debugging of c-unit-tests more useful <Created by zyga> <https://github.com/snapcore/snapd/pull/2733>
<mup> PR snapcraft#1082 closed: project: new plugin directory location <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1082>
<mup> PR snapd#2730 closed: snap: be more helpful in the `snap install <already-installed>` error message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2730>
<mup> PR snapcraft#1083 opened: project: support for gui in snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>
<mup> PR snapd#2734 opened: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2734>
<mup> Bug #1637299 changed: sudo snap login "Password:" prompt unclear what password to type <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1637299>
<mup> Bug #1633230 opened: snap ack doesn't indicate which assertions are good or bad <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1633230>
<mup> Bug #1633261 opened: snap ack should provide a summary of the assertions status <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1633261>
<mup> PR snapcraft#1084 opened: make: add support for cwd path to make() function <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1084>
<mup> PR snapcraft#1085 opened: snapcraft: fix or ignore PEP8 static errors <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1085>
<mup> PR snapcraft#1086 opened: print snapcraft's version on startup when running with --debug <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1086>
<mup> PR snapd#2721 closed: tests: integration test  for system reload <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2721>
<popey> I have a build which is failing in launchpad. Seems the 'sudo chroot' bit at the bottom barfs.. https://launchpadlibrarian.net/304085507/buildlog_snap_ubuntu_xenial_amd64_openbazaar_BUILDING.txt.gz
<popey> one for cjwatson perhaps ^ ?
<cjwatson> package context: unrecognized import path "context" (import path does not begin with hostname)
<cjwatson> that's the actual failure
<cjwatson> the rest is just consequential errors
<cjwatson> popey: ^-
<cjwatson> and that's something in your snap
<popey> hm
<popey> thanks for looking.
<mup> Bug #1658909 changed: lsb_release fails in classic (arm64) <Snappy:Confirmed for ogra> <lsb (Ubuntu):Invalid> <lsb-release (Ubuntu):Invalid> <https://launchpad.net/bugs/1658909>
<Elleo> I'm getting some very odd behaviour with gsettings under confinement, when the snap starts it reads them fine, but it seems to be unable to change them or to get notified of changes if I modify the gsettings manually (but it will pick up the changes after being restarted), anyone have any ideas what might be happening?
<Elleo> (it works fine when in devmode)
<mup> PR snapd#2482 closed: store: retry auth-related requests <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2482>
<morphis> ogra_: there?
<zyga> Elleo: do you get any apparmor denials
<zyga> Elleo: apparmor controls all dbus traffic
<zyga> Elleo: and notification is a distinct signal from read/write calls
<zyga> Elleo: dmesg | grep DENIED
<zyga> Elleo: and report that as a bug please
<jdstrand> I think it is something else
<zyga> jdstrand: hey :)
<zyga> jdstrand: what do you think?
<jdstrand> I suspect it is the bug where HOME is set to ~/snap/SNAP_NAME/SNAP_REVISION and the global dconf is in ~/.config/dconf. the policy allows it, but dconf is having trouble finding it
<mup> PR snapd#2733 closed: tests: make the debugging of c-unit-tests more useful <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2733>
<jdstrand> I think a symlink from  ~/snap/SNAP_NAME/SNAP_REVISION/.config/dconf to ~/.config/dconf would workaround it. my memory may be hazy. I think seb128 has the details
<jdstrand> zyga: nad hi :)
<Elleo> zyga: no denials, monitoring the gsetting it seems it does get written to, but then immediately gets changed back for some reason :/
<Elleo> zyga: unless I change it manually via gsettings, in which case it stays fine but doesn't get notified
<Elleo> popey: /32
<Elleo> popey: that bucklespring is a bit worrying :P
<Elleo> popey: isn't it basically exploiting the fact that x11 has zero security and acting like a keylogger?
<zyga> jdstrand: thanks for the review on the snap-update-ns draft; I'll fix the things you pointed out and focus on figuring out what is broken in the kernel
<ogra_> morphis, i'm back now
<zyga> jdstrand: while we don't hit that particular issue here (I suspect because we are not starting from a namespace already) I think that you are right in first having a clear understanding of what is at play
<seb__> Hi! Does any one know if it's possible to get the mac current out of the USB ports on a Raspberry pi 2? Used to do it with "usb_max_current=1"
<zyga> ogra_: ^
 * ogra_ doesnt know ... 
<morphis> ogra_: great :-)
<ogra_> seb__, where do you put that usually ? config.txt ? cmdline.txt ?
<zyga> seb__: let me grep one thing
<seb__> config.txt usually. New to snappy core
<ogra_> well, confi.txt is there, you can just edit it as needed ... it is mounted under /boot/uboot/
<seb__> really?!, ohh damn. Gotte go check that
<ogra_> (or directly if you plug the SD into your PC ... in the system-boot partition)
<ogra_> just make sure you dont drop anything of the existing options that are set there
<ogra_> else something might break
<seb__> Understood
<popey> Elleo: pfffft, you worry too much :S
<popey> Elleo: it uses X11 and pulse, no network...
<seb__> It worked! Thank you for your help :D
<cjwatson> popey: oh, while I remember, it'd be low-priority, but maybe a bug on launchpad-buildd to ask us to have a clean error message rather than a noisy traceback in this case would be good
<cjwatson> you'd probably have noticed the actual error if it hadn't been followed by a pile of barf
<roadmr> jdstrand: tools r833 is in prod! yay, I left them ready for deploy yesterday and they seem to have piggybacked on an impromptu deployment that happened just before midnight.
<popey> cjwatson: good point
<mup> PR snapd#2734 closed: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2734>
<rvr> ogra_: Do you do anything special to enable the serial console on the Pi?
<ogra_> rvr, whats missing ?
<ogra_> rvr, we set enable_uart in config.txt and we have a console= arg in cmdline.txt for serial
<rvr> ogra_: I got a USB TTL serial adapter and I don't get anything in the console
<zyga> jdstrand: I have a question about the mount/unmount helpers
<zyga> jdstrand: about conditionality of logging
<ogra_> did you wire it up correctly ?
<rvr> ogra_: What's the speed? 115200
<zyga> jdstrand: qemu:ubuntu-16.04-64:tests/main/op-remove
<ogra_> yeah
<rvr> ogra_: I think so, RX->TX, TX->RX
<zyga> jdstrand: if you can answer that one quickly I will do the rest of the changes
<ogra_> i usually use: screen /dev/ttyUSB0 115200
<ogra_> rvr, and only gnd/rx/tx ... not 5V connected, right ?
<rvr> ogra_: 5V connected
<rvr> ogra_: And HDMI
<ogra_> (connecting the red 5V cable can damage the board)
<rvr> ogra_: Oh, I see
<ogra_> hdmi shouldnt matter ... the two consoles are separate ... you get consoles on both tty's usually
<jdstrand> zyga: I'm not sure what you are linking to. can you give a full url?
<zyga> jdstrand: sorry, sure
<zyga> https://github.com/snapcore/snapd/pull/2658
<mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
<zyga> jdstrand: let's just discuss it here
<zyga> jdstrand: do you want me to make a debug version of snap-confine
<zyga> jdstrand: that can do logging
<zyga> jdstrand: and have all the log (and support code) compile to nothing in the regular build?
<zyga> jdstrand: and (since we're talking), about the static vs dynamic buffer; originally I implemented this to use a dynamically allocated buffer
<zyga> jdstrand: but the snappy team -1 the change as too complex
<zyga> jdstrand: so I changed that to a "good enough" static buffer
<jdstrand> zyga: I'd prefer that debug* is compiled out on production builds, yes
<jdstrand> zyga: I gave another option to the static buffer that would not be complex
<zyga> jdstrand: do you have a plan on how we'd be assisting people in debugging issues?
<zyga> jdstrand: the N-variant of scpcpy?
<zyga> jdstrand: IMHO both approaches are equally non-complex (I don't see malloc as particularly complex in this case, there are exactly two places that call those functions)
<jdstrand> zyga: re variant> you call debug_mount_cmd(), it does 'char cmd[BUF_SIZE]' then pass that into your function
<stokachu> so with latest snapcraft i saw a commit about merging snap and snapcraft directory
<stokachu> can i put everything under /snap directory and all is well?
<jdstrand> zyga: it isn't the on the stack bit I cared about, it was 'static'
<stokachu> sergiusens, ^
<zyga> jdstrand: ah, I see
<zyga> jdstrand: that's easy enough
<stokachu> also does the store support reading the /snap/setup/gui directory?
<zyga> jdstrand: (I still prefer dynamic but I don't think this is an issue)
<zyga> jdstrand: though in practice this function will move that buffer from one place to another
<zyga> jdstrand: and with the _must approach it won't be any more reusable
<zyga> (you either get the buffer size right or you don't)
<mup> PR snapd#2726 closed: interfaces/builtin: rework core-support to only allow full access to systemctl <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2726>
<pedronis> zyga: for what it worth, when I said static IÂ meant static sized,  so what jdstrand is suggesting
<pedronis> IÂ don't know what the other meant
<zyga> pedronis: static char[100]; vs char[100] vs char * (and malloc)
<pedronis> the 2nd
<zyga> pedronis: thanks for clarifying that
<pedronis> sorry, C has that kind of static, IÂ know, but might brain almost never think of it, it's rarely a good idea
<zyga> static has many meanings, unfortunately
<pedronis> yea
<pedronis> C++ adds a couple more
<zyga> indeed
<zyga> keywords are hard to add to a language
<zyga> anyway
<jdstrand> zyga: as for test plan, I would say they get to compile a snap-confine with debugging. putting it behind an env variable doesn't help with protection for someone attack snap-confine. the attacker will set the env var. if we checked if realuid == euid then honoring the variable is maybe ok
<zyga> jdstrand: hmm
<zyga> jdstrand: we might compile snap-confine-debug and make it not setuid root
<zyga> the people that know how to do it could then use it
<jdstrand> I just don't want scores of string handling code in the setuid code
<jdstrand> (on production)
<jdstrand> granted, snap-confine has an apparmor profile, but it is allowing a good bit that would be fun to attack
<jdstrand> (it has to)
<zyga> jdstrand: I think string handling is unavoidable, must_snprint is not a panacea for everything, I'd rather just bite the bullet and do it corretly
<zyga> jdstrand: but I won't object if you feel that's wrong
<jdstrand> zyga: I want both :)
<zyga> jdstrand: so what's the next step on this: drop the static char[100] buffers, have the callers pass this in (along with size) and code it 100% defensively?
<jdstrand> hence, must_strncat() suggestion
<jdstrand> zyga: yes
<zyga> jdstrand: well, I had grow_string earlier
<zyga> jdstrand: that did realloc
<rvr> ogra_: http://paste.ubuntu.com/23875465/
<zyga> jdstrand: I guess this is the root of the issue, static vs dynamic memory allocation,
<jdstrand> zyga: in general, I liked the intent and most of the branch, it was just these couple bits. getting rid of that boilerplate code will help with coding, clarity and reviews, so thanks
<ogra_> rvr, great
<rvr> ogra_: It does not boot Ubuntu Core
<ogra_> well, because you did hit a key
<zyga> jdstrand: right, that was my intent, cut the copy-pasted code and ensure the debug logs are accurate and not hand-crafted
<jdstrand> zyga: note that I didn't review the dynamic bits. if they were done right, I wouldn't have cared. some projects actually prefer heap vars over stack
<zyga> jdstrand: let me show that, it's still in the history:
<jdstrand> zyga: well, it won't matter if the other reviewers are going to nak it :)
<jdstrand> I was just pointing out that I don't have a fundamental issue with either heap or stack
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2658/commits/e2ab995067ae382372198c264abacc90872ae7d1
<mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
<zyga> jdstrand: ah, I see
<zyga> jdstrand: (the error message is corrected in the next commit if you spot the error there)
<zyga> jdstrand: and this is the use: https://github.com/snapcore/snapd/pull/2658/commits/c007979aaec28469046ecf3f5c54e0a522e31e39
<mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
<axino> hi
<axino> is it possible to have a daemon started by a snap run under a non-root user ?
<ogra_> not yet
<axino> ogra_: ok thanks !
<ogra_> (but why would you want that anyway given it is fully snadboxed)
<axino> ogra_: I don't know, running stuff as root that doesn't need to be makes me incomfortable
<rvr> ogra_: It does nothing when pressing Enter :-/
<ogra_> rvr, what should it do ?
<rvr> ogra_: Boot Ubuntu Core?
<ogra_> (aprt from giving you a newline)
<rvr> ogra_: I'm stuck in that screen from the paste
<ogra_> well, you obviously stopped the autoboot (whihc only happens if you hit a key in the serial console)
<rvr> hmm
<ogra_> so uboot now gives you a command shell
<ogra_> just reset the board
<ogra_> (either by typing reset and hitting enter on the shell prompt or my re-plugging power)
<rvr> Just replugged
<ogra_> good
<rvr> ogra_: Does screen flashes you?
<ogra_> nope
<rvr> Hmm
<ogra_> are you on a mac ?
<ogra_> there was a bug about screen misbehaving on macs
<ogra_> though that was under macos
<rvr> I'm in a Mac, but in Linux
<ogra_> right, thats what i remembered
<rvr> minicom doesn't flash
<ogra_> well, screen doesnt flash for me on either my laptop or my desktop PC
<rvr> Weird
<rvr> ogra_: But I can't see booting either
<rvr> ogra_: Do you use a Pi 3 or Pi 2?
<ogra_> https://bugs.launchpad.net/bugs/1659523
<mup> Bug #1659523: console-conf doesn't work well if using screen on Mac <Snappy:New> <https://launchpad.net/bugs/1659523>
<ogra_> i wonder if it is actually some HW thing
<ogra_> given he also claims that minicom works just fine
<ogra_> rvr, both ... and a BBB and a dragonboard
<ogra_> nothing flashes for me
<ogra_> and they all boot just fine
<rvr> Hmm... it boots fine with HDMI and without the serial console
<ogra_> well, seems something send key presses
<ogra_> thats the only way to make the boot stop where you showed it
<ogra_> *sends
<mup> PR snapd#2735 opened: interfaces/builtin: add missing syscalls to core-support needed for systemctl <Created by morphis> <https://github.com/snapcore/snapd/pull/2735>
<ogra_> rvr, with minicom you can also see it properly boot ?
<ogra_> ... like ... serial output and all
<rvr> ogra_: I unplugged the TX wire and boots ok
<ogra_> right, but you wont be able to type anthing into it now
<rvr> At least it says that it is booting the kernel
<rvr> ogra_: Nope, it wasn't booting with either screen or minicom
<ogra_> sounds like some HW issue then ... if even minicom sends keystrokes
<rvr> ogra_: Booting fine with a reflashed card and without TX :P
<ogra_> well, but that doesnt help using your serial console :)
<ogra_> are you sure your tx is actually plugged into the right place ?
<rvr> I'm happy to see it at least booting :D
<ogra_> heh
<ogra_> as long as you dont want to interact with it :)
<rvr> ogra_: Re-wired carefully, and with screen I can type now
<rvr> ogra_: Thanks :)
<ogra_> yay
<ogra_> enjoy :)
<rvr> I can finally use the screen for the desktop!
<rvr> Everytime I had to check the images, I couldn't use my screen :(
<axino> ogra_: the thing is, it appears that when run as root, my app can't read stuff in $SNAP_USER_COMMON
<kyrofa> axino, that's because your "user" is now root
<kyrofa> axino, which means $SNAP_USER_COMMON is now in /root/snap/<snapname>/<snapversion>
<axino> kyrofa: correct
<axino> kyrofa: the snap can't read there
<kyrofa> axino, can you duplicate that with `sudo snap run --shell <appname>`?
<axino> ($SNAP_USER_COMMON is /root/snap/<snapname>/common, to be precise)
<kyrofa> axino, right, sorry, I gave SNAP_DATA
<axino> kyrofa: yes
<kyrofa> axino, that sounds like a bug
<mup> PR snapd#2736 opened: Initial unity8 interface <Created by mikix> <https://github.com/snapcore/snapd/pull/2736>
<mup> PR snapd#2737 opened: tests: add more debug if ubuntu-core-upgrade fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/2737>
<stokachu> i realize i brought this up the other day but if i have a snap that is already defined as a classic it would be much cleaner to then ahve the user not have to pass --classic during a snap install
<stokachu> ive had a couple people ask me why they have to pass that option in
<kyrofa> stokachu, that would be akin to a devmode snap being automatically installed as devmode
<kyrofa> stokachu, they users need to understand that this is not a snap confined normally
<stokachu> kyrofa, yea that makes sense, i guess from my perspective sudo snap install --classic conjure-up is a lot to type
<kyrofa> stokachu, I hear you
<stokachu> didnt know if it was worth taking to the mailing list for discussion
<kyrofa> stokachu, oh please feel free, but I suspect that's the response you'll get
<stokachu> i totally understand why we do it
<stokachu> i guess cosmetically is it better to pass in --classic or show a prompt that this snap is a classic snap do you want to continue
<stokachu> and --classic would just act as a -y in apt world
<stokachu> ill just throw it out there and see what comes of it
<axino> kyrofa: I got it
<kyrofa> stokachu, I actually quite like that idea myself
<kyrofa> stokachu, send that email
<axino> kyrofa: I rsynced the files from my user to /root/snap/foo, so root wasn't the owner, which apparmor doesn't like
<stokachu> ok cool :) ill write it up now
<kyrofa> axino, ahh, yep that'll do it
<kyrofa> Hey jdstrand, I'm writing a utility in the Nextcloud snap to install one's own key/cert for HTTPS, but I've hit a bit of an issue. The utility itself needs to run as root, since it's doing stuff in SNAP_DATA. My first cut used the home interface, so as long as the certs are in $HOME the utility can pick them up (as command-line args). Of course, though, running as sudo, the utility can't access the user's $HOME
<kyrofa> What is the best way to write this utility?
<kyrofa> Saying "First put your certs in /root/ somewhere" isn't super friendly
<kyrofa> I'm trying to think of some way to pipe them in without having a terrible interface
<ogra_> axino, didnt you say you package a daemon ? why would that have any user dirs at all ... just use SNAP_DATA or SNAP_COMMON
<mup> PR snapd#2738 opened: spread: remove state tar on project restore <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2738>
<ogra_> (i dont think /root/snap/<snap> is a great idea either ... SNAP_DATA will properly put stuff into /var without being bound to any user)
<axino> ogra_: I don't know, I considered a config file to be user data, not system data
<ogra_> well, that would make /etc obsolete on most linux installs ;)
<kyrofa> axino, is it user-specific? Can users have their own?
<kyrofa> axino, if not, then it's a system-wide config living in some random user's home dir
<axino> kyrofa: yes, you could say that
<stokachu> kyrofa, ok sent lets see what happens!
<kyrofa> axino, how would a user make a system-wide service use their own config without effecting the service for other users?
<axino> kyrofa: well it's a daemon, it's snapd which makes it system-wide automatically !
<kyrofa> Haha, fair enough
<axino> kyrofa: presumably, several users could run it with different config - even thought that's not how I'm going to use it
<ogra_> i'd make it use SNAP_DATA as default and have a wrapper that takes a look if there is a config in SNAP_USER_DATA ... if the latter is true, read it and override it
<ogra_> like it would be on a normal system
<ogra_> i.e. if you have have a bip (irc proxy) snap that uses a default config but can be run by a user too ...
<axino> ha yes
<axino> that could work
<axino> ogra_: the issue is, if it's configured as a daemon, then there's no binary for users to run
<kyrofa> axino, you could declare one, if the binary is happy running multiple times
<ogra_> you could define one ... but yeah. if it is a daemon you have a systemd started instance alongside alll the time
<axino> indeed I coul
<axino> could*
<Chipaca> kyrofa, o/
<Chipaca> kyrofa, i just saw the integration tests failures :-)
<kyrofa> Hey Chipaca! Haha
<Chipaca> kyrofa, do those tests need to run with debug?
<Chipaca> i mean
<kyrofa> Chipaca, some of them do, but not all (and in fact, some don't)
<Chipaca> i can fix the tests by expecting (and skipping) the version line, or by debug=False
<Chipaca> but i don't know enough to know which is which tbh :-/
<kyrofa> Chipaca, I think the biggest reason we use debug=True there is because upon failure, the suite adds the entire dump to the output log so we can see what happened
<Chipaca> kyrofa, any guideline?
<kyrofa> Chipaca, hold on, let me take a quick look
<Chipaca> ah, true
<Chipaca> might as well just fix them to expect the version line then
<ogra_> just leave them as is and call them alternate facts
<Chipaca> kyrofa, also in the integration tests, i saw it uses version 'devel', making the version line mention 'vdevel'. Maybe i should drop the v?
<kyrofa> Chipaca, yeah but... a one-line change causing this many failures means our suite is fragile
<kyrofa> Chipaca, you'll get devel when running from source
<kyrofa> Chipaca, perhaps removing the v would look better, yeah
<Chipaca> also it was *two* lines, not one :-p
<kyrofa> :P
<kyrofa> Chipaca, yeah our tests are just super fragile. I think we need to change the assertEquals to a assertThat([...], Contains())
<kyrofa> Chipaca, but that's not a tiny amount of work. We can take it if you like
<Chipaca> kyrofa, I can take a stab at it for the ones affected by this change
<kyrofa> Chipaca, alright. Note that there are 29 of them, sure appreciate that
<kyrofa> Chipaca, but yeah, please do use the testtools matchers where you can
<mup> PR snapcraft#1087 opened: Don't wait for lxd networking in cleanbuild test <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1087>
<jdstrand> kyrofa: if the utility needs to run as root, you don't want to have it using non-root certificates. use sudo -H and then HOME is /root
<kyrofa> jdstrand, well, I sort of do. Otherwise I require users to place certs in /root first, which seems a hoop to jump through just to say "take my certs"
<kyrofa> jdstrand, I might as well not use the home plug at all and say "put them in /root/snap/nextcloud/current/
<kyrofa> "
<KristijanZic> Hi! Is there some web api for snaps like there is for clicks like https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex  ? I had some free time and have developed some ubuntu webstore in Angular just need to connect it to something if there is an api.
<kyrofa> jdstrand, but yeah, that was all I had too. Maybe I'll rewrite it to have them paste cert contents in instead
<jdstrand> kyrofa: if the tool needs to run as root, then the certs need to be put in a place owned by root, otherwise root would be trusting certs from unprivileged users. They have to put the certs somewhere anyway, right? can just use 'sudo cp ...' instead of 'cp ...'
<kyrofa> jdstrand, the utility I was writing is what put the certs somewhere
<kyrofa> (it copies them off to where they need to go)
<Chipaca> kyrofa, the tests that use pexpect are going to need to check for the version string explicitly
<kyrofa> Chipaca, ah, are there a lot of those? The ones I looked at were just assertEqualing the output. But I guess pexpect is used in the suite setup itself huh
 * Chipaca apologises for the context switch
<Chipaca> kyrofa, not to worry, i'll sort it
<kyrofa> jdstrand, I'm not meaning to argue by the way, I understand the reasoning behind this, I just wanted to make sure I wasn't missing anything
<kyrofa> KristijanZic, yes there is. Chipaca where is the snapd REST API documented these days?
<kyrofa> Oh wait-- Chipaca nevermind
<Chipaca> well, I wouldn't call that a web api
<kyrofa> KristijanZic, you don't want that, you want the store-side stuff
<Chipaca> KristijanZic, note that wiki page is outdated (it says as much up there)
<Chipaca> KristijanZic, in the updated document there's a snaps section
<KristijanZic> kyrofa: I just want to list snaps if possible that are in the current Ubuntu snap store.
<jdstrand> kyrofa: sure. so, HOME we really have to have 'owner' match (we can't say 'owner or root' in apparmor atm) in order to enforce multiuser
<Chipaca> KristijanZic, OTOH maybe you want to talk to snapd, not the store
<jdstrand> kyrofa: but, there is this rule: /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,
<jdstrand> kyrofa: that doesn't have owner match. of course, you have to put them there and if you are going to put them there you may as well use sudo cp to the place you want it
<KristijanZic> Chipaca, where are the docs for that? Is that the way uappexplorer does it?
<ogra_> KristijanZic, https://github.com/bhdouglass/uappexplorer that has options for listing snaps
<Chipaca> KristijanZic, sorry, which 'that'?
<ogra_> heh
<kyrofa> jdstrand, indeed. It just means more documentation, heh
<jdstrand> kyrofa: I'm still not sure why 'sudo cp' needs to be wrapped in a tool...
<Chipaca> KristijanZic, uappexplorer talks to CPI
<kyrofa> jdstrand, because I want where they go to be under my control
<KristijanZic> Chipaca, snapd api?
<kyrofa> jdstrand, otherwise I need to document it, keep it up to date, and migrate accordingly
<Chipaca> KristijanZic, https://github.com/snapcore/snapd/wiki/REST-API
<ogra_> but that needs a local snapd instance
<ogra_> if you dont want that CPI is the better option i guess
<jdstrand> kyrofa: you could say 'sudo cp foo $SNAP_DATA ; sudo yoursnap.register foo'
<KristijanZic> ogra, any docs for cpi?
<Chipaca> KristijanZic, that wiki page you pasted is the old CPI docs
<Chipaca> KristijanZic, it links to the new ones
<ogra_> KristijanZic, i'd just use the uappexplorer source as base for your queries ... and the wiki.ubuntu.com pages
<Chipaca> ogra_, dude, it's fully documented in its own section in the new docs
<ogra_> code talks !
<ogra_> :P
<KristijanZic> Chipaca, ok, thanks. ogra, sure
<Chipaca> KristijanZic, https://search.apps.ubuntu.com/docs/#snap-specific-endpoints-errors
<Chipaca> took me a bit because in the middle of fixing the tests before, didn't want to look at the browser :-)
<KristijanZic> Oh, great! Thank you :D
<Chipaca> kyrofa, I was wrong. Everything went better than expected.
<Chipaca> I think it's a sign I should EOF right here.
<kyrofa> Chipaca, ah! Excellent, I agree. I'm jealous you're so far ahead of me
<Chipaca> kyrofa, no you're not -- not unless you really wanted to start work nine hours ago
<kyrofa> Yeah... you got me :P
<stokachu> kyleN, bugs.launchpad.net/snappy is the place for bugs these days? i know github issues got moved
<stokachu> sorry kyrofa
<kyrofa> stokachu, good question, hold on
<stokachu> gustavo told me but it was in passing
<kyrofa> stokachu, you probably want to log against snapd
<kyrofa> stokachu, https://launchpad.net/snapd
<stokachu> ok cool thanks ill do that now
<mup> Bug #1659924 opened: Snap failures in 16.04 <Snappy:New> <https://launchpad.net/bugs/1659924>
<kyrofa> stokachu, guess we're not the only ones, good thread ;)
<stokachu> kyrofa, yea it worked out pretty great, thanks for the push
<stokachu> though sergio mentioned about snapd 2.22 without the use of sudo, does that mean we aren't requiring people to snap login anymore?
<kyrofa> stokachu, honestly I'm not quite sure what he meant by that
<Chipaca> kyrofa, i haven't actually gone, and there's a failing test i'm fixing :-/
<kyrofa> Chipaca, :(
<Chipaca> kyrofa, fixed, pushed, and happy about it
<mup> PR snapd#2735 closed: interfaces/builtin: add missing syscalls to core-support needed for systemctl <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2735>
<mup> PR snapcraft#1083 closed: project: support for gui in snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>
<mup> PR snapcraft#1081 closed: local source: preserve symlinks to directories <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1081>
<mup> PR snapcraft#1087 closed: Don't wait for lxd networking in cleanbuild test <Created by OddBloke> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1087>
<jdstrand> davidcalle: hey. I just noticed that https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has the old version of the whitepaper. is that the most current link?
<mup> PR snapcraft#1088 opened: Release changelog for 2.26 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1088>
<mup> PR snapd#2739 opened: tests: remove (some) garbage files found by restore cleanup analysis <Created by zyga> <https://github.com/snapcore/snapd/pull/2739>
<kirkland> who approves/denies requests to own reserved package names?
<kirkland> (I submitted a couple)
<sergiusens> marcoceppi_, hey, sorry for asking again, bt I lost your quick instructions, mind sending them my way again?
<marcoceppi_> sergiusens: hey, no problem https://github.com/juju-solutions/charm-pkg
<kyrofa> kirkland, talk to nessita and/or noise][
 * kirkland waves at nessita and noise][
<noise][> kirkland: hey, what's up?
<noise][> name regs...
<kirkland> noise][: howdy, I have a few snap package name registrations I'm pushing through
<noise][> just got the notif, 1m
<kirkland> noise][: yeah, i have a few more coming
<kirkland> noise][: actually just do those two, and we're good for today ;-)
<sergiusens> marcoceppi_, then charm <what>; charm <what-now> ? :-)
<noise][> ok
<marcoceppi_> sergiusens: oh, `charm version; charm create foo; cd foo; charm build`
<noise][> kirkland: done
<DedSec> hey, iam running into this strange issue on ubuntu server 16.04 when i try to run snap install of any app, snap tries to download the ubuntu core file and then gives the following error once the core file has finished downloading. error: cannot perform the following tasks:
<DedSec> - Mount snap "core" (888) ([start snap-core-888.mount] failed with exit status 1: Job for snap-core-888.mount failed. See "systemctl status snap-core-888.mount" and "journalctl -xe" for details.
<DedSec> )
<mup> PR snapd#2685 closed: interfaces/builtin: add account-control interface <Created by teknoraver> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2685>
<mup> PR snapd#2703 closed: many: make ubuntu-core-launcher mostly go away <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2703>
<kirkland> noise][: thanks, uploaded;  who does the review?
<mup> PR snapd#2740 opened: releasing snapd version 2.22 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2740>
<noise][> kirkland: reviews of the uploads are security team
#snappy 2017-01-28
<DedSec> quick question, how can i get an yaml file to curl and add an apt key for an program, reason i ask is iam trying to setup an snap for plex
<jdstrand> noise][: well, it doesn't strictly have to be us. honestly, I'd lke to get more reviewers. I know that is something you ratliff and JamieBennett are discussing so I won't rehash
<jdstrand> noise][: especially on classic confinement. the rules are almost all in place such that I/we don't need to be the only ones doing them
<jdstrand> anyhoo
<jdstrand> kirkland: done. approved but you'll need to release it
 * jdstrand wanders off
<andrew-ii> Is a snap meant to be usable immediately after install? After `sudo snap install conjure-up --classic` `conjure-up` errors with `The program 'conjure-up' is currently not installed. <apt message>`
<andrew-ii> (Ubuntu Server 16.04, all packages up-to-date)
<nacc> stokachu: --^
<nacc> andrew-ii: if i had to guess, c-n-f is not snap-aware, but i'm not sure. I'm not sure what the executable from the conjure-up snap is called
<andrew-ii> Ah. The executable is supposed to be `conjure-up`, but ... that resulted in apt complaining that I hadn't installed it
<nacc> andrew-ii: hrm, i just did a snap install of conjure-up and conjure-up is now in my PATH
<andrew-ii> I wasn't sure if there was supposed to be some way to switch or make apt aware or something
<nacc> andrew-ii: from /snap/bin/conjure-up
<nacc> andrew-ii: is /snap/bin/ in your path?
<andrew-ii> Hmmm. Certainly seems like it wasn't added to PATH for me. Wonder if I missed somehting
<nacc> andrew-ii: ubuntu?
<andrew-ii> Turns out /snap/bin is not in PATH
<andrew-ii> Should I add it, or should snap have taken care of that?
<nacc> andrew-ii: on ubuntu, snapd adds it via /etc/profile.d/apps-bin-path.sh iirc
<andrew-ii> Hmm. Whelp, that's there.
<andrew-ii> Lemme reboot and see if there was just something confounded on load.
<andrew-ii> I wonder if it's because I use fish instead of bash
<nacc> andrew-ii: it's possible, /etc/profile is only used by bash (and dash?)
<nacc> andrew-ii: you'd have to tell fish to source the profile files as appropriate
<andrew-ii> Sure feels like it.
<andrew-ii> Lesse if that clears it all up
<andrew-ii> tyyp
<andrew-ii> *Yep, excellent. It's attempting to do some silly bootstrappery now. Thanks for your patience with an unrelated noob question!
<nacc> andrew-ii: np, glad that worked!
<mup> PR snapcraft#1089 opened: options: add armv8l to list of translations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1089>
<mup> PR snapcraft#1090 opened: core: classic with no exported variables <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1090>
<mup> PR snapcraft#1089 closed: options: add armv8l to list of translations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1089>
<stokachu> sergiusens, will snapd 2.22 still require snap login to run without sudo?
<stokachu> sergiusens, and can i now put snapcraft.yaml and setup/gui inside /snap directory?
<stokachu> using git master of course
<htcoder> hi can i run a isolated linux in ubuntu ?
<stokachu> nacc, thanks for helping that person out yesterday
<kirkland> okay, so I've published "hollywood", but I still can't "snap find hollywood"
<BalazsL> Hello! I have a problem with snap. Every time when i trying to install any kind of snap it tries to download the core, but install failed with this error: error: cannot perform the following tasks: - Mount snap "core" (888) ([start snap-core-888.mount] failed with exit status 1: Job for snap-core-888.mount failed.
<BalazsL> any idea?
<Booman> Hey anyone know if there is support for snappy in centos 6 yet?
<kyrofa> kirkland, did you actually release it to a channel?
<kyrofa> kirkland, snap find only searches stable
#snappy 2017-01-29
<MaxLeiter> I opened a PR to update an example snap - is there a chance of it being merged or should I just close?
<MaxLeiter> https://github.com/snapcore/snapcraft/pull/1077 for reference
<mup> PR snapcraft#1077: Shout -> Lounge, the official fork <Created by MaxLeiter> <https://github.com/snapcore/snapcraft/pull/1077>
<mup> Bug # changed: 1570431, 1583405, 1588833, 1600545, 1610025, 1616650, 1637505
<anton___> Hi everyone
<anton___> I got a question that I couldn't find any answers to on google/mailing lists etc. How do you keep a snap application alive, i.e. let's say I have an FFMPEG session that needs to run 24/7 (recording a camera), and on occasion it crashes. Traditionally I have used monit to "watch it" and restart it when it dies. How does this work with snaps?
<kirkland> this page: http://snapcraft.io/docs/build-snaps/publish could use some updates, with "classic confinement"
<sergiusens> kirkland: I'll propose something and get davidcalle to look at
<stephans_> Hi all, I cannot get snap to work on Ubuntu 16.10. I get the error: - Setup snap "core" (888) security profiles (no state entry for key)
<stephans_> How do i get dnapd to actually work.
<stephans_> nothing strange on my system
<stephans_> just standard Ubuntu 16.10 + apps
<stephans_> installed using: sudo apt install snapd
<mup> PR snapcraft#1091 opened: Nop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1091>
<mup> PR snapd#2741 opened: store: enable download deltas on classic by default <Created by squidsoup> <https://github.com/snapcore/snapd/pull/2741>
#snappy 2018-01-22
<diddledan> gunix: yes
<mborzecki> morning
<gunix> hey diddledan
<gunix> if somebody that can explain snapd to me is online, please ping me
<gunix> i do not understand how this system works and it amazes me that stuff like LXD works on archlinux via snap
<mborzecki> mvo: morning
<mvo> good morning mborzecki
<mup> PR snapd#4508 closed: New spread test for hardware-random-observe interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4508>
<mvo> 4495 needs a second review
<mup> PR snapd#4425 closed: config: add support for `snap set core proxy.no_proxy=...` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4425>
<mvo> 4473 also needs a second review :)
<mup> PR snapd#4476 closed: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4476>
<kalikiana> good morning
<pstolowski> hey o/
<zyga-ubuntu> good morning :)
<mvo> good morning kalikiana pstolowski and zyga-ubuntu !
<mvo> happy monday!
<koza> mvo, hey, what is the forecast on the strace support for snaps?
<mvo> koza: if somone reviews my PR at least basic support will land for 2.31
<mborzecki> zyga-ubuntu: pstolowski: kalikiana: morning guys
<mvo> koza: we want support for custom options as well, there is a PR for that too
<mborzecki> koza: hey
<mvo> 4473 is the strace pr that needs a second review :)
<mvo> koza: there is also your motd PR that we need to land for 2.31, right?
<koza> mvo, but like days, weeks, months? :)
<koza> mvo, would be nice, Thibaut commented vi email, Ill change the PR accordingly today
<mvo> koza: 2.31 is scheduled for beta this week and stable in ~4 weeks
<mvo> koza: ta
<koza> mvo, nice!
<mvo> koza: yeah, we are quite excited about strace too, its a popular feature
<mborzecki> mvo: i'm looking at https://bugs.launchpad.net/snapd/+bug/1744433 so far got this: https://bugs.launchpad.net/snapd/+bug/1744433 this should make the message: 'error: cannot refresh "vlc": snap "vlc" has auto-refresh in progress'
<mup> Bug #1744433: 'snap refresh' is silent about changes in progress <snapd:Triaged> <https://launchpad.net/bugs/1744433>
<mvo> mborzecki: aha, you have a pr already?
<mborzecki> mvo: no :) trying to figure out if there's a nicer way
<mborzecki> mvo: i can open a pr with this change though
<mvo> mborzecki: what is your current diff, could you pastebin this please?
<mborzecki> mvo: https://paste.ubuntu.com/26435923/
<mborzecki> sorry, paste the bug link twice in the previous message
<mvo> mborzecki: no worries. will that help with the original issue? afaict mark did "snap refresh" and got "all snaps up-to-date" but in fact there were not, there were refreshing. so the message should be something like "vlc is refreshing" or similar. are we running a changeConflictError when a global refresh is running and a global refresh is requested again?
<mborzecki> mvo: the error mesage on `snap refresh vlc` would be friendly, instad of changes you'd get 'auto-refresh' and so on
<zyga-ubuntu> mvo: I think I should update 2.30 in opensuse today
<mborzecki> the rest i have not figured out yet
<zyga-ubuntu> mvo: and we have some bug reports on fedora front to inspect
<mvo> mborzecki: aha, ok - yeah, making this friendlier is definitely nice
<mvo> zyga-ubuntu: +1 for updates
<mvo> zyga-ubuntu: where do the fedora bugs come from? their bugtracker?
<zyga-ubuntu> mvo: yes, on bugzilla
<mvo> zyga-ubuntu: ok, how bad do they look?
<zyga-ubuntu> https://bugzilla.redhat.com/show_bug.cgi?id=1536895
<mvo> uhh, ok
<mvo> I wonder why we did not caught this in testing :(
<zyga-ubuntu> yes, it's surprising to me as well
<zyga-ubuntu> I'll be back soon, just getting some quick food
<mborzecki> zyga-ubuntu: looks like something we fixed recently
<mup> PR snapd#4513 closed: dirs: fix snap mount dir on Manjaro <Created by mati865> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4513>
<mup> PR snapd#4514 opened: overlord/snapstate: record the 'kind' of conflicting change <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4514>
<Chipaca> whoa, quickest reviewers in the west
<mborzecki> Chipaca: morning
<Chipaca> mborzecki: morning :-)
<Chipaca> do we have a pedronis again this week, or is that next week?
<mborzecki> Chipaca: i think he mentioned he'd be on vacation until 29th
<Chipaca> mborzecki: I laud your detailed memory
<mborzecki> haha, yeah, my wife would disagree :)
<mvo> lol@ mborzecki
<mvo> hey Chipaca good morning and happy monday!
<Chipaca> mborzecki: she holds you to a higher standard :-D
<Chipaca> mvo: good morning! monday's looking good indeed
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> Chipaca: I added i386
<zyga-ubuntu> Chipaca: I didn't do accounts yet but ping me if you want to play and I'll do that quickly
<Chipaca> zyga-ubuntu: awesome. I don't think I need it right now, but very good to know.
<zyga-ubuntu> and I will change the power adapter for the dragonboard so that it can be on 24/7
<zyga-ubuntu> but that's in the evening as it's not a priority for anyone today
<zyga-ubuntu> mborzecki: 4509 has another review
<mborzecki> zyga-ubuntu: thanks
<zyga-ubuntu> mvo: any news on bolt, ppc and other misery?
<mvo> zyga-ubuntu: not yet, I was doing a 2.30 core image respin to exclude the microcode again this morning, I will focus on 2.31 next, part of this is bolt on ppc
<mborzecki> wonder when the new 'working' microcode will be released
<mvo> mborzecki: you are not alone here
<mvo> mborzecki: btw, are you looking into the "snap refresh" output as well (if there is another refresh alreaady running)?
<mborzecki> mvo: no, i've put is aside for now, i ended up going in circles
<zyga-ubuntu> mborzecki: "working" or working?
<mvo> mborzecki: ok, no worries, just wanted to check
<mvo> mborzecki: I was considering looking but had no time for it yet :/
<mborzecki> mvo: go ahead, i'm poking around https://bugs.launchpad.net/snappy/+bug/1741486 now
<mup> Bug #1741486: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>
<mvo> mborzecki: aha, nice! thats a good one too
<mborzecki> btw. can we close https://bugs.launchpad.net/snappy/+bug/1743504 ? this was the unlucky fellow who basically had his filesystem bail out on him
<mup> Bug #1743504: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504>
<mvo> mborzecki: looking
<mvo> mborzecki: I closed it now
<mborzecki> mvo: great, thanks
<mup> Bug #1743504 changed: Ubuntu 16.04 snapd service not working <Snappy:Invalid> <https://launchpad.net/bugs/1743504>
<mvo> mborzecki: thank you! how are we actually doing with "New" bugs? how many are not confirmed/triaged currently?
<Chipaca> (a) wooo, baby steps progress is now tangible
<Chipaca> (b) /me -> physio
<mvo> zyga-ubuntu: silly question, do we bundle on opensuse?
<zyga-ubuntu> mvo: yes, we do
<mvo> zyga-ubuntu: excellent
<zyga-ubuntu> mvo: (it's legan now)
<zyga-ubuntu> legal*
<mvo> zyga-ubuntu: I fixed bolt on fedora by sed things back to boltdb/bolt
<mvo> zyga-ubuntu: that means we just need to fix debian, I can make a patch, just need to find the upstream repo
<mvo> zyga-ubuntu: eh, packaging repo
<mvo> zyga-ubuntu: we really should import their packaging to make this simpler. anyway, found it and doing a patch
 * Chipaca actually goes
 * kalikiana moooore coffeeeee
<jamesb192> zyga-ubuntu: working on a package for *ntoo and wondering what important stuff I am missing. manifest -> https://paste.pound-python.org/show/kHgFz1bglDwHLo89K5ZK/
<zyga-ubuntu> jamesb192: looking
<zyga-ubuntu> kalikiana: you are reading my mind!
<zyga-ubuntu> jamesb192: snap-confine is usually in /usr/lib/snapd/snap-confine or /usr/libexec/snapd/snap-confine
<zyga-ubuntu> jamesb192: same with a host of other binaries (only snap and snapctl are on path)
<zyga-ubuntu> jamesb192: you can drop the following systemd units: autoimport, core-fixup
<zyga-ubuntu> snap-repair
<zyga-ubuntu> system-shutdown
<zyga-ubuntu> and the corresponding timer
<zyga-ubuntu> jamesb192: you can drop the snapd autoimport servic
<zyga-ubuntu> er
<zyga-ubuntu> this thing: -rw-r--r-- root/root       157 2018-01-20 08:53 ./lib/udev/rules.d/66-snapd-autoimport.rules
<zyga-ubuntu> the udev rules
<zyga-ubuntu> those things are all files relevant for core but irrelevant elsewhere
<zyga-ubuntu> core == not classic systems
<zyga-ubuntu> the /opt/snapd location is curious, what made you put all those files there/
<kalikiana> zyga-ubuntu: you're welcome :-D
<jamesb192> temporary holding area until I do something useful.
<zyga-ubuntu> jamesb192:
<zyga-ubuntu> ok, I think you will have some issues still but this looks like a good starting point, I may have missed something
<zyga-ubuntu> I would suggest to look at debian/ubuntu/fedora packages and see if there are any files they ship that you do not
<zyga-ubuntu> and always exclude the files I mentioned above
<zyga-ubuntu> (they are at best no-ops on normal systems)
<zyga-ubuntu> the end goal is to have a system that can be spread tested and that would pass our integration tests
<zyga-ubuntu> but for now just iterate this way and run snaps on your system and see what breaks
<jamesb192> Okay. I will do that. thank you.
<zyga-ubuntu> jamesb192: please send update reports to the forum, I'm sure it will have wider exposure there
<zyga-ubuntu> I can respond there as well
<zyga-ubuntu> 4505 needs a 2nd review
<zyga-ubuntu> ah
<zyga-ubuntu> sorry
<zyga-ubuntu> 4502*
<zyga-ubuntu> not 5
<zyga-ubuntu> mvo: 4505 updated per your comments
<mup> PR snapd#4514 closed: overlord/snapstate: record the 'kind' of conflicting change <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4514>
<mvo> zyga-ubuntu: ta, one quick comment added
<zyga-ubuntu> sure
<zyga-ubuntu> mvo: which code reads "it" (I assume group/user name)
<zyga-ubuntu> mvo: the switch you linked to explicitly maps specific values
<mvo> zyga-ubuntu: let me double check, maybe github is playing tricks on me
<zyga-ubuntu> mvo: the code in snap-update-ns did do name lookups AFAIR but I'm not sure it has to still
<zyga-ubuntu> mvo: and that code is more generic as it applies to other mechanisms
<zyga-ubuntu> mvo: this one only does layout language
<mvo> zyga-ubuntu: aha, you are right, I was misreading the code
<mvo> zyga-ubuntu: sorry
<zyga-ubuntu> mvo: no worries, I wanted to check if I missed something :) thank you for askin!
<zyga-ubuntu> joc: gentle ping about #4326
<mup> PR #4326: interfaces/builtin: blacklist zigbee dongle <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4326>
<zyga-ubuntu> I think you know more about that than we do
<zyga-ubuntu> mborzecki: what's the status of 4285?
<mborzecki> zyga-ubuntu: i've put it on hold now, most of the tests were passing though, iirc the were maybe 1-2 left, one of those was /media directory
<zyga-ubuntu> mborzecki: does it make sense to unconflict and merge this
<zyga-ubuntu> opensuse 42.2 will be EOLed this week
<zyga-ubuntu> we should switch to 42.3
<mborzecki> zyga-ubuntu: i'll merge master and push it for a travis run and we'll see how much has changed
 * kalikiana taking a break
<gunix> hey guys
<gunix> do snaps run in containers?
<zyga-ubuntu> gunix: hey
<zyga-ubuntu> gunix: it depends
<zyga-ubuntu> gunix: snaps are known to run (with some known issues) on recent versions of lxd when running on top of ubuntu
<gunix> zyga-ubuntu: i just tried LXD on archlinux ... install via AUR is not working, but install via snapd is working. and this confuses me
<gunix> zyga-ubuntu: and that made me ask my self how snapd is actually working
<zyga-ubuntu> gunix: I think mborzecki will be the best to know this (he runs arch)
<zyga-ubuntu> gunix: I can happily respond to detains about what we need from the system and how containers may break things
<gunix> zyga-ubuntu: i am curious how snap is running system-agnostic apps
<gunix> i don't understand how that is possible
<gunix> for example, LXD needs to create a network bridge, so it needs to create specific files on the system
<gunix> files which normally are not distro-agnostic
<gunix> but still, it seems to work
<gunix> i am can't understand how this is possible and i didn't find documentation about this online
<zyga-ubuntu> mvo: 4399 needs a review, it's very nice and could be a 2.31 item
<zyga-ubuntu> gunix: I cannot comment about LXD
<zyga-ubuntu> gunix: perhaps stgraber can answer that
<mborzecki> gunix: does the network work inside the containers?
<gunix> mborzecki: yes, that's the confusing part. if you install LXC from the archlinux repos, you still have to configure networking
<gunix> mborzecki: if you install LXD from aur, you can't create containers because it can't map the IDs
<gunix> mborzecki: however, if you install LXD from snap (and snap gets installed from aur), you just do lxd init and everything works after that
<gunix> this really looks like dark magic
<gunix> oh and by default on archlinux you need to change a flag on the kernel if you want normal users to create NEWNS with clone (a.k.a. containers) ... and with the snap version of LXD, you just add the user to the lxd group and it works.
<gunix> i guess you normally get people that ask why it doesn't work. not people who ask why it works. :D
<zyga-ubuntu> mborzecki: can you please look at 4326
<mborzecki> gunix: the USERNS thing is already fix in arch kernel
<mborzecki> zyga-ubuntu: uhh vendor reused vid/pid
<zyga-ubuntu> ...
<zyga-ubuntu> yeah
<mborzecki> and here i thought i'd never have to see such things again
<zyga-ubuntu> serial ports, no vid/pid, mess, usb, reuse vid/pid becaue saves 0.01$
<zyga-ubuntu> mess
<mborzecki> ehehe, wonder how many devices are there with default ftdi vid/pid ;P
<zyga-ubuntu> mvo: 4140 needs someone to decide
<kalikiana> gunix: id mapping works differently because the snap sees the core's filesystem rather than the host's
<gunix> mborzecki: are you sure? because i just installed an arch linux and you need to add the flag or install another kernel, in order to create containers when not root
<mborzecki> gunix: which option? CONFIG_USER_NS?
<gunix> mborzecki: https://wiki.archlinux.org/index.php/Linux_Containers
<gunix> Enable support to run unprivileged containers (optional)
<gunix> i don't know which of them because i didn't get it to work yet, i will go through all steps later today
<mborzecki> gunix: yeah, just the kernel package + sysctl should work, iirc there was some discussion in the original bug report and the maintainer dopted patches from ubuntu or fedora
<kalikiana> gunix: note that the lxd snap always runs as root
<kalikiana> not as the lxd user
<zyga-ubuntu> mvo: can you please look at https://github.com/snapcore/snapd/pull/3963 (aka oldest PR)
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<gunix> kalikiana: it still has to fix the user mapping problem
<gunix> *the id mapping
<kalikiana> gunix: did you read my previous message?
<gunix> sorry, got only the one that it runs on root. reading now
<kalikiana> no worries :-)
<gunix> kalikiana: which are the core/host filesystems?
<kalikiana> gunix: from the point of view of a snap, / comes from the core snap
<kalikiana> not the actual / you'd expect
<gunix> kalikiana: so all packages get installed in its chroot?
<kalikiana> gunix: have a peek at /snap/core/current/ - nothing's installed there, but folders are mounted into place where things should be writable or you want to see the real contents
<gunix> ok. thank you ... and in the users homefolder are only settings regarding the apps? because he also gets a .snap folder
<niemeyer> OMW to the standup..
<zyga-ubuntu> hey niemeyer
<kalikiana> gunix: those are files created by the snap, yes. home isn't accessible (unless you're using the "home" interface, and only non-hidden files even then)
<gunix> you mean everything outside of /home/gunix/snap is not accessible by the application running as a snap?
<gunix> kalikiana: ^
<kalikiana> gunix: yeah. a strict snap couldn't read, say, /home/gunix/mydocument.txt by default
<gunix> kalikiana: than why was i able to change the settings of chromium to save in /home/gunix/Downloads instead of /home/gunix/snap/chromium/current/downloads ?
<kalikiana> gunix: Have a look at `snap interfaces chromium`. You'll notice it has ":home" in the list
<zyga-ubuntu> gunix: also try "snap interface home"
<gunix> kalikiana: i have to install snap again for that, can you please paste that to bpaste? i will install snap later today, if you don't have time, so it's no rush
<kalikiana> gunix: :home                    ag-mcphail,chromium,corebird,dekko,gedit,gimp,handbrake-jz,libreoffice,magic-device-tool,midori,nethack,rg,spotify,telegram-sergiusens,vlc
<gunix> kalikiana: so chromium wants to use libreoffice and vlc?
<kalikiana> gunix: Chromium uses the "home" slot, which the listed snaps plug into. Or to put it more simply, "Chromium uses the home interfaces, and all those other snaps do, too"
<gunix> kalikiana: oh, so that's a list of the snaps that use the home slot, and you installed all the snaps in the above list, right?
<kalikiana> gunix: Yes. This wouldn't show snaps that aren't installed.
<gunix> kalikiana: do snaps run as containers? because i don't understand how gnome3 GUI apps would run in a container
<zyga-ubuntu> gunix: no
<zyga-ubuntu> gunix: and maybe
<gunix> zyga-ubuntu: please explain :D
<zyga-ubuntu> gunix: have a look at this https://new.zygoon.pl/post/poking-holes-in-cheese/
<gunix> zyga-ubuntu: haha "a look"
<gunix> i will read it today or tomorrow
<gunix> i also need to start working on a tripleo deployment since that is for my job, but i am too curious how snap works and i keep testing it instead of doing what i should
<gunix> i always get this when i try archlinux. "yea i will just install arch on my desktop really quick and create some redhat VMs and continue my work" ... 5 days later: "ok so what if i install arch on the logical volume instead of the partition, so that i snapshot it before upgrades? hmm gotta try that"
<jdstrand> greyback: oh right, forgot about that. in that snap, just do: something like:
<jdstrand> name: foo
<jdstrand> slots:
<zyga-ubuntu> jdstrand: good morning!
<jdstrand>   x11-service:
<jdstrand>     interface: x11
<greyback> jdstrand: already figured out, with zyga's help
<jdstrand> apps:
<jdstrand>   ...
<jdstrand> ok, cool
<jdstrand> hey zyga-ubuntu :)
<jdstrand> cachio: reading 'man capabilities', it makes sense to add that cap to the policy
<greyback> jdstrand: and it is working ok. Am trying to tighten up the interfaces and figure out /dev/shm usage
<jdstrand> cachio: feel free to send up a PR and ping me for review
 * kalikiana going to go for lunch in a bit
<jdstrand> greyback: awesome! sorry again for the slow response. I'm no longer sprinting
<greyback> jdstrand: no worries at all
 * greyback thinks he sees the finishing line at long last
 * kalikiana read that as "fishing line" and wondered if that was sarcasm
 * pstolowski lunch
<cachio> jdstrand, ok, I'll try that, thanks
<diddledan> zyga-ubuntu: I think you're misunderstanding gunix's question regarding "do snaps run inside containers?". I think gunix means something along the lines of not "if I create a container can I run a snap inside it?" and more "when I run a snap on my system, is it being executed inside a container to isolate it?"
<seb128> mvo, is bug #1744584 might be worth commenting on if you have any recommendation of what snaps folder need backuping or not?
<mup> Bug #1744584: Exclude Snap .cache from Dejadup backups <DÃ©jÃ  Dup:Triaged> <Snappy:New> <deja-dup (Ubuntu):Triaged> <https://launchpad.net/bugs/1744584>
<zyga-ubuntu> diddledan: ah, perhaps
<zyga-ubuntu> gunix: ^
<zyga-ubuntu> gunix: which question was it?
<gunix> when I run a snap on my system, is it being executed inside a container to isolate it?
<gunix> diddledan: zyga-ubuntu ^
<mvo> seb128: thanks, looking
<seb128> mvo, thanks :)
<zyga-ubuntu> gunix: aha, I see
<zyga-ubuntu> gunix: so my answer stands, it depends on how you understand containers; I'm inclined to say "no" more than yes
<zyga-ubuntu> gunix: because most of the security confinement comes from LSM (apparmor)
<zyga-ubuntu> gunix: though we also use some of the technology used by what people agree are containers
<gunix> zyga-ubuntu: can't be. i am running archlinux
<zyga-ubuntu> gunix: hence the fuzzy answer
<zyga-ubuntu> gunix: right, we use a combination of things
<diddledan> there is a teeny bit of container-tech used, such as mount-namespaces
<zyga-ubuntu> gunix: and container is a marketing term more than a technical term today
<zyga-ubuntu> gunix: but also spiritually, we try to integrate the app with the host
<zyga-ubuntu> gunix: more than any other "containers" do
 * diddledan meditates
<gunix> zyga-ubuntu: with container, i mean NEWNS flag within the clone() function.
<diddledan> I'm spiritual
<gunix> zyga-ubuntu: was that a marketing explanation too? :D
<zyga-ubuntu> gunix: yes, we do that
<zyga-ubuntu> (ish)
<zyga-ubuntu> gunix: that's the only thing that we do that is clearly a container tech
 * zyga-ubuntu gets more tea
<gunix> zyga-ubuntu: is that default for all snaps?
<Chipaca> getting more tea _should_ be the default for all apps
 * Chipaca gets more tea too
<diddledan> I'm more a cola addict :-p
<diddledan> pepsi max ftw (no sugar)
<zyga-ubuntu> gunix: yes, all snaps use that by default; the only exception are snaps that you install with --classic
<zyga-ubuntu> gunix: those are, like classic packages, installed directly on your system
<kalikiana> re
<zyga-ubuntu> mvo: 4507 is green and has two +1s
<cachio> jdstrand, you mean net_admin capability?
<cachio> jdstrand, https://paste.ubuntu.com/26437642/
<cachio> I am using this, I already modified the capability
<Chipaca> am I missing a trick, or is it not possible to stream a file into a tar with archive/tar?
<Chipaca> (the key being I don't know the size of the file beforehand)
<diddledan> Chipaca: you should be able to do something equivalent to `cat file | tar cf mytarfile.tar`
<diddledan> unless you're talking about golang in which case I've done that before on an unrelated project
<Chipaca> diddledan: golang yes
 * Chipaca asks the same question over in #go-nuts because he feels it's nuts that he can't :-)
<elopio> Good morning!
<diddledan> my code is a mess, but you can see I stream a file from sftp into a tar here: https://github.com/bowlhat/sftp-client/blob/master/backup.go
<mborzecki> Chipaca: iirc you need to know the size upfront so that when parsing t you can skip that much + any padding
<mup> PR snapd#4507 closed: advisor: use forked bolt to make it work on ppc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4507>
<cachio> jdstrand, this is the interface that I am using when I see that error, https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/interfaces/builtin/netlink_audit.go
<cachio> jdstrand, do you think it needs any other change?
<mup> PR snapd#4495 closed: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4495>
<gunix> I added snap as an installation method for LXD on the archlinux wiki: https://wiki.archlinux.org/index.php/LXD
<zyga-ubuntu> mvo: can I close core#67 now?
<mup> PR core#67: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <https://github.com/snapcore/core/pull/67>
<gunix> since snap works flawlessly, it deserves this
<zyga-ubuntu> gunix: thank you~!
<mvo> zyga-ubuntu: so to fix the mount unit ordering issue, what kind of test do we need?
<mvo> zyga-ubuntu: is a reboot inside the lxd container the rightonw?
<mvo> right one?
<zyga-ubuntu> mvo: I think I had a branch with a test
<mup> PR core#67 closed: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/67>
<zyga-ubuntu> mvo: just remove a snap :)
<mvo> zyga-ubuntu: inside lxd? ok
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> mvo: is core#69 something that can be closed now?
<mup> PR core#69: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <https://github.com/snapcore/core/pull/69>
<mvo> zyga-ubuntu: yes, good point
<jdstrand> cachio: your paste from before was for audit_read: https://paste.ubuntu.com/26412541/
<mup> PR core#69 closed: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/69>
<zyga-ubuntu> thank you!
<cachio> jdstrand, let me create a PR with the test so you can see what I am doing
<kalikiana> gunix: niiiice :-D
<cachio> jdstrand, #4515
<mup> PR #4515: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>
<jdstrand> cachio: man 7 netlink only says that net_admin is needed for multicasting. that doesn't mean it is accurate, but your paste from last week says audit_read and 'man capabilities' says 'Allow reading the audit log via a multicast netlink socket'
<mup> PR snapd#4515 opened: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>
<jdstrand> cachio: since net_admin is needed for setting up a multicast socket, you probably will need both
<mborzecki> Chipaca: have you found a way to deal with the tar issue?
<Chipaca> mborzecki: "use archive/zip instead"
<mborzecki> radical
<Chipaca> this is exactly the sort of silly issue i wanted to root out by this approach to it all, so \o/
<mborzecki> Chipaca: glad that it works with zip :)
<Chipaca> mborzecki: we'll see :-)
<Chipaca> i like your optimism though
<jdstrand> cachio: reading that PR it isn't clear that NETLINK_AUDIT is a multicast socket
<mborzecki> Chipaca: hmm looking at https://golang.org/src/archive/zip/writer.go#L224 looks like zip writes the header upfront too
<cachio> jdstrand, what do you suggest to fix it?
<Chipaca> mborzecki: but AFAICT it doesn't require the size at that point
<Chipaca> mborzecki: note how close() updates the header
<mborzecki> Chipaca: yeah, it seems to update the count on the flly (next to crc32)
<mvo> zyga-ubuntu: any idea about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1744738 ? i.e. inside lxd it seems like apparmor is not confined anymore
<mup> Bug #1744738: snapd 2.29.4.2 ADT test tests/main/lxd failure with linux-hwe 4.13.0-30.33~16.04.1 <snapd (Ubuntu):New> <https://launchpad.net/bugs/1744738>
<mvo> zyga-ubuntu: also slightly sad, but I only get 20kb for the lxd test so my ordering fix can take forever to verify
<zyga-ubuntu> mvo: looking
<mborzecki> Chipaca: so there's a fileWriter https://golang.org/src/archive/zip/writer.go#L317 and a countWriter https://golang.org/src/archive/zip/writer.go#L384 oh my
<zyga-ubuntu> hmm
<jdstrand> cachio: I think that the capabilities man page implies it is multicast. I commented in the pr
<jdstrand> mvo, zyga-ubuntu: I may have an idea on that
<mborzecki> Chipaca: we had a running joke at my previous company that all problems are solved by adding another reader/writer, in that case we had a file upload through POST which was repacking the data, checksumming, encrypting and uploading to s3 from one of the intermediate steps :P
<mvo> jdstrand: oh, tell us more please
<cachio> jdstrand, great, thanks
<jdstrand> mvo: I haven't read that bug very closely, but serguisens reported an issue to me
<zyga-ubuntu> mvo: can you please cherry pick the unit test from #4258
<mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
<zyga-ubuntu> mvo: as for the lxd issue you just linked to
<jdstrand> mvo: on kernels that have partial apparmor support, the apparmor policy is set to the classic template
<zyga-ubuntu> mvo: not sure yet
<Chipaca> mborzecki: I may or may not have a io.TeeReader of a io.TeeReader of a member of an archive and a hasher, and a sizer
<zyga-ubuntu> jdstrand: ah, nice catch!
<jdstrand> mvo: this gives a glob rule like /** pix,
<Chipaca> mborzecki: 	dec := json.NewDecoder(io.TeeReader(metaReader, io.MultiWriter(metaHashChecker, &sz)))
<Chipaca> mborzecki: also that ^
<jdstrand> mvo: whereas the lxd-support template has /usr/sbin/aa-exec ux, (or similar)
<mborzecki> Chipaca: hahah
<jdstrand> mvo: 'ix' ends up scrubbing the environment (it shouldn't, that is an apparmor bug related to limitations in the current implementation)
<jdstrand> mvo: and 'ux' doesn't
<niemeyer> Newly allocated one machine roundtrips a dummy run in almost exactly one minute
<niemeyer> on spread+Linode, that is
<niemeyer> Surprisingly good
<mvo> jdstrand: hm, why do we start to see this now?
<mvo> jdstrand: thanks for explaining that :)
<mvo> jdstrand: I wonder a) why now b) what can we do about it :)
<niemeyer> That includes allocation of the brand new instance, image creation, trivial task run, and machine removal
<jdstrand> mvo: what I've seen is that on those kernels the 'lxd init' command can't find the required libraries because LD_LIBRARY_PATH is cleared
<jdstrand> mvo: I have a todo to file both an apparmor bug and a snapd bug. I'm evaluating how to fix this in snapd. this came up at the sprint so I couldn't chase it down further. was going to look at it after the layouts reviews
<mvo> jdstrand: great, thank you! can I paste this into the open bug?
<jdstrand> mvo: now, like I said, I haven't looked at the aforementioned bug closely, but I wonder if something with the partial support is affecting this? it *shouldn't* if I understand that bug after looking at it a little-- seems this should all be happening on a xenial kernel with full apparmor support
<jdstrand> mvo: well, no, I'm only wondering if that bug is involved
<mvo> jdstrand: aha, ok, sorry I misunderstood
<mvo> jdstrand: yes, this is all full confinement
<jdstrand> + lxd init --auto
<jdstrand> LXD has been successfully configured.
<jdstrand> that suggests that it isn't it...
<jdstrand> so, sorry for the noise, but fyi there is a problem with lxd snap and partial apparmor support :)
<mvo> jdstrand: heh, no worries and thanks, good (or bad) to know about this problem
<jdstrand> mvo, zyga-ubuntu: with that bug, it seems that the container doesn't have the snap-confine loaded or snap-confine is not detecting that it is loaded correctly
<mvo> jdstrand: the only change we did for 2.29.4.2 was http://launchpadlibrarian.net/347640641/snapd_2.29.4.1_2.29.4.2.diff.gz
<zyga-ubuntu> mvo: it feels like something else has changed under us
<jdstrand> mvo: it is a 2.29.4.1 to 2.29.4.2 regression? the bug talks about 2.28.5
<mvo> jdstrand: indeed, 2.28.5 -> 2.29.4.2
<mvo> zyga-ubuntu: same here
<jdstrand> it could be that the kernel changed or lxd. someone should try to reproduce manually and run snap-confine in debug mode
<jdstrand> mvo: (the diff you gave was 2.29.4.1 to 2.29.4.2)
<mvo> hm, 2.29.4.2 is fine with lxd for linux-meta/4.4.0.105.110 on 2017-12-22 so 2.29.4.2 is probably not it
<jdstrand> istr a bug about lxd not detecting apparmor correctly
 * jdstrand tries to find
<jdstrand> mvo: I wonder if it is a variation on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1743079?
<mup> Bug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079>
<jdstrand> mvo: ie, snap-confine.d doesn't exist and the profile fails to load
 * jdstrand looks at the log more closely
<mvo> jdstrand: ohhh, that sounds likely
<mup> PR snapd#4516 opened: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
<niemeyer> HEADS UP: I just "broke" spread on Travis.. it will fail to allocate machines if something gets pushed *right now* as I'm testing the machine allocation with the new feature (PR above)
<jdstrand> I don't see anything in the logs about that, but that doesn't surprise me. I doubt the logs would have lxc debug output
<jdstrand> mvo (cc zyga-ubuntu): there was talk last week about artful kernels breaking lxd in that profiles were not loaded with 4.13 kernels due to the container check in /lib/apparmor/profile-load
<jdstrand> mvo: this autopkgtest is with a 4.13 kernel
<zyga-ubuntu> jdstrand: ouch
<jdstrand> mvo: let me get a url for you. I don't see that a bug was filed
<jdstrand> mvo (cc zyga-ubuntu): https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34
<zyga-ubuntu> thank you
<niemeyer> And it works.. wow.. nice to see 26 machines coming up at once.
<mvo> jdstrand: thank you!
<jdstrand> mvo (c zyga-ubuntu): ok, now I paid my penance for distracting you with the partial apparmor lxd bug I mentioned
<jdstrand> hopefully this will help you zero in on it
<zyga-ubuntu> niemeyer: it's live now?
<zyga-ubuntu> niemeyer: do you have a KPI for the # of machines up? :D
<zyga-ubuntu> (average/day maybe)
<niemeyer> zyga-ubuntu: Sort of.. Travis should be working again, but new allocations won't work until I drop the 80 preallocated systems
<zyga-ubuntu> k
<niemeyer> Except for that one PR that I tuned
<zyga-ubuntu> niemeyer: cool, I cannot wait to see how that performs, maybe we'll finally never run out of systems!
<niemeyer> If this one works well, and by now I see no reason why it wouldn't, I will drop the preallocations and then everybody can enjoy faster tests
<niemeyer> zyga-ubuntu: Keep an eye here then: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification
<niemeyer> zyga-ubuntu: All 26 systems are dynamically allocated 8GB machines
<jdstrand> mvo: if you verify profile-load is actually the issue, I guess file a bug against apparmor with steps to reproduce and we can look at how to fix it
<zyga-ubuntu> looking :)
<niemeyer> zyga-ubuntu: Note how it took *9 seconds* between request to allocate the new machine and us having it
<niemeyer> For all 26 of them.. so sweet
<zyga-ubuntu> niemeyer: has something changed on linode? AFAIK last time you said that it doesn't matter if the machines are on or off, they cost the same; I understand that those are machines added and removed to the pool/account but is that a new feature on linode or just us making use of it?
<niemeyer> zyga-ubuntu: It doesn't matter if the machine is on or off, but it does matter if you have the machine or not have it at all
<mvo> zyga-ubuntu: so using the bind mount /snap /snap and unshare it approach, the mount table has now two entries for each snap :/
<Chipaca> roundtripping with zip ftw
 * Chipaca earned a break
<niemeyer> zyga-ubuntu: In other providers (Amazon, GCE) you pay only when the machine is on, even if you have the whole metadata of the machine associated with it still (configuration, disks, etc)
<zyga-ubuntu> mvo: ugh :/
<zyga-ubuntu> mvo: did you remove the code in snap-confine that was doing stuff in that area?
<zyga-ubuntu> niemeyer: aha, I see
<mvo> zyga-ubuntu: I did but let me double check
<niemeyer> zyga-ubuntu: Yeah, this is now dynamically creating the whole machine.. nothing exists before or after
<zyga-ubuntu> niemeyer: also, no more out of disk space errors!
<niemeyer> zyga-ubuntu: Hah, indeed.. :)
<mup> PR snapd#4517 opened: data: add systemd unit that unshares /snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/4517>
<niemeyer> It's looking good.. we just need to tune a bit the number of workers on each system
<niemeyer> It hasn't finished, but we're down to only 6 machines
<niemeyer> Which means 20 already terminated their job and went away
<niemeyer> We're probably not making great use of the 8GB, either memory wise or CPU wise
<niemeyer> It's probably better to split tasks further and take smaller machines
<mvo> zyga-ubuntu: I pushed a first PR with the mount rshared thing, but its ugly due to the duplication afaict
<zyga-ubuntu> mvo: duplication?
<zyga-ubuntu> of those entries?
<mvo> zyga-ubuntu: yes, everything under /snap it seems, I wonder if there is a different way to archive the --make-rshared. but I guess this only works on mounts not dirs?
<zyga-ubuntu> mvo: it only works on mount entries, yes
<mvo> zyga-ubuntu: ok, maybe we need to life with the dups then, I will see if a full snap run is happy
<niemeyer> cachio: Is there a known Fedora error right now where the test hangs on "snap install"?
<zyga-ubuntu> mvo: can you show me the code please?
<mvo> zyga-ubuntu: sure, the PR is up
<zyga-ubuntu> ah, let me refresh, thanks!
<cachio> niemeyer, no
<cachio> niemeyer, do you have any log?
<niemeyer> cachio: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification
<niemeyer> cachio: Both workers hanging exactly in the same place for 10+ minutes, so not a coincidence
<zyga-ubuntu> those fedora boxes
<zyga-ubuntu> yeah
<zyga-ubuntu> niemeyer: offtopic, I was thinking about my piles of abandonware lately and I was thinking about tagging it as such
<zyga-ubuntu> niemeyer: and I quickly made this today: https://github.com/zyga/project-status-shields
<mvo> zyga-ubuntu: adding the new units to the spec files now
<cachio> niemeyer, I dont see any error on fedora
<zyga-ubuntu> mvo: so this is the service unit
<cachio> niemeyer, but are delayed
<zyga-ubuntu> mvo: what happened to the snap.mount unit?
<niemeyer> cachio: Well..? :)
<cachio> niemeyer, first time I see that butI saw similar issues that I tried to address on the spread PR
<cachio> niemeyer, https://github.com/snapcore/spread/pull/49
<mup> PR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49>
<zyga-ubuntu> mvo: reviewed
<cachio> niemeyer, I have seen kill timeout reached the last weeks
<cachio> niemeyer, not just for fedora
<niemeyer> cachio: Again, an entire run looking perfect except for the two Fedora workers hanging exactly on the same place is not a coincidence
<niemeyer> cachio: These are independent machines, started independently, running independently
<kyrofa> kalikiana, are you still around?
<kalikiana> hey kyrofa
<kalikiana> Yes I am :-D
<niemeyer> cachio: Have you seen where it's stuck?
<kyrofa> kalikiana, late for you! I don't suppose you have 5 minutes to meet?
 * zyga-ubuntu small supper & fresh tea
<cachio> niemeyer, yes
<kalikiana> kyrofa: Indeed. I'll grab my headphones. It's fine.
<cachio> niemeyer, but the test seem to be ok
<cachio> niemeyer, in fact it is the first time I see this error
<kyrofa> kalikiana, about on-to by the way
<cachio> niemeyer, perhaps it is something related to the store
<kyrofa> Weekly?
<kalikiana> kyrofa: Ack
<niemeyer> cachio: Maybe, but what would justify getting stuck?
<cachio> niemeyer, perhaps it is not stuck, spread is who is not getting the changes
<cachio> niemeyer, I used to see that in my machine often
<cachio> mainly when we use the quiet command
<niemeyer> cachio: Not sure I understand what you mean by that
<niemeyer> cachio: There's a "snap install" command there and no output
<cachio> niemeyer, what I say is that it could be different thinks, either the snap command got stuck or spread did not received any other output but after a time snap install continued working
<cachio> niemeyer, that's what I saw running from localhost in different situations
<niemeyer> cachio: snap install should not hang silently like that
<cachio> niemeyer, let me try to reproduce it here
<niemeyer> cachio: If it does it's a bug.. if you are seeing this frequently, let's please  not ignore it
<niemeyer> Anyway, really need to run.. o/
<cachio> I created a PR in spread for those situations
<cachio> niemeyer, but I am not sure if this case is affected by that
<cachio> niemeyer, I'll try to reproduce it locally
<cachio> niemeyer,  I am already runnig this test in order to see if I can reproduce it
<jdstrand> mvo: fyi, jjohansen has been working on artful kernel for the autopkgtest failure. it seems like this will go to artful then the hwe kernel will get it in due course. in other words, if you can demonstrate that the test failure is due to the profiles not loading, then the bug will be fixed in due course
<jdstrand> mvo: that came out a little weird-- he has a kernel to fix lxd, which I think will fix the autopkgtest failure (he isn't looking at the snappy autopkgtest failure)
<cachio> mvo, the tests for beta are going really well
<cachio> mvo, we are going to candidate soon
<cachio> niemeyer, 2018-01-22 16:12:58 Cannot allocate linode:debian-9-64: no powered off servers in Linode account and no plan to allocate new machines
<cachio> niemeyer, is being happening a change in linode?
<cachio> all the machines failed because of this
<cachio> https://travis-ci.org/snapcore/snapd/builds/331880011?utm_source=github_status&utm_medium=notification
 * cachio lunch
<kyrofa> elopio, did you ever manage to get the bot cranking out autopkgtests again?
<elopio> kyrofa: no, had to do it locally. But haven't checked again since thursday.
<kyrofa> elopio, looks like we have arm again
<elopio> I'll check in a few.
<kalikiana> Going to call it a day now
 * kalikiana waves
<zyga-ubuntu> kalikiana: o/
 * zyga-ubuntu EODs and marks most of his projects as abandoned
<kalikiana> zyga-ubuntu: is that a part of "live every day like it's your last day"? ;-)
<zyga-ubuntu> kalikiana: haha
<zyga-ubuntu> no, about some thinking I was doing
<zyga-ubuntu> on ancinent projects
<zyga-ubuntu> and on ...
<zyga-ubuntu> https://github.com/zyga/project-status-shields
<kyrofa> elopio, does that mean you tested snapcraft#1877 locally?
<mup> PR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>
<mup> PR snapcraft#1878 closed: repo: use debian.arfile instead of dpkg-deb <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1878>
<kalikiana> zyga-ubuntu: neat
<elopio> kyrofa: yes.
<kyrofa> elopio, with success? :P
<kyrofa> I'll merge that PR if so
<elopio> kyrofa: https://autopkgtest.ubuntu.com/request.cgi still gives 500, so no way to launch them.
<kyrofa> cjwatson, do you know anything about that?
<elopio> kyrofa: and yes, locally the tests ran. Not all of them passed, but that's not because of the refactor.
<kyrofa> elopio, enough to give you confidence in the PR, though?
<cjwatson> kyrofa: (a) it's intentional until Spectre mitigation is finished (b) in general please ask Laney about autopkgtest stuff, not me
<elopio> kyrofa: yes, because travis is running all of them and passing.
<kyrofa> cjwatson, excellent, thank you. Good to know who runs that stuff!
<cachio> niemeyer, I could reproduce the error on fedora
<cachio> this is the log with the error https://paste.ubuntu.com/26438961/
<zyga-ubuntu>             return BadRequest("cannot %s %q: %v", inst.Action, inst.Snaps[0], err)
<zyga-ubuntu> looks like inst.Snaps is empty
<zyga-ubuntu> Chipaca: ^
<cachio> zyga-ubuntu, did you see this error?
<cachio> seem to be affecting fedora
<zyga-ubuntu> cachio: I looked at your log, I didn't investigate more
<mup> PR snapd#4518 opened: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4518>
<zyga-ubuntu> cachio: ^
<zyga-ubuntu> I think you need to use ' ' rather than ""
<zyga-ubuntu> it looks like invalid yaml
<barry> hey folks, sorry to ping here but i have a quick question which i didn't seem to find answered on the forum.  what is the roadmap for official rhel7 support?  any thoughts on osx support?  i'm betting rhel6 is completely infeasible due to its age
<zyga-ubuntu> barry: hey
<barry> zyga-ubuntu: hi!
<zyga-ubuntu> barry: I think rhel7 is "soon" but nobody has championed that, perhaps someone just needs to work together with Pharaoh_Atem who maintains the fedora packages
<zyga-ubuntu> barry: osx support is something that is a different class of problem to solve (virtualization most likely)
<cachio> zyga-ubuntu, yes
<cachio> zyga-ubuntu, thanks
<barry> zyga-ubuntu: that totally makes sense re: osx
<zyga-ubuntu> barry: I think that if you want to see rhel happen soon you should get in touch with neal (Pharaoh_Atem) and see what's missing
<zyga-ubuntu> I heard neal made some centos packages and I'm not on top of that anymore
<zyga-ubuntu> barry: technically I think rhel is "just packagign"
<cachio> zyga-ubuntu, should I add net-admin capability to the ssh-keys and ssh-public-keys interface?
<cachio> zyga-ubuntu, I mean, to avoid connecting to network-control
<zyga-ubuntu> cachio: I don't think so
<zyga-ubuntu> those interfaces don't say "you are network admin"
<zyga-ubuntu> cachio: perhaps just use a simpler test
<zyga-ubuntu> cachio: don't run ssh
<zyga-ubuntu> cachio: just read keys
<cachio> zyga-ubuntu, ok, but the test is sharing ssh, that's why I using it
<cachio> zyga-ubuntu, I mean, I am trying to cover the whole interface
<zyga-ubuntu> cachio: yes but the interface doesn't promise you can run ssh
<zyga-ubuntu> cachio: not sure if that's worth it
<cachio> zyga-ubuntu, ok, so perhaps this line should not be included
<cachio> in the interface /usr/bin/ssh ixr,
<zyga-ubuntu> cachio: hmm, intersting,
<zyga-ubuntu> jdstrand: ^ do you think this makes sense?
<zyga-ubuntu> ssh-keys should not be about running ssh
<zyga-ubuntu> jdstrand: or if it should it should really allow it
<Pharaoh_Atem> zyga-ubuntu: there's a few other things, like making the software install integration work
<zyga-ubuntu> Pharaoh_Atem: gnome-software?
<zyga-ubuntu> Pharaoh_Atem: what's missing there?
<zyga-ubuntu> Pharaoh_Atem: I think getting basic CLI package out there would help
<jdstrand> cachio: please don't add network-control for testing ssh
<barry> zyga-ubuntu: okay thanks
<jdstrand> cachio: when I tested the interface, I did not need network-control
<jdstrand> cachio: how are you using ssh?
<cachio> jdstrand, https://github.com/snapcore/snapd/pull/4512/files
<mup> PR #4512: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4512>
<jdstrand> cachio: the interfacec doesn't claim to support everything the ssh command can do
<cachio> jdstrand, so, which is the idea about the ssh command for that interface?
<cachio> jdstrand, to do what?
<cachio> jdstrand, so I can update the test
<jdstrand> cachio: "ssh-public-keys: I was unable to determine a use for this interface" from https://github.com/snapcore/snapd/pull/4100
<mup> PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4100>
<jdstrand> cachio: people wanted that interface to only allow the public keys, so that is what it does. probably the best test is ssh -V and testing if can access the .pub file
<cachio> jdstrand, ok
<cachio> jdstrand, what about the ssh-keys?
<cachio> jdstrand, should I test the ssh command connection?
<cachio> jdstrand, or just the access to the keys?
<jdstrand> cachio: "ssh-keys: I was able to login to a remote server"
<cachio> jdstrand, I tried that and I couldn't, let me try again
<jdstrand> cachio: if you can do it without network-control, then I say go for it. I don't know why it is asking for that...
<jdstrand> cachio: if you can't, the ssh -V and testing if can access .pub and private keys should be enough
<cachio> jdstrand, ok
<Pharaoh_Atem> zyga-ubuntu: g-s is one bit, but not really the important one
<Pharaoh_Atem> the important one is making sure that the selinux policies apply correctly
<zyga-ubuntu> Pharaoh_Atem: and what is missing there?
<Pharaoh_Atem> zyga-ubuntu: well, I still need to backport a bunch of patches for ensuring the paths work correctly
<Pharaoh_Atem> basically, I need to retry with 2.30 / 2.31
<Pharaoh_Atem> which I'm preparing for Fedora right now
<zyga-ubuntu> I see, thank you!
<cachio> jdstrand, permission denied
<cachio> [  497.497832] audit: type=1400 audit(1516652364.412:57): apparmor="DENIED" operation="create" profile="snap.test-snapd-ssh-keys.ssh" pid=19379 comm="ssh" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
<cachio> jdstrand, this is without network-control
<cachio> for the ssh-keys interface
<jdstrand> cachio: sure, you will definitely need 'network'
<roadmr> elopio: hi! hey do you know who mans the snapcrafters e-mail address?
<elopio> roadmr: I would guess Alan and Martin.
<roadmr> thanks elopio ! (I wrote there to double-check a couple of snap transfers, just wanted to check if it's not a black hole heh)
<cachio> jdstrand, so, what do you prefer for the test, add network or just check keys? for the ssh-keys interface
<lundmar> Hi. I need to stage libqt5charts5 but this package is not available in the official Xenial repo. I've found an unoffical .deb package I want to use. Is there a plugin that can install remote .deb packages by URL?
<jdstrand> cachio: I don't have a preference. I think it is sufficient to only check check the keys
<cachio> jdstrand, ok, tx
<jdstrand> roadmr: istr noise][ reporting at the sprint that snap v1 is gone. does that mean I can finally remove click and snap v1 from the review tools?
<noise][> jdstrand - yes!
<roadmr> jdstrand: \o/ zorch em
<jdstrand> ok thanks
<mup> PR snapd#4518 closed: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4518>
#snappy 2018-01-23
<mborzecki> morning
<mborzecki> mvo: morning
<mborzecki> mvo: do you know the story behind disabling setting up XDG_RUNTIME_DIR? i'm looking at https://bugs.launchpad.net/snappy/+bug/1738197 and the dir is not created
<mup> Bug #1738197: Daemons do not have an /run/user/* dir created <Snappy:New> <https://launchpad.net/bugs/1738197>
<mborzecki> the piece of code that created runtime dir was disabled with this commit https://github.com/snapcore/snapd/commit/7ea43f1c74e1e056250359031cb715cb85adb349 but there's no message or anything
<mvo> hey mborzecki good morning
<mvo> mborzecki: I don't remember the backstory :( and the commit description does not help much. I think zyga will remember
<mborzecki> mvo: i also found this PR https://github.com/snapcore/snap-confine/pull/195
<mup> PR snap-confine#195: Fix creation of $XDG_RUNTIME_DIR and $SNAP_USER_DATA <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snap-confine/pull/195>
<mborzecki> opened and closed by zyga,  i suppose there were some security concerns raised by jdstrand
<mborzecki> mvo: switched to bug report to confirmed for now
<mvo> ta
<mup> PR snapd#4519 opened: arch: add "armv8l" to ubuntuArchFromKernelArch table <Created by mvo5> <https://github.com/snapcore/snapd/pull/4519>
<mup> Bug #1738222 changed: FAIL: main_test.go:769: snapSeccompSuite.TestCompatArchWorks <Snappy:Fix Released by maciek-borzecki> <https://launchpad.net/bugs/1738222>
<mup> Bug #1705220 changed: Removing desktop-ubuntu-app-platform broke any app relying on the webapp-helper <amd64> <apport-bug> <artful> <julyshakedown> <third-party-packages> <Snappy:Invalid> <snapcraft (Ubuntu):Invalid> <https://launchpad.net/bugs/1705220>
<zyga-ubuntu> o/
<kalikiana> moin moin
<mborzecki> zyga-ubuntu: kalikiana: morning
<zyga-ubuntu> what is armv8l?
<pstolowski> mornings!
<zyga-ubuntu> can anyone please do 2nd review for https://github.com/snapcore/snapd/pull/3963
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<zyga-ubuntu> pstolowski, mvo: can you please give concrete votes on 4505, I'd like to know if there's more work there or can I iterate on top
<mup> PR snapd#4519 closed: arch: add "armv8l" to ubuntuArchFromKernelArch table <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4519>
<kalikiana> o/ mborzecki pstolowski zyga-ubuntu
<pstolowski> zyga-ubuntu, looking
<mup> PR snapd#4520 opened: daemon: unlock state even if RefreshSchedule() fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4520>
<zyga-ubuntu> mvo: you didn't add the mount unit
<zyga-ubuntu> thanks!
<mvo> zyga-ubuntu: meh, sorry and thanks
<mvo> zyga-ubuntu: are the spread tests under cmd/snap-confine still run?
<mvo> zyga-ubuntu: I ask because there is one that is concerned with snappy-app-dev and this needs to move to /usr/lib/snapd to work with bases
<mborzecki> 4520 ^^ trivial review
<mup> PR snapd#4521 opened: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/4521>
<zyga-ubuntu> mvo: no, only those in tests/ are used
<zyga-ubuntu> mvo: there are probably a few stale tests under snap-confine
<mvo> zyga-ubuntu: do you mind if I remove at least the one dealing with snappy-app-dev?
<zyga-ubuntu> mvo: do they hurt? I think those should be (eventually) ported and re-enabled
<zyga-ubuntu> mvo: is that test actually running now?
<zyga-ubuntu> mvo: and relevant to the discussion is https://github.com/snapcore/snapd/pull/4399
<mup> PR #4399: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
<pstolowski> zyga-ubuntu, reviewed, some tiny remarks
<zyga-ubuntu> pstolowski: thank you! looking
<Chipaca> zyga-ubuntu: that traceback and error, is that fedora in our tests, or in the wild?
<zyga-ubuntu> Chipaca: I think that was in the tests that cachio ran
<Chipaca> the net.Error case is new, but the tricky code existed before
<Chipaca> I'll push something
<zyga-ubuntu> question
<zyga-ubuntu> when you hack on go
<zyga-ubuntu> do you keep a symlink in ~ to the $GOPATH/src/yadayadayada directory?
<zyga-ubuntu> I ask because I do and I hate how go fmt is stupid and doesn't cope with that
<Chipaca> zyga-ubuntu: I don't understand what you symlink
<Chipaca> zyga-ubuntu: in any case, no i don't keep a symlink in ~ to that :-)
<zyga-ubuntu> Chipaca: ~/snapd -> ~/go/src/github.com/snapcore/snapd
<zyga-ubuntu> pstolowski: updated
<pstolowski> zyga-ubuntu, k, looking
<Chipaca> zyga-ubuntu: I just ^R cd ~ and it completes that :-)
<Chipaca> zyga-ubuntu: but it helps that I just have two go workspaces i work in with any frequency, snapd and my personal one
<Chipaca> if i had more i'd need to get inventive
<pstolowski> zyga-ubuntu, thanks for the helpers! looks very nice!
<pstolowski> +1
<zyga-ubuntu> pstolowski: thank you for the idea, I will use them in the rest of the code next
<zyga-ubuntu> Chipaca: I see, thanks
<Chipaca> did we have a checker for "it's one of these two"?
<zyga-ubuntu> Chipaca: so, I feel like I could benefit from your walker and container validation thing
<zyga-ubuntu> Chipaca: I could use it to validate that the layout makes sense
<zyga-ubuntu> Chipaca: you could abuse "contains" checker in reverse, I presume
<zyga-ubuntu> offtopic: my new favourite theme: agola green
<Chipaca> zyga-ubuntu: ebola green?
<zyga-ubuntu> https://packagecontrol.io/packages/Agola%20Color%20Schemes
<Chipaca> zyga-ubuntu: i'll push this pr and then fix my container thing
<zyga-ubuntu> Chipaca: thanks, it's not urgent, just something I realized
<Chipaca> aaand i've just done the old "committed to my master and pushed" idiocy
<zyga-ubuntu> Chipaca: classic, I do that all the time
 * Chipaca now needs to go to github, flip a flag, push force, flip it back
<zyga-ubuntu> pstolowski: can you look at https://github.com/snapcore/snapd/pull/4502 please, it's related
<mup> PR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>
<zyga-ubuntu> pstolowski: probably will do a round of similar changes there
<mup> PR snapd#4520 closed: daemon: unlock state even if RefreshSchedule() fails <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4520>
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4516 is green now but I'm not sure if we want to merge it yet
<mup> PR #4516: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
<pstolowski> zyga-ubuntu, sure
<mup> PR snapd#4522 opened: daemon: avoid panic'ing building an error response w/no snaps given <Created by chipaca> <https://github.com/snapcore/snapd/pull/4522>
<Chipaca> zyga-ubuntu: ^ should address the issue
<zyga-ubuntu> Chipaca: +1
<zyga-ubuntu> mvo: commented on 4517
<mvo> zyga-ubuntu: thanks, I am not hopefully for any of these approaches
<zyga-ubuntu> mvo: what do you think will happen?
<mvo> zyga-ubuntu: I have the feeling we need something more fundamental or more targeted, the problem is right now e.g. apt remove snapd fails because /snap is probably busy
<zyga-ubuntu> mvo: yuck, that's indeed bad
<zyga-ubuntu> mvo: so
<mvo> zyga-ubuntu: so something more fundamental would be good except that we can't ship it in other distros :/
<zyga-ubuntu> mvo: maybe time to share one (very weird and crazy) idea
<mvo> zyga-ubuntu: more targeted may mean to just run this bind,share if condition=virtual is meet
<mvo> zyga-ubuntu: sure, share!
<zyga-ubuntu> mvo: you can do this:
<zyga-ubuntu> mvo: mkdir foo
<zyga-ubuntu> mvo: in one terminal unshare, mount --bind foo foo
<zyga-ubuntu> mvo: in another terminal, afterwards, rmdir foo
<zyga-ubuntu> mvo: this works
<zyga-ubuntu> mvo: now, this lets us make a namespace where a bind mount is present and where we can do whatever we want
<zyga-ubuntu> mvo: here's a crazy idea
<zyga-ubuntu> mvo: what if we did all the rsharing in a mount namespace snap-confine implicitly joins as soon as it starts
<mvo> zyga-ubuntu: hm, if that works, +1
<zyga-ubuntu> mvo: that ns could be a slave of the real thing
<zyga-ubuntu> mvo: and it could do all the magic needed that wouldn't leak outside
<zyga-ubuntu> mvo: so apt and friends can remove things as they usually do
<zyga-ubuntu> mvo: not sure, just thought about it, I can give it a try
<mvo> zyga-ubuntu: please, I will poke around a bit more but I doubt the current mount unit approach is feasible
<zyga-ubuntu> mvo: I wonder if this can be fixed in containers
<zyga-ubuntu> mvo: maybe lxd can just do the right thing
<zyga-ubuntu> Failed to issue method call: Unit snap.mount.service failed to load: No such file or directory. See system logs and 'systemctl status snap.mount.service' for details.
<zyga-ubuntu> is it snap.mount or snap.mount.service?
<zyga-ubuntu> looks like a simple error there mvo
<mup> PR snapd#4505 closed: interfaces/mount,snap: early support for snap layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4505>
<mvo> zyga-ubuntu: indeed, let me fix, it should be snap.mount only
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> your change broke one very unexpected place
<zyga-ubuntu> + echo 'error: cannot install ["test-snapd-classic-confinement"]: classic confinement
<zyga-ubuntu>        requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap'
<zyga-ubuntu> error: pattern not found, got:
<zyga-ubuntu> see ["foo"] vs "foo"
<zyga-ubuntu> error: cannot install ["test-snapd-classic-confinement"]: classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap
<Chipaca> zyga-ubuntu: hah. Not _that_ unexpected
<Chipaca> zyga-ubuntu: in fact i was wondering if that'd come up
<Chipaca> zyga-ubuntu: I can fix :-)
<Chipaca> thanks for the heads-up
<zyga-ubuntu> mvo: snap.mount doesn't work :/
<zyga-ubuntu> Removing snapd (1337.2.30) ...
<zyga-ubuntu> Job for snap.mount failed. See "systemctl status snap.mount" and "journalctl -xe" for details.
<zyga-ubuntu> dpkg: error processing package snapd (--purge):
<zyga-ubuntu> :-(
<mvo> zyga-ubuntu: yeah, I was afraid this would happen
<mvo> zyga-ubuntu: snap.mount cannot be stopped as the mount point is busy. but we cannot make it not-busy unless we purge
<zyga-ubuntu> hmm hmm hmm
<zyga-ubuntu> but why is it busy
<zyga-ubuntu> it is busy because it is a mount point?
<zyga-ubuntu> maybe what we need is a bind mount from /var/lib/snapd/snap to /snap
<zyga-ubuntu> maybe it's a systemd bug
<zyga-ubuntu> I would presume systemd would stop all the snap mount units inside first
<zyga-ubuntu> then stop snap.mount
<mvo> niemeyer: you mentioned yesterday that you want to learn more about the writable handling for etc and var, I wrote a summary of the status now and a proposal into https://forum.snapcraft.io/t/writing-to-etc-and-var-from-the-core-snap/3653
<mvo> zyga-ubuntu: I think it is because /snap/* is still available on remove, we only get rid of the actual snaps on purge
<zyga-ubuntu> mvo: hmmm,
<zyga-ubuntu> mvo: but if dpkg starts this, dpkg first should run prerm script
<zyga-ubuntu> mvo: do we stop services and unmount snaps in prerm?
<zyga-ubuntu> iff we do, it could just work
<mborzecki> zyga-ubuntu: can you try to use snap-mgmt in prerm?
<zyga-ubuntu> mborzecki: I think we should unify script management but it's hard due to way dpkg handles files
<zyga-ubuntu> mborzecki: it'd be easier if our build system split snap-mgmt and injected it into actual dpkg management scripts
<mvo> zyga-ubuntu: we could do that, yes. it would be different from what we are doing currently. i.e. we leave the snaps and only purge on purge
<zyga-ubuntu> mborzecki: as those have differnet lifecycle from the other package files
<zyga-ubuntu> mvo: actually...
<zyga-ubuntu> mvo: we only have to unmount /snap on purge too
<zyga-ubuntu> mvo: can we make dpkg ingore /snap?
<zyga-ubuntu> mvo: if we don't ship it
<zyga-ubuntu> mvo: just create it in a script:?
<mvo> zyga-ubuntu: yeah, we would have to create it in postinst and manage it manually
<mvo> zyga-ubuntu: ugly as **** but worth a try
<Chipaca> zyga-ubuntu: tweaked #4522 a little, should address that failure you saw (and be a little nicer)
<mup> PR #4522: daemon: avoid panic'ing building an error response w/no snaps given <Created by chipaca> <https://github.com/snapcore/snapd/pull/4522>
<zyga-ubuntu> Chipaca: nice, looking
<Chipaca> when it's just one snap, error message should now be identical to what it was before
<zyga-ubuntu> ++
<zyga-ubuntu> yep
<Chipaca> when it's something else, it'll be something else :-) but nicer
<Chipaca> also less duplication, in exchange for some shenaniganry
<Chipaca> (take *that*, branch predictor!)
<Chipaca> hmmmmm
 * Chipaca fixes the fix
<mup> PR snapd#4522 closed: daemon: avoid panic'ing building an error response w/no snaps given <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4522>
<Chipaca> is raspbian always armel?
<ackk> kalikiana, hi, do you think https://github.com/snapcore/snapcraft/pull/1617 can be merged now?
<mup> PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>
<zyga-ubuntu> cachio: observation: go test ./... is far far far faster than our run checks --unit
<zyga-ubuntu> actually, can you guys please: time go test ./...
<zyga-ubuntu> from the top of the tree
<cachio> zyga-ubuntu, I'll try it
<zyga-ubuntu> pstolowski: Attr() cannot be used to check if an attribute of _any_ type exists
<zyga-ubuntu> passing interface{} won't cut it
<zyga-ubuntu> ideas?
<zyga-ubuntu> pstolowski: I'd like to add HasAttr()
<pstolowski> zyga-ubuntu, I know. I've addressed this in #4510
<mup> PR #4510: asserts: use Attrer in policy checks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>
<zyga-ubuntu> ah, nice
<zyga-ubuntu> hmm hmm
<zyga-ubuntu> ok, I'll add a todo and wait
<pstolowski> zyga-ubuntu, note, attributes can be nested. in 4510 I've also added support for dotted paths. HasAttr() will only make sense with dotted paths I guess
<kalikiana> ackk: I'd suggest to check with kyrofa  - I don't have merge powers :-D
<pstolowski> zyga-ubuntu, 4510 needs Samuele's review.. not sure if you can wait till he is back?
<mup> PR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4506>
<zyga-ubuntu> pstolowski: I think this is fine, I added a TODO note to use Lookup
<Chipaca> zyga-ubuntu: snap.ValidateContainer on master
<zyga-ubuntu> Chipaca: I saw, thank you!
<Chipaca> k
<pstolowski> zyga-ubuntu, k
<zyga-ubuntu> Chipaca: so with that, I will probably look at making it useful for validating layout
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4329 needs a 2nd review
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<mup> PR snapd#4523 opened: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4523>
<zyga-ubuntu> mborzecki: about 4523
<zyga-ubuntu> mborzecki: does the new xml snippet mean anyone can introspect udisks?
<zyga-ubuntu> I think the plug apparmor part must define something like that too
<zyga-ubuntu> ah, it already does that
<mborzecki> zyga-ubuntu: yeah, it was missing from the slot
<mborzecki> zyga-ubuntu: once i got that, the dbus rule was disallowing calls to Introspectable :/
<mborzecki> dbus snakepit
<zyga-ubuntu> hmm
<zyga-ubuntu> Chipaca: so, for containers, did you come up with a practical way to mock them?
<Chipaca> zyga-ubuntu: simplest way is to use a snapdir
<Chipaca> zyga-ubuntu: look at the tests of validate container in snap/container_test.go
<zyga-ubuntu> mmm
<zyga-ubuntu> yeah, I just need to tweak my code to accept a container
<zyga-ubuntu> and not attempt to derive one from snap info
<zyga-ubuntu> that will be much nicer for testing
<mup> PR snapd#4515 closed: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4515>
 * zyga-ubuntu jumps for quick lunchj
 * kalikiana going for lunch (and yay, a little bit of sun)
<Chipaca> niemeyer: https://forum.snapcraft.io/t/snapshots-implementation-details/3656
<Chipaca> niemeyer: i think that touches on the bits that were making you nervous, or for which you were lacking context
<Chipaca> getting it working so you can play with it is what i'm working towards, eta tomorrow
<Chipaca> notably the switch to zip at the toplevel was painless :-)
<niemeyer> Chipaca: Thanks!  I'm actually kinda nervous that we didn't talk much about the overall design.. I'm worried of introducing late suggestions that would make you cringe
<Chipaca> niemeyer: I know you'll persevere and do it anyways :-)
<Chipaca> niemeyer: (i'm joking; bring on the suggestions)
<niemeyer> Chipaca: I'll try to see that as a compliment :D
<Chipaca> niemeyer: are those suggestions going to be on the forum?
<niemeyer> Chipaca: We should definitely at least have a summary there, but depending on the topics to be covered a call might be nice.. I'll ping you this afternoon in either case
<niemeyer> cachio: That unit test takes about 10 minutes alone
<niemeyer> cachio: This is definitely making a significant impact on the overall test, because it's mixed in with all the other tests
<niemeyer> Imagine what happens if systems are all happy churning, and then at the 20 minutes mark they start running unit tests, for example
<niemeyer> That's probably one of the reasons why we fail to improve the overall test performance.. I'll have a look into this today
<niemeyer> In any case, " Ran for 25 min 49 sec"
 * pstolowski lunch
<cachio> niemeyer, ok, I'm researching that as well
<cachio> niemeyer, thanks for the heads-up
 * cachio afk 
 * Chipaca afk for a bit
<kalikiana> re
<greyback> jdstrand: question on an x11 slot. The X socket is hardcoded to /tmp/.X11-unix/X*. If X server is snapped, that /tmp is actually a private subdir of /tmp/$SNAP. I'm struggling to see a nice way to share the socket path with another snap that plugs in. Would the config system be a sensible way?
<greyback> so the plug would call "snap get x11 socket" and get a path to the socket back
<zyga-ubuntu> greyback: this is something that will be done via interface hooks
<zyga-ubuntu> greyback: please look at this PR, the tests do something quite like this
<greyback> zyga-ubuntu: interesting, looking...
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4358
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<zyga-ubuntu> specifically...
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4358/files#diff-1ee943f85f142e4019d5625a0045a88dR7
<zyga-ubuntu> jdstrand: https://github.com/snapcore/snapd/pull/4523 needs your 2nd review (very short)
<mup> PR #4523: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4523>
<mup> PR snapd#4502 closed: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4502>
<pstolowski> greyback, sounds like a good use case for interface hooks indeed. basically, on 'snap connect..' hooks are executed on plug and slot sides, and they can exchange data before connection is finalized
<zyga-ubuntu> jdstrand: this PR https://github.com/snapcore/snapd/pull/4521 is related to your work
<mup> PR #4521: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/4521>
<greyback> pstolowski: yeah it sounds like it. Does it look far from landing?
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4512 is green and needs a 2nd review
<mup> PR #4512: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4512>
<zyga-ubuntu> (we are getting close to having 3X reviews rather than 4X
<jdstrand> zyga-ubuntu: re 4523, done. re 4521, ack (note that I put that on the backburner for the moment to get to other higher priority items)
<pstolowski> greyback, my guess is probably a few weeks as there is some followup stuff that needs to land before we can enable the feature
<greyback> pstolowski: ack, thanks
<elopio> Hello!
<zyga-ubuntu> jdstrand: ack
<mup> PR snapd#4523 closed: interfaces/builtin: allow introspecting UDisks2 <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4523>
<zyga-ubuntu> niemeyer: can we land https://github.com/snapcore/snapd/pull/4516 or do you need to do more tweaking on it?
<mup> PR #4516: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
<zyga-ubuntu> (alternatively close it)
<niemeyer> zyga-ubuntu: Still working on it
<zyga-ubuntu> ack
<zyga-ubuntu> cachio: https://github.com/snapcore/snapd/pull/4511 is failing for real
<mup> PR #4511: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4511>
<kyrofa> ackk, indeed, it seems that feature is contained in 2.30, which has made it to stable, in my mind it can be merged
<kyrofa> I've updated it to bring it inline with master, the tests are running once more
<ackk> kyrofa, cool, thanks
<kyrofa> ackk, see sergio's comment on the PR. Are you up for that?
<cachio> zyga-ubuntu, yes
<cachio> also the issue that was seen in fedora should be considered, it failed to read ssh config file
<cachio> zyga-ubuntu, now as we are not executing ssh to coonect any more the error is not being reproduced
<zyga-ubuntu> cachio: not sure about fedora, the only thing I recall was an error in daemon/api.go -
<zyga-ubuntu> cachio: there's ssh_config in the core snap so it should be there
<zyga-ubuntu> cachio: did you investigate why it failed?
<cachio> zyga-ubuntu, running it now
<zyga-ubuntu> thank you!
<brunosfer> Hey guys! I need a little help from you. I'm snapcrafting my application into a snap and I'm getting some errors importing a package I called bridge. The error is: "package bridge: unrecognized import path "bridge" (import path does not begin with hostname)"
<zyga-ubuntu> brunosfer: that error looks like app specific thing
<mup> PR snapcraft#1873 closed: elf: cleaner patchelf experience <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1873>
<brunosfer> zyga-ubuntu: I think the snapcraft is trying to compile the package. However that package is a dependency of the project.
<brunosfer> zyga-ubuntu: Is there a way in the yaml file where I can specify that the specific package is a dependency and it should not be compiled?
<zyga-ubuntu> kyrofa: ^
<kyrofa> Hmm
<mup> PR snapcraft#1865 closed: lxd: always (re-)injects snaps <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1865>
<kyrofa> brunosfer, I'm afraid I don't quite understand the issue. Any chance you can share your YAML?
<brunosfer> kyrofa: How do you suggest to share?
<kyrofa> brunosfer, pastebin.ubuntu.com works pretty well
<kyrofa> Unless you already have it in e.g. github
<brunosfer> kyrofa: I'm gonna use pastebin, I don't have the project on github.
<kyrofa> brunosfer, sure thing
<brunosfer> kyrofa: Please check https://pastebin.ubuntu.com/26444892/
<cachio> zyga-ubuntu, https://paste.ubuntu.com/26444896/
<kyrofa> brunosfer, the `bridge` part is being built because you specified it as a part. Is that the one that's failing?
<cachio> zyga-ubuntu, so, the file does not exist as part of the /etc/ssh/
<brunosfer> kyrofa: yes it is
<brunosfer> kyrofa: yes it is
<brunosfer> kyrofa: how should I specify it?
<kyrofa> brunosfer, you mention that it's a dependency. A dependency of what?
<zyga-ubuntu> cachio: hmm
<zyga-ubuntu> cachio: that's interesting
<zyga-ubuntu> cachio: maybe some kind of writable path magic? not sure
<brunosfer> kyrofa: The package `bridge` is imported by the main package.
<kyrofa> brunosfer, you probably don't need to specify it as a part, then
<cachio> zyga-ubuntu, yes, not sure why it is there
<cachio> mvo, any idea?
<kyrofa> brunosfer, just specify the main part
<zyga-ubuntu> cachio: probably because of this
<zyga-ubuntu> https://github.com/snapcore/core-build/blob/master/config/etc/system-image/writable-paths#L50
<cachio> zyga-ubuntu, ouch
<cachio> zyga-ubuntu, ok, in that case I could either to check on the core snap or skip it for core
<cachio> zyga-ubuntu, I dont understand why is not mounting just 3 files
<mvo> cachio: sorry, I miss context - you don't see a file or what is going on?
<cachio> the ssh-config file is on /snap/core/x1/etc/ssh/ssh_config
<cachio> and we are checking the file in /etc/ssh
<cachio> it is happening just on core systems
<cachio> mvo, so, we are no sure if it is an issue or is it ok that the file is just part of the core snap
<mvo> cachio: the writable-path magic will not copy files there is /etc already exists
<mvo> cachio: do you have a branch where this fails?
<mvo> cachio: I'm still not sure I see the bigger picture
<cachio> mvo, https://github.com/snapcore/snapd/pull/4511
<mup> PR #4511: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4511>
<mvo> cachio: that is interessting, I'm sure its related to writable-paths. however when I try this on my pristine core device I have /etc/ssh/ssh_config
<ogra_> zyga-ubuntu, whats wrong with that writable-path line ? it defines that all content of the dir is copied to writable on first boot so that you have /etc/ssh on the running system
<mvo> cachio: so it must be something related to our test setup
<cachio> mvo, yes, probably
<mvo> cachio: could you please run it with -debug so that we can see the content?
<cachio> on how we create the core image
<cachio> mvo, I have a debug open
<cachio> what you want to see
<mvo> cachio: ls -al /etc/ssh for a start :)
<ogra_> note that the writable-paths are processed by the initrd on first boot ... before you booted for the first time all these dirs will be empty
<ogra_> (in case you poke around in an unbooted image there)
<cachio> mvo, https://paste.ubuntu.com/26445000/
<ogra_> looks broken ...
<mvo> cachio: and ls -al /snap/core/current/etc/ssh please?
<cachio> https://paste.ubuntu.com/26445012/
<mvo> cachio: ok, the issue is with prepare.sh
 * ogra_ points to http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html and specifically the description in paragraph 4 (transition)
<ogra_> "WARNING:  This is a one-off operation which requires that the
<ogra_>                  source  directory  on  the  writable  partition   not   exist
<ogra_>                  initially: if this condition is satisfied, the directory will
<ogra_>                  then be created and the data moved on  first  boot.  Although
<ogra_>                  the  mountpoint  will be writable, note that subsequent boots
<ogra_>                  will ignore any new files appearing or  disappearing  in  the
<ogra_>                  original  read-only  rootfs  location  unless  you  perform a
<ogra_>                  factory reset."
<mvo> cachio: we write a custom /etc/ssh/sshd_config into /writable and this prevents the writable-paths stuff to copy things because the dir already exists, this is only an inssue in the test. give me 2min and there should be a pastebin with the fix
<niemeyer> cachio: I can confirm the theory..
<mvo> cachio: please try https://paste.ubuntu.com/26445024/
<ogra_> makin it synced might help here
<mvo> ogra_: yeah, that would also work
<niemeyer> cachio: Found logs showing the Go unit tests starting to run 21 minutes into the logs
<niemeyer> Which pushes the full run into 30+ minutes even if everything else has finished
<niemeyer> I'm tuning it
<cachio> niemeyer, 21 minutes?
<niemeyer> cachio: Yeah, after 21 minutes of everything else working, the long task kicked in
<cachio> niemeyer, are you going the define something like order on spread?
<niemeyer> cachio: Maybe.. in the first experiment I'll just isolate these tasks in their own system to force parallelism.. that's less ideal than defining ordering because the systems are trashed after the task is done.. priority ordering would be better because the systems can be reused
<cachio> mvo, so, for ubuntu-core I should check inside the core snap, right?
<brunosfer> kyrofa: The error is exactly that! When I specify the main as a part. The snapcraft tool doesn't recognize the `bridge`.
<mvo> cachio: just check /etc/ssh/ssh_config and apply the patch I pastebined to your PR and things should work
<mvo> cachio: i.e. just apply my pastebin :)
<cachio> ok, running
<mvo> cachio: and re-run the test and it should be fine
<brunosfer> kyrofa: The error is: "package bridge: unrecognized import path "bridge" (import path does not begin with hostname)"
<kyrofa> brunosfer, ah, so you get that error if you remove the bridge part?
<cachio> mvo, I'll tell you the result
<cachio> niemeyer, otherwise we could split the unit test to make smaller tasks
<brunosfer> kyrofa: Yes. When I remove the `bridge` as a part and I only set as a part the `main` I get that error and I don't know why.
<cachio> niemeyer, that could help too
<niemeyer> cachio: Yes, but that'd be a bit boring to maintain over time
<mup> PR snapd#4524 opened: cmd: remove unused execArg0/execEnv  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4524>
<niemeyer> cachio: Introducing a priority setting feels much nicer
<kyrofa> brunosfer, alright, the picture is getting clearer. Let me finish this meeting I'm in now and I'll help further
<brunosfer> kyrofa: Awesome! Thank you.
<cachio> niemeyer, I could implement that if you think it could be valuable
<mvo> could someone one fedora paste me /lib/systemd/system/systemd-sysusers.service please?
<mvo> (pastebin)
<niemeyer> cachio: Thanks, I'm pretty sure it will be valueable.. let's see what the result of changing it looks like
<cachio> niemeyer, ok, I'll work on that
<niemeyer> cachio: Thanks!
<cachio> niemeyer, what do you think that could be better something like [HIGH ,LOW] or a numeric system [1...10]?
<niemeyer> cachio: Something like "priority: 42" seems nice
<cachio> niemeyer, ok
<niemeyer> cachio: Defaults to zero.. then we just need to sort the job list after the shuffle
<niemeyer> cachio: Note that the sort must be stable
<niemeyer> cachio: Otherwise the shuffle will be undone
<cachio> niemeyer, ok, so, bigger is bigger priority, ritght?
<niemeyer> cachio: Yes, I suspect that'll be easier to work with
<cachio> niemeyer, yes, agree
<niemeyer> cachio: As oppoesed to renice-like inverted priority
<Chipaca> mvo: let me figure out how to pastebin it and sure
<Chipaca> mvo: https://paste.ubuntu.com/26445110/
<Chipaca> mvo: that's from Fedora Cloud Base 24
<Chipaca> which may or may not be what you wanted
<Chipaca> - but it's what i had -
<mvo> Chipaca: thank you!
<mvo> Chipaca: that is perfect
<niemeyer> " Ran for 23 min 2 sec "
<niemeyer> And that's before even isolating the tests.. let's see now
<cachio> niemeyer, wow
<niemeyer> Saviq: ping
<Saviq> niemeyer: here
<niemeyer> Saviq: Heya..
<niemeyer> Saviq: Dynamic allocations are a thing now.. can you please update your repository's spread.yaml with this snippet under the backend:
<niemeyer> plan: 8GB
<niemeyer> location: fremont
<Saviq> w00t
<niemeyer> Saviq: If you've run anything recently, it was already dynamically allocated.. but that's because I've put a hack in our spread binary tarball.. I need to remove the hack, and for your runs to not break that snippet needs to be in place
<niemeyer> That goes inside the linode backend stanza, next to the key
<Saviq> niemeyer: we're using the snapped spread, FWIW
<Saviq> should we switch to your build already?
<kalikiana> kyrofa: sergiusens: elopio FYI shared the minutes with you. please double-check your junk mail etc. if you don't seem to be getting them
<niemeyer> Saviq: Ah, okay, so you won't see it..
<kyrofa> kalikiana, I always get them!
<niemeyer> Saviq: I haven't touched your other PRs yet, so probably not
<kalikiana> kyrofa: Leo told me that's where they went. I don't know if that was just Google being "smart", I just want to be sure you get the minutes :-D
 * zyga-ubuntu -> loooong walk
<niemeyer> Saviq: Or are you using the stock spread snap?
<Saviq> niemeyer: stock snap
<elopio> thanks kalikiana. Not on the spam this time :)
<Saviq> let me confirm
<kalikiana> kyrofa: I use my best hand-writing there, so I hope they will be read ;-)
<niemeyer> Saviq: Okay, great.. so please just update the spread.yaml file with these fields, and it will all take care of itself in due time
<kalikiana> elopio: Awesome! Thanks for confirming
<codeplug> Hi, how can I set a snap to automatically start when booting up?
<kyrofa> codeplug, make the app in the snap a service
<kyrofa> You can do that by adding `daemon: simple` to the app definition (alongside `command`)
<codeplug> will try. Thanks!
<kyrofa> codeplug, note that this is a system service-- it runs as root
 * Chipaca EODs
<kyrofa> sergiusens, you joining the summit prep?
<sergiusens> kyrofa yeah, sorry
<brunosfer> kyrofa: Sorry to bother you with this issue, but I'm really stuck here. =S
<kyrofa> brunosfer, no problem, I haven't forgotten! Just a few more minutes
<brunosfer> kyrofa: Ok! Thanks ;)
<diddledan> EOD: Emergence of Destruction?
<diddledan> :-p
<lundmar> Hmm, how does snapcraft actually stage stuff? I'm having some trouble trying to make Qt detect a QT "charts" module which is built and installed using the qmake plugin. The "charts" module is not available in Ubuntu Xenial. It seems the charts module (libs, headers) etc. ends up in staging but this is different from the normal system location so it is not found by Qt.
<lundmar> I thought snapcraft made staging appear as the system root.
<lundmar> */assumed
<nacc> lundmar: have you ordered your yaml correctly?
<nacc> lundmar: which Qt do you mean, stage is a build-time thing, as well
<diddledan> lundmar: snapcraft doesn't make the stage dir into a fake root
<lundmar> nacc: I'm trying to do this after I've found out Xenial does not have qtcharts5: https://github.com/lxi-tools/lxi-tools.snapcraft/commit/3ef4d1ba179d2c1a5cbac450d06f604ded24bbf4
<lundmar> diddledan: ok, so it's all LDCONFIG and enviroment variables directed.
<diddledan> yup
<nacc> lundmar: you should be able to `snapcraft stage qtcharts` (iirc) and see what it put in stage/
<diddledan> the chances are you're installing to $SNAPCRAFT_STAGE/usr/local which I don't think is included in the default overridden search paths for headers and libraries for other parts
<nacc> yeah'
<lundmar> thats kind of the problem, I can't find a way to tell Qt to look for the additional charts module installed in staging.
<diddledan> try adding a prefix of "/usr" which will be redirected into `$SNAPCRAFT_STAGE/usr`
<nacc> if they are in usr/local, then you need to tell Qt that, otherwise what diddledan is saying
<lundmar> nacc: during build it seems to stage qtcharts successfully.
<lundmar> I'll try change the prefix
<lundmar> assuming the qmake plugin supports it haha
<diddledan> I'm not familiar with qmake but cmake and autotools both provide the ability to set prefix=
<lundmar> :)
<diddledan> so I'd be surprised if qmake was different
<lundmar> I'll find out
<nacc> https://docs.snapcraft.io/reference/plugins/qmake
<nacc> i'm guessing it's a qmake option?
<lundmar> thats a short doc he he
<diddledan> ok, so if you find out the qmake command line flag then set `options: [--your-qmake-prefix-flag=/usr]`
<lundmar> qmake PREFIX=...
<diddledan> ok so `options: [PREFIX=/usr]` should work
<lundmar> I've started a build using that
<lundmar> btw, is there any way to avoid downloaing stuff repeatedly when using e.g. cleanbuild --debug ?
<lundmar> I mean, it's a lot of download for each debug iteration
<lundmar> would be nice if it could be cached
<ogra_> mvo, once the core is in stable, will you make sure we get a proper edge build with master again ... i'm itching to test the multi-volume fix (and the customer too)
<kyrofa> niemeyer, what's the status of some way for a snap to say "I'm in use, don't update!" ?
<niemeyer> kyrofa: Planned, wanted :)
<kyrofa> Prioritized?
<niemeyer> kyrofa: Not in the schedule just yet..
<kyrofa> Alright, thank you
<niemeyer> kyrofa: That and manual postponing may be nice things for after the current promised features
<nacc> lundmar: yeah, i wish too
<nacc> lundmar: the probably is, it doesn't keep the lxd around, of course
<nacc> lundmar: so you need to cache it in the lxd host (e.g., apt-cacher-ng or so)
<ogra_> nacc, snap install packageproxy ... and make sure your sources.lists point to localhost:9999 ;)
<lundmar> nacc: one thing is for sure, the more popular snap gets, the more some sort of cache mechanism is wished for. Also, to offload the hard pressed Ubuntu build servers.
<nacc> ogra_: yeah that works too
<nacc> ogra_: the issue being if you ahve multiple envs, maintaining all of them starts to be a pain
<nacc> lundmar: --^ for the above, lxd profiles are nnice
<ogra_> indeed
<kyrofa> brunosfer, I'm out of my meeting!
<nacc> but afaik, snapcraft can't use them yet
<diddledan> use `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft` instead of `snapcraft cleanbuild`
<kyrofa> brunosfer, you still around?
<nacc> diddledan: ah does that just call lxc directly?
<diddledan> then it will keep the lxc container between runs
<nacc> diddledan: ah
<brunosfer> kyrofa: Yep! Still stuck...
<kyrofa> brunosfer, very good. It's been a while since I've written some go, so let me test something out real quick
<brunosfer> kyrofa: Ok! Thanks ;)
<lundmar> diddledan: oh, thanks. I'll try that.
<diddledan> best to still check with a proper cleanbuild once you've got it running though in case you installed a `build-package` which you rely on and then removed it from the yaml because it'll still be in the container but a cleanbuild won't have it available
<lundmar> diddledan: using the PREFIX still fails. It gets installed in /root/build_lxi-tools/stage/usr/lib/x86_64-linux-gnu which looks right.
<diddledan> yup that looks right
<lundmar> I think the main problem is that qmake does not seem to support looking for "external" Qt modules installed outside of its normal Qt module installation dir (/usr/lib/x86_64-linux-gnu).
<lundmar> so for staging the way snapcraft foes this becomes an issue of course
<lundmar> does*
<nacc> lundmar: even with a flag?
<lundmar> nacc: I've haven't been able to find that flag.
<lundmar> wouldn't it be possible to overlay the staging root with the systems root and solve avoid this type of problem?
<ogra_> make sure you capture it once you found it ;)
<nacc> lundmar: then you would be using the system ... which would not be a confinned snap?
<lundmar> no no, I mean, during snap creation.
<diddledan> lundmar: does `QMAKE_LIBDIR` work?
<lundmar> during runtime it should of course not use system but still be confined.
<lundmar> diddledan: I've tried QMAKE_LIBDIR and QMAKE_INCDIR in the .pro file.
<nacc> lundmar: but presumably it nneeds those built things to be in the snap?
<lundmar> nacc: yes, the ones that are staged.
<kyrofa> brunosfer, alright, which part in the YAML is the "main" one? Are all the other go parts dependencies?
<nacc> lundmar: right, so you wouldn't want ot use the system if it had them :)
<lundmar> nacc: in this case it stages qtchart and the remaining qt5 stuff comes from the core image.
<kyrofa> brunosfer, the problem is that you're specifying a source that doesn't include the dependencies required
<lundmar> diddledan: let me try the QMAKE_LIBDIR again
<brunosfer> kyrofa: the main part is "hype"
<diddledan> you might need to set it to QMAKE_LIBDIR="$QMAKE_LIBDIR:$SNAPCRAFT_STAGE/usr/lib" or some such
<brunosfer> kyrofa: how do you include the source from the required dependencies?
<diddledan> again IANAL so I probably got the syntax wrong
<lundmar> diddledan: yeah, to avoid overriding it. got it.
<diddledan> bingo
<kyrofa> brunosfer, well, you've got your project organized a bit unconventially, and go is all about convention. How do you have this setup when you're not building a snap?
<diddledan> I expect snapcraft is setting it already, so you need to _add_ your path
<kyrofa> brunosfer, local imports, like you're going here, can bite you
<kyrofa> Relative imports
<brunosfer> kyrofa: but how can I set an absolute path for packages that I built in go?
<kyrofa> brunosfer, here, this should help: https://stackoverflow.com/a/10688069/925486
<brunosfer> kyrofa: BTW The application is running in golang with no problems.
<kyrofa> brunosfer, that's what I'm asking-- how do you have your workspace setup, and how are you building the application?
<brunosfer> kyrofa: Inside the snapcraft staging dir I have a folder called "src" and inside this folder I have several folders that I refer in the yaml file as parts. Inside each of those folders I have a golang package.
<brunosfer> kyrofa: My problem is how can I make a yaml file config where I have a golang package in a different folder from the main package.
<kyrofa> brunosfer, I'm asking how you do this _outside_ of snaps
<kyrofa> brunosfer, ignoring snaps, what does your go workspace look like?
<brunosfer> kyrofa: I do: go run main.go
<brunosfer> kyrofa: GOPATH="/home/user"
<kyrofa> brunosfer, and where is main.go relative to the GOPATH?
<brunosfer> kyrofa: GOROOT="/usr/lib/go-1.8"
<brunosfer> kyrofa: The main.go is in src/client/ and the bridge is in src/bridge relative to the GOPATH
<kyrofa> brunosfer, so you have /home/usr/src/client and /home/usr/src/bridge ?
<brunosfer> kyrofa: Yes.
<kyrofa> brunosfer, what happens if you run `go install client` ?
<brunosfer> kyrofa: It installs the client package in /usr/local/pkg
<kyrofa> Not bin?
<brunosfer> kyrofa: But is this needed with the snapcraft tool? I though it would only be needed in go.
<brunosfer> kyrofa: Sorry /usr/bin/pkg
<brunosfer> kyrofa: Sorry for the bad information regarding the `go install client` process. It's giving me error on the GOROOTPATH
<kyrofa> brunosfer, okay, so it doesn't work. What is the error?
<brunosfer> kyrofa: cannot find the package bridge. I guess it's some problem related with the GOROOT path, however I cannot change it.
<kyrofa> brunosfer, no, it's the problem I just told you was a problem :)
<kyrofa> Please read that stackoverflow post
<kyrofa> If you manage to get it working with `go install`, it'll work in snapcraft
<brunosfer> kyrofa: Sorry I didn't understood...
<mvo> ogra_: is edge behind? in theory we should have edge builds (modulo bugs of course)
<ogra_> mvo, 2.30 ...
<mvo> ogra_: uh, let me check why
<kyrofa> kalikiana, dude, just saw the on..to push
<ogra_> (at least on armhf)
<kyrofa> kalikiana, tell me that's not a simple implementation
<kyrofa> Beautiful work
<kyrofa> And easy to make more generic, I think
<mvo> ogra_: yeah, looks like the builds are behind: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<mvo> ogra_: it says build starts in ~30min so fingers crossed, thanks for notifying me
<ogra_> yeah :/
<ogra_> i wonder when we're back to normal ...
<kalikiana> kyrofa: I feel I must've missed something. It looks too simple. Tests passed, though :-D
<kyrofa> I know!
 * kyrofa waits with baited breath on Travis
<kyrofa> Err. Bated
<ogra_> yeah, baited might be a bit fishy ...
<kyrofa> ogra_, exactly what I thought as I pressed enter :P
<ogra_> heh
<kalikiana> My thought was you might have bbq breath or something, and dogs looking at you
<kyrofa> Mmm, bbq
<kalikiana> Exactly
<kalikiana> Might be the fact I'm due for dinner
<brunosfer> kyrofa: The main package (client) can only be compiled and sent to the `/usr/bin/` when the package `bridge` which is a dependency of the package `client` is recognized. The problem I still have is that the yaml config file cannot recognize the path of the bridge.
<kyrofa> brunosfer, it has nothing to do with YAML. The problem is that you don't have a suitable workspace setup
<brunosfer> kyrofa: Ok. I will look further on that. Thanks.
<ogra_> yeah, re-arragne that staplet there
<ogra_> *stapler
<ogra_> twist it 30Â° left ... that should work then :)
<kyrofa> Hmm... now I can't remember if I've shown my wife that movie
<kyrofa> brunosfer, that stackoverflow answer has a link to the go conventions, try to follow them and your life will become less filled with pain
<brunosfer> kyrofa: Ahahahah Thanks for the medication ;)
<kyrofa> :D
<mup> PR snapd#4525 opened: tests: new spread test for interface gpg-keys <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4525>
<kyrofa> elopio, have you tried autopkgtests lately? It sounds like restrictions on other platforms may be over
<elopio> kyrofa: like, no 500 anymore?
<kyrofa> elopio, yeah, it might be back up now
<nacc> request.cgi is still disabled
<nacc> afaik
<nacc> (just asking Laney about it)
<jdstrand> zyga-ubuntu: hey, been going through the layouts PRs. I notied that prt 4505 is already committed, but please see https://github.com/snapcore/snapd/pull/4505/files#r163352592
<mup> PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4505>
<nacc> the build farm is on, on all archs, that's all I can say
<elopio> kyrofa: nop, 500 again
<kyrofa> nacc, in -devel?
<nacc> kyrofa: sorry, which, in -devel? you
<nacc> s/you//
<kyrofa> nacc, sorry, were you asking Laney in #ubuntu-devel? But now I realize the conversation is probably over, haha
<nacc> kyrofa: yeah, i pinged Laney there
<kyrofa> nacc, no response yet, though?
<nacc> kyrofa: yeah, nothing yet, afaict, it's still disabled (that's seaprate from the build farm)
<kyrofa> Alright, I'll idle there and see what comes up
<kyrofa> nacc, thanks for letting us know :)
<nacc> kyrofa: np
<niemeyer> cachio: Fiddling with the images is proving very frustrating.. more so than just implementing priorities. Do you have that ready yet?
<mup> PR snapd#4526 opened: tests: new spread test for gpg-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4526>
<cachio> niemeyer, no yet, I was finishing the new tests for gpg
<niemeyer> cachio: Ok, let me dig into that then
<cachio> niemeyer, sure
<niemeyer> cachio: The problem with the images is that we have too many assumptions on the name of the image
<niemeyer> cachio: So creating a new system that works just for one specific test ends up being troublesome
<cachio> niemeyer, agree
<niemeyer> I'm hoping to get done with these Spread fixes today still
<niemeyer> Well, improvements really.. nothing is broken
<cachio> niemeyer, ok, the next step to reduce test time should be automatically update the images
<cachio> with the dependencies
<cachio> periodically
<cachio> I have that task in the todo list since long time
<sergiusens> kyrofa mind taking an initial view on snapcraft#1881 ? wording and what not
<mup> PR snapcraft#1881: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>
<kyrofa> sergiusens, sure thing
<mup> PR snapcraft#1881 opened: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>
<zyga-ubuntu> re
<kyrofa> sergiusens, you may be interested in bug #1745040
<mup> Bug #1745040: help command replaces the name of commands with itself <Snapcraft:New> <https://launchpad.net/bugs/1745040>
<mup> PR snapd#4527 opened: Fix comment about running gofmt on contributions <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4527>
#snappy 2018-01-24
<mup> PR snapd#4516 closed: spread: setup machine creation on Linode <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
<mborzecki> morning
<mborzecki> linode:ubuntu-14.04-64:tests/main/snap-service is failing accross diferent PRs, looking into it
<mborzecki> well, seems that the test is passing when run manually
<zyga-ubuntu> o/
<zyga-ubuntu> good morning
<mborzecki> zyga-ubuntu: hey, morning
<zyga-ubuntu> hey :)
<zyga-ubuntu> I just made some warm coffee
<zyga-ubuntu> we may have some unusual work to do today
<zyga-ubuntu> is mvo around already?
<zyga-ubuntu> hey chihchun
 * zyga-ubuntu did a nice walk last evening, 5K in the dark and cold of winter
<zyga-ubuntu> I didn't anticipate that I could get to so unpopulted areas of warsaw this quickly
<zyga-ubuntu> good morning mvo
<zyga-ubuntu> mvo: I replied to the thread with jamie now
<mvo> hey zyga-ubuntu
<mvo> zyga-ubuntu: thank you, checking
<mborzecki> mvo: morning
<mborzecki> mvo: morning
<mborzecki> pff
<mborzecki> wrong window :P
<mvo> mborzecki: good morning!
<mup> PR snapd#4528 opened: cmd/snap: improve `snap aliases` output when no aliases are defined <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4528>
<kalikiana> snappy morning
<mborzecki> kalikiana: morning
<pstolowski> good morning!
<mborzecki> pstolowski: morning
<zyga-ubuntu>     - linode:ubuntu-14.04-64:tests/main/snap-service fails recently
<mup> PR snapd#4512 closed: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4512>
<mborzecki> zyga-ubuntu: tried running it separately a coupe of times, but all runs were successful
<zyga-ubuntu> mborzecki: it probably needs to be ran in sequence with other tests, using the same random seed
<ackk> sergiusens, is https://github.com/snapcore/snapcraft/pull/1617 good for merging?
<mup> PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>
<mborzecki> zyga-ubuntu: reproduced test-snap-service problem
<zyga-ubuntu> mborzecki: what do you see?
<mborzecki> an ancient systemd :)
<mborzecki> zyga-ubuntu: calling reload does nothing, or iow, nothing is logged in the journal
<zyga-ubuntu> uh
<zyga-ubuntu> 14.04
<mborzecki> zyga-ubuntu:   Process: 18961 ExecReload=/usr/bin/snap run --command=reload test-snapd-service (code=exited, status=0/SUCCESS)
<mborzecki> and the service is active/running
<mborzecki> just that there is no log
<mborzecki> same thing after restarting the service
<mborzecki> btw. the *.service file looks fine
<zyga-ubuntu> any reason it would regress
<mborzecki> i'll try something more direct, like kill -HUP $MAINPID and setup a trap in the main process
<zyga-ubuntu> it does work sometimes
<mborzecki> zyga-ubuntu: https://paste.ubuntu.com/26450449/ seems to work
<mborzecki> zyga-ubuntu: https://paste.ubuntu.com/26450461/ notice how there's no long from the reload command
<zyga-ubuntu> mborzecki: so was it just a race?
<mborzecki> idk why journal is not capturing the reload command output
<mborzecki> i'll open a PR and we'll see if this is enough of a fix or not
<zyga-ubuntu> thank you
<mup> PR snapd#4526 closed: tests: new spread test for gpg-public-keys interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4526>
<mup> PR snapd#4529 opened: tests/lib/snaps/test-snapd-service: refactor service reload <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4529>
<zyga-ubuntu> hmm
<adriens> hi there. I have a problem installing lxd with snap, not sure if the problem is from snap itself or the lxd package
<adriens> snap list lxd gives: lxd   2.21     5447  canonical  -
<adriens> $which lxd   /snap/bin/lxd
<adriens> but $ lxd init
<adriens> lxd: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory
<adriens> the command "snap run hello"  runs fine, but this app may not need shared libs
<adriens> so I just installed chromium and it runs ok, so I guess the problem is within the lxd 'package'
<pstolowski> mvo, hey, can #4063 land?
<mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
<ikey> is jdstrand back?
<zyga-ubuntu> ikey: yes, he is
<mvo> pstolowski: yeah, I think so, we need to set it to manual: true and cachio needs to integrate it with the spread-daily
<ikey> awesome ty
<ikey> Can we get some attention on this topic then please? :) https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457
<pstolowski> mvo, i see, so i cannot click 'merge' just yet right?
<zyga-ubuntu> ikey: I think jamie has some backlog of topics to cover but I'm sure he will look at this as well
<ikey> awesome, ty
<ikey> basically i just need some basic gotchas so i can get some traction on it
<ikey> this whole steam snap thing has been dragging on a really long time now ^^
<mvo> pstolowski: better not yet, we need to coordinate with cachio
<pstolowski> k
<mup> Bug #1667829 changed: console-conf v0.0.5 crashes if no config needed <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1667829>
<mup> Bug #1650096 changed: 'snap list' does not show devmode property after disable and re-enable a snap <Snappy:Fix Released> <https://launchpad.net/bugs/1650096>
<mup> Bug #1666873 changed: Snap icon is not visible when called from terminal but it does when called from dash <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1666873>
<Saviq> niemeyer: hey, when around, things went wrong somehow this morning: https://travis-ci.org/MirServer/mir/jobs/332706784
<niemeyer> Saviq: Heya
<Saviq> looking at https://travis-ci.org/snapcore/snapd/builds/332735121 - linode is having trouble
<niemeyer> Saviq: Checking
<niemeyer> Saviq: I think this is an issue on my end actually
<Saviq> or that :)
<niemeyer> Saviq: Well.. sort of.. the error on the snapd branch does not match the first one, and is a problem on Linode itself
<Saviq> yeah they are different
<niemeyer> Saviq: I'll look into this
<Saviq> tx
 * Chipaca returns from the dead
<Chipaca> niemeyer: o/
<niemeyer> Chipaca: Heya
<Chipaca> niemeyer: when can we chat about snapshots?
<Chipaca> or when can i read what you've written, if it's written :-)
<niemeyer> Chipaca: I want to unblock you, so we can do that now if you have a moment.. I haven't read your forum post yet with all the spreadness yesterday, sorry, but we can catch up live
<Chipaca> sure, let me get my earphones
<Chipaca> niemeyer: standup h/o?
<niemeyer> Chipaca: Yeah, there already
<mup> PR snapd#4529 closed: tests/lib/snaps/test-snapd-service: refactor service reload <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4529>
<sergiusens> Chipaca how was the highway "from" hell? :-P
<Chipaca> sergiusens: rocky
<Chipaca> sergiusens: also rolly
<Chipaca> niemeyer: forum post updated, give it a once over in case i got it wrong
<kalikiana> o/ sergiusens
 * kalikiana going to have lunch in ~10
<jdstrand> ikey: hey, I am. I've got a todo to respond to your forum post
<kenvandine> kalikiana, sergiusens:  when will cleanbuild support building on a bionic base? There's a lxc image available at ubuntu-daily:18.04 already and we have the base-18 snap
<ogra_> jdstrand, hey, i was just asked by a customer if we have a hdparm snap (indeed we dont) ... packaging it is less than a 20 lines snapcraft.yaml, but i cant really find an interface that would allow me to not run it in devmode ... do you have any idea ?
<jdstrand> ogra_: I'd have to see the denials
<ogra_> (devmode works fine as a mometary workaround ... but i fear the audit logging might actually falsify the measuring data)
<jdstrand> I presume /dev/[sv]d* and friends
<ogra_> jdstrand, this is what i get in devmode on my laptop https://paste.ubuntu.com/26451245/
<ogra_> (nvme disk ... )
<jdstrand> right nvme
<jdstrand> anyway, that would need a new interface. it would obviously be massively powerful
<ogra_> not sure why it touches all these loop devices
<jdstrand> it is probably deciding that it doesn't need to look at them
<jdstrand> </guess>
<jdstrand> I've seen that before with something
<ogra_> (this was just hdparm -tT ... i bet there will be a lot other switches needed for the gazillion of options hdparm has)
<ogra_> yeah, would be probably a bit over-powered ... raw-blockdevice-access or some such ..
<jdstrand> ogra_: I suspect it would be a subset of the udisks2 slot policy
<ogra_> ah
<ogra_> only a subset ?
<jdstrand> well, yeah. it doesn't have a dbus service
<jdstrand> probably something like:
<jdstrand> /run/udev/data/b[0-9]*:[0-9]* r,
<ogra_> oh, udisks2 only comes from the snap ... not inside core
<jdstrand> /sys/devices/**/block/** r,
<ogra_> i see
<jdstrand> /dev/sd* r,
<jdstrand> /dev/mmcblk* r,
<jdstrand> /dev/vd* r,
<jdstrand> (and nvme*)
<ogra_> yeah
<jdstrand> probably a couple a capabilities
<ogra_> thx
<jdstrand> then the udev rule to tag all block devices
<ogra_> (i might just keep it devmode for now ... after all that works for the moment ... sounds like a bigger project to add such an interface)
<jdstrand> anyway, happy to review if you send something up. if you need me to do it, it will be a while (though let me know so I can capture this conversation)
<ogra_> yeah
<brunosfer> kyrofa: I'm dealing with the Go environment and setting my workspace correctly. However in my Go files I have functions that execute commands to the console such as `sudo snap install name.snap` the problem is that I need sudo privileges and when I do `sudo snapcraft` the Go env paths disappear.
<willcooke_> mvo, do you know who can approve membership of the canonical-snapcraft email list?  kenvandine has been pending for a couple of weeks now
<zyga-ubuntu> jdstrand: hello
<jdstrand> zyga-ubuntu: fyi, https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/56 (not sure you can see comments to merged PRs-- istr people have that issue)
<jdstrand> zyga-ubuntu: hey
<zyga-ubuntu> jdstrand: I did, I responded to them (though let me recheck)
<zyga-ubuntu> jdstrand: if you want I can just disable the whole user/mode part for now
<mborzecki> mvo: looks like the license field should be avaialble in the client, but we're just not showing it
<jdstrand> zyga-ubuntu: responed via the forum
<zyga-ubuntu> jdstrand: I'll do that quickly
<zyga-ubuntu> jdstrand: btw, for 4329, do you think this is close to landing?
<zyga-ubuntu> mvo will release 2.31 today
<jdstrand> zyga-ubuntu: I'm still going through email which includes the responses to my reviews, but my feeling yesterday was, yes, 4329 is close
<zyga-ubuntu> OK, I'll get to layouts now
<jdstrand> I'm also surprised that 2.31 will be released today. I had a pile of policy updates... :\
<mvo> mborzecki: yeah, it seems we also do not store it locally, i.e. when doing "snap info local-snap" the info seems to get lost
<jdstrand> ETOOMANYHIGHPRIORITYITEMS
<Son_Goku> EPANIC
<jdstrand> losing a week to the sprint didn't help either
<mborzecki> EAGAIN :)
<zyga-ubuntu> mvo: ^^
<zyga-ubuntu> mvo: maybe postpone 2.31 for some time?
<jdstrand> mvo: hey, willcooke_ mentioned that xdg-settings needed to be in 2.31
<brunosfer> Hey guys, can tell me how can I specify in the snapcraft.yaml a package in goland that I created and I need it to go to the GOROOT path into the pkg folder as a *.a lib?
<jdstrand> mvo: I reviewed it yesterday and its close. not through email yet (so don't know if you addressed things), but wanted to touch base since 2.31 is imminent on xdg-seettings going into 2.31
<mvo> jdstrand: *must* is a strong word
<mvo> jdstrand: I have a meeting now but lets chat after that
<mvo> jdstrand: there is always 2.32 but yeah, there is some stuff I would love to have in 2.31
<mvo> jdstrand: the trouble is that statement is always true however long one waits ;)
<jdstrand> mvo: I don't think I said 'must' :)
<jdstrand> mvo: sure, willcooke contacted me and said it was critical
<mvo> jdstrand: for policy updates I can certainly include it in 2.31~rc2 for example
<mvo> jdstrand: today would be ~rc1
<mup> PR snapd#4530 opened: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <https://github.com/snapcore/snapd/pull/4530>
<jdstrand> mvo: I think I can get a PR up today/tomorrow at the latest. if it doesn't make it, well, it doesn't make it
<jdstrand> mvo: I'll look at 4530 today
<jdstrand> err
<jdstrand> zyga-ubuntu: ^
<zyga-ubuntu> jdstrand: thank you
<mup> PR snapcraft#1617 closed: Add options to configure applications socket activation <Created by albertodonato> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1617>
<jdstrand> zyga-ubuntu: I accidentally approved 4329. please see https://github.com/snapcore/snapd/pull/4329#discussion_r163555093 for the last remaining item
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<zyga-ubuntu> jdstrand: ack
<ogra_> niemeyer, mvo, pedronis has there been any progress at https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 (we'd need it for some customer images)
<sergiusens> kyrofa fwiw, `pkg.name not in package_names` is what makes adding libc6 as a stage-packages entry work
<kalikiana> re
<brunosfer> Does anyone can help me out with a doubt? In the snapcraft.yaml in a part I have `stage-packages: [libbluetooth-dev, bluez]` and I get the error `apt.cache.FetchFailedException: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22`
<brunosfer> On Ubuntu Core Raspberry Pi 3 amrhf it works. On Ubuntu core amd64 it doesn't work...
<Chipaca> brunosfer: are you running as root or anything like that?
<mup> PR snapd#4531 opened: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
<Chipaca> niemeyer: did you get a chance to review the updated text about snapshots?
<zyga-ubuntu> mborzecki: reviewed
<brunosfer> Chipaca: Yes, I do have to run sudo.
<Chipaca> brunosfer: why?
<brunosfer> Chipaca: Because installing a downloaded snap requires sudo.
<Chipaca> brunosfer: no it doesn't
<brunosfer> Chipaca: Let me recheck again...
<Chipaca> brunosfer: if you're a developer, you can log in (snap login), and then snapd can see your private snaps
<Chipaca> brunosfer: if you haven't logged in, it should prompt you for your password to confirm the operation, but not require sudo
<Chipaca> brunosfer: sorry, i meant, you can login, in which case it won't ask you for anything, and as a plus it'll see your private snaps
<brunosfer> Chipaca: I think we are talking about different things. Let me explain better.
<brunosfer> Chipaca: The problem occurres in a ubuntu desktop with the snapcraft tool installed.
<mborzecki> zyga-ubuntu: thanks, posted some example output also
<zyga-ubuntu> mborzecki: got that, looks good
<brunosfer> Chipaca: I have a golang file in my code that executes the cmd line `sudo snap install name.snap` and when I run the snapcraft to build the snap it throws me the error I mentioned before.
<mcphail> zyga-ubuntu: saw your forum post about licence files. I'm still very confused about this. Most snaps will have multiple parts and muliple stage-packages, and may have many different licences. Is a single licence field appropriate?
<Chipaca> brunosfer: for what it's worth, the "drop privileges" thing is a warning, not an error
<zyga-ubuntu> mcphail: yes, the license field is a SPDX expression that can have many many licenses in one thing
<Chipaca> brunosfer: but, why do you have a file in your code that does that?
<zyga-ubuntu> mcphail: so you can see that an app uses, say, "MIT and LGPL-2"
<Chipaca> brunosfer: (the W: before the message means 'warning')
<Chipaca> brunosfer: and, the message is from apt, not from snap
<mcphail> zyga-ubuntu: so do we dump multiple licences in the meta/LICENSE file?
<zyga-ubuntu> mcphail: no, unless those are standard
<zyga-ubuntu> mcphail: if you have that MIT and LGPL-2 example you don't need the license text for that
<zyga-ubuntu> mcphail: the license text would only apply if you really have a custom license
<Chipaca> mcphail: spdx license expressions allow multiple licenses
<zyga-ubuntu> mcphail: all licenses known to SPDX are covered by the existing system
<Chipaca> you can do license algebra! license matrixes! license eigenvectors!
 * Chipaca runs away
<Chipaca> mcphail: https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf
<mcphail> ok. cheers chaps. However, all MIT licenses (for example) are bespoke to the individual packages and are supposed to be distributed with the copyright line unmodified. How do we cope with that?
<mcphail> "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software"
<Chipaca> mcphail: you ship the license, just not in meta/
<mcphail> Hmm. OK. So there's inevitable duplication there between adding it to the metadata format and shipping the actual licence?
<Chipaca> mcphail: or you ship it as meta/LICENSE (was that the file in meta/ we settled on? not sure), but also include license: MIT in the .yaml so the license itself is ignored by the business logic
<Pharaoh_Atem> same goes for BSD licenses
<Pharaoh_Atem> especially since BSD licenses get kinda weird
<mcphail> heh
<niemeyer> Chipaca: I had a chance to have lunch! :)
<Chipaca> niemeyer: :-)
<Chipaca> niemeyer: basically my question is whether the 'just one file' applies to all snaps in a snapshot, or if i should make them per-snap
<niemeyer> I'm reading it now
<mup> Issue snapcraft#1688 closed: Documentation for advanced grammar for sources <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1688>
<Chipaca> niemeyer: poke
<niemeyer> Chipaca: Sorry, still working on it (mid other things, appologies)
<niemeyer> apologies even
<Chipaca> yeah i know things a busy for you right :-)
<niemeyer> Chipaca: Sent some initial comments there
<zyga-ubuntu> hmm
<zyga-ubuntu> tests are not happy
<Chipaca> niemeyer: from your comment about the snapshot filename I understand your answer to my question is to have a single snap per snapshot
<zyga-ubuntu> seems tests just terminate machines in random places
<zyga-ubuntu> niemeyer: ^ perhaps related to new spread allocation
<zyga-ubuntu> sample log: https://api.travis-ci.org/v3/job/332828272/log.txt
 * kalikiana wishes that one day Google fixes hangout links in notifications to use the right account
<niemeyer> Chipaca: That seems slightly more expectable and perhaps nicer to work with
<niemeyer> Chipaca: Note we can still draw a line across multiple snapshots by sharing some information
<niemeyer> zyga-ubuntu: Looking
<niemeyer> zyga-ubuntu: Do you have the URL for the build?
<niemeyer> THese files are pretty ugly to look at while raw
<zyga-ubuntu> niemeyer: sure https://github.com/snapcore/snapd/pull/4530
<mup> PR #4530: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <https://github.com/snapcore/snapd/pull/4530>
<zyga-ubuntu> or https://travis-ci.org/snapcore/snapd/builds/332828271?utm_source=github_status&utm_medium=notification
<niemeyer> zyga-ubuntu: Okay, and what sholud I look for other than 50 thousand lines?
<zyga-ubuntu> niemeyer: look at 1st few error, it seems that the logs are just cut in random places
<zyga-ubuntu> niemeyer: as if those machines got axed
<zyga-ubuntu> hmm hold on, is that the right build
<zyga-ubuntu> sorry, rechecking, too many tabs open
<zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/332769268?utm_source=github_status&utm_medium=notification <- here
<zyga-ubuntu> we seem to die when installing packges in the first few errors
<zyga-ubuntu> not sure what to make of that really
<niemeyer> zyga-ubuntu: Yeah, that may be conflicts and two different systems trying to allocate the same machine.. I need to fix that today
<niemeyer> zyga-ubuntu: Just restart for now please
<zyga-ubuntu> thank you
<zyga-ubuntu> niemeyer: is there anything blocking 4471 left?
<niemeyer> zyga-ubuntu: I'll have to look at it to be able to ttell
<mup> PR snapd#4532 opened: store: use the "publisher" when populating the "publisher" field  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4532>
<zyga-ubuntu> ack
<mvo> Chipaca: quick question about developer/publisher - should we expose both via the rest api?
<mvo> Chipaca: context is that I'm looking at this right now for g-s (minimal fix is in 4532) but it looks like there is a bit more to make this nice
<Chipaca> mvo: I fear I'm lacking context
<Chipaca> heh
<mvo> Chipaca: sorry, so right now it seems in our code we are not super clear when publisher and when developer is used
<Chipaca> sergiusens: could you copy mvo on the email about ^ you sent me today?
<Chipaca> sergiusens: looks like he's aching to fix the issue :D
<mvo> Chipaca: and I wonder if should untangle this properly and always have those two everywhere (rest api, snap.Info etc)
<mborzecki> `snap info` output has to be valid yaml
<mborzecki> intersting
<Chipaca> mborzecki: there's a bunch of TODOs on that still though
<Chipaca> mborzecki: but, yes, ideally yes
<mborzecki> hmm the core snap does not have the license set?
<mvo> mborzecki: it might be that its local and therefore the license get lost
<mvo> mborzecki: its labeled in the store as "other open source"
<kyrofa> sergiusens, I meant to ask: what priority would you like me to give the load_plugin work? I've still got a chunk of docs to write
<kyrofa> sergiusens, shall we create an issue for it and put it on the next milestone?
<sergiusens> kyrofa something to do on Friday maybe or when you are on a creative block
<sergiusens> kyrofa an issue sounds like a good plan
<sergiusens> Chipaca ack
<mborzecki> mvo: that's likely it
<kyrofa> sergiusens, good call, those happen. I'll make an issue for it
<mvo> mborzecki: yeah, I think we just need to store it locally, its store metadata
<mborzecki> mvo: looks like a followup PR on #4531
<mup> PR #4531: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
<cachio> mvo, 2.31 is comming today?
<mup> Issue snapcraft#1882 opened: Toast load_plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/1882>
<mvo> cachio: I'm waiting for some PRs to get green
<mvo> mborzecki: +1
<cachio> mvo, ok, tx
<ogra_> if i have an "architectures: [ all ]" snap that is installed on a system and eventually add a binary to that snap (which forces me to change to "architectures: [ foo ]" ... will that snap be upgraded on my syystem ?
<ogra_> or would my user have to remove/install manually ?
 * ogra_ files https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675
 * kalikiana wrapping up for the day
<om26er> popey: are you around ?
<popey> Ya
<om26er> popey: https://github.com/snapcrafters/sublime-text/pull/5
<mup> PR snapcrafters/sublime-text#5: Snapcraft yaml cleanup <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/5>
<om26er> After that I think we should move that to stable. It has been working perfectly fine.
<mup> PR snapd#4533 opened: errtracker: include detected virtualisation <Created by mvo5> <https://github.com/snapcore/snapd/pull/4533>
<kyrofa> nacc, did Laney ever get back to you about autopkgtests? I didn't see anything
<popey> om26er: i dont think that architectures stanza does what you think it does
<popey> om26er: certainly won't stop build from trying to make an i386 snap
<om26er> popey: oh, do you know a way to do that ?
<om26er> I always thought that would limit the architectures my snap will build on
<nacc> kyrofa: nor I
<nacc> kyrofa: i'll ping again
<popey> om26er: sadly not.
<acknack> been pouring over docs and web posts but in hours haven't found an answer to a question:
<acknack> what sets the number of revisions kept for a snap?
<popey> om26er: https://github.com/canonical-websites/build.snapcraft.io/issues/556
<acknack> what or where?
<kyrofa> acknack, I believe it's hard-coded in snapd
<acknack> ouch.
<popey> yeah, i believe so
<kyrofa> acknack, why, are you wanting to change it?
<kyrofa> (and if so, why?)
<acknack> it's apparently > 2
<kyrofa> Yeah, it's three
<acknack> and i can only go back one revision by the cli?
<nacc> kyrofa: looks like it might get re-enabled tmrw
<kyrofa> No, you can revert multiple times, or revert to a specific revision
<kyrofa> nacc, ah, excellent, thank you :)
<nacc> kyrofa: yw
<acknack> okay.  being able to revert more than one didn't make an impression during my research
<acknack> i can specify a revision to remove. would you believe i was thinking the number of revisions would be configurable not hardcoded because of the VMS filesystem?
<kyrofa> acknack, if that's a feature you believe would be helpful, by all means feel free to request it
<acknack> specify a specific* revision to manually* remove
<acknack> i can see a dev wanting a few revisions around. i was hoping to be tidy and set it to 2.
<acknack> the apps are small enough but core is sizable
<acknack> k. thanks. i'll have a look at the code.  is there an existing external config file for snapd?
<acknack> otherwise, i'm thinking a cli param and a tweak to the systemd stuff which fires up snapd
<acknack> "per snap" rev limit would be lovely but overkill, i think, yes?
<Chipaca> in an ideal world you could say "call this bit of business logic to decide"
<Chipaca> but... no :-)
 * Chipaca ~> dinner
<acknack> VMS filesystem (and later implementions in other OSes) has a root dir rev limit which is inherited and ability to set per file rev limit. just fyi.
<acknack> external config file exists for snapd? yes/no?
<acknack> hmm. yes, '42' is the Great Answer.  overlord provides a hook for setting upper rev limit?
<mup> PR snapd#4528 closed: cmd/snap: improve `snap aliases` output when no aliases are defined <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4528>
 * zyga-ubuntu cooked dinner for the first time in weeks
<zyga-ubuntu> ttyl :)
<acknack> okay. i surrender. not able to grasp the thread of snapd execution and locate the decision point where 3 revisions are retained when a refresh installs a new revision.
<niemeyer> How's travis going folks?
<niemeyer> Any issue signs?
<niemeyer> I see some good data:
<niemeyer> https://usercontent.irccloud-cdn.com/file/N6NEPIKG/image.png
<kyrofa> cprov, do you have any docs on what the various ACLs mean?
<cachio> ogra_, there?
<ogra_> semi :)
<ogra_> (but yes)
<cachio> ogra_, I have some problems in a test to read from /dev/gpiomem
<ogra_> is the interface connected ?
<ogra_> iirc thats a brandnew interface
<cachio> yes
<cachio> even it fails if I do dd if=/devgpiomem
<cachio> from the console in the pi2
<cachio> and pi3
<ogra_> becaue you miss a slash ? :)
<ogra_> the device is root owned and 0600 mode ... your script needs to run as root
<cachio> the command I run is "dd if=/dev/gpiomem of=/dev/null bs=1024 count=1"
<kyrofa> Yeah, would be nice to _not_ need root
<ogra_> totally
<ogra_> just saying what i see over here :)
<ogra_> cachio, does your command run as root ?
<cachio> ogra_, this is the output https://paste.ubuntu.com/26453618/
<ogra_> ah, it does
<ogra_> hmm
<kyrofa> ogra_, yeah you're definitely right: https://forum.snapcraft.io/t/raspberry-pi-gpio-as-a-user/3188/2
<ogra_> i see the same here ... looks like the device itself blocks
<ogra_> ogra@stream:~$ sudo cat /dev/gpiomem
<ogra_> cat: /dev/gpiomem: Invalid argument
<kyrofa> How odd
<cachio> I see the same error running from the snap with the interface connected
<ogra_> yeah, its the device for sure
<cachio> ogra_, this is executing from the snap
<cachio> https://paste.ubuntu.com/26453644/
<cachio> If I run the snap using sudo I get the same error "dd: error reading '/dev/gpiomem': Invalid argument"
<ogra_> yeah, nothing to do with the snap or the test
<ogra_> cachio, thats not a stable image, is it ?
<ogra_> (stable doesnt have *any* proper gpio support ... that was only added later)
<cachio> ogra_, no, beta image using core from edge
<ogra_> but not an edge gadget
<ogra_> https://paste.ubuntu.com/26453668/
<ogra_> see that
<ogra_> i suspect you cant just dump gpiomem without having any gpios exported at all
<cachio> ogra_, no, I build the images with ubuntu-image for beta validation
<ogra_> and to export gpios you will need at least a gadget with gpio slots
<ogra_> which are still only in edge
<cachio> ogra_, ok, bad news
<cachio> ogra_, is it any way to force it?
<cachio> at least to test the interface
<ogra_> use an edge gadget
<ogra_> note though that i'm not sure thats the actual issue
<mup> PR snapd#4524 closed: cmd: remove unused execArg0/execEnv  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4524>
<mup> PR snapd#4530 closed: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4530>
<zyga-ubuntu> woooot :)
<mup> PR snapd#4329 closed:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4329>
<cachio> ogra_, ok
<cachio> ogra_, I'll continue with another test while I figure out how to make it work
<acknack> guess nobody wants to say which source file has the "max 3 revisions retained" decision point. np
<acknack> ciao
<cachio> ogra_, thaks for the support
<zyga-ubuntu> jdstrand: only one PR from my pile left, the rest I have (behind 4471) are just tests
<ogra_> cachio, good luck ... i'm also only guessing ...
<jdstrand> zyga-ubuntu: cool, and that is inline with my trello card :)
<zyga-ubuntu> jdstrand: FYI, I have full unit tests and spread tests for 4471
<zyga-ubuntu> jdstrand: I can push those if needed, they are just super long
<zyga-ubuntu> and I wanted to show this non-test change doesn't break tests
<zyga-ubuntu> and that future just-test changes don't touch functionality
<zyga-ubuntu> and that spread tests for both old and new things pass perfectly fine
<zyga-ubuntu> all of that is ready and waiting but it makes this into a ~2K review
<jdstrand> I'll leave that to your discretion
<jdstrand> but glad to hear there are a bunch of tests ready to go
<zyga-ubuntu> I think this way is just easier to land
<zyga-ubuntu> sure, it's fully tested
<zyga-ubuntu> I closed the initial PR because nobody would look at the full lot :)
<jdstrand> heh
<ogra_> cachio, it might actually be that you need to use mmap or some such to actually access gpiomem
<ogra_> and that direct dd'ing wont work at all
 * zyga-ubuntu has terrible headahe and wants to EOD now
<ogra_> (like you can not directly access /dev/mem)
<zyga-ubuntu> (you need to access /dev/mem via /dev/pointer)
 * zyga-ubuntu states that was a terrible joke and EODs
 * ogra_ ...  zyga-ubuntu > /dev/bed
<zyga-ubuntu> tar zyga -f /dev/bed
<cachio> ogra_, ok
<cachio> that makes sense
<zyga-ubuntu> niemeyer: linode broke again
<zyga-ubuntu> https://api.travis-ci.org/v3/job/332769269/log.txt
<zyga-ubuntu> (very short log)
<ogra_> i guess a small c program with a simple "fd = open ("/dev/gpiomem", O_RDWR | O_SYNC | O_CLOEXEC)" might actually work too for the test
<zyga-ubuntu> via https://travis-ci.org/snapcore/snapd/builds/332769268?utm_source=github_status&utm_medium=notification
<mup> Bug #1745214 opened: snapd retains fixed number of snap revisions <Snappy:New> <https://launchpad.net/bugs/1745214>
<sergiusens> kyrofa how do I debug a hook?
<zyga-ubuntu> for the sake of keeping track, it was all full of 2018-01-24 19:38:47 Cannot allocate linode:fedora-27-64: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout
<zyga-ubuntu> I restarted the job now
<kyrofa> sergiusens, make it fail and print
<kyrofa> sergiusens, otherwise snapd swallows its stdout/stderr
<sergiusens> kyrofa just printing enough is good? What if it is a segfault?
<kyrofa> sergiusens, note that you can also do `snap run --hook`
<sergiusens> kyrofa `snap run --hook` only works it is installed :-)
<kyrofa> Ouch, that's a bit more difficult :P
<kyrofa> sergiusens, oh, is it an install hook?
<sergiusens> kyrofa yeah
<sergiusens> kyrofa wait, it is a `configure` hook, but it is triggered on install
<kyrofa> Yeah, same effect I suppose
<kyrofa> sergiusens, try making it a command instead
<kyrofa> Would that work?
<sergiusens> kyrofa yeah, I was thinking about that, it probably should, let me double check
<kyrofa> It would be cool if snapd grew some sort of `snap install --debug` mode that just printed everything from the hooks
<kyrofa> `snap set --debug` as well
<ogra_> cachio, there is the devmem2 untility that allows reading of registers from /dev/mem ... if you hack that up to instead open /dev/gpiomem that might work ... https://free-electrons.com/pub/mirror/
<ogra_> here is also some general background https://elinux.org/EBC_Exercise_11b_gpio_via_mmap
<ogra_> (not pi specific though)
<cachio> ogra_, awesome, thanks
<sergiusens> kyrofa found the culprit, you will smirk
<kyrofa> sergiusens, haha, what?
<sergiusens> kyrofa that said, snapcraft#1881 should be ready
<mup> PR snapcraft#1881: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>
<mup> PR snapd#4534 opened: release: 2.31~rc1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4534>
<ogra_> cachio, and sisne i couldnt resist ... https://paste.ubuntu.com/26453965/
<ogra_> *since
<cachio> ogra_, heheh
<ogra_> (classic)ogra@stream:~$ ./gpiotest.sh
<ogra_> Memory mapped at address 0x76f79000.
<ogra_> Value at address 0x3F200000 (0x76f79000): 0x21200924
<ogra_> but i cheated using classic ;)
<ogra_> that should be enough to prove that the interface lets you access the device
<cachio> ogra_, hehe, let me try it on pi3
<ogra_> i simply gepped the addess gpiomem uses from the boot log as you can see ....
<ogra_> and tell devmem2 to simply print the content
<mup> PR snapcraft#1883 opened: Revert "meta: create XDG_RUNTIME_DIR in wrappers. (#1818)" <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1883>
<sergiusens> kyrofa ^ we shouldn't be doing generic workarounds ;-)
<kyrofa> sergiusens, hahaha
 * kyrofa smirks
<sergiusens> kyrofa it is a bit more complex than that, we really need to get rid of `LD_LIBRARY_PATH` and friends
<kyrofa> sergiusens, yeah, we're well on our way there I think with the readelf stuff
<sergiusens> we end up using mkdir from `core` with libc6 from a future release
<kyrofa>  /patchelf
<kyrofa> Oh brutal
<sergiusens> kyrofa yeah, we just need to be brave enough to enable it for everything ;-)
<jamesb192> pythonpath
<kyrofa> Yeah I'll admit that's a terrifying proposition
<kyrofa> We should do a feature branch and do a call for testing on it alone
<kyrofa> But if it worked... dude
<sergiusens> it will work
<ogra_> you could instead work on something easy and fix https://forum.snapcraft.io/t/avoiding-installation-of-build-dependencies/3665/3
<ogra_> :P
<sergiusens> I just need tyhicks to find the time to look closely at patchelf and verify it will not be a problem long term
<kyrofa> ogra_, no comment
 * ogra_ grins
<sergiusens> ogra_ that is actually easy to fix; it is hard to test though
<ogra_> sergiusens, well, the inability of dpkg and apt to re-locate install paths was the reason for clicks to exist initially :)
<ogra_> IIRC
<ogra_> (and thus snaps in the end)
<sergiusens> kyrofa elopio are we good with snapcraft#1879
<mup> PR snapcraft#1879: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>
 * ogra_ just waits to see fakechroot integrated into snapcraft :)
<kyrofa> sergiusens, I was hoping elopio would respond to my questions
<sergiusens> ogra_ if `which go` returns something, we use that, if not we check if a build-snaps entry for go exists and if not we default to installing the build-packages entry of go
<sergiusens> elopio answer the questions please :-) Also, the doc ;-)
<ogra_> sergiusens, well, if i dont have go in "build-packages" but like ... 300 libs ?
<ogra_> how do you avoid installing them on the host ... and still are aboe to build your target
<ogra_> *able
<sergiusens> ogra_ once you want reproduceability you should worry on how you get `go`; it could also be staged through a part (which we already support but  install anyways)
<ogra_> well, the request is to avoid installing build deps on the host machine
 * sergiusens goes back to manager work and fills in some forms for the rest of the day and tomorrow
<zyga-ubuntu> niemeyer: 4471 is green, just saying :)
<mvo> cachio: 2.31~rc1 should be available in ~1h or so in edge, not sure if I will still be up then to promote it to beta, if not, freel free to do so yourself!
<cachio> mvo, sure, thanks
<niemeyer> zyga-ubuntu: I need to break something then!
<niemeyer> ;P
<om26er> flexiondotorg: Hi! Please merge https://github.com/snapcrafters/sublime-text/pull/6 as well.
<mup> PR snapcrafters/sublime-text#6: Change app name to subl <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/6>
<mvo> cachio: great, thank you! keen to see/hear how the tests go, especially on the boards :)
<zyga-ubuntu> niemeyer: :D
<mvo> cachio: but no worries, if its late for you already this can wait until tomorrow
<cachio> mvo, I'll start today
<mvo> cachio: \o/
<cachio> mvo, let's see how it goes
<mvo> thanks cachio, I will check mail tomorrow morning then with anticipation :)
 * mvo waves and calls it a day
<om26er> popey: regarding the 'architectures' stanza, it seems once I removed i386 from sublime' yaml, its only amd64 in dashboard.snapcraft.io -- so it is indeed working.
<zyga-ubuntu> om26er, flexiondotorg: commented on sublime-text PR
<om26er> zyga-ubuntu: I like that suggestion, will make changes to the packaging tomorrow. Can you share a sample app that uses tracks ?
<om26er> well maybe I'll look at LXD' packaging.
<zyga-ubuntu> om26er: lxd is one, noise][1 can suggest some as well, probably better than I can
<kyrofa> om26er, nextcloud as well
<zyga-ubuntu> om26er: note that you need to request tracks to be made server side
<zyga-ubuntu> om26er: and I don't remember how this works but I think the 3 track should be default
<kyrofa> The default is always `latest`, which is not a pointer, but a track unto itself
<zyga-ubuntu> aha
<kyrofa> Thus if you want the 3 track and latest track to look the same, you must release to both
<zyga-ubuntu> kyrofa: how would you map sublime-text-2 (legacy) and sublime-text-3 into tracks?
<zyga-ubuntu> I see
<zyga-ubuntu> hmm
<zyga-ubuntu> maybe a 2 track is better
<zyga-ubuntu> and a latest track for 3
<kyrofa> I'd create 2 and use latest for 3
<zyga-ubuntu> the versions will convey the rest
<zyga-ubuntu> om26er: ^ I agree
<om26er> yeah that sounds a fine suggestion.
<kyrofa> Then once there's a four you can create a 3 for people who don't want to upgrade
<zyga-ubuntu> om26er: and I'd _love_ to use that
<zyga-ubuntu> as a paying sublime user :)
<kyrofa> However, if people stay on latest, they _will_ upgrade to four if they don't see that you released a 3 track. So you can maintain a standalone 3 track that mirrors the latest track if you want people to install from 3/stable knowing that they'll never update to 4
<zyga-ubuntu> kyrofa: I think 4 is faaar away
<kyrofa> (too much work in my opinion)
<kyrofa> Yeah, it's more about supporting a specific user intent: "I never want 4, just 3" and "Yeah give me the latest thing, oh it's 3, nice"
<zyga-ubuntu> kyrofa: btw, do you use sublime text?
<kyrofa> Man, I barely started using atom from gedit. I'm so far behind on the editor curve
<zyga-ubuntu> kyrofa: try it
<om26er> so will we need to get the snap renamed or register sublime-text as new ?
<zyga-ubuntu> it's awesome IMO
<zyga-ubuntu> it's like atom lost 90% of its weigth
<zyga-ubuntu> om26er: ... no idea
<zyga-ubuntu> om26er: probably new snap is better now
<zyga-ubuntu> and have store side kill the current one
<kyrofa> Haha, I'm that far down the curve for a reason: I don't like change very much. I get a setup that pleases me and I use it until it no longer does or something convinces me there's a feature that I must have elsewhere
<zyga-ubuntu> kyrofa: sublime + agola color theme (I love green variant)
<zyga-ubuntu> kyrofa: don't look then
<zyga-ubuntu> kyrofa: if you will look you won't stay on atom
<zyga-ubuntu> ;-)
<kyrofa> ;)
<zyga-ubuntu> kyrofa: sl is an order of magnitude faster and less memory hungry than atom
<kyrofa> Will it crash X every other time like atom and chrome do?
<kyrofa> (does it use electron is I guess what I'm asking)
<zyga-ubuntu> no?
<zyga-ubuntu> it never crashed on me
<zyga-ubuntu> no
<zyga-ubuntu> it's not an electron app
<zyga-ubuntu> it's really native and fantastically speedy
<zyga-ubuntu> it also auto saves its buffers if you kill your session like I sometimes do so you don't loose any work
<om26er> its a GTK app
<zyga-ubuntu> yes, gtk though just for the "gimme window" really
<zyga-ubuntu> kyrofa: it uses python for plugins
<zyga-ubuntu> kyrofa: it has nice simple syntax extension system
<zyga-ubuntu> kyrofa: it has it's own place for plugins/extensions (package control)
<kyrofa> Hmm, it sounds quite nice indeed
<zyga-ubuntu> kyrofa: it can take any python plugins you write
<zyga-ubuntu> kyrofa: I switched from vim
<zyga-ubuntu> and that says something
<zyga-ubuntu> it's really fricking awesome IMO
<zyga-ubuntu> kyrofa: and it has docs which I found surprising for most software doesn't have any
<mup> PR snapd#4535 opened: interfaces: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4535>
<zyga-ubuntu> jdstrand: I'll get it in for ~rc2
<cachio> ogra_, it works https://paste.ubuntu.com/26454638/
<cachio> it is on pi3
<cachio> without classic
<jdstrand> zyga-ubuntu: thanks! that one is against master. I'm preparing a PR for 2.31 now
<diddledan> new one: https://paste.ubuntu.com/26454647/
<diddledan> specifically: Failed to run: /snap/lxd/current/bin/lxd forkmount 30519 /dev/.lxd-mounts/lxdmount_729321534 /root/build_gnome-terminal: Failed mounting /dev/.lxd-mounts/lxdmount_729321534 onto /root/build_gnome-terminal: Invalid argument
<diddledan> looks like the lxd snap was refreshed 2 hours ago. possibly it didn't happen cleanly?
<diddledan> refreshed by my system:
<diddledan> https://www.irccloud.com/pastebin/JdJDT9OU/
<zyga-ubuntu> jdstrand: +1
<zyga-ubuntu> niemeyer: we have issues with https://github.com/snapcore/snapd/pull/4534 - I restarted it a few times already
<mup> PR #4534: release: 2.31~rc1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4534>
<niemeyer> zyga-ubuntu: What's happening there?
<zyga-ubuntu> niemeyer: this time it aborted all 1620 tasks
<zyga-ubuntu> niemeyer: everything:
<zyga-ubuntu> 2018-01-24 22:27:11 Cannot allocate linode:debian-9-64: cannot find public IP for linode:debian-9-64 (Spread-5448035)
<zyga-ubuntu> 2018-01-24 22:31:06 Cannot allocate linode:debian-9-64: cannot allocate disk linode:debian-9-64 (Spread-5448015): cannot get job details for linode:debian-9-64 (Spread-5448015): empty result
<niemeyer> zyga-ubuntu: I'm fixing that one as we speak
<niemeyer> zyga-ubuntu: It's still a consequence of the early issue today
<zyga-ubuntu> excellent, thank you!
<zyga-ubuntu> ack
<niemeyer> zyga-ubuntu: Should be ready in a few minutes
<diddledan> ok, snap.lxd.daemon.service is failed. already running but failed. restarting thru systemd caused lxd to complain it was already running - systemd thought it wasn't. needed to manually kill lxd processes and then restart the systemd service again
<diddledan> working find now
<diddledan> fine*
<mup> PR snapd#4536 opened: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4536>
<jdstrand> zyga-ubuntu: fyi, https://github.com/snapcore/snapd/pull/4536
<mup> PR #4536: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4536>
<jdstrand> oh heh
<jdstrand> zyga-ubuntu: I milestoned that one for 2.31.
<zyga-ubuntu> ack
<zyga-ubuntu> jdstrand: do you have anything else for https://github.com/snapcore/snapd/pull/4471 ?
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<jdstrand> zyga-ubuntu: no
<zyga-ubuntu> ready to approve?
<jdstrand> well, it had 3 approvals already. I didn't study all the code bits. if you want me to comment/approve on what I did look at, I can
<niemeyer> zyga-ubuntu: Alright, please give it another shot
<niemeyer> zyga-ubuntu: The issue was that when these errors happened in the morning, Linode allocated something completely bogus
<zyga-ubuntu> jdstrand: I'd love that
<zyga-ubuntu> niemeyer: trying
<niemeyer> zyga-ubuntu: We had about 90 machines that had no IP even
<zyga-ubuntu> uuhh
<zyga-ubuntu> cloud is hard
<zyga-ubuntu> is linode an openstack or a custom thing?
<niemeyer> Software is hard, I suppose :)
<niemeyer> Custom thing.. predates OpenStack by.. 20 years? :)
<zyga-ubuntu> I spawned one run
<zyga-ubuntu> ooh, that explains a lot
<zyga-ubuntu> well, I applaud them for running so long :)
<niemeyer> Yeah
<zyga-ubuntu> though it feels like other clouds are more mature API wise
<niemeyer> zyga-ubuntu: I see healthy machines spawning
<zyga-ubuntu> niemeyer: some runs of older spread are still in flight
<zyga-ubuntu> niemeyer: so they can affect the new runs
<niemeyer> zyga-ubuntu: Yeah, this running bill thing is relatively new for them.. the usual business back then was a fixed low monthly price
<zyga-ubuntu> but this will stop in ~~30 minutes or so
<niemeyer> 23ish, I hope
<zyga-ubuntu> yeah, I imagine, lots of "just replace my physical server" customers
<zyga-ubuntu> niemeyer: is there any chance you can approve 4471 now? it's my last PR and the blocker for more goodies
 * zyga-ubuntu always feels weird when he notices irssi "Day changed" notifications
<niemeyer> No, sorry.. my family is having dinner and I'm still here getting tests running smoothly
<niemeyer> I need to step out ASAP
<zyga-ubuntu> k
<niemeyer> If things go well I'll be back in business tomorrow
<zyga-ubuntu> enjoy your evening, see you tomorrow!
<niemeyer> zyga-ubuntu: Thanks, have a good night you too
<niemeyer> zyga-ubuntu: It looks like they all allocated just fine now.. fingers crossed
<zyga-ubuntu> yeah, looks good
<zyga-ubuntu> I'm looking at "follow" log
<zyga-ubuntu> 2018-01-24 23:02:31 Cannot allocate linode:debian-9-64: server linode:debian-9-64 (Spread-5460254) concurrently allocated, giving up on it
<zyga-ubuntu> I'll wait till all the other runs shut down and retry if this fails
<mup> PR snapd#4326 closed: interfaces/builtin: blacklist zigbee dongle <Decaying> <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4326>
<mup> PR snapd#4536 closed: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4536>
<zyga-ubuntu> jdstrand: I'm about to EOD but my last request would to enqueue 3963 as I'm inclined to merge and interate upon that whenever you give the green light
<zyga-ubuntu> jdstrand: as layouts move to policy topics and I have enough branches to keep reviews busy I was thinking I would look at per-user mounts
<cprov> kyrofa: https://dashboard.staging.snapcraft.io/docs/api/macaroon.html#post--dev-api-acl- but it doesn't go in detail each acl. Can you please file a bug in lp:snapstore requesting it ? we will extend the docs.
#snappy 2018-01-25
<jdstrand> zyga-ubuntu: thanks. it is high on the list but after two things
<jdstrand> zyga-ubuntu: ie, consider it enqueued. have a nice evening :)
<zyga-ubuntu> jdstrand: thank you, likewise :)
<mup> PR snapd#4063 closed: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4063>
<zyga-ubuntu> om26er: the snap version of sublime text has low-res icon
<zyga-ubuntu> om26er: the deb has much better one, is that a store side issue or just a mistake somewhere?
<om26er> zyga-ubuntu: yeah 64x64 variant
<om26er> the source has others as well, so we can use them
<om26er> 128x128 be fine ?
<zyga-ubuntu> why did we pick the 64x64 icon?
<om26er> zyga-ubuntu: ^
<zyga-ubuntu> on low-dpi screen 64x64 looks bad when alt-tabbing
<zyga-ubuntu> I'd provide all the highest-res one
<om26er> is that even possible ?
<zyga-ubuntu> (and this is an interesting TODO for theming to allow many icon sizes to ship with each app)
<zyga-ubuntu> s/all//
<zyga-ubuntu> just the one high-res one
<om26er> yeah so 128x128 sounds good to you ?
<zyga-ubuntu> om26er: whichever is highest resolution in the original package
<zyga-ubuntu> om26er: if that's 128x128 that's fine, if there's a 256x256 use that one
<om26er> I think they have 256x256 as well
<zyga-ubuntu> om26er: and it'd be cool to have track this in desktop theme discussions
<zyga-ubuntu> om26er: as it looks like an oversight on our end, something we should do better
<om26er> In an ideal world our system will chose icon automatically based on DPI
<zyga-ubuntu> om26er: (provide many icons)
<zyga-ubuntu> om26er: right but we cannot even *ship* more than one icon size yet
<om26er> yeah
<mup> PR snapd#4534 closed: release: 2.31~rc1 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4534>
<zyga-ubuntu> Son_Goku: note, 2.31 rc1 is not ready for packaging,
<zyga-ubuntu> Son_Goku: we'll have rc2 for sure, maybe more
<Son_Goku> didn't think it was
<Son_Goku> I'm only planning on doing 2.30 for now anyway
<Son_Goku> zyga-ubuntu: you might find this interesting: https://fedoraproject.org/wiki/Workstation/Flatpaks
<zyga-ubuntu> Son_Goku: ack, I'll read that tomorrow
<zyga-ubuntu> man, it's 2AM already
<zyga-ubuntu> zyga.susped()
<mup> PR snapd#4537 opened: interfaces/builtin: Replace Solus support with GLVND support <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4537>
<ikey> ok so yeah the interfaces still make zero sense
<ikey> like i cant see anywhere that allows me to do "only connect to this particular snap and do so automatically" ..
<ikey> *oh* that happens in the store
<ikey> well then.
<mup> PR snapd#4538 opened: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538>
<mborzecki> morning
<zyga-ubuntu> mborzecki: o/
<zyga-ubuntu> mborzecki: master isn't happy now
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> mborzecki:     - linode:ubuntu-core-16-64:tests/main/kernel-snap-refresh-on-core
<zyga-ubuntu> I think we have to disable it to fix builds & investigate
<mborzecki> zyga-ubuntu: hm this one was also randomly failing
<zyga-ubuntu> I'm kind of sleepy
<zyga-ubuntu> I couldn't sleep and I was here at ~3 AM
<mborzecki> zyga-ubuntu: do you have a link to the travis job where the test failed?
<zyga-ubuntu> mborzecki: https://github.com/snapcore/snapd/pulls the top three
<mborzecki> zyga-ubuntu: something fishy about linode, 2 runs attempted, both ended with io timeout when connecting to the machine
<zyga-ubuntu> mborzecki: you need to update spread
<zyga-ubuntu> mborzecki: brand new spread is out now
<zyga-ubuntu> hey mvo
<mvo> hey zyga-ubuntu
<mvo> zyga-ubuntu: how are you?
<zyga-ubuntu> haha, good question
<zyga-ubuntu> I went to bed at 3AM
<zyga-ubuntu> and woke up at 6
<zyga-ubuntu> 7
<mvo> zyga-ubuntu: woah
<zyga-ubuntu> (not six, didn't hit the key right)
 * mvo hugs zyga-ubuntu 
<zyga-ubuntu> I think my back is worse than my head
<zyga-ubuntu> mvo: I merged some things last night, reviewed most of the rest
<zyga-ubuntu> mvo: things are either green or need fixing now
<zyga-ubuntu> but I believe I broke master by merging one spread test
<zyga-ubuntu> last three runs show it as broken
<zyga-ubuntu> linode:ubuntu-core-16-64:tests/main/kernel-snap-refresh-on-core
<mborzecki> mvo: morning
<mborzecki> zyga-ubuntu: well the test is awkward
<mvo> zyga-ubuntu: aha, yeah, this one should be set to manual I think, let me double check
<mvo> hey mborzecki good morning
<mborzecki> take a look at this: https://paste.ubuntu.com/26456741/ stable and edge channels carry the same version atm
<mborzecki> i guess that's why snap_try_kernel ends up being unset
 * Son_Goku rises from the dead
<zyga-ubuntu> Son_Goku: OMG go to sleep
<zyga-ubuntu> don't do what I did
<Son_Goku> I tried... so hard
<zyga-ubuntu> I coudn't sleep, so cold last night
<zyga-ubuntu> mvo, mborzecki: one amazing thing last night was that I could restart any job and it would just go
<mborzecki> zyga-ubuntu: you can do the same over the weeked and still get some sleep :)
<zyga-ubuntu> mborzecki: I didn't plan on doing this
<mborzecki> zyga-ubuntu: mvo: tests/main/kernel-snap-refresh-on-core to manual then?
<zyga-ubuntu> yes
<zyga-ubuntu> or make it smarter and have it skip
<zyga-ubuntu> if same thing on both channels
<mvo> mborzecki, zyga-ubuntu or both, manual and smarter, we want this to run nightly via spread-cron
<mborzecki> https://paste.ubuntu.com/26456780/ any idea why pc-kernel versions don't have the 'up arrow' in snap info?
<mvo> mborzecki: I think you only get it if the channel is closed, here its all the same rev but put in the channel explicitely
<mvo> mborzecki: are you looking into this? if not I can push something in 4 minute or so
<mborzecki> mvo: yes, i'm testing a fix right now
<mvo> mborzecki: cool, thank you
<zyga-ubuntu> https://pastebin.ubuntu.com/26456824/ :/
<mvo> zyga-ubuntu: uhhh
<zyga-ubuntu> that's ok, I'm going to get rid of all this eventually
<zyga-ubuntu> mvo: why do we lose license data?
<zyga-ubuntu> mvo: what's the reference data, is it snap.yaml or the store?
<zyga-ubuntu> I think there was some discussion about that last night
 * zyga-ubuntu pulls the link
<zyga-ubuntu> https://forum.snapcraft.io/t/snap-license-metadata/856/17?u=zyga
<zyga-ubuntu> mvo: my question is this, can we just load the license from yaml today
<zyga-ubuntu> (for local snaps)
<zyga-ubuntu> and treat that as authorative?
<mborzecki> zyga-ubuntu: i think the problem is that there is no license information in meta/snap.yaml
<mup> PR snapd#4533 closed: errtracker: include detected virtualisation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4533>
<mvo> zyga-ubuntu: it is store data that we do not store locally
<mvo> zyga-ubuntu: I think we can
<mvo> zyga-ubuntu: if we have it there
<mvo> zyga-ubuntu: but most of this is store data
<zyga-ubuntu> mvo: hmm
<zyga-ubuntu> mvo: but snaps can also store it in meta/snap.yaml, right?
<zyga-ubuntu> I think I saw that in the spec
<mborzecki> the snap info does a store roundtrip anyway, it may be just a matter of merging the information
<mvo> zyga-ubuntu: I need to get back to the london sprint discussion, I don't remember the details right now
<zyga-ubuntu> mvo: yeah, I'm looking at that now
<zyga-ubuntu> yes, there's a license: <SPDX> field now
<zyga-ubuntu> mvo: so...
<mvo> Chipaca: what was this email you talked about yesterday?
<mvo> zyga-ubuntu: cool
<zyga-ubuntu> I think the is a bug in general that store and meta-data can get out of sync
<zyga-ubuntu> but this can be a good start, just show the license field, either sourced locally or remotely
<mup> PR snapd#4539 opened: tests/main/kernel-snap-refresh-on-core: do not fail if edge and stable kernels are the same version <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4539>
<mborzecki> i'm a bit confused with what happens in `snap info`, we do a store round trip, get the data, get the local data, then prefer the local data for all fields but the ones that cover channels
<zyga-ubuntu> mborzecki: I think Chipaca knows why, I'd love to know too
<mborzecki> an easy way out would be to display the license information from the store data, provided we're able to query the store for info on the snap revision we have installed now (?)
<mborzecki> an alternative is to store the license information when installing the snap (that's what i'm lookin into now)
<zyga-ubuntu> mborzecki: I think there's something odd about having to query the store for license of something we installed already
<zyga-ubuntu> mborzecki: it's wrong on many levels
<zyga-ubuntu> mborzecki: yeah, I think we must not permit the license to vary without the revision varying as well
<mvo> mborzecki: I think that is what we want - store the information locally
<zyga-ubuntu> mborzecki: it's probably illegal
<mborzecki> btw. snap.Info has some intersting fields like LicenseAgreement, LicenseVersion ;)
<zyga-ubuntu> mvo, mborzecki: but there's still the interesting case of snap meta-data that disagrees with the store
<zyga-ubuntu> mborzecki: legacy from EULA support days
<zyga-ubuntu> when one snap installs a snap locally
<zyga-ubuntu> and acks the assertion
<mborzecki> yeah, these are not there inside store.snapDetails ;)
<zyga-ubuntu> I think it's a bit of a mess, perhaps we could refuse to install snaps that disagree on license from assertion and from the meta-data?
<kalikiana> good morning
<zyga-ubuntu> hey kalikiana
<zyga-ubuntu> kalikiana: how are your REs?
<mborzecki> mvo: SideInfo is stored in state.json right?
<mvo> mborzecki: correct
<zyga-ubuntu> mborzecki: yes
<kalikiana> zyga-ubuntu: going back to being simpler. getting the processor to connect the "compound" statements now. which should be more maintainable long-term
<pstolowski> hey o/
<zyga-ubuntu> hey paweÅ
<mborzecki> pstolowski: hey
<mup> PR core#70 closed: hooks: use symlink to run `snap advise-command` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/70>
<mup> PR core#71 closed: live-build: make /lib64/ld-linux-x86-64.so.2 a relative link <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/71>
<mup> PR core#73 closed: Support for armhf binaries on arm64 (aarch64) operating system <Created by abbotware> <Merged by mvo5> <https://github.com/snapcore/core/pull/73>
<zyga-ubuntu> mborzecki: can you look at 4539, either way the answer will unblock master
<mvo> koza: hey, is https://github.com/snapcore/core/pull/76 ready to merge? iirc you were thinking about improvements to the text plus the idea to keep 00-header in place might be nice
<mup> PR core#76: hooks: update the set-motd hook to provide better motd <Created by bergotorino> <https://github.com/snapcore/core/pull/76>
<mvo> koza: I would love to have this in 2.31
<Son_Goku> mvo, mborzecki: snapd 2.30 is being pushed now: https://src.fedoraproject.org/rpms/snapd/c/47a18f3d2bbce275366342f621ce362d189cc1bc
<mvo> Son_Goku: \o/
<Son_Goku> hopefully it builds for all arches
<mborzecki> Son_Goku: that's great, thank you
<mup> PR snapd#4511 closed: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4511>
<Son_Goku> this has been the easiest rebase in a while
<Son_Goku> no unexpected dependency breaks, patches were easy to refresh...
<zyga-ubuntu> Son_Goku: nice, thank you for doing that :)
<mvo> Son_Goku: great to hear. we tried to keep the spec file up-to-date for 2.31 as well to make your life easier. lets see if that worked :)
<Son_Goku> mvo: here's to hoping
<mvo> zyga-ubuntu: is your "cool" comment in 4473 a +1 :) ?
<Son_Goku> if the build passes in rawhide for all arches, I'll merge it back into Fedora 26 and 27, and then make a PR to sync snapd master to Dist-Git again
<mvo> cool
<zyga-ubuntu> Yes :)
<zyga-ubuntu> LGTM
<zyga-ubuntu> I didn't hit approve,
<zyga-ubuntu> but I meant to
<Son_Goku> and yay rich dependencies :D
<mvo> zyga-ubuntu: \o/
<mvo> zyga-ubuntu: thank you
<mvo> I will look into the other strace one
<mup> PR snapd#4473 closed: snap: add `snap run --strace` to be able to strace snap apps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4473>
<zyga-ubuntu> thank *you* mvo :)
<Son_Goku> zyga-ubuntu: looks like people are starting to build their own HLLs using SELinux CIL: https://github.com/garyttierney/rust-csp
<zyga-ubuntu> yeah, I think I saw a similar one a few months back
 * zyga-ubuntu -> breakfast
<Son_Goku> mvo: https://koji.fedoraproject.org/koji/buildinfo?buildID=1020618 :D
<zyga-ubuntu> that was fast
<mvo> Son_Goku: yay
<mup> PR snapd#4539 closed: tests/main/kernel-snap-refresh-on-core: do not fail if edge and stable kernels are the same version <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4539>
<mborzecki> zyga-ubuntu: i'll do followup on 4539 (testing it right now but the spread nodes keep being stolen from under a running job)
<zyga-ubuntu> mborzecki: did you update your spread?
<zyga-ubuntu> mborzecki: each *up to date* spread system allocates fresh nodes
<mborzecki> it's actually quite funny, it goes to prepare, then `2018-01-25 09:52:30 Error running debug shell: EOF`, and `cannot deallocate Linode machine linode:ubuntu-core-16-64 (Spread-5470034): object not found`
<zyga-ubuntu> mborzecki: the behaviour you are describing was the bug that gustavo fixed last night
<mborzecki> zyga-ubuntu: yes i did
<zyga-ubuntu> oh :D
<mborzecki> need to make sure ti'm using the latest binary though :/
<mvo> zyga-ubuntu: fwiw, spread-cron and the update for snapd-vendor has the saem issue
<Chipaca> mborzecki: ohi
<Chipaca> mborzecki: there's a bunch of info (some of which is in the snap.yaml today) that we've decided a couple of sprints back that we should query the store for it, and cache it locally
<Chipaca> mborzecki: title, description, icon, screenshots are on that list; presumably license as well
<Chipaca> hmmm
<zyga-ubuntu> Chipaca: IMO the license shouldn't
<Chipaca> no, license needs to be local to the snap - the license of the thing you have installed can't change i guess?
<Chipaca> except that typos happen
<mborzecki> hmm
<zyga-ubuntu> Chipaca: license is validated
<zyga-ubuntu> no typos would go through
<Chipaca> BSD-2 vs BSD-3 could be a typo, but I guess it's fine
<zyga-ubuntu> yes
<Chipaca> so could MPL vs GPL vs ZPL vs YPL vs WTFYWPL
<Chipaca> wait maybe not the last one
<Chipaca> mborzecki: all that metadata should be served locally, and get updated when the store provides it for other reasons
<Chipaca> mborzecki: this is driven by a real need from GUI stores to have a single, fast, local roundtrip for installed snaps including visual elements
<Chipaca> mborzecki: whisper some of those words close to ikey if you want to know more (than you wanted to)
<Son_Goku> zyga-ubuntu, mvo: what are we doing CI with now?
<Son_Goku> for Fedora releases
<zyga-ubuntu> Son_Goku: we're running spread for all builds
<zyga-ubuntu> Son_Goku: but we don't enable all tests I think, a good subset though
<zyga-ubuntu> I didn't look at details in a while
<Chipaca> Son_Goku: Fedora-27
<Chipaca> Son_Goku: https://github.com/snapcore/snapd/blob/master/spread.yaml#L82
<mborzecki> Chipaca: i may be missing somthing then, when you do a cli.Info() it ends up in SnapState.CurrentInfo that in turn pulls in the side info from state and the rest comes from snap yaml
<Son_Goku> Chipaca: isn't ubuntu 17.04 EOL?
<zyga-ubuntu> Son_Goku: yes, it is
<zyga-ubuntu> good catch!
<Chipaca> Son_Goku: how would i know :-p
<Chipaca> mborzecki: yes, that sounds accurate
<Son_Goku> zyga-ubuntu: so you can drop ubuntu 17.04 and add fedora-26 :)
<mborzecki> Chipaca: oh ok, i thought that when you wrote `all that metadata should be served locally` you meant that it's like this now
<zyga-ubuntu> on my way
<mup> PR core#75 closed: ensure that all live-build/hooks run with `set -e` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/75>
<zyga-ubuntu> 4540
<zyga-ubuntu> Son_Goku: I'll add fedora next
<zyga-ubuntu> though I'd rather add arch
<zyga-ubuntu> as arch is not tested yet
<mup> PR snapd#4540 opened: spread: Ubuntu 17.04 is EOL, remove it <Created by zyga> <https://github.com/snapcore/snapd/pull/4540>
<mup> PR core#76 closed: hooks: update the set-motd hook to provide better motd <Created by bergotorino> <Merged by mvo5> <https://github.com/snapcore/core/pull/76>
<Chipaca> mborzecki: i meant currently a GUI needs to hit /v2/snaps, and then hit /v2/find to query the store for the same snap to get it (notable screenshots)
<mborzecki> Chipaca: right, that's much like snap info does it now too
<Chipaca> mborzecki: and even the data we do serve can be staler than we want, because of where we get it from (mostly because we've dithered between "snap.yaml is the source of truth" and "store is the source of truth" a bit)
<Chipaca> mborzecki: i'm not sure i'm answering the questions you had though
<Son_Goku> zyga-ubuntu, mborzecki: https://bodhi.fedoraproject.org/updates/FEDORA-2018-798e0f02ff & https://bodhi.fedoraproject.org/updates/FEDORA-2018-04bdce8944
<mborzecki> Chipaca: not exactly but you've confirmed what i see in the code :P at least i know i haven't missed anything
<Chipaca> mborzecki: what were your questions tho
<zyga-ubuntu> Son_Goku: ack, let me boot fedora
<zyga-ubuntu> Son_Goku: testing
<zyga-ubuntu> I should script spread external run against a fedora system
<mborzecki> Chipaca: i'm looking into storing license information locally, since it primarly comes from the store the current idea is to keep it in SideInfo in a separate field, eg. StoreLicense so that it wouldn't clash with snap.Info.License, then while doing `snap info` show one or the other (there may be license in meta/snap.yaml but i haven't seen a snap with it yet), does that sound right to you?
<Chipaca> mborzecki: why will it "primarily come from the store"?
<Chipaca> mborzecki: it's in the snap.yaml
<Chipaca> I'm assuming you mean the license field, not the license text
<mborzecki> Chipaca: license field
<Chipaca> mborzecki: as I mentioned above, license is one where the store does _not_ win, AFAIK; the license of the thing you have installed is that license
<Chipaca> mborzecki: publishers can't change the license of things they have distributed post-hoc
<Chipaca> they can distribute a new thing with a new license
<Chipaca> otherwise we need a way to let users accept the license change, which is a nightmare
<Chipaca> mborzecki: if the store is doing that it needs to stop doing that :-) says me
<koza> mvo, on the pr now
<koza> mvo, will ping u
<mborzecki> Chipaca: what i mean is that in the snaps i have installed right now, the license field in meta/snap.yaml is not set
<mvo> koza: thanks! just do a followup, this is already a nice improvement
<Chipaca> mborzecki: yes, that is true. That will stop being true soon, as I understand things.
<mborzecki> Chipaca: right, so for now i can record the license in side info when installing the snap, then should meta/snap.yaml come with a license field set it will take priority over what's kept in the state
<Chipaca> mborzecki: I don't understand
<Chipaca> mborzecki: it doesn't make sense to have it in side info
<Chipaca> mborzecki: if the snap.yaml doesn't have a license, the license of the snap is unknown
<Chipaca> mborzecki: there is no side info
<mup> PR snapd#4541 opened: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4541>
<mborzecki> Chipaca: can you take a look at #4531?
<Chipaca> mborzecki: what am I missing?
<mup> PR #4531: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
<Son_Goku> mvo: https://github.com/snapcore/snapd/pull/4541
<mup> PR #4541: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4541>
<Chipaca> mborzecki: I can repeat what I'm saying here, there
<mvo> Son_Goku: \o/
<mborzecki> Chipaca: and the effects are like this https://paste.ubuntu.com/26457230/
<Son_Goku> zyga-ubuntu, mborzecki: you'll need to get snapd packages for testing from Koji for now: https://koji.fedoraproject.org/koji/packageinfo?packageID=23242
<zyga-ubuntu> Son_Goku: yep, doing that
<Chipaca> mborzecki: tell me if that makes sense to you
<Chipaca> mborzecki: and sorry if this is too much of a politics / business / lawyers thing for your taste :-)
<Son_Goku> zyga-ubuntu: the RHEL 7.5 beta just went live yesterday, apparently: https://www.redhat.com/en/blog/red-hat-enterprise-linux-75-beta-now-available
<Son_Goku> they rebased to GNOME 3.26
<Son_Goku> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.5_release_notes/new_features_desktop
<zyga-ubuntu> Son_Goku: can I update my existing installation?
<mborzecki> Chipaca: i'm ok with not showing the field, it just looks a bit weird when it's shown once and disappears once you install :/
<Son_Goku> zyga-ubuntu: CentOS doesn't have a RHEL 7.5 based build yet
<Son_Goku> unless you're paying for RHEL in some way, nope :/
<Son_Goku> I've grabbed the source packages for RHEL 7.5 Beta, so I'm going to check and see if GNOME Software was rebased
<Son_Goku> I think it was, but there's only one way to find out
<zyga-ubuntu> Son_Goku: ok, thanks for letting me know
<koza> mvo, https://github.com/snapcore/core/pull/77
<mup> PR core#77: Feature/fix motd 2 <Created by bergotorino> <https://github.com/snapcore/core/pull/77>
<mvo> koza: ta!
<mup> PR core#77 opened: Feature/fix motd 2 <Created by bergotorino> <https://github.com/snapcore/core/pull/77>
<Son_Goku> zyga-ubuntu: huh, looks like gnome software stayed at v3.22
<Chipaca> mborzecki: my problem is that things will get very hard to keep straight if we drop it into sideinfo to address the current issue
<Chipaca> mborzecki: once it's in sideinfo it doesn't go away
<zyga-ubuntu> mborzecki: I agree with Chipaca here
<zyga-ubuntu> landing a simple patch will put pressure to fix the snaps in the store
<zyga-ubuntu> (with new revisions)
<zyga-ubuntu> snapcraft should enforce some kind of license too (that's discussed separately with the new custom license text option)
<Chipaca> the store letting publishers change the license on the fly needs fixing too
<Chipaca> i'll file a bug
<zyga-ubuntu> Chipaca: gustavo raised this on the forum but a bug is a great idea
<ikey> zyga-ubuntu, thats a no on the ptrace thing
<Chipaca> zyga-ubuntu: ooh, do you have a link?
<ikey> games crash and die
<zyga-ubuntu> ikey: is it because
<zyga-ubuntu> aha
<zyga-ubuntu> ikey: on apparmor denial or on seccomp?
<zyga-ubuntu> Chipaca: sure, one moment
<ikey> cant remember man it was almost a month ago
<ikey> pretty confident it was seccomp
<zyga-ubuntu> good
<zyga-ubuntu> we have a fix for that
<ikey> sure?
<ikey> because my experience thus far is apparmor is weak.
<zyga-ubuntu> Chipaca: I think here https://forum.snapcraft.io/t/snap-license-metadata/856/14
<ikey> and lacks basic security features
<zyga-ubuntu> ikey: there's ongoing work to make seccomp non-fatal
<zyga-ubuntu> ikey: and then all seccomp, on compatible kernels, can set errno instead of killing the process
<ikey> ok but none of this is upstream much less in my kernels :)
<zyga-ubuntu> ikey: what does it lack that you miss the most?
<zyga-ubuntu> ikey: actually the seccomp is in the kernel now
<ikey> fine grained controls
<ikey> such as ppid/group specifiers
<zyga-ubuntu> ikey: it's also in libseccomp now, it's just very new
<mvo> zyga-ubuntu: so I tried the /snap mount unit again and I did a systemd-analyize plot and it runs fairly early. however I still get duplicated mount entries
<ikey> there are a number of comments in the PR about apparmor limitations
<zyga-ubuntu> ikey: those are variables, this is true and people are working on it but it's not straightforward
<zyga-ubuntu> mvo: can you pastebin what you have?
<zyga-ubuntu> mvo: the mount table
<ikey> alright but im just saying it seems like apparmor isnt finished
<ikey> and potentially presents more of a security risk than the issues it purports to resolve
<zyga-ubuntu> ikey: it's growing so things that grow are never finished
<ikey> by nature of wide matching
<ikey> you have to use a shotgun when you only need a pinprick
<zyga-ubuntu> well, it's that or a wide open door
<zyga-ubuntu> apart from variables I think it's pretty okay
<mvo> zyga-ubuntu: https://paste.ubuntu.com/26457288/
<zyga-ubuntu> I'd wish some niche things would be there but I don't think it's that bad
<mup> PR snapd#4542 opened: tests/main/kernel-snap-refresh-on-core: skip the whole test edge and stable are the same version <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4542>
<zyga-ubuntu> mvo: that's very curious
<ikey> tbh i think with the permissions that steam titles need, sandboxing is going to be a dishonest term for it, so ill probably need to document a wiki somewhere
<zyga-ubuntu> mvo: note what happened
<zyga-ubuntu> mvo: they are *both* shared
<zyga-ubuntu> that's better than before
<zyga-ubuntu> mvo: do you have the analysis somewhere?
<zyga-ubuntu> mvo: did the bind mount happen before the snap mount?
<mup> PR snapd#4535 closed: interfaces: miscellaneous policy updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4535>
<mup> PR snapd#4537 closed: interfaces/builtin: Replace Solus support with GLVND support <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4537>
<zyga-ubuntu> ikey: sure, it's a start though, things like ptrace are biggest issues as those are a way out of confinement for bad actors
<ikey> right - and the issue is i cant not have ptrace turned on
<ikey> and LSMs have no way to control ptrace properly
<ikey> pretty much all the AAA titles these days start a process cluster with a monitor, a shm + socket share, and ptrace the child
<zyga-ubuntu> that's true
<zyga-ubuntu> that's new to me, I didn't know it is this widespread
<ikey> its frustrating but i can /kinda/ see why they do it
<zyga-ubuntu> I'll talk to the security team to see if there's something that can be done to neuter ptrace without disabling it
<ikey> believe it or not a lot of them are actually using cef UIs too
<zyga-ubuntu> why do they do it? for crash reports only?
<zyga-ubuntu> cef?
<ikey> i dont know i dont have the source code :P
<ikey> cef, chrome/electron style apps
<zyga-ubuntu> ah
<ikey> its also possible ptrace is used in some games for active monitoring of memory to prevent cheating
<Chipaca> phew, three different fora tied together makes connecting the dots hard
<Chipaca> wait does this one count as four
<Chipaca> dammit
 * Chipaca takes a break before he feels too much like a manager againi
<ikey> fwiw shouldnt the default ptrace scope prevent blind escapes anyway zyga-ubuntu ?
<zyga-ubuntu> ikey: ptrace lets you manipulate enough to prevent LSMs from working from what I know
<ikey> sure but i mean ubuntu kernels are defaulting to a strict ptrace scope - regardless of the lsm
<zyga-ubuntu> ikey: I'm afraid I don't know the answer you seek
<ikey> and you can only inspect your child or parent in the group as long as the MAC is satisfied
<ikey> before it goes up to the lsm
<ikey> (CAP_SYS_PTRACE blowing the MAC and tree out of the water ofc though)
<ikey> anyway, now you can see why i said about limiting the interface to one snap :P
<zyga-ubuntu> yes
<mup> PR snapd#4527 closed: Fix comment about running gofmt on contributions <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4527>
<mup> PR core#77 closed: Feature/fix motd 2 <Created by bergotorino> <Merged by mvo5> <https://github.com/snapcore/core/pull/77>
<ikey> zyga-ubuntu, i think ill let the security guys get frightened by it and add some comments before i do any updates to it
<ikey> on account of all the hole-pokerin
<zyga-ubuntu> ikey: sounds like a plan :)
<ikey> with any luck ill be able to get a stable snap before q2
<popey> \o/
<ikey> popey, for clarification that wasn't optimism :p
<ikey> sorry
<zyga-ubuntu> Son_Goku: trying your fresh packages now
<popey> We live in hope ;)
<ikey> its just been a really, really, really, really long, tiring road.
<ikey> and regrets are forming
<ikey> i cant be a ray of sunshine about this anymore :p
<mup> PR snapd#4543 opened: tests: set test kernel-snap-refresh-on-core to manual <Created by mvo5> <https://github.com/snapcore/snapd/pull/4543>
<zyga-ubuntu> Son_Goku: where can I comment on the new build?
<Son_Goku> zyga-ubuntu: bodhi updates
<zyga-ubuntu> Son_Goku: did you send it as an update already? I only see the koji page
<Son_Goku> [04:21:32 AM]  <Son_Goku>	zyga-ubuntu, mborzecki: https://bodhi.fedoraproject.org/updates/FEDORA-2018-798e0f02ff & https://bodhi.fedoraproject.org/updates/FEDORA-2018-04bdce8944
<mborzecki> zyga-ubuntu: do you have fedora with graphics display installation? could you try installing slack?
<zyga-ubuntu> ah
<zyga-ubuntu> thanks!
<zyga-ubuntu> sure, I just play with spotify now
<zyga-ubuntu> I'll do slack next
<zyga-ubuntu> thank you Neal!
<ikey> best snap = spotify. :p
<zyga-ubuntu> indeed
<zyga-ubuntu> offtopic, how does gnome-software do reviews
<zyga-ubuntu> the flatpak spotify from flathub has reviews
<zyga-ubuntu> snap doesn't show any
<popey> the snap store doesn't support reviews (currently?)
<Son_Goku> there's no way to tie the reviews to the snap right now
<Son_Goku> they're bound by the key of the AppStream ID
<zyga-ubuntu> I see
<zyga-ubuntu> I heard that was released recently (appid support)
<Son_Goku> gnome-software reviews are not source-specific
<zyga-ubuntu> ahh
<zyga-ubuntu> cool
<zyga-ubuntu> that's great
<ikey> uses ODRS i believe
<Son_Goku> Yep
<Son_Goku> except on Ubuntu
<zyga-ubuntu> mborzecki, Chipaca ^ would be cool to surface that through the API
<Son_Goku> where it uses the Ubuntu One system instead
<ikey> ah k
<Son_Goku> (hence the Ubuntu One login requirement for reviews there)
<ikey> oh right 0-9 regex, need to remember that thing..
<zyga-ubuntu> mborzecki: slack works
<mborzecki> yay
<ikey> heh, now i have to "validate" my PR changes
<ikey> *launches games*
<ikey> yeah so zyga-ubuntu your suggested changes make valve unhappy
<ikey> it breaks
<ikey> the [0-9]+ thing doesnt work
<zyga-ubuntu> can you paste the diff please
<ikey> -+owner /{dev,run}/shm/u*-Shm_* mrw,
<ikey> ++owner /{dev,run}/shm/u[0-9]+-Shm_* mrw,
<ikey> do i need to scape somethin?
<ikey> *escape
<ikey> cuz that +- looks janky to my eyes
<zyga-ubuntu> wow, so what's there?
<zyga-ubuntu> yeah
<zyga-ubuntu> something looks fishy
<zyga-ubuntu> * is a .* or just *?
<zyga-ubuntu> uuuuuuuuuu or uomgthisisavalidausername
<ikey> sample path looks like /dev/shm/u1000-Shm_cf1307a0
 * zyga-ubuntu has an empty mind 
<ikey> ya i dont know if this is meant to be fnmatch style or what
<ogra_> mvo, FYI, multi volume support works fine here with latest edge \o/
<mvo> ogra_: yay, great to hear, thank you
<ogra_> no, thank *you* :)
 * mvo blushes
<mup> PR snapcraft#1883 closed: Revert "meta: create XDG_RUNTIME_DIR in wrappers. (#1818)" <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1883>
<ikey> yeah idk what to do with those [0-9]+ changes, introducing them breaks everything, and without them, works wonderful
 * ikey turns blind eye to existence of regex
<Chipaca> zyga-ubuntu: where does the + come from?
<zyga-ubuntu> Chipaca: in which sense?
<zyga-ubuntu> it was my adevice
<zyga-ubuntu> but it didn't work
<ikey> linux hates me
<Chipaca> zyga-ubuntu: I don't see other rules that use a +
<ikey> but we good with that
<zyga-ubuntu> yeah, I was just drunk
<zyga-ubuntu> I slept 3 hours today
<ikey> lol
<Chipaca> zyga-ubuntu: [0-9][0-9]* might work
<Chipaca> without groking this (so people who actually know can call me out), reading apparmor.d I see ?*[]{}^ are the special sauce, and everything else is non-special
<Chipaca> notably there's no + in that
<zyga-ubuntu> ...
<zyga-ubuntu> weird
<Chipaca> that's apparmor.d(5)
 * ikey looks at man page for sortafnmatchishkinda(3)
 * Chipaca hugs ikey and points him at the bar
<zyga-ubuntu> F27 works great, let's try the same in F26
<ikey> 11am lol
 * Son_Goku is rebasing snapd and snapd-glib for el7
<Chipaca> ikey: _salad_ bar, obvs
<zyga-ubuntu> ikey: itsregexpbutnotasyouknowitcaptin
<zyga-ubuntu> LOL
<ikey> Chipaca, oooh right
<zyga-ubuntu> fermented salad, must be good
<Chipaca> Son_Goku: why did I read that as e17
<ikey> poor rabbits walking away from the salad bar sideways
<Son_Goku> that... would be horrifying
<ikey> depends
<Son_Goku> I don't know if I can deal with Enlightenment as hangry as I am now
<ikey> if you mean the desktop
<ikey> or the boyband
<Son_Goku> ikey: either or
<Chipaca> Son_Goku: maybe you were *really* fed up with gnome
<ikey> s/gnome/life/
<Son_Goku> ikey might be closer to the truth...
<cjwatson> apparmor.d> the point here is that it's a glob, not a regex
<ikey> Son_Goku, take this! https://www.youtube.com/watch?v=-wNhdjoF-6M - its not safe to go alone
<zyga-ubuntu> (insert meme, not sure if few up with gnome or ...)
<Chipaca> cjwatson: but [0-9]* means 'lots of digits'?
<cjwatson> no, it means [0-9] followed by anything
<ikey> lol
<Son_Goku> ~_~
<cjwatson> like a shell wildcard expansion
<Chipaca> a'ight
<ikey> we could use {} and [0-9] to handle uids from 0 to 65555
<ikey> >_>
<cjwatson> (well, anything except /)
 * ikey eye twitches thinking about it
 * Son_Goku shuts down from brain damage caused by contemplating it
<Son_Goku> also... this video
<Son_Goku> wtf
<ikey> XD
<ikey> e17.. lol
<zyga-ubuntu> man
<zyga-ubuntu> I remember that login animantion still
<zyga-ubuntu> like duke 3d
<zyga-ubuntu> glorious pixels
<zyga-ubuntu> fiddled with the oomph of cpu alone
<ikey> like ill happily rip kde, but e17.. damn
<ikey> the desktop that time tried to forget
<mborzecki> zyga-ubuntu:  `NAUGHTY PROGRAMMER!!! SPANK SPANK SPANK!!!`?
<zyga-ubuntu> mvo: +1 to morge 4540
<ikey> for a second i thought y'all had a secret club
<ikey> then i remembered running any efl app ever
<zyga-ubuntu> I'm still stunned
<ikey> with a hash map that might not actually be the right hash
<ikey> (not kidding.)
<zyga-ubuntu> Son_Goku: your patches are merged
<mborzecki> whole efl was an unforgettable experience, i remember how that was the first thing that greeted you when you tried intel-ivi
<Son_Goku> zyga-ubuntu: yay
<mup> PR snapd#4525 closed: tests: new spread test for interface gpg-keys <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4525>
<mup> PR snapd#4541 closed: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4541>
<zyga-ubuntu> Son_Goku: F26 testing now
<zyga-ubuntu> Son_Goku: I'll do opensuse updates next
<zyga-ubuntu> and then escape the house
<ikey> ive tried describing the UI a couple times
<zyga-ubuntu> ikey: not the right hash?
<ikey> closest i ever got was "the unwanted child of melted lip gloss and hollywood remakes"
<zyga-ubuntu> ikey: as a programmer I alwas admired EFL for trying to come up with a set of rich C APIs for apps
<ikey> yeah they're APIs are kinda janky
<ikey> *their
<ikey> ow my engerlish
<zyga-ubuntu> oajsda
<zyga-ubuntu> I never tried them
<Son_Goku> meep
<ikey> just the general style is meh
<zyga-ubuntu> I know samsung invested some time and cash into it
<ikey> like namespace_type_{get,set}
<Son_Goku> they still do
<zyga-ubuntu> omg, reall?
<ikey> serious
<zyga-ubuntu> what for?
<ikey> tizen
<Son_Goku> all their TVs, watches, etc.
<ikey> and that one fridge
<Son_Goku> everything except the phones and tablets
<zyga-ubuntu> I thought tizen was a rewrite after EFL-based code went south
<zyga-ubuntu> man, insane
<Son_Goku> right, the creepy fridge too
<mborzecki> i can probably ask around today :P
<ikey> nah the modern tizen is the rewrite using efl
<ikey> tizen 2.x
<ikey> i.e tizen minus intel
<Son_Goku> yep
<Son_Goku> the tizen 1.x was the Qt5 based one
<zyga-ubuntu> it it pure efl under the tizen layer?
<Son_Goku> yep
<ikey> ish
<zyga-ubuntu> or sed/esomething_/sammy_/
<Son_Goku> well, there's the webkit/chrome thing
<ikey> they have crosswalk and whatnot
<ikey> was it crosswalk?
<ikey> the web yokey
<Son_Goku> I think so?
<Son_Goku> it's built on top of chromium now
<ikey> i was involved in tizen a whiles back
<ikey> we used gerrit.
<Son_Goku> they use ML + patchwork now
 * zyga-ubuntu too, though briefly 
<ikey> i had the distinct joy at one point of becoming the perl stack maintainer
<ikey> terrifying.
<Son_Goku> the chromium has a *massive* patch set to swap ffmpeg for gstreamer
<ikey> thats stoopid
<ikey> gstreamer-libav..
<Son_Goku> well, they don't ship gst-libav
<ikey> thats stoopid
<Son_Goku> they want to use the hw-accel codecs on the boards
<Son_Goku> which only gst can support
 * ikey was involved in a little known swift killed effort called "tizen pc" :p
<Son_Goku> I really wish the MeeGo thing had been more successful
<zyga-ubuntu> meetoo ;)
 * zyga-ubuntu reboots F26
<ikey> so the original moblin/meego guys also worked on the tizen pc effort
<ikey> the old openhand->intel crowd
<Son_Goku> and I will forever curse that Microsoft guy who killed it on Nokia
<ikey> i.e. creators of "modern gnome"
 * ikey worked with those dudes
<ikey> then i got lucky and got to work on non desktop stuff, and for a while, was content :P
<Son_Goku> then Solus happened
<Son_Goku> thrice
<ikey> was it thrice?
<Son_Goku> I can never really remember anymore
<ikey> ah right evolve os
<Son_Goku> yeah
<ikey> technically that one was a rename not a relaunch
<Son_Goku> I thought I got it right this time
<ikey> lol
<ikey> i cant even keep up
<Son_Goku> you *created* the bugger!
<ikey> lol
<Son_Goku> if you can't, what hope do the rest of us have?
<ikey> hey im just tryna escape :p
<Chipaca> i think that escape game beats the ops one
<zyga-ubuntu> Son_Goku: polkit works nicely
<Son_Goku> :D
<zyga-ubuntu> Son_Goku: though on F26 there's a loooooad of selinux advisory messages logged
 * Son_Goku sighs
<zyga-ubuntu> we really need to fix that one day
<Son_Goku> I know
<Son_Goku> but that requires time to sit down and go through all of it
<ikey> sudo setenforce 0
<Son_Goku> which I haven't had yet
<ikey> *tada*
<Son_Goku> ikey: it's non-blocking as selinux policy for snaps is permissive
<ikey> ill just grab my coat.. xD
<zyga-ubuntu> Son_Goku: any amount will help
<ikey> Son_Goku, ah just spammage, gotcha
<Son_Goku> yep
<zyga-ubuntu> Son_Goku: could you try a forum topic with a simple loop on how to do that
<zyga-ubuntu> maybe some people will help?
<ikey> oh oh oh oh speaking of forum topics
<Son_Goku> ...
 * ikey nails zyga-ubuntu's feet to the floor before he escapes
 * zyga-ubuntu is still here
<ikey> what we gonna do about this whole udev thingy?
<Son_Goku> you might want to clean up that liquored blood
<ikey> so that steam / ps4 controllers / etc work with the snap
<ikey> on account of they dont
<ikey> i mean technically the udev rules are jank in that they 0666 the controllers
<ikey> and it should probably be a uaccess thing
<zyga-ubuntu> what is uaccess?
 * Son_Goku watches the liquored blood pool from zyga-ubuntu's feet to ikey
<zyga-ubuntu> Son_Goku: F26 looks good
<ikey> udev/systemd stuff which tags the device with ACLs
<ikey> basically its acl/attr based
<zyga-ubuntu> ikey: ah
<zyga-ubuntu> you want that for a specific user
<ikey> sure and i dont know how thats going to tie into the whole snapd world
<zyga-ubuntu> and not wide open?
<zyga-ubuntu> it's on the roadmap for a long time
<zyga-ubuntu> jdstrand described it on the forum very very early on
<zyga-ubuntu> it's just not a thing that's scheduled yet
<ikey> ya i started a thread a few months back on it
<zyga-ubuntu> since pstolowski is looking into hotplug it will come aroudn
<ikey> but failed to construct a conversation
<zyga-ubuntu> sorry, I know that sucks
<ikey> im trying not to give up :P
<ikey> but honestly this steam crap has taken up an insane amount of my time so far
<zyga-ubuntu> this hack and slash game has an excess of mobs to kill and just a few adventurers :)
<ikey> and snapd still isnt ready for it
<ikey> i just wonder if its time to throw in the towel
<ikey> and cancel the lsi snaps
<zyga-ubuntu> ikey: are they unusable or just not great?
<Son_Goku> zyga-ubuntu: they don't work
<ikey> what the snaps or the controllers?
<Son_Goku> well, a number of games don't
<ikey> the basic confinement rules in snapd breaks many games
<zyga-ubuntu> ikey: could they just work now with devmode?
<ikey> no
<ikey> devmode is whats breaking it
<zyga-ubuntu> ikey: I think it's fine to run in devmode while other things get into place
<zyga-ubuntu> why not?
<zyga-ubuntu> oh?!
<Son_Goku> zyga-ubuntu: because there are still basic filters in place with devmode
<ikey> why do you think im sat on my arse screaming all the time? :P
<Son_Goku> you _still_ can't do certain things
<ikey> snapd actively breaks my snaps
<ikey> all feral games are broken with it
<zyga-ubuntu> I know dbus doesn't get turned off
<zyga-ubuntu> maybe we could turn of the device cgroup
<ikey> it breaks mapping libraries
<zyga-ubuntu> to make devmode really devmode
<ikey> basically with my PR, the strict snap works better than the devmode one
<ikey> like, way better
<ikey> it also reduces host contamination
<ikey> so i have the snaps working the same on all distros
<zyga-ubuntu> ikey: don't throw the towel yet please, let's see what securty thinks of it
<ikey> with devmode i have contamination
<zyga-ubuntu> I think it's fine for this one snap
<zyga-ubuntu> note that devmode doesn't mean classic
<ikey> right
<zyga-ubuntu> it'd be be namespaced
<Son_Goku> classic is a whole nother problem
<ikey> its the basic profiles that bugger it
<zyga-ubuntu> but if you say that this PR fixes the buggers for you
<ikey> and i cannot use classic with my snaps
<zyga-ubuntu> let's see what we need to do to land it
<ikey> like it has to be isolated
<zyga-ubuntu> and 2.31 rc2 is around the corner
<ikey> got a whole solus inside it
<zyga-ubuntu> I see
<zyga-ubuntu> right!
 * zyga-ubuntu screams at gnome boxes
<ikey> honestly i have two major items left on my snap worklist
<zyga-ubuntu> and alt-f4 closing the wrong window
<ikey> first is actually getting full confinement
<ikey> even at that point i can move off edge channel
<ikey> the next major one being controller support
<ikey> thats literally all there is in major items
<zyga-ubuntu> can you think of some low hanging fruit to make controllers work for now?
<zyga-ubuntu> even for that one snap
<zyga-ubuntu> you can udev tag and do anything with it after all
<ikey> probably some fudging of the joystick interface
<ikey> or hidraw maybe
<ikey> because we actually will want hidraw for ps4/steam controllers
<ikey> but even getting to a point (even without controllers) where i can move the snaps off edge will help significantly
<ikey> right now only a very small handful can actually test and use it
<mcphail> ikey: i can only beg you to come back to this at some point rather than abandoning it. We really need something like your snaps to push out the rough edges of the whole snap infrastructure. i can't think of anyone else as qualified to be able to push this through
<ikey> mcphail, i get what you're saying but its the "come back to this" part thats the issue for me
<mcphail> i understand
<ikey> i want/need to move solus off of package based steam runtime
<ikey> as it has a limited shelf life for the core distro
<Son_Goku> needs to be lifecycled independently, right?
<ikey> basically
<ikey> we need to be able to hammer it and solus separately in some areas
<ikey> because ABI compat
<Son_Goku> and ABI ugliness :/
<mborzecki> mvo: linode:ubuntu-16.04-32:tests/unit/go fails in strace test https://paste.ubuntu.com/26457861/
<mcphail> if /me was sabdfl, i'd be on the phone getting a team together to push this through with urgency
<ikey> mcphail, fwiw im not overly fussed with *how* long things take, just as long as im part of that timeline
<ikey> anyway, ima hold out a bit longer on this because there are still interesting bits to solve
<ikey> and my 2018 goal is to try and kick linux gaming up the bum
<ikey> and i didnt google the current year there.
<ikey> (kinda did.)
<mcphail> ikey: what i'd say is, unlike yhe similar experiences with click packages on the phone, it does seem that snaps continue to move in the right direction. albeit it is a chore to keep everyone focused on the same goals
<mup> PR snapd#4543 closed: tests: set test kernel-snap-refresh-on-core to manual <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4543>
<mcphail> the improvements i've seen in the snap world over a few years has been greatly encoraging, and much more developer friendly
<ikey> mcphail, plus i just decided to have the most awkward snap proposal, couldnt have been satisfied with just packaging gedit :p
<mcphail> i'm optimistic it is possible to get steam and lsi working properly :) (and soon)
<ikey> we'll see which way does it go
<mcphail> ikey: and if it doesn't work out, i greatly appreciate your efforts
<ikey> ah no worries
<ikey> if push comes to shove ill bundle it up in an ironic self extracting .exe
<zyga-ubuntu> frankensteim.exe.sh
<ikey> i wish for this name to be a thing
<ikey> The Windows Steam Linux Steam Subruntime System Subsystem â¢
<zyga-ubuntu> for OS2/Warp
<ikey> lol
<zyga-ubuntu> it will play Rebel Assault
<mup> PR snapd#4540 closed: spread: Ubuntu 17.04 is EOL, remove it <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4540>
<zyga-ubuntu> and support 9dot printers
<ikey> o/t: i was at an amiga event the other day
 * ikey wants to upgrade to a downgrade
<zyga-ubuntu> pstolowski: conflict on 4401
<mup> PR snapd#4542 closed: tests/main/kernel-snap-refresh-on-core: skip the whole test edge and stable are the same version <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4542>
<pstolowski> zyga-ubuntu, thanks, looking
<zyga-ubuntu> 4459 needs a 2nd review
 * zyga-ubuntu is now starting to crash
<ikey> sleeeeeep
<zyga-ubuntu> sleep $debt
<ogra_> sleeping for the bank ?
<mvo> mborzecki: meh, thank you, looking
<ikey> count sheep vaulting over the .. well.. the vault
<zyga-ubuntu> I just imagined borderlands vault and sheep getting slaughtered
<ikey> lol
<zyga-ubuntu> with green blood and rocket lauchers
<Son_Goku> zyga-ubuntu: can I conk out and die now? https://forum.snapcraft.io/t/install-snapd-on-centos/1495/21?u=conan_kudo
<ogra_> zyga-ubuntu, mvo could someone put a yes or no in https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675 (it is bocking a decision for a customer snap)
<zyga-ubuntu> Son_Goku: please don't die
 * zyga-ubuntu looks
<ogra_> thx
<zyga-ubuntu> Nice, I will give that a try!
<zyga-ubuntu> ogra_: ack, enqueued
<ogra_> thx
<ogra_> :)
<mup> PR snapd#4356 closed: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4356>
<zyga-ubuntu> ogra_: on real paper queue
<ogra_> haha, you're so last century
<zyga-ubuntu> no, I refreshed to --stable
<zyga-ubuntu> ;)
<ogra_> lol
<mvo> zyga-ubuntu: yay, thanks for merging this
<mvo> ogra_: my gut feeling is that this is a gustavo question but let me check
<zyga-ubuntu> mvo: we're at 36 PRs
<zyga-ubuntu> mvo: much nicer than 45 yesterday
<mvo> zyga-ubuntu: \o/
<mvo> uygindeed
<zyga-ubuntu> mvo: we could go to 29 it would be an awesome day
<ogra_> mvo, well, mine is that it is a samulele one, but he seems to be vacating
<zyga-ubuntu> mvo: I think some should be closed
<mvo> ogra_: heh
<mvo> zyga-ubuntu: 4517 for example - did you had a chance to look at my mountinfo?
<zyga-ubuntu> mvo: the one with two entries?
<zyga-ubuntu> mvo: yes, did you see my follow up question?
<zyga-ubuntu> mvo: I asked about the order of events in systemd, if you had that from boot analysis
 * zyga-ubuntu updates centos 7
<ikey> good luck :3
<zyga-ubuntu> mvo: 4351 looks like an easy win if you can look
<zyga-ubuntu> mborzecki: what's the state of 4285?
<mvo> zyga-ubuntu: I missed the question, I can uplaod my svg
<zyga-ubuntu> mvo: can we just merge 4049?
<zyga-ubuntu> mvo: thanks!
<ikey> btw can report im using snapd + glvnd here quite nicely
<zyga-ubuntu> ikey: awesome!
<ikey> thought it'd be more problematic but seems to be fine now
<ikey> just had that one rule change in apparmor to do and then it slotted into place
<mborzecki> zyga-ubuntu: haven't updated 4285 yet
<zyga-ubuntu> mborzecki: shall we close it until you do or do you want to let it linger there?
<mup> PR snapd#4351 closed: tests: new test to validate location control interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4351>
 * zyga-ubuntu puts some peer pressure to cut those PRs 
<zyga-ubuntu> (howerver I come out over IRC my intentions are good:)
<ikey> text makes it hard to express *how* you mean something..
<niemeyer> Heya
<niemeyer> zyga-ubuntu:
<niemeyer> "2018-01-24 23:02:31 Cannot allocate linode:debian-9-64: server linode:debian-9-64 (Spread-5460254) concurrently allocated, giving up on it"
<niemeyer> zyga-ubuntu: Shouldn't fail based on that
<zyga-ubuntu> hey hey
<zyga-ubuntu> niemeyer: AFAIR that one failed totally but it was ok on next go
<ikey> when they said CI, you didnt think it'd be the framework you'd be integrating :p
<zyga-ubuntu> niemeyer: no issues today
<niemeyer> zyga-ubuntu: It will allocate something else, and even if that fails too, there are other systems that can pick up its work
<zyga-ubuntu> niemeyer: and things are l-l-landing :)
<niemeyer> zyga-ubuntu: But for a different reason, I assume
<zyga-ubuntu> niemeyer: yeah, I think it was still one of those pre-fix PRs
<niemeyer> ikey: Yeah :)
<ikey> so hypotheticals:
<zyga-ubuntu> niemeyer: just heads up if I don't show up today; I was up till 3AM for some reason and woke up at 7 today
<ikey> lets say post new interface merge and such, ill need to request autoconnect for the new interface
<ikey> this is something that the store decides or..?
<zyga-ubuntu> and I feel like floor is warm and soft now
<ikey> i was tryna wrap my head around it
<zyga-ubuntu> ikey: yes
<mborzecki> zyga-ubuntu: hm i have a wip branch for 4285 that i forgot to push ;) i'll merge current master, resolve coflicts and push it and we'll see how for it will go this time
<ikey> aha, ty
<zyga-ubuntu> ikey: it's in the snap declaration assertion
<zyga-ubuntu> mborzecki: awesome, thank you
<ikey> see i was stuck on this for a long time, figuring out how do i make stuff autoconnect..
<zyga-ubuntu> ikey: essentially you can get more things if the store says it's okay
<ikey> right
<zyga-ubuntu> ikey: ask on the forum and it gets voted and granted
<ikey> and for the steam-support one, we'd want it to be sanctioned by store only
<ikey> not by the snap itself
<ikey> cuz its poking an awful lot of holes
<zyga-ubuntu> yeah
<zyga-ubuntu> snap can say it wants anything
<zyga-ubuntu> but snapd has a built-in policy
<ikey> right
<zyga-ubuntu> and store has a persnap override
<ikey> yeah i dont want someone getting the wrong idea and start using steam-support in their snaps
<zyga-ubuntu> no worries, it's safe
<ikey> as it is technically an extension of browser-support
<ikey> without sandbox keys
<mvo> zyga-ubuntu: the ordering http://people.canonical.com/~mvo/tmp/snap-boot.svg
<zyga-ubuntu> thank you, looking
<ikey> so i guess an interesting question becomes - does the steam snap really then need to know about ~ after this?
<mvo> mborzecki: in what PR was this strace error? is that master failing?
<ikey> i mean i assume its harmless enough as it cant access dotfiles
<ikey> typically folks use steam with a ~ library or a removable-media library..
<zyga-ubuntu> ikey: probably no then
<mborzecki> mvo: https://travis-ci.org/snapcore/snapd/builds/333196455 4531
<ikey> ya cuz if they have steam library already in ~ - we cant see it in snap
<ikey> because it'd be ~/.local/share/Steam
<zyga-ubuntu> yep
<zyga-ubuntu> migration sucks
<zyga-ubuntu> but then ~ is $HOME/snap/$SNAP_NAME/$SNAP_REVISION anyway
<ikey> right but i mean if they move from "native" steam to lsi steam
<zyga-ubuntu> maybe offer a migration script?
<zyga-ubuntu> or a migration tool
<zyga-ubuntu> that can run and can have :home
<ikey> hm.
<zyga-ubuntu> it would just cp/mv
<ikey> yeah that could be an idea
<zyga-ubuntu> it could even be the configure hook!
<zyga-ubuntu> just give it :home
<zyga-ubuntu> :)
<zyga-ubuntu> (kind of neat, no?)
<ikey> but if they're in the old ~/.local/share/Steam then they're out of luck
<ikey> like host-side ~
<zyga-ubuntu> ah, yes
<ikey> cuz confinement wont let us see that
<zyga-ubuntu> well
<zyga-ubuntu> it's just an interface away :)
<zyga-ubuntu> it could be steam-migration iface
<ikey> well i think maybe we'll cross that bridge when we get to it
<ikey> and for now focus on immediate concerns, like, does it play the games it sees
<mvo> mborzecki: thank you
<mvo> mborzecki: I think I know what it is, sorry for that, a race, restart may help
 * ikey fixes dumb typo in PR
<zyga-ubuntu> Son_Goku: installing snapd on centos now :)
<zyga-ubuntu> so far good though I wonder about that 3.10 kernel
<zyga-ubuntu> *exciting* in some ways
<ikey> 3.10? o-O
<zyga-ubuntu> Son_Goku: failed on lack of squasfuse and policycoreutils-python-utils
<Son_Goku> zyga-ubuntu: you need epel-release installed
<zyga-ubuntu> Son_Goku: cool, can you update your post please?
<Son_Goku> done
<zyga-ubuntu> (I supect it will become the official install docs soon)
<Son_Goku> it'd better not
<ikey> lol
<Son_Goku> I don't even know if anything works
<Son_Goku> policycoreutils-python-utils is probably a packaging bug
<zyga-ubuntu> Son_Goku: better but policycoreutils-python-utils (what a package name) is still missing
<ikey> as we all know, if the package manager says something is installed, then it means it works
<zyga-ubuntu> though squashfuse is now OK
<zyga-ubuntu> ikey: if it compiles send it to the mars rover
<ikey> lol
<Son_Goku> the package was renamed sometime between Fedora 22 and Fedora 27
<Son_Goku> I should just change that to a file dep...
<zyga-ubuntu> great, I will try it when the new build is done
<zyga-ubuntu> mvo: doing that svg analysis now
<zyga-ubuntu> btw, any hints on how to reproduce that?
<zyga-ubuntu> mvo: did you see my question about 4049?
<zyga-ubuntu> mvo: is that something we can now land?
<zyga-ubuntu> Son_Goku: the instructions should tell people to update, epel-release gives new gnome-software
<Son_Goku> epel-release gives you squashfuse
<Son_Goku> not new gnome-software
<Son_Goku> new gnome-software comes from copr repo
<zyga-ubuntu> ah
<zyga-ubuntu> sorry
<zyga-ubuntu> it's from your repo
<zyga-ubuntu> I misread, all is cool
<mborzecki> zyga-ubuntu: pushed to #4285
<mup> PR #4285: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4285>
<Saviq> niemeyer: hey, any news re: spread?
<niemeyer> Saviq: Well, lots of them
<niemeyer> Saviq: What are you looking for more specifically?
<zyga-ubuntu> mvo: in your trace there are no snap mount entries, (there's just one for /snap), any idea why?
<Son_Goku> zyga-ubuntu: at least now all the selinux macros are defined in el7...
<zyga-ubuntu> mvo: was that on an empty VM without any snaps?
<Son_Goku> that was a big problem before
<Chipaca> I'm stopping for lunch with my parents who dropped by; I might be a little late to the standup (I'll try not to)
<zyga-ubuntu> Chipaca: enjoy
<Chipaca> zyga-ubuntu: as you wish
<niemeyer> Saviq?
<Son_Goku> zyga-ubuntu: new build published
<zyga-ubuntu> yes, I saw
<zyga-ubuntu> updating
<Saviq> niemeyer: sorry, the Mir failures to allocate nodes?
<niemeyer> Saviq: Where are the logs?
<zyga-ubuntu> Son_Goku: installing :)
<Saviq> niemeyer: https://travis-ci.org/MirServer/mir
<zyga-ubuntu> Son_Goku: oh, I like that prompt
<Son_Goku> zyga-ubuntu: eh?
<zyga-ubuntu> "enable non-free software"
<zyga-ubuntu> in g-s on startup
<Son_Goku> :)
<zyga-ubuntu> installing core now
<zyga-ubuntu> though no snaps in g-s
<zyga-ubuntu> I'll reboot in case ... not sure
<zyga-ubuntu> plugin dind't load somewhere
<Son_Goku> you may need to kill g-s daemon and reload it
<zyga-ubuntu> right
<Son_Goku> g-s starts as a session daemon
<Son_Goku> so I _think_ logging out and logging back in should be enough
<zyga-ubuntu> Son_Goku: g-s needs me to sign-in
<Son_Goku> yeah
<Son_Goku> that's always been the case
<zyga-ubuntu> Son_Goku: I think that's either older code or maybe polkit
<zyga-ubuntu> Son_Goku: no, it's not!
<zyga-ubuntu> Son_Goku: try it on fedora
<Son_Goku> for g-s 3.22?
<zyga-ubuntu> it's a polkit prompt now
<Son_Goku> I think it is
<ikey> i wonder what real world people do when they see those prompts
<zyga-ubuntu> ahh
<zyga-ubuntu> maybe
<ikey> "enable non-free software"
<ikey> "is this discount shopping mode?"
<Son_Goku> xD
<zyga-ubuntu> I thought that was a part of the plugin to g-s that you ship
<zyga-ubuntu> ikey: LOL
<Son_Goku> I ship the plugin as is from gnome-3-22 branch: https://gitlab.gnome.org/GNOME/gnome-software/commits/gnome-3-22
 * ikey focuses on the important issues in life.. :p
<zyga-ubuntu> OK
<Son_Goku> there's a lot more crap here: https://gitlab.gnome.org/GNOME/gnome-software/commits/wip/ubuntu-3-22
<niemeyer> Saviq: Looks like the same concurrency issue we're seeing in snapd in some cases.. I need to dig into it
<Son_Goku> but I don't really want to touch that
<zyga-ubuntu> Son_Goku: I cannot log in, probably something missing in packaging or wrong paths
<niemeyer> Saviq: It's safe to restart the build in those cases
<niemeyer> Saviq: I'll let you know once it's supposed to not happen again
<Son_Goku> the paths are unchanged between Fedora and EL7, since it's the same packages
<Son_Goku> just tweaks for dependencies
<zyga-ubuntu> Son_Goku: selinux prevents startup of snapd-login-service
<zyga-ubuntu> Son_Goku: "setenforce 0" t-shirt
<Son_Goku> oh joy
<Son_Goku> more policy fixes
<zyga-ubuntu> there are more denials on snap install
<Son_Goku> zyga-ubuntu: but this is why this is an experimental repository :)
<zyga-ubuntu> I think the "advisory" part didn't work
<zyga-ubuntu> sure :)
<zyga-ubuntu> though snap install is still running
<zyga-ubuntu> (downloading)
<zyga-ubuntu> spotify works!
<ikey> \i.
<ikey> er
<ikey> \o/*
<ikey> <insert off by one joke here>
<zyga-ubuntu> Son_Goku: com.canonical.SafeLauncher was not provided by any service files
<zyga-ubuntu> eiter activation or selinux
<Son_Goku> oh no
<Son_Goku> I know what's wrong
<Son_Goku> I updated snapd-glib
<Son_Goku> and the plugin doesn't know about the new name
<zyga-ubuntu> hmm that's from the core snap
<zyga-ubuntu> and from the snapd package
<zyga-ubuntu> so it shouldn't care
<zyga-ubuntu> I ran 'xdg-open' in snap run --shell foo
<Son_Goku> hmm, nothing has changed in the code since 1.26
<zyga-ubuntu> Son_Goku: run "snap userd"
<Son_Goku> I'm providing 1.29, which should work
<zyga-ubuntu> it cannot acquire bus name
<zyga-ubuntu> it's selinux
<zyga-ubuntu> hmmm
<zyga-ubuntu> is the dbus service file path correct?
<zyga-ubuntu> as in /usr/share/dbus-1/services/
<Son_Goku> rpm -ql snapd-login-service
<zyga-ubuntu> no not
<zyga-ubuntu> that's separate
<zyga-ubuntu> snap userd
<zyga-ubuntu> (I think)
<zyga-ubuntu> I'll investigate after standup
<Son_Goku> okay
<Son_Goku> I've got to get ready for work anyway
<Son_Goku> yay... full day of tiredness
<zyga-ubuntu> Thank you! This is a big push forward
 * Son_Goku yawns
<Son_Goku> ðª
<zyga-ubuntu> WOW
<zyga-ubuntu> irssi does emoji in gnome terminal
<zyga-ubuntu> crazy
<ikey> hot damn
<ikey> i have a tamigotchi in my hexchat
<ikey> (looks like one anyway :P)
<zyga-ubuntu> ^ Chipaca that's a whole new chapter for smily faces
<Son_Goku> if you're on gnome 3.24 or newer, you should have emoji support
<ikey> oh crap i forgot to add colour emoji support to solus
<ikey> knew i was missing something
<Son_Goku> or was it gnome 3.26
<Son_Goku> meh
<Son_Goku> either one
<ikey> .26 + git bits
<Son_Goku> right
<Son_Goku> okay then
<Son_Goku> ikey: you should add that...
<Son_Goku> it's kinda nice to have
<ikey> yeah i created an "unbreak now" task for that
<ikey> think that was november
<ikey> still deciding precisely what "now" means
<Son_Goku> yeah, there's a bit of a mess to untangle and fun fontconfig directives
<ikey> yer
<ikey> and newer fontconfig trashed older emojis
<ikey> so i reverted it
<Saviq> niemeyer: it's a 100% failure rate though, so restarting doesn't help
<niemeyer> Saviq: Ok, in the standup, but will dig into this right afterwards
<Saviq> maybe we can limit the number of jobs, since we're starting multiple spreads concurrently
<ikey> so is that glass half full or ... ? :p
<ogra_> right or left half is the question here i guess ...
<ikey> lol
<mup> PR snapd#4544 opened: spread: remove more EOLed releases <Created by zyga> <https://github.com/snapcore/snapd/pull/4544>
<zyga-ubuntu> mvo: ahem
<zyga-ubuntu> so I need that nap now
<mvo> zyga-ubuntu: hm?
<zyga-ubuntu> you were certainly right
<mvo> zyga-ubuntu: oh, sure, go for it
<mborzecki> zyga-ubuntu: need some help lookin into selinux things?
<zyga-ubuntu> I didn't stage it
<mvo> zyga-ubuntu: I'm not sure right about what, but its fine, we can talk later :)
 * pstolowski lunch
<zyga-ubuntu> mborzecki: no, not now, I'm in a state of running on life supprot
<zyga-ubuntu> I need sleep first
<zyga-ubuntu> mvo: about EOL releases, see pr 4544
<mborzecki> ok, i'll try to take the packages for a spin here
<mup> PR #4544: spread: remove more EOLed releases <Created by zyga> <https://github.com/snapcore/snapd/pull/4544>
<mvo> zyga-ubuntu: aha, ok
 * zyga-ubuntu -> sleep
 * kalikiana going to head out for lunch shortly
<jdstrand> ikey: 'apparmor is weak' - can you give specifics? if you are talking about ptrace only, then apparmor is actually quite strong
<sergiusens> mvo cachio noise][ we've been getting a bunch of these lately (from snapd) https://paste.ubuntu.com/26458462/ ... do you guys see the same?
<ikey> no ptrace is the kernels fault
<ikey> that part i know
<ikey> i mean in terms of currently available selectors
<jdstrand> ikey (cc zyga-ubuntu): the issue with ptrace (and capabilities for that matter) is that the kernel, separate from apparmor and the LSMs, lumps things together that shouldn't be
<ikey> ya i know :) tis why i said its the kernels fault
<ikey> kernel doesn't give the lsm enough to work with
<ikey> seems the kernel is generally unfriendly to lsm design
<mvo> sergiusens: that looks like a server side timeout to me
<cachio> sergiusens, I didn't see this on our tests
<jdstrand> ikey (cc zyga-ubuntu): and what the comments say in the policy is that on <4.8 kernels, ptrace could be used to break out of the seccomp sandbox. so, because apparmor is strong, we block it
<mvo> sergiusens: the snapd log should contain a bunch of retries
<mvo> sergiusens: we retry hard but eventually (have to) give up
<sergiusens> mvo thanks, it is on travis though, so I cannot see much into it :-)
<ikey> jdstrand, right
<jdstrand> ikey: the kernel certainly can be, yes (note, I'm still reading the long backtrace, so sorry if repeating things)
<ikey> yeah no worries, figured :D
<jdstrand> ikey (c zyga-ubuntu): so, for >=4.8 kernels, we could actually allow ptrace oneself and anything matching your snap's label
<ikey> right
<jdstrand> ikey: snapd could interrogate the kernel version and allow that rule conditionally
<ikey> i know in solus terms we expect minimum 4.9 kernel
<ikey> (thats the oldest we ship)
<ikey> but other distros etc..
<jdstrand> ikey: the only problem is we would really want to also support <4.8 kernels that have that patch backported, and there is no way to interrogate that (it isn't exposed in sysfs, etc)
<Son_Goku> jdstrand: distro patch for backported kernels
<jdstrand> but, we could probably do things like 'if dist is ... and kernel > ...)
<ikey> hm yeah
<ikey> fwiw solus has a funky uname so i dont know if that affects things
<jdstrand> Son_Goku: that's what I'm saying. some will want that patch (it is great on its own, unrelated to snapd)
<Son_Goku> that's probably going to be necessary for CentOS 7 if I really decide I want that working...
<ikey> i assume your detection can ignore extra_version info
<jdstrand> and we'd want to detect they have it
<ikey> robustnessnessâ¢
<Son_Goku> NOOOPE
<ikey> aw
<ikey> could so be a word
<ikey> btw jdstrand apologies for any trauma inflicted by my PR :P
<brunosfer> I'm having this error when I'm staging a file in snapcraft.yaml does anyone can help me? The error is: `SystemError: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22ece2af1015668ccc056a3396acc37aba3295be593ad5cb979843e44423ff5c3d560113fc876976790a6/var/lib/apt/lists/partial/deb.nodesource.com_node%5f8.x_dists_artful_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permi
<brunosfer> ssion denied), E:Method http has died unexpectedly!, E:Sub-process http received a segmentation fault.`
<diddledan> morning
<jdstrand> ikey: beyond ptrace, one 'weakness' is leakyness in /proc since @{pid} doesn't apply to the snap. we try to document that wherever we know it is leaky so we can fix it. *but*, those leaks are minor. if there is something big, we put it behind a separate interface
<ikey> hm ok
<jdstrand> ikey: the other thing is lack of finegrained network mediation
<ikey> yeah
<jdstrand> most snaps don't need that, so we have 'network-control'
<mup> PR snapd#4488 closed: snap: make `snap find --section` show all sections <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4488>
<ikey> and then apply to something as large as steam and it gets nasty..
<jdstrand> but sure, it isn't 'done'
<ikey> as they say, when is anything
<jdstrand> but it is very flexible and allows us to stitch together policies and let snaps interact in very flexible ways
<jdstrand> so we are working to finish it, after it is upstreamed
<ikey> which forces you to batch work really
<jdstrand> but this is also why we combine technologies
<jdstrand> anyway
<ikey> :D
<jdstrand> ikey: so, you have a forum post and a PR. its been on my todo to look at both, but between holidays and sprinting, hasn't been done yet
<ikey> sure
<jdstrand> ikey: which would you like me to look at first?
<jdstrand> (and sorry for not looking at it sooner)
<ikey> well the PR is the manifestation of the topic
<ikey> basically add new interface derived from browser-support
<ikey> to make things not bork
<ikey> and poke relevant holes
<ikey> and those holes are apparently your domain to determine badness â¢
 * ikey tm's all the things
<ikey> the idea is we want the interface to not autoconnect, and get a vote on the forum to have the lsi snap autoconnect to steam-support
<ikey> due to the nature of the hole popping
<jdstrand> ok, I'll read the forum post for context then look at the pr. I'll try to get to it today, if not tomorrow
 * jdstrand nods
<jdstrand> you know
<ikey> in future ill need autoconnects for hidraw/joystick/removable-media
<ikey> and extend for ps4/steam controllers/etc
<ikey> just the nature of the beast..
<jdstrand> we could in theory look at auto-connection depending on kernel version
<ikey> so the problem is that under strict confinement, steam absolutely and utterly requires this interface
<jdstrand> that would require a bit of work, but I'll take a look at the policy and ask questions, etc
<ikey> or will spinlock-of-doom
<ikey> it gets stuck in an infinite cycle trying to open the shm nodes
<jdstrand> shm is annoying
<ikey> yeah
<ikey> also, even in devmode, a lot of stuff is broken by the base policies
<jdstrand> there is something that apparmor could do there as well
<ikey> but yeah, as you can imagine, getting all the denials and whatnot was a complete pain
<ikey> lol
<Chipaca> niemeyer: wall of text wrt licenses
<ikey> but finally got to the point where i could even launch and play AAA titles from feral
<Chipaca> sorry for it, i mean
<ikey> so, yay
<Chipaca> also why is my day all about licenses :-(
<jdstrand> oftentimes (but not always) you can adjust the path, but that requires patching or LD_PRELOAD, which may or may not work for you (obviously patching wouldn't)
<ikey> so LSI is kinda on a thin line of "is this ok" with the existing redirects it does to games
<ikey> and the silent agreement with valve is we dont break *them* or do anything that could be misconstrued as cheating
<ikey> so unbreaking libraries and behaviour is OK
<ikey> but i imagine they'll frown on me redirecting shm
<ikey> especially when you factor in VAC
<jdstrand> that is unbreaking something :)
<ikey> its not broken
<ikey> but the shm is used for IPC in the libsteam API
<jdstrand> it depends on how you look at it
<ikey> and is used for the client + transactions
<ikey> oh i know
<ikey> but i dont wanna take the piss with valve, basically
 * jdstrand nods
<ikey> so we dont do any symbol redirection in valves space in LSI
<ikey> we only do LD_PRELOAD fixes to definitely-broken-games
<ikey> and it keeps everyone "Happy"
<ikey> its also why most of LSI is hard-coded fixes, so that users cannot extend it to bypass systems
<ikey> and thats sorta been the silent agreement
<ikey> write it well and dont let it become a cheat system
 * jdstrand nods
<ikey> fwiw in future we'll be moving solus exclusively to the snaps for steam and its very likely we'll add self verification for the LSI modules
<ikey> as part of that "we're not cheating" thing
<ikey> why i had to pick gaming for my niche ill never know
<jdstrand> haha
<ikey> but all the drama aside i do look forward to dispelling the game devs raison d'etre for not supporting linux
<Chipaca> ikey: starts with m, rhymes with schism
<ikey> "too many distros"
<ikey> Chipaca, oh i know this one!
<ikey> macho man randy savage
<niemeyer> Chipaca: np, responded
<ikey> also since when do i causally use french
<elopio> hello everybody
<mborzecki> off to get the kids
<Chipaca> niemeyer: the long thing i wrote might not have been as clear as I thought it was; can you give it a second read? What I tried to do was exactly point out what you open by saying you don't see
<Chipaca> that is, it tries to explain _why_ the issues are harder
<jdstrand> roadmr: fyi, lxi-tools got stuck on r576 and r577. I simply ran the automated reviews again and it seems to be clearing out the backlog
<jdstrand> roadmr: iirc, r576 said something about 'task state unknown'
<jdstrand> roadmr: I'm sorry: s/576/575/
<jdstrand> roadmr: I don't need anything at this point. fyi only
<roadmr> jdstrand: ok... yes, task state unknown happens when a revision gets queued while another is processing
<roadmr> because the task hasn't been started, its state is unknown
<brunosfer> I'm having this error when I'm staging a file in snapcraft.yaml does anyone can help me? The error is: `SystemError: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22ece2af1015668ccc056a3396acc37aba3295be593ad5cb979843e44423ff5c3d560113fc876976790a6/var/lib/apt/lists/partial/deb.nodesource.com_node%5f8.x_dists_artful_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permi
<brunosfer> <brunosfer> ssion denied), E:Method http has died unexpectedly!, E:Sub-process http received a segmentation fault.`
<roadmr> jdstrand: the ones that are being processed say stuff like "Task 8f975758-3665-497f-840e-77e2178c9459 is waiting for execution. "
<roadmr> in this case we're just waiting for an available worker process
<jdstrand> roadmr: ok, but by 'stuck' I mean that 18 hours ago it was uploaded and didn't progress, and 24 revisions were queued behind it
<elopio> kyrofa: the autopkgtests can be triggered again from the bot.
<roadmr> jdstrand: oh!!
<roadmr> jdstrand: let me check the logs
<jdstrand> roadmr: do look at 577 in addition to 575 though, it said something about /tmp/... couldn't be found (or similar) so it sounded like it got reaped early or something (<wildguesses/>)
<roadmr> jdstrand: yes, I have seen that thing about temporary directories occasionally, think we still have that race condition sometimes :/
<roadmr> jdstrand: and I think in that case the task does end up in an unfinished state, which is what blocks the queue
<roadmr> jdstrand: there's a place where I can check for stuck revisions, but I don't look at it regularly :/
<jdstrand> roadmr: so the theory is 575 and 577 were uploaded at about the same time, they raced and deadlocked?
<roadmr> jdstrand: it could be. The snap is big enough that one review might have been in progress when the other 2 (576 and 577) were uploaded
<roadmr> jdstrand: it's somewhat surprising though because the queue is sequential per snap
<jdstrand> yeah
<jdstrand> fwiw, it happens very rarely
<roadmr> jdstrand: so maybe the race was with another snap altogether, a revision for which was uploaded around the same time
<jdstrand> tbh, I can't remember the last time I had to do this
<jdstrand> (months?)
<roadmr> yes, it was maybe 3 months ago
<jdstrand> roadmr: fyi, when going through the backlog it got stuck on 586: "Could not find '/tmp/review-tools-nxy1gblo' msg"
<jdstrand> roadmr: I did not run it again in cause you want to investigate
<jdstrand> roadmr: https://dashboard.snapcraft.io/snaps/lxi-tools/revisions/586/
<roadmr> jdstrand: oh that's useful! let me see
<jdstrand> roadmr: our cleanup code is to remove stale review directories tha are older than 3 hours. I'm not sure how the parallelism works, but the logic is very simple-- time.time() - os.path.getmtime(d) > maxage: # 3 hours
<jdstrand> the logic in the review tools that is
<roadmr> jdstrand: so the only way that could happen is if two tools runs finish at almost the same time and try to reap the same dir, one of them would fail to find it and get that message
<jdstrand> roadmr: but, why would the dir be older than 3 hours in that case?
<roadmr> jdstrand: I'm assuming the dir to be reaped was created by a prior run
<roadmr> so: at 00:00, a run creates directory A
<roadmr> at 03:01 two runs finish at the same time, both run their reaper code, and identify A to be removed
<roadmr> but only the first one does, the second one will get "could not find A"
<jdstrand> right. that seems unlikely that ran A would take 3 hours longer to run than B
<roadmr> jdstrand: hm, but I'm assuming A ran quickly (maybe finished at 00:02) and left the directory there. Or do runs clean up after themselves too?
<roadmr> oh they do
<jdstrand> roadmr: they are supposed to cleanup after themselves
<ogra_> mvo, not sure you have seen it ... core x86 builds fail:
<ogra_> + grep -q bin/grub-editenv
<ogra_> + rm -f /.
<ogra_> rm: cannot remove '/.': Is a directory
<ogra_> E: config/hooks/15-remove-grub-common.chroot failed (exit non-zero). You should check for errors.
<jdstrand> roadmr: the reaper code is in case that didn't happen for some random reason
<ogra_> i guess the set -e shows now :)
<roadmr> jdstrand: indeed... hm
<jdstrand> roadmr: so, maybe it is that a run failed weird and didn't get cleaned. than later 2 different runs finish at the same time and try to clean it
<mvo> ogra_: aha, "great!
<mvo> ogra_: eh, "great" - this is the new "set -e" everywhere
<ogra_> yeah
<mvo> ogra_: I suspected this would cause some fallout
 * mvo weeps a bit 
<roadmr> jdstrand: yes, you expressed it more clearly, it's what I meant with my example
<ogra_> well, rm -f /. sounds weird anyway
<roadmr> jdstrand: oh mm..
<kalikiana> re
<roadmr> jdstrand: one thing that puzzled me is that your code seems to eat exceptions, so why is the message (which should be merely informative) cause the run to get stuck?
<roadmr> jdstrand: then I saw that the code does "except Exception"
<roadmr> jdstrand: but recursive_rm calls some methods which may raise OSError or IOError, which I remember from experience are sometimes not caught as Exceptions, need to be caught explicitly as IOError or OSError
<jdstrand> roadmr: the idea is that we don't want to traceback if something goes wrong with recursive_rm, and just report it
<roadmr> jdstrand: exactly, but the store is reacting as if the tools had exited with a bad error code
<jdstrand> roadmr: that is because we are gathering up any errors and shoving it into the json
<roadmr> jdstrand: haha wait - the reaper code never says "could not find". It says "could not remove"... so it's not a reaper race
<jdstrand> roadmr: if you recall, there were issues before if the output was not json
<roadmr> jdstrand: indeed - in that case the store said "unexpected output", which it isn't doing here... hmm
<jdstrand> roadmr: right-- I think we fixed almost all of those, but your remove vs find is key
<jdstrand> that could be a lot of things
<roadmr> jdstrand: "/tmp/review-tools-nxy1gblo" should be a directory, right? if so, it must be in common.py detect_package, "error("Could not find '%s'" % unpack_dir)"
<jdstrand> roadmr: I suspect it is detect_package() with the os.path.isdir()
<roadmr> \o/
<jdstrand> right
<roadmr> jdstrand and roadmr independently arrive at the same conclusion \o/
<jdstrand> there's some duplicate code in detect_package and init
<jdstrand> that shouldn't matter here, but I should fix that
<jdstrand> roadmr: you don't use bin/detect-package anywhere, do you?
<roadmr> jdstrand: nope!
<jdstrand> I'll probably just remove that then. I don't think anyone uses it and I can cleanup a little
<roadmr> yay :) less code is always better
<jdstrand> you will like when I rip out snapv1 and click code then :)
<roadmr> ohh yes
<roadmr> make sure to sloccount before and after
<jdstrand> hehe
<mup> PR snapd#4545 opened: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<mborzecki> niemeyer: 'Cannot allocate linode:arch-2017.07.01: no Linode image or distribution for "arch-2017.07.01"' the arch image is no longer available on linode?
<jdstrand> roadmr: I don't see an error in the code. it is as if after the unpack the dir disappeared. is there a fs issue? does the fs use dangerous mount options (eg, the unpack finishes but not syncd to disk)? this seems unlikely. I'll be adding some extra debugging information for next time
<jdstrand> I mean, I could be missing something, but the extra debug info will help with that
<jdstrand> roadmr: at this point, I'm inclined to run the reviews again and get this cleared out
<mup> PR snapd#4546 opened: snap: tidy up top-level help output <Created by cjwatson> <https://github.com/snapcore/snapd/pull/4546>
<roadmr> jdstrand: yes, I'd say that makes sense, until we have more debugging info/code
<roadmr> jdstrand: I found nothiing in the logs, but that's because the tools ran fine, they just reported this message as an error in the json, that causes the store to think there was a problem which gets the queue stuck
<jdstrand> roadmr: sure, that I understand. note that r575 didn't have an '!', it was the task state unknown. but I think we discussed that enough
<roadmr> yep... that one is weird :( I'll be really interested to see what the extra debugging code shows
<roadmr> jdstrand: oh wow so you unstuck 586 and 587 is now in the same boat
<roadmr> I reran automated review on that one
<kyrofa> cprov, bug #1745410, thank you!
<mup> Bug #1745410: Please further document ACLs <Snap Store:New> <https://launchpad.net/bugs/1745410>
<popey> diddledan: have you ever spoken to upstream irccloud about the desktop snap? Thinking we should upstream to get it out of snapcrafters and into their hands.
<diddledan> not yet. I'm reluctant while we're still suffering the chown to self problem because that's from a project upstream of them
<popey> Good point.
<diddledan> we're currently two releases behind because of that issue :-(
<popey> Maybe we can come up with creative solutions next week :)
<jdstrand> ikey: hey, so can you at a high level describe the intended architecture for the snaps? for example, what is declaring 'steam-support'? a launcher? games shipped as snaps?
<ikey> ah right ya
<ikey> so solus-runtime-gaming = runtime thing, basically solus's NIH core, linux-steam-integration is the "app" part which *depends* on that dude, and the whole thing together requires the permissions set in steam-support
<mvo> jdstrand: I addressed the point in 4073 and will do a followup with support for kdialog and xfce-dialog etc
<ikey> like there is no _provider_ as such, its "can haz permissions pls"
<diddledan> can I get some permissions, too, if we're handing them about freely? ;-p
<diddledan> preferably permission to something top secrit
<ikey> lol
<jdstrand> ikey: let me ask it differently. I'm a solus user and I want to play steam games. there is a steam snap that allows me to purchase games. if I buy a game, how do I then launch it?
<ikey> through steam
<ikey> all of it is running under the snap
<jdstrand> ok, so I always go through that thing that declares steam-support
<ikey> yeah
<jdstrand> and it launches the game
<ikey> there is no branching, just the toplevel steam process tree
<ikey> and any child nodes
<ikey> so its *effectively* all under a single confinement
<jdstrand> is it possible for that thing to launch games under a different apparmor profile?
<jdstrand> or is that the proprietary bit we don't control?
<ikey> proprietary
<ikey> **technically* its possible to cd into the dir and try to execute it yourself
<ikey> but "good" users of libsteam_api will fail here
<ikey> or reexec *under* steam
<ikey> so the moral is that steam client is boss and executor
<jdstrand> ikey: so the steam launcher will actually fork/exec the game (obviously). where are the executables it launches?
<ikey> they can be anywhere technically
<jdstrand> but not within the context of snappy
<ikey> either home or removable-media
<ikey> you'll notice that path addition for /media
<jdstrand> I did
<ikey> it also has its own helper binaries under its own core runtime tree
<jdstrand> so, do they ever end up in something 'steam-y'. eg, /home/user/Steam or /media/.../Steam?
<ikey> like steamwebhelper etc
<ikey> well this is the issue
<ikey> you have multiple sets
<ikey> there is no hard requirement for the steamapps path
<ikey> typically a game tree will contain steamapps/common/$NAME/
<ikey> like steamapps/common/Teeworlds
<jdstrand> what I'm pondering is that the launcher and the games themselves are really two different things, and so could in theory have different permission sets
<ikey> but the steam core itself has no such real organisation
<ikey> jdstrand, not entirely sure that would help you
<ikey> the steam api library in the client and games do much of the same stuff
<jdstrand> well, I'm not proposing it. I'm pondering it
<ikey> also many game launchers are basically full blown CEF applications
<ogra_> jdstrand, any idea why apparmor.service would take 1min to start (and stall the boot) https://paste.ubuntu.com/26459192/
<ikey> so they need as much (or more) support as the steam client itself does
<diddledan> I don't understand gnome-terminal.. I've snapped a replacement but when I launch it (it's in classic mode) it seems to decide I wanted to launch the one on my system instead of the one in the snap
<ogra_> (this is a single core imx6 ... 256M ram ... about beaglebone class HW)
<ikey> diddledan, gnome-terminal has a server running on dbus
<ikey> and will activate it on the session
<diddledan> ergh
<jdstrand> ogra_: let me get back to you. the obvious reason is the cache was invalidated and everything had to be recompiled. on an armhf device with lots of snaps, that could take a while
<diddledan> any way of telling it not to do that?
<ikey> no idea :/
<ogra_> jdstrand, only the obligatory core, kernel gadget installed :)
<ogra_> thats after a fresh install, no extra snaps
<ikey> jdstrand, i think one of the main reasons it would be so hard to split this profile up is the way in which steam client is implemented on linux
<ogra_> (but about the tenth boot so the cache should be there)
<ikey> its also a whopping great big cef app
<ikey> with a cluster of binaries *and* shell helpers and shell script init
<jdstrand> ogra_: there should only be a couple of profiles there. does rebooting help? (ie, the cache files are in place)
<ogra_> jdstrand, all reboots take about 2-3min no matter how often i reboot
<jdstrand> ikey: well, so, there were a bunch of shm accesses and the ptrace
<ikey> right
<ikey> ptrace happens with a whole bunch of feral titles
<ikey> and others
<jdstrand> ogra_: does /etc/apparmor.d/cache have anything in it? is the clock right?
<blackboxsw> hrm, anyone know how snaps which require --classic confinement can be seeded for snapd? https://forum.snapcraft.io/t/seed-yaml-documentation/3050/4
<ikey> and its not feasible for us to list path matches to every game using ptrace
<ogra_> the clock is right after network connects (no RTC indeed)
<jdstrand> ogra_: let me get back to you
<ogra_> yeah, take your time
<ogra_> ah, ineresting
<ogra_> ogra@localhost:~$ ls -l  /etc/apparmor.d/cache
<ogra_> total 0
<ogra_> i guess there is a prob with the kernel patches then .. thanks for getting me on the right track
<jdstrand> ogra_: that would explain why reboots aren't faster
<ogra_> yeah
<ogra_> funnily everything seems ot work as it should
<ogra_> *to
<jdstrand> still 1 minute for the few profiles is also pretty slow
<ogra_> well, it doesnt fill the cache ... note i'm logged in on a booted system
<ogra_> but the kernel is a pre-production thing with self-merged apparmor patches ... i bet there is something missing or broken
<jdstrand> ikey: so, just at a high level, it seems that some of the shm accesses are launcher specific. also, it seams that the launcher should be able to ptrace games, and games should ptrace themselves, but games shouldn't ptrace the launcher or other games
<jdstrand> it is also disappointing the 'm' is needed, but I suppose that is a steam thing
<ikey> yeah steam likes to map the shm
<ikey> the ptrace thing seems highly specific to child->parent relationship
<ikey> and we dont want it going outside that
<ogra_> hmm, or not ... on my pi's there is also nothing in /etc/apparmor.d/cache ...
<ikey> it does seem specific to the ones using CEF btw
<ikey> like Hitman Pro etc
<ikey> (i.e. AAAs)
<ikey> so it mightn't be such a game thing as a "they use chrome" thing
<jdstrand> ikey: it sounds like the CEF games are using the chromium setuid sandbox
<ikey> right but none of them are actually setuid
<jdstrand> curious
<ikey> mm
<jdstrand> they may have modified chromium
<ikey> very possible
<ikey> and mostly impossible for us to know sadly
<ikey> also they tend to have very ugly changing paths
<ikey> an example would be something like /run/media/bigdisk/games/steamapps/common/Hitman Proâ¢/blahblah/
<ikey> and they have spaces and unicodes and no fixed name for the main entries
<jdstrand> I'm not terribly worried about the ptrace and escaping confinement, because of what we said earlier about kernel version
<ikey> yeah
<ikey> the valve ipc objects initially i thought were private to the client but it turns out the libsteam api remaps (but not locks) from some games
<jdstrand> I don't care for the fact that an arbitrary steam game could ptrace the launcher and other steam games
<ikey> hm ok
<ikey> so how would we remedy that portion?>
<ikey> *?
<jdstrand> that is what I was pondering
<jdstrand> apparmor has the concept of child profiles
<jdstrand> if we could launch the game under the child profile, the launcher and the child could have different rules
<ikey> hm
<jdstrand> there are a lot of ways to pull that off
<mup> PR core#78 opened: 15-remove-grub-common.chroot: skip the first line in grub-common.list <Created by mvo5> <https://github.com/snapcore/core/pull/78>
<ikey> so the `capability sys_ptrace` would only be in the child profile?
<jdstrand> the launcher itself could use libapparmor to change_profile/change_on_exec. that won't happen though without crazy LD_PRELOAD or upstream support
<ikey> right and they'd kick off
<jdstrand> right
<jdstrand> so that is out
<jdstrand> if we know where the executables are, we can use banary attachment
<ikey> so can we do crummy path matching?
<ikey> if we just assume all steamapps/common/*
<jdstrand> eg, @{HOME}/Steam/** Cx -> steamgame,
<jdstrand> yes
<jdstrand> we could have as many of those as we want
<ikey> it looks like all of my test locations have that suffix
<ikey> i created 2 new libraries:
<ikey> 	"1"		"/home/ufee1dead/SteamLibrary"
<ikey> 	"2"		"/run/media/bigdisk/games"
<ikey> (on host)
<jdstrand> it doesn't seem terrible that the steam snap could be opinionated on where steam games live
<jdstrand> right
<ikey> and both definitely have steamapps/common/ as basedirs of games
<jdstrand> soso we could work with that (in theory)
<ikey> right
<ikey> so that means that when the launcher (or .sh entry or w/e) starts, its the new child profile there and can ptrace underneath, but not back up?
<jdstrand> the other thing is if the launcher uses a helper to do the launching, we have a child profile for the helper, and then the helper uses ix to launch anything
<ikey> there is absolutely no guarantee of any helpers
<ikey> they might have .sh or direct executable
<ikey> or hell even a .jar
<jdstrand> /path/to/helper Cx -> steamhelper, profile steamhelper { ... }
<ikey> like we dont ever know what the middleman is gonna be
<jdstrand> I don't mean the individual games. I mean the launcher itself is broken up into different executables
<jdstrand> *if* they had that architecture, we *may* be able to use a child for the helper instead of the path based stuff
<ikey> sure but typically its going to execute /bin/sh
<jdstrand> the launcher just fork/execs any random game thing?
<ikey> preeeeeetty much
<ikey> i mean this is the game industry
<jdstrand> ok, so that leaves only path-based matching
<ikey> i can show you strings for the libraries they use where they exec system("pulseaudio --check 2>/dev/null");
<ikey> (not even kidding.)
<ikey> they're not like us :p
<jdstrand> in your opinion, can the steam snap be opinionated in the locations of the games?
<ikey> i think it'll need to be
<ikey> i cant see evidence of a main launcher outside those paths for the games
<jdstrand> ok, that that gives us the option to explore the feasibility of a child profile
<ikey> the main client has all kinds of mad crap with various executables but that side doesnt need ptrace
<jdstrand> let me sketch something real quick...
<ikey> does a child profile automatically inherit the parent context?
<ikey> or actually ill not say stuff to distract you
<ikey> and reconvene shortly xD
<jdstrand> ikey: this is what I'm thinking about: https://paste.ubuntu.com/26459304/
<jdstrand> ikey: Cx doesn't inherit any apparmor rules. Cx (as opposed to cx) will allow most of the environ through, but LD_PRELOAD and glibc secure exec vars are scrubbed (cx doesn't do that))
<jdstrand> ikey: with that sketch, the games can be ptraced by the launcher but can't ptrace the launcher. it sounds like CEF would also need: ptrace (trace) peer=@{profile_name}, # allow ptracing one-self
<jdstrand> (that would mean all the steam games could ptrace each other though)
 * ikey clicks
<jdstrand> the question then becomes, is this added complexity doing anything meaningful?
<ikey> idk i mean its certainly managed to confuse me plenty
<kalikiana> another day going by, which feels much too short for the amount of work, *sigh*
<jdstrand> to be really useful, we'd need support from the launcher to launch games under individual profiles tailored to the game
<ikey> right
<ikey> which we're just plain and simple not gonna get
<ikey> in an ideal world we'd be able to install each game as a snap too..
<jdstrand> ikey: sorry. the idea is simple if the sketch isn't. the launcher runs under one profile and can do what it needs to launch games under the child profile. games run under a separate child profile from the launcher and have the perms to do just what they need
<ikey> so thats where we'd stuff the bits like mono shm etc?
<jdstrand> the question is then, is the intersection of the two profile basically entire and therefore there is no point in the exercise, or is it small enough to where teasing out the two is useful
<ikey> well my view is that if you tease out the two, you may as well tease the third
<ikey> the toplevel profile being basic stuff like vulkan, openal, that kinda cruft
<jdstrand> which is the 3rd?
<ikey> a child profile for the main steam client
<ikey> and then steam games
<jdstrand> I see
<ikey> so the client one could handle the mk differences on the IPC objects perhaps
<jdstrand> won't all games need vulkan, openal, etc?
<ikey> as well as only allowing the client binaries to touch the executable file on removeable-media
<ikey> right but couldnt the two child profiles inherit the top profile?
<ikey> as a common thing
<ikey> so the commonality would be in the main top profile
<jdstrand> lets not use the word 'inherit' but yes, we could do that fine
<ikey> and then specialise in the child profiles
<ikey> well, inherit/clone
<jdstrand> (inherit has a very specific meaning in apparmor)
<ikey> ah
<ikey> like this one would be explicitly for the client: /run/media/**/.steam_exec_test.sh ixmrw,
<jdstrand> we are taling about Cx rules here. that changes to a child profile. most rules you are probably used to are ix rules, which inherit the parent profile
<ikey> right
<jdstrand> anyway, let's skip all that exec transition discussion for now :)
<ikey> i did see some comments in browser-support suggesting the idea of child profiles but it was commented out
<jdstrand> ikey: just so terminology is correct, when you say 'client', it is what I've been referring to as the 'launcher', yes?
<ikey> i would imagine so
<ikey> the main Steam UI
<jdstrand> yes
<ikey> store/make games open
<jdstrand> ok
 * jdstrand nods
<jdstrand> the client wouldn't have ix rules, it would have Cx (possibly cx) rules
<jdstrand> /run/media/**/.steam_exec_test.sh Cxr -> steamgame,
<ikey> ok so that effectively changes the profile to "steamgame" if im interpreting right?
<jdstrand> profile steamgame {} would have ix rules so anything it executes would be under the 'steamgame' profile
<ikey> so it would "lose" anything defined in the main profile..?
<jdstrand> yes
<ikey> so perhaps my approach is a bit over complicated then
<jdstrand> the child profile allows us to start from scratch to build up a profile specific for games
<ikey> right
<jdstrand> we are free to use #include directives or share policy with snapd to insert common rules into it
<ikey> oh ok
<ikey> yeah i was pondering there the duplication aspect
<jdstrand> if it makes sense to create a little helper in the .go file to splat out common rules for the client and the game, that's totally fine
<ikey> right so that'd handle the runtime bits like openal/ pci, etc
<ikey> and then specialise on the path
<jdstrand> how that is implemented in code don't worry about. assume we can do what we want when building up the client and the steamgame profiles
<ikey> right
<ikey> so i mean that approach then "solves" (4.8+) the gaping hole that is ptrace?
<jdstrand> it makes it better
<ikey> because it does seem "wrong" that games can have the same permissions as the parent launcher, like writing the executable .steam_exec_test.sh ..
<jdstrand> I mean, 4.8+ means that neither the client nor the game can escape the seccomp sandbox
<ikey> right
<jdstrand> that is the real gaping hole
<ikey> and we dont want them ptracing *each other* for the icing on the cake
<jdstrand> the other bits are extra hardening to separate games from the client
<ikey> which, if we were valve, we'd kinda want
<ikey> to protect us from bad actors
<jdstrand> I would think so
<jdstrand> right
<mup> PR snapd#4547 opened: snap: fix race in `snap run --strace` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4547>
<jdstrand> what this scheme doesn't do is spearate games from each other
<ikey> ok so then we'd also want to specialise the shm paths
<ikey> yeah
<ikey> all games have the same level of access..
<ikey> which, without some level of magic client support, i dont think we could achieve..
<jdstrand> we could probably come up with something for that, but I'd like to explore the client from the games more, and if feasible, even implement that first and see if we can isolate games from each other
<jdstrand> well
<jdstrand> we could do some crazy stuff
<jdstrand> (I suspect)
<ikey> i agree protecting the client is likely the most important aspect
<ikey> given that it does store-like-things
<ikey> and credit cards
<jdstrand> where we allow the client profile to load apparmor policy, and we derive profile names from fs paths to launch clients under separate profiles
<jdstrand> but, let's not go there now
<ikey> oO
<ikey> future wizardry++
<jdstrand> maybe*
<ikey> lol
<jdstrand> really the client needs to do this rather that hackery around it
<ikey> yeah
<jdstrand> but, we're creative folks ;)
<ikey> :D
<jdstrand> anyway
<jdstrand> ikey: do you feel like two profile approach (client vs child game) would provide a meaningful benefit?
<jdstrand> assuming 4.8 kernel is in place
<ikey> well i mean you're the security guy, would that be your recommendation?
<ikey> because if it does provide real world benefit then we should
<jdstrand> I like that games can't ptrace the client a lot. like you said, the client takes payment info, etc
<jdstrand> that *alone* is probably worth it
<ikey> the following scenario is totally possible: game gets greenlit on steam, hijacks the root ppid memory, and scans for credit cards
<ikey> unity asset flip then makes real money
<jdstrand> if we can do bits with shm access to make it better, that is a bonus
<ikey> right
<jdstrand> ok
<ikey> so we allow the client / launcher to create the shm
<ikey> and the games to map and read
<ikey> or whatever stops it crashing locally when i do it
<jdstrand> heh
<ikey> so the path if it *doesn't* match, i keep my local ix?
<ikey> otherwise i go Cx and redo inside that profile..?
 * ikey might be butchering terminology slightly here
<ikey> and fwiw it seems silly for us to avoid what the sandboxing can offer ^^
<jdstrand> in essence, yes, but we might have to do some weird stuff to avoid 'conflicting x modifiers'. I'd like to shield you from that, so I'd like to work up a test snap and then give you the rules for the Cx/ix
<ikey> oh, that'd be fantastic, ty
<jdstrand> ikey: this is my idea. I create a little test snap that has a 'launcher'. the 'launcher' plugs home and removable-media. the launcher is allowed to Cx to ~/SteamLibrary/where? and /media/where?
<ikey> well SteamLibrary was just a sample path
<ikey> technically its ~/**/steamapps/common/** and /run/media/**/steamapps/common/**
<jdstrand> just give me the path in home and /media you'd like to use
<jdstrand> ok
<ikey> our launcher im gonna have to figure out technically exactly where it lives and how ~ expands
<ikey> as LSI modifies ~
<ikey> we use SNAP_USER_COMMON as our root
<ikey> basically to prevent against gigs of data being shuffled around on each snap update
<niemeyer> Saviq: Can you please give it a shot now?
<ikey> so my full host side path would be /home/ufee1dead/snap/linux-steam-integration/common/.local/share/Steam
<jdstrand> so what is ~/**/steamapps/common/** more specifically? @{HOME}/snaps/${SNAP_NAME}/common/steamapps/common/** ?
<jdstrand> ok
<jdstrand> /home/ufee1dead/snap/linux-steam-integration/common/.local/share/Steam
<jdstrand> and what about a full path in /media?
<ikey> '/run/media/bigdisk/games/steamapps/common/DiRT Rally/bin/DirtRally'
<jdstrand> interesting
<jdstrand> so *not* /run/media/USERNAME/bigdisk/...
<ikey> everything before "steamapps" is my own pathing
<jdstrand> yeah
<ikey> right its a static fstab
<jdstrand> ah
<jdstrand> ok
<ikey> i think there is some notion of /{run,}/media/**/steamapps/common/** needed
 * ikey cant mentally shell expand atm
<jdstrand> ikey: alright, I'll work through this a bit and comment in the forum. then you can play and hopefully be able to update the PR, at which point we can iterate in the PR
 * jdstrand nods
<ikey> yeah that sounds great to me, thanks
<jdstrand> yw
<ikey> like these are my last big blockers
<ikey> full confinement to unbreak it, and then controllers
 * jdstrand nods
<ikey> then tada leave edge
<jdstrand> sorry for the delay. I knew I needed both time and you to be able to respond intelligently
<ikey> yeah thats why i did the forum post approach originally, cuz i even said theres no way it could go in without discussion
<ikey> it had to be properly thinkerised
 * ikey isn't a security guy either so will happily rely on others expertise
<mup> PR snapd#4548 opened: spread: reduce linode plan size too see impact <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4548>
<ogra_> ppisati, still around ? ... if i have "kdefconfig: [xxx_defconfig, snappy/generic.config, snappy/security.config, snappy/systemd.config, snappy/snappy.config, snappy/containers.config]" and have conflicting settings in one f the snappy ones (vs xxx_defconfig), will they override ? i.e. are the configs processed in the order they are listed there .... left to right ?
<niemeyer> Saviq: Looking good: https://travis-ci.org/MirServer/mir/jobs/333310160
<Saviq> niemeyer: yeah, if only travis showed me the jobs...
<niemeyer> Saviq: Hm?
<Saviq> there we go
<niemeyer> Saviq: Doesn't it?
<Saviq> it was just hanging there with the animated dots
<niemeyer> Ah :)
<ogra_> slow javascript is slow ;)
 * Saviq restarted the remaining jobs, let's see
<Saviq> niemeyer: it does look much better indeed
<niemeyer> Saviq: I think the concurrency issues are sorted, but I've fiddled quite a bit, so please let me know if you see any extraneous behavior
<Saviq> ack!
<Saviq> thansk!
<Saviq> thanks, even!
<jdstrand> mvo: ok, reviewed your changes: https://github.com/snapcore/snapd/pull/4073#pullrequestreview-91614503
<mup> PR #4073: snap: add io.snapcraft.Settings to `snap userd` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4073>
<niemeyer> Saviq: np
<roadmr> hey folks, where can I find docs on snapd's local API?
<sigise> Is there a portable/bootstrap install of snapd?  The distro I use, openSUSE, is packaging old versions, and not responding to requests to update.  I'd rather use an upstream solution, but afaict, there's no "portable installer" at https://docs.snapcraft.io/core/install .
<sigise> Is the only option to DIY build?
<mup> PR snapd#4548 closed: spread: reduce linode plan size too see impact <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4548>
<kyrofa> sigise, that's probably a question for zyga-ubuntu
<sigise> kyrofa: thx zyga-ubuntu ping
<sergiusens> zyga-ubuntu mvo how many times can I plug with the content interface inside a snap?
<sergiusens> hoping for the answer to be N, where N > 1
<zyga-ubuntu> sergiusens: eee, yes
<zyga-ubuntu> sergiusens: especially since like yesterday
<zyga-ubuntu> sergiusens: when improved c-i got merged
<zyga-ubuntu> sergiusens: but not until 4471
<sergiusens> zyga-ubuntu so not on 2.30?
<zyga-ubuntu> sergiusens: which is the mechanism for the policy
<zyga-ubuntu> sergiusens: you can on 2.30 but it will do useless things
<sergiusens> hmm, so mid week maybe? We have interesting use cases; is this avail on edge or will it be by Monday at least?
<zyga-ubuntu> sergiusens: in rc2 it will be auto-aggregating as subidrs
<zyga-ubuntu> sergiusens: by monday likely
<zyga-ubuntu> or just merge 4471
<sergiusens> zyga-ubuntu great, do we have docs for this behavior somewhere?
<sergiusens> zyga-ubuntu I have an ISV really interested in this working
<sigise> zyga-ubuntu: ping again
<roadmr> jdstrand: hi! we added this new common-id field (https://forum.snapcraft.io/t/support-for-appstream-id/2327/18) but need the reviewer tools to be aware of the field, otherwise any snap using it will be rejected :(
<jdstrand> roadmr: ok, I'll add that for the next pull
<zyga-ubuntu> sergiusens: some in the forum but I will update the main content iface docs once it lands
<zyga-ubuntu> sergiusens: and I have pending forum post about it,
<zyga-ubuntu> sergiusens: what is the use case?
<roadmr> thanks jdstrand !
<mup> PR snapcraft#1881 closed: elf: better handling for newer libc6 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>
<mup> PR core#78 closed: 15-remove-grub-common.chroot: skip the first line in grub-common.list <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/78>
<mup> PR snapcraft#1885 opened: Release 2.39 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1885>
#snappy 2018-01-26
<diddledan> kyrofa: I like the "potentially bonkers" comment :-D
<diddledan> I'm sat here giggling to myself over that :-p
<mup> Bug #1745528 opened: snap icon available <Snappy:New> <https://launchpad.net/bugs/1745528>
<bashfulrobot> Anyone around for a few (hopefully) quick questions?
<bashfulrobot> If not, I'll pop back in the AM (PST).
<bashfulrobot> TY
<ikey> mornin
<mborzecki> morning
<zyga-ubuntu> good morning
<zyga-ubuntu> FYI, I need to take today off,
<zyga-ubuntu> last day of winter holidays for kids and I need to spend some time with them
<mup> PR snapd#4532 closed: store: use the "publisher" when populating the "publisher" field  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4532>
<mborzecki> zyga-ubuntu: hey, morning
<zyga-ubuntu> hey!
<zyga-ubuntu> I slept for hoooours
<zyga-ubuntu> I woke up later at night and just briefly wandered here
<mborzecki> yeah, today is monday you know? :)
<zyga-ubuntu> man, I missed that sleep
<zyga-ubuntu> haha!
<zyga-ubuntu> good one :) I tried to fool our daughter a moment ago
<mborzecki> haha
<mborzecki> my kids are starting the break on monday ;)
<zyga-ubuntu> oh, right :)
<mborzecki> zyga-ubuntu: btw. sent you a small PR for snapd aur package: https://github.com/bboozzoo/aur-snapd/pull/1, nothing fancy
<mup> PR bboozzoo/aur-snapd#1: snapd: fix generation of systemd unit files, use /etc/default/snapd as environment file <Created by bboozzoo> <https://github.com/bboozzoo/aur-snapd/pull/1>
<zyga-ubuntu> looking
<zyga-ubuntu> done
<mborzecki> zyga-ubuntu: can you belive that indent is no longer package in arch?
<mborzecki> i played with arch CI yday and i was like 'wtf?' when it failed on installing indent
<zyga-ubuntu> mborzecki: indent is a weird tool, I'd like to migrate away from it
<zyga-ubuntu> and use clang-format
<zyga-ubuntu> not only more widely available but much better output
<mborzecki> zyga-ubuntu: briefly thought about dumping autotools in favor of cmake or meson, though the latter is not availble in 14.04 :/
<mborzecki> `yaml.reader.ReaderError: unacceptable character #xdce2: special characters are not allowed` on arch tests/main/snap-info
<zyga-ubuntu> mborzecki: I cannot stand cmake syntax, I think ultimately what we have is bad but the alternatives are not widely available or are not fantastically better
<zyga-ubuntu> mborzecki: that's a curious one
<zyga-ubuntu> I ran into it 100s of times
<zyga-ubuntu> but it's a race somewhere
<zyga-ubuntu> memory is corrupted
<zyga-ubuntu> I dumped the yaml text when this happened
<zyga-ubuntu> and I got random stuff all the time
<zyga-ubuntu> it only ever surfaced on arch
<zyga-ubuntu> perhaps due to a combination of compiler settings not used by other distributions
<zyga-ubuntu> I didn't get to the bottom of it
<zyga-ubuntu> try printing the buffer, I'm curious what you will get
<mborzecki> zyga-ubuntu: found a related debian bug reported by Chipaca https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806826
<mborzecki> anyways, reading the patch explains why pretending we're using a utf8 locale fixes the problem
<mborzecki> `LC_ALL=en_US.utf8 python3 check.py < out` works just fine
<zyga-ubuntu> mborzecki: how does python come into the picture?
<zyga-ubuntu> mborzecki: I thought this was from golang
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> mvo: I'm off today
<zyga-ubuntu> need to leave in a few minutes anyway
<mborzecki> zyga-ubuntu: no it's python3, there's a check.py script in tests/main/snap-info, we basically dump `snap info` output and then verify it with the script, and it chokes on the unicode up arrows
<mvo> zyga-ubuntu: hey, enjoy your day off
<mborzecki> i still think that we should not produce any unicode output if locale does not support unicode
<mvo> mborzecki: not knowing much context I agree
<mvo> mborzecki: but that seems to be a broader issue, iirc our progress is also quite liberal with non ascii chars
<mborzecki> mvo: the tests are using LANG=C.UTF-8 which is in a patched glibc, this does not work on arch, so the default ends up being C, `snap info` uses unicode characters in the output, the script checking `snap info`'s output is python3 which does magic behind the scenes depending on your locale, part of it i have already fixed, the other part makes pyyaml throw an exception when reading yaml input (ie.. snap info
<mborzecki> output dump)
<zyga-ubuntu> mborzecki: not the same bug then
 * zyga-ubuntu -> afk
<mborzecki> zyga-ubuntu: not exactly, the patch does more than is written in the bug report :P
<mvo> mborzecki: right, yeah, python is unhappy if the encoding does not match, I'm not surprised. a shames that C.utf-8 is not standarized
<mborzecki> pstolowski: morning
<pstolowski> hey!
<kalikiana> o/
<kalikiana> morning, mborzecki
<mborzecki> kalikiana: hey
<Chipaca> mo'in
<ikey> rawr
<Chipaca> if you say so
<mvo> hrm, hrm, looks like master is broken right now
<mvo> search test failing
<Chipaca> mvo: D:
<mvo> Chipaca: unless you are looking into this already I will do so now
<Chipaca> mvo: I was not
<mborzecki> store related tests are randomly failing?
<mup> PR snapd#4549 opened: tests: update "searching" test to match store changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/4549>
<mvo> mborzecki: hopefully not randomly but yes, everything is broken right now
<mvo> mborzecki: see PR above
<mborzecki> mvo: i've restarted #4487 5-6 times already, not counting the searching thing, there's failures in fetching snaps (either in prepare, or some refresh tests)
<mup> PR #4487: cmd/snap: snap refresh --time with new and legacy schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
<mvo> mborzecki: oh, more? sucks
<mvo> mborzecki: sounds like a reason to talk to the good people from the store team :)
 * mvo looks at the results
<mborzecki> mvo: regarding 4549, database is no longer listed in sections :/ any clue why?
<mvo> mborzecki: yeah, I just talked to the store team - it just got removed, there is a set of new sections
<mborzecki> hm can they confirm that all the sections are listed in `snap find --section`?
<mvo> mborzecki: I think that is the case
<mvo> mborzecki: in your current run it is just "searching" what failed so far
<mvo> mborzecki: so fingers crossed :)
<mborzecki> mvo: btw: maciek@corsair:github.com/snapcore/snapd (git)-[master] ./test-snap find --section=foobar
<mborzecki> No matching snaps for ""
<mvo> yeah, we should tweak the error
<mvo> to include that the search was in a section
<mborzecki> mvo: i can look into it
<mvo> and/or show that there is no such section
<mvo> not sure what metadata we get from the store
<mvo> thanks mborzecki
<Deknos> aloha, is there a bugtracker for snaps anywhere?
<Deknos> i tried minikube and kubectl snaps on ubuntu 17.10 and debian, but it did not work. manual installation works, though. any idea how to write a issue/bug for snap?
<mvo> Deknos: is this a issue with the snaps themself? or an issue with the snapd, i.e. can you not use any snaps on your system? if the former, there is a "contact" field in the "snap info" output that you can use to get in touch with the snap provider
<mvo> Deknos: there is also forum.snapcraft.io where a lot of the snap developers hang around
<Deknos> well it seems to have to do sth with the installation since manual installation works, but via snaps setup of the vms crash
<Deknos> thanks, i'll try the forum.
<mup> Bug #1669012 changed: Can't reinstall a snap already installed switching confinement mode <amd64> <apport-bug> <xenial> <snapd:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1669012>
<mvo> Deknos: good luck!
<mborzecki> mvo: do you think a separate error message if no matches in section were found makes sense? https://paste.ubuntu.com/26463360/
<mvo> mborzecki: this looks good to me
<mborzecki> mvo: well i'm counting on sections being cached (which they seem to be) as this does an additional cli.Sections() call :)
<mup> PR snapd#4549 closed: tests: update "searching" test to match store changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4549>
<niemeyer> Mornings
 * ikey plays "Walking on sunshine" in response to "morning"
<niemeyer> ikey: I don't think I had ever seen that
<ikey> https://www.youtube.com/watch?v=iPUmE-tne5U
<ikey> ^^
<ogra_> â¬ âªâ©â¬
<mup> PR snapd#4550 opened: cmd/snap: improve output when snaps were found in a section or the section is invalid <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4550>
<niemeyer> ikey: Yeah, I just watched it.. not sure what to take from it.. my life will probably never be the same again
<ikey> most welcome lol
<ikey> so i tried jdstrand's recommendations this morning with snapd/apparmor
<ikey> apparmor was most unhappy
<ikey> gonna have to bite the bullet and just suck it up with the whole 4.8 requirement
<ogra_> niemeyer, would you mind adding a "yes this is right/no, nonsense" answer to https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675 ?
<niemeyer> ogra_: Will have a look
<ogra_> thanks
<niemeyer> mborzecki: About your question on arch yesterday,
<niemeyer> mborzecki: we never had our own arch image, I believe
<niemeyer> mborzecki: What likely happened was that you were using an arch image provided by Linode, which was obsoleted
<mborzecki> niemeyer: yes, that was the case, fortunately spread -vv contains all the info about machine templates i need ;)
<niemeyer> mborzecki: I find a bit surprising to be honest
<niemeyer> mborzecki: I mean, anyway using that image is now broken
<niemeyer> anyone
<niemeyer> Looking at https://www.linode.com/distributions, the current one seems to be 2018.01.02
<mborzecki> niemeyer: switched to that version already
<cachio_> mvo, https://paste.ubuntu.com/26461903/ https://paste.ubuntu.com/26461941/
<cachio_> mvo I see those errors on rpi2 and 3 when I refresh from stable to beta
<mvo> cachio_: thanks, looking
<mvo> cachio_: *hrm* smells like an issue with writable-path, let me dig
<mvo> cachio_: out of curiosity, this did not happen on an x86 core device?
<cachio_> mvo, no
<cachio_> mvo, just on the pi
<mvo> interessting
<mvo> cachio_: and you said you refreshed from the previous stable, correct? a fresh image from stable and then refresh to beta?
<cachio_> mvo, I used the stable from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
<cachio_> mvo, the factory one
<mvo> cachio_: thank you, I give it a go
<Chipaca> I'm not going to be here for the standup; I'm off to a school meeting (that'll probably extend into the afternoon) (I'll retroactively file for pto if it does)
<mvo> Chipaca: thanks and see you
<Chipaca> mvo: still here for another little while though :-)
<Chipaca> meeting is 13:30, google says 30 minutes of driving (but midday rush is a thing)
<mup> Issue snapcraft#1886 opened: Support for yarn --extra-args <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1886>
<mvo> cachio_: confusing, I just did install of the stable image, refreshed mnaully to beta rebooted and systemctl list-timers hows me the timer
<mvo> cachio_: can you ssh into the board and run "systemctl list-timers --all" and paste that please?
<cachio_> sure
<mup> PR snapd#4551 opened: interfaces: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<cachio_> mvo, https://paste.ubuntu.com/26463820/
 * kalikiana going to go for an earlier lunch in a few
<mup> PR snapd#4552 opened: testutil: do not use echo for printing potentially conflicting arguments <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4552>
<mvo> cachio_: hm, how strange. in a meeting now, lets talk in a bit
<cachio_> mvo, np
<mup> PR snapd#4547 closed: snap: fix race in `snap run --strace` <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4547>
<ikey> will we have a jdstrand around today? primarily so i know in order to get my best begging face on
 * ikey readies a spray bottle for the fake tears
<diddledan> ikey: https://youtu.be/elmwnUOtxu8?t=76
<ikey> hah perfect
<mvo> cachio_: what is the output of "systemctl status snapd.snap-repair.timer" on the pi2?
<mvo> cachio_: (or pi3)
<pstolowski> cachio_, do you have any gsettings branch I can look at? or can describe the test case you want to achieve?
<cachio_> https://paste.ubuntu.com/26464226/
<cachio_> pstolowski, yes, on sec
<cachio_> pstolowski, https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings
<cachio_> there is a snap already uploded to the store
<cachio_> mvo,  https://paste.ubuntu.com/26464226/
<pstolowski> cachio_, thanks, i'll have a lunch now and will take a look afterwards
 * pstolowski lunch
<cachio_> pstolowski, sure, just ping me
<mvo> cachio_: thanks, I'm on it
<mvo> cachio_: I think I found the issue and pushed a fix to the core build, will be part of ~rc2
<mup> PR core#79 opened: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink <Created by mvo5> <https://github.com/snapcore/core/pull/79>
<cachio_> mvo, great
<cachio_> mvo, which is the problem that you found?
<mvo> cachio_: its a problem with the writable-path stuff: https://github.com/snapcore/core/pull/79/commits
<mup> PR core#79: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink <Created by mvo5> <https://github.com/snapcore/core/pull/79>
<cachio_> mvo, ohh, tx
<kalikiana> kyrofa: Hey
<kalikiana> kyrofa: Can I pick your brain on the checker callable used in the grammar? I was looking into "to" for strings, ie. the source property, and it adds ":armhf" and such because ToStatement doesn't know about packages or other properties
<kyrofa> kalikiana, hahaha
<kyrofa> Yeah we probably don't want that eh?
<kyrofa> kalikiana, do you want to HO?
<kalikiana> kyrofa: Yeah, we can have a quick chat now if you have time
<kyrofa> kalikiana, I do
<kalikiana> kyrofa: Shall we use the weekly?
<kyrofa> weekly?
<kyrofa> Yep
<kyrofa> Oh wait, no
<kyrofa> kalikiana, any chance you have skype?
<kyrofa> I'm so stinking sick of chrome
<kalikiana> kyrofa: I'm seeing a trend here :-D
<kyrofa> Let's use that. Or talky
<kyrofa> Is talky better?
<kyrofa> I really don't care. Just something that doesn't require me to open chroem
<kalikiana> kyrofa: Either one works for me
<kalikiana> lol
<kyrofa> Let's try talky. Hold on
<pstolowski> cachio_, test-snapd-gsettings is the snap you meant?
<cachio_> yes
<cachio_> pstolowski,
<pstolowski> cachio_, oh wow, that snap is huge
<cachio_> pstolowski, yes :s
<pstolowski> cachio_, I see more plugs than just gsettings in its snap.yaml; is this intended to be used for many tests?
<cachio_> it is pluggin also desktop
<cachio_> pstolowski, it is because it needs to access to destop files
<bloodearnest> hey folks, is there any way to call setuid() at all from a strictly confined snap? E.G. to switch to the 'daemon' or 'nobody' user, which is in the core snap, I don't need to create a user (just can't run as root)
<mup> Issue snapcraft#1887 opened: Update to ROS2 Ardent <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/1887>
<bloodearnest> I thought there was some seccomp/apparmor provision for this, but I can't find any documentation on it
<kyrofa> bloodearnest, no, it's in the design phases as I understand it, jdstrand will know more/all
<pstolowski> cachio_, I think you could get rid of python-gi dependency (which already pulls a lot of stuff). glib comes with a gsettings cli that can query and set settings db
<pstolowski> kyrofa, hey, where can I lookup the definition of desktop-gtk3 part? I knew it but forgot..
<kyrofa> pstolowski, snapcraft define
<kyrofa> pstolowski, or do you want to update it?
<pstolowski> kyrofa, no, just check it out
<kyrofa> Yeah, that should work
<pstolowski> kyrofa, thanks!
<jdstrand> bloodearnest: not yet. it is on the roadmap. I suggest you keep an eye on https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
<bloodearnest> kyrofa: jdstrand: ok, thanks
<bloodearnest> fwiw, this make squid and postgres very difficult to run, as they both refuse to run as uid 0
<jdstrand> bloodearnest: note this is something I'd really like to see done, but it isn't prioritized high atm. the design is there and approved (which is good), but it is slow going
<jdstrand> bloodearnest: but we'll get to it
<jdstrand> bloodearnest: I think someone posted in the forum what to do with postgresql
<jdstrand> bloodearnest: there is also the snapcraft preload plugin which LD_PRELOADs to make them no-ops
<jdstrand> but like you say, the correct thing is to have this support. we'll get there
<cachio_> <cachio_> pstolowski, ok, I'll try that
<cachio_> <cachio_> pstolowski, apart of that, any idea about hot make it work on linode?
<cachio_> <cachio_> it was failing trying to create many directories
<cachio_> <cachio_> but then can't access to the gsettings user keys
<cachio_> <cachio_> it is just reading the values that come inside the snap
<cachio_> <cachio_> but when I try to update and see the change, the values have not been changed
<pstolowski> cachio_, and you depend on desktop-gtk3 path to have the entire environment and schemas set, correct?
<bloodearnest> jdstrand: ok, I'll check the forums for that. I don't think the preload plugin helps here - postgres has a hard coded if (geteuid() == 0), it doesn't try to drop privs itself, but forces you to do it
<cachio_> pstolowski, I got disconnected, sorry
<cachio_> pstolowski, yes
<jdstrand> bloodearnest: someone specifically patched postgresql for the postgresql snap
<cachio_> I copied that from the gnome-calculator app
<jdstrand> bloodearnest: so yes, you might have to patch. for now. but we'll get there
<pstolowski> cachio_, so I think you should try to remove it as it pulls half of the desktop stuff obviously, and take a look at https://github.com/Ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports
<pstolowski> cachio_, this is part of the desktop-launch script afaict
<pstolowski> cachio_, look at the gsettings stuff there
<pstolowski> cachio_, you can basically replicate it
<cachio_> pstolowski, ok, but the problem is that all the desktop part is not in the linode images
<cachio_> pstolowski, so, the mappings in this script don't work
<pstolowski> cachio_, yeah but we don't need it afaict
<blackboxsw> pedronis: hi any suggestions on https://forum.snapcraft.io/t/seed-yaml-documentation/3050/4     maybe --classic snaps can't be seeded ?
<pstolowski> blackboxsw, he is off, back next week
<blackboxsw> ahh excellent pstolowski thanks for the heads up
<cachio_> pstolowski, ok, I'll try to clean this but first I need to figure out how to fix the current issue
<cachio_> pstolowski, for example
<pstolowski> cachio_, afaiu the snap should have glib as the base dependency. all the schema stuff is build in $SNAP_USER_DATA/.local/share (we should replicate this part of the script)
<pstolowski> cachio_, and the test could use gsettings binary from the snap, no custom python to query gsettings data
<pstolowski> cachio_, we should be able to test gsettings with just cli tools, no need for gtk and all the desktop stuff
<cachio_> pstolowski, ok, I'll try this
<pstolowski> cachio_, i'm not sure about the dconf part of the interface, it has a dbus snippet
<pstolowski> cachio_, there is a dconf binary that can also query settings. but i don't know if it touches dbus
<cachio_> pstolowski, no idea
<ikey> so jdstrand to clarify, how am i going to move forward with the steam thing?
<pstolowski> cachio_, if not, then we can use dbus-send cli or something else (not to pull python)
<ikey> cuz that much i failed as yet to discern
<ikey> but gathered "pending voodoo" being the trend
<pstolowski> cachio_, well, just the bare python itself is not too bad, problems start when we pull too much stuff
<cachio_> pstolowski, yes, agree
<cachio_> pstolowski, I tried to simulate what the desktop team do but it is so complex for our tests
<jdstrand> ikey: I'd like to get some feedback on cx vs px. I also want to come up with the rules to give you, then tell you the course forward
<jdstrand> ikey: I have some work to do to give you all that
 * jdstrand is in meetings today, but hopes to pick this up this afternoon
<pstolowski> cachio_, $SNAP/usr/bin/gsettings cli is a good enough test as it uses the same glib API that gui apps would use
<pstolowski> cachio_, but as I say I don't know about the dbus part of the policy for dconf and what would be a good test for it (other than sending a dbus message manually with dbus-send or some such), perhaps someone from desktop team can explain
<ikey> jdstrand, ok
<ikey> i think ill have to pull my snaps out of the store
<ikey> as i cant update them
<jdstrand> ikey: ? why?
<cachio_> pstolowski, ok, I'll start researching on this
<ikey> because to develop them any further i need working strict confinement, and they're bugged out in their current state
<ikey> and nobody else will have the interface they need to run them properly
<ikey> etc
<jdstrand> ikey: you could set 'grade: devel' and not push them to stable
<ikey> ive not pushed to stable
<ikey> because of my permanent chicken / egg cycle with this snap :P
<jdstrand> I don't know if that is helpful or not, but an option
<ikey> basically because i cant update them i cant testify to their security status
<ikey> and would be more comfortable with withdrawing them entirely
<ikey> as it reflects poorly on solus
<cachio_> pstolowski, another question
<cachio_> pstolowski, https://paste.ubuntu.com/26465150/
<cachio_> hidraw should be just for gadgets?
<jdstrand> well, regardless, I'll be working on this to give you what you need
<cachio_> pstolowski, or it should be visible in any core?
<cachio_> pstolowski, based on that declaration
<mup> PR core#79 closed: 26-fixup-core.chroot: fix snapd.snap-repair.timer enable symlink <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/79>
<ikey> jdstrand, how would i go about unpublishing snaps..?
<ikey> if such a concept exists
<ikey> alternatively ill refresh the snaps without any of the new interfaces.. but ofc they remain broken
<ikey> this is too much thinking for a friday -_-
<jdstrand> ikey: I'm not sure tbh. perhaps roadmr or sergiusens can comment?
<ikey> what would need to be done on your side out of interest?
<ikey> re: enabling the globbing stuffs
<pstolowski> cachio_, this declaration says the slot can be on gadget or core, but i've no idea whether this is correct or not
<roadmr> ikey: the best way IIRC is to push a new snap and release that to the channel where the snap-you-want-unpublished is
<roadmr> ikey: effectively superseding it really. Once it's not published on any channels, it'll be uninstallable for anyone, not even by specifying --revision
<ikey> i mean like all revisions
<roadmr> ikey: oh like just removing them from existence entirely? I don't think that can be done :( sorry
<ikey> ah ok
<roadmr> ikey: another way is to close all channels. snapcraft close stable
<ikey> so ill need to push a gimped build then
<ikey> roadmr, unfortunately i dont have a stable channel
<roadmr> same for beta, edge, candidate.
<roadmr> ikey: if the snap is on e.g. edge, you can close that too
<ikey> ok ty
<mup> PR snapd#4553 opened: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4553>
 * kalikiana going to wrap up for the week shortly
<pstolowski> eow, o/
<mup> PR snapd#4554 opened: test build - ignore <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4554>
<cachio_> ogra_, hey
<cachio_> could you please confirm if the hidraw interface is available on any core device
<cachio_> ogra_, this is the declaration https://paste.ubuntu.com/26465150/
<mup> PR snapd#4553 closed: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4553>
<mup> PR snapd#4554 closed: test build - ignore <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4554>
<mvo> cachio_: I get dinner now, but the failure in 4073 is strange still :/
<cachio_> mvo, checking
<mup> PR snapd#4538 closed: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <Closed by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538>
<ogra_> cachio_, nops, uhid is there but not hidraw
<ogra_> cachio_, so core does not have it declared atm
<ogra_> (the core snap that is)
<cachio_> ogra_, ok
<cachio_> ogra_, tx
<ogra_> s/declared/exposed/
<ogra_> np
<cachio_> ogra_, not sure why not
<cachio_> ogra_, it should
<ogra_> ogra@localhost:~$ snap interfaces|grep hid
<ogra_> :uhid
<ogra_> well, thats what i get
<ogra_> (on all core devices running here)
<niemeyer> This is looking smooth... https://travis-ci.org/snapcore/snapd/jobs/333816377
<kyrofa> jdstrand, got a question for you. I have a user who's snap needs to be disabled/enabled _every boot_, otherwise every daemon prints this: "cannot change profile for the next exec call: No such file or directory"
<kyrofa> jdstrand, can you think of a reason for this?
<kyrofa> zyga-ubuntu, that ^ may interest you as well
<zyga-ubuntu> kyrofa: ack
<zyga-ubuntu> kyrofa: daemon should not do that
<zyga-ubuntu> kyrofa: on restart we reload profiles
<zyga-ubuntu> kyrofa: this smells like a container with apparmor disabled
<zyga-ubuntu> kyrofa: fighting over apparmor from the parent host
<zyga-ubuntu> kyrofa: if I'm right I'll get a t-shirt with some silly container stacking apparmor text
<kyrofa> zyga-ubuntu, all I know so far is that it's hosted on aruba.it
<zyga-ubuntu> yeah
<kyrofa> zyga-ubuntu, if you're up for jumping into the discussion, it's here: https://github.com/nextcloud/nextcloud-snap/issues/425
<zyga-ubuntu> looks like it
<mup> PR snapd#4553 opened: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4553>
<mup> PR snapd#4554 opened: test build - ignore <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4554>
<kyrofa> (including logs)
<mup> PR snapd#4554 closed: test build - ignore <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4554>
<kyrofa> Thanks zyga-ubuntu :)
<zyga-ubuntu> my pleasure :)
<zyga-ubuntu> I'm off today but back at my PC doing stuff so I can look for activity on that thread
<mup> PR snapd#4553 closed: many: add io.snapcraft.Settings to `snap userd` <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4553>
<mup> PR snapd#4546 closed: snap: tidy up top-level help output <Created by cjwatson> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4546>
<mup> PR snapd#4555 opened: test -ignore <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4555>
<zyga-ubuntu> mvo: what are you testing?
<mup> PR snapd#4552 closed: testutil: do not use echo for printing potentially conflicting arguments <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4552>
<mvo> zyga-ubuntu: I don't get why 4073 is failing
<cachio_> mvo, debugging it
<cachio_> mvo, it'll take a while
<cachio_> mvo, everithing is slowwww
<cachio_> mvo, https://paste.ubuntu.com/26465771/
<cachio_> it is like we create the ubuntu core, something happens to the user
<cachio_> I stopped the test just after we reboot the machine
<cachio_> and I get that
<cachio_> and before it works
<mvo> cachio_: oh, interessting
<mvo> cachio_: I wonder what in this PR broke it, it does not touch any of this
<cachio_> mvo, the test user is not in cat /var/lib/extrausers/passwd | grep test
<cachio_> not sure why
<mvo> zyga-ubuntu: just fyi - I updated http://people.canonical.com/~mvo/tmp/snap-boot.svg this time with snaps, it shows that snap.mount runs before the two snaps (core, hello) are mount. the mountinfo file is https://paste.ubuntu.com/26465825/
<jdstrand> kyrofa: I've not seen that, but it sounds like snap-confine is running and trying to change profile to the snap's profile, but that profile is not loaded
<mvo> cachio_: its super strange, I had issue with my local spread (gustavo helped me fixing it) and now I will try to get to the bottom of it
<zyga-ubuntu> mvo: oh, great, let me see
<jdstrand> kyrofa: if it is happening on boot, that could be that the snap is starting before snapd starts and the apparmor init/unit isn't loading /var/cache/apparmor
<cachio_> mvo, I am waiting to get a debug session
<mvo> cachio_: thank you, keep me updated please, curious if you hvae any ideas
<zyga-ubuntu> jdstrand: can we detect apparmor is not stacked inside a container?
<jdstrand> kyrofa: restarting snapd should cause snapd to load all the profiles
<cachio_> it is like for some reason the test user is not being added as a user in the files group gshadow passwd shadow
<mvo> zyga-ubuntu: still two mounts though
<zyga-ubuntu> inspecting
<jdstrand> zyga-ubuntu: can you rephrase?
<zyga-ubuntu> jdstrand: sure, sorry, let's say I use a privileged lxd container that doesn't use apparmor stacking, can I detect that somehow from inside the container?
<jdstrand> kyrofa, zyga-ubuntu: *if* the snap is running in a container, it certainly seems plausible that the detection logic is not working right
<zyga-ubuntu> mvo: question about the graph, what determines the width of a row?
<zyga-ubuntu> they all seem to have the same width
<zyga-ubuntu> is it "starting" or "finished"
<zyga-ubuntu> is it possible that our tweaks on post-start run in parallel with snap mounts?
<jdstrand> zyga-ubuntu: aiui, not as well as we should be able to. /lib/apparmor/functions has is_container_with_internal_policy() which is a hacky way of determining this
<mvo> zyga-ubuntu: thats an interessting idea
<zyga-ubuntu> jdstrand: thank you, let me read it
<mvo> zyga-ubuntu: the man page claims that the ordering will be correct if one mount unit is below/above the mount hirarchy
<mup> PR snapd#4555 closed: test -ignore <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4555>
<jdstrand> kyrofa, zyga-ubuntu: this seems similar to https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34
<jdstrand> I think jjohansen developed a patch for that for artful
<jdstrand> kyrofa: what kernel was that on?
<kyrofa> jdstrand, uncertain, I'll ask for a `snap version` run
<zyga-ubuntu> mvo: yes but what about the extra scripts that run after that are defined in one mount unit
<mvo> zyga-ubuntu: there is currently no extra script, its just shared,bind in the options
<zyga-ubuntu> mvo: ahh
<zyga-ubuntu> hmm hmm hmm
<zyga-ubuntu> this makes litlte sense
<zyga-ubuntu> would it bother you to drop the "shared" flag and rerun?
<zyga-ubuntu> and see what we get in mountinfo please?
<zyga-ubuntu> I'm suprprised you saw shared, in my testing shared was not working
<zyga-ubuntu> can you tell me how to reproduce your setup?
<mvo> zyga-ubuntu: sure, one sec
<mvo> zyga-ubuntu: here the same without shared https://paste.ubuntu.com/26465983/
<mvo> zyga-ubuntu: this is all on 16.04 classic
<zyga-ubuntu> hmmm
<zyga-ubuntu> odd
<zyga-ubuntu> 137 89 7:0 / /snap/core/3887 ro,nodev,relatime shared:117 - squashfs /dev/loop0 ro
<zyga-ubuntu> 138 23 7:0 / /snap/core/3887 ro,nodev,relatime shared:117 - squashfs /dev/loop0 ro
<zyga-ubuntu> 143 89 7:1 / /snap/hello/20 ro,nodev,relatime shared:122 - squashfs /dev/loop1 ro
<zyga-ubuntu> 144 23 7:1 / /snap/hello/20 ro,nodev,relatime shared:122 - squashfs /dev/loop1 ro
<zyga-ubuntu> how come you get this?
<zyga-ubuntu> thoey are all shared
<zyga-ubuntu> is this running in a container on top of your 16.04?
<zyga-ubuntu> mvo: ^ ?
<mvo> zyga-ubuntu: this is a regular vm
<mvo> zyga-ubuntu: sorry for the delay
<zyga-ubuntu> mvo: no worries, I'm mostly wondering how this is possible
<zyga-ubuntu> mvo: is there any part of test prep code that makes /snap or / rshared?
<zyga-ubuntu> maybe this is an artefact
<zyga-ubuntu> was this done via spread
<zyga-ubuntu> I was doing it in a boxes VM (so just plain KVM) on 16.04 with lxd and it was not getting the sharing
<mvo> zyga-ubuntu: this is all done manual, I used a stock 16.04 vm and added the mount unit manually
<zyga-ubuntu> I see
<mvo> zyga-ubuntu: but no lxd here
<zyga-ubuntu> hmm hm :)
<zyga-ubuntu> curious
<zyga-ubuntu> oh/
<mvo> zyga-ubuntu: this is the pure vm
<zyga-ubuntu> wait
<zyga-ubuntu> but pure 16.04 vm doesn't have this problem
<zyga-ubuntu> it's shared by default already
<mvo> zyga-ubuntu: I know, but if the fix produces double mounts thats a problem, no? or do we not care?
<zyga-ubuntu> (the duplication is a curious issue but it's not the main problem in containers)
<zyga-ubuntu> yeah, we may care
<zyga-ubuntu> I wonder what is really going on
<zyga-ubuntu> ok, this made me curous
<zyga-ubuntu> *curious
<zyga-ubuntu> I will explore
<mvo> zyga-ubuntu: ok, I will do the mount unit generated via postinst script step next
<mvo> cachio_: I know what breaks it - I added a zenity recommends that seems to cause the failure, I will dig into the details monday, peace of mind in the end :)
<cachio_> mvo, heehhe
<cachio_> mvo, ok
<cachio_> mvo, btw, I have doctor app on monday, not sure if I'll be at home for the standup
<mvo> cachio_: no worries
<mvo> cachio_: thanks for letting me know
<cachio_> tx
<Chipaca> sergiusens: question: is snapcraft validating snap version strings?
<mup> PR snapd#4544 closed: spread: remove more EOLed releases <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4544>
<kyrofa> Chipaca, yeah, to ^[a-zA-Z0-9.+~-]+$ and max length of 32
<Chipaca> kyrofa: k thx
<kyrofa> Chipaca, is that okay? Has it changed?
<Chipaca> kyrofa: snapd doesn't care :-) but i'm writing code in snapd that cares a little bit
<kyrofa> Gotcha
<Chipaca> i mean, if the version is valid, i'll use it in a filename
<Chipaca> if it's not, Â¯\_(ã)_/Â¯
<Chipaca> looking at that regexp, me, I wouldn't let versions end in ~, but again Â¯\_(ã)_/Â¯
<Chipaca> i mean, a version of 4.~1~ would be somewhat confusing
<Chipaca> at least to those of us used to VERSION_CONTROL=numbered
<kyrofa> Heck, same goes for the rest probably
<Chipaca> I could see people ending it in +
<Chipaca> still, very minor friday-what-am-i-doing-at-the-keyboard nitpick
 * Chipaca ponders beer
<cachio_>  Chipaca, any idea why the hidsraw interface is not visible?
<Chipaca> cachio_: no. visible where?
<Chipaca> cachio_: I don't have a hidsraw in my tree (but i haven't synced today)
<cachio_> Chipaca, hidraw
<Chipaca> cachio_: do you have /dev/hidraw*?
<cachio_> yes
<Chipaca> cachio_: dunno, then :-)
<cachio_> Chipaca, hehe, np
<cachio_> do you have the interface?
<diddledan> so one crazy SOB just got wine running
<diddledan> just rebuilding my snap to be sure I wasn't dreaming
 * Chipaca EODs
 * Chipaca EOWs
 * Chipaca EOLs
<mup> PR snapcraft#1888 opened: elf: make patchelf a dependency <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1888>
<Son_Goku> need testing for snapd 2.30 update for Fedora 26: https://bodhi.fedoraproject.org/updates/FEDORA-2018-798e0f02ff
#snappy 2018-01-27
<ogra_> urgh
<ogra_> jdstrand, https://paste.ubuntu.com/26467814/
<ogra_> bah, crap ... journalctl did not linewrap
<ogra_> jdstrand, https://paste.ubuntu.com/26467823/
<ogra_> jdstrand, looks like time-control doesnt allow hwclock to call settimeofday
 * ogra_ added that stuff to the hwclock forum post ...
<jdstrand> ogra_: ack, saw the forum, added to list for next batch
<jdstrand> ogra_: thanks!
<mup> PR snapd#4073 closed: snap: add io.snapcraft.Settings to `snap userd` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4073>
<mup> PR snapcraft#1888 closed: elf: make patchelf a dependency <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1888>
<mup> Bug #1745772 opened: Can't run snap in lxd container <Snappy:New> <https://launchpad.net/bugs/1745772>
#snappy 2018-01-28
<mup> PR snapd#4556 opened: strutil/quantity: new package that exports formatFoo (from progress) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4556>
<mup> PR snapd#4557 opened: osutil: add DirExists and IsDirNotExist <Created by chipaca> <https://github.com/snapcore/snapd/pull/4557>
#snappy 2019-01-21
<mup> Bug #1812605 opened: snap find crached <Snappy:New> <https://launchpad.net/bugs/1812605>
<mborzecki> morning
<zyga> Hi
<zyga> A bit in recovery mode
<mborzecki> zyga: hey
<zyga> Fell off the stairs last night
<mborzecki> zyga: oi, are you ok?
<zyga> I may join standup but donât wait for me
<zyga> When I can I will work on packaging
<zyga> So so
<mborzecki> zyga: was the trip back ok at least? :)
<zyga> Some bruises and stuff like that. Some more back pain
<zyga> Currently with wife for pregnancy checkup
<zyga> Yeah, the trip was ok :-)
<zyga> Just long and not much sleep on the way
<mup> PR snapd#6294 closed: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6294>
<mborzecki> yay
<mborzecki> mvo: hey
<mup> PR snapd#6391 closed: tests: simplify interfaces-contacts-service test <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6391>
<mvo> hey mborzecki - good morning!
<mvo> mborzecki: yeah, indeed yay :)
<mborzecki> mvo: 1.9 is the new minimum now?
<mvo> mborzecki: correct, we should probably update our readme too
<mborzecki> mvo: hm there's no metion of any particular go version in the readme
<mvo> mborzecki: yeah, I think we soon add a mention
<mvo> mborzecki: its not OMGnow important though :)
<mvo> mborzecki: also I just sent a mail out to foundations, security, sru etc to make sure they know we really did that, we did discuss it but I want to double check noone is unaware
<mvo> geh, everyone is aware (double negatives are terrible!)
<mborzecki> we can replace golang.org/x/net/context with context now
<mborzecki> and update govendor too
<mvo> mborzecki: yes, lets discuss in the standup. I would like to wait until we got feedback from foundations/security etc to make sure we don't need to revert anything. but having PRs will be good
<mborzecki> i can do a quick cleanup and open a PR if we are greenlit to move forward with this
<mvo> mborzecki: sounds great, please do
<mborzecki> wow, we even used ctxhttp
<mborzecki> 35 files changed, 36 insertions(+), 66 deletions(-)
<mborzecki> not an awful lot
<mvo> nice
<mborzecki> golang.org/x/net/context/ctxhttp goes away, but x/net/context is imported by tomb, so it has to stay around
<mvo> mborzecki: ok
<mborzecki> we could also drop the check for numerical http return codes
<mborzecki> and use consts from net/http
<mup> PR snapd#6402 opened: spread: increase default kill-timeout to 30min <Created by mvo5> <https://github.com/snapcore/snapd/pull/6402>
<Chipaca> morning peeps
<mvo> Chipaca: hey, good morning!
<mborzecki> Chipaca: morning
<mup> PR snapd#6403 opened: many: cleanup golang.org/x/net/context <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
<mvo> mborzecki: nice, thank you!
<mvo> mborzecki: looks like unit tests are unhappy in this PR, seems like new stuff that the new go checks
<mborzecki> mvo: mhm, pushing in a minute
<mvo> mborzecki: also only in tests so shouldn't be bad :)
<mvo> mborzecki: no worries, just wanted to let you know
 * mvo is quite happy about this PR
<mborzecki> mvo: and pushed
<mvo> ta
 * Chipaca removes 1.6, installs 1.10
 * Chipaca feels like it's a party
 * mborzecki can drop 1.6 gofmt wrapper now
<Chipaca> oooh, there's a bunch of things we can drop
<mborzecki> Chipaca: can you take a look at #6403 ?
<mup> PR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
<Chipaca> mborzecki: egrep -r --exclude-dir vendor '// \+build \!?go'
<mborzecki> mhm
<Chipaca> I need to double-check but IIRC ctrl17 was good up to 1.10 at least
<mborzecki> Chipaca: was there some fancy json decoding too?
<Chipaca> 1.11 might be using an even newer unicode but ctrl didn't see much change
<Chipaca> mborzecki: ctrl is part of that, if you mean the 'clean' json
<Chipaca> but
<Chipaca> mborzecki: there are places where we use *json.RawMessage instead of json.RawMessage, that we could drop
<Chipaca> and see some perf improvement
<Chipaca> perhaps
<mborzecki> pr by pr :P
<Chipaca> ep
<Chipaca> had to get https://packages.ubuntu.com/bionic/amd64/golang-golang-x-tools by hand to get godoc to play nice again
<Chipaca> (i'm on xenial here)
 * sparkiegeek wonders if Chipaca could have used https://launchpad.net/adapt
<Chipaca> sparkiegeek: no idea what that is :-)
<Chipaca> ah
<Chipaca> sparkiegeek: no need to rebuild the package, it just works as is
<sparkiegeek> Chipaca: it installs Ubuntu packages from 'other' series in a LXD and wraps them to make a cheap way of getting package X available from a given series
 * Chipaca imagines using X from bionic o n xenial, and shudders
<sparkiegeek> hah :)
<zyga> o/
<mvo> hey zyga
<zyga> hey mvo :)
<mvo> zyga: welcome back!
<mvo> zyga: but please take it easy today
<zyga> mvo: I'm sorry about expensify, it's super easy to click the wrong button while on the go
<zyga> (about that "let me expense one coffee thing")
<zyga> I'm sorting out my travel topics now
<zyga> and recovering after the small accident yesterday :)
<zyga> but all will be fine
<zyga> anything urgent, any news?
<mvo> zyga: no fires
<mvo> zyga: your go-1.10 pr is in \o/
<zyga> I noticed, thank you, good idea to notify other teams about that
<mborzecki> zyga: looking into bcond_with{,out}, do we have 15.0 image for spread?
<zyga> mborzecki: mmm, not sure
<zyga> if you have a branch I have all the VMs ready
<zyga> oh
<zyga> one thing
<zyga> so
<zyga> tl;dr; I spent last week working on top of ubuntu in hyper-v and multipass also on top of hyperv
<zyga> mborzecki: I think we could start standardizing on using multipass for test-builds on native kernel
<zyga> it's very flexible and qucick
<zyga> quick*
<mborzecki> does it work well with non ubuntu vms?
<zyga> yes
<zyga> only requirement is cloud-init in the image
<zyga> I've got a pipeline for debian builds now
<zyga> http://download.opensuse.org/repositories/Cloud:/Images:/Leap_42.3/images/
<zyga> I will give this a try (though not with any priority today)
<zyga> mborzecki: it's as simple as "multipass launch $URL-to-qcow2 -c 10 -m 4G -n vm-name
<zyga> then you have multipass commands to exec stuff inside, copy stuff around, shell interactively
<zyga> multipass handles networking and caching
<mborzecki> ah, haven't tried anything else than ubuntu with multipass yet
<mborzecki> what if the image has no cloud-init?
<zyga> nogo
<zyga> I think it's a requirement
<zyga> ask Saviq once he's back
<Saviq> I'm here
<mborzecki> Saviq: is cloud-init a hard requirement?
<Saviq> yes, otherwise we can't access the launched instance
<zyga> Saviq: did I say thank you for multipass, it's awesome
<Saviq> mborzecki: otherwise you'd need to know (and pass it to us) a default username/password
<Saviq> and we don't support that right now, nor look forward to it really
<zyga> mborzecki: does arch have any cloud images?
<zyga> everything else we support has them
<Saviq> anything else, we'd need to expose a graphical and/or serial console
<mup> PR snapd#6404 opened: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
<Saviq> and it'd be a hands-free experience from then as far as multipass is concerned
<mborzecki> zyga: nah :P no cloud images afaik
<mborzecki> you can probably build one
<mborzecki> well, we built one for spread
<mborzecki> but it's not using cloud-init afaik
<Saviq> probably has a well-know root password :)
<Saviq> +n
<mborzecki> yup, something no trivial, like 123 :P
<Saviq> https://wiki.archlinux.org/index.php/Cloud-init
<Saviq> https://wiki.archlinux.org/index.php/Arch_Linux_AMIs_for_Amazon_Web_Services
<Saviq> may very well be possible to use those
<mborzecki> mh
<mborzecki> Saviq: while at it, is it possible to launch throw-away instances with multipass? i often work directly with cloud images and use qemu .. -snapshot
<Saviq> mborzecki: we have a handful of approaches planned for speeding up boot, but we're unlikely to add full snapshot support any time soon, don't want to become just another CLI for hypervisors
<mup> PR snapd#6405 opened: run-checks: ensure we use go-1.10 if available <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6405>
<zyga> mvo: mount error still happens
<zyga> error: cannot perform the following tasks:
<zyga> - Mount snap "network-consumer" (unset) ([start snap-network\x2dconsumer-x1.mount] failed with exit status 1: Job for snap-network\x2dconsumer-x1.mount failed.
<zyga> See "systemctl status "snap-network\\x2dconsumer-x1.mount"" and "journalctl -xe" for details.
<zyga> )
<zyga> this is from the PR above
<Chipaca> zyga: is the go version relevant enough to be in 'snap version'?
<zyga> Chipaca: dunno
<zyga> perhaps?
<Chipaca> zyga: or would this be a case for a --verbose flag or sth?
<zyga> yeah
<zyga> or even a debug
<zyga> snap debug build-info
<Chipaca> i mean, if it's for the tests, just add a 'go version' :-)
<zyga> could show other helpful stuff
<zyga> +1
<zyga> go version can be elusive :)
<zyga> if we have many
<Chipaca> ooh, ooh! I remembered what I wanted to do when we moved past 1.7!
<Chipaca> https://gist.github.com/chipaca/10ecdf364db962c9b5ee590f0f610b2a
<zyga> sorry for cutting me video feed but I'm out of power on the phone
<Chipaca> zyga: we lost you
<mvo> zyga: yeah, cachio mentioned this as well, on what system did that happen for you?
<zyga> mvo: that was in the PR you sent, I don't recall
<zyga> mvo: I only saw it there
<zyga> small helper I use for packaging work
<zyga> packaigng helper https://www.irccloud.com/pastebin/oPwDE5pt/
<zyga> mvo: ^
<zyga> mborzecki: ^
<mborzecki> hm we should add a multipass backend to spread :)
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5962, snapd#6016, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6280, snapd#6281, snapd#6313, snapd#6320, snapd#6322, snapd#6324, snapd#6325,
<mup> snapd#6327, snapd#6329, snapd#6333, snapd#6341, snapd#6347, snapd#6348, snapd#6356, snapd#6360, snapd#6363, snapd#6367, snapd#6376, snapd#6380, snapd#6381, snapd#6383, snapd#6387, snapd#6389, snapd#6394, snapd#6396, snapd#6400, snapd#6401, snapd#6402, snapd#6403, snapd#6404, snapd#6405
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<cachio> mvo, should I remove the manual from debian sid after the imagge is updated?
<mvo> cachio: yeah, lets try that
<mvo> cachio: once its updated, lets push a PR that enables sid again
<cachio> mvo, sure, thanks
<mvo> cachio: and then we can check how well that goes - it will be a good prep for the packaging merge PR. thank you!
 * cachio lunch
<om26er> popey, ping
<popey> om26er: hi
<om26er> popey, could you take a look at this one https://github.com/asciinema/asciinema-snap/issues/1#issuecomment-454529232
<popey> will do
<mup> PR snapd#6406 opened: tests: enable debian sid as part of the main suite on travis <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6406>
<zyga> my debian foo has grown the SBUILD_SHELL trick
<mvo> I uploaded new test-snapd-dbus-{consumer,producer} snaps to edge, if tests suddenly explode, this is why
<mvo> (the PR below addresses this)
<mup> PR snapd#6407 opened: tests: get test-snapd-dbus-{provider,consumer} from the beta channel <Created by mvo5> <https://github.com/snapcore/snapd/pull/6407>
<mup> PR snapd#6408 opened: tests: add spread test for system dbus interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/6408>
<zyga> wooot
<zyga> I solved the debian unit test failures :)
<cachio> zyga, this is the error you have fixed? https://paste.ubuntu.com/p/cmQTKpDhh6/
<zyga> no
<zyga> this is a known issue about go fmt changing behavior across go versions
<cachio> zyga, ahh, ok
<mup> Bug #1812751 opened: Several remove event for unknown device <Snappy:New> <https://launchpad.net/bugs/1812751>
#snappy 2019-01-22
<zyga> hello
<mborzecki> morning
<zyga> mborzecki: hey :)
<zyga> mborzecki: making breakfast, how are you?
<mborzecki> zyga: hey
<mborzecki> zyga: how's your back?
<zyga> mborzecki: better, not sure what happened yesterday, wasn't my typical thing
<mborzecki> zyga: glad that it's better
<mborzecki> heh, so debian sid has some really new version of go, and tests/unit/go bails out do to gofmt changes :0
<zyga> mborzecki: yeah, I noticed :|
<zyga> we should disable those or figure out if we can pin the format
<zyga> mborzecki: I solved the unit test issues that happen when building in sbuild
<zyga> let me push a patch against master
<mborzecki> seccomp?
<zyga> no, that is still off
<zyga> but I will investigate that next
<zyga> I need to compile a few programs on sid toolchain and buster toolchain
<mborzecki> it'd be nice to run the unit tests on sid
<zyga> yeah, that's still somewhat away
<mborzecki> we'll probably need to add an off switch for gofmt in run-checks
<zyga> the key difference was not sid
<zyga> just sbuild
<mborzecki> i meant #6406, it's failing due to gofmt from go 1.11 which uses a different indent length when aligning struct field values & comments
<mup> PR #6406: tests: enable debian sid as part of the main suite on travis <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6406>
<mup> PR snapd#6409 opened: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <https://github.com/snapcore/snapd/pull/6409>
<zyga> mborzecki: I have more patches but those are of the simple kind that disable stuff
<zyga> mborzecki: the key thing I achieved yesterday, was to build a process where it is easy and fast to iterate on this
<zyga> afk
<zyga> back now
<zyga> mvo: hello :)
<zyga> mvo: how are you doing after the game last night?
<mvo> zyga: hey, still feel a bit battered but ready for work
<zyga> mvo: I pushed one PR already
<zyga> it contains the fixes for unit tests that are applicable to master
<zyga> mvo: I also, just now, opened another pull request
<zyga> that adds a program to release-tools
<mup> PR snapd#6410 opened: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
<zyga> to improve the process on working on debian packaging
<zyga> right now the package builds but needs review (it's non-trivial) and it needs more love to fix lintian isues
<zyga> adt tests also fail but I didn't investigate any more than that
<zyga> please have a look at 6410 as a starting point if that's okay
<mvo> zyga: sure
<mvo> zyga: thanks!
<zyga> mvo: you can reproduce my progress with that PR (just grab the script, it's not tied to the rest of the tree) and the "debian" branch from https://salsa.debian.org/zyga-guest/snapd
<mvo> zyga: ok
<mvo> zyga: if the package builds and works and lintian is not worse than before, can we push it to the archive? or is anything else missing?
<zyga> mvo: it has one E so I think at least that must be fixed
<zyga> mvo: I suspect I did something silly in my meld-based-merge
<zyga> and we can get rid of most of W-s easily
<zyga> mvo: my smoke test would be to install the package and run a few snaps quickly
<mborzecki> #6409 needs a 2nd review and can land
<mup> PR #6409: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <https://github.com/snapcore/snapd/pull/6409>
<mborzecki> mvo: morning
<mvo> mborzecki: good morning
<mvo> zyga: yeah, that sounds sensible
<mvo> mborzecki: did a second review on 6409 - just one tiny question
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/6405 has a suggestion from Chipaca that can be applied via github
<zyga> mvo: replied
<mup> PR #6405: run-checks: ensure we use go-1.10 if available <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6405>
<mup> PR snapd#6402 closed: spread: increase default kill-timeout to 30min <Simple ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6402>
<mup> PR snapd#6409 closed: interfaces/apparmor: mock presence of overlayfs root <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6409>
<mvo> zyga: thanks, also cherry-picked it now
<zyga> thank you!
<mvo> zyga: thank *you* :)
<mvo> zyga: one thing less to worry about
<zyga> mvo: yeah
<zyga> mvo: after getting to the point where I can run interactive shell inside sbuild inside debian 10 vm
<zyga> mvo: and finding my way around the odd way dh-golang arranges the source code
<zyga> it was okay
<zyga> mvo: all of the patches I remade/added are in https://salsa.debian.org/zyga-guest/snapd/commits/debian-patches
<zyga> mvo: I will look at seccomp now, could you look at lintian please?
<zyga> and just see if what I made makes any sense
<murthy> Olivier Tilloy thanks for making chromium with vaapi working  snap.
<mvo> zyga: yeah, could you please pastebin the errors again?
<mvo> zyga: or point me to it?
<mvo> zyga: I have lintian and your tree etc, looking at this now
<mvo> zyga: please apply http://paste.ubuntu.com/p/YkfDs69XSq/ (I can do a formal pull rquest if you prefer)
<mvo> zyga: test building that now
<zyga> mvo: re, sorry, had some things happening at home
<zyga> mvo: applying
<mvo> zyga: ta - also your changelog needs one extra space after me@zygoon.pl> and before Thu,
<mvo> zyga: there must be two spaces there or lintian is unhappy
<mvo> zyga: I look at the ones produced by the binary build now
<mvo> zyga: fwiw, the way this can be driven via gbp: http://paste.ubuntu.com/p/YYqSsxV2g6/
<mvo> zyga: this builds fine in sbuild under bionic fwiw
<mvo> zyga: (i.e. no unit test or other issues)
<Chipaca> mooing
<ogra> meow
<mvo> zyga: the other warning that is easy to fix is that snap-discard-ns.8 has "section: 5" in the .rst file, trivial to fix
<zyga> ah
<zyga> I see
<mvo> zyga: there are some more warnings that we should probably just lintian override
<mvo> zyga: but I think they are ok for now
<ackk> hi, given a .snap file, is it possible to know which arch is it built for? "snap info" doesn't provide that info AFAICT
<zyga> ackk: you can look at meta/snap.yaml, at the architecture field
<zyga> but there's nothing quick and easy I'm afraiid
<zyga> *afraid
<ackk> zyga, I ses, so I guess I have to mount the snap filesystem for that
<zyga> or extract that file
<ackk> zyga, ok, thanks
<ackk> zyga, maybe it could be an improvement of "snap info" ? :)
<zyga> ackk: do we show that with snap info --verbose?
<zyga> or -v
<ackk> zyga, no
<mvo> zyga: yeah, that sounds like a bug
<mvo> ackk: ups, sorry, I mean that sounds like a missing feature
<mvo> ackk: you can look at the filename
<mvo> ackk: but its *very* crude
<Chipaca> pedronis: you around?
<mvo> Chipaca: he is off today
<Chipaca> ah i thought that was yesterday
<Chipaca> mvo: zyga: let's add architecture to the info backlog :-)
<mvo> Chipaca: +1
<mup> PR snapd#6407 closed: tests: get test-snapd-dbus-{provider,consumer} from the beta channel <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6407>
<zyga> mvo: (sorry for the lag, this machine is pretty slow)
<zyga> so, I built and installed the package
<zyga> I think we should make a few more tweaks
<zyga> https://www.irccloud.com/pastebin/uLToDeBM/
<zyga> autoimport, core-fixup should probably be removed
<zyga> snap-repair and system-shutdown, as well
<zyga> snapd.failure.service, not sure about that one
<zyga> mvo: I'll do some more exploratory testing
<zyga> mvo: we should upload the package today
<zyga> mvo: will the upload impact disco in any way?
<mvo> zyga: yeah, all these services can go
<mvo> zyga: it shouldn't impact disco
<mvo> zyga: we will see
<zyga> mvo: I pushed to salsa again, just to ensure that if this crusty machine falls apart we won't lose anything :)
<mvo> zyga: +1
<zyga> I'm running microk8s now
<zyga> I will run a few more snaps as well
<zyga> mvo: I think we need a proper plan on how to bring this back to master
<zyga> I feel that despite the effort and progress we are still in "we'll see when we release" state
<zyga> mvo: after today I would like to work on feature I'm due to produce, I'm happy to make more progress in 2.38 or 2.37.1
<zyga> mvo: but we should discuss with samuele about what to realistically do about long term plan for snapd release readiness
<mvo> zyga: there is a PR up for that :)
<zyga> mvo: you mean your PR with sbuild?
<mvo> zyga: I mean, we have a plan, we just need to merge your latest additions into 6396
<mvo> zyga: and then we are good
<zyga> mvo: I think we still need to figure out how to work with patches
<zyga> mvo: we either keep those patches and teach people to work with them
<mvo> zyga: well, if we break a patch we break the build in 6396
<zyga> mvo: or figure out how to avoid patches
<zyga> yes
<mvo> zyga: I think that is acceptable for now and we try to reduce the patches
<zyga> 1st requires more learning on all the team members, 2nd requires some ideas and more engineering
<zyga> mvo: I would like to adjust debian to use my makefile
<zyga> it handles things like "this is for core only, don't ship it"
<mvo> zyga: yeah, but the patches are very tiny and isolated, we can always help if they get out of sync
<zyga> yeah
<mvo> zyga: quick HO for faster communication?
<zyga> I mean, as I said, this is much better :)
<mvo> zyga: yeah, one step at a time
<zyga> but we still need to get through a few releases with no issues
<mvo> zyga: I mean, I'm not disagreeing with anything :)
<zyga> mvo: we can HO but I think we are in agreement :)
<mvo> zyga: just 1. we release from salsa 2. we import salsa into our tree 3. we run the debian packaging on debian-sid in spread 4. ...
<mvo> zyga: excellent
<mvo> zyga: then lets HO later :)
<zyga> yeah
<zyga> +1
<mvo> zyga: but yeah, there is more work and open questions down the road!
<mvo> zyga: and thanks for working on this!
<zyga> mvo: "what about Debian Zygmunt?" :D
<zyga> playing with microk8s, I think it works ok :)
<mvo> zyga: cool
<zyga> another build in progress
<zyga> mborzecki: while fresh in my head, I'd like to look at https://github.com/snapcore/snapd/pull/6111 next
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> mborzecki: I will merge master and resolve conflicts
<zyga> I would like to merge it as-is
<zyga> to avoid bitrot in the makefile
<zyga> then use this for 2.37
<mup> PR snapd#6405 closed: run-checks: ensure we use go-1.10 if available <Simple ð> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6405>
<Chipaca> zyga: AIUI Neal's comments were phrased as strong suggestions but seem to be actual blockers, or did I misunderstand?
<zyga> Chipaca: I don't think those are blockers, the package works OK
<zyga> more of a "this is the style to follow", at least in my eyes
<Chipaca> zyga: what's the thing about debuginfo subpackages
<zyga> nothing new AFAIK, just a desire to be able to tweak go flags
<zyga> Chipaca: also looking at that comment, I'm not sure if that's actually something to do with suse or a preference to make it better for eventual use in fedora
<zyga> I don't mind improvements, just want to walk before I run :)
<ackk> mvo, well actually I get that file via snap download and it's like  snapname_rev.snap. but I can look at the meta.yaml file
<ackk> I mean meta/snap.yaml
<mvo> ackk: aha, ok
<Chipaca> ackk: but you know the architecture before you download, right?
<Chipaca> ackk: or, rather, you can request a particular architecture :-)
<Chipaca> so then you'd know that's the architecture you got
<ackk> Chipaca, well yes and no. this is run from a jenkins job, which takes  the revision as parameter. so yes the user know it but I wanted to avoid having to pass it. it's not a big deal at the moment as we're only building amd64, so it can be hardcoded. it'd be nice to have that in "snap info" though, it possile
<Chipaca> ackk: what do you then do with the architecture?
<ackk> Chipaca, don't ask :)
<Chipaca> ackk: I ask because I wonder if you contemplate "all" vs ["amd64", "i386"] etc
<Chipaca> bah, ["all"]
<ackk> Chipaca, it's used to populate the Architecture field of a debian/control
<ackk> well, currently it's not, but that's the idea
<Chipaca> ackk: does debian/control support multiple values?
<ackk> not sure
 * Chipaca guesses no
 * Chipaca might not be guessing
<ackk> yeah I would think no
<ackk> I think it's either "all" or a single arch
<Chipaca> ackk: man deb-control, fwiw
<zyga> switched back to my main machine
<zyga> man that thinkpad has slow cpu ;0
<ackk> ah, TIL
<ackk> Chipaca, btw how do you build a snap for more than one arch?
<Chipaca> ackk: wait, you're creating debs from snaps?
<Chipaca> ackk: build-on vs run-on
<Chipaca> ackk: 1 sec, there's an example
<ackk> Chipaca, I said don't ask :)
<Chipaca> ackk: https://forum.snapcraft.io/t/architectures/4972?u=chipaca example 6
<zyga> mvo: I'm happy with CLI testing, I'll do one quick pass over graphical snaps on up-to-date debian-10
<zyga> mvo: then I will ask you to have a last look and dput, okay?
<popey> Chipaca: is there any plan to make snap find more readable on a standard 80x25 terminal?
<ackk> Chipaca, thanks, that's nice I didn't know about it
<Chipaca> popey: no plan as yet. I'm aware it's not ideal, and have proposed a few solutions that were shot down
<popey> :(
<Chipaca> popey: currently we want (1) output unchanged (other than minor cosmetic changes) whether it's going to a terminal or to a pipe, and (2) a single result per line
<popey> people pipe the output of snap find?
<Chipaca> popey: my proposals broke both of those :-)
<popey> isn't that what an API is for?
<Chipaca> popey: snap find | grep yadda, yes people do
<Chipaca> and that's reasonable, but I'm hoping we can do something like dpkg -l does which breaks (1) but only lightly
<Chipaca> that'll be my next offering
<Chipaca> when i get to it
<Chipaca> (but it's a blue item)
<Chipaca> popey: do you have any particularly egregious example?
<popey> well, the output is barely readable in a stock terminal
<popey> https://usercontent.irccloud-cdn.com/file/Wsj2NdJH/Screenshot%20from%202019-01-22%2012-14-06.png
<zyga> popey: (I think we agree)
<zyga> popey: we just need a solution
<popey> This has been solved by apt/dpkg years ago :(
<Chipaca> popey: not really
<zyga> what is the solution?
<popey> look at the output from dpkg -l or apt search foo
<Chipaca> 'apt-cache search' just prints the name and the summary; 'apt search' is ungreppable; dpkg -l has you guessing as to whether it's the whole package name or not
<zyga> Chipaca: in defense of the idea, I believe find should not require grepping
<popey> well, apt does warn you not to use the output as it's not stable, but can be grepped
<popey> apt search firefox | grep ubufox
<popey> apt search firefox | grep -A 1 ubufox
<Chipaca> I mean, you need to use perl -00 -p '/.../'
<Chipaca> or, that
 * Chipaca itches to write the right perl but stops himself
<Chipaca> but we're arguing over non-essentials I think
<Chipaca> I agree with you that it's not ideal, and I've proposed solutions for it, and the discussion of how to address it is ongoing
<Chipaca> snap find, snap list, snap changes, they're all bad in this sense
<Chipaca> 'snap info' and the progress bars are ok afaik
<popey> Ok. I won't bug you then. Just a shame  ::(
<Chipaca> as long as we ignore unicode width that is (e.g. 'snap info unifonter')
<popey> snap info word wraps the summary oddly, snap info libreoffice
<Chipaca> seems finie here
<Chipaca> fine*
<Chipaca> popey: how's it odd?
<popey> https://usercontent.irccloud-cdn.com/file/CLXey6IM/Screenshot%20from%202019-01-22%2012-27-36.png
<popey> "  slideshows and databases"
<Chipaca> agh
<Chipaca> you did say summary
<Chipaca> i was looking at description
<Chipaca> i'll fix that
<popey> thanks
<zyga> W: snapd: systemd-service-file-refers-to-unusual-wantedby-target lib/systemd/system/snapd.seeded.service cloud-final.service
<zyga> hmmm
<zyga> hmmm
<zyga> snapd doesn't start after reboot
<zyga> boot hangs
<zyga> I guess the package needs more love
<zyga> ah, I was following edge
<zyga> switched to stable to really use the package we made
<zyga> reboot and same behavior
<zyga> hmm
<zyga> mvo: snapd.service, failedwith result 'timeout'
<zyga> (then we get killed with sigterm)
<zyga> snapd.service has onfailure=snapd.failure.service, I guess that should be patched out?
<zyga> we are type=notify
<zyga> hmmmm
<zyga> starting it by hand works ok
<zyga> no idea,
<zyga> let's see what happens with more debugging
<zyga> hmm, not much
<mborzecki> off to pick up the kids
<zyga> I've added error handling around sd_notify
<zyga> pstolowski|afk: hey
<zyga> around?
<zyga> man, build cycle is  ~20+ minutes
<zyga> hmmm
<zyga> snapd.service times out starting https://www.irccloud.com/pastebin/F1Jh1CRa/
<zyga> mvo: around?
<Chipaca> zyga: can you try that again with debug?
<zyga> it *is* with debug
<Chipaca> zyga: or  was the first time already debug
<Chipaca> the first run i mean, that timed out, can you repro it?
<zyga> looks like we block somewhere early on
<zyga> no, only during reboot
<zyga> when we start up
<zyga> maybe sanity check mount thing?
<zyga> gosh I hate patching packaging
<zyga> quilt is the monumental suck
<mvo> zyga: yes, sorry for the delay
<zyga> no worries :)
<zyga> I'm adding more debugging
<zyga> but ideas welcome
<zyga> if you want we can HO
<mvo> zyga: pstolowski|afk is not around this week
<zyga> i see
<zyga> ok
<mvo> zyga: I'm looking at the backlog - do you have a short summary hwat the issue is?
<mvo> zyga: aha, start operation timed out?
<zyga> snapd works fine
<zyga> on reboot it just hangs
<zyga> switching to a vt magically unblocks it
<zyga> adding debug to pinpoint where
<zyga> no more ideas
<mvo> zyga: on reboot only? or on stop as well?
<zyga> on boot up
<zyga> not shutdown part of reboot
<mvo> zyga: oh, on bootup - how strange
<zyga> mvo: I pushed all the patches to salsa
<zyga> I can also share a .deb for debugging
<mup> PR snapcraft#2446 opened: Update schema/snapcraft.yaml <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2446>
<zyga> added more and running another build now, ~~ 20 minutes till results show up
<mvo> zyga: can you set SNAPD_DEBUG=1 in /etc/environment
<zyga> I did
<zyga> the log above was with that in place
<mvo> zyga: oh
<zyga> right? curious
<mvo> zyga: so nothing between Starting ... and timeout :/
<zyga> correct
<zyga> my hunch is on mount
<zyga> deadlock/
<zyga> we'll ee
<zyga> see, gosh keyboards
<mvo> sty 22 14:41:30 debian-10 systemd[1]: Starting Snappy daemon...
<mvo> sty 22 14:42:35 debian-10 snapd[1040]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network
<Chipaca> zyga: can you dump "systemd-analyze --plot" somewhere?
<mvo> zyga: well, second start takes 1m05 until output
<zyga> on it
<mvo> zyga: so strange
<zyga> mvo: it starts only after I switch vt
<Chipaca> zyga: also systemd-analyze blame
<mvo> zyga: strace would be great, but I guess thats hard - or could you ssh into it?
<zyga> mvo: I'll try
<zyga> sigh
<zyga> pastebinit broken on debian
<zyga> I hate that it just doesn't work on fedora / debian normally
<Chipaca> zyga: snap it :-D
<mborzecki> zyga: huh, broken even for paste.debian.net?
<zyga> mborzecki: echo broken | pastebinit
<zyga> it's broken if that doesn't work
<zyga> it doesn't work
<mborzecki> damn
<zyga> if you have to configure it it is broken
<Chipaca> mborzecki: this being debian, I assume it needs post-install tweaking to work
<zyga> https://pastebin.ubuntu.com/p/XDpPTRhsG8/
<zyga> snapd.seeded
<Chipaca> zyga: doesn't snapd have after: snapd.seeded?
<Chipaca> or was snapd.seeded a snapd thing
<mvo> zyga: journalctl -u snapd.seeded?
<mborzecki> snapd.seeded pokes snapd
<zyga> i cannot paste the .svg file
<zyga> because reasons on pastebin
<Chipaca> ah, seeded is after=snapd
<Chipaca> so snapd does not need seded, indeed
<zyga> standup
<Chipaca> zyga: copy it to people.c.c (or dump it in your lab :-) )
 * Chipaca stands up
<Chipaca> and then?
<mborzecki> maybe it's slow key generation?
<mborzecki> ssh is also slow to start
<zyga> ssh is slow yes
<zyga> no idea
<zyga> https://www.irccloud.com/pastebin/rTkZQ1hN/
<zyga> that's for snapd.seeded.service
<Chipaca> zyga: how's your random pool?
<zyga> Chipaca: hard to say but that kernel seems to log and hand out randomness that's not really random
<zyga> let me reboot and see
<Chipaca> zyga: sysctl kernel.random.entropy_avail
<zyga> booting now
<zyga> thank for the tip :)
<Chipaca> zyga: maybe in a ExecStartPre
<zyga> it's possible
<zyga> that it was it
<zyga> and by logging in on vt3 I add entropy
<mborzecki> haha omg :)
<Chipaca> that would also explain ssh being slow
<zyga> after logging in I got 861
<mborzecki> zyga: can you prepare a new machine and install heaveged on it?
<zyga> install what?
<mborzecki> haveged
<zyga> started after adding more debugging  https://www.irccloud.com/pastebin/9oE0zyy1/
<zyga> mborzecki: sure, I can clone this machine
<zyga> and see if that helps
<mborzecki> btw. multipass ought to be using virtio-rng too (probably is)
<zyga> this is vmware
<zyga> https://github.com/snapcore/snapd/pull/6367
<mup> PR #6367: cmd/snap-update-ns: allow switching to user mount namespace <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6367>
<zyga> https://www.irccloud.com/pastebin/IQQwkG13/
<Chipaca> zyga: did you add the ExecStartPre line?
<zyga> hold on, not yet
<popey> Hm, if I set icon: somepath/foo.png then it copies that icon to meta/gui/icon.png which isn't the actual filename, and isn't what's in the desktop file
<popey> I wonder why snapcraft does that?
<popey> why not copy it to snapname.png to match the desktop file?
<Chipaca> popey: 'old on
<Chipaca> popey: that's the icon _of the snap_
<Chipaca> popey: there aren't desktop files for snaps
<Chipaca> popey: it's separate from the icon for the apps in the snap, which are referenced from desktop files
<Chipaca> popey: for example if you were packing an office suite, the icon for the suite would be distinct from the icons for each component application
<popey> huh
<popey> is that because i put the icon: outside the apps: ?
<Chipaca> popey: granted if it's a single app they'll often be the same, in which case you'd have duplicated (or carefully point at the one from the other, which is harder)
<popey> would it work if I put icon: in the apps: stanza?
<Chipaca> popey: snaps don't yet know about per-app icons (desktop files do)
<popey> why is this so hard :(
<Chipaca> popey: if it were easy, ubuntu wouldn't exist
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> the reason distributiosn exist is ebcause this stuff is hard :-)
<popey> i have an app which has an icon in its tree and a desktop file, i guess I need to ninja the desktop file and move the icon
<Chipaca> also typing is hard
<popey> right, but I thought we were supposed to be making this easier
<popey> this isn't easier, it's brutal
<Chipaca> popey: we try
<Chipaca> popey: doesn't the desktop file get included in the snap already?
<zyga> https://salsa.debian.org/zyga-guest/snapd
<mborzecki> zyga: a thought, could it be that we regenrate security profiles?
<zyga> In a call
<popey> the desktop file is included if i use desktop: to point to it, sure
<popey> ah well.
<Chipaca> hmmm
<Chipaca> maybe snapcraft should have per-app icons? but not sure what it'd to with them other than copy them
<Chipaca> does it tweak the desktop file so the icon path is in the snap, or does the dev need to do that?
<Chipaca> (sounds hard for snapcraft to know that)
<popey> ok, i have bodged it for now by editing the desktop file
<zyga> re
<zyga> mborzecki: I checked that, we just don't get started
<zyga> mborzecki: so it's not that
<zyga> mborzecki: i added a patch with extra debug logs around startup
<zyga> mborzecki: in the end it was entropy
<zyga> just hitting random keys is enough to boot instantly without any timeouts
<zyga> I will have some food now and then get back to releasing this properly
<diddledan> https://forum.snapcraft.io/t/snapcraft-schema-validation-in-vscode/9609
<diddledan> \o/
<diddledan> who rocks your socks?!?
<diddledan> me! I rock your socks! *chants* I rock your socks. I rock your socks. Ess Oh See Ess.
<diddledan> I mean Ess Oh See KayEss
<Chipaca> diddledan: https://www.reddit.com/r/Jokes/comments/1pbq6b/a_spanish_man_who_spoke_no_english_went_into_a/
<diddledan> haha
<mvo> zyga: I did some smoke testing with the debian deb and all is looking well, will try to run autopkgtest now too
<Chipaca> mvo: is this on your top secret debian box with a nuclear RNG
<jdstrand> roadmr: hi! would you mind pulling the review-tools r1178?
<jdstrand> roadmr: and happy new year :)
<roadmr> jdstrand: hello! Sure, I'll queue that. Happy new year to you too!
<jdstrand> roadmr: thanks. no rush
<zyga> mvo: thank you
<zyga> :)
<mvo> zyga: autopkgtest is tricky, but I have not given up yet
<zyga> do you mean more than sbuild --run-adt
 * cachio lunch
<mvo> zyga: I wanted to run it in a separate vm, but I can try the other option too
 * zyga resumes work in the office
<Chipaca> mvo: how are we for point releases of 2.37? anything going on there?
<zyga> mvo: I added a trello card as we talked
<zyga> mvo: I feel it would be nice to have a "process" card
<zyga> not a feature, not a bug
<zyga> I mean, card label
<zyga> oh, I see there are now two cards, sorry for not looking earlier
<mvo> Chipaca: I think we will have a .1 release but no firm plans yet, it looks pretty good so far
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<Chipaca> mvo: I'll tag a low-priority pr for 2.37 then, but no biggie if it doesn't make it
<om26er> Is this statement still true for Ubuntu Core 18 as well ? "the older kernel shipped with this image can trigger Wi-Fi issues during first boot, a network cable is recommended."
<om26er> found on: https://www.ubuntu.com/download/iot/raspberry-pi-2-3
<mvo> Chipaca: sounds good, is it up yet?
<Chipaca> mvo: no
<Chipaca> mvo: writing tests
<om26er> afaik, Pi3 UbuntuCore 18 image ships Linux 4.15 (which is new enough?)
<mvo> Chipaca: ta
<mvo> om26er: UC18 ships with 4.15, I don't know about this specific problem to know if it is fixed or not, but maybe someone from the kernel team (like ppisati knows if"the older kernel shipped with this image can trigger Wi-Fi issues during first boot, a network cable is recommended."  is still accurate
<mvo> )
<cwayne> It's not accurate
<mvo> cwayne: ok, thank you
<mvo> degville: do you know who the best person is to talk to abouthttps://www.ubuntu.com/download/iot/raspberry-pi-2-3  ? the phrase "- the older kernel shipped with this image can trigger Wi-Fi issues during first boot, a network cable is recommended." is apparently no longer needed in a 4.15 kernel world (cc ppisati cwayne om26er )
<popey> (there's a bug report link at the bottom? )
<degville> mvo: I don't know for certain, but I can likely find the repo and create a PR to get it changed.
<mvo> popey: *cough* thank you
<mvo> degville: nevermind, thanks to popey I found the "bugreport" thing, I will just paste the irc conversation
<degville> mvo: ok, cool.
<degville> mvo / popey: ...although it looks like it could get lost in a sea of issues. I'll take a look and see if it's easy to change.
<mvo> cwayne, om26er https://github.com/canonical-websites/www.ubuntu.com/issues/4577
<mvo> degville: -^
<om26er> thanks mvo
<mvo> om26er: thank you for reporting this
<mvo> zyga: autopkgtest in a full debian sid vm running, fingers test
<mup> PR snapd#6411 opened: cmd/snap: wrap "summary" better <Created by chipaca> <https://github.com/snapcore/snapd/pull/6411>
<zyga> mvo: super, fingers indeed crossed :)
<Chipaca> popey: https://github.com/snapcore/snapd/pull/6411#issuecomment-456472879
<mup> PR #6411: cmd/snap: wrap "summary" better <Created by chipaca> <https://github.com/snapcore/snapd/pull/6411>
<popey> <3
<Chipaca> mvo: ^ that's the thing I think wouldn't be bad in 2.37.1
<mvo> Chipaca: ta
<Chipaca> mvo: did you get a chance to look at #6389 ?
<mup> PR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>
<zyga> mvo: I'm trying to recall the passphrase to my gpg key :|
<Chipaca> zyga: was it "Vishok7oc,"
 * Chipaca has apg and knows how to use it
<zyga> eh, I wish I used this more often
<zyga> got it :)
<zyga> whee
<zyga> and published (I changed the expiry date)
<sparkiegeek> hmm, what's the bug for SRUing snapd 2.37 into e.g. Bionic?
<zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1811233
<mup> Bug #1811233: [SRU] 2.37 <verification-done> <verification-done-bionic> <verification-done-cosmic> <verification-done-trusty> <verification-done-xenial> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Committed> <snapd (Ubuntu Xenial):Fix Committed> <snapd (Ubuntu Bionic):Fix Committed>
<mup> <snapd (Ubuntu Cosmic):Fix Committed> <https://launchpad.net/bugs/1811233>
<sparkiegeek> zyga: thanks
<sparkiegeek> ah, was hidden from search because the main task is Fix Released
<jdstrand> mvo: hey, we spoke before about policy updates for 2.37 that I'd do the week after the sprint (ie, now). It seems like 2.37 is released (I saw the disco SRU). should I postpone these for 2.38 or submit to 2.37?
<zyga> jdstrand: (responding in place of mvo): I think we are open to a 2.37.1
<zyga> jdstrand: the point of 2.37 now is to hit debian
<jdstrand> ok, well, I'll pick that up then and target both master and 2.37
<zyga> if you target master I think we can cherry pick, as long as you tag them as 2.37
<mvo> jdstrand: should hopefully be trivial, master and 2.37 are not that different yet
 * zyga EODs
<jdstrand> mvo: yeah, wasn't worried about that-- just wanted to understand your timing. thanks!
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<roadmr> jdstrand: hi! hey I notice the base declaration added two interfaces (personal-files and system-files). Do these count as "superprivileged" ones?
<roadmr> jdstrand: adding the new r1178 release of the tools made some of my tests fail because these new interfaces appeared, and are being compared against a list of so-called superprivileged ones. I can update this list, just checking with you this is expected
<jdstrand> roadmr: they are superprivileged,
<jdstrand> yes
<jdstrand> in
<jdstrand> jeez
<jdstrand> in terms of the base decl, they follow that same pattern
<roadmr> jdstrand: ok, so this seems to be copacetic then. I'll go ahead with the merge, thanks!
<jdstrand> roadmr: cool, thanks!
<mup> PR snapd#6412 opened: tests: interfaces tests normalization <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6412>
#snappy 2019-01-23
<murthy> how to know the details of a .snap file?
<mborzecki> morning
<zyga> good morning
<zyga> I need to figure out how to wake up at 6 and start the work at 7
<zyga> kids leaving at all random moments is not helping
<zyga> murthy: hello
<zyga> murthy: can you please be more specific, what is it that you would like to know?
<murthy> zyga: https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snaps-Chromium-VA-API
<murthy> zyga: cant wait till it gets published..
<murthy> zyga: I have downloaded the .snap file from launchpad website
<murthy> zyga: I would like to run the snap file
<murthy> zyga: good morning btw
<zyga> murthy: do this please:
<zyga> murthy: on a system with snapd installed
<murthy> zyga: I just saw a video and it spoiled my day already
<murthy> I am on ubuntu 18.10
<zyga> run "snap install chromium --channel=candidate/vaapi"
<murthy> zyga: so snap search wont display from candidate?
<zyga> this will install the snap from a given "channel", like a lane of development
<zyga> murthy: that's correct AFAIK
<murthy> zyga: ok, I knew about channels, but didn't know search is not done on candidate, let me try that
<murthy> zyga: full confinment means sandboxed?
<zyga> yes
<mborzecki> zyga: hey
<murthy> zyga: it says it cant find that package. shall I do sudo snap install --candidate chromium-snap-from-source-enable-vaapi   ?
<murthy> zyga: https://code.launchpad.net/~osomon/+snap/chromium-snap-from-source-enable-vaapi?_ga=2.8470321.583249682.1548065371-1544747127.1545400671
<zyga> no no
<zyga> try --channel="..."
<zyga> full name there
<murthy> zyga: can you check the above link and tell me the exact full command
<murthy> I am yet to learn stuff about snap
<zyga> sure, just hold on
<zyga> doing a few things in parallel here
<murthy> zyga: sure no problem
<mborzecki> murthy: i just installed chromium using
<mborzecki> snap install --channel=candidate/vaapi chromium
<mborzecki> murthy: what error are you getting exactly?
<murthy> mborzecki: Its installing now
<murthy> mborzecki: I tried the following earlier as suggested by zyga "snap install chromium --channel=candidate/vaapi"
<murthy> mborzecki: That gave me an error of some thing not found
<mborzecki> murthy: what was not found?
<zyga> paste the error you got
<zyga> that helps
<mborzecki> zyga: btw. connecting interfaces for chromium takes a longer while, iirc we had a pr that would bundle all apparmor updates to one, did it land?
<murthy> zyga: I think I mistyped
<murthy> mborzecki: hardware acceleration works for you with chromium?
<mborzecki> murthy: where can i test it?
<murthy> with what you installed just now and goto youtube, search for a 4k video and play it in 4k'
<murthy> mborzecki: then type  in the address bar "chrome://media-internals"
<murthy> mborzecki: you should see some thing like this "blob:https://....."
<mborzecki> murthy: mhm, it's there
<murthy> mborzecki: click that and then tell me what do you see as value for "video_decoder"
<mborzecki> murthy: VpxVideoDecoder
<murthy> mborzecki: that means no hardware acceleration
<mborzecki> maybe it's somethign about amdgpu & vaapi then
<zyga> re
<murthy> mborzecki: goto "chrome://gpu/"
<murthy> mborzecki: see whats in for video decode
<mborzecki> murthy: heh, hardware accelerated
<mborzecki> wonder if that covers vp9 too
<murthy> brb
<zyga> good morning mvo
<zyga> mvo_: so, we have a +1 from mwhudson but we must remove transitional packages as they would get axed through NEW
<zyga> I'll do that now
<mvo_> zyga: hi
<mvo_> zyga: sorry wwas not registered earlier
<r3r57> Hello, I've got http://paste.debian.net/1062047/ with several snaps (chromium, etc.). Does anyone know if this is a distribution related issue or an issue with the snap itself? Thank you in advance.
<murthy> mborzecki: I think It specifically means hardware acceleration of vp9
<murthy> Are the intel's latest drivers packaged with the chromium browser or the drivers are synced from 16.04?
<mborzecki> murthy: chromium seems to be based on core18, so it's at least the version that shipped with 18.04
<murthy> Hardware acceleration is not working for me. I even tried after enabling overide gpu blacklist flag, no good.
<mup> PR snapcraft#2440 closed: meta: make hooks executable instead of complaining they're not <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2440>
<mup> PR snapcraft#2441 closed: legacy/meta: make hooks executable instead of complaining they're not <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2441>
<murthy> bbl
<Chipaca> moin moin
<mup> PR snapcraft#2447 opened: build providers: remove SIGUSR1 signal ignore workaround for multipass <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2447>
<mup> PR snapd#6396 closed: packaging: import debian salsa packaging work and use in spead <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6396>
<mup> PR snapd#6413 opened: packaging: import debian salsa packaging work and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
<zyga> hello Chipaca :)
<pedronis> mborzecki: hi,  the maybe my forum post was confusing but the plan is really to change behavior only if there's pinned tracked for the moment, so it cannot be done in the client. Later we will have default tracks but that is something the store will report for snaps. Either way is not about the "current" track
<mborzecki> pedronis: quick HO?
<pedronis> mborzecki: can do, one sec
<pedronis> mborzecki: I'm in the standup
<Chipaca> mborzecki: thank you for the review
<mborzecki> Chipaca: yw, hopefully haven't missed anything when iterating over this on paper :)
<Chipaca> mborzecki: on... paper?
<Chipaca> pedronis: welcome back
<mborzecki> Chipaca: making sure the counts add up
<Chipaca> ah
<pedronis> Chipaca: hi
<Chipaca> pedronis: I was wondering if I should delve into a further refactoring of cmd_info, or if I should wait for a review from you today
<pedronis> Chipaca: you are talking about #6389?
<mup> PR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>
<Chipaca> pedronis: the review I'd ask for is the epochs one, if I could only ask for one :-)
<Chipaca> I mean, yes 6389 needs a review, and I tagged you for it, but #6356 is the roadmap item
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<zyga> hey pedronis :)
<pedronis> Chipaca: ah
<mup> PR snapd#6414 opened: daemon: try to tidy up the icon stuff a little <Created by chipaca> <https://github.com/snapcore/snapd/pull/6414>
<Chipaca> pedronis: fwiw 6389 doesn't _need_ a review from you, but you had Opinions :-)
<cjwatson> sergiusens: Is there a plan to SRU snapcraft 3.x?  (Re improved core18 support, sort of)
<cjwatson> sergiusens: Or indeed to have it as a .deb in Ubuntu at all
<sergiusens> cjwatson: no, we have no plans to SRU 3.x as a deb. There is a plan to SRU a 2.44 as a deb with bug fixes but that does not have the proper support for bases
<cjwatson> sergiusens: OK, so we should be looking at automatically defaulting snapcraft to the stable channel at least for core18
<cjwatson> sergiusens: Weren't you going to do a systematic build comparison to test safety of switching to the stable channel by default across the board?
<sergiusens> my proposal sent over email was to keep using the deb when not using a base and to switch to the snap when using a base so no one would break
<cjwatson> I must have missed that, since I just reinvented the same idea independently :)
<cjwatson> I think that's reasonable; the other thing we need to do in LP is to map bases to series and automatically dispatch the right one
<cjwatson> sergiusens: https://bugs.launchpad.net/launchpad/+bug/1812985 FWIW
<mup> Bug #1812985: Support snapcraft base snaps <feature> <lp-snappy> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1812985>
<dot-tobias> I have a question re: interface hooks, happy for any pointers: https://forum.snapcraft.io/t/apparmor-denial-in-interface-hook/9625
<Chipaca> zyga: do I remember right that we had a bug where hooks wouldn't always get the right interface connections?
<zyga> Chipaca: yes
<zyga> I saw that question
<Chipaca> zyga: do you remember when we fixed it?
<zyga> I think that's fixed in 2.37 but not sure
<zyga> recently
<Chipaca> zyga: this was only about inheritance, ie it could be worked around?
<zyga> Chipaca: I don't remember
<zyga> today the focus is on some other topics
<Chipaca> zyga: ð
<Chipaca> dot-tobias: I'm going afk for a while, but meanwhile you could try 2.37 in case the issue is fixed there
<Chipaca> dot-tobias: it's already in candidate :-)
<dot-tobias> Chipaca: Thanks, will do! Answering to your forum reply just now.
<Chipaca> yeah, please do, at least for posterity
<Chipaca> :-)
 * Chipaca â physio or 'the gym'
<ackk> hi, I'm having this weird issue (not the first time I hit it): https://paste.ubuntu.com/p/9Bz2YjhDkG/
<ackk> the snap is devmode,try if it matters
<ackk> anyone has a suggestion on how to debug it ?
<popey> ackk: what does "snap version" say?
<ackk> popey, https://paste.ubuntu.com/p/DDtKbbhpvB/
<popey> is that a snap that's in the store?
<popey> snappy-debug.security scanlog
<popey> run that in a terminal, do you get output while running the snap?
<ackk> popey, not really, it's a local build
<ackk> installing snappy-debug
<ackk> popey, do I run it as root?
<popey> why do you need to?
<popey> oh, misread, sorry. No.
<popey> :)
<ackk> popey, https://paste.ubuntu.com/p/sNMfxptp68/
<popey> is this a core device?
<ackk> no, a bionic LXD container
<popey> ok, do you get any output when running your snap?
<ackk> popey, it was working earlier, I just updated some files in the prime/ dir (as said it's a snap try)
<ackk> popey, other snaps work fine fwiw
<popey> perhaps strace it to see what its failing on?
<ackk> $ snap run --strace maas
<ackk> error: exit status 1
<popey> wtf
<popey> can you wormhole me the snap so i can take a look?
<popey> or the yaml
<ackk> popey, I can tarball the prime dir, not sure if you'll have the issue though
<popey> I'd rather have the snap or yaml
<popey> nothing in dmesg?
<ackk> popey, you mean the snap.yaml or the snapcraft.yaml ?
<popey> snapcraft.yaml
<ackk> popey, https://git.launchpad.net/maas/tree/snap/snapcraft.yaml
<popey> you said this works in devmode?
<ackk> yeah, it only works in --devmode
<ackk> popey, nothing in dmesg except the usal apparmor messages, but no error that I can see
<popey> are you building this in 18.04?
<ackk> yes
<popey> with the snapcraft snap
<ackk> no, with the bionic snapcraft deb
<popey> ah
<popey> you should probably move to using the snapcraft snap
<popey> the deb is ye olde and crusty
<ackk> yeah, I'll take a look at that then
<ackk> I'll also try to reinstall the snap, that usually works
<ackk> popey, thanks
<mup> PR snapd#6415 opened: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
<mborzecki> pedronis: the change is fairly confined ^^
<Chipaca> mborzecki: the move from "stable means latest/stable" to "stable means <current>/stable" is not minor, and will break / surprise people that have learned the old behaviour
<mborzecki> Chipaca: yeah, went over it with pedronis, the PR is limited only to cover pinned (kerne & gadget) tracks only
<Chipaca> mborzecki: ah :-)
<mborzecki> Chipaca: while at it, could you take a look at #6415?
<mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
<Chipaca> mborzecki: me? review stuff? madness
 * Chipaca reviews while his food cooks
<mborzecki> Chipaca: thanks
<mborzecki> off to pick up the kids
<Chipaca> hmmmm
 * Chipaca IRL hmms
<mup> PR snapd#5822 closed: wrappers: allow user mode systemd daemons <Created by jhenstridge> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5822>
<pedronis> Chipaca: did you have a chance to look again at 6034 ?
<pedronis> should we close it until you do?
<Chipaca> pedronis: I was going to and then I doubted myself so I stopped
<Chipaca> pedronis: probably need a refresher of what needs changing, as all I remembered was "make it clearer that it's only per-snap not per-revision"
<pedronis> Chipaca: no new tasks as well (if possible)
<Chipaca> ah, forgot about that. I'll look now after the standup.
<Chipaca> thank you
<pedronis> Chipaca: also think what we would do if we grew per revision stuff like thus
<Chipaca> pedronis: and add a note about it?
<pedronis> Chipaca: yes
<Chipaca> pedronis: one thing I wondered was whether this and sequence aren't the same thing
<pedronis> Chipaca: this?  you mean that?
<pedronis> this is about per-snap
<Chipaca> pedronis: but sequence is per revision, so that's that half of it
<Chipaca> :)
<Chipaca> pedronis: I mean SnapSeqDir
<Chipaca> yeh
<Chipaca> it's a weird thing :)
<pedronis> I forgot about that
<pedronis> Chipaca: it's used only for rollback in the new core18 bootstrap support, no?
<Chipaca> pedronis: I mean, snap seq dir, is essentially a cache of per-revision side info
<Chipaca> except each json has the whole sequence of sideinfos
<Chipaca> e.g. https://pastebin.ubuntu.com/p/pnRbYThvHp/
<Chipaca> that's probably more  than is needed for that feature
<Chipaca> anyway. Standup coming up.
<cjwatson> sergiusens: quick question for you in https://bugs.launchpad.net/launchpad/+bug/1812985, since I see you aren't subscribed to it
<mup> Bug #1812985: Support snapcraft base snaps <feature> <lp-snappy> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1812985>
<mup> PR snapcraft#2447 closed: build providers: remove SIGUSR1 signal ignore workaround for multipass <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2447>
<zyga> I'll do something about the room, it's too cold here
<mup> PR snapcraft#2448 opened: Swap yaml schema document with json equivalent <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2448>
 * zyga -> lunch
<mup> PR snapd#6416 opened: snap: really run the RunSuite <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6416>
<diddledan> I love commit messages like that
<diddledan> other messages that are fun are "fix the tests so they don't fail"
<cwayne> Best ones are "I don't know what this does"
<diddledan> there totally needs to be a way to test testsuites without the program you're testing because without being sure your test suite is sane you can't be sure that the problem is in your project or the project's tests
<diddledan> "I have no idea what these changes are.. I made them ages ago and didn't commit them. they must be important or I wouldn't have left them in the source"
 * diddledan reboobs to Winders
<mup> PR snapd#6417 opened: snap: fix reexec from the snapd snap for classic snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6417>
<mup> PR snapd#6418 opened: many: allow core as a fallback for core16  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<sergiusens> \o/
<sergiusens> mvo: ð§ ð
<mvo> sergiusens: :)
<mvo> sergiusens: I had hoped you would like it
<Chipaca> I'm going to EOD in a few minutes; a little early, and I might be back later tonight. Need to say goodbye to a friend.
<sergiusens> Chipaca: good bye!
 * sergiusens assumes that _a_ friend could be _any_ friend
<sergiusens> mvo: I took a quick glance at the PR, this does not solve `snap install core16` installing `core`, correct?
<mvo> sergiusens: if you "snap install core16" you still get that, that seems to be ok, no?
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<SlidingHorn> anyone else having an issue with the icon in Discord missing within the past few days or so?
<SlidingHorn> (snap version, obviously)
<mup> PR snapd#6419 opened: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6419>
<mup> PR snapd#6420 opened: miscellaneous policy updates - 2.37 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6420>
<mwhudson> um i wonder what happened here https://launchpadlibrarian.net/407843985/buildlog_snap_ubuntu_xenial_amd64_go110_BUILDING.txt.gz
<mwhudson> does snapcraft.BasePlugin.run invoke things via sh?
<mwhudson>         self.run(['./make.bash'], cwd=os.path.join(self.builddir, 'src'), env=env)
<mwhudson> is failing with
<mwhudson> /bin/sh: 24: exec: ./make.bash: not found
<mwhudson> ./make.bash
<mwhudson> Failed to run './make.bash' for 'built': Exited with code 127.
<mwhudson> this worked yesterday :)
<mwhudson> same snapcraft version
#snappy 2019-01-24
<mup> PR snapcraft#2442 closed: cli: enable cleaning of parts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2442>
<mborzecki> mornig
<mup> PR snapd#6416 closed: snap: really run the RunSuite <Simple ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6416>
<zyga> good morning
<mvo> hey zyga
<zyga> hey
<zyga> debian drama dramas on
<mvo> zyga: oh?
<jamesh> zyga: hi.  When you have time, could you have a look at https://github.com/snapcore/snapd/pull/6313?  It adds some spread tests for xdg-desktop-portal/xdg-document-portal integration (only running on a subset of backends where I know it works currently)
<mup> PR #6313: tests: add a tests for xdg-desktop-portal integration <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6313>
<zyga> mvo: it failed to build in debian
<zyga> mvo: unpackaged file
<mvo> zyga: do you have a link?
<zyga> jamesh: hello
<jamesh> I know you were working on user mounts improvements, so this should ensure the behaviour I care about continues to work :-)
<mvo> zyga: yeah, curious, we test build it
<zyga> jamesh: I will look for sure, there are two high priority items still on my plate but I promise to review this by EOD
<mborzecki> mvo: zyga: hey
<zyga> mvo: I just ... no idea
<jamesh> zyga: thanks.  I'd also like to talk about the user daemons/dbus activation PRs at some point
<jamesh> (mainly about how to proceed forward with them)
<zyga> jamesh: I think we should have a call with samuele to sync on where we are and what the challenges are
<zyga> jamesh: we have some things in the roadmap that incresingly require session level interaction
<mvo> hey mborzecki
<jamesh> zyga: having our PRs closed without consultation irks me a bit.  Among other things, it cuts me off from CI.
<zyga> jamesh: closed?
<zyga> jamesh: that's understandable, I don't think we should close them out of the blue
<jamesh> zyga: this one: https://github.com/snapcore/snapd/pull/5822
<mup> PR #5822: wrappers: allow user mode systemd daemons <Created by jhenstridge> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5822>
<zyga> I see
<zyga> I think you need to discuss with samuele, he has some catchup to do after last week and ubuflu but I'm sure we can have a reasonable conversation
<jamesh> yeah.  I'll see if I can catch up with him later today.
<zyga> good luck!
<pedronis> jamesh: sorry, but we do close PRs from time to time if they cannot land, it's unclear when, and discussion is better not in them. I'm wary of having things that are "services" but don't fit the out whole services picture, for example what should "snap services" show about these? does it even work on the PR?
<pedronis> jamesh: these things need a proper design on the forum
<zyga> jamesh: do you have access to spread?
<zyga> perhaps the real issue is that you just need a key to run spread tests and iterate at will locally
<zyga> proposing only those chunks that are ready to be discussed / reviewed and are relatively close to landing
<pedronis> zyga: to be clear I don't think until I  see a consistent whole picture, I wouldn't take chunks either
<zyga> right, but I believe, based on what jamesh said above, that having open PRs is an important part of the workflow because that's his (apparently) only way to access CI
<zyga> does https://groups.google.com/forum/m/#!topic/golang-announce/mVeX35iXuSw affect us?
<mborzecki> zyga: don't think so
<mup> PR snapd#6421 opened: spread: enable upgrade suite on fedora <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6421>
<mborzecki> trivial PR ^^^
<mborzecki> can't reproduce the mount problem using the usual install/remove loop
<mvo> mborzecki: thanks for looking into that again
<mvo> mborzecki: this makes me wonder if something external is doing the systemctl reload during the tests
<mborzecki> mvo: 50 loops of install remove with the script we use in the protocol error test
<mborzecki> mvo: there is, on core 18, there's a job that's constatnlty failing and getting restarted
<mborzecki> mvo: serial-console-conf@ttyS0.service keeps being restarted
<mvo> mborzecki: oh, what job is that?
<mvo> mborzecki: interessting
<mvo> mborzecki: are all protcol errors we have observed recently on core18?
<mborzecki> mvo: afaik yes
<mvo> mborzecki: thats a very interssting clue then
<mborzecki> mvo: though there's this note in the forum https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682/27
<mvo> mborzecki: interessting
<mborzecki> mvo: otoh, the travis jobs i restarted were core18
<mvo> mborzecki: well, if there is activity (e.g. apt installing stuff or unattended-upgrades) in the background
<mvo> mborzecki: that may happen
<mvo> mborzecki: and there is nothing we can do :(
<mborzecki> Chipaca: morning sir
<mborzecki> mvo: hm shouldn't we touch /var/lib/console-conf/complete when preparing core18 image for tests?
<mvo> mborzecki: yes, is that missing?
<mborzecki> mvo: it is
<mvo> mborzecki: in practise it shouldn't make a difference but if it fixes the crashâ¦
<mborzecki> mvo: the unit has ConditionPathExists=!/var/lib/console-conf/complete so it should make it go away
<Chipaca> mborzecki: mo'in
<mvo> mborzecki: cool, lets add this in any case to our testsuite
<jamesh> pedronis: sorry.  Was out for a ride before it gets dark.  My point is that when you close a PR there is no way for the author to reopen it, and Travis will no longer run tests if they update it
<mborzecki> Chipaca: was your concern here https://github.com/snapcore/snapd/pull/6415#discussion_r250187805 that we accept BS channel input and let it reach the store eventually?
<mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
<Chipaca> mborzecki: no, I want whatever works with --channel=stable to also work with --channel=stable/hotfix-1234
<Chipaca> mborzecki: having --stable say "yeah you meant the pinned track" and --channel=stable/hotfix-1234 say "you can't change tracks what are you evil", is wrong imho
<Chipaca> mborzecki: i'm going to get more coffee and then re-review your pr though
<mborzecki> Chipaca: i see, i'm not sure then whether <risk>/<branch> would count as risk only request
<mborzecki> Chipaca: i does sound reasonable to me, but maybe it's really a question for pedronis
<pedronis> mborzecki: I agree with Chipaca here
<pedronis> it's the consistent thing
<mborzecki> pedronis: ok, sounds good to me
<Chipaca> mborzecki: i'll hold off on that review then
<mborzecki> ack
<ogra> ondra, https://docs.snapcraft.io/architectures/4972
<mup> PR snapd#6422 opened: tests/prepare: prevent console-conf from running <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6422>
<mborzecki> mvo: ^^
<ogra> mborzecki, wheee !!!! i love you !!!
<ogra> (only took a year :P )
<mborzecki> ogra: hahah so this was discussed before already?
<ogra> mborzecki, https://forum.snapcraft.io/t/disabling-console-conf-from-gadget-or-core-config-option/4358
<ogra> oh, your PR is only for the tests ... i thought it was also for runtime
<mborzecki> ogra: don't want to disappoint you but the pr is only to workaround a problem we see in the tests
<ogra> *snap*
<ogra> :)
<mborzecki> ogra: maybe try necrobumping the topic if it's a high priroity for you guys
<pedronis> mborzecki: it's on the list of things to desing on the way to core20
<pedronis> (how to opt out of console-conf)
<mborzecki> ah, even better
<ogra> it isnt super high, but when talking to security aware customers we get questions ... since yu can just attach a serial cable today and run through console conf to gain access
<ogra> so hacks are required to disable it
<mborzecki> anyone with manjaro vm?
<mup> PR snapcraft#2449 opened: Release changelog for 3.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2449>
<Chipaca> mborzecki: locate -i manjaro finds only pull requests from you (and the kilimanjaro wonder from civ v)
<mborzecki> hm a snap gets an interface auto connected, then it gets manually disconnected, now it's correctly shown as undersired, later i reconnect the interface, and the state information indicates that the connection is manual
<popey> (also, when you refresh, your disconnected interface gets re-connected)
<mborzecki> popey: that should have been fixed already
<zyga> break :)
<zyga> but some good news :)
<pedronis> mborzecki: did you see my question btw, https://forum.snapcraft.io/t/rfc-snap-connections-command/4296/15
<mborzecki> pedronis: yes, but it's a snap command thing, so it'll end up in 6079
<pedronis> mborzecki: well, it seems there was an ongoing discussion in the forum which seems good to try to conver in the forum
<pedronis> *converge
<mborzecki> 6421 spread run failed in tests/main/searching, looks like 'video' section is gone from the store?
<mborzecki> we were unfortunate to do  `snap find --section=video vlc | MATCH vlc` in the test
<mborzecki> pedronis: Chipaca: do you know anything about that?
<pedronis> mborzecki: I think some sections have been renamed
<mborzecki> looks like it's photo-and-video now
<pedronis> yes
<cachio> mborzecki, I'll update the test
<mup> PR snapd#6423 opened: tests/main/searching: video section got renamed to photo-and-video <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6423>
<mborzecki> cachio: opened a PR just now
<mborzecki> ^^
<cachio> mborzecki, great
<cachio> I'll take a look in that case
<mborzecki> off to pick up the kids
<Chipaca> hmm
<Chipaca> we could automate that kind of thing sooon
<ondra> sergiusens is there any  variable I can use in custom pluging which will give me target architecture?
<pedronis> Chipaca: some comment on #6389
<mup> PR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>
<ondra> sergiusens when I will use architectures: build-on: amd64 run-on:arm64
<Chipaca> pedronis: noted
<ondra> sergiusens shall I expect self.project.kernel_arch to give me target arch of the device?
<Saviq> hey, is it possible to use snapd with squashfuse? I'm in an unprivileged container so the loop device dance is prevented
<Saviq> I may ask for some additional caps to the container, but would rather not if it can work without that
<mup> PR snapd#6424 opened: tests: remove -o pipefail <Created by mvo5> <https://github.com/snapcore/snapd/pull/6424>
<Chipaca> Saviq: yes, snapd uses squashfuse if it detects the need of it
<Saviq> ok my container was missing /dev/fuse
<Chipaca> Saviq: https://github.com/snapcore/snapd/blob/master/osutil/squashfs/fstype.go#L32
<Saviq> Chipaca: yup, mount worked now, but it's a Debian kernel, Ubuntu container... how does snapd decide whether to enable apparmor confinement or not?
<Chipaca> Saviq: black magic
<Chipaca> or, maybe ask zyga :-)
<Saviq> same thing, isn't it?
<Chipaca> Saviq: snapd will print what it thinks it's got when it boots
<Chipaca> Saviq: some of it is auto-detection, some of it is manual
<Chipaca> AFAIR
<Chipaca> Saviq: e.g., Jan 14 17:49:13 fleet snapd[1789]: AppArmor status: apparmor is enabled and all features are available
<Saviq> AppArmor status: apparmor is enabled but some features are missing: dbus, network
<Chipaca> Saviq: (from 'journalctl -u snapd')
<Chipaca> that sounds like debian's kernel
<Saviq> but then https://pastebin.ubuntu.com/p/GXt5yrBGgn/ :/
<Chipaca> Saviq: zyga and/or jdstrand might know more about that
<mborzecki> cachio: i think you need to purge /var/cache/snapd/sections for snapd to grab the most recent list of sections in the store
<Saviq> ack tx
<cachio> mborzecki, ah
<cachio> ok
<sergiusens> ondra: look at the "project" object the plugin gets passed, it has deb_arch and arch_triplet properties
<ondra> sergiusens self.project.arch_triplet: x86_64-linux-gnu self.project.deb_arch: amd64
<ondra> sergiusens that seems wrong, since snap has only arm64 architecture as supported
<sergiusens> I don't know how to connect those two statements
<ondra> sergiusens I have this in snapcraft.yaml https://paste.ubuntu.com/p/kZwXp2ZKyG/
<ondra> sergiusens when I build on amd64 to arm64
<ondra> sergiusens I get https://paste.ubuntu.com/p/vNdtqsyJKd/
<ondra> sergiusens basically even with that architecture statement, I still have to use --target-arch to get right result. Is there any variable which would reliably give me target architecture
<ondra> sergiusens any thoughts?
<mup> PR snapd#6383 closed: tests: provide a fake random device to the core images <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6383>
<ondra> sergiusens shall I assume whole architecture: build-on run-on is half baked and not to be used?
<cachio> mvo, hey, I tried the pipefail cahnge but debian sid still fails
<cachio> mvo, is it needed something else
<cachio> ?
<sergiusens> ondra: the first part is for automated build systems, the latter is to tell consumers where it runs
<sergiusens> but it is up to the developer to make the right thing happen wrt where it runs
<ondra> sergiusens sure, but there should be way to tell what is target architecture
<sergiusens> that is still not there, that is the from-to language which is not there
<ondra> sergiusens I would expect project.target_arch to hold right value
<ondra> sergiusens if I do not speciffy --target-arch it's empty
<sergiusens> that might be a bug, but for now you can check if it is empty and use deb_arch instead
<ondra> sergiusens deb_arch is set to host
<ondra> sergiusens so without --target-arch it does not work
<sergiusens> ondra: ok, please write up a detailed forum post, you are feeding me drops of information on what you want to do and it is micro interrupting a bit too much
<ondra> sergiusens it gives wrong value
<sergiusens> not sure if there is a complaint, an action or what...
<ondra> sergiusens so there is no value which would give me snap target architecture and I would be able to use it in plugin?
<ondra> sergiusens because this is really only thing I need
<sergiusens> ondra: forum
<ondra> sergiusens geee, this is really not helpful
<ondra> sergiusens elt
<sergiusens> ondra: bug then
<ondra> sergiusens forum is slow for conversation, but let's see how quick you gonna reply there
<sergiusens> ondra: I have a hard time understanding your objective every time I am pinged by you on IRC
<sergiusens> well, I am doing other things now, so I am not really thinking about your problem
<mborzecki> #6423 anyone? this will unblock the PRs
 * cachio lunch
<mup> PR #6423: tests/main/searching: video section got renamed to photo-and-video <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6423>
<ondra> sergiusens simple question: is there value which would give me snap target architecture and I would be able to use it in custom plugin?
<sergiusens> ondra: simple answer, I need to look at the code, from my point of view, cross compilation is experimental
<ondra> sergiusens ok
<narutowaifu> hi, I've installed "lxd" on my debian stable using snapd.    `snap --version` shows 2.36.3  and  `lxd --version` shows 3.6. The latest version however should be 3.9. If I run `snap refresh` it says  "All snaps up to date".  Why is it not updating to 3.9? Any help? Thanks
<roadmr> narutowaifu: what does "snap info lxd" say? does it show 3.9 as available in the channel you're tracking?
<mvo> cachio: oh, meh
<mvo> cachio: let me check
<Chipaca> narutowaifu: also, what does 'which lxd' say
<mup> PR snapd#6423 closed: tests/main/searching: video section got renamed to photo-and-video <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6423>
<narutowaifu> roadmr: snap info lxd => installed: 3.6, stable: 3.9       Chipaca: which lxd => /snap/bin/lxd
<Chipaca> narutowaifu: snap info lxd | grep tracking
<narutowaifu> Chipaca: tracking: stable
<Chipaca> narutowaifu: ok. can you enable debug in snapd and do a refresh?
<narutowaifu> how do i enable debug
<Chipaca> narutowaifu: https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/2?u=chipaca
<mup> PR snapd#6425 opened: interfaces: add yubikey interface and allow reading /run/udev/data/+power_supply:* <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6425>
<jdstrand> oSoMoN: there you go ^
<narutowaifu> Chipaca: I can see the requests to api.snapcraft.io. What should I look for?
<Chipaca> narutowaifu: after the request there should be a json thing that starts with DEBUG: < (it can span multiple journal lines)
<Chipaca> narutowaifu: i'm interested in that
<Chipaca> narutowaifu: that is the response from the POST request; you might have other requests that are updating assertions that i'm less concerned with
<Chipaca> narutowaifu: do not pastebin the ones that start DEBUG: >, as those can contain macaroons
<Chipaca> but, yeah, if you could  pastebin the store response, it might shed some light on what's going on
<Chipaca> (the request could also, but i'd have to help you clean the macaroons out first)
<narutowaifu> what are macaroons?
<Chipaca> narutowaifu: like cookies, but more delicious
<Chipaca> narutowaifu: in this case, cryptographically fancy cookies
<oSoMoN> jdstrand, thanks! looking
<cachio> mvo, I just pushed the change
<cachio> mvo, I am adding more information to the documentation needed to run beta validation
<zyga> https://tracker.debian.org/pkg/snapd
<zyga> only too young exception1
<zyga> great :)
<popey> \o/ <3
<mvo> cachio: thank you
<mvo> zyga: yay
<zyga> indeed, this is a good thing :0
<zyga> :)
<mvo> cachio: thanks for the removal of pipefail, I will watch how it fails
<mvo> cachio: if it fails, maybe there is more, we will see
<cachio> mvo, also a mount error on amazon-linux https://paste.ubuntu.com/p/qZkkh97gpW/
<mvo> cachio: I had to also add some more bits to debian https://github.com/snapcore/snapd/pull/6413/commits  (the commits from today are relevant)
<mup> PR #6413: packaging: import debian salsa packaging work and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
<mvo> cachio: meh, thanks! the mount error is really unfortunate that its still there :( oh well
<cachio> mvo, yes, it mutates like a virus :)
<mvo> cachio: indeed, not pipefail :( I see the error with the missing match even without that now too
<sergiusens> cachio: is there a way to have spread add a summary of what ran passed or failed and what was skipped at the end of a run? I am interested in knowing I did not accidentally filter anything out.
<cachio> sergiusens, you want to see the skipped ones, right?
<cachio> sergiusens, if you want that, with the current spread implementation is not possible
<sergiusens> cachio: I bet you want that too to make sure you aren't messing up your filters by accident ð
<sergiusens> and yes, that is exactly what I want to see
<Chipaca> narutowaifu: FWIW, macaroons are https://ai.google/research/pubs/pub41892
<mvo> cachio: I play with some ideas right now about journalctl, all a bit annoying
<cachio> sergiusens, well, so far you need to create an script to check results
<sergiusens> cachio: you have that? I might pick your brain during our flight to Malta. I do not want to duplicate work
<cachio> sergiusens, hehe
<cachio> I don't have it
<cachio> I could create something but after my vacations
<cachio> sergiusens, first should be nice to have the tests report branch merged
<cachio> so it is possible to export the test restuls in json or xml format
<cachio> then it is much easier to parse that
<cwayne> We have some scripting around converting it to junit
<cwayne> For our Jenkins jobs running spread
<cachio> cwayne, I have a PR in spread for that too :(
<cachio> I think we could make a session on malta to see which features are desired in spread
<cwayne> +1
<mup> PR snapcraft#2450 opened: pluginhandler: handle removal of inconsistent files <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2450>
<mup> PR snapd#6426 opened: cmd/snap-confine: refactor and cleanup of seccomp loading <Created by zyga> <https://github.com/snapcore/snapd/pull/6426>
<Chipaca> zyga: you around?
<zyga> ish
<zyga> scrambled eggs brb
<cachio> mvo, is it ok to promote the core18 to candidate?
<zyga> I'll make food for Iza and brb
<mvo> cachio: did you check with foundations, I think they should do these promotions nowdays (core18)
<cachio> mvo, I'll ping them to do it
<cwayne> They have our +1 already
<cachio> from our side and CE everything ok
<cachio> ready
<cwayne> cachio: sil2100 is your guy for that
<cachio> cwayne, yes
<mvo> cachio: great
<Chipaca> zyga: mvo: looks like auto-refresh is busted for devmode distros
<Chipaca> super easy to reproduce the bug
<zyga> "fun"
<zyga> totally busted/
<Chipaca> 1. install debian
<Chipaca> 2. install a snap that has different revisions in different channels
<Chipaca> 3. snap switch the snap to a different channel (one that has a different revno)
<Chipaca> 4. snap refresh
<Chipaca> repeat 4 as many times as you want, it ain't gonna happen
<Chipaca> explicitly saying 'snap refresh thesnap' works
<Chipaca> all hail narutowaifu for finding it and pointing us to it, fwiw :-)
<Chipaca> 2. is actually "apt install snapd && snap install thesnap"
<zyga> Chipaca: if you have patches we should strive to land them for .1
<zyga> and we should get debian out of devmode
<zyga> to behave like opensuse
<Chipaca> interestingly if you do 'apt install snapd && snap install core && snap install thesnap', it doesn't happen
<zyga> broken reexec?
<Chipaca> so it's a bug in the old snapd that debian ships, that's fixed in stable
<Chipaca> zyga: reexec only works after it has something to reexec to
<zyga> right
<Chipaca> the old one is setting up the tasks wrong it seems
<Chipaca> new one fixes
<Chipaca> but doesn't know to fix old broken ones
<Chipaca> so
<Chipaca> er
<Chipaca> stgraber: ping
<zyga> offtopic, what's up with master?
<Chipaca> stgraber: with your instructions to install lxd on debian, people won't ever get updates
<zyga> is master red/
<zyga> red red red
<zyga> or just in my broken PRs?
<zyga> Chipaca: it's good that 2.37-3 is heading to debian
<Chipaca> stgraber: bug is on our side, but if you change your instructions for them to install 'core' explicitly before installing lxd, you work around it
<Chipaca> stgraber: (yes we're fixing it but the problem is in the packaged snapd, so it's slow to release the fix)
<Chipaca> zyga: wrt red, might it be because of the changed sections?
<zyga> dunno, got a log that barfed on me
<zyga> much too much stuff at once today
<Chipaca> hmm
<narutowaifu> ah stgraber is here? Thanks for adding the btrfs docs
<mvo> zyga: you may need to merge master
<zyga> mvo: aha
<mvo> zyga: there was this category change today in the store that broke tests
<zyga> thank you
<sergiusens> cachio: cwayne please add me to that session
<mvo> cachio: just fyi, with https://github.com/snapcore/snapd/pull/6413/commits/5a7d450f90e4d325b9463e1254819fa4fe644e8a debian-sid passed locally now, its still strange that export/grep is so unreliable in systemd 240
<mup> PR #6413: packaging: import debian salsa packaging work and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
<cachio> mvo, nice
<cachio> I'll run it here too
<cachio> thanks for that
<mvo> cachio: I hope to find some time (tomorrow?) to look into this, it smeels like an upstream bug and shouldn't be too hard to reproduce (famous last words :)
<cachio> mvo, yes, agree with that
<cachio> mvo, I tried updating the journal and systemd config but didn't work
<cachio> mvo, by know increasing the polling time works
<cachio> but we need to figure out the problem
<cachio> that should be temporal
<mup> PR snapd#6427 opened: interfaces: add block devices interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6427>
<mup> PR snapd#6428 opened: interfaces: add display-control interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6428>
#snappy 2019-01-25
<zyga>  Hello
<zyga> :)
<zyga> man it's all snowy white today :)
<mborzecki> morning
<zyga> hey mborzecki, mvo
<zyga> I almost typed "hey mup", but we don't greet mup :/
<mvo> hey zyga
<mborzecki> mvo: zyga: hey
<mvo> hey mborzecki
<mborzecki> 61 PRs
<mup> PR snapd#6429 opened: Bboozzoo/section rename 2.37 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6429>
<mborzecki> mvo: ^^ need this for 2.37 branch too
<zyga> I will do some reviews today
<jamesh> hi mvo, zyga
<mvo> hey jamesh
<mvo> mborzecki: ok, I have a look and will cherry-pick
<mborzecki> mvo: opened a PR to 2.37
<mvo> mborzecki: I also need to cherry-pick the find fix
<mborzecki> mvo: but feel free to close if you prefer to cherry-pick and push manually :)
<mvo> mborzecki: yeah, did cherry pick some minutes ago, but still thanks for noticing
<mup> PR snapd#6429 closed: tests/searching: handle renamed video section <Simple ð> <Created by bboozzoo> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6429>
<zyga> hey jamesh
<mup> PR snapd#6348 closed: snap: split alignment calculation and display for channels <â Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6348>
<mborzecki> Chipaca: pedronis: updated #6016
<mup> PR #6016: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
<Chipaca> mborzecki: oh no! now what do I do with my "z" snap?
<mborzecki> Chipaca: you make it go zzz
<Chipaca> about half of my registered names are answers to "i wonder if the whole stack catches me trying to register this name we decided was invalid"
<Chipaca> (hint: mmmmmmaybe?)
<mborzecki> Chipaca: btw. we allow 2 letter names right? :P plenty of combinations
<mborzecki> Chipaca: pushing a little tweak, dropped *Name suffix where it seemed a bit sueprfluous given that the package is called 'naming'
<Chipaca> hmm
 * Chipaca looks
<Chipaca> yes that works
<jamesh> mvo: where do you want to have the meeting?  IRC, hangouts, something else?
<mvo> jamesh: meet should be ok, I sent you an invite
<mvo> jamesh: sorry that it was not on the original thing
<pedronis> mborzecki: hi, Q for you in 6016
<mborzecki> pedronis: right, i tried to keep the diff size under control, so introducing the package and indirection felt right as a first step
<Chipaca> pedronis: with removing the store info cache (btw any better names appreciated) from being tasks, I'm moving them out of backend and into snapstate itself (like seq is already), ok?
<pedronis> Chipaca: it's fine out backend
<pedronis> mborzecki: can you work on a follow up to remove the indirection ones when you havea bit of time
<Chipaca> pedronis: should I read that as "it's fine not in backend"?
<pedronis> Chipaca: yes
<Chipaca> pedronis: ok :-)
<pedronis> missing a "of", at least
<Chipaca> pedronis: spent a little time with nltk looking for the intersection between synonyms of 'container' and 'blob', with no luck
<mborzecki> pedronis: sure :) planned to do it all along
<pedronis> Chipaca: ok, seems "naming" is reasonable tough
<Chipaca> pedronis: yes <3
<pedronis> Chipaca: did you see my #6389 comment ?
<mup> PR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>
<Chipaca> pedronis: yes
<Chipaca> pedronis: thank you
<Chipaca> pedronis: need to get to that yet
<pedronis> ok
<zyga> FYI I will be away for the next few hours,
<mborzecki> oh, codecov is back
<mup> PR snapd#6421 closed: spread: enable upgrade suite on fedora <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6421>
<pedronis> Chipaca: looked at #6356, doesn't seem inline with the requirements, what we discussed originally
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<sil2100> mvo: hey! Did you see Pat's and Cody's e-mail about trusty snap preseeding? I'm not really knowledgable in these areas and thought maybe you had some leads/ideas
<oSoMoN> how do I build a core snap from a PR that adds a new interface, to test it locally?
<mvo> sil2100: I did see it, but haven't managed to look at it yet :(
<sil2100> mvo: busy times, no worries! It might be something wrong from the image build POV, but I'd like a snappy expert to first take a look and see if there's anything obviously wrong there
<mborzecki> Chipaca: /var/lib/snapd/sequence is something from snapshots?
<Chipaca> mborzecki: nop
<Chipaca> mborzecki: it's a cache of <snapstate>.Sequence
<Chipaca> used for recovery iirc
<mup> PR snapd#6427 closed: interfaces: add block-devices interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6427>
<mborzecki> Chipaca: hm, didn't notice this before, snapd arch package does not clean it up properly for some reason
<Chipaca> mborzecki: missing diff in cmd/snap-mgmt/snap-mgmt.sh.in ?
<mborzecki> Chipaca: nah, it's not accounted for in the package, so removing the package leaves the dir behind
<mborzecki> Chipaca: snap-mgmt only removes /var/lib/snapd/sequence/*
<Chipaca> mborzecki: when you get a diff, show me? because I need to do something similar for /var/cache/snapd/store i suspect
<Chipaca> mborzecki: unless you mean it doesn't remove the director itself?
<mvo> 6408 needs a second review, hopefully simple
<mborzecki> Chipaca: snap-mgmt removes all of /var/cache/snapd/*
<mup> PR snapd#6424 closed: tests: remove -o pipefail <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6424>
<Chipaca> mborzecki: why doesn't it remove all of /var/lib/snapd?
<mborzecki> Chipaca: because fedora packaging takes care of this with %dir entries in rpm spec
<mborzecki> Chipaca: there is no equivalent on arch, so dirs are precreated when package is built and then automatically revmoed by pacman
<zyga> re
<mborzecki> mvo: got a node when console-conf@ttyS0 keeps restarting
<mvo> mborzecki: what is the systemctl status / jounralctl log output?
<mvo> mborzecki: any interessting error message
<mup> PR snapd#6408 closed: tests: add spread test for system dbus interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6408>
<mborzecki> mvo: no, the log is rather useless https://paste.ubuntu.com/p/CHH2m9k6t5/
<mborzecki> mvo: hm looking at the full log, there might be a pattern though
<mvo> mborzecki: how did you trigger it?
<mvo> mborzecki: my naive way did not work :/
<mborzecki> mvo: https://paste.ubuntu.com/p/qyGfvxNrmh/
<mvo> mborzecki: aha, maybe different machines
<mborzecki> mvo: notice how reloads are interleaved with console-conf restarting
<mvo> mborzecki: indeed
<mvo> mborzecki: that looks suspicious
<mborzecki> mvo: note, i'm installing and removing 11 snaps in parallel in a separate shell
<mvo> mborzecki: interessting
<mvo> mborzecki: is this all the logs we get? Jan 25 11:24:45 jan251115-985265 systemd[1]: serial-console-conf@ttyS0.service: Failed with result 'exit-code'. is really not helpful, not even the exit code numbe
<mvo> r
<mborzecki> mvo: yup
<mvo> mborzecki: nothing in journalctl -u serial-console-conf@ttyS0.service or systemctl status -l serial-console-conf@ttyS0.service :( sad
<mvo> mborzecki: I guess you can't strace it as this all happens too quickly?
<zyga> mvo: what is the value you saw from exit code?
<mvo> zyga: looking at the logs from mborzecki I see nothing there
<mup> PR snapd#6430 opened:  tests: enable debian sid as part of the main suite on travis <Created by mvo5> <https://github.com/snapcore/snapd/pull/6430>
<mborzecki> mvo: heh, reloading daemon makes console-conf fail, wtf?
<mvo> mborzecki: yeah, that is â¦ unexpected
<mborzecki> mvo: https://paste.ubuntu.com/p/ZsCjMDdQNC/ confole-conf-wrapper started by agettu
<mborzecki> mvo: fd 0 is /dev/ttyS0
<mborzecki> mvo: another one showing what it writes to stderr https://paste.ubuntu.com/p/ht5v7QhPxC/
<mvo> zyga: do you know/remember the switch to drive sbuild so that it is as close as possible to the buildds?
<mvo> mborzecki: aha, nice
<zyga> you have to change .sbuildrc
<mvo> mborzecki: "write(2, "/usr/share/subiquity/console-conf-wrapper: line 62: read: read error: 0: Resource temporarily unavailable\n", 106) = 106"
<zyga> to build arch indep separately AFAIK
<zyga> mvo: but I strongly recommend something else
<zyga> mvo: please look at and improve this: https://github.com/snapcore/snapd/pull/6410
<mup> PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
<mvo> zyga: well
<zyga> you can test it there :)
<zyga> it's just a fire&forget
<mvo> zyga: I'm looking at a spread test
<zyga> (for experimenting)
<zyga> I mean, to get to the point where we can be certain 2.37-2 reproduces the failure
<zyga> just feed the 2.37-2 package to this script
<zyga> and see if it fails
<mvo> zyga: the arch indep ?
<zyga> if so, that's representative of what we know so far
<zyga> yes
<mborzecki> mvo: yeah, then it proceeds to run stty, waits for it, waits for any children and exits, maybe it's how this works? the sequence seems legit
<mvo> zyga: but that is "just" doing a normal sbuild without any extras, no?
<zyga> correct
<zyga> I suggested that as a vehicle to find out which setting in sbuild controls this to reproduce the failure
<mvo> zyga: we did this as well and for us it did not fail
<zyga> I think it's just one of the variables you can set there
<mvo> zyga: aha, ok
<zyga> I don't know the answer from the top of my head
<zyga> sorry :/
<zyga> I just recall reading the example file
<zyga> and this is something you can tweak there
<zyga> I believe we need to run a pair of builds then though
<mvo> zyga: all parts of the example are commented out :/
<zyga> maybe               --no-arch-all
<zyga> http://manpages.ubuntu.com/manpages/bionic/man5/sbuild.conf.5.html
<zyga> by default they are built
<mvo> zyga: yeah, I play around, thank you
<mvo> zyga: but lunch first :)
<zyga> I mainly recommended that script because you  can get to the part where you can tinker easily
<zyga> and it is reproducible
<zyga> mvo: the thing is https://salsa.debian.org/debian/snapd/commit/7991e731c068148de7ae1b9e99d8df4e6f45601e
<zyga> --no-arch-any
<zyga> that's what you need
<Chipaca> pedronis: pushed changes to the store info cache. This change makes it a lot smaller; need to update the description though
<Chipaca> pedronis: but, one more change I think I should make: I should make the cache be per snap id, not per  snap name
<pedronis> Chipaca: sounds reasonable
<Chipaca> pedronis: making it per snap name would  be more friendly but not sure if we care
<Chipaca> could include the name in the json if that helped? (would it?)
 * Chipaca thinks it'd be fine as is but with snap id
<pedronis> Chipaca: we don't want people to rely on this, so it shouldn't matter
<pedronis> Chipaca: I mean, it should be a snap detail, not something people use, no?
<pedronis> *snapd detail
<Chipaca> right
<Chipaca> and tomorrow we couold change it to be a sqlite or something
<pedronis> yes
<pedronis> mborzecki: reviewed 6333
<mborzecki> pedronis: thanks
<pedronis> mborzecki: anything blokcing #6403 ?
<mup> PR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
<mborzecki> pedronis: not really
<mborzecki> mvo: are we ok to land 1.9+ things?
<rbasak> sergiusens: around? About https://irclogs.ubuntu.com/2018/12/18/%23snappy.html#t02:09
<rbasak> If you are, then I'll catch up on any upstream changes to the problem since, and if it's still there I'd appreciate some of your time please.
<rbasak> Hmm I say that but the problem appears to have gone away for now. Presumably requirements.txt changed again.
<sergiusens> rbasak: if you use a base, it is a list, if you do not, it is a string when using 3.x
<rbasak> However it would be nice to know how to solve it properly and/or register it as a shortcoming in snapcraft's Python plugin if appropriate.
<sergiusens> rbasak: and fwiw, the deb is going to stick to 2.x
 * Chipaca goes to have lunch
<mup> PR snapcraft#2451 opened: static: address black warnings <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2451>
<mvo> mborzecki: yes, we are ok
<mup> PR snapd#6431 opened: snapcraft.yaml: fix snapcraft building in launchpad <Created by mvo5> <https://github.com/snapcore/snapd/pull/6431>
<mup> PR snapd#6403 closed: many: cleanup golang.org/x/net/context <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
<mup> PR snapd#6430 closed:  tests: enable debian sid as part of the main suite on travis <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6430>
<jdstrand> zyga: hey, don't bother adding your backlight to the PR, I've got a better idea
<Chipaca> jdstrand: should I mark that pr blocked? it's green and has two +1's, somebody'll land it otherwise :-)
<jdstrand> Chipaca: I just did, thanks!
<zyga> jdstrand: ack
<zyga> jdstrand: I really wish sysfs wasn't a maze of symlinks :)
<Chipaca> jdstrand: github here disagrees, but i guess eventual consistency is eventual
<jdstrand> Chipaca: I *just* did it after you suggested it
<Chipaca> jdstrand: reloading it and still not seeing it :)
<Chipaca> anyway, i'm off to the standup
<Chipaca> degville: 2010 says hi: https://r.chipaca.com/the_cult_of_done_manifesto.png
<degville> thanks Chipaca!
<degville> done is definitely better than perfect.
<Chipaca> zyga: "shall I compare thee to seccomp" -- mvo, probably
<Chipaca> zyga: https://en.wikipedia.org/wiki/Singularity_(operating_system)
<zyga> I love the shade of blue they used
<Chipaca> zyga: https://wiki.debian.org/X32Port FWIW
<Chipaca> zyga: but alas debian-x32.org is no more
<Chipaca> anyhooo
<Chipaca> zyga: mborzecki: and i was wrong about the kernel it seems. Had the worng end of the stick on this. Sorry for the noise.
<mvo> mborzecki: re 6422 - you write that you can reproduce hte mount issue without the change in the PR. does that mean with the change (i.e. when console-conf is disabled) the mount issue is no longer there?
<mborzecki> mvo: it's still running
<mvo> ta
<mborzecki> mvo: so a core 18 node was up for ~1h and didn't error out
<mborzecki> mvo: need to go out now, but i'll spin another one and let it run
<mvo> Chipaca: do you know if 6280 is ready for a second review? or is there something fundamental that needs discussion still?
<mvo> mborzecki: ta
<mborzecki> mvo: this is the script i'm using if you want to try it yourself too https://paste.ubuntu.com/p/rXDvJgFShf/ imo it's bit more aggressive than the test we have
<mvo> mborzecki: so a core18 node without console-conf (with console-conf disabled) survived 1h ? that sounds encouraging
<mvo> mborzecki: thanks, looking
<Chipaca> mvo: I think pedronis unblocked it because it's ok
<mvo> Chipaca: it got my +1 - its (IMHO) an easy win, would love to see itin
<mvo> so if someone looks for a fun review: 6280 (/me clearly works on is marketing skillz)
<roadmr> I bet it's a trap
<pedronis> Chipaca: mvo: yes, nothing fundamental against it (also now that --unicode is fixed for non-tty)
<pedronis> mborzecki: +1 to 6016 but some comments there
<zyga> re
<zyga> dinner done, now onwards
<r4co0n> Since a few months, sound is no longer working in my snapped Firefox, but other applications can still produce sound. This is running Debian buster. I haven't tested other sound-producing snaps, though. (repost from #snapcraft)
<kenvandine> r4co0n: how about the chromium snap?
<r4co0n> kenvandine, I'll go install and test. I got chromium installed via apt and it is working fine.
<zyga> r4co0n: hey
<zyga> r4co0n: we've made an upload to buster recently, 2.37-3 will be coming your way soon (tm)
<zyga> r4co0n: would be great if you could check once that is released
<zyga> r4co0n: or get it from the incoming pipe if you want
 * cachio lunch
<r4co0n> zyga, I'm still on 2.36-3, let's see when this comes to my mirror.
<zyga> r4co0n: it's not migrated yet
<zyga> r4co0n: can you look at your journal output, perhaps there are some denials or something similar?
<zyga> r4co0n: I can try locally in a moment
<mup> PR snapd#6412 closed: tests: interfaces tests normalization <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6412>
<Chipaca> pedronis: got a bit to talk about the triggering logic for rere?
<r4co0n> zyga, kenvandine, sound is working in the chromium snap.
<pedronis> Chipaca: I have a meeting noew
<Chipaca> pedronis: my condolences
<zyga> Chipaca: let's just head to the pub then ;)
<Chipaca> yeah
 * Chipaca puts on his boots
<mvo> zyga: I added sbuild spread test now
<zyga> woot, I'm going through reviews now, but I can look at this out of band if you want
<r4co0n> How can I run the firefox snap in safe mode, with all plugins disabled? I tried gathering it from the help and a websearch, but found nothing.
<zyga> r4co0n: no idea, sorry
<kyrofa> r4co0n, zyga, kenvandine might be able to help
<r4co0n> I can start with --ProfileManager and create a new profile
<r4co0n> Not exactly the same, but problem solved.
<r4co0n> But no sound in a new profile :/
<r4co0n> zyga, you were talking about some journal output I can be checking? How do I do that? I ran the snap from the terminal and there is nothing remarkable showing up...
<mvo> 6431 is a very easy review
<mvo> *please*
<pedronis> Chipaca: the meeting was short, didn't quite happen
<r4co0n> btw, the same snap continues to work fine on Debian stretch.
<r4co0n> Similar setup.
<r4co0n> Other system.
<kenvandine> r4co0n: maybe different versions of snapd though
<Chipaca> pedronis: wrt "only do refreshes that would change epoch again", I would have to check with the store about updates, and then decide client-side whether to do the update or not depending on whether an epoch change happened?
<kenvandine> r4co0n: is it connected to the pulseaudio interface?
<kenvandine> check "snap interfaces firefox"
<Chipaca> pedronis: I understand that there's a small window where a snap changes its epoch and then refreshes without changing the epoch and this would re-refresh "early" (not sure why it's a problem), but having to decide client-side whether to do a refresh the store told me to do seems wrong?
<r4co0n> kenvandine, yes ':pulseaudio              chromium,firefox'
<r4co0n> Could reinstall help anything?
<r4co0n> The thing is, I am using every other part of this snap just fine everytime I'm at this system. It's just those odd YouTube,etc. moments when I get aware of this problem again.
<kenvandine> r4co0n: did you try chromium?
<r4co0n> kenvandine, yes I did and it works there
<kenvandine> well that's odd
<kenvandine> r4co0n: what version of firefox?
<mup> PR snapd#6419 closed: miscellaneous policy updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6419>
<mup> PR snapd#6420 closed: miscellaneous policy updates - 2.37 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6420>
<mvo> 6417 is another simple review
<mvo> (we just need a second one :)
<r4co0n> kenvandine, it's 64.0.2-1 (167) with no available upgrades on stable
<kenvandine> r4co0n: same as me
<mvo> Chipaca: if you are around - can I merge 6400 (nice number!) or is there anything missing? I did a quick test on the UX and it looks reasonable to me
<mvo> Chipaca: nice job btw, really like this
<r4co0n> I got KDE reporting  in Audio Volume Applications that 'No applications playing or recording audio' before I start audio in firefox snap, and 'AudioIPC Server' showing up as an application as soon as I start the audio stream.
<r4co0n> The volume is non-zero.
<Chipaca> mvo: ooh, you did the ux thing?
<Chipaca> mvo: let me look
<Chipaca> mvo: nice. It won't be translated, but at least it's not lying :-)
<Chipaca> mvo: pedronis had Opinions about the naming of things, but not sure if they were blockers
<Chipaca> ErrNoExpectedResult instead of ErrStoreUnresponsive
<Chipaca> although ErrNoExpectedResult is wrong; it'd be ErrMissingExpectedResult
<Chipaca> but, as i say,  dunno if a blocker
<kenvandine> r4co0n: so it's trying to do something
<mvo> Chipaca: hm, hm, both seem ok to me. no strong opinion
<mvo> Chipaca: anyway, should be landable once this is clarified
<Chipaca> mvo: thanks
<mvo> Chipaca: you trapped me, now I'm thinking about a good name for the last 5min
<pedronis> Chipaca: yes, it's a blocker
<r4co0n> kenvandine, with Chromium, it is showing the application name 'Chromium' almost(?) immediately, sound is at the same level, and I hear stuff.
<r4co0n> Testing with the top-left link on YouTube, btw.
<pedronis> Chipaca: I mean, I really don't like unresponsive there
<pedronis> Chipaca: do you want me to explicitly -1 it ?
<mup> PR snapd#6363 closed: cmd/snap-update-ns: save errno from strtoul <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6363>
<Chipaca> pedronis: it wouldn't be necessary now that i know you think it's a blocker
<Chipaca> pedronis: but it does communicate that unambiguously :-)
<Chipaca> i wish the store returned 420 instead of bogus responses, fwiw
<pedronis> Chipaca: done
<Chipaca> this is again us heuristicating things
<kenvandine> r4co0n: gnome also shows firefox as Audio IPC Server
<kenvandine> but i can hear it
<pedronis> Chipaca: once we alway have rerefresh , we have to do something to chose when to reupdate
<mup> PR snapd#6432 opened: interfaces: add block-devices interface - 2.37 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6432>
<r4co0n> kenvandine, funny side story, I purged it yesterday after having not used it for quite some months. But I still run it on my laptops.
<r4co0n> Would have been nice for testing now.
<pedronis> Chipaca: you are already checking if epochs are equal  (in the common code, which I don't think is where we want to make the choice)
<pedronis> Chipaca: I'm saying that needs to be postponed plus extra recheck in the task itself
<mvo> down to 53 open PRs - lets see if we can hit 50 today!
<pedronis> Chipaca: we can chat more on Monday
<pedronis> Chipaca: Missing works for me
<pedronis> jdstrand: hi, could you look at #6376
<mup> PR #6376: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376>
<jdstrand> pedronis: yes, I started yesterday and will pick up in a bit
<mup> PR snapd#6433 opened: tests: Update fedora 29 workers to speed up the whole testing time <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6433>
<kyrofa> Hey ogra, does the Ubuntu Core image support the rpi 3B+ ?
<cwayne> Yes
<cwayne> kyrofa: ^
<kyrofa> cwayne, thank you, I suppose you ARE the person to ask these days, eh?
<cwayne> So I've heard :)
<kyrofa> Ha!
 * cachio afk
<zyga> re
 * zyga fell asleep, sorry :(
<zyga> Chipaca: https://github.com/google/gops
<zyga> shiny
<mup> PR snapd#6425 closed: interfaces: add u2f-devices interface and allow reading udev +power_supply:* in hardware-observe <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6425>
<mup> PR snapd#6432 closed: interfaces: add block-devices interface - 2.37 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6432>
<mup> PR snapd#6433 closed: tests: update fedora 29 workers to speed up the whole testing time <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6433>
<mup> PR snapcraft#2449 closed: Release changelog for 3.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2449>
<mup> PR snapd#6434 opened: interfaces: add u2f-devices interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6434>
<mup> PR snapd#6435 opened: interfaces: add display-control interface - 2.37 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6435>
<mup> PR snapcraft#2452 opened: Fix typo in comments <Created by Lin-Buo-Ren> <https://github.com/snapcore/snapcraft/pull/2452>
#snappy 2019-01-26
<leinardi> Hi, I'm trying to distribute GWE via Snap (https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440) and I was wondering if someone here can give me some real time support.
<leinardi> diddledan, popey told me that you have done some gnome stuff recently, do you have some time to help me getting started?
<Chipaca> leinardi: maybe during the week...?
<Chipaca> people go outside for the weekend
<leinardi> Chipaca, I work during the week but I can be available after 18:00 CET. I work on this project on my free time so, usually, during the weekend.
<popey> hey leinardi happy to help
<Chipaca> popey: go outside! i hear there's icecream
<cwayne> Chipaca: what's this "outside" you speak of
<leinardi> :D
<popey> I went outside. Didn't like it much.
<Chipaca> ah, fair enough
<cwayne> There's bees and stuff out there
<Chipaca> did you say beer
 * Chipaca runs
<popey> BEES!
<popey> leinardi: snap install gnome-3-26-1604
<popey> I have seen that error too
<popey> it tells you the wrong content snap to use, right?
<Chipaca> popey: https://youtu.be/Nni0rTLg5B8?t=40
<popey> ooh oooh, i know wht
<popey> *why
<popey> leinardi: how are you building this given your snap/snapcraft.yaml isn't in the root of the project but buried in dist?
<leinardi> popey, yep, that's the error, but I don't get why should I install both gnome-3-26-1604 and gnome-3-30-1804, is that normal?
<popey> no, i know why it's happening and want to build here on my laptop to prove it
<leinardi> on my local branch is on the root, but I would like to move it to dist if possible
<leinardi> I can push another commit so that we have the same location for the snapcraft.yaml
<popey> how can i get the latest source and yaml?
<leinardi> popey, ok just pushed, you can checkout the branch feature/snap
<popey> ok, lemme have a play
<leinardi> sure, thanks!
<mup> PR snapd#6436 opened: interfaces: add system-backup interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6436>
<popey> https://www.irccloud.com/pastebin/5aQABZPM/
<popey> ^ leinardi
<popey> https://www.irccloud.com/pastebin/iwsIb2xx/meson-log.txt
<leinardi> popey, could it be that you are missing some of the dependencies? Are you able to run GWE with the ./run.sh?
<leinardi> deps: sudo apt install python3-pip libcairo2-dev libgirepository1.0-dev libglib2.0-dev libdazzle-1.0-dev gir1.2-gtksource-3.0 gir1.2-appindicator3-0.1 python3-gi-cairo
<popey> thats me building it as a snap
<popey> will check those are build-packages..
<popey> Dependency gtk+-3.0 found: NO found '3.22.30' but need: '>=3.24'
<popey> :(
<popey> do you really need 3.24?
<leinardi> popey, unfortunately yes, due to libdazzle
<popey> This is a bit of a blocker. There's ways around it though.
<leinardi> https://gitlab.gnome.org/GNOME/libdazzle/issues/31
<popey> One way is to add a ppa from the ubuntu desktop team, which pulls in newer GTK
<popey> Another way is to build gtk (and whatever else) from sauce
<popey> I believe there is work ongoing to fix this
<popey> kenvandine and diddledan are working on a gnome extension for snapcraft
<leinardi> the ppa needs to be added to the host machine, right? I guess is needed only for Ubuntu < 18.10. I'm on 18.10 I have the right version
<popey> Well...
<kenvandine> Build for core18
<popey> Snaps are built against a runtime. The main ones are core(16) and core18
<popey> kenvandine: i am building for core18
<kenvandine> Is my recommendation
<popey> but this app needs newer gtk
<kenvandine> Oh
<kenvandine> The future build snap will help there... But not ready yet
<kenvandine> You can also build you own gtk part
<popey> got any examples?
<leinardi> I'm confused, what is the gnome-3-30-1804 that I have in the snapcraft.yaml? Isn't that providing gtk 3.24?
<popey> That's used at runtime, to provide some support libs and a launcher
<popey> We're (I'm) stuck at the "building" part
<popey> When you built on 18.10, you're going to likely end up with a snap that won't run on anything
<popey> Because it will be built against newer libc and friends.
<leinardi> I see
<popey> We recommend building in a clean container or vm running 18.04 or 16.04
<popey> now, 16.04 is too old for your application, so prefer 18.04.
<popey> http://paste.ubuntu.com/p/rtv4V37Ddm/
<popey> that's the yaml I have so far, note the addition of "base: core18" which tells snapcraft to build against core 18 which is ~ ubuntu 18.04
<popey> Unless we go down the path of building the world from scratch, starting with newer GTK, we may have to put this on pause.
<popey> I mean, I'm happy to help you move forward, and build these bits to get you moving :)
<popey> until the work ken mentioned is done.
<popey> This is a pitfall of having a beautiful app on the bleeding edge :)
<popey> but you'd likely have to build quite a bit of gtk / gnome / gi to get this working.
<leinardi> is there any ETA it? Are we talking about weeks, months or 20.04?
<leinardi> *for it
<popey> Great question. Might be faster to build those parts :S
<leinardi> :)
<popey> I was hoping kenvandine might have a repo on gitlab somewhere which we can steal parts from :)
<leinardi> sorry for the silly question but it is still not clear to me: shouldn't be enough to have the proper runtime and just build on a host that has GTK 3.24?
<popey> 18.10 for example? No, because it will be built against the libc that's in 18.10
<popey> So someone on 16.04 installs your snap and it will fall over with horrible LIBC errors in capital letters
<kenvandine> https://gitlab.gnome.org/Community/Ubuntu/gnome-3-28-1804-sdk/blob/master/snapcraft.yaml#L297
<popey> GOOD LORD
<kenvandine> That's a gtk part, just ignore the build-environment line
<popey> and bump source-branch?
<kenvandine> But, you might run into issues
<popey> haha, no shit :)
<kenvandine> I gotta run now.. but I can help out on Monday
<popey> thanks!
<leinardi> mmm please be patient, just need to ask more questions to better understand :) When we are talking about building, we are talking just about libdazzle, right? Because My app is a PyGOpject app, so I don't have to build anything beside libdazzle, or not?
<leinardi> what I am expecting is that gnome-3-30-1804 is providing all the gnome 3.30 support, but I still need to provide libdazzle since is not part of it
<leinardi> or am I missing something?
<popey> gnome-3-30-1804 doesn't provide the stuff needed at *build* time.
<popey> only runtime components
<popey> The problem is that you're targetting 3.24 which isn't available in Ubuntu 18.04 repos
<popey> (I mean, libdazzle needs that)
<leinardi> ok but, I don't get why for a user with gnome-3-30-1804 installed would be a problem to run the snap build on my machine, if I bundle libdazzle binary (I'm an Android dev, so not really familiar with C dependencies)
<popey> if you build on a system which has newer libc, it likely won't work on a system with older libc
<popey> this is part of the reason snaps exist at all. You build in a specific environment (core 16 ~ Ubuntu 16.04, or core 18 ~ Ubuntu 18.04).
<popey> When the user instals the snap, they get core16 or core18 which contains the libc the app was built against, no matter what they install the snap on
<popey> So whether they install your snap on fedora 28 or arch bleeding edge, your snap works because along comes core18 or core16 snap "runtime"
<popey> That's all fine, and isn't the problem we need to solve today.
<popey> The problem is *building* the thing at all on 18.04 (not 18.10)
<leinardi> ok, now I think is clear, thanks :)
<popey> :)
<popey> I'll have a chat with Ken on Monday. I'll add it to discuss in our regular catch up meeting to see what our options are, okay?
<popey> (and reply on the forum)
<leinardi> that would be awesome, thanks a lot!
<popey> left a placeholder reply on the forum so others don't waste time on it.
<popey> sorry I don't have a quick answer for you
<leinardi> no worries, I'm glad to be getting some help, I can work on other thing while we figure out how to build on 18.04 :)
<leinardi> popey, one last question for today: do you know if this is possible? https://forum.snapcraft.io/t/specify-custom-build-directory/9671
<diddledan> popey: leinardi: building against core18 should give you gnome 3.28 from the 18.04 repo (that's what bionic has natively)
<leinardi> diddledan, correct, but I need gnome 3.30 / gtk 3.24
<diddledan> aah, gtk. sorry, I misunderstood
<diddledan> in that case then popey is right that the only way currently to get a more recent gtk is to rebuild it from source
<leinardi> diddledan, I see, thanks. Do you know if it's possible to specify a custom directory for the build output of snapcraft? I'm talking about the parts, prime and stage directories. I'd like to have them inside a build folder.
<diddledan> that's not possible
<popey> note I tweaked your yaml to not have references to snap in the prefix
<diddledan> the idea is that you use a throwaway build system, e.g. a vm, that does everything internally to the vm
<popey> it shouldn't be needed
<popey> yeah, base: core18 will use multipass to build in an 18.04 vm
 * diddledan goes to find a multipass pic
<diddledan> https://cdn.instructables.com/FTJ/CYOV/IEB8CSW1/FTJCYOVIEB8CSW1.LARGE.jpg?auto=webp
<leinardi> oh ok. popey: thanks, I have already pushed your changes to the feature/snap branch
<leinardi> diddledan, :D
#snappy 2019-01-27
<Son_Goku> niemeyer, zyga: another step on the ladder: https://src.fedoraproject.org/rpms/fedora-release/pull-request/67
<probono> Why would one want a Fedora base snap though?
<probono> isn't the point of base snaps that there shouldn't me many of them?
<probono> if every app depends on another base snap, the whole system will be very inefficient
<probono> kinda like Flatpak today
<popey> probono: some software vendors build against rpm based distros and don't want to re-tool for debian based ones.
<probono> that imho is the software vendor's problem; should users really have to care what tooling software vendors are using?
<probono> possibly the base snaps should be entirely distro agnostic
<probono> e.g., built on yocto
<probono> evidence shows that in flatpak almost evey app uses a different (version) runtime. let's not repeat that in snappy. releasing one distro-agnostic base snap every 4 years or so would be ideal, imho
<popey> Users won't care.
<probono> hard disk and ram does care
<popey> Users will just install foo-app which will bring in whatever base is needed
<popey> core18 is 54MB in size
<probono> yes, which means that we'll end up with more than 1-2 base snaps on each system, which is not efficient
<popey> That depends on the choice of apps the user has and the popularity (or not) of the 3rd party bases
<popey> While it's possible there may end up being fedora, suse, gentoo and whatever else, realistically not many apps will depend on gentoo base
<popey> Because (rightly or not) many developers 'standardised' on Ubuntu as their build system.
<popey> So chances are a large proportion of users will have 1 or 2 bases, and a small number might have 3, which third one they have, depends
<probono> Because many developers 'standardised' on Ubuntu as their build system, Ubuntu should be sufficient as the base snap, no?
<dviola> hi
<dviola> I am trying to run a mono app from a snap, but I'm not sure what I'm doing wrong, can someone help please?
<dviola> here is the snapcraft.yaml: https://gist.github.com/diegoviola/e848072006ea0a310828a2e8df769ae3
<dviola> this is the error I get: https://gist.github.com/diegoviola/43acb954b969eb47a0e67c8165132e21
<dviola> System.IO.FileNotFoundException: Could not load file or assembly 'gtk-sharp, Version=2.12.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' or one of its dependencies.
<dviola> mono and gtk-sharp2 is being installed on the snap
<dviola> but when I run it I get that
<dviola> I tried copying the gtk2sharp.dll to the mono's gac but that didn't work
<dviola> any ideas please?
<popey> dviola: it's a bit late on a sunday. might be better to either ask again during the european / US working week, or on the forum
<popey> (forum is probably best so others can learn the solution.)
<dviola> ok thanks
#snappy 2020-01-20
<mborzecki> morning
<zyga> hey mborzecki
<zyga> mborzecki: who's in today?
<mborzecki> zyga: hey, happy blue monday ;)
<zyga> oh is that today?
<zyga> I'm feeling pretty happy :)
<zyga> more branch iteration
<zyga> need to double check roadmap work
<mborzecki> zyga: mvo, samuele and Chipaca are out, maybe cmatsuoke too (?) he mentioned something during the standup didn he?
<zyga> mborzecki: chachio is out too AFAIR
<mborzecki> zyga: oh, right, summer time ;)
<mborzecki> zyga: oh, and ian is out today too?
<zyga> haha really?
<zyga> in that case we can just chat in #snappy-pl ;)
<mborzecki> hahah
<mborzecki> zyga: have you read about the drama in rust community?
<mborzecki> zyga: https://words.steveklabnik.com/a-sad-day-for-rust
<zyga> no, did someone die?
<zyga> hmmm
<zyga> I will call my programs unsafe.c ;)
<zyga> this whole thread re-affirms my perception that most social networks are poison
<zyga> and reddit is particularly bad
<zyga> it's one to argue with someone you know
<zyga> it's another thing to play the game "endless waves of people talking you down"
<mborzecki> zyga: idk, imo twitter takes the crown
<mborzecki> as the worst social network
<zyga> I disagree for a single reason
<zyga> twitter is more of a rain
<zyga> you can get hit by drops and stuff
<zyga> but it's not a place where you are under a open pipe
<zyga> reddit has sub-reddits that amplify this
<zyga> reddit has "better" thread tools that amplify efficiency of negative feedback
<zyga> it doesn't negate twitter being junk in other forms but I haven't seen as much crap there, specifically on FOSS topics
<zyga> hey pawel
<mborzecki> pstolowski: hey
<pstolowski> heyas
<zyga> dzindybry
<mborzecki> zyga: yeah, readdit is quite effective at spreading negative feedback, though imo still twitter is where most drama takes place, and it's a short ride from twtitter to shitty news outlets everywhere
<zyga> mborzecki: for general news yes
<zyga> mborzecki: e.g. trump
<zyga> mborzecki: but my entire foss/twitter interaction was way better than reddit
<zyga> to change the topic slightly
<zyga> I was playing with C code coverage over weekend
<zyga> specifically using clang on macos
<zyga> and I learned a few things
<mborzecki> zyga: old dog, new tricks? :)
<zyga> more like alt toolchain I rarely use
<zyga> my toy library has better code coverage now
<ogra> it is just all these fancy new languages you all use ... rust ... go ... nobody complains about shell on reddit ;)
<zyga> not at 100% yet but much closer
<zyga> also wrote a few new manual pages
<zyga> I'd say 1/3 of the API has manual pages now
<zyga> ogra: oh
<mborzecki> zyga: about C, did you use that pvs studio open source license and tried to analyze out C bits?
<zyga> I found a cool thing for shell
<zyga> one sec
<zyga> mborzecki: yes I did
 * ogra sits in awe .... new things !
<zyga> ogra: a pep-8 like thing for shell
<zyga> oh gosh, how was it called...
<ogra> shellcheck on steroids ?
<mborzecki> smellcheck probably :)
<ogra> *sniff* *sniff*
<zyga> oh well, I cannot remember
<zyga> maybe I'll recall it
<ogra> i'ts fine ... usually my code doesnt survive long enough to be worth checking it for pep-8 before someone rewrites it in a fancy lang ;)
<mborzecki> zyga: https://github.com/openstack/bashate ?
<zyga> mborzecki: no, it had a more polite name
<zyga> I should have kept the tab
<ogra> btw, i finally managed to get gnome-shell up on core with mir-kiosk on the weekend (only very rudimentary yet) ...
<ogra> my snapcraft.yaml only has ~100 layout overlays yet (with more to come i guess)
<ogra> layouts really rock !
<ogra> (until you decide to move an overlayed dir to single files with an upgrade and cant uninstall the sanp anymore at least :P )
<zyga> uh
<ogra> what would be a really helpful feature would be "overaly every file thats in the snap but not in core in one go"
<ogra> *overlay
<ogra> i.e. simply diffing the dir structure and binding all non-existent files ...
<ogra> i was surprised how many bits and pieces are still hardcoded in gnome and not overridable by env vars ... (search paths for data in /usr/share etc ... )
<ogra> ... and finding out that even gnome-terminal doesnt run without dbus, systemd and logind anymore was a rather shocking moment ... half of it is javascript nowadays !!
<mup> PR snapd#8020 closed: interfaces/apparmor: fix doc-comments, unnecessary code <Simple ð> <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8020>
<zyga> mborzecki: do you think you could look at https://github.com/snapcore/snapd/pull/7980
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<mborzecki> zyga: sure
 * zyga has enormous headache :/
<zyga> the air today is terrible
<mborzecki> zyga: so is atmospheric pressure, was suppsoed to be 1050hPa
<zyga> uh, that's high
<mup> PR snapd#7995 closed: debian: check embedded keys for snap-{bootstrap,preseed} too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7995>
<zyga> hey mvo
<zyga> :)
<mvo> hey zyga
<mborzecki> mvo:  hey!
<zyga> any news?
<mvo> hey mborzecki
<pstolowski> hi mvo !
<mvo> mborzecki, zyga not much yet
<mvo> hey pstolowski
<mborzecki> zyga: though the pressure sensor in my phone is showing 1024hPa
<mvo> but it looks like we need to revert the do-not-show-writable PR, I think john is on this. or are there more news?
<zyga> mvo: do not show writable PR?
<zyga> mvo: are you referring to /writable unmounting we do?
<mvo> zyga: yeah, let me try to give you more context
<mvo> zyga: looks like statvfs("/writable") was used and that is no longer working
<zyga> mvo: yeah, I know this from last week - did we find out why they are doing it?
<mvo> zyga: monitor diskspace
<zyga> mmm
<zyga> it's not really reliable
<zyga> but I see
<mvo> zyga: because we do not work well when we run out of diskspace
<mvo> zyga: yeah, we need to fix the out-of-diskspace problem
<zyga> I mean the check itself is also unreliable
<mup> PR snapd#8018 closed: spread.yaml: fix ubuntu 19.10 and 20.04 names <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8018>
<zyga> because partitions
<mvo> zyga: in what way?
<mvo> zyga: can you expand that a bit please?
<zyga> because /writable is just one directory
<zyga> maybe /writable/user-data is another
<zyga> it's not fixed in stone
<zyga> it's just a way to observe current implementation on some systems
<mvo> zyga: aha, I see. but for their devices it's all on a single partition. but in general yes, it may not be
<mvo> zyga: yeah, thanks, I get what you mean now
<zyga> mvo: I'm okay to revert this for now but I'd like not to be hostage to /writable
<zyga> as in, that it is a single partition and that you can stat it to know disk space
<mborzecki> btw. this isn't reported in any way in /sys right?
<mvo> zyga: yeah, I think we may need to short-term revert, and then ensure we deprecate this mount and then remove it again in 1-2 releases
<zyga> mvo: agreed
<zyga> mborzecki: it might be
<mvo> zyga: thanks!
<mvo> mborzecki: a good question, that would be interessting
<mborzecki> mvo: /sys/ext4/<device> constains some files but none that seems to carry size/free info
 * mvo nods
<zyga> mborzecki: ironically
<zyga> mvo: stat -f $HOME is an equally good check
<mborzecki> zyga: heh, yeah, but looks like i can trigger fs errors :P
<zyga> mvo: maybe we should not revert
<zyga> mvo: but instead ask to tweak the one-liner stat check
<zyga> mvo: AFAIK it's one customer and one bit in their software
<mvo> zyga: yeah, I will explore if that is possible
<zyga> mvo: thank  you
<zyga> mvo: would certainly be more in line with what would work long term IMO
<mborzecki> zyga: and you need a mounted fs to check free space too?
<mvo> mborzecki: haha - really?
<zyga> mborzecki: yes
<mvo> zyga: will this work inside the snap too?
<zyga> mvo: yes, stat is not mediated
<zyga> mvo: nor is statfs
<zyga> mvo: but I can double check if you want me to
 * zyga checks on a pi next 
<mvo> zyga: if it's not too much hassle would be nice
<mvo> zyga: a good alternative will make the conversation easier
<zyga> mvo: it works
<zyga> https://www.irccloud.com/pastebin/r6fnRvXK/
<zyga> mvo: this is on 2.43.1
<zyga> mvo: so I'd vote +1 on customer change rather than our change unless they strongly oppose
<zyga> mvo: but even if they oppose we should have a proper interface for disk space
<zyga> mvo: statfs on a random picked directory is not it
<mvo> zyga: does "snapd-hacker-toolbelt.busybox stat -f $HOME" also work?
<mvo> zyga: +1 for proper interface
<mvo> zyga: also we should just be able to handle low/no diskspace better
<zyga> mvo: yes because $HOME is expanded in unconfined shell
<zyga> mvo: and it is unmediated as far as apparmor is concerned
<zyga> mvo: it is also working with snap rewritten home
<zyga> https://www.irccloud.com/pastebin/wBLAE3nq/
<mvo> zyga: nice, I will see if we can get away with this then
<zyga> cool :)
<zyga> I didn't think of this last week
<zyga> but I think it's a clean solution out of this problem
<zyga> I need to grab painkillers, as infrequently as I use them I cannot work with constant headache :?
<zyga> mvo: high-pressure wave across .pl
<zyga> brb
<mvo> zyga: uh, good luck!
<mup> PR snapd#8022 opened: Revert #7421 <Created by chipaca> <https://github.com/snapcore/snapd/pull/8022>
<zyga> back
<__chip__> zyga: ð
<zyga> hey __chip__ :)
<__chip__> zyga: can you take a look at #8022 ? there was a conflict in the revert so I hand-edited a couple of files, but I'm not sure they came out OK. I ran the spread test but the conflicts were in 1604 test files that don't seem to be exercised ((?))
<mup> PR #8022: Revert #7421 <Created by chipaca> <https://github.com/snapcore/snapd/pull/8022>
<__chip__> concretely tests/main/mount-ns/google.ubuntu-core-16-64/PER-USER-16.expected.txt and tests/main/mount-ns/google.ubuntu-core-16-64/PER-SNAP-16.expected.txt
<__chip__> were the ones with conflicts
<zyga> ok
<__chip__> (I'm not sure they're exercised as that spread test only runs in 1804)
<zyga> __chip__: FYI check out the conversation with mvo just above
<__chip__> zyga: I've only just logged onto irc so i'll have to wait for ubuntulog2 for that :)
<zyga> __chip__: idea to use stat -f $HOME instead of the revert
<zyga> __chip__: and ask the customer to use that instead
<__chip__> zyga: $HOME, or /home ?
<zyga> __chip__: due to how statfs works they can check /var/snap, /var/lib/snapd and other places
<__chip__> $HOME is probably /root FWIW
<zyga> __chip__: /home would work as well
<zyga> that works too btw
<__chip__> yep
<__chip__> zyga: I think we can ask the customer to make any amount of changes, the issue is the timeline
<zyga> __chip__: I was concerned about cementing /writable as an interface
<zyga> __chip__: changing stat on their side is a one liner
<__chip__> agreed, and note i targeted the release branch with the pr, not master
<zyga> and it works in past snapd versions as well
<zyga> __chip__: sure, I just wanted to recap what was said above
<__chip__> zyga: i wouldn't presume to know the timeline of them releasing a one liner
<__chip__> but yeah if they can change it quicker than we can revert it, +2
<zyga> yeah
<zyga> I don't know either
<__chip__> in any case that's async
<__chip__> we can have this pr ready to go if they come back with '2 months to get this rolled out to prod'
<zyga> I'll adjust your PR to pass
<__chip__> ah, the PR title is probably wrong :-) thanks
<__chip__> zyga: i pinged you on telegram before coming on here because sprint-mode
<__chip__> zyga: you can ignore that now :-D
<__chip__> also it might've gone to your spanish phone #
<zyga> I see it now :)
<__chip__> :)
<zyga> it's my proper telegram number btw
<__chip__> i see you seeing it
<mborzecki> cjwatson: hi, do you have access to the machine where https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1860324 occurred?
<mup> Bug #1860324: snapd crashed and can't start: "Re-refresh task has 1 tasks waiting for it" <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1860324>
 * __chip__ out
<cjwatson> mborzecki: yes, it's my normal development laptop
<mborzecki> cjwatson: can you post the output `snap changes` command? or if snapd cannot start, then make sure it's stopped and try `snap debug state /var/lib/snapd/state.json` and post that
<cjwatson> mborzecki: added to the bug
<mborzecki> cjwatson: thanks!
<mborzecki> hmmm, so switch-snap channel got added, and everything is ordered before it, incl rerefresh
<zyga> mborzecki: ?
<mborzecki> zyga: see the bug report ^^
<mborzecki> heh, Switch snap "gitlptools" from channel "latest/stable" to "stable"
<zyga> uh
<zyga> that's not good
<mborzecki> wish chipaca was around ;)
<mborzecki> hm potentially same thing with toggle-snap-flags task
<zyga> snap debug state is lovely
<zyga> but that argument could be optional (state file path)
<pstolowski> zyga: it would be super useful to teach it more things
<zyga> pstolowski: now's the chance to merge ;-)
<pstolowski> zyga: haha
<mup> PR # closed: core#38, core#107, core#108, core#110
<mup> PR # opened: core#38, core#107, core#108, core#110
<mup> PR snapcraft#2886 opened: Use ensure_dir_exists instead of mkdir -p <Created by MarcusTomlinson> <https://github.com/snapcore/snapcraft/pull/2886>
<mborzecki> cjwatson: would you be able to attach the output of `sudo cat /var/lib/snapd/state.json| jq '.data.snaps.gitlptools'` too?
<cjwatson> mborzecki: done
<mborzecki> cjwatson: cool, thanks
<zyga> mborzecki: any closer?
<mborzecki> zyga: no, not really, added a managers level test, but can't seem to reproduce it
<pstolowski> mborzecki, zyga it's pretty scary we have logger.Panicf("Re-refresh task has %d tasks waiting for it.", numHaltTasks)
<zyga> mborzecki: do you have a theory what is going on?
<zyga> pstolowski: are we hitting that?
 * zyga is out of sync with that bug
<pstolowski> zyga: yep, it's in the desc of the PR
<pstolowski> Jan 20 09:54:38 niejwein snapd[9861]: panic: Re-refresh task has 1 tasks
<zyga> uh
<zyga> I see
<zyga> some assumption doesn't hold
<zyga> is this code in the candidate branch?
<pstolowski> yeah.. root cause is something else, but we shouldn't do this..
<zyga> can we degrade  that to an error
<zyga> so that some refresh goes on
<zyga> I really think we should not panic :/
<pstolowski> yeah, not in the task handler that is bound to be re-run
<zyga> brb,
<pstolowski> mborzecki: so yeah, as you said above (sorry, just catching with the backlog on that bug), it's because of adding switch-snap-channel
<zyga> re
<pstolowski> mborzecki, zyga so i think (afair from talking to pedronis long time ago) the basic invariant has always been for check-refresh to be the last task. UpdateWithDeviceContext seems to have bug as it can append to tasks from doUpdate
<mborzecki> pstolowski: i think it's related to having channel: "stable" in the state, and the code around that does a simple lexical comparison
<pstolowski> mborzecki: that may be another problem then.. but as is, I think nothing prevents UpdateDeviceContext from appending task after check-rerefresh, in which case check-rerefresh will panic
<mborzecki> pstolowski: so we have possible aliases update, a task gets added, then rerefresh (why is the alises update done at all?), then level up the call stack, switch channel is added because snapstate channel is "stable", while we currently resolve "stable" (that came from the command line) to "latest/stable"
<mborzecki> pstolowski: oh, and another problem, now snapd is stuck and panics, how we get out of that ;)
<mborzecki> (other than editing the state)
<pstolowski> mborzecki: i see. i suppose it would end up badly also with a switch from stable, to say latest/edge?
<pstolowski> mborzecki: bummer..
<pstolowski> we shouldn't panic in task handlers :(
<pstolowski> first time to use recovery mode?
<cjwatson> For myself I'm perfectly happy to edit the state if given instructions on how to do that correctly, but I assume this might affect others
<mborzecki> hmm edited my state in a way that should break it, but no luck there
<mup> PR snapcraft#2885 closed: lifecycle: only warn when a default provider snap is missing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2885>
<mup> PR snapcraft#2886 closed: Use ensure_dir_exists instead of mkdir -p <Created by MarcusTomlinson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2886>
<mup> PR snapcraft#2887 opened: 3.9 cherrypicks <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2887>
<zyga> net issues?
<zyga> yeah, I have net issues at home
<zyga> sil2100: https://github.com/snapcore/pi-gadget/issues/13 did you see?
<mup> PR snapd#8023 opened:  devicestate: encryption regardless of grade <Created by mvo5> <https://github.com/snapcore/snapd/pull/8023>
<zyga> re
<ijohnson> mborzecki: thanks for the PR to etrace, the options there aren't well documented :-(
<mborzecki> ijohnson: figured it's a WIP :)
<ijohnson> mborzecki were you using it to measure a cli program or did the window name stuff not work?
<ijohnson> Yes still a WIP
<mborzecki> ijohnson: started with `etrace run ls`
<ijohnson> Ah yes that probably just got stuck
<mborzecki> pstolowski: haha, got `panic: Re-refresh task has 1 tasks waiting for it.`
<pstolowski> mborzecki: re stable vs latest/stable, it seems we have a bug in that we don't normalize --stable and then stable != latest/stable in snapstate's Update
<pstolowski> mborzecki: uhh, what did you do? how?
<mborzecki> pstolowski: let me open a PR
<mborzecki> however, i still ahve no idea how we ended up tracking the 'stable' channel expliclitly in the state
<zyga> mborzecki: good work L)
<pstolowski> mborzecki: i've a theory on that
<zyga> :)
<pstolowski> mborzecki: in patch 6_3 we only normalize tracking channel, but not the channel sequence (maybe that's fine, i don't know). perhaps that revision was installed with older snapd so didn't get normalized. revisions installed with new snapd get the full channel inside sequence
<mup> PR snapd#8024 opened: overlord/snapstate: add reproducer for LP#1860324 scenario <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8024>
<mborzecki> pstolowski: ^^
<pstolowski> mborzecki: as for aliases you're right, the number of aliases changed, and this resulted in check-rerefresh task (because reportUpdated is non zero)
<mborzecki> pstolowski: yeah, and snap declarations are refreshed on their own
<oSoMoN> jdstrand, hey, I would welcome your opinion on bug #1859643
<mup> Bug #1859643: [snap] cannot use shared NSS db <snap> <chromium-browser (Ubuntu):Triaged by osomon> <https://launchpad.net/bugs/1859643>
<om26er> zyga I need your input on https://forum.snapcraft.io/t/software-based-presentation-remote-or-need-an-interface-to-talk-uinput/13951
<zyga> mmm
<zyga> looking
<zyga> responded
<mup> PR snapcraft#2887 closed: 3.9 cherrypicks <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2887>
<om26er> Thanks ^ I replied ;-)
<zyga> om26er: reading
<zyga> om26er: can you please run that and attach a strace to the thread
<zyga> om26er: ideally strace -e ... that limits to the relevant parts
<zyga> (probably open + ioctl or open + write)
<zyga> om26er: thank you!
<om26er> Sure, I will do that
<zyga> om26er: btw, is the rest of what I said sensiblke?
<zyga> om26er: it could be handled by the user session daemon, perhaps
<zyga> om26er: also, do you know how this differs in wayland?
<zyga> does wayland have a proper event injection API?
<om26er> zyga I think the X11 interface allows access to /dev/uinput hence it works fine in that environment. Not sure if the wayland interface allows that
<zyga> om26er: apart from interfaces in snapd
<zyga> om26er: I mean, x has an explicit message to inject events
<zyga> om26er: so you can either push them back from linux side
<zyga> om26er: or talk to X and tell it "here's an event"
<zyga> om26er: do you know how _this_ aspect looks like in Wayland?
<om26er> no, not aware about internals of wayland at all :/
<om26er> Will need to look if wayland has a "higher level" of input injection API of sorts
<zyga> om26er: ok
<om26er> that discussion might be relevant https://lists.freedesktop.org/archives/wayland-devel/2017-March/033514.html
<om26er> interestingly Jamie had some feedback on a related topic a while back https://bugs.launchpad.net/snappy/+bug/1622639
<mup> Bug #1622639: Snap access to /dev/uinput <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1622639>
<zyga> re
<zyga> switching gears to one more PR
<zyga> but I'll EOD in about an hour
<abeato> ijohnson, maybe you know, how something like 'Dec 12 21:56:18 evt2-integration-3 snapd[1225]: stateengine.go:150: state ensure error: Get https://api.snapcraft.io/api/v1/snaps/sections: dial tcp: lookup api.snapcraft.io: no such host' could happen?
<ijohnson> abeato: looks like dns resolution failure
<abeato> ijohnson, yeah, but they seem to have access... weird
<ijohnson> abeato: how do you know they have access ? was this a temporary failure perhaps ?
<abeato> it does not look like that - maybe they use a proxy though
<abeato> I'll ask them back
<ijohnson> could be proxy issue
 * zyga takes a break
<mup> PR snapd#8025 opened: overlord/snapstate: add reproducer for LP#1860324 scenario (2.43) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8025>
#snappy 2020-01-21
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey
<zyga> hey
<zyga> reading notes from the sprint
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: did you have you morning coffee already? :)
<mborzecki> we need to talk
<zyga> good morning
<zyga> mborzecki: I didn't but I can listen :)
<zyga> I went outside, the air is foul :/
<pstolowski> mborzecki: hey, i'm having 2nd cup right now ;), would like to have a chat about the panic?
<mborzecki> pstolowski: yup, standup HO?
<pstolowski> mborzecki: sure, coming
<mborzecki> zyga: ^^
<zyga> up
<mup> PR snapd#8026 opened: data/selinux: workaround incorrect fonts cache labeling on RHEL7 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8026>
<mborzecki> pstolowski: ^^
<sdhd-sascha> hi,
<sdhd-sascha> does anybody has experience with `build-snap` and `pkgconf` inside of the build-snap ?
<sdhd-sascha> In the build- & prime-stage of the snap with the *.pc there is : `prefix=/root/stage/usr`
<sdhd-sascha> In the build stage, where the `build-snap` is used. There is this inside of *.pc: `prefix=/build/wlroots/stage/usr`
<sdhd-sascha> Inside of the multipass VM - there is no directory "/build/wlroots".
<sdhd-sascha> Now, of course, `meson snapbuild` has trouble to resolve.
<zyga> sdhd-sascha: sorry, doesn't ring a bell
<zyga> what is pkgconf and build-snap
<sdhd-sascha> zyga: pkg-config command - the new spelling
<zyga> aha
<sdhd-sascha> zyga: build-snap: i mean a snap which includes only library and headers
<sdhd-sascha> I know, that snapcraft replaces the prefix inside of *.pc (pkg-config files)
<sdhd-sascha> Then i have a second snap, which want to use the library-snap.
<sdhd-sascha> In the second snap is `prefix=/build/wlroots/stage/usr``
<sdhd-sascha> zyga: It's okay, i can figure it out by myself.
<zyga> sdhd-sascha: good luck, sorry I'm not of much help - I rarely use snapcraft myself
<sdhd-sascha> zyga: thank you :-)
<mborzecki> zyga: a replacement for pkg-config
 * sdhd-sascha i wonder, if it's worth the time. And i should search some other task to fix...
<mborzecki> afaik there should be a symlink as pkg-config too
<zyga> mborzecki: btw, do you know more
<zyga> why is a replacement called nearly the same
<zyga> is the upstream the same?
<mborzecki> zyga: didn't investigate much other than what was discussed on arch dev mailing lists https://lists.archlinux.org/pipermail/arch-dev-public/2018-May/029252.html
<mborzecki> zyga: but it's supposed to be maintained (not necessarily true for pkg-config though)
<mborzecki> zyga: btw. seems like fedora may have more info https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
<zyga> thanks, that's interesting
<mborzecki> zyga: haha and our friend Eighth_Doctor was involved :P maybe you could poke him
<sdhd-sascha> hey, is the snap installation directory fixed ? Should it be always /snap/<snapname>/  ? Also for build-snaps ? Or is this not a must
<zyga> sdhd-sascha: snaps should not have to know about where they might be installed, that's the theory
<zyga> sdhd-sascha: a snap can find its assets and data using $SNAP and $SNAP_DATA environment variables
<Eighth_Doctor> mborzecki: most pkgconfig files in Debian/Ubuntu are broken
<zyga> sdhd-sascha: many snaps assume they are installed in /snap/$SNAP_NAME/current/ and use that as quasi-prefix
<sdhd-sascha> zyga: well, that means, that on installation snapd has to give the snap some ENV to the *.pc files
<Eighth_Doctor> the --prefix capability isn't going to work because a lot of pkgconfig files are not correctly written for prefixes to work correctly
<mborzecki> Eighth_Doctor: hah, that's reassuring
<zyga> sdhd-sascha: why?
<zyga> sdhd-sascha: are you shipping .pc files in snaps?
<Eighth_Doctor> and because Debian/Ubuntu don't actually use pkgconfig for dependencies or any reasonable validation, they never catch that
 * zyga doesn't follow
<sdhd-sascha> Eighth_Doctor: you mean, that i should ignored the prefix ? And look a `meson` why the path isn't resolved ?
<Eighth_Doctor> mborzecki: when we switched from deb/fdo pkg-config to pkgconf, we caught *a lot* of broken pkgconfig files
<zyga> Eighth_Doctor: to be fair, pkgconfig has limited usefulness if everything is in the usual locations and you need only -lfoo to link to foo (and nothing else)
<zyga> so I don't blame anyone for not using something when the advantage is non-existent most of the time
<Eighth_Doctor> zyga: ironically, the reason why that is largely rests at pkg-config's own broken implementation of --prefix
<zyga> Eighth_Doctor: it only shows that .pc files need a better validator/linter
<zyga> Eighth_Doctor: or need to be discouraged unless required
<Eighth_Doctor> it doesn't support it correctly, and iirc, bug reports for it have gone unanswered for a while
<sdhd-sascha> Eighth_Doctor: i have fun with `wayland-scanner` here: `protocols/meson.build:51: WARNING: Custom target input '//root/parts/sway/install/root/parts/sway/install/build/wlroots/stage/usr/share/wayland-protocols/unstable/xdg-output/xdg-output-unstable-v1.xml' can't be conv
<sdhd-sascha> erted to File object(s).`
<Eighth_Doctor> sdhd-sascha: I dunno, is that path valid?
<sdhd-sascha> Eighth_Doctor: no, of course
<Eighth_Doctor> I don't work with snapcraft either, I know it rewrites pc files sometimes, I don't know how good it is at it
<Eighth_Doctor> zyga: pkgconf has a pc validator internally
<Eighth_Doctor> but for political reasons, Debian refuses to switch default implementations
<sdhd-sascha> Eighth_Doctor: i will debug my case. And can report later what was the failing point ;-)
<Eighth_Doctor> (the creator of pkgconf used to be a Debian Developer who tried to replace dpkg with a better package manager, and went on to create Alpine's apk after their prototype was rejected by Debian)
<Eighth_Doctor> this is a story that would be near and dear to Gustavo's heart, as he tried to get Debian and Ubuntu to replace apt with smart nearly 15 years ago
<Eighth_Doctor> mborzecki, zyga: ^
<zyga> that's interesting
<zyga> I guess FOSS is never about merit
<Eighth_Doctor> well, anything involving people isn't about merit
<Eighth_Doctor> it's always about people
<zyga> more about soft skills, knowing people and just sticking to it
<zyga> yeay
<zyga> yeah
<Eighth_Doctor> at this point, I think the only reason pkgconfig is maintained is because Debian uses it
<Eighth_Doctor> I switched Fedora, Mageia, and openSUSE
<Eighth_Doctor> Arch, OpenMandriva, Yocto, and Buildroot have followed
<sdhd-sascha> Eighth_Doctor: I know pkg-config mostly from gnome sources
<Eighth_Doctor> OpenWrt recently changed too
<Eighth_Doctor> sdhd-sascha: fdo pkg-config originally came from GNOME
<sdhd-sascha> :-)
 * zyga notices kubuntu focus laptop
<zyga> how can anyone want a 1080p 16" screen?
<zyga> my 15" CRT had better pixel density
<Eighth_Doctor> zyga: the greatest irony is that pkg-config was invented by a Debian Developer to make it easier to create dev dependencies across libraries, but the debian package manager people refuse to use the data for dependency generation for dev packages
 * sdhd-sascha just remembering `gnome 1` 
 * Eighth_Doctor remembers when gnome used to have as large of a sprawl of libraries as KDE does today
<sdhd-sascha> :-D
<pstolowski> on a side note, coincidentally, the author of the original pkg-config is active on this channel ;)
<zyga> oh, who is it?
<pstolowski> zyga: jamesh
<zyga> ha, such a small planet
<zyga> (shame it's going up in smokes)
<pstolowski> tep
<pstolowski> yep
<jamesh> my original version was in shell though
<Eighth_Doctor> yep, iirc, dan nicholson rewrote it into C
<zyga> jamesh: I think it's fair to say everything starts as shell :)
<jamesh> the one that got popular was a C rewrite by Havoc Pennington
<Eighth_Doctor> oh Havoc did it
<Eighth_Doctor> hey!! it's someone I know! :D
<Eighth_Doctor> and I can even guess why he did it!
<Eighth_Doctor> probably to reduce the number of ugly shell things that rpm depended on when the pkgconfig dependency generator was added to rpm
<Eighth_Doctor> (for those who don't know, Havoc was a base system developer on Red Hat Linux, and was involved in the early days of developing Fedora with Fedora Core)
<jamesh> there was a similar general purpose script called "gnome-config", which could take a list of packages and produce appropriate cflags and libs
<jamesh> it worked by combining the output of the relevant "*-config" scripts for those libraries
<Eighth_Doctor> also... Havoc created freedesktop.org :D
<jamesh> what pkg-config brought to the table was having a single script driven by data files
<Eighth_Doctor> yes
 * sdhd-sascha i like the idea of pkg-config :-)
<Eighth_Doctor> most people do :D
<jamesh> Here's that ancient script: https://gitlab.gnome.org/Archive/gnome-libs/blob/master/gnome-config.in -- it looks like it can be extended via data files, but it primarily had special handling for most modules
<sdhd-sascha> jamesh: :-)
<Eighth_Doctor> huh, TIL that Erik Troan was the one who first rewrote alternatives from Perl to C
<Eighth_Doctor> but of course, that version never propagated to Debian, who in turn took a Perl implementation of chkconfig from SUSE instead of the C one from Red Hat and stuffed it into Debian
<Eighth_Doctor> (interestingly, the sources for alternatives in RH-ish systems is bundled with chkconfig because it's essentially a single freestanding C file)
<Eighth_Doctor> I think a decade or so later, Debian rewrote their own alternatives implementation from Perl to C
<Eighth_Doctor> but it still retains its dependency on dpkg
<sdhd-sascha> This: `wl_protocol_dir = wayland_protos.get_pkgconfig_variable('pkgdatadir')`
<sdhd-sascha> And this goes wrong:
<sdhd-sascha> ```
<sdhd-sascha> prefix=/build/wlroots/stage/usr
<sdhd-sascha> datarootdir=${prefix}/share
<sdhd-sascha> pkgdatadir=${pc_sysrootdir}${datarootdir}/wayland-protocols
<sdhd-sascha> ```
 * __chip__ waves
<zyga> hey __chip__
<__chip__> zyga: sup
<zyga> __chip__: mosly ok, some issues to be discussed more next week
<zyga> how's the sprint?
<__chip__> zyga: awesome
<__chip__> zyga: ffantastic
<__chip__> zyga: beeeoootiful
 * __chip__ stops
<zyga> I see the wine was good :D
<mborzecki> __chip__: got some notes regarding the segfault
<mborzecki> __chip__: i'll push a proposed fix, please bring it up with samuele
<__chip__> mborzecki: i commented on that pr
<mborzecki> __chip__: just seen that, cool
<mup> PR snapd#8026 closed: data/selinux: workaround incorrect fonts cache labeling on RHEL7 <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8026>
<__chip__> mborzecki: basically all those AddTask in Update* are suspect
<__chip__> mborzecki: but we need to look
<__chip__> it's some gnarly code :)
<mborzecki> __chip__: updated the standup doc with more context
<__chip__> mborzecki: tks
<zyga> mborzecki: is https://github.com/snapcore/snapd/pull/7614 is green, do you think it is something you could review this week?
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<mborzecki> zyga: yes, want to push a proposal for the aliases thing, and then look at ian's boot pr first
<zyga> ok
<zyga> brb, need coffee
<zyga> (real not decaf)
<zyga> making small progress on older PRs
<zyga> should have all green week :)
<zyga> brb
<mup> PR snapd#8023 closed:  devicestate: encryption regardless of grade <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8023>
<mup> PR snapd#8027 opened: snap: disable auto-import in uc20 install-mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8027>
<thresh> hello, is it a known issue that telegram-desktop snap cant open URLs when linked?
<thresh> I've got 'user-open error: cannot open supplied URL' in ~/.xsession-errors whenever I click on one
<zyga> thresh: I don't believe so
<zyga> but perhaps mborzecki knows more, he was patching it recently
<mborzecki> hmm hmm?
<zyga> mborzecki: telegram-desktop and xdg-open
<mborzecki> ijohnson: meh, can't push to #8001
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<ijohnson> mborzecki: sorry the box wasn't ticked
<ijohnson> try again, I just checked the box
<mborzecki> ijohnson: cool :)
<mborzecki> ijohnson: and pushed
<mborzecki> zyga: thresh: that's a message from userd, looks like it actually ran xdg-open on the host, but that exited with an error
<mborzecki> thresh: can copy the url, and then in a separate shell try to run `xdg-open <URL>` (that's what snap userd did)?
<zyga> small break
<sdhd-sascha> hmm, just remembering about gentoo. And wondering, if snap supports gentoo's build system ? can a gentoo package be build with snapcraft ?
<mborzecki> sdhd-sascha: snap or snapcraft?
<zyga> that is a snapcraft question
<zyga> probably no
<mborzecki> sdhd-sascha: for snapd on gentoo, iirc zyga had an overlay
<zyga> because of little general interest in gentoo
<sdhd-sascha> zyga: right ;-) i'm just asking to start to think about it. (do not mention)
<sdhd-sascha> zyga: sorry - we previously bootstrap winXp machines with a custom gentoo
<sdhd-sascha> i like the concept to use compiler-options to go through all sources (e.g. snaps)
<thresh> mborzecki, huh, I feel embarassed a bit since I didnt have xdg-utils installed on this laptpo.
<thresh> it worked right after apt install'ing it.  thanks a lot!
<sdhd-sascha> mborzecki: was just an idea, to use `snapcraft` to build a gentoo package
<sdhd-sascha> ;-)
<mborzecki> thresh: that explains why it didn't work ;)
<zyga> thresh: interesting, missing dependency or a weak dependency?
<thresh> doesnt look like snapd package depends/suggests/recommends it
<thresh> (i'm on debian)
<zyga> hmm, not godo
<zyga> *good
<thresh> https://packages.debian.org/bullseye/snapd <- I'm on testing
<Trevinho> zyga: hi, I was looking a way to run a snap in gdb as user, I saw https://github.com/snapcore/snapd/pull/6825 (and previous), but is there anything going on for that, or how can i do that?
<mup> PR #6825: cmd: rework `snap run --gdb` to work as user <â Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6825>
<zyga> Trevinho: I'm afraid I don't know
<zyga> I think it died because of ENOTIME
<Trevinho> zyga: ok, thanks anyways
<zyga> mborzecki: I'm going for a walk with Bit because kids don't want to
<zyga> I'll join from my phone
<sdhd-sascha> hey, Is there a way to only install packages, which would by: "--no-install-recommends".
<sdhd-sascha> Or can i blacklist apt-packages inside `build-packages` ?
<mborzecki> zyga: looks mostly ok, but we probably need a wrapper for dprintf() https://github.com/snapcore/snapd/pull/7614#pullrequestreview-345913137
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<sdhd-sascha> I have to write down a decision table. Classic-mode has no gnome-extension. Strict-Mode is lesser Yaml with it...
<ijohnson> pstolowski: I'm looking at a uc20 spread failure and it seems the upower snap is not found, is that expected? is the upower snap supposed to be in the store? I can't seem to find that snap anywhere
<ijohnson> pstolowski: I only ask you because I seem to remember you used that snap in one of your recent hook permissions spread tests
<pstolowski> ijohnson: that's very weird, https://github.com/snapcore/snapd/pull/7871 passed
<mup> PR #7871: tests: add spread test for hook permissions <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7871>
<pstolowski> ijohnson: fwtw interfaces-upower-observe test needs it as well
<ijohnson> pstolowski: yes that test failed too
<pstolowski> ijohnson: huh
<ijohnson> maybe I should ask in the store if there's some sort of outage happening or something
<pstolowski> ijohnson: maybe something has changed. i cannot find this snap anymore as you said
<ijohnson> yeah it's very odd
<ijohnson> pstolowski: I asked in the store team's channel
<ijohnson> pstolowski: it seems the snap has been unpublished as per https://forum.snapcraft.io/t/upower-snap-deprecation/14772
<pstolowski> ijohnson: :(
<ijohnson> pstolowski: since this will now break master I will push up a "test-snapd-upower" snap and convert all the tests to use that snap
<pstolowski> ijohnson: oh that's super nice, thank you
<pstolowski> ijohnson: i was already crushed about that hook-permissions test becoming useless
<ijohnson> yeah :-(
<cjp256> if I have environment.PATH = $SNAP/somepath:$PATH, does snapd expand that before invoking command?
<ijohnson> cjp256: it should
<cjp256> I have a classic snap  that directly invokes a python script  (#!/usr/bin/env python3), and PATH seems to just take on the default path.  If it uses a shell script (#!/bin/sh), $PATH applies as expected.  I'm not sure the cause of the change of behavior.
<sdhd-sascha> cjp256: i'm just not on keyboard. but send me the snap. maybe i look tomorrow or later ?
<sdhd-sascha> did you mean `subprocess.run` ? And the env is not as excepted ? Did you use some `extension` or other preloads ?
<ijohnson> cjp256: hmm strange, does it work if you don't use env and execute python3 directly instead?
<cjp256> i have been playing around with the various options, though i gotta jet for a bit.  I'll come back later with a small example :) thanks!
 * sdhd-sascha since zyga says, that snapcraft & snapd should handle every preload stuff. I'm too unsure if i should be worried if the env is unexpected
<zyga> mborzecki: thank you, will do
<mup> PR snapd#8028 opened: tests: use test-snapd-upower instead of upower <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8028>
<zyga> ijohnson: nice
<ijohnson> zyga: thanks
<ijohnson> zyga: I still want to have a separate "test-snapd-snaps" repo with all these test snaps that are complicated enough to not build locally from the test that just rebuilds the snaps every so often but mostly so it's easier to keep track of these snaps we use in the tests
<zyga> yeah, I think it would be good to get out of the manual pipeline
<zyga> not sure how to structure it
<zyga> perhaps a repo is the way to goi
<ijohnson> I think a repo with all the snaps is more scalable than a repo per snap, since we have many of these snaps I think
<zyga> yeah, I agree
<zyga> it would be a problem if they were asymmetric in compile cost
<zyga> but it's mostly lots of the same
<ijohnson> yes most of these are pretty similar
<sdhd-sascha> zyga: if you have some task, which i could help. Just ask ;-)
<zyga> sdhd-sascha: hmmm
<ijohnson> uggghh stupid upower snap needs new dependencies
<ijohnson> I see why tony deprecated this snap :-(
<zyga> sdhd-sascha: do you prefer coding or review?
<sdhd-sascha> zyga: i'm from starting more coder... but at my current level, review, would also be okay ;-)
<sdhd-sascha> zyga: i'm fix things by review, you know ;-)
<zyga> sdhd-sascha: I don't know how you could help right now
<zyga> sdhd-sascha: drive what you want to drive, learn, work with us for reviews/advice and have fun :)
<zyga> I guess that's how most FOSS works
<sdhd-sascha> zyga: its okay. I didn't go. I love linux and debian. So i love ubuntu too ;-) I know i can help, if i'm expert in som language. But not if i can many language ;-)
<zyga> sdhd-sascha: are you a debian developer or maintainer?
<zyga> sdhd-sascha: we could use help with debian maintenance (always)
<sdhd-sascha> hmm, zyga: i could - but i'm don't - why? In debian, it's very difficult to be diplomatic ;-)
<zyga> I asked mainly to check if you have commit access to various places
<sdhd-sascha> zyga: i'm with you - about the social-skills, what you say today ;-) +1
<sdhd-sascha> zyga: yesterday, i wonder about, how to write a cover-letter for canonical ... but tomorrow, or some time - ... i will try again ;-)
<sdhd-sascha> hey, didn't anybody see `mvo` these days ?
<ijohnson> sdhd-sascha: mvo is in south africa this week at a company sprint and is generally unavailable this week
<ijohnson> sdhd-sascha: mvo will be back next week tuesday or wednesday (not sure how much time he's taking off after the sprint)
<sdhd-sascha> ijohnson: cool :-) wish him all the best. could him only help by one task, yet
<sdhd-sascha> What is the sprint ? i talk about juju and kubernetes. And that these things are bundeled with snap ;-)
<ijohnson> sdhd-sascha: it's a company wide sprint, discussing business planning things for canonical
<ijohnson> juju and kubernetes are sometimes bundled as snaps; have you used them as snaps before?
<sdhd-sascha> ijohnson: ok. (Today, i talk with alisson about my old company. But couldn't go in detail. I'm sure you all could help ;-) )
<sdhd-sascha> ijohnson: yes. i tried conjure-up, to a time, where canonicals-kubernetes has problems with apparmor ... sorry. But it's great to use this `python` ncurses widget ...
<sdhd-sascha> I love the idea... But then, in my last company, i fixed rancher, that the zfs utils are included
<sdhd-sascha> Soon, i will use manual-juju-machines or maas.. i will see
<sdhd-sascha> ijohnson: i found it... it was again, just a silly thing: https://github.com/sd-hd/hyperkube/commit/5a7acceeedccf41d45210004daa7eb557ebc77b7
<sdhd-sascha> zyga: sorry - it's late... but could you tomorrow look at `clean-install` from this repo ?
<zyga> sdhd-sascha: can you tell me more?
<zyga> I'm not a docker person
<sdhd-sascha> zyga: it's just a wrapper around `apt-get install --no-recommends` ... it would make sense for snap ?
<zyga> sdhd-sascha: I honestly don't know
<zyga> perhaps tomorrow with fresh head
<jdstrand> sdhd-sascha: if canonical kubernetes has trouble with apparmor, I suggest filing a bug. perhaps joedborg could provide the link
<sdhd-sascha> zyga: i'm too ;-) ( hope i'm not so disturbing )
<sdhd-sascha> jdstrand: yes, you are right. but this was a time, where i didn't talk so much with you ;-) sorry
<pokk> Is there anything special I should know about timers for systemd on ubuntu core? I'm really not getting it to work. my service runs once and then no more even with a OnCalendar=:
<joedborg> jdstrand: to the snap repo?
<jdstrand> joedborg: I have no context. sdhd-sascha may have lost the context but can comment
<sdhd-sascha> i will try it soon. jdstrand: i figured out, that it was the zfs-drivers again. Like in rancher ;-)
 * ijohnson is back from lunch
<ijohnson> sdhd-sascha: re: clean-install do you mean when building snaps you want snapcraft to not include recommended debian packages?
<ogra> ijohnson, oh, arent you in CPT ?
<ijohnson> ogra: nah
<zyga> ogra: are you?
<ogra> next week
<ogra> sales planning etc ...
<sdhd-sascha> ijohnson: no, no - `clean-install` is really just a wrapper from google for `apt-get` with least possible packages...
<ijohnson> sdhd-sascha: sure, but how does that apply to snaps?
<sdhd-sascha> if, some snap needs libXYZ ... then i don't want ...
<ogra> sdhd-sascha, you could add an override-pull that mangles the hosts apt config
<ijohnson> sdhd-sascha: snaps are meant to be self-contained so they don't have dependencies the same way that a debian package does. if a snap application needs libXYZ, then libXYZ will be bundled inside the snap (except for a few exceptions)
<ogra> like you'd do when addint a ppa
<ogra> *adding
<ogra> ijohnson, well, recommands are typically optional dependencies ... not necessarily needed to actually *run* the app (but likely needed if you want the full feature set)
<ogra> *recommends
<sdhd-sascha> ijohnson: are you sure, that when i install `lxterm` inside a snap. That only packages needed, are installed ? I'm not sure. I'm don't know
<ijohnson> sdhd-sascha: I don't know about the lxterm snap, but yes that is how snaps are supposed to be designed is that all of their dependencies are included inside the snap
<sdhd-sascha> :-)
<ogra> (IIRC lubuntu and xubuntu are both setting "APT::Install-Recommends "false";" and  "APT::Install-Suggests "false"; " in their apt.conf by default ... apps work, install is smaller but to get all features from all apps you'd have to install additional packages
<ogra> )
<sdhd-sascha> ogra: cool :)
<bluesabre> I donât think weâre doing that in Xubuntu
<bluesabre> Hence the 1.7gb image these days :(
<ogra> so if size is really a concern it is surely possible to mangle the apt config by droping someting into the /etc/apt.conf.d/ dir, run apt update and only get the essential deps
<ogra> bluesabre, oh, then i remember that wrongly, i thought you did
<ogra> i doubt the benefit inside a snap is really big anyway ... given the squashfs is compressed and all ...
<ogra> but if your app pulls in all LaTex packages (which is probably in the area of 100+ MB) just for some exotic feature it probably makes sense
<diddledan> ogra, doesn't snapcraft do deb dependency tree generation internally - i.e. not using apt/apt-get/dpkg so that config option probably has little effect?
<ogra> does it ? i thought it calls out to apt
<ogra> i know it doesnt run maintainer scripts of the packages .... but i thought dependency resolution still comes from apt
<sdhd-sascha> diddledan: really?
<sdhd-sascha> diddledan: you mean: dpkg -i ?
<diddledan> maybe I'm mistaken :-)
<diddledan> I figured it was doing it all internally to not run those maintainer scripts and such
<sdhd-sascha> i don't know ... but this way - would be too much code, or ?
<sdhd-sascha> hmm
 * sdhd-sascha just talked to my old bosses - to use ubuntu for everything (sometimes i'm so stupid... - but i love to see, that a laboritory company use linux ! )
<sdhd-sascha> zyga: i've just seen some logs from my mobile-phone... could you send me your irc-logs ?
<mup> PR snapd#8029 opened: tests: use test-snapd-upower instead of upower <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8029>
<cjp256> ijohnson: wrt the PATH being odd, i have a small test case: https://github.com/cjp256/pedrolino with a script to reproduce quickly enough: https://github.com/cjp256/pedrolino/blob/master/reproducer.sh
<ijohnson> cjp256: nice I'll take a look
<cjp256> the simplest case, printpath is just a C binary that prints the path.  it does not see the expanded $PATH.  However, the wrapper (shell script) and shell script example both do have expanded paths...
<cjp256> https://github.com/cjp256/pedrolino/blob/master/snap.yaml is the corresponding snap.yaml
<ijohnson> cjp256: hmm yeah so I can reproduce your bug
<ijohnson> to be clear the issue is that the printpath app's $PATH doesn't include $SNAP/other-path correct ?
<cjp256> sorry I left that bit in there from another test and removed it.  PATH: $SNAP/usr/bin:$PATH
<cjp256> (i was just testing per-app environment vs per-snap environment)
<ijohnson> cjp256: to be clear, this is basically what you see as well: https://pastebin.ubuntu.com/p/r3qzGh92K3/ right?
<ijohnson> I built the snap you linked to and used the resulting snap
<cjp256> ijohnson: yeah
<cjp256> i'd expect all the PATHs to be the same?
<ijohnson> cjp256: yes I would expect them all to be the same as well
<ijohnson> it's possible that classic confinement has something to do with this
<ijohnson> did you try just changing confinement for the same snap to be strict and see what happens?
<cjp256> strict looks fine fwict
<ijohnson> well congratulations I think you found a real bug! (until someone comes along and says that this is intended behavior from some random decision 8 years ago :-) )
<mup> PR snapd#8030 opened: tests: add a command-chain service test <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/8030>
<cjp256> ijohnson: lol, ok well I'll just punt this LP bug in snapd's general direction ;D
<ijohnson> sounds good to me!
<sdhd-sascha> hey, guys - only work this much - if it works for you ;-)
<sdhd-sascha> zyga: i don't know how.. but you listen, and then you was the first who answer (i know that many people write ;-) )
<zyga> sdhd-sascha: I try to, though I am a flawed human as all of us :)
 * zyga tries to put lucy to bed
<sdhd-sascha> :)
 * sdhd-sascha hope you understand - i like you, as you are ;-)
<sdhd-sascha> hey, ijohnson: could i learn something from you? i know i'm different. And sometimes slow ... But i want still help -- hey, give me a chance ;-)
<sdhd-sascha> well... okay .. i have to lean `golang`...
<sdhd-sascha> r
<sdhd-sascha> ijohnson: did you think i have a chance to work for canonical ? or what did i wrong ?
<ijohnson> sdhd-sascha: we're really happy to have you contributing to the project, it's just we're all a bit busy at the moment and it's difficult sometimes to find things that are easy for new folks to work on. This week is also unfortunate timing because our main manager and architect are at a company sprint so they are largely unavailable this week. I'm sure that next week when Michael is back that he will have some more
<ijohnson> things you could work on.
<sdhd-sascha> hey, then give me a half time job ;-) i love it
<ijohnson> sdhd-sascha: regarding whether you have a chance to work at Canonical or not, unfortunately that is not a question for me to answer as I am not a manager here, but I strongly encourage you to talk with Michael, and IMHO I think you're already demonstrating a willingness and ability to work on things so that can only work to your benefit.
<sdhd-sascha> ijohnson: thank you :-)
<ijohnson> sdhd-sascha: but also it's important to understand that the company is not always hiring on every team, I'm not sure if we have openings on the snapd team or not right now
<ijohnson> Michael really is the best person to talk about that and I'm sure he'd be happy to set up a meeting for you next week
<sdhd-sascha> ijohnson: that's ok. snapd was the basic ;-0
<sdhd-sascha> ;-)
<ijohnson> Also, yes learning more about coding in Go is a great idea considering snapd is mostly a Go project
<sdhd-sascha> i told mvo that without "secomp" (which told zyga) and without apparmor... there was no conjure-up `juju`
<sdhd-sascha> ijohnson: to learn some `common` language is ok... to learn brainfuck ... is not okay !!!
<sdhd-sascha> ijohnson: without `zyga` i was some days behind here !!! really !!
<sdhd-sascha> ijohnson: for me the language doesn't matter. (i will talk about the language... ) but make the best of the existing ;-)
<sdhd-sascha> ijohnson: and you can trink some beer with me ;-)
<ijohnson> sdhd-sascha: one other thing I just wanted to mention is that most of the Snapd team is EU based and so it gets quite late for them around this time and they won't be around on IRC (even if they are logged in). I'm based in the US so I'm around at this hour but not many of the others are around at this hour (and if they are they probably shouldn't be :-) )
<sdhd-sascha> ijohnson: i inspect them ;-) it's cool to know the time .. and told my wife... where i have to work...
<sdhd-sascha> i read the jobs from MAAS too.. They are often in American
<sdhd-sascha> So i didn't work on MAAS
<sdhd-sascha> I'm stopped work on
<sdhd-sascha> hey. ijohnson: sorry, that sometimes i'm so a dumpnut
<sdhd-sascha> ijohnson: what time is at yours ?
<sdhd-sascha> hey, in the last weeks. I have watched where you come from
<sdhd-sascha> when is your evening ? ijohnson
<sdhd-sascha> `this can't be true, to download a kernel...` *maybe the calced bitcoins* ... ?
<sdhd-sascha> ijohnson: ogr... sleeps ;-) And your english is perfect ;-)
<ijohnson> sdhd-sascha: I'm in Central US TZ, so it's basically EOD for me right now
<sdhd-sascha> WHAT ? EOD ? You mean NY
<sdhd-sascha> Or, i'm wrong again
<sdhd-sascha> didn't know anything again;-) ijohnson
<sdhd-sascha> my, ex - with my son - :-( - was in florida...
<ijohnson> EOD -> End of the Day
<sdhd-sascha> oh, thank you... i understand
<sdhd-sascha> good night
<sdhd-sascha> ijohnson: and again... sometimes i write on weekend (i day after i regret)
<ijohnson> sdhd-sascha: it's okay, just wanted to let you know so you didn't think folks were ignoring you, just that they're not around (even if they're still logged into IRC)
<ijohnson> Have a good night
#snappy 2020-01-22
<sdhd-sascha> you. all, too :-)
<sdhd-sascha> Ian. It's nice to read your message. Because my thing in my brain remembers, or something.. thank you, for learning ; -) just rembering the timezones ;-)
<mwhudson> how can i see when a branch is going to close?
<mborzecki> morning
<mup> PR snapd#8028 closed: tests: use test-snapd-upower instead of upower <Test Robustness> <â  Critical> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8028>
<pstolowski> morning
<zyga> good morning
<zyga> mwhudson: what do you mean?
<mwhudson> zyga: branches autoclose in 30 days right?
<zyga> mwhudson: ah, I see
<zyga> I _think_ so
<zyga> but I only used branches once
<zyga> and I didn't look at it after the week I needed it
<mwhudson> i'm sure i've seen the date a branch is due to close at somewhere in some command's output
<mwhudson> but i can't remember what
<roadmr> zyga, mwhudson : they do, and closure date might show in snapcraft status output
<roadmr> not sure snap info shows that
<roadmr> actually pretty sure snap info does NOT show that because it doesn't show branches at all :)
<roadmr> mwhudson: confirmed, you need to own the snap and use "snapcraft status" to see branch expiration timedate
<mwhudson> oh wait part of why i'm confused is that the branches i care about have already closed :)
<mwhudson> roadmr: thanks for checking that though :)
<roadmr> mwhudson: :P
<mborzecki> zyga: pstolowski: hey
<mborzecki> zyga: do you remember a discussion about debug symbols in snaps?
<mborzecki> zyga: there's a discussion about stripping arch packages, and someone brought up Clear Linux debug symbols support: https://docs.01.org/clearlinux/latest/guides/clear/debug.html#
<mborzecki> zyga: imo it does look intriguing
<mup> PR snapd#8030 closed: tests: add a command-chain service test <Simple ð> <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8030>
<zyga> mborzecki: yes, I do
<zyga> mborzecki: indeed, that is interesting
<zyga> mborzecki: can you add this so the thread somewhere or add a card to investigate it later
<zyga> gosh, I'm so sleepy today
<mborzecki> zyga: the fact that it's snowing doesn't make it better i suppose
<zyga> snownig?
<zyga> *snowing?
<mborzecki> zyga: or at least it's pretending to snow here
<zyga> really?
<zyga> it's raining here
<zyga> at +3
<roadmr> snowesome!
<zyga> I wish we had a real winter
<zyga> not this fake winter thing
<mborzecki> zyga: yeah, snowing very lightly and it melts right away
<zyga> I'm fighting the mount-ns test and the gadget test now
<zyga> I'll make real coffee (decaf doesn't work but doesn't cause headaches) and keep pushing
<roadmr> in soviet russia vinter melts you
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/8029 ?
<mup> PR #8029: tests: use test-snapd-upower instead of upower <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8029>
<zyga> oh, that's a 2.43 backport
<zyga> sure
<zyga> +1
<zyga> shall we just merge? I think so
<mborzecki> https://github.com/snapcore/snapd/pull/8027 is green, i'd land it and start working on a followup
<mup> PR #8027: snap: disable auto-import in uc20 install-mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8027>
<zyga> mborzecki: I see what you mean now, that's great
<zyga> it's green
<zyga> let's land
<zyga> though ian wanted to look
<zyga> can you work on a follow-up
<zyga> ian should be up soon-ish
<mborzecki> zyga: yeah, i will
<mborzecki> quick errand, back in 1h or so
<zyga> ok
<zyga> hmm
<zyga> what's /image.fstab?
<mup> PR snapcraft#2874 closed: Sync fixes from snapcraft-desktop-helpers (LP-1661626 & broken XDG link) <Created by MarcusTomlinson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2874>
<pstolowski> zyga, mborzecki are you guys familiar with test suites in spread?
<zyga> pstolowski: as much as we all are
<zyga> what's up?
<pstolowski> zyga: i defined a new one (which is a carbon copy of existing one, plus tweaks), but getting: error: nothing matches provider filter
<zyga> pstolowski: can you show me ze code
<pstolowski> spread -debug google-nested:ubuntu-18.04-64:tests/nested/preseed/
<zyga> you need an entry in spread.yaml
<zyga> and a directory with actual tests
<pstolowski> zyga: https://pastebin.ubuntu.com/p/7YRs9qT6w7/
<zyga> pstolowski: did you add tests to tests/nested/preseed?
<pstolowski> zyga: https://pastebin.ubuntu.com/p/3HFjMMrG7b/
<zyga> is the task manual?
<pstolowski> zyga: it's manual:true in the suite definition, not in the task ()it's the same for existing nested tests
<zyga> hmm
<zyga> can you spread -list and see it?
<zyga> brb
<pstolowski> aha, it's not shown, maybe indentation is off in the yaml
<pstolowski> nope, indentation is fine.. it must be something silly
<zyga> pstolowski: silly idea
<zyga> pstolowski: build spread and printf the yaml it loads
<zyga> pstolowski: or maybe spread -list -vv will show that, dunno
<zyga> I wonder what is
<pstolowski> zyga: indeed -vv prints it
<zyga> pstolowski: backends?
<zyga> and if you remove manual: true?
<zyga> ha
<zyga> I found a bar of chocolate
<zyga> it was on top of the fridge
<zyga> probably hid it so  that kids would not devour all xmas stuff at once
<zyga> $wife doing orange juice and needed to fetch the juicer
<pstolowski> :)
<pstolowski> removing manual:true doesn't help. my suite is visible as spread.Suite with -vv. something doesn't match somewhere apparently
<zyga> can you check backends
<zyga> I had an issue somewhere a while ago
<zyga> where a test would just not execute on anything defined
<zyga> because backends or systems didn't match
<pstolowski> zyga: aaah, silly me, solved. backends systems definition vs test's system as you said, thank you!
<zyga> cool :)
<pstolowski> i'll need sergio to figure out 19.10 and 20.04 on gc
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8031 when you are back
<mup> PR snapd#8031 opened: tests: update mount-ns test tables <Created by zyga> <https://github.com/snapcore/snapd/pull/8031>
<mup> PR #8031: tests: update mount-ns test tables <Created by zyga> <https://github.com/snapcore/snapd/pull/8031>
<zyga> mborzecki: in particular I think I found a bug in writable paths configuration
<zyga> mborzecki: as /etc/systemd/system is mounted twice
<mborzecki> re
<zyga> mborzecki: o/
<mborzecki> oh, that's interesting
<mborzecki> zyga: does that only happen on core?
<zyga> system or machine-id?
<zyga> I think only on core
<zyga> let me check
<mborzecki> /etc/systemd/system moutned twice
<zyga> yeah
<zyga> note that it is mounted on HOST
<zyga> so it's there before we touch it
<mborzecki> zyga: maybe related to /etc/systemd/system coming from writable
<zyga> I bet some code manually does it
<zyga> I checked core18 and it's only listed once
<mborzecki> or the whole /etc/systemd, don't remember how wriable-paths is set up in 18
<zyga> so ... dunno
<sdhd-sascha> hey, is there another interface for the call `sched_setscheduler` ? I only found `process-control`, `docker`, `browser` ? It seems that music-application, like synthezier and midi-sequencer also needs this.
<zyga> I don't think so
<zyga> there used to be rtkit
<sdhd-sascha> hmm, `process-control` could be good enough.
<zyga> that would allow apps to use it without privs
<zyga> sdhd-sascha: do you have an app that needs it?
<sdhd-sascha> zyga: true, thank you
<sdhd-sascha> in #snapcraft, there i test `gsequencer` snap https://bazaar.launchpad.net/~jkraehemann/+junk/gsequencer-3/files
<sdhd-sascha> i just see this call in the logs. Is not for me
<zyga> mborzecki: check this out
<zyga> https://www.irccloud.com/pastebin/89vWxX4n/
<zyga> just a quick prototype
<zyga> the diff is tiny, I'll check how it changes the usability of the data
<zyga> I suspect it will let us see meaningful diffs across core systems
<zyga> brb
<zyga> mborzecki: also note the machine-id thing
<zyga> it feels very fishy
<zyga> unless I am looking at some tmpfs-not-persistent view
<zyga> but I doubt taht
<zyga> *that
<mup> PR snapd#8027 closed: snap: disable auto-import in uc20 install-mode <UC20> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8027>
<zyga> re
<zyga> hey ian!
<zyga> thanks for merging that
<zyga> mborzecki: ^ follow-up space ready
<mborzecki> mhm
<ijohnson> Hey folks
 * ijohnson is not really here yet
<pstolowski> hi ijohnson!
<mup> Issue core20#12 opened: Drop consoleconf from the core snap <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> PR core20#11 opened: Add arm64 architecture <Created by xnox> <https://github.com/snapcore/core20/pull/11>
<zyga> eh, mup still gives bad github urls
<zyga> mborzecki: I simplified the differential idea, I love it
<zyga> mborzecki: thank got python has type inheritance on base types
<zyga> mborzecki: so all I needed was sint(int) that renders as {:+}
<zyga> and a few patch-ups to use sint() when diffing
<zyga> I'll check how this behaves in reality in core16
<zyga> but I'm very optimistic now
<zyga> mborzecki, ijohnson: I'd like to land this https://github.com/snapcore/snapd/pull/8031
<mup> PR #8031: tests: update mount-ns test tables <Created by zyga> <https://github.com/snapcore/snapd/pull/8031>
<zyga> green
<zyga> please review / object
<mup> PR snapd#8032 opened: boot, cmd/snap(-bootstrap): move run mode and system label detection to boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8032>
<mborzecki> cmatsuoka: ^^ can you take a look
<cmatsuoka> mborzecki: sure, I'm just finishing a fix here
<zyga> guys, I need to skip standup
<zyga> or I'll join from the go
<zyga> need to help wife as she drives around with lucy
<cmatsuoka> ack
<zyga> plus no food at home and starving to eat out
<zyga> I'll keep working on a feature branch on the ho
<zyga> *go
<mup> PR snapd#8033 opened: Tweak/differential mount ns <Created by zyga> <https://github.com/snapcore/snapd/pull/8033>
<ijohnson> zyga: yeah I reported the mup GitHub issue links to Gustavo a while ago
<zyga> ^ just a draft, partial data change, won't pass
<ijohnson> zyga: also yes I will review your branch after SU
<zyga> ijohnson: I think I did so as well
<zyga> ijohnson: thanks!
<zyga> going now
<zyga> ttyl
<zyga> I'll publish testbed-tool today
<zyga> didn't figure out a better name, open to rename later
<mborzecki> ijohnson: have you started looking into a spread test for kernel failover? if not i can look into that
<mup> PR snapcraft#2888 opened: elf: read ELF type when extracting attributes <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2888>
<ijohnson> mborzecki: do you mean for the uc20 kernel extraction? I have not yet done a spread test, but I have started a bit what we talked about with pedronis on Friday about panic'ing in the mock bootloader
<mborzecki> ijohnson: i can try with actual broken kernel, to see how complicated that is
<zyga> re
<zyga> online in the back seat
<zyga> all three kids accounted for
<zyga> dog included
<zyga> man
<zyga> we travel like polish memes
<ijohnson> mborzecki: I tried the failover with an empty file as the kernel.efi but the bootloader just hung, so if you had a real broken kernel that panicked immediately that would be better for tests
<cmatsuoka> can I un-approve a PR after I already approved it?
<mborzecki> cmatsuoka: you can dismiss your review
<mborzecki> cmatsuoka: should be near the bottom of the page, where the ci checks are listed
<cmatsuoka> hmm, let me see...
<cmatsuoka> Ok, nice, thanks!
<ogra> zyga, https://imgur.com/a/XtGYPeI ... about 200 layout entries now ... but it runns fully confined (as root, no gdm/lightdm though)
 * ogra is very surprised to not see an actual performance impact from these many layouts 
<zyga> ogra: OMG
<zyga> I need to rework some layout code to make it better
<ogra> it would be really awesome to have  something luke "auto-layout" ...
<ogra> simply diff $SNAP with / and automatically add bindmounts and symlinks for all non-existing files in /
<ogra> s/luke/like/ ... :)
<mborzecki> ijohnson: standup?
<diddledan> mborzecki, sit down!
<mup> PR snapcraft#2889 opened: meta: always generate snapcraft-runner to workaround classic PATH bug <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2889>
<zyga> back!
<zyga> what did I miss
<zyga> mborzecki: is the standup over?
<mborzecki> diddledan: rinse and repeat :)
<mborzecki> zyga: yup
<ijohnson> zyga: you missed the part where I heroically came in at the last minute to standup
<zyga> haha
<zyga> if you were a moment longer I could have joined too :)
<zyga> but no worries
<ijohnson> :-)
<zyga> my standup update is simple: fixed one more branch (green), working on leaky tests
<ijohnson> also did you see my comment on your core20 mount ns PR?
<zyga> as an associated brach-off I updated mount-ns tables
<zyga> ijohnson: not yet
<zyga> and I'll open another PR that does differential tables
<ijohnson> just a quick thing not sure if you had a typo or if we do actually have an issue there
<zyga> probably not a typo
<ijohnson> hmm :-/
<zyga> ijohnson: so (/dev/sda3)/EFI/ubuntu was mounted as /boot/grub
<zyga> ijohnson: (if this syntax makes sense)
<zyga> ijohnson: is that unexpected?
<ijohnson> yes that makes sense
<ijohnson> your PR description said /boot/grub was from /boot/EFI
<zyga> ijohnson: in any case I think this PR showed some suspicious stuff and I'm happy I updated those tables
<ijohnson> (missing the /ubuntu) at the end
<zyga> ah, probably mistake there :)
<ijohnson> :-)_
<zyga> I did type the commit by hand
<zyga> while outside I got a veggie burger
<zyga> and it was ... good
<zyga> not great but not bad either
<zyga> need to try some more
<zyga> ijohnson: I revised the commit message
<mup> PR snapd#8024 closed: overlord/snapstate: add reproducer for LP#1860324 scenario <Created by bboozzoo> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/8024>
<mup> PR snapd#8025 closed: overlord/snapstate: add reproducer for LP#1860324 scenario (2.43) <Created by bboozzoo> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/8025>
<ijohnson> zyga: have you tried the "impossible burger" ?
<zyga> ijohnson: nobody sells them here yet
<zyga> but I heard about it
<ijohnson> zyga: ah I see
<ijohnson> I haven't tried it myself yet either
<ijohnson> I really like these black bean veggie burgers from the supermarket though
<ijohnson> don't remember the brand
<zyga> I love beetroot burgers
<zyga> we make them at home
<ijohnson> interesting never tried beetroot burgers
<mborzecki> zyga: beetroot in place of meat or the bun?
<zyga> mborzecki: meat
<zyga> it's not pure beetroot, I can ask my wife for the recipe
<zyga> but the taste is insane :)
<zyga> I love those really
<zyga> we bake them in the oven
<mborzecki> btw. if it has no mean, can it still be called a burder or does it downgrade to sandwich at that point? :P
<mborzecki> s/mean/meat/
<zyga> and when we make a batch it's usually 30-50
<zyga> we eat half and freeze the rest or give them away
<zyga> mborzecki: I think nobody can claim it is not a burder ;-)
<zyga> https://github.com/snapcore/snapd/pull/8031 <- review please
<mup> PR #8031: tests: update mount-ns test tables <Created by zyga> <https://github.com/snapcore/snapd/pull/8031>
<zyga> it's just the data tables
<zyga> and I can open the follow-up on top
<mup> PR snapd#8034 opened: fix for lp:1860324 for 2.43 <Created by chipaca> <https://github.com/snapcore/snapd/pull/8034>
<__chip__> ð
<zyga> hey __chip__
<__chip__> #8034 should be interesting
<mup> PR #8034: fix for lp:1860324 for 2.43 <Created by chipaca> <https://github.com/snapcore/snapd/pull/8034>
<zyga> __chip__: ouch, updated vs updates!
<__chip__> as soon as samuele can there'll be one against master (already pushed so you can look at it if you want but not proposed so missing my test)
<zyga> mhm
<zyga> thank you for finding the time to propose those at the sprint!
<__chip__> to be clear, this is a bug on master, 2.43 just makes it more likely
<zyga> we'll get them reviewed
 * zyga nods
<__chip__> but it's subtle enough that it warrants another 2.43, at least the last time i was able to talk about it with mvo
<zyga> __chip__: did any new data on the __writable__ issue came up at the sprint?
<__chip__> zyga: not yet, i think we're waiting for info from $customer but i don't know if we've asked them yet :|
<__chip__> zyga: i'll ask
<ijohnson> __chip__: zyga: I asked the customer in the bug but didn't hear anything back
<zyga> ack, thank you guys
<__chip__> ijohnson: was the customer reading the bug, or did it need to go via field?
<__chip__> 'cause all i was going to do was ask field :)
<__chip__> (which i can still do, sometimes the cable needs jiggling)
<ijohnson> __chip__: the customer reported the bug and responded to a question I asked on Friday so I assume that they are reading it, but they might have been busy with other things mon/tues
<zyga> __chip__: the bug tracker was customer specific so I would expect they follow it
<__chip__> ah
<__chip__> k
<ijohnson> __chip__: yeah probably worth trying to talk to John Agosta in CPT to raise it with them
<ijohnson> raise it -> make sure that the customer tries our suggestionss
<__chip__> ijohnson: will do
<ijohnson> __chip__: ack thanks
<mborzecki> __chip__: thanks for the PR! edited the title so that the title checks are happy
<__chip__> ah, yeh thanks
<mup> PR snapd#8035 opened: data/selinux: workaround incorrect fonts cache labeling on RHEL7 (2.43) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8035>
<mborzecki> pstolowski: ^^
<pstolowski> sure
<zyga> mborzecki, ijohnson: ping on https://github.com/snapcore/snapd/pull/8031 please
<mup> PR #8031: tests: update mount-ns test tables <Created by zyga> <https://github.com/snapcore/snapd/pull/8031>
<zyga> it's just data tables!
<ijohnson> zyga: but it's almost 2000 lines of data tables! :-)
<zyga> yes but they are what we do today
<zyga> we can argue if that's correct but that's just a snapshot
<zyga> note that I don't mind if you read them in detail
<zyga> the next PR after that will make it less painful to do changes
<zyga> (after another painful change though)
<ijohnson> hmm wasn't your re-numbering option supposed to prevent things like this?
<zyga> it makes them less severe
<zyga> but as I explain in the follow-up
<zyga> it's not immune to insertion in the middle
<zyga> that causes re-numbering
<zyga> the follow-up switches to delta encoding
<ijohnson> i.e. for xenial it was `1:1 /system-data/etc/systemd/user /etc/systemd/user rw,relatime shared:45 - ext4 /dev/sda3 rw,data=ordered` and now it's just `1:1 /system-data/etc/systemd/user /etc/systemd/user rw,relatime shared:46 - ext4 /dev/sda3 rw,data=ordered`
<zyga> so insertions in the middle don't affect the rest as much as they did
<ijohnson> the only difference being that 45 changed to 46
<zyga> yeah
<ijohnson> but I thought you sorted it and re-numbered it?
<ijohnson> oh wait I see what you mean
<zyga> yes but something else became :45
<ijohnson> there's a new thing that was added
<zyga> right
<ijohnson> sorry a bit slow today
<zyga> I mean, it's not perfect, it's already a bit distant from the totally volatile original
<zyga> but this will make it better :)
<zyga> the problem is that core tables are out of date
<zyga> because those test were disabled
<zyga> and we missed some updates the core snap being reflected
<ijohnson> zyga: submitted
<ijohnson> err approved
<zyga> :D
<zyga> thank you!
<zyga> I'll open the follow up shortly
<ijohnson> zyga: but also I do like the relative numbering idea to reduce the diff to protect against this kind of thing
<zyga> yeah
<zyga> it's super costly and painful to read
<mborzecki> yeah, we'll know more once the tests are enabled on core
<zyga> just doing classic side now
<zyga> and I'll fix those bugs with gadget snaps
<zyga> at least one
 * zyga braces for the fight!
<mup> PR snapd#8031 closed: tests: update mount-ns test tables <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8031>
 * ijohnson recommends zyga look for the mount ns excalibur
<mup> PR snapd#8036 opened: snapstate: refactor things to add the re-refresh task last <Created by pedronis> <https://github.com/snapcore/snapd/pull/8036>
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8033
<mup> PR #8033: tests: switch mount-ns test to differential data set <Created by zyga> <https://github.com/snapcore/snapd/pull/8033>
<zyga> ijohnson: I love how github rendered some of the diffs
<zyga> https://github.com/snapcore/snapd/pull/8033/files#diff-9593b62bc67b4cedc7e7106954025f18
<zyga> e.g. here
<zyga> it's clear what only the relevantparts are changed
<zyga> and I can really read the diff
<zyga> 16.04 -> 18.04 is just a few changes
<zyga> that are all explainable
<ijohnson> yes that is very nice
<zyga> wow' it's raining heavily now
<ijohnson> do you have an example of what it would look like if a new mount was added in the middle to see that the generated diff is very small then ?
<zyga> https://usercontent.irccloud-cdn.com/file/ckBZMBmf/classic%2016.04%20vs%20classic%2018.04%20mount%20ns
<zyga> just look at this
<zyga> those are real tables for 16.04 and 18.04
<zyga> with changes in the middle
<ijohnson> that's great
<ijohnson> much much better, good work!
<ijohnson> maybe include that screenshot in the PR as a comment for other reviewers?
<zyga> yeah
<zyga> good idea
<zyga> https://usercontent.irccloud-cdn.com/file/7loYb2PY/core%2016%20vs%20core%2018%20mount%20ns
<zyga> this one is a lot different
<zyga> but the diff is really readable now
<ijohnson> here's a silly question - do we even need those mount numbers at all for your actual tests?
 * ijohnson doesn't remember what the actual original test looks for
<zyga> that's a good question
<zyga> it's hard to answer
<zyga> for the shared: parts I'd strongly say yes
<zyga> for the major:minor it's useful but probably for debugging (i.e. it will tell you what the device really was)
<zyga> for mount_id parent_id it's also less clear but perhaps for debugging
<zyga> I think the strongest case is for the shared: master: numbers
<zyga> those really mean stuff
<ijohnson> right
<zyga> as in, right vs broken
<ijohnson> hmm well something to think about perhaps
<zyga> screenshot added
<zyga> oh, 14.04 !
<zyga> forgot about that
<zyga> I'll force-push one more change
<zyga> ah, no
<zyga> it's not there, just enabled too many things locally
<zyga> uff :)
<zyga> ijohnson: I'll do one more pass locally without the major:minor
<zyga> and perhaps an --exclude feature
<zyga> to remove some of the annoying cgroup changes that caused breakage before
<zyga> but first... tea break
<zyga> it's still cold in the office :/
<zyga> I wonder if winter comes at all this year
<ijohnson> zyga: shall I bring some snow to frankfurt for you to take home?
<ijohnson> :-)
<zyga> haha, I wonder if you actually will
<zyga> with the climate upside down
<zyga> march may be snowy
<roadmr> we had days above zero in Montreal, in January... go figure
<zyga> roadmr: yesterday the temperature in warsaw and in the canary islands was the same
<zyga> +6
<roadmr> haha
 * zyga goes fetch that tea
<roadmr> definitely a more valid comparison than "it's as cold as mars"
<roadmr> at this rate it'll be "it's hotter than venus"
<zyga> (robot announcing the weather) GOOD MORING REMAINING HUMANS; TODAY IS A LOVELY DAY WITH TEMPERATURES AT AROUND +370C; NIGHT WILL BE BELOW ZERO, BELOW -200C TO BE EXACT; HA HA HA; STAY WARM WARM-BLOODS!
<roadmr> more slaves for my robot colony
<mup> PR snapcraft#2890 opened: extensions: add opengl extension to support classic and strict <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2890>
 * sdhd-sascha oh - oh ... i don't wan't to disturb someone ---- big sorry ;-)
<sdhd-sascha> is it for you the same, that younge poeple want learn ? or is this only my person who is strange...
<sdhd-sascha> wan't
<sdhd-sascha> i consider, you can be `consuldant` ... or ... but didn't work..
<sdhd-sascha> hmm... d... mn
<sdhd-sascha> have had visit .. i talk about tesla - and that every informtic-problem is solved now ... and so on...
<sdhd-sascha> ...
<sdhd-sascha> (my wife is afraid, that i'm again a plant eater .. ;-) )
<sdhd-sascha> zyga: hey, again, thank you ;-) the python library i mean ,  was used by `conjure-up` ... but can't remember *widget..*
#snappy 2020-01-23
<mborzecki> morning
<mup> PR snapd#8035 closed: data/selinux: workaround incorrect fonts cache labeling on RHEL7 (2.43) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8035>
<mup> PR snapd#8014 closed: tests: run `uc20-snap-recovery-encrypt` test on 20.04-64 as well <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8014>
<jamesh> looks like the nakedret static check is failing CI runs that were passing previously
<jamesh> seems the tool fixed a bug 5 hours ago and showed up a bunch more errors: https://github.com/alexkohler/nakedret/pull/10
<mup> PR alexkohler/nakedret#10: Fix bug with not detected nested returns <Created by programmer04> <Merged by alexkohler> <https://github.com/alexkohler/nakedret/pull/10>
<mup> Bug #5: Plone Placeless Translation Service metadata missing from po files <feature> <iso-testing> <lp-translations> <Launchpad itself:Fix Released by daf> <https://launchpad.net/bugs/5>
<jamesh> it seems the tool previously only detected naked returns at the top level of the function, ignoring any embedded in blocks
<jamesh> ah.  Looks like the new nakedret version is throwing up false positives
<zyga> o/
<jamesh> it doesn't understand nested functions
<mborzecki> jamesh: hmmm ehh, looks like a bug in nakedret
<mborzecki> maybe something i can fix
<jamesh> mborzecki: yeah.  I'm filing a bug report now
<zyga> thank you guys
<jamesh> mborzecki: here's the bug report with a trivial example reproducing it: https://github.com/alexkohler/nakedret/issues/11
<mborzecki> jamesh: thanks for the report!
<jamesh> mborzecki: I've got some idea of how to fix the script.  Are you already working on it, or should I give it a crack?
<mborzecki> jamesh: i'm looking into nakedret, feel free to fix the script
<jamesh> mborzecki: I meant nakedret :-)
<jamesh> should have said tool rather than script
<mborzecki> jamesh: ah, ok, then go ahead :) don't want to spoil the fun
<jamesh> okay
<mborzecki> jamesh: heh, never played with go ast, i guess since ast.Inspect is depth first, i gets to the return in the nested func() block first without noticing it's a separate nested func, is that your thinking as well?
<jamesh> mborzecki: I was thinking of just doing the whole job in Visit, substituting a new Visitor whenever we encounter a new function
<pstolowski> morning
<mborzecki> pstolowski:  hey
<mborzecki> jamesh: hmm looking more, i have a feeling nakedret doesn't actually handle naked return in function literals
<zyga> hmm, when rebooting my ubuntu system "a stop job is running for Service for snap application lxd.daemon"
<zyga> and just sits there until 10 minutes elapse
<jamesh> mborzecki: yeah.  that'd be an ast.FuncType with no ast.FuncDecl, I think
<jamesh> no.  That's not quite right
<mborzecki> jamesh: FuncLit
<zyga> brb
<jamesh> mborzecki: thanks
<mborzecki> jamesh: so this bit skips function literals https://paste.ubuntu.com/p/ZTYjQkDHbt/
<jamesh> mborzecki: I was thinking of adding literals rather than skipping them
<mborzecki> jamesh: yeah, i suppose returnVisitor could be smarter and just accept FuncDecl and FuncLit, while the nested ast.Inspect could skip FuncLit
<jamesh> mborzecki: here's what I've got so far: https://paste.ubuntu.com/p/RQBnqKtjDP/
<__chip__> ð
<mborzecki> jamesh: got this https://paste.ubuntu.com/p/ThN9FnbpyH/
<mborzecki> __chip__: hey
<__chip__> network seems laggy
<__chip__> mborzecki: hiya
<jamesh> mborzecki: here's my PR: https://github.com/alexkohler/nakedret/pull/12
<mup> PR alexkohler/nakedret#12: Handle function literals and nested functions <Created by jhenstridge> <https://github.com/alexkohler/nakedret/pull/12>
<__chip__> new nakedret, need to push a pr to address new failures
<mborzecki> jamesh: cool, looking
<__chip__> unless somebody else already has?
<mborzecki> __chip__: false positives, jamesh is trying to fix it upstream
<jamesh> mborzecki: I might steal your naming for literals
<mborzecki> jamesh: go ahead, was about to add a comment there :)
<__chip__> oh!
<jamesh> there's two real problems in testutil/containschecker.go, lines 89 and 129
<__chip__> jamesh: glad you're on it
<mborzecki> tbh, i like how it's easy to work with go ast, i mean, both of us could address the problem quite easily
<__chip__> i'll go to the snaps performance session then
 * __chip__ agrees with mborzecki 
<__chip__> ISTR even the python ast wasn't as nice
<__chip__> but i've grown since i tried to use that so maybe not
<jamesh> __chip__: the old nakedret only detected nakedret only detected problems at the top level of a function, ignoring returns in blocks
<jamesh> the new nakedret is too aggressive and misattributes return statements in embedded function literals
<__chip__> it was a very simplistic first pass, yes
<__chip__> seems they overshot in the new year :)
 * __chip__ out
<mborzecki> in the meantine, we need to unblock master :P
<abeato> zyga, hey, how is snapd development these days? I bind mount my binary to /usr/lib/snapd/snapd but I get this error:
<abeato> cannot run daemon: state startup errors: [cannot obtain snap-seccomp version information: invalid format of version-info: "051a668fa5c47aa16280298ed72cc38c8ac3dc40 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af"]
<mborzecki> jamesh: i'll fix snapd master
<abeato> s/how is/how is it done/
<jamesh> mborzecki: okay.  Disable the check, and fix testutil/containschecker.go ?
<mborzecki> jamesh: yes
<pstolowski> abeato: you also need snap-seccomp binary rebuilt from same tree; if running snapd directly from builddir (instead of bind-mounting) you can copy snap-seccomp into cmd/snapd dir
<abeato> pstolowski, ok, so I can rebuild snap-seccomp and bind mount to /usr/lib/snapd/snap-confine?
<abeato> -seccomp I meant
<zyga> Snap-seccomp
<zyga> Yeah
<zyga> But
<zyga> I rarely do that
<zyga> Just build and run from tree
<zyga> Make sure snap-seccomp and snapd are siblings (symlink is ok)
<pstolowski> yeah that's what i always do too; i've never bind-mounted it
<abeato> I was building in another machine - but yeah, I can build there too
<abeato> thanks
<mup> PR snapd#8037 opened: travis, tests, run-checks: skip nakedret <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8037>
<mup> Issue core18#145 opened: pollinate missing from core18 snap <Created by rcj4747> <https://github.com/snapcore/core18/issue/145>
<mborzecki> zyga: pstolowski: ^^ trivial PR
<mup> PR core18#146 opened: Add pollinate to the extra packages #144 <Created by rcj4747> <https://github.com/snapcore/core18/pull/146>
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8037#pullrequestreview-347158408 imo the problem is that it's not immediately clear what could be the value returned by given piece of code
<mup> PR #8037: travis, tests, run-checks: skip nakedret <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8037>
<mborzecki> zyga: you may still need to read back and analyze, but it's even less clear when there just 'return'
<mborzecki> zyga: tbh i find named return variables to have only documentation value, and maybe if you need to do some trickery in deferred code but that requires really good reason to do so
<jamesh> zyga: there's also a proposal to remove them in Go 2: https://github.com/golang/go/issues/21291
<zyga> hmm
<zyga> I guess it depends on context
<jamesh> (that doesn't mean they will actually be removed though: just that some people think they should)
<zyga> I'm feeling sick today, sorry for being slow
<zyga> I'll warm up the office grab some meds and be back
<sergiusens> pstolowski: is the configure hook triggered with a "snap start|stop" and is it possible to know the hook was triggered due to this event?
<pstolowski> sergiusens: no, it's not triggered, start/stop simply wrap systemctl
<sergiusens> pstolowski: ah, thanks
<pstolowski> sergiusens: nb hooks are always run under a snapd task, so you would see a task under a change in snap changes / snap change <id>
<zyga> back, feeling slightly better now
<zyga> hmm
<zyga> oddly enough I'm making progress
<zyga> fresh ideas, even when I'd rather sleep all day
<zyga> mborzecki: btw, I made the dprintf change
<mborzecki> zyga: cool, did you push it already?
<zyga> yesterday
<mborzecki> hmm https://github.com/snapcore/snapd/pull/8037 SKIP_NAKEDRET isn't picked up from environment?
<mup> PR #8037: travis, tests, run-checks: skip nakedret <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8037>
<zyga> it's green :)
<zyga> mborzecki: ... weird?
<zyga> is the test correct? why exit 1 ?
<mborzecki> heh, the unit test is run as a different user
<zyga> ahhh
<mborzecki> ok, force pushed a fix, should be good now
<zyga> ... ... ...
<zyga> iterating on core tests sucks
<zyga> like badly
<zyga> I wonder what we could do to make that faster
<zyga> could we boot core, install lxd, pull the sources, build, install the snaps and carry on without rebooting and wiping the disk?
<mborzecki> zyga: we need to build a custom core/snapd snaps and build a whole image with that
<mborzecki> zyga: maybe we should try to take some time to improve that, but local testing sucks too
<zyga> not sure if we need to build the whole image with that
<zyga> it depends on the test
<zyga> we could have a suite that does that
<zyga> but I could iterate on pretty much all my core work without that property
<zyga> but I see your point
<mborzecki> although local testing is much fater, because my deskop is way faster than the gcp vms we use
<mborzecki> s/fater/faster/
<mborzecki> that, unless you need to work with a device :/ then it sucks again
<mborzecki> quick errand at the tax office, back in 1h or so
<zyga> holly shit, fixed it :D
<zyga> mborzecki: my local testing is slower
<zyga> mborzecki: but it's always network bound
<zyga> mborzecki: I hacked (over two years ago) totally offline spread test loop
<zyga> and it was insanely fast
<zyga> with many-core qemu
<zyga> pre-cached snaps inside VM
<zyga> apt-cacher-ng for all apt stuff
<zyga> it was super nice
<zyga> I even hacked it so that builds were incremental
<zyga> (as long as you --reuse)
<zyga> but we don't have that property
 * zyga runs one clean loop to see
<zyga> mborzecki: that's one fixed and one or two to go (forgot exact number)
<zyga> but progress :)
<zyga> whee
<zyga> so happy
<zyga> this is real :)
<zyga> PR coming up in 15-20 minutes
<zyga> mborzecki, pstolowski: please review
<zyga> https://github.com/snapcore/snapd/pull/8038
<mup> PR snapd#8038 opened: tests: fix gadget-update-pc test leaking snaps <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8038>
<mup> PR #8038: tests: fix gadget-update-pc test leaking snaps <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8038>
 * zyga high-fives himself, onto the next failure!
<pstolowski> zyga: looking
<roadmr> zyga: I call that progress
<zyga> roadmr: I stared on this early last year
<zyga> roadmr: and just never managed to come up with something that would work
<zyga> this is so simple now
<zyga> eh
<zyga> nacked returns haunt me
<zyga> and the fix for that failed
<zyga> did they fail because of hooks snap
<zyga> are we in a catch 22?
<zyga> + [[ -n 1 ]]
<zyga> /bin/bash: line 89: skip: unbound variable
<zyga> mborzecki: ^
<zyga> what?
<zyga> oh
<zyga> I see it
<zyga> btw, why did you say if [[ -n ... ]]
<zyga> rather than if [ -n ... ] ?
<zyga> mborzecki: ^
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8037/files#r370072706
<zyga> please apply
<mup> PR #8037: travis, tests, run-checks: skip nakedret <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8037>
<jamesh> zyga: btw, I refactored https://github.com/snapcore/snapd/pull/7588 a bit to move the cgroup based pid->snap helper to sandbox/cgroup.  I was hoping to have a green CI tick by now to ask for more review, but got stuck on the nakedret problem
<mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<zyga> jamesh: I'm sorry, I'll have a look at that
<zyga> jamesh: looks great, once either branch lands I'll adjust the other
<zyga> pstolowski: like this? https://github.com/snapcore/snapd/pull/8038/files#r370078320
<mup> PR #8038: tests: fix gadget-update-pc test leaking snaps <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8038>
<pstolowski> zyga: yep, it's even better than my suggestion, ty
<zyga> cool, I'll integrate that back when the master blockers are fixed
<mborzecki> re
<zyga> welcome back, please check the comment above
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8037
<zyga> this should unbreak your PR
<mup> PR #8037: travis, tests, run-checks: skip nakedret <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8037>
<zyga> which will unbreak master and many other PRs
<mborzecki> huh, it failed?
<zyga> mborzecki: shellcheck
<zyga> mborzecki: $skip is unset
<mborzecki> zyga: shellcheck does not complain
<zyga> hmm? didn't it in the log
<zyga> ah
<zyga> mborzecki: /bin/bash: line 89: skip: unbound variable
<zyga> well, anyway
<zyga> not shellcheck
<zyga> (which is weird)
<zyga> but still
<mborzecki> weird, don't remember spread tasks runnig with set -u
<zyga> fixing next test, ubuntu-core-refresh
<zyga> should be simple
<zyga> wow, I feel like this week will end without leaks
<zyga> and re-enabled mount-ns tests
<mborzecki> haha nakedret fix landed, before we managed to land 8037
<zyga> shall we skip it then
<zyga> and just re-trigger?
<mup> PR snapcraft#2888 closed: elf: read ELF type when extracting attributes <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2888>
 * roadmr keeps reading that as nakedregret
<zyga> to me it just reads as nekker
<mborzecki> zyga: too much witcher :P
<zyga> "fuck" ;-)
<mborzecki> hahah
<mborzecki> zyga: i think i'll push an update to task.yaml, but will leave the knobs in run-checks
<zyga> sounds reasonable,
<jamesh> there were real nakedret failures in master, so 8037 needs to be landed either way
<roadmr> nakedrat!! https://en.wikipedia.org/wiki/Naked_mole-rat
<zyga> ok, one more test fixed
<zyga> PR a soon as I confirm
<mborzecki> this is nice https://rakyll.org/inlined-defers/
<zyga> brb
<zyga> coffee
<pstolowski> @mborzecki: oh, interesting, "This overhead is why Go developers started to avoid defers in certain cases to improve performance"
<pstolowski> is nakedret SFW? ;)
<mborzecki> pstolowski: yeah, must have skipepd the memo on that or sth
<mvo> pstolowski: hey, quick question - what's the state of the "snap refresh" of a disabled service will re-enable this service
<pstolowski> mvo: hi! it was fixed by ijohnson some time ago
<mvo> pstolowski: do you remember if the fix is in 2.43 or even earlier?
<pstolowski> mvo: no, let me check
<zyga> re
<zyga> hey mvo
<zyga> another test fixed :)
<mvo> pstolowski: it's fine, got asked this question here during the sprint
<mvo> zyga: hey! nice to see you
<pstolowski> mvo: appears to be fixed in 2.43, commit 98c1da1c2b75883585e606d935dfff694e257753 on 2019-11-19
<mvo> pstolowski: thank you!
<mup> PR snapd#8039 opened: tests: remove revision leaking from ubuntu-core-refresh <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8039>
<ijohnson> hi mvo! Yes the fix is in 2.43
<mup> PR snapd#8040 opened: gadget: skip update when raw structure content is unchanged <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8040>
<pstolowski> mvo, ijohnson it was https://bugs.launchpad.net/snapd/+bug/1827237
<mup> Bug #1827237: disabled services are re-enabled after revert <snapd:Fix Committed by anonymouse67> <https://launchpad.net/bugs/1827237>
<zyga> mborzecki: +1
<zyga> mborzecki: question about this feature
<mborzecki> zyga: hm?
<zyga> mborzecki: is there anything one could do to fix a device that has broken raw partition content
<zyga> mborzecki: e.g. interactively working on a device
<zyga> dd gone souht
<zyga> south8
<zyga> south*
<zyga> device still booted so you can fix it
<zyga> is there any command that would "ensure" that partitions are as expected
<zyga> and that the content is as expected?
<mborzecki> zyga: we have no such things yet
<zyga> ok
<mborzecki> zyga: and there's probably scenarios where gadget.yaml would be insufficiently expressive
<mborzecki> zyga: idk if there's a plan to have a like a factory reset perhaps
<zyga> I think it would have to be a debug command
<zyga> "debug ensure-partitions" or something
<mborzecki> zyga: i had a debug command that would dump the expected layout, but nothing that actually compares and lists differences if any
<mborzecki> hhm perhaps a dry-run gadget update would be useful
<zyga> hmm
<zyga> indeed
<zyga> even as a "here's what would happen so that you can make a more informed decision"
<roadmr> does anyone know of any snaps that bundle a mysql server as required by the snapped software? is there something I can reuse for that?
<jamesh> nextcloud maybe?
<zyga> yes, nextcould for sure
 * zyga needs to check up on kids, fix for the last test seems very easy, just needs about 2-3 tries to ensure 
<zyga> brb
<roadmr> thanks jamesh zyga I'll look at nextcloud!
<zyga> huh
<zyga> my wife just returned home
<zyga> and bought me two spools of duct tape
<roadmr> ðª
<zyga> like... what?
<roadmr> zyga: what's she trying to tell you ð¤
<zyga> :D
<mborzecki> lp timeouts again
<ijohnson> mborzecki: #8037 is green
<mup> PR #8037: travis, tests, run-checks: skip nakedret <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8037>
<mborzecki> and now we'll fill up the travis build queue :)
<ijohnson> :-)
<mup> PR snapd#8037 closed: travis, tests, run-checks: skip nakedret <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8037>
<ijohnson> mborzecki: have you had a chance to review #8001 again? is there anything else you think I should add to that PR before we can merge it?
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<mborzecki> ijohnson: let me see, i think it shoudl be +1 for me
<mborzecki> ijohnson: we're still blocked on samuele/mvo, aren't we?
<ijohnson> mborzecki: great, still waiting for pedronis and/or mvo on that but just wanted to get it as close as possible before they look
<ijohnson> mborzecki: yes still blocked waiting for them
<zyga> trying a fix for the last one
<zyga> fingers crossed
<mup> PR snapd#8041 opened: tests, run-checks, many: fix nakedret issues (2.43) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8041>
<zyga> 3rd reboot
<zyga> fingers crossed
<zyga> maybe it will be green now
<zyga> success
<zyga> wow
<zyga> all three fixed in one day :)
<zyga> mborzecki: is master green now?
<mborzecki> zyga: should be
<zyga> super
<zyga> mborzecki: can you review the two test robustness PRs
<zyga> I'm opening the last one
<mup> PR snapd#8042 opened: tests: remove revision leaking from remodel-kernel <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8042>
<zyga> I rebased all three fixes
<zyga> and will grab lunch now
<zyga> afk
<mborzecki> i'm going for a late lunch with the kids somewhere in the city, i'll check the PR state in the evening
<zyga> pstolowski: could you review the 2nd of the fixes
<zyga> https://github.com/snapcore/snapd/pull/8039/files
<mup> PR #8039: tests: remove revision leaking from ubuntu-core-refresh <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8039>
<zyga> I will have half of reviews this way
<zyga> I'll do a pass to add --purge to them as well
<pstolowski> sure
<zyga> I still have three red PRs but one will turn green soon
<zyga> and that's only two remaining for tomorrow
<zyga> I may get one more today, need to check how much work it is
<pstolowski> zyga: nb purge only makes sense when the last revision gets dropped
<zyga> ah
<zyga> didn't think of that
<pstolowski> zyga: i mean, you can pass it, just has no effect
<pstolowski> *always pass it*
 * zyga runs larger batch of tests and takes a break
<zyga> I'll come back to explore
<zyga> jdstrand: hey
<zyga> jdstrand: how does your queue look like?
<zyga> jdstrand: do you think you could review the setgid PR this week?
<zyga> (7980)
<jdstrand> zyga: it is the queue for 2.44. I doubt it will be this week, but hope to have a big PR push next week
<zyga> jdstrand: understood thanks!
<zyga> I'm working on the backlog so no emergency but I'd love to get some progress on those eventually
<zyga> jdstrand: I have enough things to work on  this week
<zyga> ijohnson: hey
<zyga> ijohnson: just use syscalls package directly
<ijohnson> hey zyga
<zyga> we use loads of syscalls that are not in the golang stack
<ijohnson> zyga: you mean like Syscall6  etc. ?
<zyga> yeah
<mup> PR snapd#8041 closed: tests, run-checks, many: fix nakedret issues (2.43) <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8041>
<ijohnson> zyga: ah ok cool
<ijohnson> zyga: thanks!
<zyga> ijohnson: just make sure about the requirements of renameat2
<zyga> kernel requirements
<ijohnson> zyga: it's from 2.6.16
<ijohnson> zyga: is that too new?
<zyga> ah, that's ancient
<zyga> I thought it's something 4+
<zyga> ijohnson: I'd love a review of the three fix PRs for the tests leaking mounted snaps
<zyga> ijohnson: one is green, the other two are still in testing
<ijohnson> zyga: yes it's in my queue, I'll try to get to them this afternoon
<zyga> super, thanks
<zyga> I'll rebase the mount leak detector on that tomorrow
<zyga> and focus on the last two red PRs
<zyga> :)
<ijohnson> zyga: one last question for you since you're around
<zyga> yeah?
<ijohnson> zyga: it appears that the syscall number for renameat2 is different on different architectures
<zyga> yes, that's normal
<ijohnson> the usual go thing is to have a sys_linux_arm64.go ,etc. and define the constant in those files
<zyga> each architecture has a separate table
<ijohnson> is there a place we do that already?
<ijohnson> I don't see anywhere we do that currently
<zyga> ijohnson: ish, not for go
<zyga> ijohnson: btw, I think you may be lucky
<zyga> last time I looked at it
<zyga> go uses renameat2 internally
<zyga> just not exposes it
<zyga> so _maybe_ there's a syscall const for SYS_RENAMEAT2
<zyga> but if there is none, yeah, you have to define those
<zyga> that sucks
<ijohnson> I just looked and it uses renameat to implement Rename
<zyga> ah
<zyga> boo
<zyga> well :/
<zyga> that's that
<ijohnson> I'll double check, but yeah boo
<zyga> start with x86
<zyga> and x86_64
<ijohnson> yeah I was just gonna do all the architectures that the core snap is available on currently, so arm64, armhf, i386, amd64, s390x, and ppcel64
<ijohnson> though I don't know if we support powerpc at all
<zyga> ijohnson: tip: seccomp knows
<ijohnson> ah yes that's a good idea
<zyga> the magic command is scmp_sys_resolver (obviously :)
<zyga> (it's a terrible name)
<ijohnson> yes I've used that a few times before
<zyga> cool
 * zyga pulled fixed fixes and restarted local tests of all of core
<zyga> o/
<mup> PR snapd#8043 opened: osutil: add Renameat2() <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8043>
<mup> PR snapd#8044 opened: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
<ijohnson> hey jdstrand, since you last touched the spread pulseaudio tests, any quick takes on what the problem might be here: https://pastebin.ubuntu.com/p/4Kqpj2CnPb/ ?
<jdstrand> ijohnson: not otoh. based on the top of the past, seems a pulseaudio is already running. perhaps something from a previous test?
<ijohnson> jdstrand: hmm could be
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8033/commits/c1621b9f3250edc9c41f5ee5acd8163d6d584614
<mup> PR #8033: tests: switch mount-ns test to differential data set <Created by zyga> <https://github.com/snapcore/snapd/pull/8033>
#snappy 2020-01-24
<zyga> ijohnson: I'll update the data tables to be correct and push
<ijohnson> zyga great but also feel free to wait until tomorrow :-)
<zyga> ijohnson: small review on renameat2 https://github.com/snapcore/snapd/pull/8044#pullrequestreview-347688118
<mup> PR #8044: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
<ijohnson> zyga: thanks for the review, tldr is that it's not a big deal if the random source is poor, as it's just being super extra super safe anyways
<zyga> ijohnson: and the renameat part?
<ijohnson> zyga: the paths are absolute so the fds are ignored
<zyga> hmm
<ijohnson> I would have used rename2 but the only way to get atomicity is to use renameat2
<ijohnson> (with the RENAME_EXCHANGE flag)
<zyga> ijohnson: I think that's okay but I would still use the special value, technically the 0 descriptor is valid and means something but the code that ensures arguments are absolute is not close to the call
 * zyga nods
<ijohnson> zyga I'll add a comment where it's used
<zyga> I think using the special value is preferred
<zyga> even with a comment
<zyga> it's more like what you wanted
<ijohnson> Okay I'll use that then
<zyga> ijohnson: double check with jdstrand but I think that's safer
<ijohnson> Okay, the man page says the FD is supposed to be ignored when it's an absolute path
<zyga> yes, that's true
<zyga> my point is not that this is incorrect
<zyga> it's just that it can be safer
<ijohnson> Sure
<mborzecki> morning
<mup> PR snapcraft#2889 closed: meta: always generate snapcraft-runner to workaround classic PATH bug <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2889>
<mborzecki> zyga: interesting forum topic https://forum.snapcraft.io/t/permission-denied-in-general-ubuntu-19-10-snap-2-42-5/15161
<mborzecki> hmm not sure anything happend on the desktop front, snaps still render with boxes instead of actual fonts: https://i.imgur.com/V3mKUt8.png
<__chip__> ð
<geodb27> People : hi ! I have 9 machines (ubuntu LTS 18.04 server) that are split into 3 lxd clusters. Yesterday, at 15:13 all nine decided to update the snap lxd package. They are all stuck at task "Copying datas from the snap lxd package".
<geodb27> So, since yesterday, the "lxc" commands provided by this snap are not available anymore, and I can't do anything. I don't want (and can't) lose all my lxd containers. What can I do to have snap lxd package up-to-date ?
<zyga> Hey
<zyga> Outside
<zyga> Back soon
<mborzecki> zyga: __chip__: hey
<mborzecki> geodb27: can you collect the output of `snap change --last=refresh` from one of the machines?
<pstolowski> morning
<mborzecki> pstolowski: hey
<geodb27> Thanks for your answer mborzecki. I'll check this right now.
<geodb27> Well, it remains the same as "snap changes" followed by "snap tasks nn" with nn the id of the change. And this leads to the step that is waiting since yesterday 15:13 as I said before.
<geodb27> I've just checked all my 9 machines. 6 are OK. But 3 (the three of one same cluster) are in the same state. Stuck at :
<geodb27> Doing  yesterday at 15:13 CET  -                       Copier les donnÃ©es du paquet Snap "lxd"
<mborzecki> geodb27: weird, iirc lxd keeps container data under the location shared by all revisions
<mborzecki> geodb27: can you check whether there any any files under /var/snap/lxd/current/ ?
<geodb27> there is no /var/snap/lxd/current. All I have is /var/snap/lxd/{12317,12631,common}
<geodb27> (On the first machine).
<mborzecki> geodb27: try /var/snap/lxd/12317/
<zyga> re
<geodb27> On the two others I have /var/snap/lxd/{12317,12631,13073,common). But the last two are stuck at "Doing  yesterday at 15:12 CET  -                       DÃ©marrer les services du paquet Snap "lxd" (13073)"
<zyga> ha
<mborzecki> geodb27: anything in there? can you run `du -sch /var/snap/lxd/12317/` ?
<zyga> I saw this
<zyga> last night
<zyga> mborzecki: lxd cannot be stopped
<zyga> it sticks around forever
<zyga> I noticed this yesterday when rebooting
<zyga> systemd eventually kills it after 10 minutes and just reboots
<mborzecki> zyga: w8, so it hits all the timeouts, systemd still doesn't stop it?
<zyga> but when I noticed the messages it was not able to unmount cleanly
<mborzecki> zyga: but sunce we moved to the next task, systemd must have reported it stopped
<zyga> mborzecki: it seems there are no timeouts for lxd
<zyga> maybe it's something special it does
<geodb27> On the first machine, the /var/snap/lxd/12317 folder is empty.
<zyga> mborzecki: for me the reproducer case was ubuntu 19.10 (now 20.04) with lxd and a container
<zyga> stopping lxd doesn't work
<mborzecki> geodb27: right, as zyga mentioend, maybe it's related to lxd not stopping
<mborzecki> geodb27: can you ps -ef|grep lxd ?
<geodb27> Indeed, it could be. Let me check.
<geodb27> root        1518       1  1 janv.10 ?      05:36:05 [lxd] <defunct>
<mborzecki> zyga: ^^
<zyga> ha
<geodb27> What now ? If I reboot, will lxd complete it's upgrade and will I get all my containers back up and running ?
<zyga> geodb27: I'd not test in production, cannot say for sure
<zyga> geodb27: I suspect that snapd will recover
<zyga> geodb27: and carry on with the update
<zyga> geodb27: but depending on how your time works I'd evaluate this separately
<geodb27> Thanks for your help zyga. Anyhow, I have backups of my machines (fortunately, the containers are hosted on a ceph cluster)... I'll give it a try and give a feedback here as the reboot completes.
<zyga> geodb27: thank you
<zyga> mborzecki: we should check this out
<mborzecki> zyga: any clue whether stgraber and his team noticed this too?
<zyga> no idea
<mborzecki> hmm `Instance name is: on-jackass`
<zyga> is there a way to wait for a change?
<zyga> from command line
<zyga> snap watch --last
<zyga> ah
<mborzecki> zyga: if you're addressing the commnents in your PR then retry-tool probably makes more sense in case the change does not complete
<zyga> ish
<zyga> I must be doing it wrong
<zyga> while snap changes | grep Doing; do sleep 1; done
<zyga> this failed just now
<zyga> with snap changes showing a change that is Doing
<zyga> wtf?
<zyga> https://www.irccloud.com/pastebin/pc7zuZZX/
<zyga> but I'm very suspect of the test itself
<zyga> it happily REBOOTS
<zyga> without any synchronization on async snapd activity
<zyga> I suspect it need to have snap watch --last=... in each stage
<zyga> as otherwise nothing is certain
<geodb27> Well... Fyi : I rebooted only one machine of the lxd cluster... It took some time (the reboot process had to kill a process related to filesystem mounted)... And... Tada : all three machines are up-to-date and running fine. Thanks for your kind help !
<geodb27> I do not have time (and it is anyhow too late) to investigate further to find out what was hanging the system. One could suspect some lock (maybe on the cephfs side or on the lxd database at some point) that was holding things stalled.
<mborzecki> we should write down the reasons for avoiding golang.org/x/sys/unix
<zyga> mborzecki: I'll grab some food and make tea
<zyga> mborzecki: I'm iterating on the wait/reboot problem
<mborzecki> zyga: heh any ideas why /etc/apparmor.d/usr.bin.snap might exist?
<mborzecki> zyga: meh, reading renameat2 implementation, not sure whether we need to sync the directory too
<zyga> mborzecki: yes
<zyga> mborzecki: I read about a case where someone had it
<zyga> mborzecki: _something_ definitely creates it
<zyga> mborzecki: not snapd
<zyga> mborzecki: I cannot recall the details of the case I remember but it was probably on the forum too, let me check
<zyga> hmm, not on the forum
<mborzecki> zyga: so this guy got both snap and usr.bin.snap in apparmor profiles in case you missed it https://forum.snapcraft.io/t/permission-denied-in-general-ubuntu-19-10-snap-2-42-5/15161
<zyga> yeah
<zyga> I read
<zyga> + snap watch --last=revert
<zyga> error: no changes of type "revert" found
<zyga> + snap changes
<zyga> 9    Done    today at 09:39 UTC  today at 09:41 UTC  Revert "core" snap
<zyga> sigh
<zyga> that's such a crappy behavior
<zyga> ah, it's called revert-snap
<zyga> oh well
<mup> PR snapcraft#2891 opened: meta: always generate snapcraft-runner to workaround classic (#2889) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2891>
<zyga> and I found a small bug
<zyga> https://www.irccloud.com/pastebin/JBOzGPsz/
<zyga> ok, one more run
<zyga> brrr
<zyga> cooold
<zyga> iteration on this is painful
<zyga> mborzecki: I wonder if that denial was from snap-store
<zyga> maybe it does something weird
<mborzecki> zyga: that diff loos like we could use a helper of sorts
<zyga> mborzecki: I changed https://github.com/snapcore/snapd/pull/8039
<mup> PR #8039: tests: remove revision leaking from ubuntu-core-refresh <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8039>
<zyga> pstolowski: ^ can you look again
<pstolowski> k
<zyga> I mainly added the snap watch --last=...
<zyga> as otherwise we just race
<zyga> I'm running a small loop of this to see if it is stable
<zyga> back with coffee
<zyga> tests going
<zyga> still good
<zyga> passed
<zyga> ok onto more branches
<zyga> guys, please don't merge any of the test fixes yet
<zyga> I'm iterating on comments and even though some are green and +2 I'll adjust them
<zyga> heh
<zyga> weird failure
<zyga> https://www.irccloud.com/pastebin/SIB7x6zG/
<zyga> snapd is not installable
<mup> PR snapd#8045 opened: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
<zyga> mborzecki: ^ I  think AtomicRename without replace/not-replace is unsafe
<zyga> as it's easy to use it to nuke stuff
<mborzecki> zyga: isn't rename the same?
<zyga> yes, but that's my point
<mup> PR snapd#8046 opened: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<zyga> it depends on how it is used obviously
<zyga> hmm
<zyga> why is kernel remodeling so slooooow
<zyga> it's 10 per test
<zyga> 10 minutes
<mborzecki> unexpected failure https://paste.ubuntu.com/p/D6n2g4MfwD/
<zyga> hmmm
<zyga> no idea,
<zyga> I am really wondering if we do things right
<zyga> we pull the rug from under snapd in teardown
<zyga> not wait for things
<__chip__> zyga: the kernel is very prima donna about its hair, so remodeling takes ages
 * __chip__ in Friday mode
<zyga> __chip__: we should ... shave a few minutes
<__chip__> zyga: rimshot
<__chip__> zyga: google 'rimshot pirates gif' for the right thing
<__chip__> mah interwebs are slow so i can only do meta-gifs
<zyga> __chip__: how's Friday?
<zyga> __chip__: I was super happy yesterday
<__chip__> zyga: what happened yesterday? (let's do it more!)
<zyga> __chip__: I fixed the three tests leaking stuff on core167
<zyga> some lessons learned as well
<zyga> __chip__: now mount-ns can run on core
<zyga> _ages_
<__chip__> is that core based on ubuntu 2167.04?
<zyga> it took years to do this
<zyga> hahaha
<zyga> star trek
<zyga> the next remodel
<zyga> these are the changes of the packaging systems
<zyga> to explore ... channels
<zyga> yada yada
<__chip__> zyga: sudo apt install xscreensaver-gl-extra, and then /usr/lib/xscreensaver/starwars -program 'cat stufftxt'
 * zyga iterates on another PR
<cmatsuoka> mborzecki: #8045 failed on a travis test with a random store error so I restarted it
<mup> PR #8045: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
<mborzecki> cmatsuoka: thanks!
<zyga> hmm
<zyga> is the store all right
<zyga> my tests are timing out on super slow traffice
<zyga> downloading core takes close to an hour
<zyga> 10KB/s
<zyga> 20-60
<zyga> brb
<zyga> re
<zyga> degville: did you find anything interesting in the content interface?
<degville> zyga: I'm still working on it - but I did get my own slot/plug snaps working with it, and I've mostly added the details you suggested/linked to.
<zyga> cool! :)
<zyga> I think the thing I've learned is that simple stuff tends to work
<zyga> but is surprising when you start being very creative
<degville> ok, sounds sensible. I'll make a note of it. Certainly, my own snaps are simple, but they were just for my own understanding.
<ijohnson> morning folks
<zyga> - Download snap "ubuntu-image" (161) from channel "edge" (received an unexpected http response code (504) when trying to download https://canonical-lcy01.cdn.snapcraft.io/download-origin/canonical-lgw01/4RW78vIax8JW5S8HkYsa8lNbv68uPaYX_161.snap?token=1579885200_4dbf2a807d9b9a8d56cb263d6e7dcc6e61a45952)
<zyga> ijohnson: hey
<ijohnson> hey
<zyga> ijohnson: store is wonky
<ijohnson> does that mean I can just go back to bed
<ijohnson> :-)
<mborzecki> it is :/
<mborzecki> error: cannot perform the following tasks:
<mborzecki> - Download snap "core" (8268) from channel "stable" (Get https://canonical-bos01.cdn.snapcraft.io/download-origin/canonical-lgw01/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_8268.snap?token=1579881600_d8a5fae185f0cf6884a96c15c566fc6876922512: EOF)
<zyga> ijohnson: or play in the snow
<zyga> yeah
<ijohnson> mborzecki: so what's the story behind this AtomicRename ?
<ijohnson> mborzecki: is my implementation flawed? I see your comment about the dir syncing
<mborzecki> ijohnson: want to talk before the standup?
<ijohnson> sure, like now?
<mborzecki> or after/or during :P doesn't matter, it's only 5 of us today
<zyga> btw, I'm next to lucy
<zyga> she's sleeping
<zyga> I may join standup and listen on very quiet level
<zyga> either I swap with my wife or it's silent standup for me :)
<mborzecki> ijohnson: zyga: let's do it
<zyga> no no
<zyga> I mean leater
<zyga> I'm working on stuff now
<zyga> go chat!
<ijohnson> mborzecki: I'll join in just a minute
<ijohnson> zyga: why use `snap watch` instead of `retry-tool` ?
<zyga> ijohnson: because snap watch does exactly what I need
<zyga> and retry tool would have to do snap changes and grep
<ijohnson> I'm still just a little worried that it will block forever
<zyga> exactly what snap watch does inside
<zyga> I wish we had a way to make retry-tool ask snapd something directly
<zyga> retry-tool snap debug settled
<zyga> or something
<zyga> I see your point, it's just lesser evil right now (out of two choices this one is more robust in being precise)
<zyga> not that the other would just grep Doing
<zyga> which doesn't catch Undoing
<zyga> and is fooled by "Done Doing stuff"
<ijohnson> zyga: ok, it's fine for now then I guess
<ijohnson> I'll approve in a little bit
<zyga> I think "snap debug settle" would be good
<zyga> I'll ask about it next week
<zyga> also the shell code after reboot-causing activity
<zyga> that scans logs
<zyga> to know when it can REBOOT
<zyga> yuck
<zyga> we should have a better way
<zyga> not calling REBOOT is not good because then spread was not anticipating it
<zyga> it would be good to have ANTICIPATE_REBOOT
<zyga> and then just do what normally happens
<zyga> but there is no channel to send that information today
<zyga> (sadly)
<ijohnson> Afk for little bit
<zyga> - Download snap "core20" (331) from channel "edge" (Get https://canonical-bos01.cdn.snapcraft.io/download-origin/canonical-lgw01/DLqre5XGLbDqg9jPtiAhRRjDuPVa5X1q_331.snap?token=1579888800_379b23e2fe4d0bd8d7152c92943200e95a92deb0: EOF)
<zyga> I think today is early EOD land
<zyga> I will do reviews
<zyga> mborzecki, ijohnson: -1 on https://github.com/snapcore/snapd/pull/8045#pullrequestreview-348005564
<mup> PR #8045: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
<pstolowski> ijohnson: i joined tgif the second you left
<ijohnson> pstolowski: sorry be there in a minute
<ijohnson> irl thing
<pstolowski> no worries
<zyga> ijohnson: what does zsys stand for?
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8043#pullrequestreview-348015574 + but please check my comment
<mup> PR #8043: osutil: add Renameat2() <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8043>
<ijohnson> zyga: zsys is just what the go sources use for those definitions
<ijohnson> i.e. https://github.com/golang/sys/blob/1a3b71a79e4aff00d87e69e0744746d7d67a3f8f/unix/zsysnum_linux_arm.go
<ijohnson> zyga: what do you think about my implementation vs mborzecki ?
<ijohnson> zyga: mborzecki: I think I will push to 8045 a change to do try creating the symlink in a loop and then refactor my grub PR to use mborzecki's implementation and drop the osutil.Renameat2. we can always refactor to use that later if we find os.Rename it's not safe enough
<zyga> ijohnson: I think the looping should be in maciek's pr but otherwise I agree
<zyga> ijohnson: ah
<zyga> ok
<zyga> (about zsys)
<zyga> - Download snap "core18" (1668) from channel "edge" (received an unexpected http response code (404) when trying to download https://canonical-lcy01.cdn.snapcraft.io/download-origin/canonical-lgw01/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_1668.snap?token=1579892400_a96a7203408107730307613e718e90209628f548)
<zyga> store is so down
<ijohnson> zyga: okay sounds good
<roadmr> zyga: wait 404?
<roadmr> zyga: is that reproducible?
<mborzecki> ijohnson: pushing in a bit
<roadmr> it should NOT 404 (no found) on you - I might expect a 50x but not a 404
<ijohnson> mborzecki: ah okay if you're already doing that I'll wait for you
<roadmr> zyga: wfm fwiw
<mborzecki> ijohnson: zyga: pushed
<mborzecki> time to wrap it up
<mup> PR snapd#8043 closed: osutil: add Renameat2() <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8043>
<zyga> re
<ijohnson> zyga: are your leaky mount ns PR fixes all ready? if so I can merge them this PM after I review them
<ijohnson> trying to finish UC20 things this morning
<sdhd-sascha> hi, sorry to mention you. I already ask at #openstack and #ubuntu-kernel.
<sdhd-sascha> Should a bond which is member of a bridge has a mac-address ? And if so, should it be the same mac ? (netplan use automatically the same mac)
<ijohnson> sdhd-sascha: I don't know the answer myself, but there's also the #netplan channel
<sdhd-sascha> ijohnson: thank you :-) meanwhile i found #lxc-dev, too.
<ijohnson> sdhd-sascha: glad to help
<zyga> ijohnson: no, not ready
<zyga> ijohnson: close but not yet, I'm wrapping up another branch and will return to get through feedback and do tests
<ijohnson> zyga: ack, np
<zyga> ijohnson: but I'm still up here
<zyga> so I'll try to merge them if possible by EOD
<ijohnson> zyga: sure np
<sdhd-sascha> Is it possible to approve this classic-snap : https://build.snapcraft.io/user/sd-hd/termite-snap . (I already asked in the forum for a `classicmode` track )
<zyga> sdhd-sascha: does it have required votes?
<sdhd-sascha> zyga: just talk today, per email, with someone who has requested support from me.
<sdhd-sascha> What are required votes ?
<zyga> sdhd-sascha: it must go through the review process
<zyga> sdhd-sascha: and get enough votes
<sdhd-sascha> I published it as strict before, with ssh and byobu. But didn't had the time to test and use it in production.
<sdhd-sascha> zyga: Ok, understood. No problem. I told the reviewer, that he could build the snap himself. (He knows how to strace it ;-) )
<sdhd-sascha> zyga: is this enough: ? https://forum.snapcraft.io/t/termite-classicmode-track/15169
<zyga> no
<zyga> please look at the process requirements
<zyga> it's documented on the forum
<zyga> you must justify it
<zyga> there are requirements and it's not always granted
<zyga> it also takes some time so don't expect instant replies
<sdhd-sascha> zyga: hmm
<sdhd-sascha> zyga: https://forum.snapcraft.io/t/termite-classicmode-track/15169/2
<zyga> sdhd-sascha: I'm sorry it's too late for me to focus on that
<zyga> I'm trying to wrap up some fixes and spend some time away from work
<sdhd-sascha> zyga: no problem - i just try to look at github actions... maybe i can create it there, for now
<zyga> sdhd-sascha: someone recently tweeted about using github actions for snaps
<zyga> but I'm off now, need to take the dog out
<sdhd-sascha> i know... christmas presend ;-) i remember ;-)
<sdhd-sascha> no problem ;-)
<sdhd-sascha> Hey folks - did you ever had a remote tree-tag on github. But no branch. How can i fetch this ?
<sdhd-sascha> /me i know, i wish too, i had had people in the past to ask ;-)
<zyga> ijohnson: updated differential PR
<zyga> switching to the fixes
<ijohnson> zyga: ack thanks
 * zyga checks on tests
<sdhd-sascha> markstos: welcome :-)
<sdhd-sascha> markstos: well, termite on sway launched on my system
<sdhd-sascha> Yes, it runs on strict ... But you didn't have access on outher applications. Except you use some remote login, to another system
<sdhd-sascha> markstos: the most folks, here are gone, and be on gmt+3 back ;-)
<sdhd-sascha> or, so
<sdhd-sascha> But, if i say something wrong, than they can criticism me
<sdhd-sascha> If i understand you, then, you would like to have some terminal which is strict protected with apparmor and seccomp. But its usable ?
<markstos> Ah, so it's good for SSH, but not for accessing the filesystem. That's a lot less useful.
<markstos>  I'm not surprised Sway works, since Sway uses Wayland and Wayland seems to work as the default for Termite.
<sdhd-sascha> :-)
<sdhd-sascha> No, no -- the most guys said to me, that `classic mode` with full filesystem (not only home) makes more sense
<markstos> My primary interest was simply to have a package that I could install on Ubuntu.
<sdhd-sascha> I read, in your mail signature, that you have a security company - or you are freelance ?
<sdhd-sascha> hmm - ... maybe it was the easiest, if i create a `ppa` for you ? and termite plus libvte-ng
<sdhd-sascha> then there is no snap needed ?
<sdhd-sascha> Firstly, i thought you would like to have a snap.
<sdhd-sascha> markstos: What OS are you use ?
<markstos> I'm using Ubuntu 18.04, but plan to soon convert a new persona laptop laptop to Ubuntu 20.04 alpha. I'll run containers to support 18.04 apps until  20.04 is released.
<sdhd-sascha> Oh, you just said them. I'm sorry
 * sdhd-sascha just remember
 * sdhd-sascha also have to try to use slack.... (thanks for the tip)
<markstos> Yes, a PPA would also be welcome. As much as possible I'm trying to automate my environment with Ansible, so whichever format it is, I'll automate installing and next time upgrades will just about as easy either way.
<sdhd-sascha> hey, markstos - my wife is come back. And yes, i can create a ppa the next days ;-)
<sdhd-sascha> But mention, that libvte-ng and libvte can be different version. (i try to do my best to resolve this ;-) )
<sdhd-sascha> see us - tomorrow ;-)
<markstos> Thanks!
<sdhd-sascha> markstos: of course, i'm glad to help (sometimes, i didn't have the time, for an one-person ... ;-) )
<mup> PR snapcraft#2892 opened: Add snapcraft plugin for Qt Build Suite (qbs) <Created by bjorn> <https://github.com/snapcore/snapcraft/pull/2892>
 * zyga alters a test and spawns another run
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8038 updated
<mup> PR #8038: tests: fix gadget-update-pc test leaking snaps <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8038>
<zyga> 4 is enough
 * zyga notices LXD test is broken
<zyga> eh
<zyga> I guess that's not a good way to end the week
<zyga> something to fight on Monday
<zyga> ttyl
 * zyga eods
<ijohnson> Have a good weekend zyga!
<zyga> thank you, you too
<zyga> (lxd is not broken, installing snapd in lxd doesn't pass through dpkg, some deps are wrong, perhaps the test starts to suffer from the build-on-A-and-install-on-B problem)
 * zyga goes to watch Picard pilot
#snappy 2020-01-25
<sdhd-sascha> ok, copy & paste of snap building was fine: https://github.com/sd-hd/termite-snap/runs/407725965?check_suite_focus=true
<sdhd-sascha> hmm, thanks
<zyga> uh 18C in the office
 * zyga debugs lxd issue
<zyga> and now it obviously doesn't fail
<zyga> WTF
<zyga> waaat
<zyga> stgraber: hey
<zyga> stgraber: not sure if you are traveling now
<zyga> stgraber: on an amd64 system, "lxc launch ubuntu:xenial" launches ... i386 container
<zyga> er "lxc launch ubuntu:18.04"
<ogra> doesnt here
<zyga> ogra: it does here once in a few runs
<zyga> ogra: it's super weird
<zyga> it started yesterday
<zyga> https://www.irccloud.com/pastebin/FmxUFgc1/
<ogra> very strange
<zyga> is there a way to pick the architecture explicitly
<ogra> must be new indeed
<zyga> lxc
<stgraber> zyga: I'm still in Cape Town
<zyga> stgraber: aha
<zyga> stgraber: was there a release of lxd into candidate lately?
<zyga> stgraber: we're pulling candidate in all our tests
<stgraber> zyga: I know what change could have caused this, but it's not happening on my system here using master so it's unlikely to be something that hits every time
<zyga> stgraber: it's random
<zyga> hits every few times
<zyga> maybe dictionary ordering
<zyga> or something like that
<stgraber> zyga: what does `lxc image info ubuntu:xenial` get you?
<stgraber> the logic specifically sorts by arch, starting by primary before going to secondary, so shouldn't be random
<zyga> checking
<zyga> https://www.irccloud.com/pastebin/RRCUeVqC/
<zyga> architecture looks correct here
<stgraber> zyga: hit it here just now
<stgraber> well, on a remote server, CPT internet is too slow to do a test loop :)
<zyga> :)
<zyga> yeah
<zyga> stgraber: if there's a chance to tweak it and patch candidate we'd love that
<stgraber> root@buildd01:~# for i in $(seq 20); do lxc image info ubuntu:xenial | grep Architecture; done | sort | uniq -c
<zyga> stgraber: otherwise please give me a signal and I'll mask LXD tests for now
<stgraber>       5 Architecture: i686
<stgraber>      15 Architecture: x86_64
<mup> PR snapd#8047 opened: tests: detect LXD launching i386 containers <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
<stgraber> zyga: yes, it's a fix we had to rollout to fix all foreign arch (say armhf on arm64) that was broken, so we'll fix the fix and push it through quickly
<zyga> haha, thank you :)
<stgraber> zyga: we obviously don't want folks to accidentally run their foreign arch instead of native :)
<zyga> I hope I didn't ruin your weekend
<ogra> just call it an easter egg !
<stgraber> testing a fix now
<stgraber> zyga: nah, I'm at the company meetings this weekend
<stgraber> zyga: I think my fix is working, just finishing a test loop
<stgraber> yep, ran 1000 times and all x86_64
<stgraber> sending upstream
<stgraber> zyga: https://github.com/lxc/lxd/pull/6773
<mup> PR lxc/lxd#6773: shared/simplestreams: Fix inconsistent sorting <Created by stgraber> <https://github.com/lxc/lxd/pull/6773>
<zyga> stgraber: super, looking
<stgraber> zyga: it's in candidate now
<zyga> stgraber: yep, I just checked
<zyga> re-starting our tests
<zyga> thank you!
<stgraber> Will promote to stable after dinner once Jenkins is happy
<zyga> stgraber: hmmm, I just reproduced it again... from candidate
<zyga> ah, no sorry
<zyga> hmm
<zyga> actually
<zyga> yeah
<zyga> https://www.irccloud.com/pastebin/D0mfZLII/
<zyga> This was two hours ago
<stgraber> Right so on the old rev still
<stgraber> I ran a for loop trying it 1000 times so pretty sure this code path isn't racy anymore
<zyga> ok
<zyga> re-started
<zyga> stgraber: did you publish to candidate?
<zyga> it failed again at 18:57 CET
<zyga> stgraber: so either I'm running unfixed revision or it is still broken
<zyga> lxd (candidate) 3.19 from Canonical* installed
<stgraber> Do you know the revision?
<zyga> stgraber: no, the test doesn't show it
<zyga> I'll change it to do so
<zyga> stgraber: https://github.com/snapcore/snapd/pull/8047 will show it soon
<mup> PR #8047: tests: detect LXD launching i386 containers <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
<zyga> stgraber: installed revision 13113
<zyga> stgraber: version 3.19 from latest/candidate
<stgraber> zyga: 13113 isn't an amd64 revision
<zyga> stgraber: note that latest/edge is 13119
<stgraber> zyga: 13115 is the amd64 one
<zyga> doh!
<zyga> indeed
<stgraber> so yeah, if testing on 32bit, you'll get i386
<zyga> we still run -32 version
<stgraber> if you weren't, that'd be a bug :)
<zyga> corrected my checks, let's see
<mup> PR snapcraft#2893 opened: [legacy] meta: include environment in hook wrappers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2893>
<mup> PR snapcraft#2894 opened: Fix issue with multipass mount on win32 <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2894>
<zyga> stgraber: all good
#snappy 2020-01-26
<mup> PR snapcraft#2891 closed: meta: always generate snapcraft-runner to workaround classic (#2889) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2891>
<mup> PR snapd#8048 opened: tests: disable system-usernames test on core20 <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8048>
<mup> PR snapd#8048 closed: tests: disable system-usernames test on core20 <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8048>
<mup> PR snapd#8042 closed: tests: remove revision leaking from remodel-kernel <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8042>
<mup> PR snapd#8038 closed: tests: fix gadget-update-pc test leaking snaps <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8038>
<mup> PR snapd#8039 closed: tests: remove revision leaking from ubuntu-core-refresh <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8039>
<mup> PR snapd#8049 opened: tests: fix revisions leaking from snapd-refresh test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8049>
