#snappy 2016-02-08
<zlowred> hi there, I'm having troubles using 1-wire on Raspberry Pi 2 using latest Ubuntu Snappy Core, I did 'modprobe w1-gpio' which looks ok and adds w1 into /sys/bus, but /sys/bus/w1/devices is empty. Same hw works well under Raspbian. Are there any manuals/hints on getting it running? thanks
<Tenacious-Techhu> Good luck, zlowred; every time I ask a question here, I get nothing. :P
<zlowred> didn't want to dive  into kernel sources... but afraid choices are only that or switching back to raspbian
<Tenacious-Techhu> zlowred, you know anything about how secure by default Snappy is?
<zlowred> not really worried about this as my device is supposed to run on local network
<Tenacious-Techhu> That's the question I've been asking... I'm the one that cares. XD
<pitti> elopio: sure, call it with --copy to copy a file into the testbed, or pass it via --setup-commands
<pitti> elopio: you can't do that on the production infrastructure of course
<pitti> but locally is fine
<Tenacious-Techhu> pitti, how secure by default is Snappy, and in what ways isn't it secure by default?
<pitti> Tenacious-Techhu: I'm not working on snappy, sorry; but this is a very fuzzy question, you need to get more specific
<pitti> (I. e. I can't answer details about snappy)
<Tenacious-Techhu> It's not a fuzzy question. "Secure by default" is a practice in which the attack surface of a system is completely minimized at the time of initial install and startup, until the "system administrator" changes it in order to enable features.
<fgimenez> good morning
<Tenacious-Techhu> Hello!
<Tenacious-Techhu> How secure by default is Snappy?
<anpok> Tenacious-Techhu: hm i guess this question is best aked on the mailing list.. But snappy by default is very minimal.. and it requires you to enable access for applications via app armor
<Tenacious-Techhu> Being secure by default isn't necessarily about minimality; that's more about how insecure things are after they've been turned on. But thanks for the info.
<anpok> i.e. installing common linux software is all about making sure it does not touch anything on the file system and figuring out what profile might be suitable for the applicatiohn
<anpok> -h
<anpok> you dont turn on things globally.. you do that per application..
<Tenacious-Techhu> Right; but if I were to install everything, would those things start off turned off or not?
<Tenacious-Techhu> They should be disabled even though they've been installed.
<anpok> take a lot at the security wiki page .. hmm here:
<anpok> https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
<anpok> some the yaml settings have been renamed already
<anpok> if you install a snap its package yaml is scanned for requires security profiles, those are then used to confine the application.. and yes if the snap contains a service that one will be started.
<anpok> *required..
<anpok> note i am not one of the devs, just someone that tries to use it.
<Tenacious-Techhu> More answers than I was getting anpok. XD
<dholbach> good morning
<Tenacious-Techhu> Good morning!
<Tenacious-Techhu> dholbach, how secure by default is Snappy?
<noizer> good morning :D
<dholbach> Tenacious-Techhu: https://github.com/ubuntu-core/snappy/blob/master/docs/security.md should give you a good idea
<Tenacious-Techhu> So... it's not.
<dholbach> ?
<Tenacious-Techhu> "If unspecified, default confinement allows the snap to run as a network client."
<Tenacious-Techhu> It's not.
<dholbach> ...
<Tenacious-Techhu> dholbach, do you disagree with my assessment?
<seb128> kyrofa, hey, could you comment on bug #1542451? is that scope deprecated or is it going to be fixed/updated?
<ubottu> bug 1542451 in unity-scope-snappy (Ubuntu) "RM: unity-scope-snappy" [Critical,Triaged] https://launchpad.net/bugs/1542451
<seb128> willcooke, ^ just fyi, since our team was assigned to reply on it
<willcooke> thanks seb128
 * willcooke subscribes 
<seb128> yw
<seb128> willcooke, you should get emails through desktop team assignement
<willcooke> hrm
 * willcooke searches
<willcooke> in spam
<willcooke> od
<willcooke> d
<Tenacious-Techhu> Anyone else have anything to say about whether Snappy is secure by default?
<JamesTait> Good morning all!  Happy Monday, and happy Chinese New Year! ð
<Tenacious-Techhu> dholbach, do you disagree with my assessment?
<noizer> Hi, I got a short question can i start other snaps from my snap?
<Tenacious-Techhu> noizer, good luck getting your question asked.
<beuno> noizer, hi. No, you can't
<beuno> it breaks confinement, essentially
<Tenacious-Techhu> beuno, is Snappy secure by default?
<beuno> Tenacious-Techhu, I think that's been answered already
<Tenacious-Techhu> No, it hasn't; they just pointed at documents. But if you would be so kind as to elaborate, that would be very helpful.
<noizer> beuno hmm will there be something to start an other app later?
<beuno> it seems like you are fishing for something, I'd prefer you to ask specific questions
<Tenacious-Techhu> I am looking for a linux distribution that is secure by default.
<beuno> Tenacious-Techhu, maybe you need to expand on what secure to you means?
<Tenacious-Techhu> "Secure by default" means that all installed software starts with defaults that prevent it from being insecure.
<beuno> noizer, it's not currently on our radar, given it breaks out of confinement. Can you expand a bit on what you're trying to acheive?
<Tenacious-Techhu> It is my impression that, allowing software to be a network client by default goes against that security paradigm. Is that consistent with your perspective on the issue?
<beuno> Tenacious-Techhu, I read through your previous comments on apps that can access the network makes them insecure
<Tenacious-Techhu> So your conclusion would be that it isn't?
<noizer> beuno We are making a product where people can make snaps for it. This product needs able to start applications just like the webdm or something
<beuno> Tenacious-Techhu, we don't plan on locking down Snappy by default to that extent, Internet of Things without the Internet part is just "things"  :)
<Bughunter> Any one experience the same situation with two ubuntu-core packages installed.
<Bughunter> The default username and password are ubuntu.
<Bughunter> snappy list -v Name        Date       Version   Developer   ubuntu-core 2016-01-28 7         ubuntu*     ubuntu-core 2016-01-28 7         ubuntu
<beuno> noizer, ah, I see. So, we will have special permissions you can request in order to use the same APIs webdm uses
<Tenacious-Techhu> Well yes, but you also don't want your unwatched "thing" to start running software the user didn't explicitly approve.\
<Tenacious-Techhu> Malware installed on an IoT device shouldn't be allowed network access by default.
<beuno> Tenacious-Techhu, we do capture that a device uses the network, and there are scenarios where you might be able to lock it down further and/or inspect what snaps have requested network access
<Tenacious-Techhu> That would only allow dealing with the problem after-the-fact.
<noizer> beuno where can i find the webdm api?
<Tenacious-Techhu> A piece of software should have to explicitly specify if it wants network access, and be granted that approval.
<beuno> noizer, it's WIP, but, here it is: https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md
<beuno> Tenacious-Techhu, we might be able to provide a bit further down the line an option to set stricter policies
<beuno> but it is unlikely going to be the default
<noizer> can webdm starts an application?
<noizer> beuno
<beuno> noizer, I think it either can now or it will in the near future
<beuno> the command line and webdm are both moving to the internal rest api
<Tenacious-Techhu> beuno, that does little good when a device is already out in the field, waiting to be preyed upon.
<Tenacious-Techhu> Better to handle it now.
<Bughunter> Issue: after update of ubuntu-core package with command "sudo snappy update ubuntu-core" we end up with two simular versions of ubuntu-core.
<noizer> thanks for the help beuno :D
<beuno> Bughunter, sorry, I don't understand the issue
<beuno> what's going on?
<ogra_> Tenacious-Techhu, if you are concerned about that, there is a ufw snap that allows you to firewall the whole device by default and thus have full control over network accesses
<Bughunter> Strange things is, why update with simular version. And why is it impossible to remove the duplicate package?
<beuno> Tenacious-Techhu, end users don't understand security and will just approve everything. Additionally, most devices that will ship will require them to have internet access *and* won't have a UI for the user
<Tenacious-Techhu> ogra, that would only be an improvement if that firewall were installed by default on all versions of Snappy.
<ogra_> no, it wouldnt
<Tenacious-Techhu> Additionally, it would still be insufficient for meeting the criteria of "secure by default".
<beuno> Tenacious-Techhu, so, if you want to ship a device that is further locked down, you can with Snappy
<ogra_> it would mean the everyone who uses a device behind a firewall already would have to set it up
<beuno> we aren't planning on shipping devices locked down that much
<Tenacious-Techhu> Yes, and that is my objection.
<Tenacious-Techhu> Don't.
<beuno> Bughunter, sorry, I don't understand the problem. Why update with similar versions?
<beuno> Tenacious-Techhu, ok, noted
<ogra_> but you are free to create your own gadget snap that pulls in ufw in your default install
<Tenacious-Techhu> Devices should ship as secure by default, period. Otherwise, they're just going to be exploited under the watch of people who don't know any better.
 * ogra_ would say thats up to the device manufacturer
<Bughunter> Now, wy does snappy update ubuntu-core at al with the same version. Seems version checking is bugged?
<beuno> Tenacious-Techhu, that's one way to look at it if you're not actually shipping devices to users, yes
<Tenacious-Techhu> And as such, Snappy should start out that way, so that developers are starting from a state as correct as possible.
<beuno> Tenacious-Techhu, we disagree
<Bughunter> i just perfomed this command: snappy update ubuntu-core.
<Tenacious-Techhu> Yes, I know.
<Tenacious-Techhu> I encourage you to take the security of IoT devices more seriously.
<beuno> Bughunter, is this 15.04 or 16.04/rolling?
<ogra_> *developers* shoudl start as easy as possible .... *manufacturers* should start as safe as possible with pre-defined services
<beuno> Tenacious-Techhu, I think you're misguided. I understand why locking down the network makes it more secure, however, it also makes it useless to users
<beuno> as a default
<ogra_> you can go and buy a dell ip gateway with snappy preinstalled ... you will find that this is differently secured than our developer images
<Bughunter> I would expect snappy to update only when there is a later version of the ubuntu-core package. Instead it downloads and install the same packages. Thats odd.
<Tenacious-Techhu> It is up to the developers to unlock it, and up to third party software to request that network access be unlocked.
<Tenacious-Techhu> If network access is allowed to any third party software that doesn't specify a specific request, it's going to be a nightmare.
<Bughunter> Think ill search the  snappy-devel@lists.ubuntu.com list for answers. Sheers.
<Tenacious-Techhu> You'll get a bunch of trojans that call home and such.
<ogra_> and what do they tell "home" ?
<ogra_> an app cant really see anything outside of its own box
<Tenacious-Techhu> Whatever that software was written to. :P
<ogra_> apart from thinks like CPU architecture and some minor info+
<ogra_> *things
<ogra_> apps cant access the OS
<Tenacious-Techhu> Well no, but the minute one of those pieces of software uses an exploit on an embedded system to gain more access, they can tell them who knows what.
<Tenacious-Techhu> You're leaving open an unnecessary security hole that will be a problem later when an exploit for that embedded system is discovered.
<ogra_> apps cant exploit the system either ... they are checked what they du when uploaded to the store
<Tenacious-Techhu> And it may go unpatched while the device sits wherever the naive users put it.
<ogra_> *do
<Tenacious-Techhu> Who says the thing was installed from the store?
<ogra_> well, then you are on your own
<Tenacious-Techhu> From what I could tell, what I read said anything that was installed had network privileges by default.
<ogra_> you would have to scp and manually snappy install though
<Tenacious-Techhu> Installed from the store or not.
<ogra_> via ssh
<ogra_> for which you have the key
<Tenacious-Techhu> The point is, it's an unlocked door.
<ogra_> so that an administrator mistake
<ogra_> not snappys fault
<Tenacious-Techhu> The end user will NEVER be an administrator!
<Tenacious-Techhu> That's the point!
<ogra_> its an unlocked door if you gave some evil guy your ssh key, yes
<Tenacious-Techhu> Lock ALL the doors, and make the devs decide which doors to open, and which not to open.
<Chipaca> Tenacious-Techhu, i don't understand
<Chipaca> Tenacious-Techhu, what's the point you're trying to make
<Chipaca> ?
<Tenacious-Techhu> That way, everyone knows whose responsibility it is when malware gets on the device.
<ogra_> well, you know who has the ssh key ... so you know who leaked it
<Tenacious-Techhu> That's not what I'm saying.
<Chipaca> ogra_, if ssh is running the device was in developer mode :-)
<Tenacious-Techhu> Allowing software network privileges by default is an unlocked door.
<ogra_> (and to be honest, i wouldnt expect ssh to be enabled on enduser devices .... but again, thats up to the vendor)
<ogra_> Tenacious-Techhu, to do exactly what ?
<Tenacious-Techhu> A door that should have never been left unlocked to begin with.
<Tenacious-Techhu> Every door that's left unlocked is security that could have prevented disaster.
<ogra_> Tenacious-Techhu, yozur app runs under confinement, it cant see anything outside of its own system space
<anpok> Tenacious-Techhu: I believe they are talking about network-client
<ogra_> all it could do would be to exploit its own data
<Tenacious-Techhu> You guys need to stop assuming that the rest of the security is going to work.
<Tenacious-Techhu> Lock ALL the doors.
<anpok> which is not unlocked network..
<Tenacious-Techhu> Assume each one is the thing that is going to keep the bad guys out.
<Tenacious-Techhu> Yes.
<Tenacious-Techhu> The software should have to request network access, and the system should be able to deny it.
<Chipaca> Tenacious-Techhu, request to whom?
<Chipaca> Tenacious-Techhu, and which system?
<Tenacious-Techhu> To the system that is currently allowing that by default. :P
<Chipaca> Tenacious-Techhu, can you describe exactly how you think things work now, and how you think they should work?
<Tenacious-Techhu> https://github.com/ubuntu-core/snappy/blob/master/docs/security.md
<Tenacious-Techhu> If unspecified, default confinement allows the snap to run as a network client.
<Tenacious-Techhu> Bad. Very bad.
<Tenacious-Techhu> Default should allow absolutely nothing at all.
<Chipaca> i'm five seconds away from assuming you're trolling
<beuno> so, by default, the device isn't useful for anything?
<Tenacious-Techhu> Not until the developers building software for that device specifically unlock it, yes.
<Chipaca> beuno, either that, or they think we should manually review every app that requests network-client
<beuno> right
<Tenacious-Techhu> Everything should be locked until a developer unlocks it.
<Tenacious-Techhu> Accountability should be squarely placed on the developer's shoulders.
<beuno> Tenacious-Techhu, I think your argument is technically sound, not particulary novel, but sound. It just isn't practical when you actually think about users
<Tenacious-Techhu> Third party software that makes it onto the device however it may should be able to be soundly rejected, if required.
<Tenacious-Techhu> When I think about users, I think about some teenage girl whose boyfriend slipped a webcam snooper onto her outdated router.
<Tenacious-Techhu> Unless a piece of software has been whitelisted, or someone has entered an administrator password to allow that software, it should be denied.
<Tenacious-Techhu> Just because it's found on the device, that doesn't mean it's legitimate software.
<Tenacious-Techhu> And so it shouldn't be granted network access.
<beuno> snappy devices won't be outdate, they auto-update
<Tenacious-Techhu> Don't assume where they will be installed.
<beuno> if you want to lock down the device further and know how to administrate a device, you can
<Tenacious-Techhu> If it is on some local network, and not on the internet, it won't update.
<Tenacious-Techhu> But it can still do damage there.
<Tenacious-Techhu> This is not about what I want to do.
<Tenacious-Techhu> This is about what any IoT OS should do by default.
<Tenacious-Techhu> To keep the users safe, the onus for unlocking access should be on the software developers.
<Chipaca> Tenacious-Techhu, by default, you won't be able to install software that doesn't have a chain of certs behind it
<Chipaca> of assertions
<Tenacious-Techhu> Maybe not, but once it's on the device, how it got there doesn't matter anymore, does it?
<Chipaca> enabling that software to be on that particular device, and asserting it has been made by who it says it's been made, and etc
<Chipaca> Tenacious-Techhu, the snap won't work unless it has the assertions
<Tenacious-Techhu> You don't get to justify leaving one door unlocked just because the others are.
<Tenacious-Techhu> You have to lock all of them, because you don't know which one is going to keep the system safe.
<Chipaca> you don't get to tell me what i have to do
<Chipaca> especially when i try to explain why what you think is a problem isn't, and when i've tried to explain that what you think is a solution isn't
<Chipaca> and have ignored or dismissed those points
<Tenacious-Techhu> Oh? So if your neighbor left your front door open, you wouldn't want me to tell him to shut it?
<Tenacious-Techhu> I am not dismissing your points out of hand.
<anpok> Tenacious-Techhu: no better analogon would be.. the keys for your house are all opening the door of your house without coming with an extra letter telling you that the keys of your house unlock your doors
<Tenacious-Techhu> I am dismissing them because they are insufficient.
<Chipaca> Tenacious-Techhu, you're saying the neighbour should have to write "i can open the front door" before they can open the front door
<Chipaca> Tenacious-Techhu, that's all you're saying
<Tenacious-Techhu> No, you misunderstand, anpok.
<Chipaca> that an app dev needs to explicitly write "i can use the network" before they can use the network
<Chipaca> and that that will somehow stop malware
<Tenacious-Techhu> It is not what the app dev writes...
<Tenacious-Techhu> It is what the system decides when receiving that request that matters.
<Tenacious-Techhu> Rather than granting that access by default, it has the chance to reject it.
<Chipaca> Tenacious-Techhu, so three options: either always grant that request, always reject it, or always have somebody manually audit it
<Tenacious-Techhu> And right now, you are auditing those requests, except by default.
<Chipaca> Tenacious-Techhu, which of those do you think is sane?
<Tenacious-Techhu> I'm just saying audit that one too.
<Chipaca> Tenacious-Techhu, we are not auditing all requests, only those that we consider have real security implications
<Tenacious-Techhu> Yes, but internet access DOES have real security implications.
<Chipaca> Tenacious-Techhu, explain
<Chipaca> Tenacious-Techhu, give me an example, even if it's contrived, in which *just* being a network client has security implications for a sandboxed app
<Tenacious-Techhu> Someone could find an exploit on the poorly maintained, widely deployed IoT device, write a piece of trojan malware for it, get a bunch of naive idiots to install it, and then when the server it dials home to says "go", it explodes.
<Tenacious-Techhu> Whereas, if it had to request internet access to begin with, it could be rejected, and thus, never could be installed in the first place.
<Chipaca> Tenacious-Techhu, how could it be rejected?
<Tenacious-Techhu> The request for internet access would be denied by the existing mechanisms that deny other things in non-default circumstances.
<Tenacious-Techhu> My recommendation is to assign network access, even as a client, to a specific request, and not a default one. That way, it can be denied, just as any other specific request can be.
<beuno> Tenacious-Techhu, as I said an hour ago, noted
<Tenacious-Techhu> Well, fair enough then.
<Tenacious-Techhu> Go to a Homeland Security conference some time.
<didrocks> ogra_: argh, no loadkeys in 15.04 Core image! Do you know off hand how to switch to my sweet french kbd layout? :)
<ogra_> didrocks, i dont, actually :)
<ogra_> even if loadkeys was there we wouldnt have the keymaps
<didrocks> ogra_: do you know who would have any idea on this? :p
 * ogra_ tends to always use ssh so i dont run into this ;)
<beuno> ogra_, where does uboot go in the 16.04 images?
<ogra_> didrocks, i guess they shoudl be part of some UI  snap in the end ...
<didrocks> ogra_: yeah
<ogra_> beuno, on disk ? in what snap ? you have to be more precise ;)
<beuno> ogra_, heh, yeah, in what snap
<ogra_> gadget
<ogra_> (talking about all-snaps here ... system-image builds still use the 15.04 setup)
<beuno> ogra_, and that's the plan going forward, right?
<beuno> yeah, all-snaps
<ogra_> right
<beuno> thanks ogra_
<noizer> ogra_ Hello, I'm trying to use UWSGI in a snap but i got following error: error removing unix socket, unlink(): Read-only file system [core/socket.c line 198]
<noizer> but this is some permission issue. If you have any idea how I can solve that
<Chipaca> noizer, what's in the audit logs?
<noizer> where can i find the audit logs Chipaca?
<Chipaca> noizer, sudo journalctl | grep audit
<ogra_> yeah, looks like the socket is created in some dir outside of your box
<Chipaca> noizer, there's probably a better way, but that one works :-)
 * ogra_ prefers syslog :)
<noizer> oooh ok ogra_ first i will try to change the path of my sock maybe that will hep
<noizer> Chipaca then i will share my log
<ogra_> noizer, use $TMPDIR ;)
<noizer> in the ini of the socket?
<noizer> (ini of uwsgi)
<ogra_> if that respects the environment vars, yes
<Chipaca> otherwise /tmp/something should work
<ogra_> yeah
<Chipaca> /tmp/foo.sock
<Chipaca> noizer, it's a private tmp, fwiw
<ogra_> what a luck Tenacious-Techhu is gone now
 * ogra_ bets that would be the next discussion ;)
<noizer> hahah xD
<noizer> Chipaca and ogra_ thx this error is fix. I think so xD. now the next error
<zyga> jdstrand: hey
<zyga> jdstrand: around?
<noizer> Chipaca ogra_ do you now something about this error? lock engine: pthread robust mutexes
<noizer> oooh sorry thats the issue Bad system call
<ogra_> might be seccoomp related
<noizer> secoomp??
<ogra_> right, check with ubuntu debug
<ogra_> *seccomp
<ogra_> err
<ogra_> snappy-debug, sorry
<zyga> robust mutex are used internally to implement parts of the stdlib
<zyga> they should be allowed by seccomp
<zyga> (perhaps they are not)
<ogra_> right
<ogra_> thats why i asked to check it :)
<zyga> hey ogra_ :)
<ogra_> yo
<zyga> busy week ahead
<ogra_> two of them :)
<zyga> that's quite true
<noizer> ogra_ what do you mean with ubuntu debug
<ogra_> snappy-debug was what i meant
<ogra_> it ships a tool to check the logs for seccomp denials
<noizer> ok and how can i test that because im nog familiar with it
<ogra_> (i forgot the new name, it used to be called sc-logresolve in 15.04)
<noizer> ogra_ I'm using 16 (xenial)
<ogra_> install the snappy-debug snap and run sc-logresolve ... IIRC it tells you the new name
<ogra_> then run whateve it tells you
<noizer> ok i will check it out
<noizer> snappy-debug failed to install: can not open /tmp/snappy-debug230025468: cannot open snap: unknown header: "!<arch>\ndebian-binar"
<noizer> tried to install it dammed
<noizer> is that a bug?
<ogra_> jdstrand, ^^^ hasnt that been updated to the 16.04 format yet ?
<ogra_> noizer, try snappy install snappy-debug/edge
<ogra_> if that gets you the same error it hasnt been updated yet (and thats a bug, yes)
<noizer> hmmm same error
<ogra_> yeah, thats a bug then
<noizer> ogra_ should I file it or??
<ogra_> yeah, i'm unsure against what exactly though ... file it against the snappy project itself for now
<noizer> this project ? https://bugs.launchpad.net/ubuntu/+source/snappy
<ogra_> nop, see the channel topic
<ogra_> ("/ubuntu/+source/snappy" would be the snappy package in ubuntu ... not the project)
<noizer> ok sorry xD my mistake
<noizer> now I will file it now. But how can we debug it then?
<ogra_> i guess you have to ask tyhicks or jdstrand ... i dont know how you can get seccomp messages without the tool
<ogra_> (or even if you can)
<noizer> ogra_ ok i will ask them
<noizer> tyhicks and jdstrand Hi i wanted to use UWSGI in xenial but i had some errors. ogra_ said to me its something with the seccomp can we debug it without snappy-debug? (I'm using xenial for my development)
<kyrofa> Good morning
<noizer> ogra_ they online? or can kyrofa help me?
<noizer> Good morning
<ogra_> noizer, perhaps not yet (US timezone ?)
<ogra_> sergiusens, what are you doing here ? isnt is a holiday in arg. ?
<noizer> ok
<kyrofa> Hey seb128 the scope is out-of-date (using the webdm API instead of the snappy API) and not being used since Personal isn't being used. And as you see on the bug, it sounds like the golang updates have broken it. I think it will probably be updated eventually, but it doesn't make sense to put in the effort right now for something no one is using :)
<sergiusens> ogra_, auto connect; good bye ;-)
<ogra_> enjoy !
<ogra_> :)
<sergiusens> ogra_, it's almost 11 and I just got up; I started the day perfectly :-)
 * sergiusens waves
<ogra_> :D
<seb128> kyrofa, I expect some people are going to want pocketpc or unity8 desktops to be able to install snaps, even if there is no personal image
<kyrofa> ogra_, I believe seccomp denials go into syslog as well
<seb128> willcooke, ^ do you know?
<ogra_> kyrofa, oh, right
<kyrofa> seb128, good question
<kyrofa> ogra_, snappy-debug just parses syslog
<ogra_> yeah
<noizer> ogra_ are there some other things that i can test?
<willcooke> seb128, kyrofa - yes, I would expect that people would want to install snaps in a U8 session on a desktop.  But, it's probably not a priority.  Let me see what I can find out.
<ogra_> noizer, as kyrofa said, check syslog for seccomp lines
<noizer> ow sorry
<noizer> how can i do that ogra_ sorry not familiar with some logging of linux
<ogra_> its a text file :)
<ogra_> /var7log/syslog
<ogra_> bah
<noizer> ooh dammed
<ogra_> /var/log/syslog
<noizer> :D
<noizer> ty
<ogra_> run tail -f /var/log/syslog ... in one terminal ... in another terminal start your app/service/whatever ... and see what it logs ... watch for seccomp lines then
<ogra_> (or just search for former seccomp lines without monitoring live ... as you like)
<noizer> ogra_ that is what i got when im started my application
<noizer> http://pastebin.ubuntu.com/14993207/
<kyrofa> willcooke, yeah, please let me know. I can talk to alecu again, see if we should give it a higher priority if that's true
<ogra_> noizer, syscall=282 is blocked then
<ogra_> noizer, now run: scmp_sys_resolver 282
<ogra_> that tells you which function it is
<noizer> its the bind method
<noizer> now the bind method is that from the ubuntu snappy? or from my uwsgi?
<kyrofa> noizer, binding to a port, probably. You're using Snappy 16.04 right? What capabilities are you providing to your service/binary?
<noizer> kyrofa yea i'm using Snappy 16.04. what do you mean by the capabilities of my binary?
<kyrofa> noizer, pastebin your YAML real quick
<noizer> ok
<noizer> but now its not a service I start it from command line (bash file)
<kyrofa> noizer, alright
<noizer> He isnt at the moment a network service if you mean that
<noizer> I will add something to it
<noizer> kyrofa does you need then my Yaml file?
<noizer> kyrofa how can i sea if uwsgi is running then? In normal ubuntu then you can see it with ps -A but in snappy i don't know that
<kyrofa> noizer, yeah let me take a look. But yeah, you need to give it permission to bind to a port
<kyrofa> noizer, yeah you can still use ps
<noizer> Ok awesome
<noizer> My snap is now building with the network-service. but now an other question seccomp what does it do with snappy?
<kyrofa> noizer, ahh, so much
<kyrofa> noizer, snappy has an excellent confinement story, utilizing a number of technologies to get there
<noizer> kyrofa can i find some information of the complete build of snappy
<kyrofa> noizer, it uses apparmor to make sure the .snap can only play in its own space on the filesystem, seccomp filters to make sure it can only call a whitelist of syscalls, as well as cgroups
<kyrofa> noizer, so that one little network-service capability you added results in a different profile being used for apparmor and seccomp
<kyrofa> noizer, what do you mean by "complete build?"
<noizer> oooh ok dem so a nice system Snappy
<noizer> How snappy is builded
<noizer> So i know more about the underlaying things
<kyrofa> noizer, ah, that's outside of my purview. But here's an overview of the security side of things: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
<noizer> kyrofa ok I will read this. Looks very intresting :D
<noizer> kyrofa I tried now with ps -A but dont see anything running
<kyrofa> noizer, probably died then. If it gets a seccomp denial it's always fatal
<noizer> will it be in the syslog?
 * kyrofa has a flashback to having to modify the mysql code so it wouldn't die
<noizer> Does i need do some command to start the services?
<kyrofa> noizer, not sure what you mean
<noizer> no uwsgi can run now :D awesome
<kyrofa> noizer, so it works?
<noizer> normally yes thanks for you help :D awesome support here :D
<kyrofa> noizer, very good!
<ogra_> yay
<noizer> hahah ogra_
<noizer> now i need to wait until Skills will be released :D
<noizer> what is the expected release date of the skills?
<beuno> noizer, I think we have a few more weeks until we reach a testing phase
<kyrofa> noizer, the only target I know of is "for 16.04" :P
<noizer> kyrofa lol ok :D
<dholbach> kyrofa, did you ever see anything like this? http://paste.ubuntu.com/14993445/
<kyrofa> dholbach, uhh
<kyrofa> dholbach, nope. Gross :P
<dholbach> I'll file a bug :)
<kyrofa> dholbach, does it work on a second try? i.e. store hated you for a sec?
<kyrofa> dholbach, obviously we should handle those errors better
<dholbach> kyrofa, this time it didn't explode :)
<dholbach> so maybe intermittent
<kyrofa> dholbach, honestly that's an all-around snapcraft bug (the stack trace)
<kyrofa> dholbach, something I've been very much wanting to make cleaner
<dholbach> <3
<kyrofa> ogra_, can 15.04 run decently on the dragonboard then?
<ogra_> kyrofa, it might, i dont think anyone works on this beyond some basic demo stuff (i surely am not aware of plans to make official 15.04 images)
<kyrofa> ogra_, alright, does regular-old Ubuntu work?
<ogra_> it might ... you have to set up the SD in a special way though
<ogra_> i have scripts for that at http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/README
<elopio> fgimenez: tests still fail with http proxy. Could you please check if I'm doing something wrong here: https://github.com/ubuntu-core/snappy/pull/429/files
<kyrofa> ogra_, I'll take a look, maybe I can get the owncloud snap built for arm64
<ogra_> yay, that would be cool (though it is WLAN only, might have some bootloenecks)
<fgimenez> elopio, sure, on it
<fgimenez> elopio, jenkins feels young and strong again! :D
<elopio> fgimenez: yes! I changed the ip. I'm making a change in this branch to see it run.
<fgimenez> elopio, last time i tried the http://squid.internal:3128 was only accessible from scalingstack instances
<fgimenez> elopio, in order to test in jenkins we need to add -httpProxy to snappy-tests-job too
<elopio> fgimenez: on that last execution, I did the deps manually, got an image, and called main.
<zyga> jdstrand: hi
<zyga> jdstrand: could you have a look at https://github.com/ubuntu-core/snappy/pull/462
<zyga> jdstrand: (hopefully last iteration of this type)
<zyga> tyhicks: ^^
<jkridner> hi ogra_!
 * jkridner looks for rcn-ee
<ogra_> hey jkridner !
<kyrofa> elopio, wait... encrypted variables in travis don't work from forks?
<elopio> kyrofa: yes, just the main repo.
<kyrofa> elopio, why? I glanced through that bug but didn't really see one. Maybe the worry is that the third-party can add code to phone the variable's value home to them?
<elopio> kyrofa: or just echo it and get it from the logs.
<kyrofa> elopio, that might be easier, yeah
<kyrofa> elopio, huh. Guess I never thought about it before
<kyrofa> elopio, how on earth does coveralls work?
<ysionneau> Hi, is it possible to install the snappy-tools on Debian?
<jkridner> ogra_: can you give rcn-ee and I some pointers on how to easily build a snappy image? The above question about doing it on Debian is also useful.
<jkridner> ogra_: sorry to ask such a google-able FAQ....
<jkridner> ogra_: but want to make sure we short-circuit it as much as possible.
<noizer> kyrofa i have an other question for you
<noizer> is it possible to launch an other snap from my own snap?
<ogra_> jkridner, our core tool (for the final assemblement) is called ubuntu-device-flash ... it is written in go with no deps ... that part should definitely run under debian
<ogra_> not sure about other bits though
<jkridner> ogra_: cool.
<kyrofa> noizer, no, snaps can only touch their own stuff, not interfere with each other
<jkridner> ogra_: /me can't /invite rcn-ee
<kyrofa> noizer, unless you unconfined it, but I doubt such a thing would accepted in the store
 * jkridner notes no channel operators here!
 * jkridner goes afk
<noizer> hmm
<noizer> kyrofa but we asked ubuntu if that was possible or will be possible and then they said yes. Because we are making something where people can make their own applications and these application needed to be snaps.
<noizer> or can you start an app from the webdm?
<kyrofa> noizer, I'm not saying it'll never be possible-- anything is possible with the right skill. There's just no skill that encompasses that functionality that I know of
<kyrofa> noizer, no, just install/uninstall them
<noizer> hmmm
<kyrofa> noizer, and you don't want them to be services that just run upon install?
<elopio> kyrofa: it doesn't sound hard to allow secure env vars per user, instead of per repo. But the travis team is small, they just close most of the bugs as won't fix :(
<kyrofa> elopio, sad
<elopio> kyrofa: and I have no clue about how coveralls work. I started wondering because fgimenez added a coveralls report without token.
<noizer> maybe but can you hook into an snapp as a developer I dont think so :s
<kyrofa> noizer, I'm not sure what you mean
<elopio> they should have something special between coveralls and travis. As the reports are per branch, it sounds safer than normal tokens.
<noizer> Do you mean that the people needed to make services so they can run on it?
<noizer> kyrofa
<kyrofa> noizer, I'm sorry, I still don't understand. So you have service snap A, upon which client snaps B and C depend. Are you saying that snap A needs to be able to start and stop the programs contained within snaps B and C? Or can the programs contained within B and C simply be running at all times?
<zyga> jdstrand: around?
<fgimenez> elopio, about the different images reported by the vivid and xenial slaves http://paste.ubuntu.com/14993929/
<elopio> fgimenez: that's crazy. A bug?
<elopio> a bug in grep maybe :D
<fgimenez> elopio, no idea, anyway vivid's version of the client is very old, maybe it's a known issue... "image show" woks even with images that don't appear in the list :D
<elopio> fgimenez: how do you set up two labels for a slave in this docker run statement?
<fgimenez> elopio, white-spaced separated according to https://wiki.jenkins-ci.org/display/JENKINS/Swarm+Plugin#SwarmPlugin-AvailableOptions
<jdstrand> zyga: hey, yes
<jdstrand> zyga: I got your request to look at the pull request. I haven't gotten to it just yet
<zyga> jdstrand: thanks
<elopio> fgimenez: common.sh is getting really ugly when I add the snapcraft container. Is there a way to install the dependencies on each test run?
<elopio> oh, he's gone.
<elopio> fgimenez: common.sh is getting really ugly when I add the snapcraft container. Is there a way to install the dependencies on each test run?
<fgimenez> elopio, right now the slave user isn't a sudoer, we can change that. anyway, why not adding the dependencies to the container itself?
<elopio> fgimenez: I did that. The problem is with the naming. Now we have slave-xenial and slave-xenial-snapcraft. So all the get_name and get_dir functions are getting an extra optional argument.
<elopio> doens't look nice.
<kyrofa> noizer, you're asking questions that may interest others. If you ask them via PM no one else can benefit from them
<fgimenez> elopio, all that functions are going away with docker-compose, no worries
<elopio> fgimenez: right, I supposed you were going to say that.
<elopio> :)
<fgimenez> fgimenez, yep :)
<elopio> so I'll dump this branch and wait for you.
<elopio> pedronis: you merged your last PR with integration errors. Did you check if you could have caused them?
<pedronis> elopio: they are quite flaky this dies, it was again a vm creation problem
<elopio> pedronis: I see: sudo snap assert integration-tests/data/dev1.acckey
<elopio> error: open : no such file or directory
<pedronis> ?
<pedronis> where what
<elopio> which doesn't make a lot of sense.
<elopio> pedronis: http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/725/consoleFull
<pedronis> elopio: they passed here:  http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/723/
<pedronis> I don't think IÂ changed anything significant since
<elopio> pedronis: that one failed to create the vm.
<elopio> wrong link?
<pedronis> elopio: is marked as passed in github
<pedronis> fascinating
<elopio> crazy thing.
<elopio> it should say no results found.
<elopio> pedronis: we have a brand new jenkins today. Now that the deploy and the slaves are more stable, we can dig on those weird things.
<elopio> and add retries for when scalingstack is grumpy.
<pedronis> elopio: seems there all bunch of green in github that was actually vm not started
<pedronis> so not sure when they started failing, I see other failures in that run that are not assert related
<elopio> pedronis: please give me a link.
<elopio> pedronis: I'll be monitoring today.
<pedronis> elopio: the runs at the top here: https://github.com/ubuntu-core/snappy/pull/460
<pedronis> marked as green
<pedronis> if you click you see they didn't run
<fgimenez> elopio, pedronis this is probably due to the lack of sync before setting up the new server, this is the successful run that pedronis was talking about http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/723/
<elopio> pedronis: hum, that doesn't make sense. Maybe when we redeployed we messed with the history.
<pedronis> ah
<elopio> it prints 60 successful tests. There's no way to get that message from a failed job.
<fgimenez> elopio, pedronis and the list of greens http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/
<pedronis> ok, but if that one passed, no clue what make them fails
<pedronis> after
<elopio> so now the numbers are different.
<pedronis> because nothing substatianl change
<pedronis> d
<pedronis> it's all formatting and comments
<elopio> weird. fgimenez: do you have any idea about that failure to find the file in integration-tests/data?
<fgimenez> pedronis, something must be different in the new server, probably not related to the code
<fgimenez> elopio, nope, taking a look now
<pedronis> also that message is not super clear, not sure is not finding the file or one of the commands
<pedronis> or what
<elopio> pedronis: fgimenez: I also see this: https://paste.ubuntu.com/14994568/
<elopio> doesn't seem normal.
<fgimenez> elopio, this was happening before the server change
<pedronis> elopio: that's the code John added, is retrying so that's expected I think
<pedronis> a bit ugly but expected
<fgimenez> elopio, http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/723/consoleFull
<elopio> I'm going to get a testbed kvm.
<elopio> ah, we can make that prettier making more prints in the wait package.
 * pedronis needs to go have dinner, will check logs later
<fgimenez> elopio, pedronis i think that the errors might be related to the recent changes in the testutils/cli package, the server seems to be fine
<fgimenez> elopio, if you can execute it locally it would be great to confirm, i'm leaving too
<elopio> fgimenez: pedronis: enjoy. I'll be debugging here, come back tomorrow for the results :)
<fgimenez> elopio, thx :) i'll keep an eye on telegram o/
<pedronis> elopio: if I try to run the tests here IÂ crash already in testutil/common.go   GetCurrentVersion
<pedronis> something is off with those cli changes, I also don't understand that branch didn't seem to have run the integration tests
<pedronis> ah, no it did
<elopio> pedronis: I'm bisecting...
 * ogra_ wonders why nobody has created a unifi manager snap yet 
<ogra_> (i know many canonicalers are using unifi APs)
<elopio> pedronis: nop, I went back to a revision that I know passed all the tests and it still fails. Something else changed, not our repo.
<pedronis> at least I crash on snappy list not having content
<elopio> it has to do with the flags, because assertOptions.AssertionFile doesn't get the name from the command line.
<elopio> zyga: pedronis: ^
<elopio> zyga: you have been touching the cmds, right? Any idea what could be going on here?
<zyga> elopio: looking
<zyga> elopio: I haven't seen GetCurrentVersion, that's not related to my changes
<zyga> elopio: I was making CLI more testable (ironically!)
<pedronis> that is still something else
<elopio> I don't get any error with GetCurrentVersion. Nor scalingstack.
<pedronis> elopio: the snap I get compiled here seems to work (it gets the first arg)
<pedronis> but my test runs crash before that :/
<elopio> pedronis: the one I got here doesn't even show the file help in -h
<pedronis> snap [OPTIONS] assert assertion-file
<elopio> pedronis: https://paste.ubuntu.com/14995878/
<pedronis> weird
<elopio> this is a pristine all snaps just generated with mvo's udf
<elopio> asserts -h shows the options.
<pedronis> bulding it on trunk looks right
<pedronis> does the archive have a go-flags that is older than the dep
<elopio> ahh, no, this is a whole mess. https://paste.ubuntu.com/14995920/
<elopio> asserts shows options that are not for the asserts command :)
<pedronis> it's ignoring arg 1
<pedronis> but yes it seems the snap and snappy in the image are broken
<elopio> I'm using goflags 0.0~git20150817-0ubuntu1
<elopio> latest xenial.
<elopio> pedronis: which one do you have?
<pedronis> I'm building from the checkouts
<pedronis> but yes the snappy snap in ubuntu-core.snap are broken IÂ suppose
<pedronis> elopio: I double checked the image my tests are trying to use has a broken snappy list
<elopio> pedronis: I can run snappy list here.
<pedronis> so weird
<elopio> yes indeed.
<pedronis> elopio: this is what I get http://pastebin.ubuntu.com/14996079/
<pedronis> this built with u-d-f by running integration tests
<elopio> pedronis: ah, if you didn't patch your udf with mvo's version, that's not going to work.
<pedronis> elopio: have mvo versions
<pedronis> IÂ have been happily running integration tests all last week
<elopio> oh, I think I know what's the deal.
<elopio> give me a second...
<elopio> pedronis: this made my tests pass.
<elopio> https://paste.ubuntu.com/14996133/
<elopio> now you have an image that's clearly more broken than mine.
<elopio> I flashed like this: https://paste.ubuntu.com/14996153/
<pedronis> did xenial go-flags change recently?
<pedronis> still not understanding what changed since last week
<pedronis> elopio: was the old testing box also xenial?
<elopio> pedronis: no, it's the same that we have in the deps since a long time ago.
<elopio> maybe something in go changed.
<elopio> pedronis: yes, also xenial, but we deployed a new one today. That one had old packages, probably.
<elopio> this is an important thing that we are not doing. apt-get update && upgrade often on the slaves.
<elopio> pedronis: can I propose this as a quick fix to get back to green, and let you investigate the reason tomorrow?
<elopio> https://bugs.launchpad.net/snappy/+bug/1543266
<ubottu> Launchpad bug 1543266 in Snappy "snap assert failing with error: open : no such file or directory" [Critical,Confirmed]
<pedronis> elopio: yes
<pedronis> and yes it seems related to go version
<elopio> pedronis: ok. So this can wait until tomorrow, you don't need to stay so late.
<elopio> thanks a lot for your debugging.
<pedronis> so it's probably go-flags that is unprepared/has go 1.6 bugs
<pedronis> I don't care either way about that code though
<pedronis> elopio: solved the snappy list, seems IÂ had mvo u-d-f but not the latest
<elopio> pedronis: phew. One less thing to investigate :D
<elopio> oh, the asserts tests should be failing too.
<elopio> let me upper-case that.
<pedronis> found the problematic code in go-flags, in case we want to give them a PR
<elopio> pedronis: that would be awesome. I want to peek, where is it?
<pedronis> elopio: it's related to this
<pedronis> http://tip.golang.org/doc/go1.6#reflect
<pedronis> group_private.go:72:		if field.PkgPath != ""   in go-flags
<elopio> interesting. Not a single boring day in the snappy world.
<pedronis> should be change like they change encoding/json in go ittself, it seems
<elopio> kyrofa: is there a way to see the squashed commits after the PR was merged?
<kyrofa> elopio, not without playing some fun games... that's kinda the point. Why, what happened?
<elopio> kyrofa: nothing. I want to convince snappy to squash commits.
<kyrofa> elopio, yeah not really
<elopio> if there is a way to see all the commits, there's no convincing to do. I'll just tell them to use that.
<kyrofa> elopio, yeah, you'd have to use the reflog
<kyrofa> elopio, which is usually more of a "I made a mistake, give me back my stuff" type of thing in my experience
<elopio> ok, it doesn't matter. I have a good argument.
<elopio> the discussion history is not lost.
<kyrofa> elopio, haha, you're brave
<elopio> bisecting this crazy issue just made it clear that not even with a nice commit message the snappy changelog makes sense.
<elopio> we need branches, and we need squashes. QA has spoken! :D
<kyrofa> elopio, heh, yeah bisecting is key
<wiggleworm> is there a graphical interface for wifi setup in snappy
<wiggleworm> i worry i am staring right at it :)
<camako> When I change the cmake file 'snapcraft snap' doesn't seem to detect the changes and regenerate cmake config accordingly. Is there a way to do that?
<camako> I couldn't find a '--force' option either
#snappy 2016-02-09
<zyga> hello
<dholbach> good morning
<noizer> good morning
<JamesTait> Good morning all!  Happy Tuesday, and happy Pancake Day! ð
<diwic> JamesTait, good morning! What do I need to install to see that unicode character? It is not visible on OOTB Ubuntu 14.04, at least.
<JamesTait> diwic, you're not the first person to ask, but I still don't know the answer.  I might have had to install a specific font for it, not sure.
<dholbach> diwic, fonts-symbola?
<dholbach> I searched for it in gucharmap and right-clicked on it
<JamesTait> dholbach, that does sound familiar, actually.
<dholbach> mh... then I don't know :)
<diwic> dholbach, thanks, but I can't find fonts-symbola in the archive...?
<dholbach> diwic, I'm on xenial
<JamesTait> In fact I think someone on IRC told me to install that, let me check my logs.
<dholbach> Description: symbolic font providing emoji characters from Unicode 7.0
<JamesTait> ttf-ancient-fonts-symbola?
<diwic> interesting, it appears on vivid and nothing below that
<dholbach> that's what it provides in 16.04, yes
<dholbach> 14.04 is pre-emoji times
<diwic> heh
<diwic> maybe I can just install the .deb from vivid and hope for the best :p
<diwic> it worked! \o/ thanks dholbach and JamesTait
<JamesTait> Woohoo!  ð
<dholbach> :)
<diwic> or should I say ð
<diwic> oh well, now on to figuring out how to make snapcraft generate correct security profiles
<opny> Hello! After a bit of hassle, I've been able to get running Snapcraft 2.1 on Xenial. I've noticed however the jdk plugin fails now, is this a known issue?
<dholbach> opny, fails how?
<opny> dholbach, http://paste.ubuntu.com/15000971/
<dholbach> opny, I can't find any bug report for it at https://bugs.launchpad.net/snapcraft
<opny> dholbach, is it an implicit request?
<dholbach> opny, you asked if it was a known issue :)
<dholbach> I'm just playing around with the java related examples to see if I can reproduce anything
<dholbach> so the java-hello-world example works for me too
<dholbach> trying the tomcat example now
<opny> dholbach, :) ok.. If you mind I have a github repository for that snap I'm looking to build
<dholbach> cool - have a link?
<opny> dholbach, https://github.com/muka/kura.snap (Let me a moment to push current status)
<dholbach> cool, let me know once you're done
<opny> dholbach, ok done
<dholbach> taking a look now
<dholbach> opny, I can't reproduce the problem
<opny> dholbach, uhm ok thank you for checking. May be the case I'm using a mount in virtualbox, will try to move it out
<dholbach> maybe you can run  snapcraft clean  and start over? it looks like an apt problem
<dholbach> maybe... *shrug*
<dholbach> first I thought "maybe a part can't have the name of a snapcraft plugin", but that seemed irrelevant
<dholbach> then I saw that build-packages should probably be stage-packages
<dholbach> (if you want to bundle things in your snap, as opposed to making sure that certain packages are installed on the machine where you're building the snap)
<opny> dholbach, build vs stage packages is a recurring topic for me :) Yes, stage is the appropriate one!
<dholbach> :)
<opny> dholbach, moving out of shared folder worked.. thanks
<dholbach> excellent :-D
<asac> elopio: running unit snapcraft tests on master cant find the storeapi etc... i use ./runtests.sh unit
<asac> ok seems thats xenial only
 * zyga pushed https://github.com/ubuntu-core/snappy/pull/468
<opny> Hi, in snapcraft can I specify a git branch to pull?
<dholbach> opny, yes - take a look at examples/godd/snapcraft.yaml
<opny> dholbach, thank you
<opny> dholbach, I do not see any branch ref https://github.com/ubuntu-core/snapcraft/blob/master/examples/godd/snapcraft.yaml#L15
<opny> dholbach, Is it like url#branch ?
<dholbach> opny, use source-branch
<dholbach> (type: snapcraft help sources)
 * zyga pushed big security part of skills for review
<zyga> https://github.com/ubuntu-core/snappy/pull/468
<zyga> elopio: do you know why some integration tests fail on all the branches (3 out of 58)
<fgimenez> zyga, that was fixed with https://github.com/ubuntu-core/snappy/pull/467, if you rebase to the tip of master all should be fine
<zyga> fgimenez: ah, thanks
<zyga> fgimenez: I should stop being lazy and use my VPN :)
<kyrofa> Good morning
<didrocks> hey kyrofa!
<kyrofa> didrocks, hey there! Good day so far?
<didrocks> kyrofa: so far, yeah :-)
<didrocks> how are you?
<kyrofa> I'm doing pretty well-- my son has been sleeping kinda bad, which means I have been too :P
<didrocks> argh, yeah, coffee time I guess then! :-)
<kyrofa> Oh yes ;)
<ogra_> ppisati, hmm, is the "linux-snapdragon" you uploaded this morning usable on the dragonboard already ?
<ppisati> ogra_: nope
<ogra_> k, thx
<opny> hi, snapcraft fails while doing its own apt-get update with a  "Hash Sum mismatch". I've edited the sources.list to point to other archives but snapcraft still tries to use the old one
<kyrofa> opny, that's usually a temporary error with the archives
<kyrofa> opny, just try again in a few minutes
<opny> kyrofa, thanks, however, this is making me go crazy!
<kyrofa> opny, yeah it kills our CI tests every once in a while too
<opny> kyrofa, I have a sed thing to switch around countries and have it working. This work for apt-get but not for snapcraft
<kyrofa> You know you're OCD when you realize you have a thousand tabs open and just close the browser completely to start over
<ogra_> the bad thing is that over time you end up with all these "session restore" tabs that pile up :P
<kyrofa> ogra_, hahaha
<kyrofa> ogra_, but those only come up if it exits inappropriately, though
<ogra_> well, depends if you actually want that (i have occasions where i just want to archive the tabs and start over to save ram... and kill -9 ...)
<kyrofa> ogra_, ha!
<JamesTait> So glad to know I'm not the only one who has that problem.
<kyrofa> JamesTait, which one, slaughtering firefox to archive your tabs, or OCD?
<JamesTait> kyrofa, just the "ZOMG, I have 7 Firefox windows with 54 tabs in each, how did this happen?" problem.
<kyrofa> JamesTait, ah, yes exactly. "Kill them all! Go away! I don't care what I was in the middle of doing, I can't keep track of all this!"
<JamesTait> And they're killing tab groups!
<JamesTait> So instead I made an attempt to organise things into bookmark folders, and then "open all in tabs" when I want to work on something specific.
<JamesTait> With varying degrees of success....
<kyrofa> Interesting idea
<JamesTait> I'm still trialling it.  It's taking some time to get used to and to be disciplined about.
<kyrofa> elopio, I'm assuming you can't hear me :P
<jdstrand> dholbach: hi! would you mind looking at my response to your comment to my MP?
<kyrofa> elopio, if you have headphones in, and aren't hearing me... what you are listening to? Are you muted and just have headphones on?
<dholbach> jdstrand, I'm in calls for the next hour, but could take a look later on
<kyrofa> elopio, so this is creepy. I'll get out so I don't feel like I'm spying on you :P . Ping me when you're ready?
<kyrofa> Ping timeout... that might explain some things
<kyrofa> elopio, you there now?
<JamesTait> jdstrand, I just re-merged that branch locally and get the same, but I didn't see it yesterday.  Not sure what changed since then.
<elopio> kyrofa: I can't see you.
<elopio> nor hear you.
<kyrofa> elopio, yeah that was several minutes ago now. Let me hop back in
<JamesTait> jdstrand, are there any plans (is it even possible) to split the MP into smaller chunks?  10k lines is a lot to review. âº
<elopio> several minutes ago it also appeared that I was alone.
<kyrofa> Creepy
<zyga> jdstrand: hey :)
<plars> elopio: for the testconfig.json needed by the integration tests, what's the bare minimum we need to make it run?
<plars> elopio: also, do the values in it really affect the tests that run?
<jdstrand> JamesTait: well, I could remove some of the sr_ bits
<jdstrand> JamesTait: but the problem is that it will be large because it is a refactor
<jdstrand> well, in part
<jdstrand> zyga: hi :)
<jdstrand> I did write a ton of new tests for snap.yaml which are adding to the length
<JamesTait> jdstrand, yeah, I noticed that, and I'm thankful. âº
<JamesTait> jdstrand, I've been looking at individual commits to try and make the diff smaller.  I just wondered if there was a neat way to split "this factors out the common stuff but maintains feature parity" from "this starts adding snappy 2.0 specific functionality".
<elopio> plars: I think now it will just affect the update tests.
<elopio> oh well, after a couple of my branches land, that simplify things.
<elopio> I need to check in detail if we still need it.
<JamesTait> jdstrand, fwiw I've been throwing lots of files at the refactored version and haven't noticed any obvious problems.
<kyrofa> elopio, ... it's an invalid python syntax thing?!
<jdstrand> JamesTait: well, I can probably do that if is do the refactor, then pull out the 16.04 tests from cr_*, then add the 16.04 sr_* tests. the problem is, that is going to take me a while to make those 3 commits committable since the refactor happened rather organically since I didn't know what needed refactoring until I got into it
<jdstrand> JamesTait: but, if that is going to help with the review, I can take the time to do that
<plars> elopio: these branches will make it so that all the tests don't try to need that json file?
<elopio> plars: no, I think we'll still need it.
<jdstrand> JamesTait: re lots of files-- yeah, as part of the testing I plan to run all the snaps through the tools in the old and new versions and do a compare (like I've done with other big changes)
<elopio> I'm just not 100% sure why. It had like three functions. I removed one.
<elopio> kyrofa: that's what it says, but it's valid syntax.
<jdstrand> but as I've been going I've been doing various spot checks
<jdstrand> JamesTait: thanks for the testing
<elopio> kyrofa: ah, it could be missing the quotes.
<plars> elopio: ok, we're trying to run these tests under checkbox, and it's complaining about not having that file. I'm trying to see if there's a way to just avoid it, or if we should just put a stub file there to make it happy, or if we need to generate the real thing
<kyrofa> elopio, yeah running that command here doesn't work, though it exits with a shell error, not a python error
<elopio> plars: you need to generate the real thing.
<JamesTait> jdstrand, yeah, I understand. âº   I've been there enough times myself!  On the one hand I'd like to do a thorough review of all the changes, on the other hand we'd like to get this landed sooner rather than later.
<elopio> plars: I'm with you all morning today. Just give me a second to get ready.
<plars> elopio: no rush, I am off to a standup anyway
<jdstrand> JamesTait: ok, I will focus on finishing the TODO for this so at the very least, reviewers can run this branch locally on snaps that are flagged for manual review. that will make sure there isn't any more refactoring (it's possible I'll have more for the security bits). then I can look into breaking this up into review parts
<jdstrand> dholbach, JamesTait: weird, if I bzr branch anew and the run-tests, it passes
<jdstrand> dholbach, JamesTait: the new check_snappy_readme_md() just doesn't use is_squashfs anymore... not sure why it is that way for you guys
<JamesTait> jdstrand, interesting - I just did that and it worked for me as well.
<jdstrand> dholbach, JamesTait: do you guys need to do 'make clean'?
 * JamesTait does that just to be sure.
<JamesTait> Nope, that still failed. :-/
<jdstrand> diff -Naur -x .bzr ./existing ./newcheckout
<jdstrand> might be interesting
<dholbach> jdstrand, still fails here - I checked 'bzr {diff,ignored,unknowns}' to have no output... not sure what else to do
<jdstrand> it is a mystery, but if I am breaking this up into 3 different parts, then perhaps looking into why it is a problem now is probably not the best use of our time
<JamesTait> Weird, this is the same branch that was passing for me last week.
<jdstrand> dholbach, JamesTait: you you both on xenial? I am, though I haven't updated in a few days
<JamesTait> I'm not - still on Wily.
<dholbach> yes, on xenial, up to date
<jdstrand> heh
<dholbach> hah, a new checkout works
<jdstrand> so, probably not xenial specific
<dholbach> that'S bizarre
<JamesTait> Yeah, odd.
<jdstrand> ok, I'm not going to worry about this. I'll keep pushing to the big branch, then I'll break up into smaller branches later
<jdstrand> if there is a problem then, we'll dive in
<JamesTait> Thanks, jdstrand!
<dholbach> jdstrand, I think I know what the problem is - maybe we have a backed-out change in lp:click-reviewers-tools?
<dholbach> jdstrand, http://paste.ubuntu.com/15002261/
<dholbach> or rather: http://paste.ubuntu.com/15002273/
<JamesTait> dholbach, I see http://paste.ubuntu.com/15002276/
<JamesTait> Aha!
<JamesTait> Heh. âº
<dholbach> :-D
<diwic> jdstrand, hi, want to chat about PulseAudio on snappy?
 * tedg watches, he wants to define new skills too
 * JamesTait defines the new skill Time Travel.
<kyrofa> JamesTait, I didn't know Apple was bring Time Machine to Ubuntu Core!
<jdstrand> dholbach, JamesTait: are your branches up to date with trunk?
<JamesTait> kyrofa, you should see it - it's magical! ð
<dholbach> jdstrand, yes
<jdstrand> diwic: give me just a minute
<diwic> the "kill daemons" skill sounds like it could fit in an RPG style game
<JamesTait> Seems to be.
<tedg> Honestly, that would be a sweet snap. Have it come on a device with a HDD or put it on your server.
<diwic> jdstrand, sure
<jdstrand> cause, I'm at r572 in my trunk
<dholbach> jdstrand, are there any previously backed-out changes that might confuse bzr during the merge?
<jdstrand> I think I didn't merge 569 and later into the cleanup branch
 * JamesTait wonders what on earth he did to have this working locally.
<JamesTait> Probably not a make clean. :-/
<JamesTait> Bah, school run time.
<jdstrand> but I just tried to merge with trunk and it came back clean
<jdstrand> ok, pulling in as cherrypicks
<jdstrand> and I can reproduce
<jdstrand> let me fix that and push
<jdstrand> dholbach, JamesTait: ^. thanks for helping me figure that out
<dholbach> glad it's going to be fixed soon :-)
<jdstrand> dholbach, JamesTait: ok, pushed
<jdstrand> diwic: ok
<diwic> jdstrand, ok, so what's currently blocking me is access to /dev/snd/*
<dholbach> jdstrand, confirming the fix :)
<jdstrand> diwic: are you on 15.04 or 16.04?
<diwic> jdstrand, 16.04, just upgraded to the latest skill-based images
<jdstrand> diwic: ok, things may be a bit rough atm as the skills work is mid-implementation
<jdstrand> diwic: let me check something
<diwic> jdstrand, to the extent that you think I should defer the snappy work and go do something else and come back in a week or two?
<kyrofa> elopio, I can't duplicate that ROS error locally
<jdstrand> diwic: alright, since /dev/snd devices aren't implemented as skills yet, hw-assign is what you need to use, and it is still available on 16.04
<kyrofa> elopio, I'm really not sure what's happening there
<jdstrand> diwic: sudo snappy hw-assign foo.sideload /dev/snd/*
<diwic> jdstrand, ok, let me see if that works
<elopio> kyrofa: ok, I can try to debug in a docker that's the same as the slave.
<jdstrand> diwic: well, we're going to need to understand what pulse needs in order to create the skills for it. I'm confident we can get you unblocked such that we have enough information for developing those skills
<kyrofa> elopio, alright. That call happens via a subprocess.check_output, so there should be no problems with the quotes
<kyrofa> elopio, I suspect the syntax error is a red herring
<diwic> jdstrand, cool. Feel free to ping me if you have further questions about what pulse needs - the hwassign thing does seem to work.
<diwic> jdstrand, how does hw-assign work internally, btw?
<diwic> jdstrand, is it related to acls somehow?
<jdstrand> diwic: great. really, if you have a working snap, I just need it or the link to the branch
<jdstrand> diwic: yes. if the specified files are in /sys, then you get apparmor rules, if in /dev, the device gets added to an app-specific cgroup
<jdstrand> diwic: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
<diwic> jdstrand, cool, thanks. I'll need to work some more on the snap - now that I know how to deal with /dev/snd/ - to make sure the sound card loads correctly
 * diwic unblocked
<jdstrand> \o/
<jdstrand> dholbach: did it work for you?
<dholbach> jdstrand, yes
<dholbach> <dholbach> jdstrand, confirming the fix :)
<tedg> jdstrand: But won't diwic need to provide a skill for applications to use? I don't understand how he does that.
<tedg> jdstrand: Seems he'll need to put some apparmor configuration inside his snap.
<jdstrand> dholbach: ah, I took 'confirming' as you were in the process of confirming it and would get back to me. thanks!
<dholbach> ah, sorry :)
<dholbach> so, yes - fixed, all good! :-D
<jdstrand> tedg: that part of the discussion has been deferred since he is unblocked
<jdstrand> tedg: but the general idea is this
<jdstrand> tedg: people have something that needs to use skills that aren't yet defined. in this case, he needed /dev/snd and mayve some udev stuff
<jdstrand> tedg: comes to snappy team, decide if the skill is worthwhile. if it is, define a skill type and the security policy, and add to snappy
<jdstrand> tedg: then the app can 'uses' the skill
<tedg> jdstrand: That clearly doesn't scale.
<JamesTait> jdstrand, dholbach - thanks!
<diwic> pulseaudio clients don't need /dev/snd, only the pulseaudio server does.
<tedg> jdstrand: And what you're saying is that snappy hardcodes the path to the pulse socket. When in reality, it should be pulse defining that. So if it is "foo" today and "foo1" tomorrow, that's defined in the relationship between the provider and the slot.
<jdstrand> tedg: then if the app is going to provide skills, they use existing types to declare what it provides. so, in this case, a socket and a dbus interface. snappy understands these skill types (eventually) and will dynamically create security policy for apps that 'uses' them
<tedg> jdstrand: It shouldn't be dependent on a specific version of snappy.
<jdstrand> tedg: no, not what I'm saying
<jdstrand> tedg: there were two parts
<jdstrand> there is what pulse needs from the system that is different from what is already there
<jdstrand> and there is what pulse can provide to other snaps
<tedg> Sure, I'm worried about the second.
<jdstrand> the first part will be a smallish set of skills
<jdstrand> that is what I described
<jdstrand> the second part is a smallish set of skill *types* that are configurable by the providing snap
<jdstrand> eg, lets say for simplicity there is a dbus skill type
<jdstrand> snappy knows about this skill type
<jdstrand> pulse snap fills in attributes for this skills type so that snappy can do stuff on the fly
<jdstrand> pulse provides a pulse skill to the system
<jdstrand> apps 'uses' this pulse skill
<tedg> Okay, I'm good with that, but then what does the app specify? All the parameters for dbus?
<jdstrand> tedg: what attributes pulse can set in its snap skill declaration for dbus is TBD
<jdstrand> tedg: bluez, pulse and nm are three snaps we can look at to help define what a dbus skill or set of skills will look like
<tedg> Seems like a big TBD, as that's kinda the core of how they integrate with each other.
<diwic> side note: pulseaudio uses unix sockets as primary IPC mechanism
<tedg> Unfortunately none of those deal with things like AppIDs being part of the dbus path, which is important for us on the phone.
<jdstrand> diwic: yes, we have 'socket' right now for that, but there will be some sort of transition to skills for that aiui (which is TBD)
<tedg> It would be nice to add a case of that as well.
<jdstrand> diwic: and the 'socket' options support both file and abstract sockets
<diwic> jdstrand, in snapcraft terms, where should I add 'socket' ?
<diwic> i e where in snapcraft.yaml
<jdstrand> tedg: today on snappy there is only a singular 'bus-name' (eg, org.freedesktop.pulseaudio)
 * ogra_ curses 
<jdstrand> diwic: alongside 'command' under 'apps'
<ogra_> root@anubis:/# snappy build --squashfs snap/
<ogra_> 2016/02/09 16:02:18.472075 main.go:40: WARNING: can not create syslog logger
<ogra_> open snap/meta/snap.yaml: no such file or directory
<jdstrand> diwic: see docs/meta.md in the snappy git tree
<tedg> jdstrand: So, in general, I agree that this overall approach makes sense. But when I said that on the list, zyga said that is incorrect.
<jdstrand> tedg: but this was far too limiting on two fronts: bluez listens on more than one bus-name and there was no way to define dbus bus policy
<tedg> jdstrand: The problem is that is the "easy case" â where there is less interaction and negotiation that is needed. We need to tackle the hard cases too.
<diwic> jdstrand, in 16.04 too?
<jdstrand> tedg: so the skills work will need to accommodate that. note, I said for the simple case there is a skills type of 'dbus'-- I don't know if that will be more specific or not
<jdstrand> diwic: yes
<tedg> jdstrand: Before feature freeze next week? ;-)
<jdstrand> tedg: now, in terms of APP_ID, that shouldn't be a hard problem. only 'trusted helpers' need to know about APP_ID's. app templated policy won't really have to change here and the trusted helper will only need security policy to allow looking at its own path, etc. it should basically work, but there might be some fine-tuning (possibly an additional skill for trusted helpers, but I doubt it). I don't see a big issue there
<jdstrand> tedg: this is snappy, feature freeze isn't until May :P
<noizer> hi, short question. is ASCII not support by a snap?
<noizer> because i get the following error with my uwsgi LookupError: no codec search functions registered: can't find encoding
<tedg> jdstrand: Sure, there could be another simple type, but we're startting to add a lot of simple types then.
<tedg> jdstrand: I'm worried we're only covering the trivial cases and not specing out the complex ones early enough. The format doesn't seem like it can handle the complex cases and is becoming more and more difficult to chagne.
<jdstrand> tedg: I personally worry about the number types exploding. on touch we tried to keep that low. in snappy 15.04 we did the same. in snappy 16.04 and skills, people said this wasn't a problem and that is the path forward
<jdstrand> tedg: types are actually supposed to be pretty easy to add
<tedg> jdstrand: I *think* the hooks are going to need richer communication with the security frameworks, which is harder to add. It's hard to see with the current state of things though.
<jdstrand> and 16.04 is only supposed to have a smallish number of easily understood types so that we can learn from them to do more complex ones
<jdstrand> tedg: mapping click hooks to snappy is not on anyone's 16.04 todo list afaik
<tedg> I'm fine as long as "smallish" is "everything we need for phone" :-)
<tedg> jdstrand: It is on my todo list, but I can't figure out enough info to make anything other than a shot in the dark.
<jdstrand> tedg: I though 'Personal' work was not for 16.04. did that change?
<jdstrand> also, while I am speaking rather authoritatively here, skills are Gustavo's and zyga's baby-- I'm only providing input for the security bits and bringing up other things as needed (ie, I'm thinking about touch too)
<tedg> jdstrand: Getting snaps so they could be installed on desktop or phone is a desirable feature, and we'd want those snaps to work into the future. So "personal" is not, but getting apps that will work for personal is.
<fgimenez> elopio, sorry, don't know how i ended in the internal channel :D
<jdstrand> tedg: I think getting leaf desktop snaps will be fine. that is different from a trusted helper and different than a click with lots of hooks, both I interpreted in the realms of 'Personal'
<tedg> jdstrand: Certainly desktop is easier than phone, but while no one has decided anything, phone apps are on the table still as well.
<zyga> jdstrand: I refreshed bool-file skill, would love if you can have a 2nd look at the security side
<elopio> fgimenez: I think this is ready: https://github.com/ubuntu-core/snappy-jenkins/pull/72
<fgimenez> elopio, thx let's merge after travis finishes
<jdstrand> zyga: ack-- saw it, haven't gotten out of irc questions yet :)
<zyga> jdstrand: thanks, if you have any questions about it we can also talk on irc
<jdstrand> ok
<JamesTait> jdstrand, what gotchas would I need to look out for if I wanted to use click-reviewers-tools as a library in the Store, rather than shelling out to a subprocess?  Is there a stable public API?
<jdstrand> JamesTait: I think to do that well, we'd want to break what is in click-review out into a library and have that be the api. then click-review and you could use that
 * JamesTait nods
<jdstrand> JamesTait: click-review itself has been very stable and not changed much (until this cleanup branch)
<jdstrand> so I think breaking out those bits would provide a good api
<JamesTait> It's not something I'm looking to do immediately, unless it turns out to be so trivial it'd just fit into existing work, but as a future path I think it'd be preferable.
<plars> elopio: I think it looks like we won't need much (anything?) in that json file if we aren't using the update/rollback tests, but it will still error if it can't read the file. So we can stub one, but it seems to read from a hardcoded relative path, that picks up its base path from the GOPATH on the build system
<plars> elopio: would a parameter for this testconfig path be ok to add?
<plars> elopio: or do you have a better suggestion
<JamesTait> jdstrand, also, this is totally work that I'd expect the Store team to take on - just to be clear. ð
<jdstrand> ack
<elopio> plars: it's only used for update, rollback and the info_test.
<elopio> I'm not sure if you want to run the info test.
<elopio> if you don't want anything to do with it, I can catch the file not existent error, and put a default config.
<JamesTait> We've got a Trello card open for it, I'm just going to add some thoughts to it for now and we'll see where it fits in.
<plars> elopio: but all tests try to read it: Error reading config: open integration-tests/data/output/testconfig.json: no such file or directory
<jdstrand> makes sense
<elopio> plars: yes, because all tests check if they are in the middle of an update or rollback.
<elopio> I can put a default false in there.
<plars> elopio: or we could probably just generate a json file with "{}" in it right?
<elopio> plars: I'm not sure what will happen in that case. Maybe json.Unmarshal sets default values, or maybe it fails because of the missing fields.
<elopio> plars: but there's something more important to solve here.
<elopio> that integration-tests/data/ path is important, not just for the config. All the test snaps are in there.
<elopio> so it's not just the binary what you need. You also need the test data.
<plars> elopio: oh, so it's not enough just to ship the test binary, there's other data there too it needs?
<plars> got it
<elopio> yes. The config is not too important now. But the others are.
<elopio> plars: can you try creating that testconfig.json to see if the binary finds it?
<plars> elopio: I see that now... elopio but those don't get built when I build the integration tests with go test -d
<plars> err.. -c
<elopio> nop. Just the code goes into the binary, no data files.
<plars> elopio: yeah, we'll give that a try. What will I need to force it to build all those other snaps? and will they need to be in that exact directory structure?
<olli_> ho
<elopio> plars: you don't need to build the snaps, they are build during the tests. You can't include them in the binary, afaik. You'll have to copy them to the testbed, as we do here with adt-run.
<olli_> I love xchat and how it moves keyboard input between channels when starting up
<fgimenez> elopio, this is done https://hub.docker.com/r/ubuntucore/snappy-jenkins-slave-xenial/builds/ we can build the new base image now
<elopio> fgimenez: let me first re-run the tests on my branch and merge it.
<fgimenez> elopio, the error from travis should be fixed with the latest changes too, ok
<kyrofa> olli_, so you don't actually know where you pinged unless you look through them all? Yeah I love that too
<jerryG> Chipaca: have you done a coredump ?
<jdstrand> beuno, matiasb: I just uploaded snappy-debug to the store for rolling only, and 'snap find snappy-debug' doesn't see it. is this because the device is not authenticated with the store?
<jdstrand> beuno, matiasb: it is published afaics
<plars> elopio: getting a log of errors, even if I put the testconfig.json and snaps data there: http://paste.ubuntu.com/15003786/
<jdstrand> beuno, matiasb: in the logs: snapd[3217]: 2016/02/09 18:20:36.827803 response.go:118: method "GET" not allowed
<jdstrand> beuno, matiasb: /usr/bin/snapd[3217]: daemon.go:153: DEBUG: uid=0;@ GET /2.0/snaps?q=snappy-debug&sources=store 630.821587ms 200
<elopio> plars: is that an allsnaps image generated with mvo's latest udf?
<matiasb> jdstrand, let me check
<plars> elopio: no
<plars> elopio: it needs to be in order to work?
<elopio> plars: if you have a 1504 image, you have to run the tests from the 1504 branch. If you want to run tests in rollilng, you need to use mvo's allsnaps image.
<elopio> https://people.canonical.com/~mvo/all-snaps/
<jdstrand> matiasb: thanks
<elopio> pindonga: how can I upload a snap to the edge channel?
<plars> elopio: so, the test binary I built was from ubuntu-core/snappy trunk, with your patches to enable the parameters cherry-picked on top of it
<pindonga> elopio, setting channels is not yet supported in the api, so I think you need to upload then go to the web ui and set the channels for the new verison
<elopio> pindonga: do you know if that will be ready for 1604?
<elopio> plars: yes, trunk needs allsnaps.
<pindonga> elopio, depends on how strong you can make your case for beuno  :)
<plars> elopio: ack, thanks
<pindonga> elopio, I'd start by filing a bug for it
<matiasb> jdstrand, afaict, the revno is published and it looks ok; we would need to confirm that the rolling snappy client is not sending a framework when hitting CPI <- mvo could you confirm?
<pindonga> elopio, and possibly listing all bugs related to the upload api
<jdstrand> mvo is out sick
<pindonga> so that we can see what's really missing and consider the effort
<elopio> pindonga: well, I need squashfs first autoreview first, so I won't push to much with the channel.
<pindonga> elopio, as said, autoreview depends on click-reviewers tools
<pindonga> so, not something we can change in the store itself
<jdstrand> matiasb: perhaps Chipaca could help in mvo's absense?
<elopio> pindonga: right, but is that beuno's team too?
<pindonga> not really
<pindonga> it's snappy team I think? (jdstrand, mvo, ...?)
<matiasb> jdstrand, did you get any results when searching? I mean, are you getting an old revision instead?
<elopio> oh good. So I can make the two requests in parallel to two different teams :D
<jdstrand> matiasb: no
<jdstrand> pindonga: I wasn't following the conversation. I can say that snap.yaml changes for the review tools are in progress and squashfs in the store is after that
<elopio> jdstrand: awesome!
<jdstrand> matiasb: $ snap find snappy-debug
<jdstrand> error: no snaps found for "snappy-debug"
<jdstrand> $ snap find snappy-debug.canonical
<jdstrand> error: no snaps found for "snappy-debug.canonical"
<nessita> jdstrand, you need to be running this commit of snap command (or newer) https://github.com/ubuntu-core/snappy/commit/d18e35ef719a418332cd14eb61ec3841ff2a535f
<matiasb> jdstrand, odd, everything looks ok, and hitting the index directly, the search seems to return the expected result
<jdstrand> nessita: I'm on latest all snaps images from mvo...
<jdstrand> let me see if I can determine if that is in it
<nessita> jdstrand, if you could grab the raw http request is being done, it would be helpful
<nessita> the headers being sent is key
<jdstrand> ok... tcpdump not on the device...
<nessita> jdstrand, as a summary, if your snap search is sending the framework ubuntu-core-15.04-dev1 only revnos with that framework will be returned, and revno 12 opf snappy-debug does not have any framework (which is correct)
<jdstrand> nessita: hrmm, this is https so I don't seem to be able to see the headers
 * jdstrand goes back at looking at changes in the ppa
<nessita> jdstrand, I guess source inspection with go is not possible?
<jdstrand> nessita: that is what I am doing. the current os snap has an earlier version than what is in the ppa so I'm just tracking it all down
<jdstrand> nessita: based on the diff for 1.7.3ubuntu1-1+1108~ubuntu16.04.1 , which is what is on the image, the change should be on the image
<jdstrand> nessita: could this have something to do with it not authenticating with the store, ala, that other thread?
<nessita> jdstrand, nopes, since search is anonymous: https://search.apps.ubuntu.com/api/v1/package/snappy-debug.canonical
<nessita> https://search.apps.ubuntu.com/api/v1/search?q=snappy-debug
<nessita> jdstrand, not authenticating could be a 401 when downloading the package, but this is not the case
<jdstrand> this is what I see in the log:
<nessita> jdstrand, from those package index URLs, you can see a search (with no headers) returns your package
<jdstrand> /usr/bin/snapd[3217]: response.go:118: method "GET" not allowed
<jdstrand> /usr/bin/snapd[3217]: daemon.go:153: DEBUG: uid=1000;@ GET /2.0/snaps?q=snappy-debug&sources=store 1.059970664s 200
<nessita> jdstrand, that URL is not store "server" side, may be something internal
<jdstrand> hmm
<jdstrand> I guess I'll file a bug
<nessita> the URL for searching is https://search.apps.ubuntu.com/api/v1/search?<params>
<nessita> plus headers
<jdstrand> Chipaca, matiasb, nessita: fyi, https://bugs.launchpad.net/snappy/+bug/1543731
<ubottu> Launchpad bug 1543731 in Snappy "'snap find snappy-debug' cannot find snappy-debug" [Undecided,New]
<matiasb> ack
<elopio> Chipaca: do you have the credentials of the canonical account in the store? I need it to get the spi tests working.
<jerryG> any1 been able to create coredumps successfully?
<wiggleworm> I am getting a java error when I try to start my snap - "nohup: failed to run java: no such file or directory
<wiggleworm> any thoughts on how to fix this?
<wiggleworm> Or better yet, Am i not dofing somthing correct in snapcraft?
<jerryG> kgunn: are you there?
<kgunn> jerryG: i'm literally needing to step away just now...feel free to leave query
<jerryG> kgunn: kk lol.  ill wait till tomorrow :}
#snappy 2016-02-10
<zyga> good mornig
<dholbach> good morning
<opny> hello, the maven plugin assumes  that in a target directory there have to be a jar or war after mvn package. Is there a way I can circumvent this check?
<opny> (in snapcraft)
<dholbach> opny, you could use https://github.com/ubuntu-core/snapcraft/blob/master/docs/plugins.md and copy the maven plugin to remove the check just to see if that makes it work
<dholbach> opny, maybe this should be an option in the maven plugin?
<opny> dholbach, hello, yes having it optional may be a good start. I try to add the option in the "overidden" plugin. Actually a property allowing to move custom dir/files like the filesets one would complete the loop
<dholbach> maybe you can bring up the idea on the mailing list?
<dholbach> it'd be interesting to hear what others think and how the idea could be generalised
<opny> dholbach, sure, which one?
<dholbach> snappy-app-devel@lists.ubuntu.com?
<opny> dholbach, ok
<dholbach> awesome :)
<JamesTait> Good morning all!  Happy Wednesday, and happy Plimsoll Day! ð
<noizer> HI does somebody knows how I can solve this?   u"!#$%&'*+-.^_`|~:").encode('ascii')
<noizer> LookupError: no codec search functions registered: can't find encoding
<noizer> it is with werkzeug that i have this error
<opny> Is there a method to force snapcraft to update the apt repository as listed in sources.list ?
<dholbach> opny, maybe you'd need to talk to sergiusens about reopening https://bugs.launchpad.net/snapcraft/+bug/1493081 (or https://github.com/ubuntu-core/snapcraft/issues/19)
<ubottu> Launchpad bug 1493081 in Snapcraft "Ubuntu plugin: allow downloading of binary packages from PPAs" [Medium,Invalid]
<dholbach> kyrofa, ^ do you have any idea if there was any additional discussion about this?
<opny> dholbach, thanks.. again :) I'm plagued with Hash mismatch errors which block me for hours
<dholbach> opny, I'm afraid I don't know how to work around that
<dholbach> maybe when sergiusens and kyrofa come online you can ask them
<dholbach> a quick search in the code didn't let me find anything yet
<kyrofa> Good morning
<kyrofa> dholbach, I'm afraid that was before my time-- I've not heard anything about it
<noizer> kyrofa HI does somebody knows how I can solve this?   u"!#$%&'*+-.^_`|~:").encode('ascii')
<noizer> LookupError: no codec search functions registered: can't find encoding
<noizer> it is with werkzeug that i have this error
<kyrofa> noizer, I'm sorry no, I don't know anything about that one
<kyrofa> noizer, you might consider asking in #python
<noizer> ok
<dholbach> hey sergiusens
<sergiusens> dholbach, hello
<dholbach> sergiusens, is there a way for snapcraft users to provide their own sources.list... or add PPAs or use different mirrors and stuff?
<sergiusens> dholbach, not currently; but soon we will remove just use local sources by default so it is whatever you have on your system
<dholbach> opny, ^
<dholbach> ok cool
<opny> sergiusens, dholbach thanks
<sergiusens> opny, dholbach for now there is a hidden USE_LOCAL_SOURCES you can export
<opny> sergiusens, dholbach seems like sources.list is took once and then not updated anymore..
<dholbach> ah, nice one... I saw that in the source and wondered how it'd work
<opny> sergiusens, dholbach is it like `USE_LOCAL_SOURCES=1 snapcraft` ? I cannot find it in the snapcraft source, maybe a python/apt thing
<dholbach> sergiusens, or _PLUGIN_STAGE_SOURCES?
<sergiusens> opny, dholbach sorry, it is SNAPCRAFT_LOCAL_SOURCES
<opny> sergiusens, dholbach works, perfect! Thank you :)
<dholbach> :-D
<dholbach> brilliant!
<kyrofa> Anyone else having stability problems with the dragonboard?
<ogra_> kyrofa, on what image ?
<kyrofa> ogra_, actually on the linaro Ubuntu image, so not really an Ubuntu Core question. But I find if I push it very hard for very long, it just gives up
 * ogra_ is about to finish an all-snaps one that should be stable .... my 15.04 one is clearly hacked up enough to expose instability 
<ogra_> ah
<kyrofa> ogra_, ah, I'll definitely give that a shot when it's available. I'm just worried it's a heating problem or something
<kyrofa> Can't build any good-sized snaps on it
<ysionneau> hi, how can I generate an oem snap? Do I need to use snapcraft?
<ogra_> i dont think we have oem plugins yet ...
<ogra_> also note that oem snaps are 15..04 only ... we switched to a different setup with "gadget" snaps in 16.04
<ysionneau> type: oem does not seem to work indeed it tells me "you need either app or framework"
<ysionneau> oh
<ysionneau> I'm following the documentation for "how to port snappy to your platform"
<ogra_> yeah, thats still 15.04
<ysionneau> https://developer.ubuntu.com/en/snappy/guides/porting/
<ysionneau> ok
<ogra_> 16.04 is to much in flux still .... we're in the middle of switching the whole image design to a "all snaps" setup
<ysionneau> It seems I need the oem snap in order to do the ubuntu-device-flash command to generate the image
<ysionneau> oh
<ysionneau> interesting
<ogra_> right
<ysionneau> so, how am I supposed to generate the oem snap?
<ogra_> ysionneau, we store the official code for the oem/gadget snaps at https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems ... for 15.04 you would have to go a bunch of revisions backwards in the commits though
<ysionneau> oh right, there are the snap.yaml files in there
<ysionneau> type: gadget
<ysionneau> hmmm
<ogra_> yeah, you will have to go back through the history to get to package.yaml and 15.04 setup
<ysionneau> ah, if I go back in time indeed I get the package.yaml files
<ysionneau> I'm especially interested in the arm64 stuff, so dragon I guess
<ysionneau> rev 18 seems interesting
<ysionneau> since rev 19 renamed package.yaml to snap.yaml
<ogra_> ysionneau, http://people.canonical.com/~ogra/snappy/dragonboard/
<ogra_> thats a very hackish 15.04 image
<ysionneau> thanks!
<ogra_> thogh 15.04 has issues that will likely not get fixed
<ogra_> (on the dragonboard specifically)
<ogra_> focus is on 16.04 only
<ysionneau> hmmm ok
<ysionneau> maybe I should switch to 16.04 then
<ogra_> yeah
<ysionneau> I'm wondering, now that I have that package.yaml
<ysionneau> I still don't understand how to generate the oem.snap :p
<ogra_> i'm waiting for a final kernel build and should have some test image ready later today
<ysionneau> snapcraft is searching for snapcrafy.yaml
<ysionneau> -y
<ysionneau> ah good news!
<ogra_> yeah, we dont use snapcraft for oem/gadget ... but "snappy build" directly
<ysionneau> ah great, it worked :)
<ysionneau> thanks
<ysionneau> now I get "Signature verification failed" :'
<ysionneau> while doing the ubuntu-device-flash
<ogra_> you need to use --developer-mode
<ysionneau> btw, 16.04 is devel ? devel-proposed ?
<ogra_> else it wont allow your own oem/gadget
<ogra_> 16.04 is rolling/edge
<ogra_> (release is rolling, channel is edge)
<ysionneau> ogra_: did you ever tried to run your dragon snappy system on qemu?
<ysionneau> try*
<ogra_> does qemu support arm64 yet ?
<ysionneau> yes
<ogra_> (and does it emulate the dragon ?)
<ogra_> no, i never tried
<ysionneau> it does not emulate the dragon specifically
<ysionneau> I cannot see any arm64 emulated boards
<ysionneau> but you can do something like -M virt -cpu cortex-a53
<ysionneau> and such
<ogra_> well, i doubt that works with the dragonboard specific kernel
<ysionneau> http://www.bennee.com/~alex/blog/2014/05/09/running-linux-in-qemus-aarch64-system-emulation-mode/ < like this
<ysionneau> but you don't need to compile your own qemu
<ysionneau> it worked on my debian testing with official debian qemu package
<ogra_> with a dragonboard kernel ?
<ysionneau> nop
<ysionneau> I don't even know how this guy generated his kernel (with which config)
<ogra_> right, most likely just some generic arm64 thing
<ysionneau> yeah I guess
<ysionneau> maybe I can just use the dragon snappy image, but use my generic aarch64 kernel
<ysionneau> so that it can run in qemu
<ysionneau> or I should just generate my own system image
<asac> hmm. i have a rolling all-snaps image from the 8th january ... do i need to reinstall to get back on latest rolling lane?
<asac> my image doesnt update
 * asac just goes and installs latest https://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz
<ogra_> asac, yeah, i dont think they update yet
<asac> guess they changed names :
<asac> )
<asac> of snaps like ubuntu-core
<ogra_> (and we have no auto-builds that would submit the snaps to the sotre yet .... all manual)
<asac> will see once its booted
<asac> hmm
<asac> ok
<asac> well, thats fine. let me see what i find here on the 4th feb image i guess
<asac> interesting that bbb is 40M igger than pi2 image
<asac> guess pi2 isnt a full blown kernel?
<ogra_> it is
<ogra_> but a smaller initrd
<asac> hmm. ok. different config?
<asac> or how did this end up being different?
<asac> anyhopw, i am on pi2 anyway so dont mind smaller footprint
<ogra_> simply doesnt pull in as many modules
<ysionneau> is there online documentation about the new "all-snaps" architecture?
<ogra_> (and yeah, i guess there are less built ... effectively you mostly only want USB stuff that you can plug in)
<sergiusens> kyrofa, elopio be there in 2
<kyrofa> sergiusens, sounds good
<asac> ysionneau: i dont think there is... buut summary is that everything is now snaps. anything specific you want to know?
<asac> dholbach: think good clinic topic would be to make overview of all-snaps when mvo is back
<kyrofa> jdstrand, is access to /proc/<pid>/statm a risk? (denied in 15.04)
<elopio> fgimenez: my deploy got stuck stoping jenkins-master-service. Did you do one?
<ysionneau> nothing specific, it's just that I'm very beginner with ubuntu snappy stuff
<ysionneau> so I feel more confortable using something documented
<dholbach> asac, yes - that's noted down and requested already
<ysionneau> root@imperium:/home/yann/dev/snappy# ls -l my-snappy.img
<ysionneau> ls: cannot access my-snappy.img: No such file or directory
<ysionneau> oops
<jdstrand> kyrofa: looks fine to me
<asac> dholbach: cool!
 * jdstrand adds it
<dholbach> asac, niemeyer and mvo just seemed very busy lately - so I didn't get a date from them yet
<ysionneau> http://pastebin.com/0u4f92Xc < any idea why this fails?
<asac> dholbach: fine
<asac> just keep nagging... guess after sprint might be better time
<jdstrand> kyrofa: what is requesting the access (trying to decide if in default or a cap)
<asac> ysionneau: you cannot use tarballs as device parts anymore... needs to be snap. check with ogra
<jdstrand> oh, status is basically the same info
<jdstrand> ok, default profile
<elopio> plars: http://pad.ubuntu.com/spi I started updating the stuff, with a little bit of problems.
<plars> elopio: oh, I've done none of that yet on my side
<ogra_> ysionneau, right, like asac says, all-snap means that everything is a snap .... rootfs, kernel, gadget (oem)
<ogra_> ysionneau, the 15.04 setup still uses the phone based tarball system-image setup
<plars> elopio: for authorization stuff, you'll need to contact ev's team I think
<elopio> plars: yes, I'll be talking to them today.
<elopio> plars: from your side, we need to be able to call the all-snaps udf.
<ogra_> ysionneau, try using the oem snap from my image ...
<ysionneau> ogra_: ok thanks
<elopio> plars: maybe if we include the binary name, not just "udf-params"
<ogra_> oh, annd the dragonboard setup has a very specific partitioning for the bootloader ... that requires the very latest ubunu-device-flash from xenial
<ysionneau> 15:37 < asac> ysionneau: you cannot use tarballs as device parts anymore... needs to be snap. check with ogra < which means the documentation is wrong? :o
<ogra_> ysionneau, the documentation refers to 15.04
<asac> right
<ysionneau> yes, which is what I'm using right now
<ogra_> it will be changed once all-snaps is the default
<asac> ysionneau: i would suggest to stick to 15.04 for now
<asac> if you are new
<ogra_> if you build for 15.04 you can indeed use tarballs
<asac> bc there is lots of stuff landing as we speak on trunk
<asac> so if you are not yet deep in this topic it will be rough at best :P
<ogra_> but i dont think you will get a dragon image to work with 15.04
<ysionneau> so since I'm targeting 15.04 in my pastebin, any idea why it does not work?
<ogra_> there are various issues with that
<ysionneau> ah
<ogra_> (as i said earlier)
<plars> elopio: is there a cheat sheet for how to build all the all-snaps images using the all-snaps udf?
<ysionneau> what you say about "dragon image" is also true for any arm64 image?
<ysionneau> the fact that it would not work for 15.04
<ogra_> no
<plars> elopio: and can you confirm if I really need to be on xenial to build all-snaps images or not? I remember you mentioned that before, but I thought it was unconfirmed at the time
<ogra_> generic arm64 might work or not
<ogra_> the specific dragnboard setup will definitely not work though
<ysionneau> ok
<ogra_> so you can try a aemu arm64 image based on a generic kernel ... but YMMV ... i dont thinnk anyone actually tested arm64 on 15.04
<ogra_> *qemu
<ysionneau> hmm hmm ok
<ysionneau> understood
<fgimenez> elopio, nope, your's finished after all
<noizer> Hi how can I force delete an application. Because when I'm trying. it says read only permission or something
<jdstrand> kyrofa: I'm going to upload this in a few minutes, but I don't know when the next image will be spun. I believe one is undergoing testing to pull in security updates, so the next one may not have this unless they respin (or you ask them to respin)
<kyrofa> jdstrand, woo! Excellent news, thank you :)
<asac> hmm. snappy search command doesnt exist right now on 16.04?
 * asac installs bluez5 out of the blue
<jdstrand> asac: snap find foo
<jdstrand> I don't know the reasoning behind that, but came across it
<elopio> fgimenez: no, it's missing one slave.
<asac> good... i looked at snap command
<elopio> I'll retry.
<asac> but missed that find thingy
<asac> thanks jdstrand
<jdstrand> np
<asac> snap find bluez5 yields nothing
<asac> guess store is borked?
<asac> snap find bluez
<asac> error: no snaps found for "bluez"
<asac> ubuntu@localhost:~$ snap find bluez5
<asac> error: no snaps found for "bluez5"
<asac> ubuntu@localhost:~$ snap find hello
<asac> error: no snaps found for "hello"
<asac> ok let me find a bt dongle ... /me hopes he can find those mini things
<ogra_> asac, 90% of the store snaps cant run on 16.04 anyway ... until they are converted to squashfs
<ogra_> might be that the store now finally filters them
<ogra_> (snappy install falls over on the click legacy during install for most of them)
<asac> ok this is not looking good
<asac> let me order a new one
<ogra_> no beer before 5 !
<asac> hehe
<asac> i wish
<asac> so what cool BLE device could i buy? guess just a dongle wont make it
<ogra_> asac, http://www.amazon.de/Satechi%C2%AE-Bluetooth-Button-Kompatibel-Cortana/dp/B012OWC5NQ/ref=sr_1_4?ie=UTF8&qid=1455117712&sr=8-4&keywords=BLE+bluetooth
<ogra_> or http://www.amazon.de/Satechi%C2%AE-Bluetooth-Button-Series-Samsung/dp/B00RM75NOW/ref=pd_cp_23_2?ie=UTF8&refRID=0SA6C938R1PRR0S634S7
<asac> lol
<asac> a bt button
<asac> always wanted that :0
<asac> ok ordered :)
<asac> lol
<jdstrand> kyrofa: 15.04.12~ppa17 uploaded to the ppa
<jdstrand> (ubuntu-core-security)
<kyrofa> jdstrand, awesome, thanks
<ogra_> ppisati, FYI ... boots perfect with the new DT
<ogra_> thanks a lot
<ogra_> !
<ppisati> ogra_: yeaaaaaaahhh! :)
<ppisati> ogra_: as soon as i have some time, i'll try to debug what was going on with the old dtb
<ogra_> yeah
<ogra_> it is weird that we dont see it everywhere
<ppisati> yes it is
<jdstrand> kyrofa: and ubuntu-core-security 16.04.15 uploaded to xenial
<kyrofa> Thanks jdstrand!
<sergiusens> elopio, kyrofa reviewzzzz :-)
<kyrofa> elopio, did you say the maven PR was good?
<elopio> kyrofa: I did, yes. But sergiusens changed everything. I'm looking again.
<jdstrand> zyga: dumb question-- I'd like to review the entire PR as it stands now (ie, with all of your changes) in github. how do I do that?
<jdstrand> I feel like I found it yesterday, but I can't seem to today
<jdstrand> oh, Files changed
<jdstrand> ok
<jdstrand> zyga: nm
<elopio> ev: noise][: can you help me today with spi?
<zyga> jdstrand: hey
<zyga> jdstrand: :D
<zyga> jdstrand: ping me if there are tests missing
<zyga> jdstrand: I think you asked for one more but I'm not sure
<joc__> elopio: hi, we're making some good progress on running the snappy tests from checkbox
<elopio> joc__: awesome!
<joc__> elopio: last few failing tests are printing "Error: aa_change_onexec failed with -1. errmsg: Permission denied
<ev> elopio: hey, whatâs up?
<joc__> elopio: are they expecting to be run with sudo?
<jdstrand> zyga: I think we are good (gave +1)
<jdstrand> zyga: thanks!
<elopio> joc__: they should have permission to run sudo, but the scripts themselfs add the sudo command when required. That's more likely that you have an outdated allsnaps image.
<kyrofa> sergiusens, any idea why all-snaps doesn't have /etc/protocols?
<elopio> joc__: I was looking at this yesterday: http://bec-systems.com/site/942/running-a-reboot-cycle-test-shell-script-with-systemd
<elopio> we could use it to test reboots without adt-run. It would be a lot more complex than what we have now, though.
<elopio> seems easier to do adt-run with the nil testbed, so it runs in the same host.
<joc__> elopio: i wrote some stress-tests that do almost exactly that in checkbox
<elopio> ev: hey. I got two errors here: http://pad.ubuntu.com/spi
<elopio> In the current section.
<joc__> elopio: they arent great though as you can't receonnect to them from a user session
<joc__> elopio: but they allowed us to atleast set up warm boot / cold boot stress tests
<plars> elopio: did you see my questions earlier about building images? in particular, for x86?
<ysionneau> in ubuntu-device-flash , the --oem is supposed to be the path to the .snap ? or the path to the source of the oem package (the directory containing the meta directory)?
<sergiusens> kyrofa, should I name it 2.1.2? I already have, but seem to regret it a bit
<plars> elopio: also, how much concern do you have for testing older pre-allsnaps images across supported platforms? I'm tempted to just move everything to the new tool except for specific platforms that generally need the older image
<elopio> plars: sorry, I didn't. zyga said he's writing a cheat sheet for all snaps, or that's what I understood.
<sergiusens> kyrofa, no idea; but why should it be there for you?
<plars> elopio: ack
<sergiusens> need to resolve a proto name?
<elopio> plars: and it doesn't need to be xenial. What I said is that the new ubuntu-image will be xenial only.
<kyrofa> sergiusens, for getprotobyname and associated calls
<plars> elopio: I found what to do for rpi2, and I can see from your pastebin how to do it for bbb, but I'm interested in db410c and x86 too
<sergiusens> kyrofa, so I bet netbase is installed; ogra_ clues?
<kyrofa> sergiusens, regarding the version, wouldn't 2.2 be more correct since you have the --output feature?
<zyga> jdstrand: perfect, thank you :)
<elopio> plars: for db ask ogra_. For x86, maybe he'll know too.
<sergiusens> kyrofa, there
<noise][> elopio: hey, missed your ping earlier, what can I help with?
<sergiusens> kyrofa, netbase is not in the manifest http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<sergiusens> kyrofa, you can ask ogra to seed it I guess
<elopio> plars: and if it makes things easier, just don't worry at all about 15.04 images. Our main focus is 16.04.
<kyrofa> sergiusens, thanks :) . ogra_ how would you feel about that?
<elopio> hey noise][. Pasting the message again: I got two errors here: http://pad.ubuntu.com/spi
<elopio> In the current section.
<kyrofa> ogra_, it was in 15.04... was it removed for a reason?
<ev> elopio: authorisation is keyed on permissions to snaps now, rather than organisation keys: https://spi.canonical.com/assets/tutorial.html#creating-a-product
<ev> https://spi.canonical.com/assets/tutorial.html#testing explains how to set up that gold master test
<ogra_> kyrofa, i didnt explicitly remove it ... weird ... yeah, we can add it bacjk
<ogra_> kyrofa, btw, see my dragonboard mails ... image is up
<sergiusens> ogra_, maybe related to the 'one seed to rule them all' thread?
<kyrofa> ogra_, I saw that, thank you :)
<ogra_> sergiusens, i dont think anything changed yet
<ogra_> though i might be wrong, seems severakl teams now tinker with that, could be that slangasek already started with some changes that i missedf
<ogra_> plars, i only heard this week that x86 will be a supported target, i'll work on it alongside with enabling the arm64 builds for the db
<noise][> elopio: checking..
<kyrofa> ogra_, hmm... should we talk to some about adding it back, then? Or do you think it's safe?
<ogra_> kyrofa, lets wait for slangasek, i dont want to mess up anything he is currently fiddling with ... apart from that, yeah, i think we should add it back
<kyrofa> ogra_, alright sounds good. Thank you!
<ogra_>  /etc/services and /etc/protocols is definitely something we should have :)
<kyrofa> Agreed
<kyrofa> Took me a while to trace my segfault back to that
<ysionneau> http://paste.ubuntu.com/15009577/ any idea? ( I'm using the bzr rev12 of snappy-systems for the oem package of beagleblack)
<didrocks> Do you know where the webdm code is? I would have expected it to be on https://github.com/ubuntu-core
<ogra_> didrocks, m,ost likely on launchpad
<ogra_> didrocks, only snappy and snapcraft moved to github
<didrocks> oh right, for some reasons, I thought https://code.launchpad.net/~snappy-dev/webdm/trunk was old
<dholbach> didrocks, https://code.launchpad.net/webdm
<ogra_> afaik
<didrocks> yeah, thanks ogra_ & dholbach :)
<didrocks> interesting, it doesn't use snapcraft (yet ;))
<sergiusens> elopio, pushed now, I had addCleanup which took care of os.environ afaik, but since you love fixtures, it is there now
<sergiusens> didrocks, because of multi arch
<sergiusens> didrocks, now that that is there it can migrate
<didrocks> excellent!
<noise][> elopio: i'm able to repro that error, digging now to see why
<elopio> sergiusens: ah, I didn't see that and it was just one line above :) But yes, I prefer fixtures.
<elopio> sergiusens: missed one: os.environ['SNAPCRAFT_SETUP_PROXIES'] = '1'
<sergiusens> strange
<elopio> that's twice actually.
<sergiusens> elopio, oh, I didn't push :-p
<sergiusens> well, I didn't commit to be precise
<sergiusens> done
<plars> noise][: do we have to specify a primary snap to base the "product" around? What if we just want to test the base image by itself?
<elopio> as I understood, that's just for authentication. So I used a dummy snap of mine.
<elopio> I might be wrong, of course.
<noise][> right, the primary snap is for authz
<elopio> sergiusens: just the two os.environ['SNAPCRAFT_SETUP_PROXIES'] = '1', and then you are free to go.
<plars> noise][: elopio: so to test the image, I have to create a dummy snap that I have no intention (or desire) of actually installing, and everything is dependent on updating that snap?
<elopio> I wonder if useFixture works on a @classmethod. umm...
<sergiusens> elopio, oh, right
<slangasek> ogra_: hi, I don't think I have context for these highlights
<elopio> plars: no, it is dependent on the list of snaps you use. Which don't need to be yours.
<ogra_> slangasek, snappy seeds ... did you cahnge anything for them yet ?
<plars> elopio: but one of them does, right?
<slangasek> ogra_: no, what are you expecting to be changed?
<sergiusens> elopio, is this needed at all http://paste.ubuntu.com/15009708/ ?
<sergiusens> elopio, and will that work?
<ogra_> slangasek, well, there was some discussion to base them on lxc seeds ort some such ...
<ogra_> *or
<noise][> plars: primary_snap needs to be owned or shared with you
<elopio> sergiusens: to be safe, I would put it in the SetUp.
<slangasek> ogra_: I'm not sure I was part of any concrete discussion about this
<ogra_> slangasek, natbase seems to be gone from snappy in 16.04, i was asked to put it back, i just wanted to make sure i'm not stepping on your toes here
<ogra_> *netbase
<slangasek> we certainly shouldn't have lots of different parallel seed definitions, but I'm not driving anything here currently, no
<ogra_> ok, good
<elopio> sergiusens: and maybe it's not needed to clean it up, as all the examples tests will need the proxy. But I've gone mad a couple of times because of environment variables that I'm not sure where are set. That's why I started liking fixtures.
<sergiusens> elopio, yeah, that's why I didn't worry about cleanup here
<sergiusens> elopio, in anycase, pushed
<elopio> sergiusens: thanks. Land whenever you want.
<sergiusens> elopio, when testing finishes of course ;-)
<elopio> fgimenez: the sync has been here for a long long time: https://paste.ubuntu.com/15009722/
<elopio> is it normal?
<noise][> elopio: aha!  s/rolling/rolling-core in your "release"
<elopio> noise][: what? I didn't know rolling-core was a thing.
<elopio> I'll update it.
<noise][> elopio: I'm just going by what data is actually in the store/CPI
<noise][> for those snaps you list it's rolling-core
<elopio> noise][: thanks for digging it out.
<noise][> y, sorry that error message isn't very good
<fgimenez> elopio, i don't think so, that should be the final step, after all the files has been copied right?
<elopio> fgimenez: I don't know. The jenkins page is down.
<elopio> if I ctrl+c and sync again would I just break it all?
<fgimenez> elopio, :) i think that it would be better to try to restart the docker service, it seems to be broken somehow, anyway compose will simplify this (that's my moto)
<elopio> fgimenez: killing and retrying is my motto :p
<elopio> restarted. I can't even run docker ps.
<elopio> I'll do it all over again.
<fgimenez> elopio, wait, docker ps is working
<fgimenez> elopio, np :)
<elopio> fgimenez: yeah, too late.
<kyrofa> ogra_, just read the scrollback. netbase sounds okay to add back then, it seems?
<ogra_> kyrofa, yeah, i'll update that tomorrow if thats sufficient
<kyrofa> ogra_, perfectly :)
<kyrofa> ogra_, thank you!
<fgimenez> elopio, all the containers were there http://paste.ubuntu.com/15009811/ anyway we could replace restarting them with the service restart in the sync script if you find problems again
<kyrofa> elopio, re: rolling vs. rolling-core, remember there's rolling-personal as well
<elopio> let's see how it goes now.
<elopio> kyrofa: ahh
<sergiusens> elopio, kyrofa https://github.com/ubuntu-core/snapcraft/pull/311
<jdstrand> JamesTait: hey-- not trying to create more work for you but I did a refactor branch and have one ACK, which would normally be enough for me to push. were you planning on looking at it more?
<jdstrand> JamesTait: I'm not blocked
 * zyga thinks that https://github.com/zyga/devtools/ is now useful for snappy development in general
<elopio> plars: ^ a temporary ubuntu-image.
 * sergiusens notes that zyga has become the ubuntu-image owner ;-)
<plars> elopio: I know, I saw... I'd prefer just a cheatsheet of the cli args, but I have that now :)
<elopio> it was a trap
<plars> haha
<zyga> plars: the cli will probably change
<zyga> (over time)
<sergiusens> elopio, great https://launchpadlibrarian.net/237772709/buildlog_ubuntu-xenial-amd64.snapcraft_2.2_BUILDING.txt.gz
<sergiusens> elopio, I need to 'unset' the no_proxy var as well :-/
<elopio> sergiusens: I think that if you pass None to the fixture it will remove it.
<sergiusens> elopio, too bad I merged the changelog...
<sergiusens> elopio, should I create 2.2.1 or should I create a PR that fixes this and still considers it 2.2?
 * kyrofa wouldn't look if sergiusens rebased the changelog
<sergiusens> kyrofa, nah, not for this
<elopio> sergiusens: you can modify the master commit, right? Just reset one change.
 * sergiusens ponders splitting up the packaging branch
<kyrofa> Yeah I say fix it for 2.2 the move the changelog commit
<elopio> sergiusens: I thought you were waiting for my +1 to merge that :D
<elopio> also I wonder why travis doesn't fail.
<sergiusens> elopio, because it doesn't set a no_proxy ;-)
<sergiusens> elopio, I didn't know I was waiting for your +1 fwiw
<plars> noise][: I logged in, generated the config.ini, but I get 401 when I try a similar product creation to what leo did: http://paste.ubuntu.com/15010644/
<elopio> kyrofa: sergiusens: I reported three bugs for the failing examples. These are not related to our release, so I was about to +1 the changelog.
<sergiusens> elopio, kyrofa quick hangout; irc feels like broken telephone
<sergiusens> ?
<elopio> okay.
<noise][> plars: and you own that primary snap?
<plars> noise][: the user I'm trying to login as does, yes... but maybe that's the problem if it's really checking. It probably isn't published yet
<plars> noise][: I need to wait for approval I guess?
<noise][> plars: yeah, has to exist in CPI, thus be published
<plars> ok
<kyrofa> sergiusens, I can't at the moment, but if you guys go ahead I'm happy with whatever you decide
<noise][> plars: "./scripts/api_example.py config.ini https://spi.canonical.com/products" will spit out the list of "packages" that you have access to
<plars> noise][: I can't see that until I register the product as above though, right?
<plars> right now, it's an empty set, because I wasn't authorized to register the product yet, since the snap is not yet published
<noise][> plars: i think that should give you the list of all published packages you own or have shared access to
<noise][> regardless of having created a product yet
<plars> noise][: ah, ok
<noise][> the endpoint returns a dict w/2 top fields: packages, products
<plars> noise][: I would have assumed it's only the set of products I've created
<plars> I see
<noise][> yeah, the packages part if just a bonus :)
<sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/312
<elopio> sergiusens: +1. Now another for the changelog?
<elopio> I'm hungry! :D
<sergiusens> elopio, oh, we don't need one is what I thought
<elopio> sergiusens: ah, right, no problem.
<elopio> merged. Ping me on telegram if you need me.
<sergiusens> elopio, built fine https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+packages?field.name_filter=snapcraft&field.status_filter=published&field.series_filter=xenial
<sergiusens> now let's hope that adt works for at least amd64
<sergiusens> kyrofa, feel free to edit for clarity https://launchpad.net/snapcraft/+milestone/2.2 (the Release Notes that is)
<sergiusens> don't change bug status yet
<sergiusens> as we haven't migrated from proposed still
<sergiusens> jdstrand, hey, at your leisure, can you look at https://bugs.launchpad.net/snapcraft/+bug/1544249 ?
<ubottu> Launchpad bug 1544249 in Snapcraft "mosquitto example fails to start" [Undecided,New]
<jcastro> If I wanted to track development with a spare machine I just dd mvo's all-snap image onto a disk right?
<sergiusens> jcastro, yes
<sergiusens> elopio, new set of errors FAILED (failures=1, errors=14, skipped=2)
<JamesTait> jdstrand, thanks for doing that, I'd missed the new branches.  Taking a look now.
<sergiusens> elopio, I'm giving adt some more importance, so I might fix these tonight https://launchpad.net/snapcraft/+milestone/2.2.1
<JamesTait> jdstrand, first branch +1'd.
<jdstrand> JamesTait: thanks!
<jdstrand> JamesTait: fyi, about to head out, but the 3rd branch while 'work in progress' is only missing the 5 TODO tests at the bottom of sr_lint.py
<JamesTait> jdstrand, *so* much cleaner, thanks for breaking it up, and apologies for the extra work.
<jdstrand> JamesTait: glad it helped. the exercise actually helped me spot a few things
<jdstrand> I'm working on those 5 tests now, but won't be done with those and tests before eod
<JamesTait> jdstrand, now I don't feel so bad. ð
<jdstrand> but there is a lot to review in that branch if you want to get a head start
<JamesTait> jdstrand, that's fine, I can take a look in the meantime and finish the review when you're done.
<jdstrand> cool
<JamesTait> It's not blocking me, and I'm out Friday and Monday.
<jdstrand> me too :)
<JamesTait> Yay for long weekends! D
<JamesTait> Gah, I hate this keyboard. :-/
#snappy 2016-02-11
<dholbach> good morning
<zyga> good morning
<JamesTait> Good morning all!  Happy Thursday, and happy Get Out Your Guitar Day! ð
<diwic> hi, I'm having trouble with my mirror, can I redirect snapcraft 2.2 (when pulling) to use the main archive instead?
<asac> whats the new SNAP_APP_DATA_PATH env?
<asac> hm. guess i would need to upload hello world again
<asac> didrocks: you made a central place for examples in github right?
<diwic> okay, the mirror is up again now
<noizer> Hi guys is nginx supported on snappy?
<ogra_> Chipaca, tickle
<ogra_> noizer, if you manage to package it, it is supported :)
<noizer> nicee :D just i can't get it started xD
<noizer> ogra_ where can we find the image for the dragonboard for snappy?
<ogra_> are you not on the mailing list ?
<noizer> oooh ok sorry i didn't have time to look at it the last couple of days
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/
<ogra_> i mailed yesterday ;)
<ogra_> (snappy-devel that is)
<ogra_> as for ngnix ... i think the spreedbox guys use it in their spreedbox snap in the store
<ogra_> no idea where their code is (and this is for 15.04 only iirc)
<ogra_> you could install their snap on a 15.04 armhf install and inspect the installed snap though
<noizer> ok thx ogra_
<Chipaca> ogra_, tockle
<sergiusens> asac, he has, but it seems bare bones now https://github.com/ubuntu-core/demos
<ogra_> Chipaca, damn, i forgot what i wanted to ask you now :(
<Chipaca> ogra_, \o/
<ogra_> Chipaca, oooh ... ubuntu-snappy ftbfs on arm64 since a while again, i need to re-build images after fixing the resizing for dragonboard setups
<ogra_> would be good if someone could take a look (and since mvo is away ...)
<Chipaca> ogra_, ouch
<Chipaca> i'll take a look in a bit
<ogra_> thanks ... take your time though ... i'm still working on the resize fixes
<asac> sergiusens: ok thats demos then... guess moving snappy-examples to 16.04 in its current place is worthwhile then still...
<didrocks> asac: yeah, it needs sorting, and it quite empty, but it should be a central place
<didrocks> the difference I see is that demos will be more complete real pieces
<didrocks> and snapcraft should keep examples separated
<didrocks> (as more "simple way of doing X")
<zyga> noizer: try https://github.com/zyga/devtools/blob/master/ubuntu-image and tell me if it works for you
<noizer> zyga what is that?
<noizer> is that for the dragon board or is that for my nginx
<joc__> ogra_: hi, i'm trying to boot the new all-snap dragonboard image, but i'm not seeing any output on hdmi. do you have any ideas on why not?
<joc__> ogra_: same setup works ok with the install image from 96board website
<ogra_> joc__, because the boot console still points to serial ... once it booted you should get a login prompt on hdmi though
<ogra_> (i definitely do here)
<ogra_> joc__, also regard the big fat warning in the readme
<ogra_> (to not use a card bigger than 4GB)
<joc__> ogra_: will it resize and reboot before the hdmi login prompt?
<ogra_> it resizes before it mounts anything
<ogra_> (so thats a yes)
<ogra_> i'm hoping to have that bit fixed today :)
<joc__> ok thank you, plars was saying that he had one successful boot before the resize would stop his board working so I was hoping for that - he may have been using serial though
<sergiusens> kyrofa, when you get on, mind looking at https://launchpad.net/snapcraft/+milestone/2.2.1 ?
<ogra_> joc__, i havent tried booting without the serial board attached, perhaps that blocks somewhere else though ...
 * ogra_ gives that a try 
<zyga> noizer: that's for building images easily
<zyga> noizer: including dragonborad
<noizer> zyga can I make then custom images for myself?
<noizer> zyga ps I will first make my nginx up and running
<noizer> Who will also join the clinic tommorow?
<zyga> noizer: depends on what you mean by custom
<zyga> noizer: anyway, have a look, the tool is _tiny_
<noizer> zyga ok
<ogra_> joc__, hmm, yeah, looks like it hangs somewhere at the bootloader if the serial board isnt attached ....
<kyrofa> Good morning
<ogra_> joc__, so for now, please attach the serial board, i'll research that
<noizer> Good morning kyrofa
<kyrofa> sergiusens, what should I be looking at here?
<didrocks> good morning kyrofa!
<sergiusens> kyrofa, the PRs :-)
<kyrofa> Hey noizer, didrocks :)
 * sergiusens needs to go to the bank, will bbl
<kyrofa> sergiusens, ah, that's what I'm on now
<kyrofa> sergiusens, alright, seeya!
<noizer> ogra_ What is the name of the application of spreedbox?
<ogra_> noizer, spreedbox :)
<ogra_> (iirc )
<noizer> kyrofa Hi do you know where I can get more information about netwerk listeners etc
<ogra_> ppisati, did you ever try to boot without serial board attached ? seems it hangs at the bootloader
<kyrofa> noizer, you mean what permissions are encompassed by it?
<noizer> yes
<ogra_> ppisati, dragonboard that is
<ppisati> ogra_: uhm no, i never trie
<ppisati> d
<ppisati> let me tru
<ppisati> let me try
<noizer> kyrofa its for the rolling version. Or will it be explained tomorrow on the clinic?
<ogra_> seems to not be kernel related ... i just did set console=tty0 and it still hangs
<noizer> ogra_ I installed the 15.04 version on my Raspberry Pi 2 and tried to install spreedbox with the following command: sudo snappy install spreedbox but he dont find it
<ogra_> ppisati, wow .... trying to set "stdin, stdout or stderr" at the uboot prompt with setenv actually complains
<ogra_> i cant set it to serial,lcd
<kyrofa> noizer, I'm not aware of any documentation on each one. jdstrand might know more
<ppisati> ogra_: ## Error inserting "stdin" variable, errno=22
<ppisati> :O
<ogra_> yeah
<ogra_> i know i can set that var on the rpi
<ogra_> i did that multiple times
<ppisati> ogra_: i was using https://github.com/hallor/u-boot.git / dragonboard-for-mainline-v2
<ppisati> ogra_: i just did a git fetch, and there's a 'dragonboard-for-mainline-v3'
<ppisati> let's see
<ogra_> ah
<ogra_> though i fear there is some build time hardcoding going on here
<ppisati> ogra_: same story, doesn't boot and you can't set stdin&c
<ogra_> yeah, i suspected that
<ogra_> i just pinged in #96boards ... lets see, perhaps a known issue
<Chipaca> ogra_, i can't find the build failure email, could you fwd it me?
<ogra_> i have to dig it up
<ogra_> Cghbtw, vivid failed too (on arm64, powerpc and ppc64el)
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<ogra_> arm64 xenial is here https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/8962323
<ogra_> => setenv stdout serial,lcd
<ogra_> ## Error inserting "stdout" variable, errno=22
<ogra_> => setenv stdout serial
<ogra_> =>
<ogra_> ppisati, ^^^
<ogra_> so its the parameter
<ogra_> just setting it to serial works
<ppisati> oh ok
<noizer> kyrofa did you already installed an apache in a snap?
<ogra_> i guess we miss a build time option somewhere in uboot to enable lcd at all
<kyrofa> noizer, indeed, yes
<kyrofa> noizer, that owncloud snap uses apache
<ogra_> though i still dont get why it hangs hard ... it shoudlnt
<diwic> general question: if the app has some files in /usr/share/ - but with snappy, they're instead in $SNAP/share or $SNAP/usr/share, what's the smartest way to have the app (or one of its library dependencies) look there instead of in /usr/share ?
<noizer> kyrofa owkay i will look for the yaml because I can't run nginx :s
<kyrofa> noizer, how come?
<kyrofa> noizer, I can share my plugin with you if you like
<noizer> yea i would like that maybe i can get some info for my nginx from there
<kyrofa> noizer, alright. It's still a work-in-progress, no decent documentation or anything, but it works: https://github.com/kyrofa/owncloud-snap/blob/apache_plugin/parts/plugins/x_apache.py
<ogra_> ppisati, ah, seems we just need to set CONFIG_LCD in dragonboard.h
<noizer> kyrofa You didn't installed it with stage-packages? why?
<kyrofa> noizer, you give it a source (like any other plugin) and it'll unpack it into htdocs. You also specify the modules you want built/enabled, and you can specify some sections of the config and a startup script if you want
<kyrofa> noizer, because debian packaging uses a different apache layout than the standard, and it's all setup in a post-inst
<kyrofa> postinst, rather
<noizer> kyrofa ok.
<kyrofa> noizer, since Snapcraft only unpacks debs, that stuff never gets run
<kyrofa> noizer, so it led to a lot of hackery. Not to mention this way I could tune it exactly the way I wanted and get it down to a few megs
<noizer> so nginx won't run with the deb package?
<kyrofa> noizer, it might, it might not. Depends on how it's packaged
<ppisati> ogra_: let m,e try that
<kyrofa> noizer, that was the first lesson I learned making that massive snap: debian packages only get you so far in snappy
<noizer> ok so maybe the best way is from source code.
<kyrofa> noizer, indeed
<noizer> kyrofa, ok thats a lot harder then using a deb package :p
<noizer> kyrofa lets give it a try
<kyrofa> noizer, yeah it's a bit complex. Apache was particularly painful because it writes its prefix _everywhere_, config files, scripts, etc
<noizer> hopefully is nginx not so painful :p
<ppisati> ogra_: nope, it doesn't compile with only CONFIG_LCD
<kyrofa> noizer, heh, good luck
<noizer> kyrofa thx. if I succeed maybe then i will post an easy example of it for other users of Snappy
<ogra_> ppisati, how does it fail ?
<kyrofa> noizer, the way snapcraft works requires software that can be configured and built in one location, and run in a complete different location, with different paths. Some software works fine that way. Some though, like apache, do not
<ppisati> ogra_: http://pastebin.ubuntu.com/15015948/
<ppisati> ogra_: CONFIG_LCD is just the machine independent code, every hw needs some specific bits to make it work
<ogra_> crap
<ppisati> ogra_: we should talk to guy who ported uboot to this board
<ogra_> ppisati, thats hallor in #96boards i think
<noizer> kyrofa is that not a good idea to use docker in the snap. Because docker have already a build with nginx?
<kyrofa> noizer, hmm... I'm not sure I understand
<noizer> Ok you know docker? So when I'm installing docker and on the docker side you can install nginx easily (normally)
<kyrofa> noizer, alright, I'm with you so far
<noizer> So when im installing nginx on docker. into my snap then can I maybe refer to my data in my nginx.conf?
<kyrofa> noizer, that's where you lose me. How does docker relate to your snap?
<noizer> hmm i don't know is it possible to use docker and nginx into my snap?
<noizer> kyrofa i didn't use docker before so I'm really noob at docker
<kyrofa> noizer, okay so you're thinking "It's easy to put nginx on docker. It's hard to put nginx into the snap. So can I get docker into my snap instead and put nginx on there?"
<kyrofa> noizer, sound about right?
<noizer> kyrofa yes :p
<kyrofa> noizer, I know a docker framework exists on 15.04, though I'm not sure what the plans are for 16.04
<noizer> oooh ok xD i will do it the hard way and I think the best way then :D
<kyrofa> noizer, you'd have to depend on the docker framework and make your .snap that way. I've not done that, though there are people here that have
<kyrofa> noizer, yeah, there's non-negligible overhead associated with things like docker. You don't want it if you don't need it
<noizer> kyrofa ok. I will you update on my status of nginx. If you want that :D
<kyrofa> noizer, sure :) . It may not be as bad as you think!
<noizer> kyrofa ok hopefully xD
<kyrofa> noizer, I strongly suggest you experiment with it outside of snapcraft until you understand the build process
<noizer> kyrofa
<noizer> ok i will do that first
<ogra_> ppisati, try bui9lding with CONFIG_USB_KEYBOARD (and perhaps with CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP)
<ppisati> ogra_: compiling...
<ppisati> dragonboard410c => setenv stdin serial,usbkbd
<ppisati> ## Error inserting "stdin" variable, errno=22
<ppisati> ogra_: ^
<ogra_> bah
<ppisati> with these:
<ogra_> ok, i gues si have to disable bootdelay then
<ppisati> +#define CONFIG_USB_KEYBOARD
<ppisati> +#define CONFIG_SYS_STDIO_DEREGISTER
<ppisati> ogra_: you mentioned something else before
<ppisati> ogra_: setenv stdin ...
<ogra_> i only know serial.usbkbd
<ogra_> err ... comma indeed
<ppisati> ogra_: oh ok
 * ogra_ tries the evil way
<ogra_> ubuntu@localhost:~$ sudo fw_setenv stdin serial,usbkbd
<ogra_> ubuntu@localhost:~$
<ogra_> muhahaha !
<ppisati> oh
<ppisati> did it work?
<ogra_> ubuntu@localhost:~$ fw_printenv |grep stdin
<ogra_> stdin=serial,usbkbd
<ogra_> ubuntu@localhost:~$
<ogra_> it sets it
<ogra_> weather it will boot is another question :)
<ogra_> reading uboot.env
<ogra_> In:    serial
<ogra_> Out:   serial
<ogra_> nope
<ogra_> ignores it
<ppisati> doh :(
<ogra_> Environment size: 4424/131067 bytes
<ogra_> => printenv stdin
<ogra_> stdin=serial
<ogra_> wow
<ogra_> it even unsets it during boot
<ogra_> (it accepted my bootdelay change)
<ogra_> well, people wanting to debug the bootloader can always set bootdelay from the running system, so i guess i'll default to bootdelay=0
<ppisati> ogra_: k, i sent an email to the uboot guy, just in case (you are in cc:)
<ogra_> thanks
<ogra_> he already said there might be a bug in hserial
<ogra_> joc__, thanks a lot for bringing that up !!!
<ogra_> (no dev would ever have catched it since we all boot with serial board attached )
<joc__> ogra_: np, thanks for the info
<jdstrand> noizer: re documentation, install snappy-debug then do 'snappy-debug list -i'
<jdstrand> noizer: the 16.04 names will be changing based on skills work though
<jdstrand> hopefully those will be settled within the next couple weeks
<kyrofa> noizer, questions over here please :)
<noizer> jdstrand ok
<Chipaca> ogra_, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/8962323
<Chipaca> ogra_, the good news is, I did nothing more than rebuild
<Chipaca> ogra_, but that is also the bad news
<Chipaca> ogra_, there are tests in there i'm not proud of :-(
<Chipaca> that depend on the test starting and ending the same minute
<ogra_> Chipaca, well, at least we have a binary now to make the image build, thanks a lot !
<d2388> Hi I have a question about Ubuntu as an OS
<kyrofa> sergiusens, FYI, as soon as netbase is in an all-snaps image I'll make MOOS an example. Until then, if you're curious: https://rainveiltech.com/posts/that-s-one-snappy-moos
<sergiusens> kyrofa, nice
<ogra_> kyrofa, oh, thanks for the reminder :P
 * ogra_ hacks the seeds
<kyrofa> ogra_, ha! Thanks again on that :)
<sergiusens> ogra_, can you upload new OS images? or is it only mvo? or does slangasek have the priv as well?
 * sergiusens heads back home
<kyrofa> sergiusens, walk safely. Look both ways
<ogra_> sergiusens, i dont know what account mvo used for them ... i'd rather have hiom do it
<elopio> fgimenez: why do we have offline slaves? Did I break something?
<ogra_> kyrofa, seeded and pushed, next image should have it
 * kyrofa hugs ogra_
<fgimenez> elopio, i have no idea, was waiting to ask you :)
<elopio> I don't know. Didn't notice yesterday.
<fgimenez> i'll remove them
<kyrofa> Hey didrocks I wanted to ping you regarding the owncloud snap. Is that in a good state for demo? We still have some time to fix things if necessary
<ogra_> kyrofa, an arm64 buiold would be so awesome :)
<noizer> kyrofa where can i see the deamons running in a snap?
<kyrofa> ogra_, ha! I'm working on it, the dragon keeps dying
<ogra_> noizer, snappy service status <packagename>
<ogra_> kyrofa, even with the new image ?
<kyrofa> ogra_, ah, I haven't tried yet. I'll get back to you
<ogra_> great
<didrocks> kyrofa: I guess it's good enough for the demo, I played with it and didn't spot anything bad :)
<didrocks> thanks for pushing this btw!
<kyrofa> didrocks, you GUESS? Psshh
<kyrofa> didrocks, and no problem, it's nice to get it some exercise
<didrocks> kyrofa: I still think (but maybe once 16.04 is out) we need to centralize all those "demos" in the git repo
<didrocks> but I tend to wait for 16.04 for now (at least, that it starts to stabilize with snapcraft 2)
<didrocks> so I hope for end of March/early April :)
<kyrofa> didrocks, yeah it's too much of a moving target right now
<didrocks> seen that :p
<kyrofa> ogra_, nooo, I don't have a 4GB SD card
<kyrofa> didrocks, heh, yeah I bet you have :P
<ogra_> kyrofa, you can resize the writable partition before first boot
<ogra_> just use gparted
<noizer> ogra_ can I see why it is inactive my service?
<ogra_> or gnome-disks
<ogra_> noizer, snappy service logs <packagename> ?
<kyrofa> ogra_, your README leads me to believe there will be nothing to resize?
<ogra_> or something along these lines
<kyrofa> noizer, the only reason it would be down is if it crashed. Check the syslog for reasons (or your application's log, if any)
<kyrofa> noizer, or yeah, snappy service logs
<ogra_> kyrofa, dd to a big SD ... then re-plug and open gnome-disks ... pick the writable partition and resize it to occupy all free space ... then  the resite on boot wont kick in
<kyrofa> I keep forgetting about that command
<ogra_> *resize
<kyrofa> ogra_, ahhh, okay
<ogra_> it checks for more than 10% free space on the SD ... if thats not there it wont run
<kyrofa> ogra_, kinda neat that it's there at all, honestly
<ogra_> yeah, i just wish i had picked the right partition tool from the start
<ogra_> (who would have thuoght we ever have u-boot devices with GPT partitions !)
<kyrofa> ogra_, it gets ingrained and it's difficult to switch, eh?
<noizer> ogra_ i got no error in my syslog or in my log of the service
<ogra_> well, it needs a bunch of code changes ... it is just annoying to test since you need to dd all images for all devices to SD multiple times
<ogra_> enervingly time consuming
<kyrofa> ogra_, ah, sure
 * zyga reflashed his BBBs
<elopio> fgimenez: hangout.
<fgimenez> elopio, yep omw
<kyrofa> ogra_, do I need to do anything fancy with these switches on the dragon to boot?
<ogra_> you need to turn the SD one on
<ogra_> and leave all others off
<asac> could it be taht running udf as root (not sudo)... is not working at all?
<asac> i get weird error that it cannot create /root/.cache etc.
<kyrofa> noizer, by the way, if you're curious about the actual apparmor snippets relating to each capability, check out /usr/share/apparmor/easyprof/policygroups/ubuntu-core/16.04/
<noizer> okey i see
<noizer> ps i tried to run the standard nginx ( installed with stage-packages) and it do not work at all :s
<kyrofa> noizer, /usr/share/seccomp/policygroups/ubuntu-core/16.04 for seccomp filters
<ogra_> asac, i never ran it as root, might interfere on some levels
<kyrofa> noizer, yeah, not surprising
<noizer> kyrofa i can see it start but not that it crashes in the logs :s
<kyrofa> ogra_, gnome-disk is just showing be a bunch of unknown partitions. I'm in trusty... too old?
<kyrofa> s/showing be/showing me/
<noizer> kyrofa so i need to compile it myself
<ogra_> kyrofa, you should see at least two usable ones (the last two)
<noizer> but so I can see it says make serve
<noizer> to build it
<kyrofa> ogra_, nope... everything is unknown
<ogra_> kyrofa, the rest will most likely still be unknown today, they are part of the bootloader and use very specific IDs
<ogra_> thats weird
<kyrofa> noizer, maybe. You might be able to get away with some sed magic
<ogra_> the last two are just vfat and ext4
<ogra_> with no special signature
<kyrofa> gparted sees that, but then gets super confused when I try to resize the ext4 saying the partition doesn't exist
<ogra_> hmpf
<kyrofa> gnome-disk doesn't actually show the last two at all, now that I look closer
<kyrofa> ogra_, just 1-7
<noizer> kyrofa sed magic?
<ogra_> well, you can always use gdisk on the cmdline
<kyrofa> ogra_, ah, I didn't actually know about gdisk. Tried using fdisk to obvious dispair
<ogra_> yeah, the old tools all kind of lack if it comes to GPT
<kyrofa> noizer, if for example it's dying because it's trying to save logs in a non-writable place, you can try copying a new config file over the top that uses the right paths
<asac> hmmm. running bluetoothctl hangs my pi2 ... or at least my ssh session goes down
<zyga> woot, all boards operational :)
<noizer> ok i will do that first
<zyga> asac: maybe get beefier psu
<zyga> asac: I'm using a big 5-port 10A supply
<zyga> asac: works great for a small farm
<asac> hmm. you say this could be power?
<asac> it happens even without a dongle attached
<zyga> hmmmmm
<ogra_> asac, anything in syslog or dmesg ?
<asac> ogra_: not really
<asac> let me see after this reboot
<asac> the last two times nothing was written
<asac> even though i had entries from yesterday in there
<asac> so something got persistet, but not these boots it seems
<ogra_> also try to use serial to make sure its only ssh/network that goes down
<asac> yeah it seems to really not persist the syslog
<ogra_> culd be your USB hub dying ... (since everything on the rpi is USB)
<asac> if it dowenst shut down cleanly
<asac> guess thats a bit of a bad feature :)
<asac> ogra_: could be, but i dont attach anything and just run bluetoothctl
<asac> and it dies
<asac> my pi2 is in an orange box
<asac> cant connect serial
<asac> if you have a pi2 with 16.04 just install bluez5
<ogra_> asac, you have a USB NIC ...
<asac> anywsay, i connectd it now to strong USB power supply
<asac> let me try again
<asac> nope same... with 4A
<ogra_> yeh
<asac> just dead the second i run bluetoothctl
<asac> without attaching any dongle and nothing
<asac> k... llet me try to find my other pi2 where i can make a serial avail
<asac> i think i had another one
<asac> ogra_: which pins do i connect the ttl to?
<ogra_> ugh ... i dont have my rpi nearby
<ogra_> asac, http://workshop.raspberrypiaustralia.com/assets/console-cable-connections.jpg
<ogra_> (you dont need VCC usually)
<asac> yay, i like raw boards with serial console :OP
<asac> works
<asac> lets see what happens there
<asac> they look so nice on the desk
<ogra_> yeah, my desk is plastered with them :)
<asac> right, but its your life style to have raw boards on your desk ... i am trying to get to a clean desk (not succeeded yet)
<asac> hehe
<ogra_> my desk is clean !
<ogra_> (everything around it is a mess admittedly)
<asac> ok first thing i notice is: http://paste.ubuntu.com/15017149/
<asac> lol
<asac> so thats probably not the best indicuation of successful bluez5 usage
<ogra_> ouch
<ogra_> yeah
<asac> yeah
<asac> dead
<ogra_> morphis, ^^
<asac> console dead when running bluetoothctl
<asac> no oops
<asac> nothing
<asac> end of life
<asac> bang
<asac> guess this is bogus stuff
<ogra_> thts with a USB dongle ?
<asac> no
<asac> nothign attached but serial, power through USB and LAN cable
<ogra_> is tere any BT onboard on the rpi ?
<asac> i dont think so
<ogra_> right, so why would it start then :)
<sergiusens> kyrofa, elopio here's a weird one https://github.com/ubuntu-core/snapcraft/pull/316
<asac> ogra_: what would start? bluez5?
<ogra_> yeah
<asac> i think its a deamon that should just there
<asac> until something gets plugged in
<ogra_> if there isnt a BT device there is nothing to attch to
<asac> also how can bluetoothctl binary just crash everything
<asac> sure, but its a service
<asac> no?
<ogra_> ask the kernel :)
<asac> the kernel doesnt even spit out anything before it dies
<asac> ppisati: ^^
<asac> 16.04 pi2 ... install bluez5 and run bluetoothctl
<asac> it will be dead without oops
<ogra_> do you get the obex messages too if you have a BT dongle pluggged in ?
<asac> ok let me reboot and plug it in
<asac> well, powercycle ... rather than reboot :)
<ogra_> yeah
<ppisati> asac: but is the board dead? led blinking? can you still ping it? ssh-in?
<ogra_> ssh dies
<plars> noise][: I think I hit the same issue as you were discussing yesterday, but I didn't understand what it was until now. I specified the release for my product as "rolling" instead of "rolling-core". Is there an easy way for me to edit the product?
<asac> ppisati: ssh is dead ... thats how i noticed and connected serial
<asac> serial also dead
<asac> i will check LEDs next time
<asac> give me 1 sec
<ogra_> yeah, we have heartbeat on by default
<ogra_> leds should tell you something
<asac> obey is not starting
<asac> even with dongle
<asac> bluez still fails even with dongle plugged while booting
<ogra_> sounds broken :)
<ogra_> do you see the right driver being loaded on plug/unplug ?
<ogra_> (in dmesg)
<asac> ok so right now the led is red
<asac> i can still use console
<asac> i am typuing bluetoothctl again
<asac> (nothing is blinking though even though it works)
<asac> the LED is still red
<ogra_> hmm, i thought the rpi kernel had heartbeat on by default
<asac> no blinks
<ppisati> me too
<ogra_> thast 16.04 ?
<asac> yeah
<ppisati> 4.4 kernel?
<asac> ok let me reboot from scratch and try the pinging of iface
<ogra_> can you ckeck the kernel version with uname ?
<asac> can also do that
<asac> [    0.000000] Linux version 4.3.0-1006-raspi2 (buildd@kishi13) (gcc version 5.3.1 20151206 (Ubuntu/Linaro 5.3.1-2ubuntu2) ) #6-Ubuntu SMP Tue D)
<asac> ppisati: ogra_:^
<asac> seems disk io makes the LED blink
<asac> its blinking right now
<asac> while booting
<ppisati> asac: so i just start bluetoothctl and the board dies, correct?
<asac> yeah
<asac> just do that
<asac> dead
<asac> no dongle needed
<ppisati> ok, let me try
<asac> end of day :P
<asac> lol
<ppisati> end of life :)
<plars> noise][: otherwise I can just delete it, just checking first if there's a better way
<asac> yeah, wanted to write that, but then i can still  powercycle, so i think its more like a day... :)
<asac> but guess every boot is a life
<asac> then its fine
<asac> guess i could also have fun and bring another board to my desk ... my good old bbb
<ogra_> really depends on the game though
<ppisati> asac: so, i just tested on a 4.2 raspi system
<ppisati> asac: if i start blueoothctl, it takes over the tty and i loose it
<ppisati> asac: e.g. if i'm in a ssh connection, it freeze
<ppisati> asac: but the board is ok
<ppisati> asac: serial works, and the heartbeat led keeps beating
<ppisati> asac: indeed if from serial i kill the bluetoothctl process, i'm back in business
<asac> oh... so it might also take the tty on our serial for snappy?
<asac> let me ping to test
<ppisati> asac: actually even the ssh is still up
<ppisati> asac: this on a 4.2 kernel
<ppisati> i shall try with a 4.3
<ppisati> just in case
<ppisati> asac: i guess so
<ppisati> oh, it might a bug tough
<ppisati> i'm no ruling out that
<ppisati> just that the board is alive, use ssh and then try with the serial
<asac> ping still works indeed
<asac> but my serial is down too
<ppisati> ssh in, bluetoothctl over ssh and it freeze
<ppisati> than try the serial
<ppisati> system is ok
<ppisati> *then
<ogra_> asac, try changing the kernel commandline
<ogra_> and drop the console=tty0
<ogra_> (with fw_printenv and fw_setenv)
 * ppisati tries with a 4.3 kernel, you never know
<ogra_> snappy has two console= options on the cmdline
<asac> ogra_: from userspace? fw_printenv is not there in uboot
<ogra_> asac, indeed from userspace
<ogra_> in uboot just use setenv and saveenv
<asac> yeah only that uboot dies when running printenv alone :( ... doesnt return to prompt after its finished
<asac> let me boot this thing to linux then
<ogra_> huh ?
<ogra_> definitely works here
<asac> ogra_: isnt that somewhere in a file in /boot?
<asac> that i can edit rather than running fw_ ?
<ogra_> no
<ogra_> it is a file in system-boot but it is binary
<asac> ogra_: so i run fw_setenv 'mmcargs=setenv bootargs "${args} console=ttyAMA0 root=${mmcroot}"'
<asac> ?
<asac> that wiped the whole mmcargs line :(
<ogra_> yeah, wrong quoting
 * asac hopes he can fix it before reboot
<ogra_> fw_setenv mmcargs 'setenv bootargs "${args} console=ttyAMA0 root=${mmcroot}"'
<asac> ok
<ogra_> and check with fw_printenv
<asac> ok that looks better
 * asac crosses fingers and reboots
<asac> ogra_: didnt help
<asac> seems to highjack all ttys
<asac> that i have
<asac> what a beast
<ogra_> well, was worth a try
<asac> so what now? guess coffee and break
<ogra_> yeh, and a cigraette
<ogra_> +r
<kyrofa> ogra_, gdisk won't let me create a partition of type FFFF... know any workarounds?
<ogra_> kyrofa, the type deosnt matter
<kyrofa> ogra_, oh, okay
<ogra_> not rfor the last two
<genii> mmm coffee
<ogra_> just make sure to not touch the first ones
<elopio> fgimenez: is it safe to restart a slave?
<elopio> ah nevermind, It's not needed :D
<fgimenez> elopio, sure, docker restart will give you a pristine one
<fgimenez> elopio, ok :)
<elopio> we are missing update-ca-certificates -f in the slaves
<ogra_> uncertified slavery !
<elopio> all our papers are in order. This is legal.
<ogra_> hah
<elopio> fgimenez: should I put it in the swarm-slave?
 * ogra_ sends khaleesi and the dragons to check that 
<elopio> ogra_: this totally badass scary guy will be waiting for you: https://wiki.jenkins-ci.org/download/attachments/2916393/logo.png?version=1&modificationDate=1302753947000
<fgimenez> elopio, mm i thought this was done in an ancestor of that images, let me check
<ogra_> OMG !
<ogra_> he will treat us with extensive friendlyness !
<fgimenez> elopio, ogra_ careful sometimes he gets angry https://raw.githubusercontent.com/jenkinsci/jenkins/master/war/src/main/webapp/images/rage.png
<elopio> lol, that should be our default logo.
<ogra_> hah, i picked up a sticker of that at SCaLE :)
<fgimenez> if you manage to get a java exception on the server you'll see him like that :)
<elopio> challenge accepted!
<fgimenez> elopio, it's done only on the master https://github.com/ubuntu-core/jenkins-ubuntu/blob/master/Dockerfile#L5
<asac> 2016-02-04T21:26:39.484191Z ubuntu-core-launcher cp: cannot create regular file
<asac> ï¿½ï¿½â/etc/dbus-1/system.d/bluez5_bluez_5.37-1-armhf.confï¿½ï¿½â: Permission denied
<asac> think thats not good
<ogra_> yeah, your UTF-8 is broken :P
<asac> well, the fac that it cannot put that stuff there
<asac> is ther eason why bluez is not activated
<asac>   # Allow replacing our dbus policy configuration file until
<asac>   # snappy has a better way to do this.
<asac>   /etc/dbus-1/system.d/bluez_* rw,
<asac> is in apprmor profile
<ogra_> yes,, it has a hacked up sercurity template iirc
<elopio> fgimenez: I know. What I'm not sure is if I should add it to the two slaves, or to the swarm.
<asac> ogra_: right, which seems to not work well
<Guest91403> Hey I just installed snappy on my  RPi and then instakk thexkcd-webserver.  How do I start xkcd?
<ogra_> asac, probably because snappy moved a lot since the package was uploaded
<ogra_> asac, especially the security/skills stuff
<ogra_> Guest91403, it starts automatically
<asac> jdstrand: did we drop support for the old way to do profiles now?
 * ogra_ forgot on which port ... might be 8080
<Guest91403> Thats what I read online so how do I view it then?
<asac> i am on ubuntu-core         2016-02-03 16.04.0-7.armhf canonical
<ogra_> Guest91403, point a browser at your rpi
<Guest91403> okay
<ogra_> http://webdm.local:8080/
<ogra_> that might work
<asac> ok i manually copied the dbus conf there now
<asac> ets see
<whizzo> Hi all, I have a snap for both the amd64 and armhf architectures that needs a Java JRE. It looks like there's a "jdk" part but it's unclear what plugin it should use.
<asac> whizzo: java plugin or maven plugin should do the trick in snapcraft
<kyrofa> ogra_, no that's webdm
<kyrofa> Guest91403, xkcd is just on port 80
<ogra_> kyrofa, on 8080 ?
<kyrofa> ogra_, yeah
<asac> whizzo: err jdk plugin
<ogra_> since when
<asac> or maven or ant
<kyrofa> ogra_, no
<ogra_> it used to be 4200
<kyrofa> ogra_, 4200 or something, sorry
<ogra_> yeah :)
<kyrofa> ogra_, 8080 isn't anything unless you're using kvm
<asac> 4200 isa webdm
<asac> you can go to the app there and there is a link to its real port
<kyrofa> ogra_, and forwarded 80 to 8080
<ogra_> kyrofa, right, i wasnt sure if the xkcd demo runs on 80 or 8080
<whizzo> asac, when I try part "jdk" with plugin "jdk" I get an error that 'source' is a required property
<kyrofa> ogra_, yeah, just 80
<ogra_> k
<kyrofa> ogra_, last time I tried anyway
<asac> whizzo: yeah you need to do something there
<whizzo> asac, does it matter what?
<ogra_> source: .
<ogra_> that might work
<asac> whizzo: try to just specify .
<asac> its a bug
<ogra_> (it works with the python plugin ... )
<asac> not sure if jdk plugin is suposed to be use standalone
<asac> if you use ant or mavent as build system just go for thse directly
<asac> ogra_: so after putting the dbus file in blace, bluez and obex daemons are happy
<asac> but bluetoothctl still highjacks everything
<ogra_> heh
<whizzo> asac, it seems to be building with that change.
<asac> man what nasty stuyff does this thing do
<ogra_> yeah
<asac> whizzo: cool. lets hope it also works :)
<whizzo> asac, thanks for the help... i'll see if it actually works properly
<asac> whizzo: what build system are you using?
 * asac wonders if there is anything beyond ant and maven used in java world
<whizzo> asac: I'm using maven but my maven build is above snapcraft -- it builds for several platforms.
<asac> ic so you need multi arch/cross feature
<asac> whizzo: so you have JNI bindings?
<whizzo> asac: the maven build lays down the directory that I run snapcraft against
<asac> i think you might run better with doing one snap for amd64 and another for armhf for now
<whizzo> asac: did something change? I used to be able to build a snap that included both archs...
<asac> yeah i get it. think best if maven could just be used tip to tail, but then, give it a try. the jdk plugin surely will get you the jre bits
<asac> whizzo: yeah you can still do that, but snapcraft doesnt support doign that
<asac> in the sense of building two runs with different toolchains
<asac> i think what you try to do could work
<asac> just need to add the magic wrappers etc. in place
<asac> but you cant get multiple archs for jre
<ogra_> yeah, snapcrft definitely supports just copying binaries around
<asac> in one build
 * ogra_ does that all the time
<whizzo> asac: ok, i'll give the snap that just built a try
<asac> so you might want to use the multi-arch syntax and see if that explodes
<asac> :)
<asac> right
<asac> hmm. wonder why we build bluez5 without-systemd
<asac> or rather what would happen if its build that way
<ogra_> ask tony or morphis
 * asac kind of suspects it might be interfering with auto tty by systemd
<ogra_> but i guess it would need even more apparmor hackery
<asac> not even sure what systemd would bring in ... shrug :)
 * asac will try to look at code
<asac> but has not high hopes
<asac> hmmmmmm
<asac> let me try to do two ssh logins
<ogra_> dont overload the poor board !
<plars> elopio: zyga: either of you (or anyone else) ever see this error when building an x86 image with mvo's udf?
<plars> snap unpack failed with: exec: "unsquashfs": executable file not found in $PATH ()
<ogra_> :)
<asac> so yeah its just that its bogus
<asac> readline
<asac> doesnt return
<plars> oh
<plars> *sigh* I realized what's up with it as soon as I pasted it
<plars> :)
<ogra_> heh
<elopio> :)
<asac> ok got it... dbus permissions are not granted, hence bluetoothctl just sits there forever waiting for a dbus response
<asac> yay
<ogra_> lol
<asac> looking at code can be revealing :P
<asac> hehe
<Guest91403> how do you know which port an app will use?
<asac> Guest91403: if you go to webdm you can find a link there afer navigating to the app itself
<asac> Guest91403: otherwise check the package.yaml in the snap and look for port
<asac> some are nice and specify which port they want to use
<asac> in 15.04
<asac> if all that fails run sudo lsof | grep LISTEN
<asac> and you will see what it listens to
 * ogra_ thinks having a "snappy list-ports" command would be nice 
<ogra_> listing yll the ports assigned to the packages
<ogra_> *all
<asac> snappy list-ports doign a magic lsof would work yeah.
<ogra_> yeah, or netstat
<asac> netstat doesnt help you finding the ports for a procss, no?
<asac> i can only see all ports open
<asac> but not figure who is doing what
<ogra_> it lists the binary if you use the right options
<asac> zyga: so how can i give my bluez5 snap powers to use dbus?
<asac> it has amigration-skill etc.
<asac> but taht seems to not work
<ogra_> ubuntu@localhost:~$ sudo netstat -tulp
<ogra_> Active Internet connections (only servers)
<ogra_> Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
<ogra_> tcp        0      0 *:22                    *:*                     LISTEN      981/sshd
<Guest91403> you mean go to webdm.local in my browser and then there will be a link?
<asac> Guest91403: http://webdm.local:4200 -> navivate to the app
<asac> and then there is a link at the top\
<ogra_> Guest91403, go to http://webdm.local:4200/
<Guest91403> ya i did that
<asac> ogra_: ok didnt nkow about -tulp i guess
<asac>  :)
<ogra_> there is a link in the details page of the app
<Guest91403> I see it install on my RPi but when I click it I just see information about it
<whizzo> asac: is there a log to check to see why my app didn't start once the snap was installed?
<asac> whizzo: snappy service logs PACKAGENAME
<asac> has the logs
<asac> hast the aggregate of systemd logs for services
<asac> :)
<ogra_> we also still have good old /var/log/syslog if you prefer fishing ;)
<asac> whizzo: for debugging its sometimes easier to not use service: but rather binaries:
<asac> and then see how it explodes when running that command
<asac> sandbox env etc. should be same, so when that starts working you can make it a service again
<asac> but service logs should have all
<whizzo> asac: It says Unknown command 'service'
<ogra_> hmm, is that 15.04 ?
<asac> whizzo: post: snappy list
<asac> right
<asac> if you are on an ancient 15.04 build you wont have snappy service... but recent 15.04 has it
<ogra_> yep
<whizzo> asac: ubuntu-core   2015-07-29 4       ubuntu
<asac> yeah thats too ancient
<ogra_> wow
<Guest91403> I click on the app and I see links for Details, which has a small description, and then settings and reviews, which have nothing.
<ogra_> thats oooold
<asac> whizzo: what board are you on?
<asac> if its a pi2 i would just update to latest
<ogra_> Guest91403, ah, if the app would have declared a port there would be some link called "Open"
<whizzo> asac: I downloaded the latest OVA from the snappy site.
<asac> ok OVA is utlemming
<asac> utlemming: :)?
<asac> whizzo: can you just snappy update that thing?
<asac> sudo snappy update
<asac> and see if it explodes
<asac> (back up first) :)
<whizzo> asac: yep, doing it now
<asac> ok lets cross fingers
<whizzo> asac: when I run the snappy update, it looks like it pulls down 2016-01-20, but when I reboot it still comes up as 2015-07-29
<asac> yeah, could be thats OVA
<asac> whizzo: you run on a mac?
<whizzo> asac: yes
<asac> if you are on linux just go for a normal qemu
<asac> so yeah, i am not sooo sure what to do there. guess wait for utlemming to get back to you and for now test on the arm board
<asac> rather than the amd64 virt thingy
<whizzo> asac: ok, will try on an ARM board.
<asac> whizzo: curious, did you see anything about grub when OVA booted?
<asac> or is that thing not using grub?
<whizzo> asac: it boots so fast its impossible to read the startup messages. Is there something in the filesystem I can check?
<jdstrand> asac: all the old ways are still there via the migration skill. the goal is to have them be gone though. see https://bugs.launchpad.net/snappy/+bug/1543220
<ubottu> Launchpad bug 1543220 in Snappy "skills and migration-skill in particular needs more documentation" [Critical,New]
<ogra_> jdstrand, yeah, but a snap that was built before the skills appeared will be broken
<jdstrand> those are broken regardless
<jdstrand> snap.yaml
<ogra_> well, it installs
<ogra_> but doesnt seem to apply the apparmor rules
<jdstrand> no
<jdstrand> there is no compat in 16.04 for the old stuff
<ogra_> yeah
<jdstrand> ie, if you used 'caps' you must move to the migration skill format
 * ogra_ desnt know what the blues5 package uses though 
<ogra_> but timely it fits into the big changes with its upload
<jdstrand> it uses the new format
<ogra_> then it isnt complete or something
<jdstrand> I tested package install on a vm, all the profiles were added
<ogra_> apparmor seems to have " /etc/dbus-1/system.d/bluez_* rw," ... but the package cant create its dbus file
<ogra_> (teh service one)
<jdstrand> he forgot to add that rule to the policy
<ogra_> /etc/dbus-1/system.d/bluez5_bluez_5.37-1-armhf.conf: Permission denied
<ogra_> ah
<ogra_> thats what you get when pushing someone to do last minute uploads before his vacation :)
<asac> jdstrand: well, so i have the bluez5 snap installed from store
<asac> jdstrand: it uses migration-skill
<asac> buit all those seem to not work anymore
<asac> jdstrand: i am on ubuntu-core         2016-02-03 16.04.0-7.armhf canonical
<jdstrand> see above
<jdstrand> there is a missing rule
<jdstrand> that will make it fail to work
<jdstrand> I suspect
<asac> jdstrand: hmm. so can i just fix the snapy.yaml?
<asac> or you say it wont work in all cases?
<asac> jdstrand: http://paste.ubuntu.com/15017801/
<asac> is the current one
<jdstrand> you need to adjust meta/bluez.apparmor to have:  /etc/dbus-1/system.d/bluez5_bluez_* rwk,
<asac> ok one sec
<jdstrand> asac: are you repacking the snap?
<asac> jdstrand: it currently has:
<asac>  # Allow replacing our dbus policy configuration file until
<asac>   # snappy has a better way to do this.
<asac>   /etc/dbus-1/system.d/bluez_* rw,
<asac> jdstrand: no i am not
<jdstrand> right
<asac> i am trying to assess whether there is hope to use this
<asac> ah i see
<asac> let me fix it
<asac> bluez5
<jdstrand> ok, I guess I didn't adjust the rule properly when moving from bluez to bluez5
<asac> jdstrand: so the other thing i get is even nastier :)
<Guest91403> when I try to ssh into my RPi I just get permission denied.  I am using the same password that I login with though
<jdstrand> but it is going back to bluez aiui after awe returns from vacation
<jdstrand> that is still tbd aiui
<Guest91403> nevermind
<asac> jdstrand: the whole dbus stuff [  297.130585] audit: type=1107 audit(1455211145.162:20): pid=724 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=966 label="bluez5_bluetoothctl_5.37-1-armhf" peer_pid=894 peer_label="bluez5_bluez_5.37-1-armhf"
<Guest91403> i forgot the ubuntu@
<asac> is jdstrand is that also caused by that line?
<asac> if so i will repack it now
<jdstrand> not by that line, but the same reason
<jdstrand> let me look at it
<asac> maybe the dbus paths also have 5 now?
<asac> like /org/bluez5?
<asac> and interface org.bluez5 ?
<jdstrand> no
<jdstrand> this is in meta/framework-policy/policygroups/client
<jdstrand> where it says 'label=bluez_bluez_*'
<jdstrand> it should be label=bluez5_bluez_*
<ogra_> what a mess :(
<jdstrand> asac: are you planning to upload? I think I should clean this up if not
<asac> jdstrand: i dont plan to upload, just unblock
<jdstrand> asac: ok, so adjust your policy for that. I'll upload after my meeting in a few minutes
<asac> jdstrand: there is no meta/framework-policy/policygroups/client
<asac> just seccomp
<asac> nevermind
<asac> found it
<jdstrand> asac: sorry, meta/framework-policy/apparmor/policygroups/client
<asac> garbage collection impossible: prerequisites untrue: remove /snaps/bluez5/5.37-1-armhf/command-bluetoothctl.wrapper: read-only file system
<jdstrand> that is copied to /var/lib/snappy/apparmor/policygroups
<jdstrand> and then on policy compile, the contents of that put in the app's profile in /var/lib/snappy/apparmor/profiles
<asac> works :)
<asac> you are rockstar for me jdstrand  :)
<ogra_> damn ...
<jdstrand> nice!
<asac> wonder why this got uploaded without working :)
<jdstrand> that is a long story
<ogra_> so the dragonboard always changes its MAC until i put it in a txt file somewhere on disk
<asac> hehe
<asac> dont worry. i know why i think
 * ogra_ hatse the world 
<ogra_> *hates
<jdstrand> awe had a working snap when named 'bluez'
<asac> jdstrand: let me know when you uploaded the clean version so i can validate
<asac> i am mostly interested how i can then allow a snap to use the RFCOMM devices
<jdstrand> store stuff, I renamed, fixed a few things but not all, but couldn't test locally due to lack of hw
<asac> so i will need your help sooner or later i guess
<asac> i hope its a rfcomm tty
<jdstrand> it will probably be in ~1 hour
<ogra_> so this makes me thingk we cant easily get away with only attaching the modules to a generic initrd :(
<asac> yeah no hurry. have to go for lunch now taht bluetoothctl is not hanging anuymore :)
<asac> ogra_: what?
<asac> we can
<ogra_> asac, well, not if you want a persistent MAC on the dragonboard
<asac> changing macs is normal in these worlds :)
<ogra_> not in my world !
<asac> ogra_: do you want a persistent mac that is the same everywhere?
 * ogra_ stomps foot 
<ogra_> !
<asac> if not then no initrd will help you :)
<asac> otherwise putting a txt file is fine
<ogra_> i want a MAC like MACs are defined
<asac> in kernel snap ... just dont want the bootlogic in there
<ogra_> unique in the world
<asac> modules + hacked stuff for the board is ok
<asac> or for the series of boards :)
<ogra_> and you can only read it from the kernel cmdline that the lk sets
<asac> we could also do the text file in the gadget?
<ogra_> so i need to parse /proc/cmdline and extract it from there
<ogra_> and then write to a txt file
<ogra_> and i cant really do that from the rootfs
<asac> yeah thats fine
<asac> thats db specific hackery
<ogra_> (well, i could, but that would even be more ugly)
<asac> like in init-bottom dir
<asac> or something
<ogra_> asac, exactly ... so we need an opportunity to inject device specific scripts into the initrd
<ogra_> from the non-generic side
<asac> ogra_: yeas, but all the initrd merging does
<asac> is adding stuff to the OS one
<asac> so you can add other files there too
<asac> \beyond modules
<ogra_> well, that wasnt really the plan
<asac> just put the file you want in the kernel snap initrd and thats cool
<asac> its fine
<ogra_> but yes, we will have to
<asac> the plan can be adjusted
<asac> and its also in the spirit
<ogra_> yeah, but it gets more complex
<asac> as long as all the platform indpendent stuff goes into OS initrd i am happy
<asac> dont think it does
<ogra_> just merging (or even loop mounting) /lib/modules is a lot easier
<asac> we need scripts for firmware upload hackery sometimes too there etc.
<asac> we dont want to do that
<asac> we want to concat the initrds
<ogra_> i do
<asac> taht was plan from day one
<ogra_> yeah, thats messy
<asac> yeah, better drop that idea and join us concat folks
<asac> :)
<ogra_> but anyway
<ogra_> i guess i'll be overruled ...
<asac> well, you overruled yourself :)
<asac> hehe
<asac> ok dinner
 * ogra_ used a VHS as well ... even though there was betamax
<asac> ttyl
<asac> haha
<asac> yeah loop moubnting modules feels similar to betamax
<ogra_> it does
<ogra_> and drops all the duplication :)
<sergiusens> kyrofa, did it work for you?
<sergiusens> elopio, want to give the PR a look?
<kyrofa> sergiusens, oh I didn't notice the new push
<sergiusens> kyrofa, I suppose it does given the tests pass, but I'll leave it up to you ;-)
<kyrofa> sergiusens, indeed, that works :) . I'll let elopio take a look before merging
<elopio> sergiusens: oh, sorry. Got too deep debugging in the cloud.
<elopio> give me a minute.
<sergiusens> kyrofa, yeah, a release comes after this; I hope we get a green adt run
<aatchison> Hello! It's Arron from the Mycroft team.
<aatchison> I was wondering a few things, how might we integrate continuous integration when building snaps for the raspberry pi via Jenkins?
<sergiusens> aatchison, oh hello; your mere presence reminds me I need to pick something up
<aatchison> hehe
<sergiusens> aatchison, you can look at snapcraft itself; we build a ton of snaps with travis; it shouldn't differe much; elopio is working on building that stuff on jenkins fwiw
<aatchison> ok, cool
<aatchison> I'm jsut wondering about cross-compilation
<elopio> but we are building for amd64 here.
<aatchison> I tried to attach to openvpn via an lxd container, but there is no tun device...not sure how to create one
<elopio> yeah, we currently don't have cross-compilation. You would need an armhf machine to build for rpi.
<aatchison> my thought was, jenkins slave in lxd -> push via ssh to the host snappy-core host machine via ssh?
<aatchison> I saw a similar thing with docker containers,we already have a server
<ogra_> hey aatchison !
<aatchison> Hey!
 * ogra_ feels the same as sergiusens 
<ogra_> oh the guilt !
<aatchison> lol
<aatchison> no worries or hurries
<ogra_> i have the mycroft snapcraft.yaml ope in a terminal though :)
<ogra_> *open
<aatchison> awesome!
<ogra_> (didnt close it since SCaLE :P )
<aatchison> hahaha
<elopio> aatchison: https://github.com/ubuntu-core/snapcraft/blob/master/examples_tests/tests.py#L293
<aatchison> ahh, thanks:D
<elopio> if you run this in an armhf machine, and your testbed is the ip to the rpi, you will have it working.
<elopio> aatchison: what I didn't get was your lxd comment. Where are you missing the tun device?
<sergiusens> aatchison, is your jenkins local?
<elopio> aatchison: this is what I'm struggling to fix today: https://github.com/ubuntu-core/snappy-jenkins/blob/master/containers/jenkins-master/config/jobs/github-snapcraft-integration-tests-cloud/config.xml
<elopio> jenkins, docker, snappy on the cloud. Maybe you'll find it useful.
<sergiusens> oh elopio don't get distracted :-P
<elopio> sergiusens: I'm so close... I test to fix.
<aatchison> well, I was trying to connect to openvpn ( our jenkins server connects to slaves that way), there is no tun device in /dev/net/ in an lxd container
<elopio> but I need to make your review... agh. I'm trying :)
<aatchison> nice. I'll take a look at that script and see if I could push via another pi on the local network
<elopio> aatchison: we have a reverse proxy that solves the communication between github and the lab that's behind vpn.
<morphis> ogra_, asac: no real reason
<morphis> ogra_, asac: and other than startup support isn't special in bluez for systemd
<ogra_> morphis, yeah, was a packaging error it seems (due to the bluez5 rename)
<aatchison> elopio: that's a good idea
<morphis> ogra_: possible
<ogra_> looks like asac and jdstrand solved it
<elopio> aatchison: what we haven't solved yet is the provisioning of the rpis. http://linux.codehelp.co.uk/?p=235
<aatchison> hmm
<aatchison> I'm using SPI to burn Arduinos via Raspberry Pi GPIO, we are actually wondering if a small bootloader could be written to the SD card the other direction
<elopio> aatchison: ogra_ is the bootloader guy. And plars is the hardware lab guy.
<elopio> they might have tips. At least about things that didn't work :)
<aatchison> haha, cool
<sergiusens> elopio, add comments ;-)
<jdstrand> ogra_, morphis_: fyi, out of my meeting now and will work on getting a fixed up bluez5
<jdstrand> uploaded
<morphis_> jdstrand: oh, is something wrong with the snap?
<jdstrand> in the apparmor policy
<jdstrand> two rules need to be updated
<jdstrand> it is what ogra_ was saying as ac and I worked out
<jdstrand> I'm just saying, I'm going to get that into the store
<robert_ancell> is 'snappy login' persistent - i.e. you just do it once on install and then never again?
<sergiusens> robert_ancell, yes, I don't think we kill expired keys though
<robert_ancell> sergiusens, thanks
<robert_ancell> sergiusens, and it does use a standard token? So it could be integrated with Ubuntu Online Accounts?
<sergiusens> robert_ancell, not using online accounts, something closer to click-toolbelt (just like snapcraft)
<sergiusens> robert_ancell, this is the gist of it https://github.com/ubuntu-core/snappy/blob/master/snappy/auth.go
<robert_ancell> sergiusens, thanks
<sergiusens> robert_ancell, if you want to runtime check on some online account features that would be sweet; we have some go code you can copy/paste or be inspired from in lp:account-polld even though we use the glib api instead of the new qt one
<robert_ancell> sergiusens, so you think it would be appropriate for snappy to check u-o-a for credentials?
<robert_ancell> and fall back to ~/snaps/snappy/auth/sso.json if u-o-a is not there?
<sergiusens> robert_ancell, yes; a runtime thing I guess would be valid; although I am not core to snappy anymore so maybe ask Chipaca first
<sergiusens> robert_ancell, or wait until Monday where we will be in the same room ;-)
<robert_ancell> yeah, will do that too!
<sergiusens> unless this is pre flight home work :-P
<robert_ancell> it is
<Chipaca> um
<sergiusens> so either runtime or though configuration
<Chipaca> 'snappy login' is going away, at least in its current form
<Chipaca> you want to talk with facu about that
<sergiusens> Chipaca, oh, right
<sergiusens> he is not here
<Chipaca> and unless online accounts support macaroons already you want to talk with facu and/or beuno *stat* :-)
<sergiusens> elopio, kyrofa https://github.com/ubuntu-core/snapcraft/pull/319
<beuno> robert_ancell, Chipaca, so
<beuno> I don;t understand why online accounts comes into play
<sergiusens> elopio, kyrofa just in case I pushed a tentative deb for that here https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+packages?field.name_filter=snapcraft&field.status_filter=published&field.series_filter=xenial
<Chipaca> beuno, robert_ancell is trying to tie snappy into the authentication, access and secrets storage (and more?) that exist already on the desktop
<Chipaca> at least that's my understanding of what he's doing :-D
<jdstrand> JamesTait: fyi in case you are looking for something to do, https://code.launchpad.net/~jdstrand/click-reviewers-tools/lint-snapv2/+merge/285666 is ready for review
<whizzo> asac: I installed my snap on a BBB running 2016-01-20 and it doesn't appear to install java
<whizzo> asac: I take that back, it installs java but I get an "Exec format error" when trying to run the java executable
<elopio> kyrofa: wtf catkin? It generates a bash file and a python file from templates, and then calls the python file from the bash file, and the python file calls python -c with a script in a string.
<elopio> whyyy???
<elopio> I had to put like 30 echos to understand that, and I'm still not close to understand the error.
<sergiusens> elopio, fwiw, is my changelog good to land? just asking since the last one was waiting on you without notice ;)
<whizzo> Has anyone else seen an issue with building a Java-based snap for BBB (specifying armhf as the architecture in snapcraft.yaml) and the java that is installed says "Exec format error" when you try to run it?
<whizzo> It looks like it installed the amd64 version instead of the armhf one
<jdstrand> asac: fyi, updated bluez5 in the store
<elopio> cd
<asac> whizzo: exec format error means you included binaries fro different architecture
<asac> you need to build on arm for arm and on x86 fof x86
<asac> as i said, snapcraft desnt support crossing
<asac> so best off make two snaps really
<asac> then you can probably just use the maven
<asac> plugin as well
<whizzo> asac: I got that error when building a snap specifically for armhf only
<whizzo> asac: oh, I see, you're saying I can't build an armhf snap on an amd64 ubuntu machine?
<whizzo> asac: It seems that even though the only architecture in the snapcraft.yml file is armhf, the jdk part still lays down the amd64 version of the JVM
#snappy 2016-02-12
<sergiusens> elopio, kyrofa I think I want to disable the catkin plugin example test for now https://bugs.launchpad.net/snapcraft/+bug/1544790
<ubottu> Launchpad bug 1544790 in Snapcraft "ros example fails in adt" [Undecided,New]
<yasser> hello
<yasser> \join
<yasser> anyone here?
<didrocks> good morning!
<fgimenez> good morning
<dholbach> good morning
<didrocks> hey dholbach, fgimenez!
<fgimenez> morning didrocks and dholbach :)
<mvo> hey fgimenez, good morning! how is the recent 15.04 alpha image looking? any issues that might block a migration?
<fgimenez> hey mvo good to see you around! yep, all is fine with the image, i did a first pass with kvm and bbb and elopio confirmed including rpi2
<fgimenez> mvo, are you feeling better?
<dholbach> salut didrocks - hola fgimenez! :)
<mvo> fgimenez: yeah, thanks! better, still not great but I wanted to cleanup some things before the weekend
<mvo> fgimenez: very nice, thanks to you and elopio for the validation. I will create a new stable update then in the channel today then based on the validated alpha
<fgimenez> mvo, great :)
<dholbach> mvo, I hope you can take some time off and get well again?
<mvo> dholbach: thanks, I feel better, just want to ensure I tie up some loose ends
<zyga> asac: hey, I'm not sure -- that would be a framework but we removed them, I don't know what today can generate a dbus profile in 16.04
<zyga> asac: I suspect it's 2 weeks away from trunk to be able to do that with skills
<ysionneau> hi asac
<asac> hi ysionneau
<mvo> ogra_: hey, good morning! great work on the dragonboard. I upload your kernel snap to the store now and check the other snaps. that should allow building an image that can be updated remotly :)
<vir17> hi, can I create a snap from .deb files?
<zyga> mvo, ogra_: please ping me with updated instructions, I'll refresh ubuntu-image
<zyga> once those bits are in the store
<zyga> vir17: hey, maybe, please look at snapcraft examples on github
<vir17> zyga:  I check and I cannot find an example that suits what I want to do, I forget to add that I want to have the .deb files into the folder where is the .yaml file and I try to find an example like that
<zyga> vir17: why don't you just unpack those debs
<zyga> vir17: there are plugins for just shoving a tar content into your snap
<vir17> thanks zyga  i will try that
<opny> Good morning, do you know a way to run an arm xenial image on qemu ? (In place of running snapcraft on the Pi)
<mvo> ogra_: I uploaded the snaps now, hopefully http://paste.ubuntu.com/15023254/ will install it now all from the store. there is one open issue with the gadget snap as it does not download from the store right now (401 error). I suspect this will be resolved soon(ish), I asked the store people already. this should give us remote updateable arm64 images
<zyga> mvo: \o/ great
<zyga> mvo: can you tell me the names of each of the snaps?
<mvo>      --gadget canonical-dragon.canonical \
<mvo>      --kernel canonical-dragon-linux.canonical \
<mvo>      --os ubuntu-core.canonical
<mvo> zyga: -^
<zyga> thanks!
<mvo> ogra_: note that the ubuntu-core-arm64 is no longer needed, we now have multi-dimension snaps in the store so ubuntu-core on arm64 will resolve to the right ubuntu-core:arm64
<zyga> mvo: works, except for the gadget
<zyga> mvo: I'll keep gadget as a copy from ogra's directory
<mvo> zyga: if you could build the image using the gadget with that dir and see if that boots that would be great. I mean, pass the local gadget but kernel and os from the store. if thats booting, then I can upload the image soon(ish)
<zyga> mvo: actually, the kernel doesn't resolve
<ogra_> mvo, uuh, stop
<mvo> zyga: I will keep an eye on the store issue
<mvo> ogra_: hm?
<mvo> zyga: it does not?
<ogra_> mvo, the gadget needs bootdely=0 set in uboot.env.in first
<ogra_> *bootdelay
<zyga> + exec sudo /home/zyga/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 core rolling --channel edge --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical --gadget /home/zyga/.cache/ubuntu-image/blob.e9d33cda70f8384c0ec31e4822a6ed457c98ca7ce6682b93875390507903413a04d81e9a8c8966c32d2d32865f56e
<zyga> 789be3cf25f8a66b1f1658b8fa4f8c443fe --developer-mode -o dragon-devel.img
<zyga> Determining gadget configuration
<ogra_> mvo, and the kernel snap needs a fixed resize script that can deal with GPT on u-boot (working on that today)
<zyga> mvo: (downloads some parts then):
<zyga> Installing canonical-dragon-linux.canonical
<zyga> canonical-dragon-linux failed to install: snappy package not found
<zyga> mvo: maybe it's not published yet, you can see which version of udf I was using here
<mvo> ogra_: ok
<mvo> zyga: ok
<ogra_> mvo, with the bootdelay=0 we sadly wont be able to enter the uboot console (unless you set it to something other than 0) but you can at least boot without the serial board attached
<mvo> ogra_: ok, I leave that to you
<zyga> mvo: try your serial board again, use various usb cables, I had 1/4 work/not work ration
<zyga> ratio*
<mvo> zyga: I won't spend time on it today, other stuff is more important :)
<zyga> sure
<mvo> zyga: but thanks, good to know that there is a fail rate
<asac> ysionneau: ricmm is ricardo
<ysionneau> ok :)
<ysionneau> thanks again guys!
<ysionneau> I'll try to think about all of this, right now it's a lot to process :)
<mvo> new (minor) stable update for 15.04 !
<ogra_> mvo, including the new rpi oem snap ?
 * ogra_ guesses so ... i guess the old one is gone from the store :)
<mvo> ogra_: so far it is only a system-image update, no new image yet
<ogra_> oh, that reminds me ... i havent updated snappy-hub yet
<ogra_> but the snap is in the store, so you will get it
<asac> ysionneau: right. can imagine, but in the end its pretty simplisitic :)
<mvo> jdstrand: fwiw, a stable update via system-image is now enabled, no new images yet though but the right bits should flow to the people via the stable update
<kyrofa> Good morning
<didrocks> hey kyrofa!
<kyrofa> Hey didrocks!
<kyrofa> Haha, elopio yes, catkin is the worst build system on earth
<vir17> anyone had installed snapcraft in raspian?
<ogra_> ppisati, so we have another prob on the dragonbaord .... the MAC doesnt persist ...
<zyga> ogra_: ohh?
<ogra_> ppisati, apparently linaro does this https://git.linaro.org/landing-teams/working/qualcomm/wcnss-config.git/blob/HEAD:/wcnss-gen-macaddr to work around it ... but we dont get androidboot.serialno= in u-bnoot because the lk doesnt hand it over
<ogra_> ppisati, i wonder if you know any method to pull the MAC out of /proc/device-tree in that case
<vir17> I try to install snapcraft in rasbian.I clone the repository and then "sudo python setup.py install". When I try to create a snap I get this error: http://pastebin.com/b1ZAvFZW
<vir17> anyone knows how to solve this?
<sergiusens> kyrofa, didrocks morning
<ogra_> vir17, what do you expect snapcraft in raspbian to produce once you have it installed ?
<didrocks> hey sergiusens, how are you?
<ogra_> vir17, i highly doubt the binaries woill be executable on snappy
<sergiusens> didrocks, fine, just thinking we might need an FFe ;-)
<didrocks> sergiusens: oh no, it's that fun time again! :-)
<sergiusens> as we will barely land all the features next week
<sergiusens> or we can just land everything broken
<sergiusens> ;-)
<didrocks> sergiusens: don't remind me of those dark times in the distro :)
<kyrofa> Hey sergiusens :)
<vir17> ok ogra_ i will abandon this solution then
<sergiusens> kyrofa, hey, can you take a look at  https://bugs.launchpad.net/snapcraft/+bug/1544790
<ubottu> Launchpad bug 1544790 in Snapcraft "ros example fails in adt" [Undecided,New]
<sergiusens> kyrofa, I want to either fix or disable that test in adt :-)
<sergiusens> kyrofa, there might be a proxy issue
<kyrofa> sergiusens, yeah that's a difficult log to digest, haha
<kyrofa> sergiusens, I want my line breaks back!
<sergiusens> kyrofa, maybe blame subunit
<sergiusens> or elopio ;-)
<sergiusens> kyrofa, I did grab the relevant failure there
<sergiusens> kyrofa, should be reproduceable locally too iirc
<kyrofa> Ah, I like reproduceable ones
<sergiusens> kyrofa, you can probably edit debian/tests/control and just run the catkin example
<kyrofa> sergiusens, ah, so I can't just run the example test to see this?
<sergiusens> kyrofa, only reproduceable in an adt env
<sergiusens> kyrofa, hmmm, unless the python path fix made it fail, but this test has been failing since before that
<kyrofa> sergiusens, I've not had to do that before, can you point me in the right direction?
<sergiusens> ogra_, wrt generic initrd; any ETA?
<ogra_> sergiusens, after i'm done with the dragonbaord
<ogra_> (i hoped to finish that today, but still digging on that MAC address issue atm)
<sergiusens> dholbach, btw, is the clinic an hour from now, two or three?
<sergiusens> kyrofa, when time permits https://github.com/ubuntu-core/snapcraft/pull/320
<kyrofa> sergiusens, 3 I think
<kyrofa> sergiusens, 1600 UTC, right?
<sergiusens> kyrofa, what a relief :-)
<kyrofa> sergiusens, hahaha
<sergiusens> kyrofa, I hope you show up too, unless well, you know ;-)
<kyrofa> sergiusens, I fully plan on it! Unless well, you know :P
<kyrofa> sergiusens, 2.x features right? Got an idea of what we'll talk about?
<kyrofa> sergiusens, will we try to stay on what is currently available, or will we discuss what it'll be come 16.04?
<ogra_> mvo, for setting the MAC on the dragonboard we need /lib/firmware/wlan/macaddr0 being writable :/
<ogra_> yay android drivers :((
<sergiusens> kyrofa, differencenes between 1 and 2; then what is coming for 2
<kyrofa> sergiusens, sounds fun!
 * zyga has updated unofficial ubuntu-image to handle dragon board from the store
<mvo> ogra_: uh, we need /lib/firmware/wlan/macaddr0 to be writable?!?
<ogra_> mvo, well, we need that file to contain the MAC
<ogra_> if you have an idea how to do it without a writable file ...
<mvo> ogra_: we could make it a symlink in the os snap and point to something in /run that the initrd creates/populates
<mvo> ogra_: but all rather terrible
<ogra_> (i mean, we could also patch the driver top look somewhere else ... but i doubt ppisati would like to carry such a patch forever)
<ogra_> *to look
<ppisati> ogra_: that information is not part of the device tree
<ogra_> ppisati, well ... it is ...
<ogra_> but only of the lk DT
<ppisati> ogra_: uhm
<ogra_> i just found a way to parse that from uboot ... similar to how we do it on the rpi
<ppisati> ogra_: how did you do that?
<ogra_> "fdt addr $value_i_fished_out_of_lk_output ; fdt get value args /chosen bootargs"
<ogra_> thsi works by hand ... still fiddling with scripting it now
<ppisati> ogra_: oh ok
<jdstrand> mvo: thanks! I see my devices were updated and have the security updates :)
 * jdstrand isn't really here
<jdstrand> mvo: you feeling better?
<ogra_> => fdt addr 0x81e00000
<ogra_> => fdt get value args /chosen bootargs
<ogra_> => printenv args
<ogra_> args= androidboot.emmc=true androidboot.serialno=7c16331a androidboot.baseband=apq mdss_mdp.panel=0:dsi:0:
<ogra_> ppisati, ^^^
<ppisati> ogra_: but there's no mac address there
<ogra_> ppisati, the serial is the MAC
<kyrofa> ogra_, so I can't seem to get the all-snaps image to boot on the dragonboard. I have the SD card switch on, but it keeps booting to the linaro image I flashed to internal. Is that interfering somehow? Or did I just fail on resizing the partition?
<ogra_> kyrofa, it obnly works on 4GB cards ... like the big fat notice in the README says
<ogra_> and yes, resizing still wipes the partition table
<kyrofa> ogra_, I know, but you mentioned if I resized manually before trying to boot it shouldn't try the resize
<kyrofa> ogra_, but it was a little weird on trusty
<kyrofa> ogra_, so I wouldn't be surprised if it didn't work out
<ogra_> hmm, perhaps your manual resize somehow messed it up ?
<ogra_> you need to be super sure the IDs, size and content of the first partitions doesnt change ... ever
<kyrofa> ogra_, yeah. Okay I just wanted to make sure there wasn't something special I was supposed to do if I had already flashed another image. Any chance you could let me know when that resize bug is fixed?
<kyrofa> ogra_, or is there a bug I can keep my eye on?
<jdstrand> mvo: I'm on holiday today so stepping away (after asking my question). I'll take the fact that you are here as you feeling better (and I'm glad for it)
<ogra_> kyrofa, no bug ... but i was planning to get this done today ... its a matter of how long this MAC address thing now takes ... i didnt plan that one :P
<jdstrand> mvo: I'll also provide a potentially other clue on the apps reinstalling over and over again on stable. it seems to only happen with snaps that exist in both rolling and stable. eg, hello-world and snappy-debug, but not ufw
<kyrofa> ogra_, oh you're good man, I didn't mean to rush you :)
<kyrofa> ogra_, glad to hear it's on the horizon, though
<jdstrand> mvo: I don't know if that is a definite part of the problem-- it is just something I noticed
<ogra_> well, i need to work on generic initrd next week ... so i ant the dragonboard done today
<jdstrand> ok, really gone now
<kyrofa> ogra_, understood. By the way, is that porting guide still applicable? Or does it need to be rewritten completely for all-snaps?
<ogra_> the latter
<ogra_> i'll work on that once we are through all these conference thingies :)
<kyrofa> There's one piece of hardware I'd really like to support, and I feel like it'd be a great learning experience
<ogra_> ubuntu@localhost:~$ cat /proc/cmdline
<ogra_>  androidboot.emmc=true androidboot.serialno=7c16331a androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: console=ttyMSM0,115200n8 root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snappy_os=ubuntu-core-arm64.sideload_IMNAJeAIfTOc.snap snappy_kernel=canonical-dragon-linux.sideload_IMNAJdKaXGIP.snap
 * ogra_ dances 
<mvo> ogra_: nice!
<mvo> jdstrand: cool, thanks and enjoy your holiday
<ogra_> mvo, well, thats only half the fix .... we need something like https://git.linaro.org/landing-teams/working/qualcomm/wcnss-config.git/blob/HEAD:/wcnss-gen-macaddr now
<mvo> ok
<ogra_> i get cold shivers seeing that code though :P
<ogra_> (especially the "first writing the file wrongly and then fixing it with sed" part ...)
<dholbach> sergiusens, 16 UTC, so in 1h44m from now
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/30
<ogra_> changes pushed
<zyga> https://github.com/zyga/devtools updated with i386 snappy, i386 virtualization and latest dragonboard support
<sergiusens> dholbach, thanks
<ogra_> mvo, would you do me a favour and push that update for the dragon to the store ?
<ogra_> (with fresh uboot.env generated from rev 30 on snappy-hub)
<ogra_> (if you dont have time i'll do it tonight)
<elopio> fgimenez: we are still in the snapcraft planning session.
<elopio> you can join us if you want :)
<rtg> I've been trying out the kvm instructions in order to test sideloading a 16.04 kernel snap. However, the instructions on the web page do not appear to be correct. The example for 15.04 doesn't work, e.g.,
<rtg> sudo kvm -m 512 -redir :8090::80 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img
<rtg> WARNING: Image format was not specified for 'ubuntu-15.04-snappy-amd64-generic.img' and probing guessed raw.
<rtg>          Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
<rtg>          Specify the 'raw' format explicitly to remove the restrictions.
<rtg> Could not initialize SDL(No available video device) - exiting
<fgimenez> elopio, i'm not feeling well today, still a bit sick, maybe next time :)
<mvo> ogra_: sure, I assume I can just bzr up; snappy build?
<ogra_> i guess so ... hwo did you produce the last one ?
<ogra_> :)
<mvo> ogra_: exactly this way
<ogra_> yeah, then it shoudl eb fine ... uboot.env needs updating first ...
<mvo> ogra_: I ran mkenvimage
<ogra_> well, let me do that and commit it so the bionary is in sync with the source
<ogra_> ah, k
<wiggleworm> I am looking for some help installing java on snappy so that my app will run. I think I need to have it packaged along with my app during the snap craft process but not sure.
<wiggleworm> has anyone here done such a thing
<ogra_> wiggleworm, i think there are examples for snapcraft to get the java bits bundled properly inside your snap
<mvo> ogra_: bootdelay is zero and the bootargs is for the mac address?
<ogra_> mvo, yeah
<ogra_> the bootdelay thing is a bit unfortunate but no better workaround for now
<mvo> ogra_: ha! thats magic
<sergiusens> wiggleworm, yeah, run 'snapcraft help ant' or `snapcraft help maven'
<sergiusens> wiggleworm, also look at the examples for maven and a hello world
<wiggleworm> ok - thanks I will take a look
<mvo> ogra_: I pushed to "edge", if you could double check that everything is ok and give me green light I push to stable
<ogra_> mvo, ok
<ogra_> mvo, hmm is --gadget canonical-dragon/edge the right syntax ?
<ogra_> seems u-d-f doesntz find it (with or without /edge)
<mvo> ogra_: http://paste.ubuntu.com/15023254/ works for me
<ogra_> ah .canonical
<mvo> ogra_: this should give us fully updaable ones, well - except for the partition resize issue :)
<ogra_> yeah, i hope to get that done before EOD ... its just super time consuming since i need to test on all arches (lots of dd*'ing and waiting)
<ogra_> i wonder if i shoudl just make the resize code a no-op just for this initrd for now ... that would be quick and dirty :)
<ogra_> mvo, hmm u-d-f dies for me with "can not find OS part"
<ogra_> using --os ubuntu-core.canonical like in your paste
<ogra_> bah, silly me ... forgot --channel :P
<mvo> ogra_: :)
<mvo> ogra_: if all is looking well I'm happy to promote to stable
<ogra_> mvo, i'll let you know ...
 * ogra_ waits for xz and dd
<dholbach> for everyone waiting for the Snappy Clinic - we're just about to start
<dholbach> http://ubuntuonair.com
<dholbach> if you have questions for the clinic, just make sure you prefix them with QUESTION:
<ogra_> ubuntu@localhost:~$ cat /proc/cmdline
<ogra_>  androidboot.emmc=true androidboot.serialno=7c16331a androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: console=ttyMSM0,115200n8 root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snappy_os=ubuntu-core.canonical_16.04.0-3.arm64.snap snappy_kernel=canonical-dragon-linux.sideload_IMRdLKVUXAPL.snap
<ogra_> mvo, ^^^ looks good ... and boots with serial board detached too
<ogra_> mvo, promote it :)
<mvo> ogra_: all snaps available on stable now, once the resize bug is fixed we should push a new image
<ogra_> mvo, yeah, i'll probably go with a quick fix specific to this initrd for now (and i can also quickly hack it up to get the MAC linked into /lib/firemware/wlan)
<ogra_> i can luckily do it all inside the -linux snap
<sergiusens> mvo, can we get a new OS today or is that too much to ask?
<ysionneau> asac: do you know any target supported by snappy, with a somehow working qemu port?
<ogra_> ysionneau, amd64
<ysionneau> sorry, I forgot to mention : arm target
<ogra_> heh
<ogra_> i dont think there is any
<ysionneau> I found a qemu-raspi2 on github, didn't manage to get it to work yet though
<noizer> QUESTION: how long does it take for an app to be reviewed?
<mvo> sergiusens: what do you need in the new OS? happy to build one, we just won't have snappy updated because the auto-build is broken
<ysionneau> https://github.com/0xabu/qemu
<ogra_> noise][, auto-revie is usually happening in munites
<mvo> ogra_: +1
<ogra_> bah
<mvo> sergiusens: any particular arch that is important to you?
<ogra_> noizer, ^^^
<sergiusens> mvo, snap launcher
<sergiusens> mvo, it creates dirs, also systemd SNAP_USER_DATA set correctly
<noizer> ogra :p
<sergiusens> mvo, x86 and armhf
<ogra_> noizer, manual review can takes weeks or months and is also likely to be rejected
<sergiusens> first more important than the second
<noizer> ogra_ ok
<noizer> awesome
<noizer> QUESTION: will it be possible to share libraries over multiple snaps with skills? (SO files)
<dholbach> nice questions - keep them coming :)
<mvo> sergiusens: ubuntu-core is updated for amd64 in the edge channel, if you could give it a quick test if it has what you need I will promote
<mvo> sergiusens: arm is ready in some minutes as well
<elopio> pitti: is this a correct incantation? https://paste.ubuntu.com/15025272/
<elopio> It just gets stuck after creating the instance.
<noizer> snapcraft 2 is realy awesome :D
<ogra_> it is !!
<noizer> yea xD just one problem I had was when I'm installing my snap to much I cant delete it
<dholbach> any more questions? :)
<noizer> When will be the stable release for 16.04.
<noizer> ?
<kyrofa> noizer, april 2016
<noizer> kyrofa nicee :D
<kyrofa> (those release numbers are dates)
<noizer> kyrofa ooh didn't know that
<sgclark> If I ever finish debian merges I still plan on tackling kde :)
<dholbach> thanks everyone!
<sgclark> ty
<elopio> thanks to you dholbach.
<kyrofa> Thanks dholbach :)
<dholbach> sergiusens, kyrofa, elopio: thank YOU :)
<thibaut> QUESTION: When will we be able to run graphical snaps on the desktop?
<ogra_> probably not before the desktop defaults to Mir
<ogra_> "Â§%e%/&Â§$=%Â§/%/& !!!!
<ogra_> GRRRR
<ogra_> ^^^ this is me when accidentially hititng the "cursor up" and enter keys  in a terminal where dd just finished ....
<ogra_> :(((
<zyga> ogra_: lol
<zyga> ogra_: dd should remember the last request and ask "are you sure? [n/y]"
<ogra_> yeah
<zyga> speaking of which, let's try parted
<ogra_> the bad thing is that i didnt just leave it running but did hit ctrl-C .... which gets only respected after it is half done :/
<ogra_> so another useless dd-time-waste
<zyga> ogra_: oh, SIGINT clobbers the card?
<zyga> ogra_: as in writing partially shit?
<ogra_> well, you hit ctrl C but it will finish writing the block from ram ... depening on the blocksize you have a half written card then
 * ogra_ uis curently using bs=128M ... dd wrote ~400M (it told me) even with ctrt-C
<zyga> well, is the rest different compared to earlier write?
<zyga> it seems that it's just an overwrite
<zyga> with same blob
<zyga> so it should be safe to kill
 * ogra_ boots and sits in awe
<sergiusens> thibaut, were you watching the hangout in non live mode?
<ogra_> ubuntu@localhost:~$ ifconfig wlan0|grep HW
<ogra_> wlan0     Link encap:Ethernet  HWaddr 02:00:7c:16:33:1a
<ogra_> ubuntu@localhost:~$ cat /run/macaddr0
<ogra_> 02:00:7c:16:33:1a
<ogra_> YAY !!!!!!
<zyga> ogra_: new gadget or kernel?
<ogra_> zyga, kernel ... resize cvompletely ripped out and MAC adedress handling fixed (that will both need more work later, but good enough for now)
<elopio> sergiusens: how did you generate your changes file?
<zyga> hmm, I have terrible serial data connection
<zyga> tons of bytes lost
<dholbach> all right my friends - have a great weekend!
<zyga> ogra_: gimme, I'll gladly try it
<zyga> dholbach: likewise, enjoy
<ogra_> zyga, currently uploading for mvo to push it to the store
<zyga> ogra_: so will that actually auto-update/
<ogra_> mvo, http://people.canonical.com/~ogra/snappy/dragonboard/tmp/canonical-dragon-linux_4.2.0-2012-generic-dragon410c_arm64.snap ... push to edge again and i'Ãll test it from the store, then we can release
<ogra_> zyga, i guess
<zyga> woot
<zyga> ogra_: how do you rebuild from the store?
<zyga> ogra_: anything I could tweak in ubuntu-image for that?
<didrocks> have a good week-end everyone!
<ogra_> for what exactly ?
<zyga> ogra_: for being able to get fresher (test) snaps
<ogra_> zyga, well, i guess from now on we'll just push to the store regulary
<ogra_> so as long as you use the edge channel you will get the latest crack
<sergiusens> elopio, gbp buildpackage -S
<zyga> ogra_: perfect
<zyga> ogra_: does 'sudo snappy update' works for you?
<zyga> ogra_: for me it doesn't (store issue?)
<ogra_> i'd have to set up networking
<zyga> ahh
<zyga> I didn't either - sorry :)
<ogra_> yeah, then snappy spills that wonderful informative error message
<ogra_> zyga, but what would you want to update ? there is no new rootfs or anything
<zyga> ogra_: the new kernel, later
<ogra_> not sure the old one was uploaded yet
<zyga> ogra_: btw, the kernel version is weird, is the generic-dragon410c needed?
<zyga> ogra_: it had to be, I built the image I'm running from the store earlier
<ogra_> (that might cause us issues since we dont have a minor version we can easily bump)
<zyga> (well 30 minutes ago)
<ogra_> not sure how/if mvo can solve that
<zyga> mvo can do anything :)
<ogra_> if the store lets him :P
<ogra_> beuno can break all of us nowadays, he has the powah :)
<zyga> still I cannot be happier, all my 6 boards are working
<ssweeny> trying to install lxd from the store on my rpi2 (rolling, all-snap) I get this error: lxd failed to install: can not open /tmp/lxd893703768: cannot open snap: unknown header: "!<arch>\ndebian-binar"
<zyga> ssweeny: the snap is using the old format (not valid for 16.04)
<ssweeny> aha
<zyga> ssweeny: it's the clickdeb format apparently
<ogra_> ssweeny, yeah, stgraber needs to update the snap to the new all-snaps setup (using squashfs and all via snapcraft 2.x)
<ssweeny> that makes sense
<ssweeny> this is from before 16.04 moved I take it
<ogra_> yeah
<ssweeny> since other 15.04 snaps don't show up at all for me
<ogra_> most of the snaps are currently non-installable from the store ... only few have been updated yet
<ssweeny> ok, good to know
<ssweeny> i suppose i can use classic mode for development until containers are working again
<ogra_> yeah ... effectively you should now always use classic mode
<ogra_> (it is just a container after all :) but with a lot less overhead)
<ssweeny> right :)
 * ogra_ needs to get dinner ... mvo let me know if there is something i can test :)
<zyga> ogra_: FYI classic on dragon doesn't work
<zyga> ogra_: missing parts somewhere:
<zyga> ubuntu@localhost:/etc/network/interfaces.d$ sudo snappy enable-classic
<zyga> needle "ubuntu;xenial;arm64;default;" not found
<sergiusens> zyga, I bet there isn't an arm64 image available on the image server
<sergiusens> zyga, ogra_ yeah, that's it http://images.linuxcontainers.org/images/ubuntu/xenial/
<ogra_> zyga, yes, known, stgraber is on it
<sergiusens> hah, was just about to ping him ;-)
<zyga> thanks!
<ogra_> zyga, sergiusens bug 1543764
<ubottu> bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New] https://launchpad.net/bugs/1543764
<asac> ysionneau: we only use qemu for x86... otherwise boards
<asac> ysionneau: shouldnt be that hard to make it work on versatile though etc.
<ysionneau> I am now able to boot the raspberry pi 2 img (with my own kernel) on some custom qemu
<ysionneau> but it fails to login with ubuntu:ubuntu l/p
<asac> hmmmm
<asac> ysionneau: so i think the ubuntu/ubuntu credential might be set by cloud-init... do you see that running? (dont ask why its called like that :))
 * ogra_ doubts you actually booted correctly then
<ysionneau> ah, cloud-init is failing :)
<ysionneau> maybe because I get no network
<ogra_> and writable is most likely not properly mounted either
<asac> that shouldnt be a problem for credentials
<ogra_> asac, thats just fallout
<asac> ysionneau: ogra is your man i guess :) ... he is the master of ARM bringups :P
<ogra_> did you actually fish the initrd out of the image to hand it to qemu (i assume you need to point it to kernel and initrd on cmdline)
<zyga> ysionneau: try https://github.com/zyga/devtools/
<zyga> ysionneau: if you just want a working vm
<zyga> ysionneau: for other goals -> look elsewhere :)
<asac> zyga: he is experimenting how to his own kernel/board etc.
<asac> on 15.04
<zyga> ah
<ysionneau> ogra_: nop I didn't put the initrd from the image in qemu, I'll do that :)
<asac> ysionneau: so if you have your own kernel there are a couple patches you need for our security bits
<asac> that you need to add
<ysionneau> something which bothers me is that I wasn't able to tell qemu to just boot from the .img
<ogra_> ysionneau, well, only if you actually use --ramdisk and --kernel options in qemu indeed
<ysionneau> I had to build my own kernel/dtb and pass it to -kernel
<asac> yeah snappy needs our initrd
<ysionneau> and then with the root=/dev/mmcblk0p2 it works
<asac> thats where the magic failover bootlogic and other stuff is
<ysionneau> so I'm not even using the snappy kernel
<ogra_> i really doubt you can get that to work at all
<ogra_> outr image needs crtain bootloadder login that lives in uboot
<ysionneau> arg ok
<ogra_> root=/dev/mmcblk0p2 isnt enough
<ogra_> (the cmdline is actually getting assembled during boot)
<ysionneau> do you know how to tell qemu to boot directly from the sd ? :o
<asac> ysionneau: in case you want to do your own kernel check out these: https://wiki.ubuntu.com/SecurityTeam/AppArmorForSnappyKernels
<ysionneau> asac: thx
<kyrofa> elopio, sergiusens so adt-run passed for me on xenial...
<ogra_> i'm not sure the qemu arm system implementation can actually use u-boot (i could be wrong though, it is years that i have used qemu-system last)
<kyrofa> elopio, sergiusens just using the released package as a test. Shouldn't they fail?
<rtg> ogra_, where do the magic scripts for the initrd live ? I've got kernel snaps working for raspi2 and BBB (and sort of working for amd64/i386)
<asac> ogra_: i know that beagleboard worked with uboot iirc
<ogra_> rtg, initramfs-tools-ubuntu-core
<rtg> ogra_, right, lemme make sure I'm getting those in rootstock
<ogra_> asac, yeah, but also with -kernel and -ramdisk iirc so thats only half
<asac> i think its more likely you could get a beagleboard image work on qemu with uboot... as upstream state is far more
<asac> ogra_: no... i remember us booting it with .img
<ogra_> asac, beagleboard != beaglebone :(
<asac> right
<ogra_> anyway ...
<asac> still i think its more likely to work with beaglebone than pi2
 * ogra_ goes back to the dinner table :P
<sergiusens> kyrofa, drats, that means it will be a hard fix
<asac> given that beaglebone works all plain vanilla upstream
<kyrofa> sergiusens, yeah :(
<asac> for beagleboard with img see https://wiki.linaro.org/Resources/HowTo/Qemu-beagleboard
<asac> so maybe building kernel and uboot for beagleboard might be a way to get this going
<sergiusens> ogra_, there is nothing simple about this json http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:download.json
<asac> do we have a prebuilt bone .img?
<ogra_> sergiusens, thats what i learned today ... sadly
<sergiusens> ogra_, I prefer the container site (which is what I started to use for cleanbuild)
<zyga> asac: I tried qemu with beagle * and support in our ubuntu copy of qemu is no longer there
<zyga> asac: linaro had a patched qemu that had -M beaglexm support
<zyga> asac: I tried this earlier today
<asac> hmm. that never made it upstream?
<asac> bummer
<zyga> asac: or got removed, it's not in our qemu for sure
<zyga> asac: probably just a linaro patch
<asac> https://launchpad.net/qemu-linaro
<asac> seems outdated too there
<zyga> yeah, linaro moved to internal git
<asac> internal?
<zyga> well
<zyga> internally hosted :)
<zyga> it's public for most of the part
<zyga> https://git.linaro.org/
<zyga> tons of hits for qemu, good luck finding the right branch to follow
<zyga> I'd look for tarballs
<asac> http://git.linaro.org/pkg/qemu-linaro.git also not better
<zyga> well, someone would have to have a look, compare to upstream, etc
<zyga> asac: is the goal to have bbb image working in qemu
<zyga> ?
<asac> that would be a good start i guess
<asac> think cool woudl be to have snappy work on any qemu
<asac> doesnt matter which kernel etc.
<zyga> right
<zyga> I'd switch to one of the supported vexpress modules and just build a vexpress kernel
<asac> ok asked fabo in #linaro
<zyga> probably saner than chasing $random_board kernels
<zyga> and emulation
<asac> yeah guess vexpress would be the best wayt o go, but that doesnt have u-boot
<asac> so you cant do the real thing
<asac> with tx updates and friends
<zyga> what does it do to boot?
<zyga> efi?
<asac> nothing
<zyga> oh?
<asac> just pure kernel i think
<asac> with qemu setting things up right to start
<zyga> isn't that something you can also get physically, with big fpga's and stuff
<zyga> it boots off sd cards AFAIR
<asac> yeah you can get vexpress
<asac> those are cool :)
<asac> cost a lot, but you can swap out SoCs in plug and play fashion :P
<zyga> I mean, if the real thing boots from SD, does it also load a kernel from some fixed offset?
<asac> its a motherboard basically where you can plug in new SoCs that are just reference low-volume SoCs done by ARM
<zyga> can we do something like that for the emulated vexpress with barebones kernel/u-boot?
<zyga> ah
<zyga> well, let's see what fabo says
<asac> the real thing boots very weird i remember
 * zyga hasn't seen fabo in ages
<asac> lots of stuff you can do
<asac> before it even hits the bootloader afaik
<asac> but then, we dont have one of those toys anyway :P
<asac> ok i am out for a bit...
<kyrofa> sergiusens, so maybe disable the test for now since the catkin plugin may be changing a bit?
<kyrofa> sergiusens, I don't understand why I'm not seeing the failure. Have you tried locally?
<sergiusens> kyrofa, not today, network errors a galore
<kyrofa> pitti, hey, your docs on autopkgtest were extremely helpful by the way
<ogra_> mvo, i have an appointment in ~30min ... if there is anything to test in the edge channel, just leave me a note here and i can test later tonight
<ogra_> mvo, (regarding the kernel from above that is)
<mvo> ogra_: hi, sorry, was at dinner myself, I'm uploading now, I made up a version number for you (added a +1 at the end :P and that should be enough to make the store and snappy happy
<kyrofa> mvo, if I wanted to test out all-snaps edge, how would I do it?
<ogra_> mvo, yeah, but we need to find some agreement with the kernel guys how we do that in the future (without clashing etc)
<mvo> kyrofa: http://people.canonical.com/~mvo/all-snaps/ is the best place and then use "snappy update ubuntu-core/edge "
<mvo> kyrofa: that should work if not let me know :)
<kyrofa> Ah, so just change channel from within the image? Okay easy enough :)
<mvo> ogra_: adding a +1 (or +2) should always be safe
<mvo> kyrofa: well, it should work if not we need to talk
<mvo> kyrofa: and it works today, next week on the sprint the /channel syntax is up for discussion
<kyrofa> mvo, heh :)
<kyrofa> mvo, I get "the given snap is not installed."
<kyrofa> mvo, I tried .canonical as well
<sergiusens> kyrofa, so are you creating the PR to disable that test?
<kyrofa> sergiusens, do you agree that's the best way forward until we figure out a way to reproduce it?
<sergiusens> kyrofa, yes
<kyrofa> sergiusens, should I simply remove it from the examples test, or is there a way to just not run that one from debian/tests/control?
<sergiusens> kyrofa, there is a way; don't know the syntax
<kyrofa> elopio, do you have the magic?
<sergiusens> kyrofa, there's a filter command, maybe a reverse-filter option would do
<kyrofa> sergiusens, alright, researching!
<sergiusens> kyrofa, I'll take over it if you want
<kyrofa> sergiusens, nah, I don't know anything about this. That means I should
<kyrofa> sergiusens, unless you're in a hurry :)
<sergiusens> kyrofa, ok, look at example_tests/__main__.py
<kyrofa> sergiusens, thanks for the pointers!
<sergiusens> kyrofa, probably change debian/tests/exampletests and instead of ./runtests.sh just call python3 -m exmaple_tests --reverse-filter 'ros'
<sergiusens> kyrofa, or come up with a regex that matches everything but ros and just pass --filter
<sergiusens> kyrofa, something like '^(?!ros$).*$'
<sergiusens> kyrofa, hmm, I think I did it already :-P
<kyrofa> sergiusens, hahaha, alright, go ahead
<sergiusens> kyrofa, just need to add --filter at the end of the command
<kyrofa> sergiusens, oh, yeah I was just playing with that actually
<sergiusens> kyrofa, python3 -m examples_tests --skip-install --filter '^(?!ros$).*$'
<kyrofa> sergiusens, but examples_tests's main supports passing --filter
<kyrofa> sergiusens, and run-tests.sh passes $@ through
<sergiusens> kyrofa, yeah, it is a one line change
<sergiusens> ./runtests.sh examples --skip-install --filter '^(?!ros$).*$'
<kyrofa> sergiusens, yup, works fine
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/321
<ogra_> mvo, hmm, doesnt look like i got the right kernel snap :(
<ogra_> mvo, are you sure thats http://people.canonical.com/~ogra/snappy/dragonboard/tmp/canonical-dragon-linux_4.2.0-2012-generic-dragon410c_arm64.snap ?
<ogra_> anyway, need to run
<beuno> ogra_, the latest upload from mvo broke the store  :)
<beuno> the + sign in the version number is causing problems
<beuno> unlikely we'll get that fixed today, I'd suggest re-uploading with a non-+ version  :)
<mvo> ogra_: I re-uploaded with a "-1" instead of a "+1", fortunately that also counts as a higher version
<mvo> ogra_: should be in the store now
<mvo> kyrofa: hrm, hrm, thats a bug, I think I know what to do
<kyrofa> mvo, haha, sorry!
<sergiusens> elopio, kyrofa https://github.com/ubuntu-core/snapcraft/pull/322
<ogra_> mvo, still not :(
<ogra_> looks like it has the wrong initr
<ogra_> d
<ogra_> hmm, no ... seems to be the completely wrong one
<ogra_> ubuntu@localhost:~$ ls /lib/firmware/wlan/
<ogra_> prima
<ogra_> (there should be a "macaddr0" link in there pointing to /run/macaddr0)
<mvo> ogra_: hm, sorry, let me try harder
<ogra_> 903ded84656483c34616143dbf492f29  canonical-dragon-linux_4.2.0-2012-generic-dragon410c_arm64.snap
<ogra_> thats the md5
<ogra_> and
<ogra_> ogra@anubis:~/Devel/dragonboard$ md5sum xenial-chroot/snap/initrd.img-4.2.0-2012-generic-dragon410c
<ogra_> 24508f65cbdf05aa13e8613836d4609d  xenial-chroot/snap/initrd.img-4.2.0-2012-generic-dragon410c
<mvo> ogra_: a new version should be ready RSN
<ogra_> take your time :)
<mvo> ogra_: should be ready in edge now (for real this time)
<ogra_> heh
<kyrofa> sergiusens, elopio I'm off for the weekend. FYI monday is a holiday here
<sergiusens> kyrofa, enjoy!
<sergiusens> kyrofa, elopio adt passed \o/ http://autopkgtest.ubuntu.com/packages/s/snapcraft/xenial/amd64/
<kyrofa> sergiusens, awesome! A little bittersweet considering WHY it's all green now, but still awesome :)
<ogra_> beuno, are you able to push mvos last upload to stable from edge ? (the snap is good)
<Tertain> When using docker with ubuntu snappy, is it meant that the docker containers are using traditional ubuntu, or other distro as the base image?
<elopio> sergiusens: yay1!!
<ogra_> Tertain, totally your choice
#snappy 2016-02-13
<vir17> how can I install snapcraft 1 instead from the current version?
<faddat> I s there are recommended/standard way to do snappy by pxe?  I did see the mailing list bi5t
<faddat> but curious if anything has evloved since then
<faddat> also-- docker 1.6.0 in xenial is very weak sauce
<vir17> guys I try to install the webchat example and I get this error: webchat_0.0.1_armhf.snap failed to install: open /tmp/read-file224232084/unpack/meta/package.yaml: no such file or directory
#snappy 2016-02-14
 * ogra_ sighs ... webdm building is really a no-go on arm64 ... very sad
#snappy 2017-02-06
<swluo> helo?
<swluo> anyone here?
<swluo> hello?
<oky> hi swluo
<swluo> hey
<swluo> i was wondering if you could help me out with some library issues that i've been having
<swluo> is there any ways of editing the default SNAP_LIBRARY_PATH
<swluo> i'm getting errors when trying to load my shared libraries
<swluo> hey qengho
<swluo> hey jjohansen
<jjohansen> hey swluo
<swluo> hey man i was wondering if you can quickly help me out
<swluo> do you know if you can edit the default path of the SNAP_LIBRARY_PATH
<swluo> i'm having issues loading shared libraries
<jjohansen> swluo: sorry that is one I don't know
<swluo> mhmm thanks
<swluo> too bad
<swluo> the documentation could be a lot better for snap
<swluo> is it because its soo new?
<jjohansen> swluo: is this on trusty?
<swluo> nah 16.04
<swluo> like i can run it from command line just fine
<jjohansen> swluo: yeah snap is a moving target, so its hard to get good docs just yet
<swluo> but when i use the snap command it gives me library not ffound
<swluo> ahah yeah true true fair enough.
<swluo> "cannot open shared object file: No such file or directory."
<swluo> and i can't even make symlink for the default path with is annoying as well
<jjohansen> oh yes, confinement is great until it gets in the way, and then its at a minimum annoying, and usually a right pita
<oky> swluo: it's a symlinked binary and you have the libraries (shared objects) also being packaged?
<swluo> well ok like in the .yaml
<swluo> i've delcared build-packages: [libsdl2-dev]
<swluo> which should give me the proper libraries that it needs
<swluo> so i didn't package it together
<swluo> will that work?
<oky> i wouldn't know if it does or not. maybe you can look at what is in $LD_LIBRARY_PATH from inside your env
<swluo> aha its funny cause i tried that
<oky> if you open your snap, does it have the .so files that you'd expect?
<swluo> from the docs "snap run --shell <snap>.<command>"
<swluo> this commant should let me look at the env. but it also gives me errors
<swluo> no it does not. because i'm assuming its already downloaded
<oky> swluo: well, in most system, 'build packages' would not be included in the final output
<oky> for example, in debian, you have build deps which are only required for building the package (but not required for installing it), i might check if that is what is happening here
<oky> swluo: just fyi, i am new to snap, so i am not a reliable source of ideas / debugging
<swluo> yeah no worries
<swluo> anything helps
<swluo> just need to bounch ideas off someone
<swluo> like do you think it possible to just bundle the library with the snap?
<swluo> and somehow refer it then
<oky> swluo: can you check if it is building a statically linked binary or a dynamic library?
<swluo> its a dynamic library
<swluo> like i can't run it using the snap command
<swluo> but if i use the absolute path
<swluo> it runs just fine
<swluo> "concentration  /snap/concentration/x13/run: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory"
<swluo> so if i go "/snap/concentration/x13/run" it works
<oky> swluo: in your command wrapper, dump env using 'env' command and inspect the vars. compare your current LD PATH and see if where libSDL2 resides now is in the snap's paths
<oky> are you running as root or regular user? and is this a snap you are running via the 'try' command or is it installed?
<swluo> i'm regular user
<swluo> and its being installed everytime
<oky> swluo: i just did a search on google for 'snapcraft libsdl2' and came across your SO question, lol
<swluo> yeah ahaha!
<swluo> i'm at a hackathon soo time is kinda important
<mup> PR snapcraft#1106 opened: tests: check the CLA on all the commits <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1106>
<swluo> anyways how do you do a dump?
<swluo> from the command wrapper
<oky> swluo: add the line 'env'
<oky> swluo: ok, so: can you check to see if your stage/ has the library files? if it does (and the prime/ does not), you need to manually specify that they are copied over into the prime/
<swluo> i don't have any stage library files
<oky> where do they exist at all? how is it building?
<swluo> so i think i might need to manually copy it into prime
<swluo> its building all from parts
<swluo> its all building from just one make file
<oky> yeah, at each stage, you can specify which files to copy over to the next (or something like that)
<swluo> interesting yeah ok i'll try that thanks
<swluo> so basically we're back to the original idea of just shipping the library file with teh snap then
<swluo> ahah
<oky> that's how it would have to be done, though...
<oky> unless you are creating a statically linked binary
<swluo> mhmm ok maybe i'm just understanding it inocrrectly then
<oky> i think (and i'm not certain) that snaps are supposed to be runnable standalone (as though all necessary libraries are included with them)
<swluo> mhmm no that makes sense let me try some things out
<swluo> you've been great
<swluo> cheers
<oky> swluo: plz let me know if you get it working, good luck at the hackathon!
<swluo> yeah i'll update it here
<swluo> are you a fulltimer or a student?
<oky> swluo: fte
<swluo> where you working? i'm coop at blackberry rn ahahahah
<oky> swluo: at one of those big companies that no one likes
<oky> there are so many of them, now that i think about it
<swluo> ahahaha would you do something else if you could?
<oky> swluo: why do you ask?
<swluo> idk if this is the stuff i want to do in the future
<oky> swluo: i'm in charge of my self, atm, so i'm fine with how things are - i would not trade it, perhaps excepting for 50 mil
<swluo> like i'm good at it and its good money
<swluo> but i "love it"
<swluo> don't*
<oky> swluo: take your computer to a relationship counselor
<oky> tell the counselor that you've fallen out of love and need to rekindle the spark
<swluo> and like i'm just starting sooo its aiiyaaah
<swluo> mhmm rando strangers on the internet that my mom says i shouldn't talk to?
<oky> swluo: you should read "Disciplined Minds: A Critical Look at Salaried Professionals and the Soul-battering System That Shapes Their Lives"
<oky> or at least the wiki page on it
<swluo> damn the first review on amazon hit me like a truck.
<swluo> thanks for the advice ahah
<oky> actually, nvm - wiki page is terrible
<swluo> i just brought the book
<swluo> ... see this is what happens when you have too much money and no girlfriend to spend it
<swluo> btw oky thanks
<swluo> i figured it out you're right
<swluo> i included all the libraries using a stage
<swluo> https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/
<swluo> cheers
<oky> haha, awesome
<diddledan> just updated corebird-diddledan to corebird-1.4.2
<mup> PR snapd#2788 closed: store,osutil: use new osutil.ExecutableExists(exe) check to only use deltas if xdelta3 is present <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2788>
<mup> PR snapd#2780 closed: tests: increase snap-service kill-timeout <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2780>
<mup> PR snapd#2760 closed: merge release 2.22.1 into master <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2760>
<mardy> pstolowski: hi! Got a minute to talk about interface hooks?
<pstolowski> mardy, hi! sure
<mardy> pstolowski: so, I finally succeeded in getting my hook invoked :-)
<pstolowski> mardy, great! :)
<mardy> pstolowski: now the next question is, how to get information about the client, from within the hook of the socket
<mardy> pstolowski: I tried with "snapctl get", but it failed to read the attributes set on the plug
<mardy> pstolowski: I'm running this: snapctl get --plug :online-accounts manifest
<mardy> pstolowski: where "online-accounts" is the name of the interface, and manifest is an attribute set on this interface in the plug
<pstolowski> mardy, can you show me a complete hooks/ content?
<mardy> pstolowski: and I get this on stderr, when connecting: error: cannot add authorization: open /home/mardy/.snap/auth.json: permission denied
<pstolowski> mardy, that should generally work in my branch (i've a spread test with similar setup)
<mardy> pstolowski: I'll push the branch in a minute, I'll ping you
<mardy> pstolowski: bzr branch lp:~mardy/webapps-core/iface-hook-test
<mardy> pstolowski: the socket is snap/amazon/snapcraft.yaml
<mardy> pstolowski: the plug is snap/facebook/snapcraft.yaml
<pstolowski> mardy, socket == slot ;)
 * pstolowski was slightly confused for a moment
<mardy> pstolowski: indeed :-)
<pstolowski> mardy, no hooks files there, did you forgot to commit them?
<mardy> pstolowski: ehm... :-)
<mardy> pstolowski: ok, please pull again
<mup> PR snapd#2791 opened: store: use xdelta3 from core if available and not on the regular system <Created by mvo5> <https://github.com/snapcore/snapd/pull/2791>
<pstolowski> mardy, ok
<pstolowski> mardy, so, the problem is
<pstolowski> mardy, you want plug and slot names there, not the interface names; so this will be 'oa', not online-accounts. that applies both to the :names you pass to snapctl, and to the names of the files under hooks/
<pstolowski> mardy, or rename oa to online-accounts
<mardy> pstolowski: right, makes sense
<mardy> pstolowski: thanks a lot, I'll try that
<pstolowski> mardy, np. see my test snaps under tests/lib/snaps/basic-iface-hooks-* (in my MP) if in doubt
<mardy> pstolowski: btw, would it be possible to get an implicit attribute with snapctl, which is the name of the connecting snap?
<mardy> pstolowski: I mean, suppose that that plug doesn't declare any attributes; could the slot hook still infer some info about who's trying to connect?
<mardy> pstolowski: the use-case is that we want to make sure that the client really is what it claims to be
<pstolowski> mardy, i see what you mean. yes that's easy to do, i wonder if env variables would be good for that. i'll bring it up with niemeyer
<mardy> pstolowski: thanks
<mup> PR snapd#2763 closed: store: retry on 502 http response as well <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2763>
<mup> PR snapd#2761 closed: vendor: move gettext.go back to github.com/ojii/gettext.go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2761>
<adamlove> hi
<mup> PR snapcraft#1106 closed: tests: check the CLA on all the commits <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1106>
<mup> PR snapcraft#1105 closed: tests: rename the integration test snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1105>
<mup> PR snapcraft#1099 closed: catkin plugin: don't pass args to setup.sh <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1099>
<mup> PR snapcraft#1107 opened: meta: correct the deprecation for `setup/gui` use <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1107>
<lool> ogra_: heya
<ogra_> lool, yo
<lool> ogra_: what's the cleanest way to put a GRUB config snippet (override kernel cmdline) with the x86 images?
<ogra_> create your own gadget
<lool> is there no local way?
<ogra_> well, you asked for the cleanest :)
<lool> (I need it to survive upgrades)
<ogra_> you can surely just hack up /boot/grub/grub.cfg
<lool> ogra_: hehe, yes
<ogra_> we dont update bootloader configs on gadget upgrade currently
<ogra_> so whatever you do there should persist
<lool> ogra_: would you have an upboard by any chance?
<ogra_> nope, never heard of it
<lool> kind of a rpi from intel
<lool> http://www.up-board.org/
<lool> v2 isn't out yet
<ogra_> ah
<lool> some guys using it have trouble forcing the CPU to max freq, I'm trying to let them set cmdline options to disable it
<ogra_> lool, wont work ... we force the ondemand governor
<ogra_> from an ancient init.d script
<ogra_> (see /etc/init.d/ondemand )
<lool> ogra_: well unless we disable it from the kernel cmdline, no?
<ogra_> so the CPU will always scale down .. what they could do is build their own kernel with only performance in it
<lool> I was actually thinking of disabling the underlying implementation rather than the governor, /me digs the name
<ogra_> the script reads /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
<lool> intel_pstate=disable
<ogra_> if you can make it not appear there it should work
<lool> ogra_: for some reason, they can't even set the "performance" governor on this board (it appears, but can't be selected)
<lool> my devices here use ACPI, but they have a more recent Intel embedded CPU which does this pstate stuff
<ogra_> hmm, thats weird ...
<ogra_> yeah, i'm not very familiar with pstate vs cpufreq yet ... i'd ask cking
<ogra_> (i dont really have newer intel systems here, only ARMs :) )
<lool> well ARM is the new Intel!
<lool> soon we'll be looking at some other architecture which is more embedded and wants to displace ARM!  ;-)
<ogra_> hehe
<zyga> lool: let's skip mips and go to risc ;-)
<ogra_> no risc, no fun
<zyga> but low-risk risc is fun
<davmor2> lool: just get a reflex hammer and strike arms elbow that'll displace it
<lool> zyga: I was thinking something lower tech like stones
<lool> take two piles of stones together to make an addition
<lool> remove stones to make a substraction
<lool> throw stones to make a function call
<zyga> ubuntu for forests and quarries?
<mup> PR snapd#2792 opened: tests: add spread test for delta downloads <Created by mvo5> <https://github.com/snapcore/snapd/pull/2792>
<mup> PR snapd#2779 closed: tests: gruntwork backend and suite; task for sync snapd with vendor <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2779>
<zioproto> hello #snappy. Can I get help here in pushing packages to the Ubuntu Store ? I have this package with confinement classic that I cant push
<zioproto> anyone can help me with this ? :) https://myapps.developer.ubuntu.com/dev/click-apps/6815/rev/4/
<uijnoinompo> join
<popey> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662181 is this expected behaviour? People have to enable each alias individually?
<mup> Bug #1662181: Aliases didn't enable out of the box <snapd (Ubuntu):New> <https://launchpad.net/bugs/1662181>
<popey> zioproto: hello, i think jdstrand is the one to ask about that - I note he already replied to one of your uploads though.
<morphis> ogra_: when did we drop ppp from the core snap?
<morphis> ogra_: we have a dependency on it from the modem-manager snap
<morphis> that is why we created the ppp interface
<zioproto> popey, do you mean 'This snap is using 'classic' confinement. At this time we have the technical implementation for how to implement classic confinement but the processes for when to grant acceptance in the store is still being worked out. This is actively being discussed and we'll get back to you once the store acceptance policies are defined.'   ????
<zioproto> popey, that is a bot answering
<popey> zioproto: no, jdstrand is a person :)
<popey> ooh, speak of the devil
<popey> jdstrand: when you have a moment, zioproto is asking about https://myapps.developer.ubuntu.com/dev/click-apps/6815/rev/4/
<jdstrand> popey: that is actually something for ev
<popey> ah okay.
<popey> thanks
<jdstrand> np
<zioproto> who is ev ?
<zyga> zioproto: evan, why?
<popey> zioproto: I'm discussing with him, I'll get back to you asap
<zioproto> okay
<zyga> jdstrand: hey, I'm ill today; if you have some time please look at C patches, otherwise I'm semi-useless and not making much code
<zyga> jdstrand: I know that the kernel has a way to convey bind mounts to userspace now
<zyga> jdstrand: I'm coding a routine that does that
<mup> PR snapd#2793 opened: Add Maliit input method interface <Created by Elleo> <https://github.com/snapcore/snapd/pull/2793>
<mup> PR snapcraft#1103 closed: meta: support for the environment keyword <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1103>
<jdstrand> zyga: hope you get better soon
<zyga> thanks
<mup> PR snapcraft#897 closed: pluginhandler: use an alternate location to organize <Created by josepht> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/897>
<mup> PR snapcraft#1064 closed: pluginhandler: support colliding with directories <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1064>
<jdstrand> mterry: hey, working through the unity8-session store reviews. note that until the PR lands, I don't think we should issue a snap declaration for unity8 (I'm not sure of the side effects that would have on systems without unity8). I see you already are using only 'mir', and I issued a snap declaration for that
<mterry> jdstrand: sorry, you mean allowing unity8-session snap to have those slots?
<jdstrand> mterry: I also see that you are using top-level 'slots'. This gives all commands PermanentSlot policy for the mir server. I'm quite sure you do not want this. Please add 'slots: [ mir ]' to the command that needs it
<mup> PR snapcraft#904 closed: cleanbuild: use pylxd instead of lxd command line <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/904>
<jdstrand> mterry: unity8-session is now allowed to use slot mir
<jdstrand> mterry: I think we should wait for it to slot unity8 until the PR lands
<mterry> jdstrand: yeah that was because I needed to talk to tedg_ about which of the commands actually need it, but noted
<mterry> jdstrand: yah agreed -- I took out the slot
<jdstrand> mterry: you are going to receive a few rejection emails until we hit the upload that only slots mir
<mterry> Huh...  I was under the impression I had already built and uploaded one of those
<jdstrand> it's going to take a few minutes
 * mterry rebuilds a new snap
<mterry> I mean, I did that on Friday
<jdstrand> mterry: you did, but the way the store works is this is a queue of uploads. I need to reject each one that is queued before it
<mterry> oh ah
 * mterry doesn't build a new snap then
<jdstrand> it'll be a few minutes before we are there (fyi, the store team will be improving this process for reviewers)
<ogra_> kgunn, http://imgur.com/a/ddqjQ Pi2 ubuntu-core running the unity8-session snap !!!
<ogra_> (right monitor)
<kgunn> nice!
<ogra_> there are font issues and the top panel is completely transparent .... tha console is also spilled with lots of failing/respawning  upstart jobs
<kgunn> ogra_: i didn't think pi2 had the right stuff for gpu...
<ogra_> but its the first time i get something on display with that snap
<kgunn> only pi3
<kgunn> very cool
<ogra_> i made sure both do now :)
<ogra_> after all the changes were identical
<kgunn> and yeah, lots of spew
<kgunn> re upstart jobs
<ogra_> yep
<jdstrand> nessita: fyi, bug #1662218
<mup> Bug #1662218: Please email store reviewers with changes to classic confinement <Software Center Agent:New> <https://launchpad.net/bugs/1662218>
<jdstrand> nessita: and hi!
<nessita> jdstrand, hi! I would have thought we did that already, but let me check and/or raise the issue. Thanks!
<nessita> roadmr, ^
<jdstrand> nessita (roadmr): if you look at the 'Package declaration update' email, it lists plugs, slots, auto-aliases and refresh-control, but not classic. I can't recall ever seeing and email for changes to classic confinement
<roadmr> right nessita jdstrand maybe we did that for the other things and not classic... ugh sorry
<cory_fu> jdstrand: Thanks for the approval on the juju-crashdump snap.  I had a question re: your comment about LP builds.
<cory_fu> I tried to have it build on LP, but it's failing except on ppc64el: https://code.launchpad.net/~johnsca/+snap/juju-crashdump
<jdstrand> cory_fu: that seems like a question for the LP team based on, for example, https://launchpadlibrarian.net/305075153/buildlog_snap_ubuntu_xenial_arm64_juju-crashdump_BUILDING.txt.gz
<cjwatson> known bug
<cjwatson> https://bugs.launchpad.net/launchpad-buildd/+bug/1650946
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1650946>
<cory_fu> cjwatson: Ok, thanks
<cory_fu> How long after releasing a snap to the stable channel should I be able to see it in `snap find`?  Is there something I can run locally to force a refresh?
<cjwatson> Planning to attack that later this week; just need to get an ack from Sergio on the basic approach first
<balloons> nessita, might you be able to transfer ownership of the juju snap between ubuntu one accounts?
<nessita> balloons, hello! yes, I can do that. What would be the target account?
<nessita> balloons, also, please send me an email with the request so I can keep track of the transfers, I'd need source account and target account, with some consent from the target account in there
<balloons> nessita, will do. I'll cc both accounts and yourself so you can see consent
<nessita> balloons, thank you!
<aisrael> stokachu, here
<stokachu> whats the best way to get someone who is has ubuntu-core snap installed migrated to the latest core snap?
<stokachu> they're on snapd 2.21
<stokachu> he can't remove the ubuntu-core snap and snap refresh/install does not seem to handle upgrading from ubuntu-core to core
<stokachu> would a simple apt-get remove snapd and reinstall work?
<stokachu> zyga, ^ any idea here?
<aisrael> stokachu, I removed and reinstalled and now I can install core (previously installed snaps were gone)
<stokachu> aisrael, ok cool
<stokachu> may be worth trying to reinstall conjure-up now
<stokachu> before you do a build
<stokachu> aisrael, ^
<ogra_> stokachu, yes, that works but removes all already installed snaps alongside ... so handle with care ;)
<stokachu> ogra_, is there any upgrade path?
<aisrael> stokachu, There were a few leftover symlinks in bin I had to remove. With those gone, conjure-up installed and works
<stokachu> aisrael, \o/
<ogra_> mvo works on that ... not sure whats the target release for it though
<mvo> stokachu: you want to transition ubuntu-core to core?
<stokachu> mvo, yea we had a user aisrael who still had ubuntu-core on his system
<ogra_> they already did by reinstalling snapd ...
<stokachu> mvo, yea he reinstalled snapd which wasn't an issue for him but i was curious what the upgrade path is
<mvo> stokachu: please try the snapd from -proposed or run "snap refresh --candidate ubuntu-core" for re-exec magic
<stokachu> mvo, ah ok, ill make a note if anyone else runs into that
<mvo> stokachu: thank you, please do. keen to get feedback on the auto-migration :)
<stokachu> mvo, is there a way i can manually reproduce?
<stokachu> can i snap install ubuntu-core on a fresh xenial system with 2.21?
<mvo> stokachu: so far it works well but it seems relatively few people are astill having ubuntu-core
<stokachu> mvo, yea this was the first case i ran into where someone was still on ubuntu-core
<mvo> stokachu: yes, if you have nothing installed you can snap install ubuntu-core
<stokachu> mvo, cool ill give it a shot and let you know if i run into an issue
<mvo> stokachu: then you can upgrade your snapd or install a newer ubuntu-core that contains the re-exec magic and it will auto-transition you
<mvo> stokachu: great, thank you
<stokachu> mvo, ah so his issue was he couldnt snap install ubuntu-core
<stokachu> or snap refresh ubuntu-core
<mvo> stokachu: ohh
<stokachu> mvo, snap refresh just told him no updates available
<mvo> aisrael: hey, if you were affected by the problem with not being able to install/refresh ubuntu-core, could you please pastebin "journalctl -u snapd" (or mail that output to me). that hopefully gives me a clue why the system behaved strangely
<mvo> stokachu: snap changes should show a transition, it may take up to 10min though to start
<stokachu> mvo, oh i learned a new command
<mvo> stokachu: please paste the snap --version output here so that I can check if the version you have supports the auto migration already
<stokachu> snap    2.21
<stokachu> snapd   2.21
<stokachu> series  16
<stokachu> ubuntu  16.04
<mvo> stokachu: snap changes is cool, you can also see the individual changes via "snap change N" (with N being the one you want to see)
<mvo> stokachu: aha, that is not recent enough, you will need 2.22.X, either from xenial-proposed or "sudo snap refresh --candidate ubuntu-core"
<mvo> stokachu: with either one of those the next snap --version output should be higher
<stokachu> mvo, ah that is it then
<stokachu> yea we're both on 2.21 still
<mvo> stokachu: aha, ok. the journal output for snapd from the broken system should have hints what went wrong. i need to leave for dinner now but you can mail it to me at mvo (at) ubuntu.com
<mvo> and I have a look (or I will read scrollback when I return :)
<stokachu> mvo, sure ill get another system going
<test__> ping elopio: test from quassel-webserver snap
<stokachu> mvo, https://gist.github.com/battlemidget/e55498a759f14b865c2bfe1e410a022c thats where i ended up at
<mvo> stokachu: thanks, lets talk tomorrow but I think snapd 2.22.X will fix it automatically for you
 * mvo waves and leaves for dinner
<mup> PR snapcraft#1108 opened: Add support for LTS Channels <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1108>
<stokachu> yea installing snapd 2.22 from proposed cleaned up my core snaps without an issue
<stokachu> doh he left already
<cory_fu> I released my snap to the stable channel a couple of hours ago, but still can't install it.  Re-released via snapcraft per the docs and it still doesn't work.  http://pastebin.ubuntu.com/23942129/  Any suggestions?
<ogra_> cory_fu, did you check on the store page ?
<cory_fu> ogra_: I originally released it via https://myapps.developer.ubuntu.com/dev/click-apps/6876/ and it still says that it's published
<ogra_> and it is published in the stable channel ?
<cory_fu> ogra_: Yes (see pastebin)
<cory_fu> ogra_: NB: it is a classic snap, if that makes a difference
<ogra_> oh, it surely does ... i think classic snaps need manual approval in the sotre
<ogra_> *store
<cory_fu> ogra_: It was approved by jdstrand
<mhall119> jdstrand: browser-support is triggering a manual review for a daemin app, I believe I needed it for NodeJS (or somethingJS) that's used by the daemon
<mhall119> is there a security concern about allowing that interface for daemons without review?
 * mhall119 thinking back, I believe it wasn't NodeJS itself, but something else couchdb does with js, so maybe there aren't that many cases where this will happen
<cory_fu> ogra_: Any other advice?  :/
<ogra_> cory_fu, well, if the version shows a green box in the UI and you have a channel listed in the details of the version then i dont know
<cory_fu> ogra_: Oh, I figured it out!  I had only released the ppc64el version that had managed to successfully build on LP, so it wasn't showing up for me due to arch mismatch
<ogra_> aha !
<ogra_> yeah, i see it :)
<ogra_> congrats !
<cory_fu> ogra_: Thanks, and thanks for your help
<ogra_> the store UI is an adventure game at times :)
<cory_fu> :)  It told me the info I needed, but it just wasn't very prominent
<ogra_> yep
<mup> PR snapcraft#1109 opened: LP #1662240 (define post-stop-command) <Created by elespike> <https://github.com/snapcore/snapcraft/pull/1109>
<jdstrand> mhall119: note, this is a warning, not an error (no difference for human review of course). the browser-support interface is a transitional interface for full-on web browsers (eg, chrome, firefox, webbrowser-app, etc) and it would be unusual for a server to embed a complete web browser. can you remove 'browser-support' and show me the denials?
<mup> PR snapcraft#1107 closed: meta: correct the deprecation for `setup/gui` use <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1107>
<jdstrand> mterry: ok, all revisions with only slots: mir are approved but not released
<jdstrand> (and the other rejected)
<mhall119> jdstrand: = Seccomp =
<mhall119> Time: Feb  6 13:22:11
<mhall119> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=32209 comm="couchjs" exe="/snap/couchdb/x15/rel/couchdb/bin/couchjs" sig=31 arch=c000003e 141(setpriority) compat=0 ip=0x7f465ca61177 code=0x0
<mhall119> Syscall: setpriority
<mhall119> Suggestion:
<mhall119> * add one of 'browser-support, process-control' to 'plugs'
<mterry> jdstrand: I don't think I have access myself to the store page -- will future auto-uploads pass through without the manual review process?
<mhall119> fwiw, it's only happening when I try to run couchdb's builtin health check
<mterry> jdstrand: (thanks for clearing the queue btw)
<jdstrand> mterry: yes. if you want, I think I can press the 'release' button
<mterry> jdstrand: sure that saves a rebuild, thanks!
<jdstrand> mhall119: use process-control instead, not that 2.23 will have policy that may allow you to drop process-control
<jdstrand> s/not/note/
<mhall119> thanks jdstrand
<linuxhiker> Is there a way to see what platforms a particular snap is available for?
<jdstrand> mterry: ok, released all to 'edge'
<mterry> cheers
<linuxhiker> Would that be a no?:D
<mup> PR snapd#2784 closed: image: check kernel/gadget publisher vs model brand, warn on store disconnected snaps  <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2784>
<balloons> stokachu, did you see my note about bash completion with your snap?
<stokachu> balloons, nah
<stokachu> balloons, you get it working?
<balloons> stokachu, I couldn't get what you'd check in to build, but I believe it will work with the addition I made
<stokachu> balloons, you got a diff or PR for me?
<balloons> stokachu, sure. Let me find the repo
<stokachu> balloons, if we get this working are we advertising pure snaps for the next release announcement?
<balloons> it has my vote stokachu
<stokachu> yay
<stokachu> balloons, im getting a testsuite done this week too
<stokachu> balloons, ill take a diff to whatever is easier for you
<stokachu> or just the entire file and ill merge it
<balloons> stokachu, basically you are missing the bash completion file for 'juju'. It needs to be named 'juju'
<balloons> as that is what it will go looking for. The 2 bins we're shipping (well, one bin for you I guess?) is juju and juju-2
<balloons> found the diff
<balloons> stokachu, https://pastebin.canonical.com/178372/. You can see I had trouble with the source dump location. But I trust the rest more or less makes sense
<balloons> stokachu, essentially cp etc/bash_completion.d/juju-2 $SNAPCRAFT_PART_INSTALL/usr/share/bash-completion/completions/juju
<balloons> I *think* that will make it work
<stokachu> ah i think i did that earlier
<stokachu> lemme double check
<stokachu> balloons, building again but i did already do this one min
<stokachu> balloons, make sure you're using snapcraft from master
<stokachu> just git clone https://github.com/snapcore/snapcraft; and access snapcraft/bin/snapcraft
<stokachu> balloons, once you do that then clone https://github.com/conjure-up/conjure-up and try to build again
<stokachu> that should work
<balloons> stokachu, ahh, the snap/snapcraft is supported now
<stokachu> yea
<balloons> cool, so I can play more if needed
<stokachu> yea im building the latest now and going to test it again
<stokachu> balloons, yea that change didnt work either :(
<stokachu> no idea what im missing
<Blu2> ohmygiraffe update :D
<stokachu> anyone else familiar with bash completion inside a snap?
<mcphail> stokachu: I've been wondering how to implement that!
<stokachu> we copy our files here: https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L63-L65, and source them https://github.com/conjure-up/conjure-up/blob/master/snap/wrappers/juju#L8-L9
<stokachu> mcphail, yea we're hitting some kind of issue even after we source the completion
<stokachu> mcphail, ^ should give you some kind of idea of how we're doing it if youre curious
<stokachu> just doesn't work quite yet
<mcphail> stokachu: cheers! I'll have a look
<mcphail> stokachu: that way isn't going to work, though, is it? Surely that will just source the completion from the subshell, rather than the shell you're using to call the program?
<stokachu> mcphail, ah
<stokachu> yea bash completion would need access to the binary and not the wrapper
<stokachu> hmmmm, what if i put it in /etc/bash_completions.d/
<mcphail> stokachu: completion is done by the shell you use to call the snap. But completion isn't loaded into that shell. You'd need access to a completions directory, as you say
<mcphail> (and that isn't allowed, afaik)
<stokachu> mcphail, we use a classic snap so maybe we can?
<mcphail> stokachu: aah. I haven't looked at classic snaps yet
<stokachu> does bash completion have a ENV variable we can alter?
<Blu2> I noticed that snaps are not allowed to link to a website using the default browser
<stokachu> i couldnt find anything in the docs about it
<mcphail> stokachu: you know /etc/bash_completions.d/ is deprecated for all packages anyway?
<stokachu> mcphail, ah i do now :)
<mcphail> `pkg-config --variable=completionsdir bash-completion
<mcphail> should give the up-to-date one
<stokachu> ah perfect
<stokachu> so we put those completion in that directory now
<stokachu> but that's within the snap
<mcphail> Yes. Nothing useful is going to see that
<stokachu> and there doesn't seem to be a way to make bash completion look in an alternative directory
<mcphail> I think there needs to be a hook for completions
<balloons> stokachu, I also got the snap built, but it's not providing juju
<stokachu> balloons, you gotta run snap alias
<stokachu> balloons, and make sure you dont have the deb juju installed otherwise it'll make you think you got it working :)
<balloons> stokachu, sorry snap lied: snap list aliases error: no matching snaps installed. Trying again, I suddenly see the aliases for conjure-up and lxd
<stokachu> balloons, ah
<balloons> stokachu, nothing in /usr/share/bash-completion/completions/
<balloons> so the hook didnt work. this is the problem I had
<stokachu> balloons, yea they would be in $SNAP/usr/share/bash-completion/completions
<balloons> they can't go there. They need to be in the right place
<stokachu> so you could try taking out $SNAPCRAFT_PART_INSTALL
<stokachu> it'd have to go in a different hook though not the install
<stokachu> i think mcphail is correct though there needs to be a hook for it
<stokachu> they have to live outside of the snap
<stokachu> balloons, we could put it in the hooks/configure script
<balloons> stokachu, yes, I was trying in the configure hook
<balloons> I thought you were too
<stokachu> oh lemme check
<stokachu> maybe i did
<balloons> I just hit build, I've no idea :p
<stokachu> building now i didnt have it in there
<stokachu> balloons, pushed a new update to the master branch
<stokachu> that copies the files to the hosts system
<stokachu> balloons, so that section where it's detecting which juju binary to use
<stokachu> balloons, https://github.com/juju/juju/blob/staging/etc/bash_completion.d/juju-2.0#L339-L350
<stokachu> balloons, do you need to add the /snap/bin/juju path too?
<stokachu> balloons, yea changing the last line's path to /snap/bin/juju makes it all work
<balloons> for realz?
<stokachu> balloons, yep
<balloons> woot
<stokachu> balloons, so if you could get the updated completions pushed to branch 2.1 ill rebuild with it all
<stokachu> or i can just include it as a file in the snap
<stokachu> i can also make a new section and just pull from juju master for the completion stuff
<mup> PR snapcraft#1101 closed: misc: consistently use a dash for copyright years <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1101>
<balloons> stokachu, hmm, let's have a think
<balloons> I need the same for the juju snap
<stokachu> balloons, yea
<stokachu> balloons, worse case i can do some sed magic to replace /usr/bin/juju with /snap/bin/juju
<balloons> stokachu, ok, so it's what I was thinking. We should just add a check for /snap/bin/juju as well
<balloons> It checks $gopath as well for example
<stokachu> balloons, yea
<mup> PR snapd#2789 closed: overlord/devicestate: backoff between retries if the server seems to have refused the serial-request <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2789>
<balloons> stokachu, awesome. So we have a complete snap story then?
<stokachu> balloons, yep just as soon as you update the bash completion in the upstream code
<stokachu> i can pull that down and install it
<balloons> I'll make a PR with it and the tweaked snap
<stokachu> balloons, cool once that lands we'll be in good shape
<balloons> stokachu, did you push what worked for you for conjure-up?
<stokachu> ill create a seperate section to pull from master for it as well unless you think it'll make it into the beta5 branch?
<stokachu> balloons, yea thats pushed upstream
<mcphail> stokachu: you got it working?
<stokachu> mcphail, yea, basically what you said we had to put it in the hooks/configure in the snap build
<stokachu> and install it to /usr/share/bash../
<mcphail> stokachu: aah. Is tehre any way to clean it up if the snap is removed? Thinking we really do need some form of hook
<stokachu> mcphail, unfortunately there isn't a cleanup hook for snaps, it has been asked a few times to incorporate that so i think that discussion is ongoing
<stokachu> a uninstall hook would be nice
<stokachu> i think the fear is making building snaps to complicated by going down that road
<mcphail> stokachu: shame. Would be nice to have that. I'll need to check out these classic snaps. Seems to give more freedom
<stokachu> mcphail, yea tons of freedom though at a cost like what you see here
<mcphail> Ideally, it would be good to have a hook to deal with completions/man pages etc
<stokachu> mcphail, so i think mayb esomething like https://github.com/snapcore/snapd/wiki/Content-Interface
<stokachu> though i don tknow if that addresses the issue of putting it outside the $SNAP
<mcphail> stokachu: Don't think that is a complete solution, but is certainly a start. Would be interesting to have a virtual filesystem overlaid on the completions directory which would give access to these slots
<stokachu> that would be cool
<stokachu> balloons, ping me when you get a pr up so i can subscribe to it
<Fohlen> heya there. I have an application that builds a binary folder with plenty of assets it as well needs to start the executable in the bin* folder. I didn't yet understand how am I supposed to copy the folder from my parts into the stage and the command does not ship a make install command
<mup> PR snapd#2794 opened: tests/lib/fakestore/refresh: some more info when we fail to copy asserts <Created by pedronis> <https://github.com/snapcore/snapd/pull/2794>
<qengho> Fohlen: Hi! Is the build system unique?
<Fohlen> qengho: it's conan
<Fohlen> and produces cmake in the end
<Fohlen> https://www.conan.io/
<qengho> Ah, I know cmake.
<Fohlen> basically what I would like snap to do is copy the bin folder and make it executable
<qengho> Fohlen: Put your snapcraft.yaml in a pastebin so we can see. Someone, perhaps not me, might have an idea what you need to do.
<Fohlen> http://pastebin.com/HEb3z1Sv
<mup> PR snapcraft#1110 opened: Show error messages for snap processing errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1110>
<robert_ancell> Is ./run_checks no longer used for snapd? It's reporting bad formatting in master
<qengho> Fohlen: Hi. First, you probably don't need your "stage-packages" as staged packages, because those are ones that go into your snap. You only need most of those for building. That's a different object, "build-packages:", I think.
<qengho> Fohlen: Then, your filesets: object doesn't do anything. That just gives some things a name "binaries", and you don't use that name anywhere.
<Fohlen> qengho: http://pastebin.com/Dfebej1d
<Fohlen> trying this now.
<mup> PR snapd#2795 opened: Only add aliases field when we have aliases <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2795>
<mup> PR snapd#2794 closed: tests/lib/fakestore/refresh: some more info when we fail to copy asserts <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2794>
<oky> which org is behind snapcraft, btw?
<oky> is it canonical? what is yocto?
<mup> PR snapcraft#1111 opened: tests: rename the waf test snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1111>
<kyrofa> oky, indeed, canonical is behind snapcraft
<oky> kyrofa: ok, interesting. is there a discussion of the potential downsides of snapcraft that i can refer to? just things to know before i use it
<oky> (common pitfalls would be useful, too)
<kyrofa> oky, all the docs are on snapcraft.io
<oky> i think i've read a lot of them, curious to find things like project philosophy and motivation
<oky> (i do see snapping philosophy doc, don't worry)
<kyrofa> oky, perhaps its README would be helpful? https://github.com/snapcore/snapcraft
<oky> kyrofa: it is, yes - but it seems like perhaps there were a lot of design docs or internal discussion that
<oky> is unavailable
<kyrofa> oky, I'm not really sure what you're looking for then, I'm sorry
<oky> kyrofa: things like: "what is current support on other distributions", "what are potential downsides of using snaps", "how do pin a snap to a specific version", "who is doing the vetting"
<kyrofa> oky, snapcraft is only a packager of snaps. It sounds like you're looking for the philosophies behind snaps themselves
<oky> i really like what i am seeing about snaps, they appear to be recipes that create statically installable packages akin to .dmg files
<oky> kyrofa: yes, that must be it
<kyrofa> That's like expecting pbuilder to document the rational behind the deb format
<oky> kyrofa: so, there's a seperate site for docs on snaps?
<oky> kyrofa: i'm not blaming or accusing, just looking for more info - and yes, i am confused about the two names. i've seen snappy, snap, snapd and snapcraft. the only docs i've read are the snapcraft ones
<kyrofa> oky, there isn't one place that answers all your questions, but I can point you in a few different directions to obtain answers
<oky> kyrofa: thanks!
<kyrofa> oky, first of all, the current distro support matrix is here: https://github.com/snapcore/snapd/wiki/Distributions
<mup> PR snapcraft#1112 opened: core: setup core to support classic confinement <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1112>
<kyrofa> oky, as far as potential downsides, there are a few AskUbuntu questions about them but the answer is really opinion-based
<kyrofa> oky, there are a few downsides I can list off: dependencies are bundled so they tend to be larger than, say, a deb would be. Developing them can be a little different because, as you noted, they are read-only images with defined writable areas and not all software is used to working that way
<kyrofa> I'm not sure pinning is supported, but there are some features coming that will get you closer
<kyrofa> As far as who is doing the vetting, I'm not quite sure I understand the question
<oky> kyrofa: the concern with 'pinning' is regarding having a set of packagers with expertise vetting their work vs. anyone self publishing. with packagers, its a little more assured that new version should not break things, but self publishing leads to weirdness with deps between parts, etc
<kyrofa> oky, there are no dependencies with snaps, at least not in that sense
<oky> pinning (or custom repos) appears to be a compromise to sticking to a specific version (and having that version available at some later data, ideally), which is why i asked about it
<oky> kyrofa: even if there are no direct deps or compile time, there inevitably will be deps or linked packages (imo)
<kyrofa> oky, of course, but they're contained within the same snap
<oky> kyrofa: interesting, ok - so, the store would have many different versions for each package depending on the config desired
<oky> kyrofa: thanks for taking the time
<kyrofa> oky, that depends on the package I suppose
<kyrofa> oky, for example, there's a Nextcloud snap that bundles mysql and apache. There is _not_ a nextcloud snap that uses nginx instead
<kyrofa> Nothing is stopping that, but nextcloud only supports that one setup
<oky> kyrofa: i'm thinking of an example more like: package + data dependencies. maybe there is a package of geoip data and you can buy addon packs
<oky> anyways, it's all tangential - not that important to my other questions
<kyrofa> oky, that's probably a use-case for the (very limited) sharing that can happen between snaps. That's called the `content` interface
<oky> it seems like the snaps should ideally prevent lots of bugs and make it so that security flaws in out dated libraries are still contained in what damage they can do
<kyrofa> Indeed
<oky> so in the end, its still an improvement in security (maybe)
<kyrofa> That's the idea anyway
<oky> i was trying to imagine what happens when the next large networking bug comes along and threatens a bunch of packages
<kyrofa> oky, well, let's walk through that using the Nextcloud example
<kyrofa> oky, let's say the bug was so bad as to grant a shell with the Apache permissions
<bdmurray> lsb_release crashes on Ubuntu Core 16 - where should that be reported?
<kyrofa> Which is pretty much as bad as it can get
<kyrofa> What happens?
<bdmurray> http://pastebin.ubuntu.com/23944029/
<oky> kyrofa: how does nextcloud enforce that the user is 'apache' user?
<oky> i'm looking through https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml to see how they manage permissions
<kyrofa> oky, nope, it's root
<kyrofa> oky, however, even though it's root it's still under confinement
<kyrofa> oky, which means they can access the network and the writable areas of the snap
<kyrofa> oky, they can't alter anything contained within the snap because it's by definition read-only
<oky> kyrofa: and the confinement is via SElinux? ima? app armor?
<kyrofa> appamor, seccomp, and cgroups
<kyrofa> oky, the worst they can do is mess with the data of the nextcloud snap. They can't touch the rest of the system
<kyrofa> oky, and there's nothing they can do to prevent the next snap update from happening, which would hopefully contain a fix
<oky> kyrofa: and does app armor support integrity checks via hardware? (TPM, for example)
<kyrofa> That I don't know
<oky> ok, it's also tangential
<mup> PR snapd#2796 opened: Fix checks failing on code formatting <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2796>
<kyrofa> oky, also, to clarify terminology: snapd is the daemon behind the snap format. It's in charge of mounting snaps into place, running their services, handling updates, etc
<oky> kyrofa: thanks for all the info, i'm looking forward to seeing wider adoption on other platforms
<kyrofa> oky, snapcraft is a packager. It allows one to create snaps
<kyrofa> oky, "snappy" is just referring to the whole system
<oky> kyrofa: ok, i'll try to remember their distinct usages
<mup> Bug #1662357 opened: Can't use lsb_release on Ubuntu Core 16 <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):New> <https://launchpad.net/bugs/1662357>
<mup> PR snapcraft#1111 closed: tests: rename the waf test snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1111>
#snappy 2017-02-07
<mup> PR snapcraft#1113 opened: repo: cache stage packages for faster future use <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1113>
<liuxg> ogra_, I am now using your proxy snap for building snap. when I build nodejs project, it still downloads the node-v4.4.4-linux-x64.tar.gz from internet. it is not cached. is there any way to solve the problem? it is really slow.
<mup> PR snapd#2771 closed: debian: update changelog from releases 2.22.{1,2} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2771>
<mup> PR snapd#2558 closed: snapstate: move refresh from a systemd timer to the internal snapstate Ensure() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2558>
<mup> PR snapd#2764 closed: tests: disable ubuntu-core->core transition on ppc64el (its just too slow) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2764>
<mup> PR snapd#2754 closed: tests: improve debug when the core transition test hangs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2754>
<mup> PR snapd#2772 closed: interfaces: allow nice/setpriority to 0-19 values for calling process by default <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2772>
<mup> PR snapd#2750 closed: interfaces/default: don't allow TIOCSTI ioctl <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2750>
<mup> PR snapd#2796 closed: Fix checks failing on code formatting <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2796>
<mup> PR snapd#2797 opened: tests: stop tying setting up staging store access to the setup of the state tarball <Created by pedronis> <https://github.com/snapcore/snapd/pull/2797>
<mup> Bug #1662452 opened: A snap tries to continue setting up a systemd service, even if download failed <Snappy:New> <https://launchpad.net/bugs/1662452>
<log-snap> hi there just wanted to include an icon as mentioned here [1], but snapcraft calls it unexpected. Was "icon" deprecated? And how do i include my icon now? .desktop?
<log-snap> 1: https://snapcraft.io/docs/build-snaps/metadata
<mup> PR snapd#2757 closed: tests: add regression spread test for #1660941 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2757>
<mup> PR snapd#2798 opened: interfaces/builtin: instead of just /proc/bus/pci/devices allow full read access on /proc/bus/pci <Created by morphis> <https://github.com/snapcore/snapd/pull/2798>
<morphis> mvo: can you add the PR above for 2.23?
<mvo> morphis: sure
<morphis> mvo: thanks!
<mup> PR snapd#2799 opened: tests: fix pattern and use MATCH in find-private <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2799>
<mup> PR snapd#2795 closed: Only add aliases field when we have aliases <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2795>
<ogra_> liuxg, well, my packageproxy only operates .deb packages ... i suspect you would have ot hack up the nodejs plugin to use a local tarball for this
<liuxg> ogra_, yeah, this is too troublesome.. the developers in my last sprint was desperate in downloading the package again and again.
<ogra_> liuxg, well, the plugins are only python. cant be to hard to make this one use a local tarball instead of downloading it
<ogra_> liuxg, also file a bug so the snapcrafters can add an option for this
<ogra_> there is one :)
<liuxg> ogra_, yeah, I will do it. thanks. really? what is the bug number?
<zyga> I thin the issue is that snapcraft often requires "gah, doesn't work - snapcraft clean" workflow
<ogra_> sergiusens, is it somehow possible to prevent the nodejs plugin from downloading the tarball all the time ?
<zyga> and then you are stuck with downloading over and over
<ogra_> liuxg, i said you should file a bug :)
<liuxg> ogra_,  OK. I will do that, thanks
<ogra_> zyga, right, but you should be able to make it skip the downloading and make it use a local version of the tarball
<ogra_> that cant be to hard
<zyga> ogra_: no, it just just be smarter
<sergiusens> ogra_: implementing a fix for the bug ev logged a while back will do the trick
<ogra_> zyga, what if you dont want to download it at all ?
<mup> PR snapd#2797 closed: tests: stop tying setting up staging store access to the setup of the state tarball <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2797>
<zyga> ogra_: you don't want to hand-hold the process, you just want the process to be less silly
<ogra_> smartness wont help
<zyga> ogra_: I don't understand what you mean,
<zyga> ogra_: if your snapcraft is offline then it will work offline
<zyga> ogra_: if it is not offline, you need to get them
<zyga> ogra_: and be super smart on caching
<sergiusens> ogra_: I am going to implement something similar to the python plugin where if it is staged (dump it) you won't need to download
<ogra_> most of the times i agree ... but in a presentation where you already use a package proxy for the debs and your internet is 2G based you better down download at all
<zyga> ogra_: adding a gazillion options won't be useful as nobody will really feel good about that (hard to find, quirky, why it it even an option)
<ogra_> make it not an option, make it an env var (and consider not documenting it)
<zyga> program --dont-be-silly-and-broken=3
<sergiusens> ogra_: when I get xenial on my tablet I will be able to work from bed and be much more productive btw ;-)
<ogra_> zyga, rather --dont-use-the-great-chinese-wall
<ogra_> thats the issue here
<zyga> so what are the options?
<zyga> where do people get those bits from?
<zyga> moon? :)
<ogra_> zyga, in the workshop the presenter shares them
<zyga> I see
<ogra_> he downloaded it in davance over night
<zyga> if snapcraft had caching sufficient to do "snapcraft cache"
<zyga> then one option would be to copy that tree over to everyone
<zyga> but there are many things that are tricky to do caching / offline work right
<ogra_> the point is that liuxg has limited time forhis workshops ... debs already use a package proxy ... but the plugin still downloads
<zyga> I bet sergiusens know this far better than I even imagine the problem
<ogra_> yeah, i'm fine with copying a cache ... as long as you cover this usecase
<ogra_> not everything needs to be an option ;) you can make it a hidden feature, a cache dir to copy, a hidden env var etc
<liuxg> zyga, ogra_, yes, that is the point. during a workshop, the download of the nodejs can be tedious, even in my daily work. it takes a few minutes to get it done.
<liuxg> ogra_, I have reported a bug for it. https://bugs.launchpad.net/snapcraft/+bug/1662464, thanks for your help
<mup> Bug #1662464: node-v4.4.4-linux-x64.tar.gz is downloaded again and again during the build of a snap <Snapcraft:New> <https://launchpad.net/bugs/1662464>
<liuxg> sergiusens, is there any way to use the nodejs from the cache? thanks
<JerryKao> mvo, ping
<mvo> JerryKao: pong
<JerryKao> hi mvo, how to check snapd version in core system?
<ogra_> snap version
<ogra_> like on a classic system
<JerryKao> ogra_, thanks
<mup> PR snapd#2799 closed: tests: fix pattern and use MATCH in find-private <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2799>
<mvo> ara: one quick question - what is the output of "snap version" in the non-chatty version that fails for you?
<ara> mvo, 2.22.1
<mvo> thanks
<mup> Bug #1662357 changed: Can't use lsb_release on Ubuntu Core 16 <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):New> <https://launchpad.net/bugs/1662357>
<ogra_> mvo, would you be opposed if i made lsb_relese non-executable with a build time hack on the core images ... we're always getting bugs for it
<mvo> ogra_: hm, can we remove it entirely?
<ogra_> i can rm it but not remove the package easily
<ogra_> we also need it in the classic tarball ... there i made it work fine
<mvo> ogra_: right, either way is fine with me then, rm the binary feels slightly cleaner
<ogra_> no prob, will do that then ...
<mvo> ta
<mup> PR snapd#2677 closed: snap: improve the error message for `snap try` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2677>
<mup> PR snapd#2800 opened: daemon: show "$snapname (delta)" in progress when downloading deltas <Created by mvo5> <https://github.com/snapcore/snapd/pull/2800>
<mup> PR snapd#2801 opened: snap-confine: add the key for which hsearch_r fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/2801>
<kw> Hi guys, has anyone here tried to upgrade/change the kernel in ubuntu core?
<zyga> kw: hey, can you be more specific? the kernel is reglarly updated
<ogra_> zyga, well ...
<kw> Yes, sure. Let me rephrase.
<ogra_> kw, what hardware ?
<kw> I'm using up board with ubuntu core installed. The original goal is to overclock the cpu frequency a little bit but it seems that the kernel wouldn't allow. ( not sure how to confirm)
<kw> We have a working one beside (up board with legacy ubuntu 14.04 and higher cpu freq)
<kw> that's probably where the guess is from
<kw> so I'm thinking the possibilities to upgrade the kernel in ubuntu core
<kw> it would be appreciated, if anyone could give any recommendation,
<zyga> kw: you will need to roll your own kernel snap
<zyga> kw: and a model assertion that describes that
<zyga> kw: and (AFAIK, could be wrong) a gadget snap
<kw> yes ,I was also thinking about that and I found this
<kw> https://docs.ubuntu.com/core/en/guides/build-device/image-building
<kw> not sure if this is the manual I should follow. the information is limited though
<zyga> kw: the kernel and gadget need to be signed by your "brand" key
<zyga> kw: you will need to build an image with that assertion
<zyga> kw: you cannot change a kernel on an already running device (only the brand can do that)
<zyga> kw: not sure,
<ogra_> zyga, hmm, its an ATOM, i would expect our pc kernel snap to work on this
<zyga> ogra_: yeah, it should work
<kw> I see
<ogra_> i rather think you want your own gadget and modify cmdline options
<kw> is there tutorial or instruction for creating custom kernel and gadget snap?
<ogra_> and possibly ship some sysctl.d files
<ogra_> kw, https://github.com/snapcore/pc-amd64-gadget
<ogra_> pull that, install snapcraft on your desktop ... then run snapcraft in the toplevel dir
<ogra_> and indeed make changes before calling snapcraft as needed :)
<kw> yes, this also works for me. thanks
<ogra_> with ubuntu-image you just need to use the --extra-snaps option and point to your snap then
<ogra_> the local one will override the one from the store
<kw> I see.
<kw> I think I'll give it a try first and see how it goes.
<kw> I'm not familiar with snap enough yet
<kw> many thanks :)
<ogra_> just ask if you run into more issues :)
<mup> PR snapd#2801 closed: snap-confine: add the key for which hsearch_r fails <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2801>
<joedborg> hey all
<joedborg> has anyone got experience with creating a snap package where git binary is needed for the application you're snapping (e.g. NPM)?
<ogra_> add git-core to build packages or some such
<ogra_> or just the toplevel 2git"
<ogra_> *"git"
<zyga> joedborg: could be hairy (it will pull in perl and a zoo of other bits I bet) but you can try
<ogra_> thoug, doesnt the nodejs plugin provide all bits needed for npm builds ?
<joedborg> i've tried adding it as a build-package and stage-package as well as a separate part and build it
<joedborg> but it always says that the "https helper is missing"
<joedborg> so it can't pull any https repos
<joedborg> I'm trying to package bower
<joedborg> NPM was just an example
<ogra_> try libcurl4-openssl-dev in build-packages
<joedborg> yep, I've tried that too
<ogra_> i think that provides https
<joedborg> as well as       - gettext
<joedborg>       - libssl-dev
<joedborg>       - libcurl4-openssl-dev
<joedborg>       - libexpat1-dev
<joedborg> and adding the --with-curl and --with-expat flags to the configure
<joedborg> and then given it home and network plugs
<ogra_> err, wait, you are trying to run git *inside* your snap at execution time ??
<zyga> ogra_: yes
<ogra_> ah, i misunderstood
<zyga> joedborg: I'd suggest trying to usea classic confinement snap
<joedborg> zyga: yeah, I made the snap like that originally but want to try to get it into strict confinement
<zyga> joedborg: depending on what you want from git (I suspect npm just wants to clone)
<zyga> joedborg: you could build a super small git version in your snap
<zyga> joedborg: just enough to have basic bits written in C
<zyga> joedborg: should be simple and fast
<zyga> joedborg: (build git from source, disable all the useless option)
<joedborg> zyga: you mean write my own, calling libgit?
<zyga> joedborg: no, just build upstream git but trim all the deps
<zyga> joedborg: npm doesn't need 99% of git, just git clone I suspect
<zyga> joedborg: and a minmal build of git from source should be good
<zyga> joedborg: and you can pick any version you want :)
<joedborg> zyga: yes, that's what I've also been trying, but if I cannot build the current source with git-http, I think I'd have the same issue even if i cut the bloat out, right?
<zyga> joedborg: what's the problem with building?
<joedborg> zyga:   git:
<joedborg>     source: https://github.com/git/git
<joedborg>     source-type: git
<joedborg>     source-depth: 1
<joedborg>     plugin: autotools
<joedborg>     configflags:
<joedborg>       - --with-curl
<zyga> joedborg: bloat may be built-in (deps)
<joedborg>       - --with-expat
<joedborg>     build-packages:
<joedborg>       - gettext
<joedborg>       - libssl-dev
<joedborg>       - libcurl4-openssl-dev
<joedborg>       - libexpat1-dev
<joedborg>     stage-packages:
<joedborg>       - libcurl3
<zyga> joedborg: rather than pasting here please use pastebin, irc likes things this way
<joedborg> this builds without warnings
<zyga> joedborg: does it work in the end?
<zyga> joedborg: note that I'm not a snapcraft expert, I work on snapd internals
<zyga> joedborg: perhaps sergiusens or kyrofa can give you better advice
<joedborg> zyga: okay, here is is as a Gist https://gist.github.com/joedborg/c496eaa6de26a14d73b55a6db372f531
<joedborg> and the build looks okay, I even see "checking if Curl supports SSL... yes"
<zyga> joedborg: and what is the part that doesn't work?
<joedborg> zyga: but then, if i install with --devmode (to see what's going on) and try to get bower to pull something (which is done via git) I get "Failed to execute "git ls-remote --tags --heads https://github.com/jquery/jquery-dist.git", exit code of #128 fatal: Unable to find remote helper for 'https'"
<zyga> joedborg: what probably happens is that your git looks for /usr/bin/something
<zyga> joedborg: and that's not found there
<zyga> joedborg: apart from teaching git to use $SNAP and be smarter
<zyga> joedborg: I'd suggest configuring with --prefix=/snap/$SNAP_NAME/current/usr
<zyga> joedborg: and changing the installed files with organize
<zyga> joedborg: so that your snap contains just the /usr part
<zyga> joedborg: I did that a few times when apps love to hardcode where to run stuff from
<zyga> joedborg: otherwise it just looks for files in the usual spot and they are not there
<joedborg> zyga: that makes sense, because the helper should be in "/snap/libexec/git-core"
<zyga> joedborg: look at the output of `dpkg -L git`
<zyga> joedborg: this is where git keeps all the commands
<joedborg> zyga: so I guess it's an environment problem
<zyga> joedborg: play with --prefix and other bits
<zyga> joedborg: I bet you can get it to work
<zyga> joedborg: environment?
<joedborg> zyga: if that's the case, I think I'd just need to add libexec/git-core to $PATH inside the snap
<zyga> joedborg: depending on how git runs those
<zyga> joedborg: if it uses PATH to search, yeah
<zyga> joedborg: if it has a hard-coded path, you need to do more
<joedborg> I've just got to work out how to do that from snapcraft
<zyga> joedborg: --prefix=/snap/yoursnapname/current/usr
<zyga> joedborg: then use organize
<zyga> joedborg: (in the part)
<zyga> joedborg: to strip that so that only usr is placed in the prime dir
<mup> PR snapd#2768 closed: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2768>
<ogra_> https://git-scm.com/book/tr/v2/Git-Internals-Environment-Variables#Global-Behavior
<ogra_> you migth want to use a wrapper around git that sets some of these global vars ;)
<zyga> ogra_: yeah, nice
<zyga> joedborg: GIT_EXEC_PATH
<zyga> though I think building git with correct prefix is pretty good too
<joedborg> zyga: trying the prefix first, can't work the syntax out for setting envars in snapcraft yaml
<zyga> joedborg: you need a wrapper script or latest snapcraft
<zyga> (it's a new feature in snapcraft)
<zyga> sergiusens: ^^
<ogra_> ah, did that land already ?
<zyga> not sure, it might have
<joedborg> zyga: i'm on 2.26
<ogra_> i saw a commit but didnt follow the status
<joedborg> zyga: you get the same issue when setting prefix - i assume because path still isn't pointing to the libexec/git-core directory
<zyga> joedborg: note that that is not on PATH in any distro either
<zyga> joedborg: look at what git is doing internally
<mup> PR snapd#2746 closed: interfaces: remove some syscalls already in the default policy plus comment cleanups <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2746>
<ogra_> GIT_EXEC_PATH is the one that needs to point to libexec/git-core
<ogra_> (check on any ubuntu install with "git --exec-path" ... it should return /usr/lib/git-core)
<ogra_> (which has all the binaries)
<zyga> ogra_: question is, how does git decide on that value?
<ogra_> why does that matter as long as it respects your override
<zyga> ogra_: it matters to know how git works as this may be something we may fix in general
<ogra_> i guess it is set at build time normally
<zyga> ogra_: depending on ... ? prefix?
<ogra_> combo ...
<ogra_> at build time i guess prefix is just /usr
<ogra_> so it combines with the distros typical libexec path
<ogra_> which is lib in our case
<joedborg> ogra_ zyga: would that be baked in when git is packaged for apt?  i don't think we have any GIT_* envars set
<ogra_> the vars are for user overrides ... so indeed they are not set by the package :)
<ogra_> they are nontheless the right thing to use in a snap
<joedborg> orga_: do you know if this can be passed in via snapcraft?
<ogra_> https://github.com/snapcore/snapcraft/pull/1103 is the commit adding support for that to snapcraft btw
<mup> PR snapcraft#1103: meta: support for the environment keyword <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1103>
<ogra_> merged 23h ago
<joedborg> okay, I'll pull master down and built it and try with that
<ogra_> hah
<ogra_> look  at the changed files there ... there is even:
<ogra_> +      PATH: $PATH:$SNAP/libexec/git-core
<ogra_> +      GIT_TEMPLATE_DIR: $SNAP/share/git-core/templates
<ogra_> so exactly what you want
<mup> PR snapd#2802 opened: snap-confine: make sc_map_search/read_number take const const char * arguments <Created by mvo5> <https://github.com/snapcore/snapd/pull/2802>
<joedborg> ogra_: just getting through the snapcraft master build :)
<mup> PR snapd#2803 opened: asserts: introduce a variant of model assertions for classic systems <Created by pedronis> <https://github.com/snapcore/snapd/pull/2803>
<joedborg> ogra_: seems to still fail the YAML check
<mup> PR snapd#2770 closed: interfaces/core-support: allow modifying snap rsyslog configuration <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2770>
<jdstrand> ogra_: fyi ^
<ogra_> \o/
<ogra_> jdstrand, next is timesyncd :)
<jdstrand> ogra_: I'm sending up a PR for /etc/systemd/timesyncd.conf now
<ogra_> hah, snap
<jdstrand> yep! :)
<jdstrand> :)
<ogra_> and then the more complex sysctl.d
<jdstrand> oh, I haven't seen that one. is there a bug?
<ogra_> though thats only complex on the configure hook side ...
<ogra_> hmm, not sure, let me search
<ogra_> bug 1485683 and bug 1552679
<mup> Bug #1485683: /etc/sysctl.d is not applied on boot <Snappy:Expired> <https://launchpad.net/bugs/1485683>
<mup> Bug #1552679: snappy config ubuntu-core should get support for manipulating /etc/sysctl.conf <Snappy:Triaged by chipaca> <https://launchpad.net/bugs/1552679>
<ogra_> hmm. probably only the latter one
<jdstrand> ogra_: do you want to modify /etc/sysctl.conf or /etc/sysctl.d/{,[0-9][0-9]-}snap*.conf ?
<ogra_> yeah, one fixed filename would be enough though
<ogra_> i doubt we will use multiple files since the configure hook needs to generate all of it on every run
<jdstrand> ogra_: shall I send something up for that?
<ogra_> that would be awesome
<jdstrand> ok
<jdstrand> ogra_: will you be applying the sysctl values in the config hook or some other way?
<ogra_> the config hook will create or re-create the file if it runs
<jdstrand> ogra_: will the config hook also run 'sysctl -p /etc/sysctl.d/<file>'?
<ogra_> i'd like a more atomic way, but the current implementation of the config handling doesnt provide that ... i could create a file per option but i fear that gets messy
<ogra_> oh, i didnt think of that, yeah it should immediately apply the new settings with sysctl -p
<mterry> Elleo: so my in-progress unity8 interface had some maliit access bits and jdstrand pointed me to your maliit interface branch.  jdstrand, how granular do we want those to be?  Elleo, do we plan to ship the OSK separate from the unity8 snap?
<Elleo> mterry: when I'd suggested including maliit access in the unity8 interface tvoss wasn't very keen on the idea, so might be a good idea to check up on his thinking there
<zyga> mterry: FYI: one snap can use many interfaces
<Elleo> mterry: but we're likely to have scenarios where we want the OSK but not unity8 (e.g. probably in kiosk cases)
<jdstrand> I figured that maliit and unity8 interfaces would be separate, but unity8-session snap would slots both
<mterry> zyga: I know, it's just a matter of what we want app developers to put: "[maliit, mir, unity8]" or just [mir, unity8]
<jamespage> jdstrand, hey I understand you might be the person to talk to about getting auto-aliases added to my snaps in the snapstore - is that right?
<jdstrand> jamespage: I am one person who can help with that, yes
<mterry> Elleo, jdstrand: OK I can take the maliit bits out of u8
<jdstrand> mterry: I think the former ([maliit, mir, unity8]). this can all be made the default in the sdk
<jdstrand> for the unity8 tempalte
<mterry> yar
<mup> PR snapd#2804 opened: interfaces/core-support: allow modifying systemd-timesyncd and sysctl configuration <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2804>
<jdstrand> ogra_: fyi, ^
<ogra_> yeah, just saw it pass on telegram :)
<jdstrand> fun :)
<ogra_> mup is everywhere !
<jdstrand> heh
<ryebot> We're snapping an application that calls out to iptables - is there a way to do that without classic confinement? We've looked into using the network-control plug, but that doesn't appear to have the juju we need.
<ogra_> ogra@localhost:~$ snap interfaces|grep firewall
<ogra_> :firewall-control         -
<ogra_> :)
<ogra_> not sure thats available on classic installs though ...
<ogra_> (i see it exposed there ...)
<ryebot> Thanks ogra_
<ppisati> ogra_: i'm rebuilding a snapdragon image from scratch, and it stops at "/scripts/local-premount" - does it ring any bell?
<ogra_> ppisati, how did you rebuild ?
<ppisati> ogra_: right, i didn't explain well enough
<ogra_> (do you have a "writable" label, else the boot will wait for 2min til it times out)
<ppisati> ogra_: if i use the kernel from the store, everything is fine
<ogra_> ah
<ppisati> ogra_: my problem only happens with a src built kernel snap
<ppisati> i'm using the -stable channel FWIW
<ogra_> ppisati, there is a bug in the kernel plugin
<ogra_> sergiusens just worked on a patch afaik
<ogra_> (modules and firmware land in the wrong dir)
<ppisati> oh
<ppisati> lp1658177
<ogra_> in /lib/firmware and /lib/modules ... while they should be in /firmware and /modules
<ppisati> ogra_: i was tryting to follow up to the snapdragon's guy on the ml
<ppisati> ogra_: so i was trying to reproduce all the steps to generate a new image with a custom kernel
<ogra_> with the eragon board ?
<ppisati> ogra_: nope, snapdragon
<ogra_> yeah, seems thats one of the main issues he hits
<ogra_> hmm
<ppisati> sergiusens: do you have anything for lp1658177?
<ppisati> ogra_: i don't know, it appears he has many issues
<ogra_> yeah
<ppisati> ogra_: but i wanted to be sure that our kernel (and our building workflow was fine)
<ogra_> he showed his demsg and there his kernel only has half the cmdline
<ppisati> ogra_: so tried to build eveyrthing from scratch and i hit this
<ppisati> ogra_: right
<ryebot> ogra_: that worked, thanks!
<ogra_> :)
<kw> For some reason, we had to port some open source tools as snap package that we can continue what we wanted to do. Can we just upload those tools to the store? I saw that for some package, there are different versions of it. Is there any rules to manage this currently?
<kw> This might be a strange question though
<zyga> kw: hey
<zyga> kw: you can just upload those to the store
<zyga> kw: versions have no relevance in the store
<zyga> kw: it's just a convenience for the user
<zyga> kw: but it doesn't decide on updates or anything like that
<mup> PR snapd#2798 closed: interfaces/builtin: instead of just /proc/bus/pci/devices allow full read access on /proc/bus/pci <Created by morphis> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2798>
<qengho> kw: The most recent update (" that is applied to the "channel" a user is tracking becomes what is received by the user. The "version" is information for brains, not computers.
<qengho> kw: The most recent update ("revision") that is applied to the "channel" a user is tracking becomes what is received by the user. The "version" is information for brains, not computers.
<mup> PR snapd#2805 opened: snap: improve message after `snap refresh pkg1 pkg2` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2805>
<pmcgowan> ogra_, there is no db image at http://cdimage.ubuntu.com/ubuntu-core/16/stable/
<pmcgowan> which https://developer.ubuntu.com/core/get-started/dragonboard-410c points to
<ogra_> pmcgowan, http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
<pmcgowan> yeah but
<ogra_> slangasek, can we get that missing symlink too ?
<pmcgowan> thanks
<mup> PR snapcraft#1085 closed: snapcraft: fix or ignore PEP8 static errors <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1085>
<slangasek> "db image"?
<slangasek> oh, dragonboard
<ogra_> yeah "insider speak" :P
<slangasek> sorry, seems to be a bad symlink
<ogra_> np
<slangasek> because of a differing filename
<ogra_> 96boards insists on the numbering there
<slangasek> fixed
<ogra_> because there are multiple dragonboards
<ogra_> thanks !
<pmcgowan> ogra_, the reason I was getting it is my current install won't refresh any snaps, was that a known error at some point?
<pmcgowan> the downloads just hang
<ogra_> pmcgowan, oh, i have the same burt was blaming my old install from nov.
<ogra_> zyga, ^^^^
<slangasek> ogra_: sure - the script I inherited from mvo didn't name it that way.  Guess I'll update the script
<ogra_> slangasek, yes please
<pmcgowan> I have an oldish core but it used to work
<ogra_> pmcgowan, right ... we didnt get anywhere debugging that on my board
<ogra_> core                16.04.1       551  canonical  -
<ogra_> thats what i'm stuck at
<pmcgowan> I have 717
<zyga> ogra_: mmm
<ogra_> but it doesnt download anything at all ... there is a macroon issue i think
<ogra_> zyga, so pmcgowan sees similar issues with not being able to update on a dragonboard
<zyga> I don't remember the issue exactly
<ogra_> macraoon auth issue iirc
<zyga> hmmm
<zyga> ah
<pmcgowan> I entered this bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662603
<zyga> I know
<mup> Bug #1662603: snap refresh hang during download <snapd (Ubuntu):New> <https://launchpad.net/bugs/1662603>
<zyga> pmcgowan: move aside /root/.snap please
<ogra_> in fact Chipaca actually debugged it more woth me than you
<zyga> pmcgowan: it's fixed now, just get that out of the way and it will refresh
<zyga> pmcgowan: or more accurately, the config will apply
<zyga> pmcgowan: (it breaks core snap tho)
<zyga> pmcgowan: if you don't hae /root/.snap then this is a different bug
<ogra_> i dont think that was it
<pmcgowan> I dont have ".snap" just snap
<ogra_> right
<pmcgowan> zyga, I have a .snap in the user home dir
<pmcgowan> but not for root
<ogra_> pmcgowan, can you file a bug, i dont think we have one yet ... i'll bring it up with the team tomorrow ...
<pmcgowan> ogra_, I did see above
<ogra_> if it isnt my messed up install and you see it too i guess it is more serious
<ogra_> oops
<pmcgowan> ogra_, I previously had that issue where current pointed to an old version, and fixed it manually somehow
<ogra_> yeah, that one was fixed
<ogra_> i remember this one
<pmcgowan> really dont want to wipe it and start over
<pmcgowan> zyga, let me know if I can add more info to the bug
<zyga> pmcgowan: checking
<pmcgowan> ogra_, the macaroon in auth.json on my desktop is very different than on the db, is that normal?
<zyga> pcoca: can you refresh just core?
<zyga> pmcgowan: can you refresh just core?
<ogra_> pmcgowan, i thought macaroons are device specific
<zyga> pcoca: (sorry, bad tab-complete)
<ogra_> zyga, you cant refresh anything
<pmcgowan> zyga, nope, that hangs
<pcoca> zyga, no worries :)
<zyga> pmcgowan: can you tell me what happens? snap refresh core
<zyga> then show snap change for that
<pmcgowan> sure I have that, it shows all the steps with downloading Doing
<pmcgowan> but it never finishes
<zyga> pmcgowan: specifically on the core?
<zyga> hmmm
<zyga> pmcgowan: can you show your syslog please
<zyga> (journalctl)
<pmcgowan> zyga, here is one in progress http://pastebin.ubuntu.com/23948993/
<pmcgowan> zyga, core was the same as that
<zyga> pmcgowan: mir-kiosk is another thing, I'm thinking about core specifically
<zyga> if you are stuck on broken core because you cannot update
<zyga> vs all the snaps are broken but you can update core
<zyga> pmcgowan: can you set your $HOME/.snap directory aside
<zyga> the one in your home directory, not root
<zyga> pmcgowan: then snap refresh core
<pmcgowan> zyga, sure on sec
<zyga> (snap abort changes if they are in progress)
<ogra_> pmcgowan, was your board off for a while ?
<pmcgowan> ogra_, yes, at least two weeks
<pmcgowan> maybe more
<ogra_> pmcgowan, Chipaca seems to have a theory that it is realted to that
<ogra_> yeah, mine too
<zyga> mine too
<zyga> but the PSU is too far away to turn on and I'm somewhat swamped with laundry up here so I won't reach it easily
<pmcgowan> zyga, sudo snap refresh core
<pmcgowan> error: cannot perform the following tasks:
<pmcgowan> - Download snap "core" (892) from channel "stable" (cannot download non-free snap without purchase)
<zyga> hmmmm
<zyga> looks like a store bug or something I'm not familiar with
<zyga> thanks for letting us know
<ogra_> just FYI i checked the store page and the core snap still says it is free
<ogra_> Price
<ogra_> Free
<ogra_> Licence
<ogra_> Other Open Source
<zyga> jdstrand: hey, can you please look at https://github.com/snapcore/snapd/pull/2778
<mup> PR snapd#2778: cmd: use safer functions in sc_mount_opt2str <Created by zyga> <https://github.com/snapcore/snapd/pull/2778>
<zyga> failry short and simple, large part of the diff is boring format change caused by indent
<seshu> Is there a way to make the entire system point to beta channel? Our QA wants to test autoupdate of our snap and its behavior.
<kyrofa> seshu, channels are per-snap. Some snaps may not even have releases in beta
<seshu> Kyrofa: If I point and download my snap from a particular channel, would a higher version upload to same channel gets pushed to device as autoupdate?
<kyrofa> seshu, indeed
<kyrofa> seshu, note though that the version has nothing to do with it-- it's the fact that it's a higher revision
<kyrofa> Which is something assigned by the store. Essentially, since you uploaded another one, it gets a higher revision
<seshu> kyrofa: Great! That's what I wanted to know. I guess, the update happens within next 6-12 hours after I upload and publish.
<kyrofa> seshu, indeed, autoupdates happen four times a day, but the exact spacing is somewhat random so as to even the load
<kyrofa> seshu, if you want to update immediately, you can use the `snap refresh` command
<seshu> kyrofa: One more quick question...would a reboot or network event trigger such autoupdates...In case, I don't want the user to wait an entire day to get my updated snap on to his system
<kyrofa> seshu, that's a good question, I'm not sure. zyga or mvo probably know
<seshu> kyrofa: assuming mine is a system without terminal and keyboard...hence cannot do snap refresh
<kyrofa> seshu, right, that's what this was made for
<seshu> zyga: would a reboot or network or (any special) event trigger autoupdates...In case, I don't want the user to wait an entire day to get my updated snap on to his system and `snap refresh` is not an option for the user (as my system is headless and without keyboard attached).
<mup> Bug #1662627 opened: snapd project also open for bugs <Snappy:New> <https://launchpad.net/bugs/1662627>
<zyga> seshu: looking
<zyga> seshu: not at this time
<seshu> zyga: Thanks for checking. Would autoupdate happen atleast at first boot (after flashing the image or first time out-of-the-box) assuming the factory installs base image few months prior the actual deployment in the field and there may be updates to pre-bundled snaps (including core snap...which would need reboot)...coz in critical deployments any reboot after the install setup could cause major loss (i mean in factory automation set
<rogpeppe> anyone know how I can run a command at bootstrap time in Snappy? (as root)
<zyga> seshu: I think first boot is special, yes
<zyga> seshu: we do a few things there, that should ensure that your snaps are fresh
<mup> PR snapd#2803 closed: asserts: introduce a variant of model assertions for classic systems <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2803>
<zyga> rogpeppe: can you be more specific (what do you mean by bootstrap?)
<rogpeppe> zyga: for background, i have a raspberry pi with a hardware rtc but the kernel /dev/rtc device doesn't seem to work (I'm fairly sure I've configured the right overlay). I can use my own code to read the rtc and system clock time, but I don't know how to get that to run before the snap services do.
<zyga> hmmm
<zyga> ogra_: ^^
<rogpeppe> s/system clock time/set system clock time/
<zyga> (he's EOD now)
<seshu> zyga: Great...that's nice...would you please point to any documentation or details to know more about the first boot behavior.
<zyga> rogpeppe: that smells like a derivative gadget snap to me
<zyga> seshu: I don't think we have any, let me check though
<zyga> seshu: no we don't have that
<rogpeppe> zyga: mm hmm.
<rogpeppe> zyga: :(
<rogpeppe> seshu: :)
<zyga> seshu: I can write something tomorrow, it will be available on the snapd wiki
 * rogpeppe can't type
<rogpeppe> zyga: that sailed right over my head. what's a "derivative gadget snap" ?
<zyga> rogpeppe: you need to take the stock gadget snap for pi and patch it with that logic and build an image using that gadget snap
<seshu> zyga: Sure helps! thanks a ton.
<zyga> rogpeppe: unless there's a way to make that work with an add-on snap
<zyga> rogpeppe: and an interface
<zyga> rogpeppe: on a generic
<seshu> Thank you kurofa and zyga.
<zyga> rogpeppe: I think you want to chat with ogra_ tomorrow when he's around (europe)
<zyga> rogpeppe: as he may have an easier suggestion
<rogpeppe> zyga: so you're saying i can't use the stock ubuntu-core image?
<zyga> seshu: stick around, I'll ping you tomorrow
 * rogpeppe reads up about gadget snaps
<zyga> rogpeppe: well, I'm saying that we don't allow to stick unconfined stuff that runs as root on boot, yes
<zyga> rogpeppe: https://github.com/snapcore/snapd/wiki/Gadget-snap
<rogpeppe> zyga: ok, i suspected that was the case.
<zyga> rogpeppe: https://github.com/snapcore/pi3-gadget
<zyga> (there's a pi2-gadget repo as well)
<rogpeppe> zyga: i'm wondering if it was a bad idea using snappy for this :)
<zyga> rogpeppe: not if you want security and snaps people make :)
<zyga> rogpeppe: if it is a common RTC we could perhaps support it in the gadget snap for pi in general
<zyga> rogpeppe: and everyone could use it
<rogpeppe> zyga: well, yeah, that would be nice. but being able to install temporary hacks to stop things crashing is also nice sometimes. I know those two things are oppositional :)
<zyga> rogpeppe: I really suggest that you talk to ogra_ tomorrow to find a solution
<zyga> rogpeppe: well
<zyga> rogpeppe: temporary hack is something else
<rogpeppe> zyga: i raised it on the mailing list a while ago
<zyga> rogpeppe: just stick a systemd service
<zyga> rogpeppe: (manually)
<seshu> zyga: Sure...
<zyga> rogpeppe: the shell you log into is not confined
<rogpeppe> zyga: and poked again last week
<rogpeppe> zyga: but no response
<zyga> rogpeppe: you can experiment and do stuff like that
<zyga> rogpeppe: I see, well, sometimes people are busy
<rogpeppe> zyga: it's important that it needs to happen automatically on reboot
<zyga> rogpeppe: a systemd unit will give you that
<zyga> rogpeppe: you can even ensure it runs before snapd or other bits
<zyga> rogpeppe: but that's a one-off hack
<zyga> rogpeppe: for a way to incorporate that into snappy proper you have to talk to ogra or see if you can achieve this with your gadget snap
<rogpeppe> zyga: i know, but it's a little bit frustrating as i'm actually trying to use this to control a household electrical system and it's a bit embarrassing when it fails after a power cut...
<zyga> rogpeppe: I bet it is,
<jdstrand> zyga: re 2778, ok
<zyga> jdstrand: thanks
<lool> jdstrand: hey ever seen something like this? http://paste.ubuntu.com/23949356/
<lool> this is a regular snap I had installed in devmode
<lool> I changed it ot classic
<lool> I tried a reboot to clear the loaded apparmor profiles but it didn't help
<rogpeppe> zyga: so if i add, say, /etc/systemd/system/rtcsync.service and start it, that might do the job?
<zyga> lool: is this on old snapd?
<zyga> rogpeppe: I think so
<lool> ubuntu@fbwedge100:~$ snap version
<lool> snap    2.20.1ubuntu1
<lool> snapd   2.20.1ubuntu1
<jdstrand> lool: you can't use plugs with classic
<rogpeppe> zyga: (assuming the right systemd magic - my head still hasn't migrated from upstart yet...)
<zyga> lool: update, that's been fixed long ago
<lool> zyga: ok
<zyga> lool: (and regenerate the profile)
<lool> jdstrand: ok, the store rejects plugs: [] in hooks though
<zyga> (we should _really_ do that automatically soo)
<zyga> lool: just don't do any plugs
<jdstrand> lool: hmm?
<lool> zyga: ok, will update and install the snap
<jdstrand> lool: the store will let you know that you are using plugs with classic. what are you referring to?
<zyga> lool: recent snapd lets you disable / enable a snap to refresh security
<rogpeppe> zyga: i can always make my service pause for 10s when it runs to make sure that the other one gets to run first...
<zyga> jdstrand: note that plugs on classic snap make sense with --jailmode and the store should not reject those
<zyga> rogpeppe: the other one?
<lool> jdstrand: no I mean a regular snap with plugs: [] will be rejected
<zyga> rogpeppe: I refer you to excellent systemd documentation, it has all the bells and whistles you need
<lool> sorry, a configure hook wiht plugs: []
<zyga> rogpeppe: you should set up correct dependencies
<zyga> rogpeppe: and not use any timers
<rogpeppe> zyga: ah, ok. i really must sit down one day and rtfm, yes
<jdstrand> lool: I'd need to see the yaml. just drop 'plugs' at all if you don't want it rather than specifying an empty list?
<rogpeppe> zyga: thanks
<zyga> rogpeppe: systemd starts things in parallel so your 'wait for 10s' thing won't matter
<zyga> rogpeppe: unless you express that as a dependency
<rogpeppe> zyga: given that snappy creates the other service for me, is it possible to make it depend on my rtcsync service?
<kyrofa> zyga, are dependent services supported, though?
<lool> jdstrand: if I drop plugs entirely snapcraft rejects it
<zyga> rogpeppe: yes, but I suggest to make your hack to run early on boot
<zyga> rogpeppe: it really depends on what you want to do there
<zyga> kyrofa: no
<lool> jdstrand: https://github.com/lool/sonic-snap/blob/master/snapcraft.yaml
<zyga> kyrofa: but systemd has reverse dependency syntax
<zyga> kyrofa: a service can run before something else
<rogpeppe> zyga: i want to do as little as possible pending the real driver/kernel fix :)
<jdstrand> lool: I feel like I am missing a lot of context. are we talking about snapcraft.yaml, snap.yaml or the store?
<rogpeppe> zyga: ah, i wondered if it might
<lool> jdstrand: both
<rogpeppe> zyga: thanks
<lool> jdstrand: sorry, I'm doing too many things in parallel
<rogpeppe> zyga: i'll give that a go
<kyrofa> zyga, yeah, would sure be nice to expose that in snapd
<lool> jdstrand: if I dont specify plugs at all, snapcraft rejects it, so I specify an empty list, but then the store rejects it
<jdstrand> lool: that yaml is using devmode. what is the yaml that uses classic?
<lool> jdstrand: I've just changed this snap from devmode to classic to run gdb on it
<lool> locally
<rogpeppe> zyga: where would you suggest starting in the systemd docs?
<jdstrand> sergiusens: snapcraft now requires 'plugs' in snapcraft.yaml?
<rogpeppe> zyga: is the canonical place? https://www.freedesktop.org/wiki/Software/systemd/
<zyga> rogpeppe: man systemd.unit
<zyga> rogpeppe: man systemd.service
<zyga> rogpeppe: that wiki is probably also good but you have everything on your system already
<lool> jdstrand: $ snapcraft
<lool> Issues while validating snapcraft.yaml: The 'hooks/configure' property does not match the required schema: None is not of type 'object'
<rogpeppe> zyga: ah, great, i like section 5 pages.
<lool> if I drop the plugs line
<lool> with 2.26
<jdstrand> sergiusens: and it generates 'plugs: []' in snap.yaml? if so, why? ^
<lool> zyga: hmm $ sudo snap refresh --edge core
<lool> 2017-02-07T19:06:44Z INFO snap "core" has bad plugs or slots: core-support (unknown interface)
<lool> error: cannot perform the following tasks:
<lool> - Setup snap "core" (1126) security profiles (no state entry for key)
<jdstrand> lool: what if you do 'configure: null'?
<zyga> lool: oooooh
<zyga> lool: that's pretty interesting/bad
<zyga> lool: so core support is a new interface
<lool> jdstrand: Issues while validating snapcraft.yaml: The 'hooks/configure' property does not match the required schema: None is not of type 'object'
<zyga> lool: that is there to support... core
<rogpeppe> zyga: thanks a lot for your help. i think that's enough to get me a system that works...
<zyga> lool: and I suspect we install new core
<lool> zyga: yeah I figured, seems like the upgrade path is broken though
<zyga> lool: try to conifgure it (it ships a hook now)
<zyga> lool: and it dies
<zyga> lool: can you report this please
<lool> snappy project?
<zyga> lool: snapd please
<zyga> rogpeppe: good luck, and don't forget to talk to ogra tomorrow
<ryebot> Is there a plug that allows a snap to use sysctl?
<lool> zyga: https://bugs.launchpad.net/snapd/+bug/1662636
<mup> Bug #1662636: Can't upgrade to edge core snap due to missing core-support interface <snapd:New> <https://launchpad.net/bugs/1662636>
<lool> jdstrand: the second copy-paste was with configure: null
<zyga> lool: just to checek, can you add snap changes & snap change N for that change to the bug report
<lool> zyga: would it help to use 2.22 from -proposed?
<zyga> lool: (actually just the change)
<zyga> lool: not sure yet, hold on
<zyga> lool: I specifically want to see what failed (which task in that change)
<lool> zyga: actually I lied, this system is NOT up-to-date
<ryebot> specifically, the app we're trying to snap is failing with "can't set sysctl net/ipv4/conf/all/route_localnet: open /proc/sys/net/ipv4/conf/all/route_localnet: permission denied"
<ryebot> is that possible without classic snaps?
<lool> zyga: upgrading now
<ryebot> classic confinement*
<zyga> ryebot: not likely, classic confinement has no limitations
<zyga> ryebot: but look at dmesg |grep DENIED
<zyga> maybe we're missing something
<ryebot> zyga: yeah, it definitely works with classic confinement
<ryebot> zyga: trying to confine it now
<zyga> ryebot: ah, I misread your question
<zyga> let me check
<ryebot> zyga: thanks :)
<lool> zyga: I'm upgrading to xenial-updates
<lool> and then will repro
<zyga> ryebot: I don't think there's an interface that covers this, perhaps https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go should but I don't know
<ryebot> zyga: I'll give it a shot; thanks
<lool> jdstrand: BTW is there a shortcut to gdb-ing a snap? here are the options I thought of: 1) switch to classic snap, snap run --shell, run gdb there; 2) set SNAP env var manually, run binaries (but then namespaces aren't setup); 3) add gdb as a stage-package and snap run --shell
<lool> none of these are very pleasing, is there something smarter to do?
<mcphail> Can you debug in "snap try"?
<balloons> anyway I can do something like this: source: file://$GOPATH/src/github.com/ to pull and use local sources to build my snap instead of a remote?
<lool> mcphail: I guess; I'm actually building the snap on another host
<balloons> note, I can specify the absolute path, and that does work
<mup> Bug #1662627 changed: snapd project also open for bugs <Snappy:Invalid> <https://launchpad.net/bugs/1662627>
<sergiusens> lool: jdstrand you only define hooks in `snapcraft.yaml` if you need to define plugs, what is going on?
<lool> sergiusens: hooks have plugs
<lool> sergiusens: but you can't define a hook without the plugs entry
<lool> if you do an empty plugs list that's rejected by the store
<zyga> lool: use snap run --shell
<zyga> lool: and yes, use gdb from there
<zyga> lool: if this is on classic you have gdb available in the host (via /var/lib/snapd/hostfs)
<zyga> lool: if core then not sure
<zyga> lool: didn't try that
<zyga> lool: I think we could grow snap debug --strace | --gdb | ... over time
<zyga> lool: that would do all the magic for symbols and what not
 * zyga wonders about -debug snap with detached symbols
<zyga> e.g. foo might have a private foo-debug snap
<zyga> install both, content does the rest
<seshu> any issue with snap store? I'm unable to install my snap from --edge and --beta channel...got struck at Download snap XXXX from channel "edge" for a while now...
<mup> PR snapcraft#940 closed: store: implement delta uploads in push <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/940>
<mup> PR snapcraft#1114 opened: tests: avoid snapping progress to leak into report <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1114>
<ryebot> zyga: That actually got us part of the way there, thanks!
<ryebot> zyga: Now we're hitting "open /sys/module/nf_conntrack/parameters/hashsize: permission denied"
<ryebot> network_control.go supports "@{PROC}/sys/net/nf_conntrack_max rw", but unfortunately I don't see sys/module/nf... in there.
<zyga> ryebot: oh, that's great
<zyga> ryebot: can you open a bug on this (in the snapd project on launchpad)
<zyga> ryebot: and make sure to tag it "snapd-interface"
<ryebot> zyga: will do!
<zyga> ryebot: thank you
<zyga> ryebot: our security team will review it and if it is within the policy, it will be added in a few days
<ryebot> zyga: awesome, thanks!
<jdstrand> ryebot: feel free to ping me when you file it
<ryebot> jdstrand: cool, will do
<zyga> seshu: yes, we think there's an issue
<zyga> seshu: can you look if this bug describes the problem you are seing...
<zyga> seshu: hmm, it's not filed?
 * zyga should EOD and rest
<jdstrand> tvoss, zyga: fyi, https://lists.freedesktop.org/archives/xdg-app/2017-February/000534.html
<pedronis> zyga: it's filed on the package
<pedronis> not snappy or snapd
<zyga> pedronis: ah, thanks
<pedronis> (it's confusing all these places)
<ryebot> jdstrand zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662662 <-- lmk if you need more information
<mup> Bug #1662662: No interface allows access to "/sys/module/nf_conntrack/" <cdk> <snapd-interface> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1662662>
<zyga> jdstrand: very interesting
<zyga> jdstrand: thank you
<pedronis> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662603
<mup> Bug #1662603: snap refresh hang during download <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662603>
<zyga> seshu: ^^
<pedronis> seshu: what device are you running snap from?
<jdstrand> ryebot: thanks, triaged and assigned to me
<ryebot> jdstrand: You rock, thanks a lot!
<jdstrand> ryebot: thank you for filing the bug! :)
<ryebot> np!
<zyga> jdstrand: we should discuss the state of nvidia support
<zyga> jdstrand: it's more complex with glvnd
<jdstrand> zyga: probably should discuss with tvoss. I'm happy to participate for implementation ideas but I'm not well-versed in gl
<popey> zyga: arch appears to have snapd 2.16, do you know when they might get 2.21?
<mhall119> sergiusens: how can I make an architecture-agnostic snap with snapcraft?
<sergiusens> mhall119: force it with `architectures: [all]`
<sergiusens> you seem to ask this question a lot :-P
<mhall119> I do?
<mhall119> all or any? that's the part I can never remember
<popey> sergiusens: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/libraries.py#L84 is that relatively new? Pretty neat.
<popey> I only discovered it today :)
<popey> zyga: ignore me, wiki has the data
<zyga> popey: no, I poked the package as out-of-date but I had no reply
<zyga> popey: I don't have time to update it now
<zyga> (the package)
<sergiusens> popey: this is what sort of needs disabling that was discussed on-list :-/
<zyga> jdstrand: I have looked at this a while ago but I think we should come up with a solid plan forward
<zyga> jdstrand: and it's 100% required to have nvidia hardware to hack on this, I don't have any anymore
<jdstrand> hmm, me either
<zyga> (had old GPU but I left it in poland as it was not working reliably)
<mup> PR snapd#2778 closed: cmd: use safer functions in sc_mount_opt2str <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2778>
<zyga> jdstrand: I merged the PR, I'll follow up with same cleanups in more places
<zyga> jdstrand: thanks for the strnlen tip
<kyrofa> popey, yeah we like it too, but it's just not deterministic enough
<zyga> jamiebennett: ^^
<zyga> jamiebennett: (the nvidia discussion)
<mhall119> thanks sergiusens, you got me all squared away :)
<balloons> sergiusens, is there a way to use local source, even for the godeps?
<balloons> if you use source: ., godeps will still download the depends, even though I have them in $GOPATH
<sergiusens> balloons: GOPATH for the plugin is different that GOPATH in your env
<balloons> sergiusens, yea that seemed quite apparent when I tried to use file://$GOPATH. Still, is there anyway for godeps to find the dependencies, or not really?
<popey> kyrofa: yeah, it threw me today. One of my snaps magically acquired the right libraries, but didn't when built on another arch machine - ppa missing.
<popey> kyrofa: took me a while to figure out, then I saw the warnings (which have an odd b/ in front of them) and found that source code
<kyrofa> popey, yeah, exactly. Magic is awesome but only if you can promise it'll always work, eh?
<sergiusens> balloons: not that I can think of, not really a godeps person here
<balloons> perhaps kyrofa would know?
<sergiusens> balloons: I don't think you can aggregate GOPATHs though
<sergiusens> don't clean the pull step is what I can think of
<sergiusens> and maybe root for having the rebuild support in place ;-)
<balloons> is this a wishlist bug perhaps?
<sergiusens> it's almost like next in line
<kyrofa> Yeah we're close
<balloons> ohh, is there an open issue or something for me to watch?
<balloons> I'd be keen to use it :-)
<kyrofa> balloons, https://bugs.launchpad.net/snapcraft/+bug/1647877
<mup> Bug #1647877: The pull step is not marked as dirty when the source of the dump plugin is changed <dirty> <Snapcraft:Confirmed for kyrofa> <https://launchpad.net/bugs/1647877>
<balloons> thanks guys!
<mup> PR snapcraft#1114 closed: tests: avoid snapping progress to leak into report <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1114>
<mup> PR snapd#2800 closed: daemon: show "$snapname (delta)" in progress when downloading deltas <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2800>
<mup> PR snapd#2792 closed: tests: add spread test for delta downloads <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2792>
<cholcombe> snappy: i'm getting a `classic confinement requires the core snap to be installed. Install it by running `snap install core`.` on my builds.  is that something you need to do or me?
<balloons> cholcombe, you need to have the core snap installed; you can fix it by installing it
<cholcombe> balloons, https://code.launchpad.net/~xfactor973/+snap/ceph-safe-disk i can't do that
<cholcombe> i have LP building for me
<balloons> cholcombe, ahh, lp can't build classic snaps yep
<cholcombe> darn
<cholcombe> alright dev mode it is
<balloons> yea sadness
<cholcombe> balloons, is there a bug i can reference around that?  Just so i can remember to update this when that gets fixed
<balloons> https://bugs.launchpad.net/launchpad-buildd/+bug/1650946
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1650946>
<sergiusens> balloons: cholcombe that's going to be in snapcraft 2.27 and in master tonight/tomorrow
<cholcombe> sergiusens, oh cool! alright
<balloons> sergiusens, but it still needs lp changes right?
<balloons> If I can build with -proposed or your daily build ppa to get snapcraft 2.27 , I'll do it. I'd love to switch to classic for lp builds
<sergiusens> balloons: yeah, but timelines should align and the lp folks are working on another solution as well
<sergiusens> balloons: snapcraft has no PPA, it goes against its principles :-)
<balloons> sergiusens, :-)
<mskalka> has anyone tried installing the Juju charm-tools snap lately? I can fetch it just fine but when I try to install it errors out with: error: cannot install "charm": snap not found
<sergiusens> mskalka: maybe marcoceppi knows
<mskalka> looks like it's just that one snap too, others install fine
<kyrofa> It's a classic snap-- do you need to pass --classic?
<kyrofa> mskalka, ^^
<mup> PR snapcraft#1098 closed: Ignore .tox directories when creating cleanbuild tar <Created by OddBloke> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1098>
<mup> PR snapcraft#1115 opened: kernel plugin: fix kernel snap layout <Created by lool> <https://github.com/snapcore/snapcraft/pull/1115>
<mup> PR snapd#2773 closed: interfaces/mount: generate per-snap mount profile <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2773>
<mup> PR snapcraft#1110 closed: Show error messages for snap processing errors <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1110>
<mup> PR snapd#2747 closed: interfaces/mount-observe: add quotactl with arg filtering (LP: #1626359) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2747>
<mup> Bug #1637596 changed: Configure hook in tried snap with ecryptfs: permission denied <snapd:New for zyga> <https://launchpad.net/bugs/1637596>
<mup> Bug #1653769 changed: Missing keyring interface <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1653769>
<mup> Bug #1655125 changed: Missing interface: content sharing in the other direction <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1655125>
#snappy 2017-02-08
<mup> PR snapcraft#1052 closed: Make git pulls less error prone due to history changes <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1052>
<mup> Bug #1645445 changed: Turtlebot needs /dev/kobuki <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1645445>
<mup> PR snapd#2806 opened: interfaces/io-ports-control: use /dev/port, not /dev/ports <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2806>
<mup> Bug #1646559 changed: should periodically refresh ssh keys that were obtained from SSO/store for local users <snapd:Confirmed> <https://launchpad.net/bugs/1646559>
<mup> Bug #1662723 opened: Removing a snap with `snap remove <app>` doesn't remove everything <Snappy:New> <https://launchpad.net/bugs/1662723>
<mup> Bug #1662723 changed: Removing a snap with `snap remove <app>` doesn't remove everything <Snappy:Invalid> <https://launchpad.net/bugs/1662723>
<mup> PR snapcraft#1116 opened: Changed "snappy try" to "snap try" <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/1116>
<mup> Bug #1634890 changed: File system not resized in some devices <Snappy:Expired> <https://launchpad.net/bugs/1634890>
<mup> PR snapcraft#1117 opened: [wip] build and push the API docs to github pages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1117>
<mup> Bug #1662772 opened: systemd[1]: Failed to start Set the hostname to the value stored on the writable partition <snappy-set-hostname.service> <Snappy:New> <https://launchpad.net/bugs/1662772>
<mup> PR snapcraft#1075 closed: travis: allow to pass --channels parameter to generate proper config <Created by 3v1n0> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1075>
<mup> PR snapcraft#1118 opened: Trigger beta tests on travis every day <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1118>
<mup> PR snapcraft#1109 closed: meta: allow `post-stop-command` for an app entry in `apps` <Created by elespike> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1109>
<stub> Snaps don't install in lxd containers unless the squashfuse package is installed, but I can't find the relevant bug report to link.
<stub> Found it: Bug #1628289 (although it claims to be FIX COMMITTED in xenial, comments indicate otherwise)
<mup> Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Triaged> <squashfuse (Ubuntu):Confirmed for doko> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
<kalikiana> Hrm. Issues like bug 1652643 make a snappy life tedious at times. Bonus points for letting a non-tech-aficionado use LibreOffice on one of my machines.
<mup> Bug #1652643: LibreOffice Snap: unable to access documents in some nested direcotries <libreoffice> <snap> <Snappy:Confirmed> <https://launchpad.net/bugs/1652643>
<mup> Bug #1612453 changed: `snap connect` requires me to type ubuntu-core <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1612453>
<jamespage> morning all
<jamespage> I have a question re auto-aliases and conflicts with other snaps
<jamespage> jdstand kindly setup auto-aliases for the openstackclients snap yesterday
<jamespage> however that had a slightly un-intended side effect that now the glance, nova etc snaps are not co-installable with the openstackclients snap, as it ships aliases for commands with the same name as those sanps
<jamespage> for example
<jamespage> error: cannot install "glance": snap "glance" command namespace conflicts with enabled alias "glance" for "openstackclients"
<jamespage> however the glance snap does not provide a 'glance' command :-)
<pedronis> jamespage: well it could at some point
<pedronis> because is its snap name
<jamespage> pedronis, I guess my question is what is the conflict resolution strategy for this type of thing?
<jamespage> if this is always enforced in this way, we should have policy that means one snap can't auto-aliase a command with the name of another snap right?
<pedronis> jamespage: yes, that was the idea
<pedronis> jamespage: IÂ understand this is annoying,   the issue here is that in theory any snap has the right to a command called like it
<jamespage> pedronis, I'm ok with that, I guess my challenge is how that and auto-aliases should be managed
<jamespage> ideas - when you install the glance snap on a system that already has openstackclients, we might un-alias a conflicting glance command/aliase, and let glance own it.
<pedronis> jamespage:  but is annoying if server/client snap   have pairs  where we call server foo  and client has  a  command foo
<jamespage> pedronis, yup that's this use-case
<jamespage> pedronis, I'll raise a bug so we can track this better
<zioproto> hello there
<zioproto> jamespage, unalias sounds bad
<zioproto> usually people on the openstack controller have both the glance-api that comes with the glance snap and the glance client utility
<zioproto> they need to work both at the same time
<jamespage> zioproto, oh I agree
<jamespage> zioproto, its common todo that
<jamespage> letme raise this bug
<pedronis> jamespage: the problem is that well known aliases are also for scripts so random unaliasing them is bad
<zioproto> paste here the bug link so I can subscribe to it
<pedronis> mmh, what IÂ mean is more that we need predictable behavior
<jamespage> https://bugs.launchpad.net/snapd/+bug/1662815
<mup> Bug #1662815: conflicts between auto-aliases and real snap names <snapd:New> <https://launchpad.net/bugs/1662815>
<jamespage> pedronis, agreed
<jamespage> zioproto, ^^
<kw> zyga: I got the point of "version"  What if, for example, everyone upload their "version" of vim and actually they are almost the same just uploaded by different person and have different namespace
<zyga> kw: nothing
<zyga> kw: as long as they have different snap name this is all right
<kw> zyga: I see. interesting :)
<zyga> kw: there were some ideas about how to let pepole get an official vim or a fork of vim from a given user (vim being just an example) but there was no agrement on what the semantics would be
<zyga> kw: but it is possible we will re-visit this
<kw> zyga: I suppose that people would prefer a copy from author or official one which makes them comfortable
<mup> Bug #1662817 opened: some snaps stop working after revert the core snap <Snappy:New> <https://launchpad.net/bugs/1662817>
<mup> PR snapd#2806 closed: interfaces/io-ports-control: use /dev/port, not /dev/ports <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2806>
<mup> PR snapd#2766 closed: tests: improve snap-env test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2766>
<cos-> is there a plugin or other way to build and install a debian package from source? running debuild and dpkg -i would be enough..
<ogra_> cos-, a rather ugly way is https://github.com/ogra1/packageproxy/blob/master/Makefile
<ogra_> from https://github.com/ogra1/packageproxy
<ogra_> (it works though)
<ogra_> https://github.com/ogra1/laidout is another one
<ogra_> (the latter only uses a binary, the former builds a deb from the upstream source)
<cos-> ok, no clean way to do that :-(
<ogra_> dont judge by my hacks :)
<ogra_> this is all very old stuff, perhaps there is a cleaner way nowadays
<ogra_> i just tend to abuse makefiles as scripts for quick results
<popey> cos-: why do you need to rebuild the deb? can't you just suck it in?
<ogra_> yeah, then you would just put it in stage-packages
<cos-> popey: if it exists only in a private git repo
<kw> why is some snap namespace reserved? e.g. i7z
<stub> Will we get to the point of being able to guarantee that a Xenial or later machine has the snapd package installed when it is provisioned?
<stub> I've got a problem with /snap/bin not being in the $PATH of processes spawned before the snapd package got installed (lxd containers in this case)
<stub> I don't know if I should file an lxd bug (because it provisioned a machine without snapd and handed it to Juju),or a Juju bug because it asked for the wrong thing, or an Ubuntu bug because /snap/bin should be on the $PATH in /etc/profile no matter what
<stub> Or if I should be handling it myself, and rebooting the machine after installing the snapd package to get the /etc/profile.d changes in effect everywhere
<popey> kw: so the upstream developer can 'claim' it.
<popey> or someone working with the upstream developer
<mup> PR snapd#2805 closed: snap: improve message after `snap refresh pkg1 pkg2` <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2805>
<mup> PR snapd#2807 opened: snap: add new `snap switch` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/2807>
<vigo> ogra_, ping
<ogra_> vigo, yo
<vigo> ogra_, what does this mean?
<vigo> 2017-02-08T12:08:04Z INFO snap "core" has bad plugs or slots: core-support (unknown interface)
<ogra_> when do you get this ?
<vigo> I get this refreshing core from candidate
<vigo> well stable-> candidate
<ogra_> well, it is an info message telling oyu that the running core does not have the interface (the new core after the install finished will have it)
<ogra_> the question is here if snapd is clever enough to re-run any potential config settings that use this interface once the new core is running
<ogra_> if not, that would be a bug
<vigo> ogra_, great, thanks
<om26er> Hello! where can I download model assertion for rpi2 ? need to build an image with default user
<om26er> I have the one for pc right now but want to build for rpi2/db
<Chipaca> jdstrand, any reason you can think to not let strict snaps read /usr/share?
<Chipaca> jdstrand, if yes, what about just /usr/share/bash-completion/bash_completion :-)
<mup> PR snapd#2804 closed: interfaces/core-support: allow modifying systemd-timesyncd and sysctl configuration <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2804>
<mup> PR snapd#2774 closed: interfaces/mount: add dedicated mount entry type <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2774>
<mup> PR snapd#2808 opened: interfaces: use mount.Entry instead of string snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/2808>
<jdstrand> Chipaca: this is going to be a can of worms. in general, we should only allow what is required. ok, so for bash completion that is /etc/bash_completion* and /usr/share/bash_completion/*. however, on classic, /etc is mounted in the snap but /usr/share is from core, and core doesn't ship /usr/share/bash-completion/bash_completion, so there is a potentional mismatch, especially when using different cores
<ogra_> jdstrand, core ships it now
<jdstrand> Chipaca: assuming you fix that (or defer caring), then all the commands in /usr/share/bash-copmpletion/completions/* are probably going to access the filesystem in new and exciting ways
<ogra_> ogra@localhost:~$ ls /usr/share/bash-completion/bash_completion
<ogra_> /usr/share/bash-completion/bash_completion
<ogra_> added last week :)
<jdstrand> that's find, but the /etc vs /usr bit on classic may cause problems and I'm positive will cause problems with say, a fedora core
 * jdstrand wonders why he doesn't have an updated core
<mvo> jdstrand: what do you see in snap changes?
<mvo> jdstrand: anything that indicates why core is not updating?
<jdstrand> maybe it didn't go to stable?
<ogra_> yeah, far from that
<mvo> jdstrand: oh, you are using stable :) consider switching
<jdstrand> I have r888
<ogra_> edge and (not sure) perhaps candidate
<jdstrand> well, my laptop I won't, but I can do that somewhere else
 * jdstrand notes that adding bash_completion was the least of his concerns-- that's easy :)
<jdstrand> (the file, not the functionality)
<Chipaca> jdstrand, core does ship bash completion as of now (on edge)
<Chipaca> jdstrand, all I really need is /usr/sahre/bash-completion/bash_completion, not the completion scripts
<ogra_> Chipaca, well, on classic you might want them
<Chipaca> ogra_, not from inside confinement
<Chipaca>                       ^ strict
<ogra_> ah,. k
<jdstrand> mvo: have you given this bug more thought: hsearch_r failed: No such process?
<mvo> jdstrand: yes
<jdstrand> mvo: I updated core and now nothing starts (cause of old snap-confine)
<mvo> jdstrand: in the standup right now,  I have something but we need to talk more because reverts of core are probably broken right now too
<mvo> jdstrand: I have a branch that is still a bit messy
<jdstrand> mvo: I would be interested in seeing that branch when you're ready for me to look at it
<zioproto> hey when you have a syntax like git+https://github.com/zioproto/kolla-ansible how do I select a specific branch ?
<zioproto> I mean in python-packages: in the snapcraft.yaml
<mvo> jdstrand: preview (slightly messy) https://github.com/snapcore/snapd/compare/master...mvo5:feature/snap-confine-from-core?expand=1
<mvo> jdstrand: but its essentially what we discussed via mail, i.e. snapd wil create correct apparmor profiles for the snap-confine on core
<zioproto> managed ! #branch=name
<br4nd0m> Hi guys, I am using /snap/bin/snappy-debug.security scanlog my_first_app
<sergiusens> zioproto: yeah, same semantics as with pip
<br4nd0m> to see why AppArmor is blocking it
<popey> br4nd0m: awesome, how's it working out?
<br4nd0m> and I get:* adjust snap to ship 'ip' * adjust program to use relative paths if the snap already ships 'ip'
<br4nd0m> hi popey, it's going OK, just got stuck there
<rvr> ogra_: Serial console on the Pi is the best invention since the sandwich :)
<ogra_> haha
<rvr> ogra_: Do you know why the wifi is not working on the Pi3 yet?
<ogra_> rvr, driver bug, not sure if ppisati ever got around reserching it more (i didnt)
<ogra_> rvr, it works if you first configure wired, then reboot and call sudo console-conf via ssh ... you can then turn off wired, configure wlan and reboot
<rvr> ogra_: I see
<rvr> ogra_: I just re-checked during the first boot, and of course failed
<ogra_> righ, second boot is the key :)
 * Mirv notes that tsdgeos_ should get a shell account or fix internets
<tsdgeos_> Mirv: oh no
<tsdgeos_> it's that snap is hardlocking my system
<tsdgeos_> that's what shoudl be fixed :D
<Mirv> it cannot be, ogra_ says snappy fixes stuff, not breaks
<jdstrand> mvo: http://paste.ubuntu.com/23954598/
<jdstrand> mvo: would be nice if I could comment on your branch before the PR...
<mvo> jdstrand: oh, nice
<mvo> jdstrand: thank you!
<mvo> jdstrand: I can make it into a PR, then you can comment
<jdstrand> mvo: there is one other fun wrinkle that I thought of. /etc/apparmor.d/abstractions vs /var/snap/core/current/etc/apparmor.d/abstractions
<jdstrand> mvo: this is something that has always been there but I don't think we ever considered
<jdstrand> mvo: today I think we are lucky cause the core snap is pulling from the archive and so is the classic host and we haven't made changes to the abstractions, so they are in sync
<mvo> jdstrand: yeah, good point
<jdstrand> mvo: but it is easy to imagine scenarios when they may be out of sync
<jdstrand> mvo: I don't think that has to be fixed here
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2809/files
<mup> PR snapd#2809: cmd/snap-confine-tests: reformat test to pass shellcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/2809>
<mup> PR snapd#2809 opened: cmd/snap-confine-tests: reformat test to pass shellcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/2809>
<mvo> jdstrand: https://github.com/snapcore/snapd/pull/2810 <- so that you can comment more easily
<mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
<mvo> jdstrand: I work on that now
<jdstrand> zyga: speaking of shellcheck. I noticed that my build environment was complaining (non-fatally) that shellcheck wasn't there. I then installed it, and it still complained
<mup> PR snapd#2810 opened: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
<tsdgeos_> not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.21 2.21]): older than "/usr/bin/snap" (2.22.2+17.04)
<tsdgeos_> what does this mean?
<tsdgeos_> is it bad?
<mvo> tsdgeos_: totally harmless - where do you see that?
<tsdgeos_> mvo: /var/log/syslog
<mvo> tsdgeos_: ok, that is expected. it just means your deb version of snapd is newer than the version in the stable core snap. on zesty that is pretty much always the case because zesty is very ahead :)
<tsdgeos_> ok, tx
<pedronis> mvo: we are missing  in ver[1] in the printing that message :)
<pedronis> s/in//
<stokachu> how do i see what applications are available in the core snap
<ogra_> stokachu, we onyl guarantee /bin/sh (and recently python)
<stokachu> ogra_, ok cool, makes it easy
<mvo> pedronis: indeed, the message is not as nice as it should be
<ogra_> stokachu, while theer are indeed a lot more binaries included they can always drop out
<stokachu> ogra_, ack
<ogra_> Mirv, since you are here ...
<ogra_> ogra@localhost:~$ snap install ubuntu-app-platform
<ogra_> error: cannot install "ubuntu-app-platform": snap not found
<ogra_> do we not build it for armhf ?
<jdstrand> mvo: commented
<ogra_> (i can actually install the terminal app butz not the needed platform for it)
<zyga> jdstrand: re-run autogen, that should fix shellcheck
<zyga> jdstrand: it's a configure-time decision
<mvo> jdstrand: thank you!
<zyga> ogra_: we guarantee a bit more
<ogra_> zyga, well, libc
<zyga> ogra_: look at what the apparmor profile allows for various interfaces
<zyga> ogra_: if we say that interface "foo" can run /usr/bin/fooctl then that is what we allow
<ogra_> zyga, well, thats definitely wrong then
<zyga> ogra_: we really do that
<zyga> jdstrand: I added a review to mvo's branch
<ogra_> unless we dropped all our policies
<zyga> jdstrand: please read it as well as it is very tricky business
<ogra_> any binary in the core can drop out at any time
<zyga> guys, I need to run to buy some food
<zyga> I'll be back in one hour
<ogra_> we always said we dont give any guarantee for them to be there
<jdstrand> zyga: any reason why we don't build-depends on shellcheck?
<jdstrand> ogra_: is ubuntu-app-platform only in --edge?
<ogra_> jdstrand, i tried all channels and with/without --devmode
<zyga> jdstrand: 14.04
<ogra_> zyga, huh ?
<zyga> jdstrand: and immense pain on gentoo :)
<ogra_> shellcheck is in ubuntu since ages ...
<zyga> ogra_: it wasn't available last time I looked
<ogra_> it definitely is
<ogra_> https://launchpad.net/ubuntu/+source/shellcheck
<ogra_> hmm
<ogra_> backports ... thats weird ... i knwo i used it in code in 10.04
<jdstrand> zyga: I'm talking about Ubuntu's debian/ directory
<jdstrand> zyga: there is no reason Ubuntu's snapd couldn't BuildDepends on shellcheck. am I missing something?
<ogra_> jdstrand, well, it isnt in 14.04
<zyga> jdstrand: yeah, now it can; it was hard before
<zyga> jdstrand: I'll make that so
<ogra_> as zyga just proved to me ...
 * ogra_ is still baffled
<jdstrand> ogra_: oh, I took your 'ages' comment to include 14.04 :)
<ogra_> jdstrand, well, as i said above, i'm sure i used shellcheck in 10.04 projects
<jdstrand> well, whatever, I have a note now for it
<ogra_> so thats super confusing
<ogra_> but LP doesnt lie
<ogra_> (i assume)
<zyga> jdstrand: can you please approve https://github.com/snapcore/snapd/pull/2811
<mup> PR snapd#2811: cmd: add sc_is_debug_enabled <Created by zyga> <https://github.com/snapcore/snapd/pull/2811>
<mup> PR snapd#2811 opened: cmd: add sc_is_debug_enabled <Created by zyga> <https://github.com/snapcore/snapd/pull/2811>
<zyga> jdstrand: trivial and I plan to use it to avoid debugging-only code in new stuff
<zyga> jdstrand: feel free to request name changes, I will follow up if you want that
 * zyga -> shopping
<mup> PR snapcraft#1119 opened: tests: skip the tests that can't be run in arm64 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1119>
<Son_Goku> sergiusens, hey did you manage to take a crack at refactoring the build/stage-packages backend?
<mterry> didrocks: thanks for quick merge on the desktop helper  :)
<didrocks> mterry: yw! :-)
<Flint> Hi guys
<Guest45206> Quick question, is there a snap packages offering maas-region controller and maas-rack controller or even a maas meta snap package?
<Fl1nt> cls
<Fl1nt> lol
<Fl1nt> ok, so: Here I'm back: Quick question, is there a snap packages offering maas-region controller and maas-rack controller or even a maas meta snap package?
<victorbjelkholm> Is there any way I can provide a mirror for snaps? Basically, a rsync endpoint I could download all the snaps for, then configure snap to fetch the packages from my endpoint instead?
<zyga> re
<tsdgeos_> snap is all unhappy if you try to remove the same thing twice :D
<tsdgeos_> http://paste.ubuntu.com/23955037/
<tsdgeos_> and the spinner stays there foreeeeeeeeeeeever
<mup> PR snapd#2811 closed: cmd: add sc_is_debug_enabled <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2811>
<tsdgeos_> ah. not forever
<tsdgeos_> finished eventaully
<mup> PR snapd#2809 closed: cmd/snap-confine-tests: reformat test to pass shellcheck <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2809>
<mup> PR snapd#2680 closed: interfaces: shutdown: also allow shutdown/reboot/suspend via logind <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2680>
<ppisati> ogra_: even with the modules and firmware directory in /, a freshly created image stops at "Running /scripts/local-premount ..."
<ogra_> ppisati, squashfs compiled in or as module in the initrd ?
<ppisati> ogra_: module, but part of initrd (at least if i trust snapcraft haven't manually checked though)
<ogra_> hmm
<ppisati> ...
<ppisati>       - CONFIG_SQUASHFS=m
<ppisati>     kernel-initrd-modules:
<ppisati>       - squashfs
<ogra_> and you have a proper label on the writable partition ?
<jdstrand> Chipaca: http://paste.ubuntu.com/23955092/
<ogra_> thats the only two things i could imagine making it stop there
<ppisati> ogra_: i dd the image, let me check
<ogra_> oh, also dont forget we have two console= args nowadays
<ogra_> might be the output switches to tty (in case you are watching serial)
<jdstrand> Chipaca: note, with that I can get command tab completion to work and then argument completion to try to work. but things aren't going to be great. eg,
<jdstrand> $ . /etc/bash_completion
<jdstrand> bash-4.3$ fdisk bash: /bin/lsblk: Permission denied
<ppisati> ogra_: i was watching serial and the lcd screen
<ogra_> ah, k
<ppisati> ogra_: indeed the "Running local-premount" only shows on lcd
<jdstrand> Chipaca: (where after 'fdisk ' I pressed <tab>
<ppisati> ...
<ppisati> /dev/sdc8: LABEL="system-boot" UUID="2638-BE3F" TYPE="vfat" PARTLABEL="system-boot" PARTUUID="67822573-51a0-4e57-af2a-7f675ff35f0e"
<ppisati> /dev/sdc9: LABEL="writable" UUID="e0364375-0ae8-4459-8462-2745dfe933a0" TYPE="ext4" PARTLABEL="writable" PARTUUID="fdaaa4cd-7a8e-4f1f-a0f1-4bbb0ea622a8"
<ppisati> and it appears the correct partition label is there
<ogra_> looks fine
<ogra_> well, thats the only thing i could imagie apart from missing kernel config
<ogra_> though i wouldnt know what could be missing
<jdstrand> Chipaca: but it works fine for things that are allowed in teh policy. eg:
<jdstrand> bash-4.3$ dmesg --
<jdstrand> --buffer-size    --ctime          --human          --read-clear
<jdstrand> ...
<ppisati> ogra_: let me do some more debugging
<ogra_> if you boot with break=premount, does /proc/filesystems have squashfs ?
<ogra_> perhaps there is more broken in the kernel plugin
<Chipaca> jdstrand, this is for tab completing of snap apps
 * ppisati tries
<Chipaca> jdstrand, so the completion script itself would be shipped in the snap (hypothetically; i'm still at the proof-of-concept step)
<Chipaca> jdstrand, that's why it was only bash-completion (which granted does ship a lot of completers itself; maybe i need to cut that down and ship our own version of it for this?)
<ppisati> ogra_: ah, i can't stop it at boot prompt
<ppisati> lovely
<ogra_> oh
<zyga> ppisati: did you enable the correct compression options for squashfs?
<jdstrand> Chipaca: I know tyhicks represented the concerns regarding this since something the snap ships is running outside of confinement (unless we do something to confine it, which I gather is what you are working on)
<ogra_> ppisati, even with break=top ?
<ogra_> (that should kick in before *anything runs)
<Chipaca> jdstrand, exactly, what i'm working on is having the completion itself running confined
<ppisati> zyga: http://pastebin.ubuntu.com/23955117/
<cholcombe> anyone willing to take a look at my amd64 build log for rust: https://launchpadlibrarian.net/305573480/buildlog_snap_ubuntu_xenial_arm64_ceph-safe-disk_BUILDING.txt.gz ?  It's failing but I'm not entirely sure why
<jdstrand> Chipaca: so, there is a choice. I just demonstrated tab completion can work for commands on the system. I think there will be issues with different cores and on classic with host /etc mounted in the snap, but it works in principle
<zyga> ppisati: yes, looks good; though you may want to check how this compares to ubuntu kernel on amd64, we changed some things after realizing the settings we used consume gobs of ram
<ppisati> ogra_: i can't break to the uboot prompt (counter is 0), so i need to regenerate uboot.env with tha option appended
<zyga> ppisati: there was a bug about that on the kernel package
<ppisati> zyga: yeah, that was the parallel decompressor
<ogra_> zyga, ppisati http://paste.ubuntu.com/23955121/ ... from the current pi2
<ppisati> yeah, i'll do some debugging
<ogra_> ppisati, you dont need to break at the uboot prompt
<ogra_> just edit cmdline.txt
 * zyga -> some quick food and back to PRs
<ppisati> ogra_: dragonboard unfortunately
<ogra_> and ?
<ogra_> SD is SD
<ogra_> just plug it over to your lpatop/PC
<ppisati> ogra_: there's no cmdline.txt there, does it load automagically?
<jdstrand> Chipaca: I think to make this work for /snap/bin commands to only the user on the system (not in snaps), you could probably extend what is there
<ogra_> oh
<ogra_> crap, yeah
<ogra_> sorry
<Chipaca> jdstrand, I'm possibly missing something, you mind if we PM for a bit?
<ogra_> commandline is indeed in uboot.env only there
<ppisati> yep
<jdstrand> Chipaca: to makes shells in snaps use it (eg, make it work with what I pasted), might have to think about that a bit more
<ppisati> and there's no text versiobn of that uboot.env
<ppisati> ogra_: do you know where i can find the text version of it?
<ogra_> ppisati, https://github.com/snapcore/dragonboard-gadget/tree/master/prebuilt
<ppisati> ogra_: nice, ta
<ogra_> elopio, so lool has to sign the CLA to use non-canonical addresses for signing on github ? could we fix that so that people in core-dev on LP are automatically included ?
<ogra_> that seems a bit strange to demand from people that have full commit rights to all of ubuntu already
<lool> ogra_: it's copyright assignment to Canonical, so perhaps people in some ~canonical team should be exempt
<ogra_> lool, yeah, that then ...
<ogra_> i just find it silly that people already being covered have to sign it again
<ogra_> and i'm personally reluctant to use my @canonical address for anything else than business mail (i.e. on something like github)
<mup> PR snapd#2812 opened: tests: fix "snap managed" output check and supress output from expect in the authenticated login tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2812>
<ogra_> mvo, uuuh ... i'm hitting the "hsearch_r failed" on my laptop ! i thought that happened only during upgrades
<ogra_> ogra@styx:~/Devel/branches/snapd/interfaces/builtin$ telegram-sergiusens.telegram
<ogra_> hsearch_r failed: No such process
 * ogra_ blames sergiusens 
<ogra_> (running the edge core here though)
<elopio> ogra_: from travis, there is no way to check who is in the canonical team in launchpad.
<ogra_> elopio, well, then this check should be postponed until there is
<elopio> ogra_: the script is only an aid. If it fails, we have to check manually
<elopio> it's not a blocker for merging the pr.
<ogra_> or it should not make commits fail
<ogra_> ah, the conversation looked like it was
<elopio> ogra_: that's because sergiusens says that all contributions from canonical employees should be made with the canonical address. I think he read it in some guidelines, but not sure.
<elopio> kgunn: did you get my email?
<ogra_> well
<ogra_> agaik we are free to use our ubuntu.com address ... unless we commit to external projects
<ogra_> *afaik
<ogra_> where it is indeed important that you use cnonical.com when doing commits in your work time
<ogra_> canonical.com
<ogra_> for our own projects thats moot
<elopio> I don't know, I had my personal address as the main one configured everywhere.
<ogra_> also being an employee means you have signed the CLA with your contract :)
<mup> PR snapd#2813 opened: tests: filter ubuntu-core systems for authenticated find-private test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2813>
<elopio> ogra_: I started a thread in canonical-snapcraft about how to check the CLA in a nicer way. Feel free to vent all your frustration there, maybe we get something done.
<ogra_> heh, no frustration here ...
<ogra_> just slight disconcert
<elopio> ogra_: :) we need an agry mob
<mvo> ogra_: sorry, its a general problem with edge, #2810 has a fix
<mvo> ogra_: but still some work required before that can land :/
<ogra_> elopio, http://i.imgur.com/GX5tSki.jpg
<ogra_> mvo, i noticed i was not on the latest ... a snap refresh fixed it ...
 * ogra_ unblames sergiusens 
<mvo> ogra_: interessting
<ogra_> well, in fact a snap refresh core --beta ... which failed complaining about teh configure bits  ... then a snap refresh core ... which just got me updated fine
<ogra_> so i tried to roll back first
<ogra_> perhaps that was the bit making it behave
<mup> Bug #1662962 opened: 'snap find' does not allow channel specification <Snappy:New> <https://launchpad.net/bugs/1662962>
<mup> PR snapcraft#1120 opened: Update rustup link.  Bug: 1662960 <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/1120>
<lool> woudl someone have an example of a gadget.yaml with interface autoconnection handy?
<ogra_> lool, morphis perhaps (but he just said goodbye for the day in another channel)
<mup> PR snapcraft#1112 closed: core: setup core to support classic confinement <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1112>
<mup> Bug #1662899 opened: Snap packages install but can't be run <isv> <Linux Mint:New> <Snappy:New> <https://launchpad.net/bugs/1662899>
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2814
<mup> PR snapd#2814: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814>
<zyga> jdstrand: the mount/umount command helpers, with better buffer handling and with past issues fixed
<mup> PR snapd#2814 opened: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814>
<zyga> jdstrand: if you can review that today I'll propose the actual useful cleanup of snap-confine that uses sc_mount/sc_umount and doesn't log manually
<zyga> jdstrand: I was also wondering how to progress on the big update-ns branch, I think that the mount entry helpers PR is the first one to land there
<zyga> jdstrand: namely this branch: https://github.com/snapcore/snapd/pull/2775
<mup> PR snapd#2775: cmd: add functions to load/save fstab-like files <Created by zyga> <https://github.com/snapcore/snapd/pull/2775>
<oky> how would something like an /etc/ file be handled with snappy packaged programs? i want a config file that can be edited by someone outside the snap
<zyga> oky: store it in $SNAP_DATA or $SNAP_USER_DATA
<zyga> oky: or use snappy configuration system (using the configure hook)
<zyga> oky: and snap get/set commands
<zyga> oky: normal /etc is off-limits
<zyga> oky: and is mostly read only
<oky> zyga: alright, i understand. i was hoping there'd be another option available (like readwrite mounts into the snap)
<oky> zyga: or like a particular dir in the snap that is exposed as RW (where i can place configs)
<zyga> oky: you just described $SNAP_DATA
<zyga> oky: as for mounts, that may come but not in the next few releases
<zyga> oky: and it would still be a poor UX for users
<zyga> oky: that mount would be visible only to the snap, at runtime
<zyga> oky: (to that particular snap)
<zyga> oky: and users would still have to edit $SNAP_DATA/$SNAP_USER_DATA
<oky> zyga: sure. i'll need to look to see how i can pre-populate the SNAP_DATA dir with my configs
<zyga> oky: you should use a wrapper around your real app
<zyga> oky: I think this is the only reliable way today
<zyga> oky: configure hook runs after services start
<zyga> oky: (or doens't always run before)
<oky> i've already made several (maybe 5 or more) changes to my program to work with snap (specifically around using SNAP_DATA and SNAP_USER_DATA), now realizing that i need a configurable /etc/ system, it seems like i need to make some more
<oky> thanks for the guidance, zyga - i'll be exploring the options you outlined
<zyga> oky: good luck
<Fl1nt> guys, is there someone working on maas snaps?
<zyga> Fl1nt: I bet but I think you should ask on the maas mailing list or ping the maas developers directly
<Fl1nt> ok, thanks a lot zyga
 * ogra_ bets someone like stokachu would know 
<ogra_> (or at leats be able to point in the right direction)
<Fl1nt> zyga: got my answer \o/ They made my day :D
<Fl1nt> see ya guys, thanks a lot for your support.
<jkridner> call for participation in #beagle-gsoc: http://bbb.io/gsoc
<jdstrand> zyga: I'll try
<rogpeppe1> just checking: if I want my snap to have some configuration options, is this the mechanism I should use? https://developer.ubuntu.com/en/snappy/guides/config/
<rogpeppe1> also, how is that related to https://github.com/snapcore/snapd/wiki/Configuration ?
<rogpeppe1> niemeyer: ^
<rogpeppe> niemeyer: (hiya BTW!)
<niemeyer> rogpeppe: Heya
<niemeyer> rogpeppe: The former is completely out of date.. the "snappy" command doesn't even exist anymore
<rogpeppe> niemeyer: ok - that's the first result that google gives me when googling for "ubuntu snap configuration"
<niemeyer> rogpeppe: The latter is the current mechanism
<niemeyer> rogpeppe: We should kill it
<rogpeppe> niemeyer: ok, great
<rogpeppe> niemeyer: i'm glad i asked :)
<rogpeppe> niemeyer: BTW my snappy-based domestic power control system has been coming along a lot in the last week.
<rogpeppe> niemeyer: lots of "things" on the net here
<niemeyer> @rogpeppe Sweet, that's great to hear!
<nothal> niemeyer: No such command!
<niemeyer> @nothal sshh!
<nothal> niemeyer: No such command!
<rogpeppe> lol
<rogpeppe> niemeyer: one stumbling block has been lack of rtc integration
<rogpeppe> niemeyer: but i managed to work around it by making a systemd unit to set the time before the snap unit starts
<ogra_> rogpeppe, well, did you try to follow the raspbian howto and try to hack the things they use to get it working into a core image ?
<ogra_> rtc integration is fine ... just third-party rtc isnt :)
<rogpeppe> ogra_: i added the usual dtoverlay to the boot config, if that's what you mean
<rogpeppe> ogra_: it even worked once
<ogra_> well, there is more to it than the dtoverlay i guess
<rogpeppe> ogra_: but not ever again
<rogpeppe> ogra_: i don't really understand the kernel internals of how /dev/rtc is provided tbh
<rogpeppe> ogra_: s/really understand/understand a thing about/ :)
<ogra_> https://www.abelectronics.co.uk/kb/article/22/rtc-pi-on-a-raspberry-pi
<ogra_> i fear we still have a bug with i2c not being enabled in config.txt ...
<ogra_> that would be your first step
<ogra_> we dont blacklist the i2c modules so you can skip that bit
<ogra_> but i guess you will definitely need step 4 from the tutorial
<rogpeppe> ogra_: almost none of those instructions work as is in snappy
<rogpeppe> ogra_: no i2cdetect
<ogra_> yeah skip that
<ogra_> but make sure to have i2c enabled in config.txt
<rogpeppe> ogra_: the device works ok
<rogpeppe> ogra_: i have a program that talks to it fine
<ogra_> on snappy ?
<rogpeppe> ogra_: yeah
<rogpeppe> ogra_: https://github.com/rogpeppe/misc/blob/master/cmd/pirtc/rtc.go
<ogra_> hmm, so whats the exact issue now
<rogpeppe> ogra_: /dev/rtc doesn't exist
<rogpeppe> ogra_: so timedatectl can't use it
<ogra_> well, the device should be created when the module is loaded
<rogpeppe> ogra_: the rtc module?
<ogra_> does lsmod show rtc-ds1307 ?
<rogpeppe> ogra_: no
<ogra_> aha
<ogra_> well, so modprobe it ;)
<ogra_> then check dmesg
<rogpeppe> ogra_: ok. i've not used modprobe before.
<ogra_> sudo modprobe rtc-ds1307
<ogra_> ;)
<ogra_> then check the end of dmesg and see if it created some device
<rogpeppe> ogra_: lsmod now shows the module
<ogra_> good
<zyga> rogpeppe: see, I told you to talk to ogran :)
<zyga> well, ogra even
<ogra_> ogra[n]
<ogra_> :)
<rogpeppe> ogra_: no device though
<ogra_> one of my many personalities
<rogpeppe> ogra_: and nothing in /var/log/dmesg
<ogra_> rogpeppe, ok ...
<rogpeppe> ogra_: is modprobe persistent?
<ogra_> not over reboots ...
<ogra_> rogpeppe, so now ... sudo -s
<ogra_> echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
<ogra_> then check dmesg again
<kalikiana> Hmmmm no package snapcraft on trusty?
<rogpeppe> ogra_: still nothing in dmesg
<ogra_> any /dev/rtc now ?
<rogpeppe> ogra_: yup!
<ogra_> aha
<rogpeppe> ogra_: my pirtc command now no longer works (2017/02/08 18:48:36 cannot open: error opening the address (104) on the bus (/dev/i2c-1): device or resource busy) - that's probably healthy though.
<ogra_> rogpeppe, so as a quick hack: create a file /etc/modules-load.d/modules-rtc.conf ... and add rtc-ds1307 to it
<mup> PR snapcraft#1059 closed: pluginhandler: support more complex stage-packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1059>
<rogpeppe> ogra_: just "rtc-ds1307" as a single word on its own line?
<ogra_> long term this requires the new snappy config setup for core which does not knwo about modules yet though
<ogra_> yeah
<ogra_> only that
<ogra_> i'm not sure how we can add the "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device" though ...
<ogra_> normally you woould do that through a line in /etc/rc.local but we do not make that writable on purpose
<rogpeppe> ogra_: ok, done
<rogpeppe> ogra_: so should that have fixed my issue?
<ogra_> well, you need that echo line before it works apparently
<rogpeppe> ogra_: if so, i'll reboot and check
<ogra_> the module is only half the solution,  the other half is the "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"
<ogra_> after that hwclock -s and -r should just work
<ogra_> err
<ogra_> hwclock -r and -w
<rogpeppe> ogra_: ok, so to get things straight, on a new device, to get rtc working, i add "dtoverlay=i2c-rtc,ds1307" to /boot/uboot/config.txt; i run "modprobe rtc-ds1307; echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"
<rogpeppe> ogra_: sound about right?
<rogpeppe> ogra_: i'm thinking that timedatectl should just use it when it's there, right?
<ogra_> yeah, that is how i read the vendor page :)
<ogra_> right
 * rogpeppe reboots
<ogra_> but it wont work on boot since you will have to manually do the echo bit still
<ogra_> and without rc.local being writable that will be a bit tricky to get going
<rogpeppe> ogra_: oh
<rogpeppe> ogra_: right, so it actually doesn't solve my issue, unfortunately, 'cos it must be done on boot
<ogra_> (and i also suspect rc.local might be a bit late, the hwclock start job runs before that i fear)
<rogpeppe> ogra_: i guess at least now i can dispense with my pirtc command)
<ogra_> rogpeppe, we need to find a solution for that though :) please file a bug
 * ogra_ wonders how we can solve that ... thats really a bit tricky
<rogpeppe> ogra_: where's the right place to file this kind of bug?
<ogra_> see the channel topic
<ogra_> image realted bugs are fine on the snappy project
<rogpeppe> ogra_: in fact, i think you might be better to file the bug because i don't actually know what the underlying issue is here but you do
<mup> PR snapd#2815 opened: release: don't force devmode on LinuxMint "serena" <Created by zyga> <https://github.com/snapcore/snapd/pull/2815>
<rogpeppe> ogra_: i.e. is the problem because the device isn't being created or because the module's not being detected or...
<ogra_> rogpeppe, because the addon board needs the echo line for initialization
<rogpeppe> ogra_: or i could just file a bug that says "h/w RTC doesn't work on raspberry Pi"
<ogra_> the module loads obviously and we also have the devicetree file but you can do the last step
<ogra_> no, rtc works ... generically ... thats specific to the addon board initialization
<ogra_> i'm filing one
<rogpeppe> ogra_: thanks
<rogpeppe> ogra_: that's why it's better you file it :)
<mup> Bug #1662899 changed: Snap packages install but can't be run <isv> <Linux Mint:Invalid> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1662899>
<mup> Bug #1663001 opened: rc.local not writable, but i2c addon board needs special treatment <Snappy:New> <https://launchpad.net/bugs/1663001>
<ogra_> rogpeppe, ^^
<ogra_> would be nice if you could "me too" that one :)
<ogra_> i might have further questions and since you are the only one owning that HW ....
<rogpeppe> ogra_: done
<ogra_> thx
<ogra_> and sorry for not getting back to you on the ML yet
<ogra_> (and thanks for hunting me down here now)
<rogpeppe> ogra_: FWIW that seems like the most obvious h/w for anyone that might use an RTC on a pi
<rogpeppe> ogra_: np, thanks for helping out now
<rogpeppe> ogra_: one difficulty i have with using snappy is that it's not clear how much in the system is snappy-specific and how much is generic linux stuff.
<ogra_> just forget about generic linux stuff and assume its all new :)
<ogra_> i.e. all the above we just did are hacks in the light of snappy ...
<cholcombe> this is a silly question but how do i unit test just the rust plugin and not the entire world?  I've tried a bunch of different patterns and I can't seem to hit the right one
<kyrofa> cholcombe, python3 -m unittest snapcraft.tests.plugins.test_rust
<cholcombe> kyrofa, thanks :)
<cholcombe> so it's the python path not the directory
<kyrofa> cholcombe, nothing magical there. The ./runtests.sh essentially just does that plus the discover module
<kyrofa> cholcombe, right
<cholcombe> kyrofa, does sources.Script default to setting the name of the file it downloads to the same name as the link?
<kyrofa> cholcombe, I'm not sure off the top of my head
<cholcombe> ok
<kyrofa> cholcombe, but you can look, it's in snapcraft/internal/sources/
<pmcgowan> kyrofa, is there a way to reinitialize my state.json on a device
<kyrofa> pmcgowan, I've never tried. Did you try stopping snapd and renaming that file?
<pmcgowan> kyrofa, not yet
<kyrofa> pmcgowan, that's really my only idea :P
<pmcgowan> I saw an old post that said to restart the firstboot service, but thats not there any mre
<kyrofa> pmcgowan, zyga would probably know better
<kyrofa> pmcgowan, or ogra_ perhaps?
<zyga> pmcgowan: hmm, on a device
<zyga> pmcgowan: why do you want to do that?
<pmcgowan> zyga, yeah, still playing around with my stuck dragonboard
<zyga> pmcgowan: the store was just fixed
<zyga> pmcgowan: can you try to refresh now?
<pmcgowan> zyga, oh?
<pmcgowan> one sec
<pmcgowan> zyga, its working on the first snap I tried
<zyga> pmcgowan: sounds promising, try to refresh core
<pmcgowan> zyga, it started to refresh automagically
<pmcgowan> its working woot
<zyga> woot :)
<pmcgowan> zyga, what was the issue?
<zyga> pmcgowan: store-side bug, according to pedronis the store was asking to refresh the wrong macaroon so the client refreshed but was back to square one
<pmcgowan> great glad its fixed
<ogra_> pmcgowan, whee ! here too !
 * zyga EODs
<zyga> ttyl
<pedronis> pmcgowan: ogra_: great
<pmcgowan> pedronis, why only certain devices?
<ogra_> matter of them having been off for a while
<pedronis> pmcgowan: first it needed to be core (it doesn't affect classic), 2nd it depends when the last time the macarron was created/refreshed
<ogra_> zyga saw it on a pi today ...so it wasnt actually drafgonboard specific
<pmcgowan> ok
<pedronis> pmcgowan: the bug was introduced unoticed in the store a little bit ago
<pedronis> pmcgowan: but it triggered only once the macaroon were starting to expire and need refreshing
<pmcgowan> gotcha
<pmcgowan> pedronis, is there a bug # for that? I can close the snapd one
<pedronis> we are also looking how to tests these paths a bit more (it's a bit complicated because of the expiry side of this, normally it's relatively long)
<pedronis> pmcgowan: not yet, we'll do some bug gardening tomorrow
<pmcgowan> ok
<ogra_> woah
<ogra_> 2017-02-08T19:46:49Z ERROR cannot remove snap file "core", will retry in 3 mins: [--root / disable snap-core-533.mount] failed with exit status 1: Failed to execute operation: Structure needs cleaning
<pmcgowan> whered ya see that
<ogra_> after the snap refresh core
<ogra_> smells a bit like my SD is borked
<ogra_> ogra@dragon:~$ sudo reboot
<ogra_> sudo: error in /etc/sudo.conf, line 0 while loading plugin `sudoers_policy'
<ogra_> sudo: unable to load /usr/lib/sudo/sudoers.so: /usr/lib/sudo/sudoers.so: cannot read file data: Input/output error
<ogra_> sudo: fatal error, unable to load plugins
<pmcgowan> oops
<pedronis> pmcgowan: I moved this one to store
<pmcgowan> pedronis, perfect
<pedronis> now there's  snapstore project for those
<pedronis> pmcgowan: the other strange message about needing to buy core, is that after removing creds the stuck download got a 401 and there's a bit of lack of details there atm, so snapd assumed is a non-free snap
<pedronis> that one needs  a bit of work both in store and snapd
<pmcgowan> pedronis, right I saw that commentary
<ogra_> yay
<ogra_> ogra@dragon:~$ snap refresh
<ogra_> All snaps up to date.
<ogra_> so after reboot it is back in order
<pmcgowan> nice
<pedronis> it's a cosmetic/UX issue though, nothing fundametally broken, but bad error reporting
<pmcgowan> right
<ogra_> ogra@dragon:~$ snap info core|grep installed
<ogra_> installed:   16.04.1 (1133) 67MB -
<pmcgowan> now to remember what I was doing
<mup> PR snapcraft#1121 opened: cleanbuild: allow talking to a remote <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1121>
<mup> PR snapd#2802 closed: snap-confine: make sc_map_search/read_number take const const char * arguments <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2802>
<mup> PR snapd#2816 opened: interfaces/builtin/core-support: Allow modifying logind configuration from the core snap <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2816>
<mup> PR snapcraft#1108 closed: store: add support for tracks in channels <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1108>
<zyga> jdstrand: re, regarding strncmp I thin we ought to compare strlen()+1 characters
<zyga> jdstrand: otherwise this happens:
<zyga> 	printf("%d\n", strncmp("noneofyourbusiness", "none", 5));
<zyga> jdstrand: comparing 4 characters means they are equal
<zyga> jdstrand: we should compare 5,
<zyga> jdstrand: do you agree?
<jdstrand> zyga: using 5 is fine. note my comments mentioned that
<zyga> jdstrand: right (start with)
<jdstrand> not 5 specificially, but that nothing should be noneofyourbusiness
<zyga> jdstrand: I just wanted to be on the safe side
<jdstrand> that's fine
<zyga> jdstrand: thanks
<zyga> jdstrand: hmm, thinking about it some more, I think that strncmp and strcmp with one constant string is identical
<zyga> jdstrand: I already made the change but we will compare at most 5 characters in both cases
<jdstrand> zyga: that would be implementation-specific. strcmp may use a strlen() on a non-terminated string
<victorbjelkholm> Is there any way I can provide a mirror for snaps? Basically, a rsync endpoint I could download all the snaps for, then configure snap to fetch the packages from my endpoint instead?
<zyga> jdstrand: hmm, indeed, thanks for the insight!
<zyga> victorbjelkholm: not at present
<victorbjelkholm> zyga: thanks. "not at present" referring to a rsync endpoint? There is some other way I could have my own mirror?
<zyga> victorbjelkholm: no
<zyga> victorbjelkholm: you may try to write a proxy for the snap store
<zyga> victorbjelkholm: that should be doable today
<victorbjelkholm> ooh... I see... So where are the snaps hosted today?
<zyga> victorbjelkholm: you can then point snapd at your proxy and have it mirror or cache stuff
<zyga> victorbjelkholm: in a CDN, I don't know the details
<victorbjelkholm> yeah, that makes sense
<victorbjelkholm> ah, so I guess it's a CDN hosted by/owned by Canonical?
<zyga> jdstrand: can you re-review the sc_u?mount_cmd branch please
<victorbjelkholm> hm, maybe the snaps will never be mirrorable if so...
<zyga> jdstrand: minimal changes as instructed
<zyga> victorbjelkholm: I believe someone will come up with a proxy
<zyga> victorbjelkholm: as for mirroring it is not clear as snaps don't have to be FOSS
<zyga> victorbjelkholm: and may require license
<zyga> victorbjelkholm: the free snaps should be possible to mirror but I don't know if anyone works on this
<victorbjelkholm> ah, yeah, wouldn't be too hard, I'm just afraid of installing things from a central repository I have no idea where it comes from or where it's hosted
<zyga> victorbjelkholm: as the API stands today snapd asks the store for the URL
<zyga> victorbjelkholm: why?
<victorbjelkholm> so in the end snaps would be the same as .deb packages today, multiple repositories with different requirements and uses
<victorbjelkholm> I'm not sure I can trust it, might be a CDN running on some randoms computer, I have no information at this point and I'm having troubles finding it as well
<zyga> victorbjelkholm: because each snap is signed and there is a root of trust there's a different approach to repositories
<zyga> victorbjelkholm: one store can aggregate other stores
<victorbjelkholm> ah, where can I see this chain of trust?
<zyga> victorbjelkholm: but you cannot use multiple stores
<zyga> victorbjelkholm: in github.com/snapcore/snapd look at the asserts package
<zyga> victorbjelkholm: and the overlord/assertstate package
<zyga> victorbjelkholm: one store design solves many issues in a natural way (name authority for instance)
 * zyga gets back to his family
<zyga> jdstrand: if you +1 it I'll get a 2nd +1 from the rest of the team tomorrow
<victorbjelkholm> hm, not sure I understand. But yeah, have dinner here as well so maybe we'll speak later
<zyga> jdstrand: thank you for the detailed review, I need to stamp strNfoo on my screen
<zyga> :-)
<jdstrand> heh
<jdstrand> well, strNfoo aren't always the answer, but they can be helpful in certain situations
<zyga> yeah but I rarely think about them
<mup> PR snapd#2817 opened: many: switch channels on refresh if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2817>
<jdstrand> zyga: I think I am being dense: http://paste.ubuntu.com/23956602/
<jdstrand> zyga: I couldn't reconcile your comment to what I was thinking. can you enlighten me?
<mup> PR snapcraft#1122 opened:  repo: cache stage packages for faster future use <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1122>
<mup> PR snapcraft#1119 closed: tests: skip the tests that can't be run in arm64 <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1119>
<mup> PR snapd#2812 closed: tests: fix "snap managed" output check and supress output from expect in the authenticated login tests <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2812>
<cholcombe> elopio, that PR i put in should fix my build problems on arm64 and ppc64 i hope :)
<mup> PR snapcraft#1123 opened: Adding Fish she'll source and IDEA IDE to gitignore <Created by joedborg> <https://github.com/snapcore/snapcraft/pull/1123>
<zyga> jdstrand: hey
<zyga> jdstrand: you are currect, it is just the case that MS_REC has no meaning alone
<zyga> jdstrand: so your code is closer to ideal but the difference does not matter here
<jdstrand> zyga: right. in the 'what I expected' code, it never would be
<zyga> jdstrand: the goal of that variable is to collect flags we've used so that we don't repeat them
<zyga> jdstrand: since they use special syntax
<jdstrand> zyga: well, but isn't it with the current code at least possible for MS_REC to be set when it should not?
<zyga> jdstrand: yes but that is harmless, we use that as a mask to filter out stuff not to show again
<zyga> jdstrand: yes, you can call mount (..., MS_REC)
<zyga> jdstrand: and that will show
<zyga> jdstrand: if you couple that with MS_PRIVATE it won't show again but you will see --make-rprivate
<zyga> jdstrand: it's subtle
<zyga> jdstrand: because we don't filter invalid arguments
<zyga> jdstrand: if you want I can be precise there
<zyga> jdstrand: but I don't think it matters (in this specific case)
<cholcombe> sergiusens, i don't get why it's still looking for rustup.sh.  I changed the unit tests.  Maybe there's some test i missed?
<jdstrand> zyga: I think either being precise or adding a comment as to why you don't need to be precise would be good, cause the way it reads (at least a quick reading) is that MS_BIND alone will set MS_REC and you'll get --rbind
<zyga> jdstrand: wait, that shoud not be the case
<zyga> jdstrand: you will get --bind
<zyga> https://github.com/snapcore/snapd/pull/2814/files#diff-380b7bd2738396bc92ee5a2bd7f81d11R191 (I'm sure you know this now but just to be clear, we unset the bits seen in used_special_flags)
<mup> PR snapd#2814: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814>
<zyga> jdstrand: and this is tested: https://github.com/snapcore/snapd/pull/2814/files#diff-70758630224dcb7ba3963d1fa05bb69aR102
<mup> PR snapd#2814: cmd: add helpers for working with mount/umount commands <Created by zyga> <https://github.com/snapcore/snapd/pull/2814>
<jdstrand> actually, I missed the one's complement
<jdstrand> zyga: ok, I responded. couple of small things but feel free to pass along
<cholcombe> anyone want to take a quick peek at my pr and see where i goofed: https://github.com/snapcore/snapcraft/pull/1120 ? I looked at the download function and it uses os.path.basename for the link you give it.  My change should work but the units are still failing
<mup> PR snapcraft#1120: Update rustup link.  Bug: 1662960 <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/1120>
<cholcombe> i deleted the pyc files just to see if that was it but it's not
<cholcombe> i see it.  thank you grep :D
<mup> PR snapcraft#1121 closed: cleanbuild: allow talking to a remote <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1121>
<mup> PR snapcraft#1113 closed: repo: cache stage packages for faster future use <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1113>
<mup> PR snapcraft#1124 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1124>
<mup> PR snapcraft#1124 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1124>
#snappy 2017-02-09
<seshu> zyga: Do you have the snapd documentation on snap refresh, first boot behavior.
<mup> PR snapcraft#1054 closed: [WIP] snapcraft as a snap <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1054>
<mup> PR snapcraft#1069 closed: snapcraft.yaml and building in snap directory <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1069>
<mup> PR snapcraft#1125 opened: tests: fix the env vars passed to the docker container in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1125>
<eeight> wow that much people, neat!
<eeight> is it true that if i publish a snap on myapps.developer.ubuntu.com and send an update, people will get my update automagically after 24h?
<eeight> also I don't see the documentation for plugs: ... (need to access the webcam) https://snapcraft.io/docs/reference/
<mup> Bug #1663091 opened: Mir interface does not auto-connnet <Snappy:New> <https://launchpad.net/bugs/1663091>
<mup> Bug #1663060 opened: Add a title field to snap metadata <Developer registration portal:New> <Snappy:New> <gnome-software (Ubuntu):New> <snapcraft (Ubuntu):New> <snapd (Ubuntu):Triaged> <snapd-glib (Ubuntu):New> <https://launchpad.net/bugs/1663060>
<mup> Bug #1663103 opened: No snapd API to determine which plugs/slots an app uses <Snappy:New> <https://launchpad.net/bugs/1663103>
<mup> PR snapcraft#1117 closed: [wip] build and push the API docs to github pages <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1117>
<mup> PR snapcraft#1122 closed:  repo: cache stage packages for faster future use <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1122>
<mup> PR snapd#2818 opened: Allow specifying another store via env variable for the download command <Created by morphis> <https://github.com/snapcore/snapd/pull/2818>
<mup> Bug #1662817 changed: some snaps stop working after revert the core snap <Snappy:New> <https://launchpad.net/bugs/1662817>
<Mirv> ogra_: we have arm64, since the general idea was vivid/armhf/click -> xenial/arm64/snap. of course, armhf would be only a click^Wsnap away in Launchpad.
<Guest> hi all here
<Guest> i'm found some new ubuntu-core ami on aws, but i cannot connect to instances via ssh
<Guest> maybe i need some like `ssh_enabled: True` on instance user data?
<liuxg> ogra_,  so far, packageproxy works well. However, i find that it does not cache the packages for ppa:ci-train-ppa-service/stable-phone-overlay. when I build my app, this repository always re-downloaded. is this normal? thanks
<mup> PR snapd#2816 closed: interfaces/builtin/core-support: Allow modifying logind configuration from the core snap <Created by ssweeny> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2816>
<liuxg> ogra_, ping
<ogra_> liuxg, edit /snap/packageproxy/current/config.yaml and add an entry to the "repos" list there ... then restart packageproxy or reboot
<liuxg> ogra_, really, I do not know the trick. thanks. let me try it :)
<ogra_> i.e. like: [ubuntu-overlay,http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu]
<ogra_> i must damit i never tried ppas, so no guarantee that it works ... but after all ppas are just archives
<ogra_> *admit
<ogra_> liuxg, in your sources.list on the client you then use something like: deb http://localhost:9999/ubuntu-overlay xenial main
<liuxg> ogra_, so, I need to use two places, right?
<mup> PR snapd#2819 opened: packaging/ubuntu-14.04: inform user how to extend PATH with /snap/bin <Created by vosst> <https://github.com/snapcore/snapd/pull/2819>
<liuxg> ogra_, one is for the config.xml and the other is sources.list
<ogra_> well, like you always do ... on the client you use sources.list and on the server the config.yaml
<liuxg> ogra_, ok. thanks
<liuxg> ogra_, , one problem here, /snap/packageproxy/current/config.yaml is read only.
<liuxg> ogra_, we cannot change the file mannually
<ogra_> oh, right, there is a writable version in SNAP_DATA
<ogra_> sorry, the above is indeed the wrong location
<liuxg> ogra_, so, var/snap/packageproxy/current$ , this is the location. but I think it is good to add it to your app by default
<liuxg> ogra_, so that everyone does not need to manually add it. what do you think?
<ogra_> well, once i fixed the config hooks you will just use "snap set"
<liuxg> ogra_, yeah, I know.
<ogra_> this used to work in 15.04 with snappy config, i just havent ported that part yet
<ogra_> Mirv, i'd really appreciate that one click ;) i assume we might actually have some users using RPi's for kiosk apps or even with unity8 once it runs smooth
<kalikiana> +1
<ogra_> (it actualyl runs very smooth btw (i got it running here) it is just still awfully buggy)
<kalikiana> Meanwhile I'll ask once more: does anyone know about snapcraft on Trusty? The package doesn't seem to be there. I kinda expected snapd and snapcraft to be like a monogamous couple that won't be separated
<ogra_> kalikiana, well, they are separate projects
<ogra_> kalikiana, ask sergiuens or kyrofa
<mup> Bug #1663175 opened: chroot not allowed in devmode/strict <Snappy:New> <https://launchpad.net/bugs/1663175>
<mup> Bug #1663177 opened: "Bad System Call" when using "dbus" snapd interface <Snappy:New> <https://launchpad.net/bugs/1663177>
<ogra_> (once they are up)
<t1mp> kalikiana: I assume that even on trusty, the snaps run against the 16.04.1 ubuntu-core snap, so then they should be built on xenial?
<kalikiana> Yeah, I guess they are, I tend to see it as part of the same meta thing.
<kalikiana> t1mp: Right, I would expect the sources for 16.04 to be used.
<kalikiana> Note: I'm saying this with my user hat on.
<kalikiana> It makes sense to my mind, but it could be blocking on some bugs.
<t1mp> didrocks: are the desktop helpers are pulled in from github when building a snap? So then https://github.com/ubuntu/snapcraft-desktop-helpers/commit/82ebfb53afa897f32ac029fd46fe4b7453319037 is effective immediately when I build a snap now?
<kalikiana> Try it. The answer should be evident?
<t1mp> right :)
<didrocks> t1mp: indeed, it's effective immediately. Only if snapcraft.yaml definition changed you need to snapcraft update first
<t1mp> didrocks: great, thanks.
<didrocks> (or you will get older snapcraft.yaml content with newer git code)
<didrocks> yw!
<kalikiana> didrocks: Do you know if that'll be automated at one point? I find it confusing and potentially error-prone to have to 'snapcraft update' "in case something changed"
<didrocks> kalikiana: I think it's something to discuss with sergio
<didrocks> kalikiana: he wasn't against it latest time we did discussed about it
<didrocks> and yeah, it's error-prone, I got caught myself once :)
<mup> PR snapd#2820 opened: Add send/recv syscalls for upower-observe interface as required on ARM <Created by morphis> <https://github.com/snapcore/snapd/pull/2820>
<mup> PR snapd#2821 opened: overlord/ifacestate: setup seccomp security on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/2821>
<mup> PR snapd#2822 opened: Added a linux framebuffer interface <Created by femdom> <https://github.com/snapcore/snapd/pull/2822>
<Mirv> ogra_: armhf platform snap now available in the store (candidate, beta and edge channels)
 * ogra_ hugs Mirv 
<ogra_> (and his cat)
<kalikiana> lol
<tsdgeos> jdstrand: are you the one to talk about apparmor/snap socket() call accepting/rejecting ?
<liuxg> ogra_, after I change the config.yaml and sources.list, it still fetches from the server. is there anything I did worngly? I have rebooted the machine. sources.list http://paste.ubuntu.com/23959907/, /var/snap/packageproxy/current/config.yaml http://paste.ubuntu.com/23959909/
<ogra_> liuxg, looks all fine to me ... and you did apt update and removed the old ppa entries from the clients sources ?
<ogra_> liuxg, note that the ppa bits might be in sources.list.d/
<liuxg> ogra_, previously, I used "sudo add-apt-repository ppa:ci-train-ppa-service/stable-phone-overlay" to add the ppa. do you mean I need to use "sudo add-apt-repository -r" to remove it?
<ogra_> yeah
<liuxg> ogra_, ok. I got it. thanks
<ogra_> as long as you have it in sources.list (or .d/ ) it will indeed be used
<liuxg> ogra_,  http://paste.ubuntu.com/23959927/, this is it. so I need to remove it, right?
<ogra_> right
<ogra_> and the next apt update should actually show it using ubuntu-overlay then
<zyga> re
<zyga> tsdgeos: hey, how can I help you
<tsdgeos> zyga: so i'm trying to figure out if it's on purpose that we're denying this call without the network plug
<tsdgeos> socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT);
<zyga> definitely
<tsdgeos> this is basically udev connecting to it's socket
<tsdgeos> so it's not a network connection
<tsdgeos> s/it's/its
<zyga> tsdgeos: yes but before recently we didn't do argument filtering in seccomp
<zyga> tsdgeos: even now I don't think we will allow this in the network interface
<tsdgeos> zyga: why?
<zyga> tsdgeos: there should be a dedicated netlink interface as netlink is rats nest of stuff
<zyga> tsdgeos: netlink is privileged
<tsdgeos> so basically any app using udev won't be functional?
<zyga> tsdgeos: any app using netlink will need a correct interface
<zyga> tsdgeos: (security is hard)
<zyga> tsdgeos: what exactly do you need to do?
<zyga> tsdgeos: often there's an easier solution
<tsdgeos> no :D
<tsdgeos> you know i'm using qml that uses the ubuntu-ui-toolkit that uses QtSystemInfo that uses udev
<tsdgeos> and udev uses that socket
<tsdgeos> sure i can rewrite the world
<liuxg> ogra_, if I have another computer pointing to the server, does it need to have any authorization? I have not tried it yet.
<zyga> tsdgeos: I see, this needs to be discussed with the security team, my rough feeling is that it may require patches to qt or a review of what is allowed once you have a netlink socket
<zyga> tsdgeos: jdstrand is the right person for that, yes
<tsdgeos> ok
<ogra_> liuxg, nope, it just acts like a http server
<ogra_> no auth required
<tsdgeos> zyga: so what's the best way to discuss this? a bug? an email? if a bug, where, in launchpad?
<ogra_> but make sure your sources.list is correct indeed
<liuxg> ogra_, so, is there any security issue?: )
<liuxg> yeah, I will have a try for it. thanks
<zyga> tsdgeos: bug is a first idea, yes, file it on launchpad.net/snapd, tag it with #snapd-interface tag
<ogra_> well, some hacker could DOS your disk by downloading the whole archive i guess :)
<tsdgeos> zyga: ok, will do, thanks
<liuxg> ogra_, yeah, that is what I am thinking :)
<ogra_> but beyond that it is just a copy of deb packages in the end
<ogra_> no risk in that
<tsdgeos> Mirv: meanwhile i guess you can patch qtsystems with my patch so we get reduced functionality instead of a crash :D
<liuxg> ogra_, yeah, I got it. just joking :)
<zyga> tsdgeos: I would love to know what happens after you have that netlink socket
<zyga> tsdgeos: if you can add that to the code it would be fantastic
<tsdgeos> reads from it afaics
<zyga> tsdgeos: sure but what exactly is being looked for
<tsdgeos> zyga: what do you mean? "what is being looked for"
<zyga> tsdgeos: so you read from it, what happens then
<zyga> tsdgeos: what information is being accessed
<zyga> tsdgeos: what's the goal of QtSystemInfo
<tsdgeos> gives you system info
<zyga> which is what exactly?
<tsdgeos> in this particular case it's telling us if you have keyboard/mouse attached
<zyga> tsdgeos: thanks, please attach this to the bug as well
<tsdgeos> will do
<liuxg> ogra_, you are right. the second time is super fast!
<ogra_> ;)
<liuxg> ogra_, previously, it took almost one hour to build it :(
<ogra_> wow, bad
<liuxg> ogra_,  yes, this is why your solution is super. I will try to use another machine to access it.
<t1mp> didrocks: great, thanks.
<t1mp> heh, I thought I sent that message 1.5h ago ;)
<t1mp> why do I get DEPRECATED: Custom plugins should now be placed in 'snap/plugins'.
<t1mp> when I don't have custom plugins?
<t1mp> plugin: nil and plugin: dump don't seem custom to me.
<kalikiana> t1mp: Do you have a folder parts/plugins?
<t1mp> kalikiana: no
<kalikiana> Hmmm maybe something in a cloud part?
<didrocks> could be, desktop helpers don't have though
<didrocks> unsure about the other you get
<t1mp> I use after: [desktop-ubuntu-app-platform]
<t1mp> it has plugin:make
<t1mp> but that doesn't sound like a "custom plugin" to me
<kalikiana> Right, it's not
<didrocks> yeah, there is no custom plugin in my helper
<didrocks> could be a snapcraft bug, would be interesting to either report or retrace in the code what triggers it
<didrocks> also, having the plugin name in the deprecation notice would worth a bug :)
<didrocks> to see what it's complaining about
<kalikiana> +1
<Guest72753> Hi guys, I am trying to find out why an electron-based app works in devmode but not in strict, the logs show that a config file can't be written within the snap: /home/osboxes/snap/linkbox/x14/.config/configstore/linkbox-log.json
<Guest72753> any clue on what i am missing here?
<zyga> Guest72753: hey
<mup> Bug #1663220 opened: Add support to Secret Service APIs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1663220>
<zyga> Guest72753: can you pastebin: dmesg | grep DENIED
<Guest72753> sure, just a sec
<tsdgeos> zyga: took me a while but https://bugs.launchpad.net/snapd/+bug/1663221
<mup> Bug #1663221: snap/apparmor default confinement rejects socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT); <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1663221>
<tsdgeos> zyga: anything else you'd like me to add?
<zyga> Guest72753: and dmesg | grep type=1326
<liuxg> ogra_, if it works for pips, that would be fantastic :)
<zyga> tsdgeos: thank you, that should be fine for now
<Guest72753> zyga: http://pastebin.com/nTTuJSRf
<zyga> Guest72753: it seems that the writeful snap wants to run "ip", that is not allowed by the base policy
<zyga> Guest72753: if you disable that do you see any other issues?
<Guest72753> how do I disable that?
<zyga> Guest72753: it's your snap, don't ask me
<Guest72753> electron app are chromium based
<zyga> Guest72753: is electron shelling out to run /bin/ip?
<Guest72753> so I don't really know why it needs ip
<zyga> Guest72753: neither do I; you can use the network-observe plug on your app but it is reserved and your app will be blocked in store review
<zyga> Guest72753: do you see anything in the second grep I asked for?
<Guest72753> no, that one is empty
<ogra_> zyga, why woulld it be locked ? will it not just be not connected by default ?
<zyga> Guest72753: so that's the only problem
<zyga> ogra_: it's marked as reserved
<zyga> ogra_: there's a difference between not connecting and not allowing to have it
<ogra_> ah
<zyga> ogra_: if you just don't connect it people will fall for simple sociological attacks "this is how you install my snap"
<Guest72753> zyga: so if I add the plug to network-observe plug it will work but not accepted in the store?
<ogra_> it will go into manual review
<zyga> Guest72753: it will not go through automatic review, it will be flagged and will go to manual review
<Guest72753> ok
<zyga> Guest72753: I'm not sure, maybe there's a better idea; I don't have experience with electron
<zyga> sergiusens: ^^ any ideas (electron based app uses /bin/ip)
<zyga> sergiusens: is that electron itself?
<Guest72753> I'll try doing that and see if it works at least
<zyga> Guest72753: yeah, go ahead
<zyga> Guest72753: don't forget to connect the plug
<zyga> popey: hey, so apart from https://github.com/snapcore/snapd/pull/2815/files
<mup> PR snapd#2815: release: don't force devmode on LinuxMint "serena" <Created by zyga> <https://github.com/snapcore/snapd/pull/2815>
<zyga> popey: what else should we whitelist there?
<zyga> popey: I saw you mention various distros in the os-release-zoo project but I'm not feeling very well and I wanted to confirm those with you
<Guest72753> zyga: still doesn't work, this is all the output since I started it: http://pastebin.com/4Y3JRVmG
<zyga> Guest72753: hmm, so now it wants to ptrace an unconfined process
<mup> PR snapcraft#1125 closed: tests: fix the env vars passed to the docker container in travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1125>
<zyga> Guest72753: can you tell me if that's stock electron or is this the app itself?
<zyga> Guest72753: ptrace is very powerful and ptracing unconfined processes is a clear no-go
<zyga> Guest72753: also based on this output I don't think you did the plug correctly (maybe it's disconnected) because /bin/ip is still denied
<zyga> Guest72753: or maybe this is a new feature of recent snapd, I'd have to check
<zyga> Guest72753: but can you ensure that "snap interfaces" shows that your snap is using the new plug?
<zyga> (and that it is connected)
<zyga> popey: ideally, can you please open a bug for each distribution that you know should be whitelisted
<Guest72753> zyga: this is the app itself, and you're right the plug is still not there
<Guest72753> i'll try again
<zyga> popey: a distribution should be whitelisted iff: it uses the ubuntu kernel, it uses ubuntu packages (snapd/snapp-confine/...) *without* rebuilding them from source (some decisions are compile time and distro-based)
<zyga> Guest72753: just rebuild the snap and install it again
<zyga> Guest72753: if you are in try mode
<zyga> Guest72753: you need to uninstall/try again
<zyga> AFAIR
<zyga> (we should have --retry or something)
<zyga> Chipaca: ^^ just an idea, have snap try --retry or just smarter try that updates meta/snap.yaml without dropping data)
<zyga> popey: if you file those bugs please poke me with URLs
<Chipaca> zyga, a bare "snap try" should work; doesn't it?
<Chipaca> no uninstall needed
<Chipaca> (granted it's a bit messy)
<zyga> Chipaca: won't it artificially stack more "revisions" (which feels wrong)
<zyga> right
<Chipaca> well, yes it will, but why would it feel wrong?
<zyga> maybe try should use a "xx" revison
<zyga> Chipaca: people get into all kinds of mess with try
<Chipaca> zyga, ?
<zyga> Chipaca: you remove a directory and it's all wonky
<Chipaca> `xx` as in not `x1`?
<ogra_> hmm ? does try actually bump the revision unconditionally ?
<zyga> Chipaca: and the way to fix that is only sensible if you know how snapd works
<Chipaca> ogra_, of course
 * ogra_ wouldnt expect that
<zyga> Chipaca: yes, xx as a special-special revision
<Chipaca> ogra_, just like snap install --dangeroos ./potato.snap
<Guest72753> zyga: this is it right? http://pastebin.com/1eHFpdzT
<ogra_> ah, i thought try just spawns the snap
<Chipaca> ogra_, i'd love to know what spawning a snap means :-D
<zyga> Guest72753: yes
<zyga> "spawn more snaps"
<ogra_> dunno, execute it and stuff in it
<zyga> ogra_: snaps are just zip files ;-)
<ogra_> without actually installing over
<ogra_> lies ! you cant unip them :P
<zyga> (fancy zipfiles)
<ogra_> *unzip
<Chipaca> ogra_, so, a snap is just a filesystem-in-a-file
<Guest72753> zyga: it does show but at the end of snap interfaces: -                         writefull:network-observe
<ogra_> yeah
<Chipaca> ogra_, "snap try" uses the directory directly
<Chipaca> as if it were mounted already (it does a bind mount)
<ogra_> right, so there is no reason to bump the revision every time
<mup> PR snapcraft#924 closed: New plugin: jhbuild <Created by attente> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/924>
<Chipaca> ogra_, there totally is
<ogra_> why is that ? if you end the try the revision is free again, no ?
<Chipaca> yes
<Chipaca> and revert of a try would be fun
<ogra_> so you could just re-use
<zyga> Guest72753: you need to connect that now
<zyga> Guest72753: snap connect writefull:network-observe
<Chipaca> ogra_, yes, we could reuse, but that would involve a bunch of special-casing for something that is trying hard not to be that different from installing the snap
<ogra_> heh, k
<Guest72753> zyga: yeah, that works and the app works again
<Guest72753> zyga: will the user have to do this?
<imexil> Hi, it's been about 6 month since I last was building a snap package. At the time there was an issue that if your snap depended on TeXLive you basically had to include it yourself which makes the snap quite big. Does any one know if there is now a way to make use of an existing TexLive installation?
<ogra_> we have a content sharing interface now so you could roll a texlive snap you can share ...
<ogra_> and there is a way to build classic snaps ... whihc are essantially debs in a new dress
<imexil> could you point to some up to date docs on that sharing interface and how to use it?
<imexil> oh the classic snap would be interesting too.
<ogra_> but that will only work on classic systems (ubuntu-server, ubuntu desktop etc)
<imexil> ah right.
<ogra_> using the content sharing stuff would make it more future proof for running on an all-snap image later
<ogra_> i guess classic is a good quick start way though
<imexil> well upstream has already switched to appimage (because of the texlive issue)
<imexil> I was hoping to make them consider snap again if this TeXLive thing was fixed
<ogra_> to build a classic snap you can just use ""confinement: classic" in your snapcraft.yaml ... and make sure to not use any interfaces at all (they are not available in classic mode)
<imexil> interface == plug?
<mup> PR snapcraft#1115 closed: kernel plugin: fix kernel snap layout <Created by lool> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1115>
<ogra_> well, socket and plug ...
<imexil> any doc you can link to?
<ogra_> or i think we call them "slot" not socket now
<ogra_> on the snpcraft side you only use plug though
<ogra_> https://docs.ubuntu.com/core/en/reference/interfaces/index
<sergiusens> zyga: seems app specific
<imexil> so documentation is still spread around snapcraft.io and docs.ubuntu and dev.*** ? ;-)
 * sergiusens is not paying too much attention to irc these days as it is only open on one box, the one with fixed networking
<ogra_> imexil, snapcraft docs are on snapcraft.io ... general docs are on docs.u.c
<imexil> right.
<imexil> But interfaces are a snap thing right?
<ogra_> https://snapcraft.io/docs/core/interfaces
<imexil> OK thanks!
<ogra_> so you might want tostart with snapcraft.io ... for more detauls you have then docs.u.c
<ogra_> *details
<Mirv> tsdgeos: your patch will land via https://bileto.ubuntu.com/#/ticket/2456
<popey> zyga: https://bugs.launchpad.net/snapd/+bug/1663041
<mup> Bug #1663041: Snap packages install but can't be run on Zorin OS <snapd:New> <https://launchpad.net/bugs/1663041>
<Guest72753> does anyone know if there a way to automate `snap connect x:network-observe ` upon installation?
<ogra_> popey, geez, you hand people your pinky and they want the whole hand ! should be happy they can install them !
<ogra_> </trump sound off>
<popey> zyga: https://bugs.launchpad.net/snapd/+bug/1663226
<mup> Bug #1663226: Snap packages install but can't be run on Peppermint OS <snapd:New> <https://launchpad.net/bugs/1663226>
 * popey builds a wall around ogra_ 
 * ogra_ turns the music up 
<imexil> ogra_: So I tried classic mode. But I have a conflicting ubuntu-core snap which snap won't remove. Any idea
<imexil> http://pastebin.ubuntu.com/23960466/
<ogra_> imexil, hmm, i thought that landed already, a new snapd should move you from "ubuntu-core" to "core" ... perhaps i'm wrong though and that version has not landed yet
<imexil> "snapd is already the newest version (2.21)"
<ogra_> yeah, might be the one in -proposed that has this
<ogra_> iirc 2.23
<imexil> Well it looks like I'm fighting a lost fight here anyway. Upstream has a working cross-distro solution which only takes up 30 MB for the image and no duplicate minimal TeXLive installation required. There is probably no point in putting more energy into snap :-(
<imexil> That's appimage based there.
<ogra_> well, 2.23 should be released this week (or latest next)
<popey> the alternative is to remove snapd and reinstall
<ogra_> alternatively you coudl uninstall snapod and reinstall that ...
<popey> which is what I did to switch from ubuntu-core to core, as I was in a hurry
<ogra_> but that makes you lose all existing snaps
<popey> yeah
<imexil> classic mode would not help since it means distro depending again which is kind of the opposite you want.
<popey> classic mode isn't distro dependent
<popey> you can install classic snaps on debian 9
<ogra_> yeah
<mup> PR snapcraft#1127 opened: Release changelog for 2.27 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1127>
<imexil> well debian derivative dependent then
<imexil> So I see classic mode now the nicer alternative to build something for deb like systems without having to do deb packaging. Which is nice but does not help when distributing cross distro.
<popey> i only mentioned debian 9 because that is the only one I've tested. others may well work but i dont run them here
<ogra_> theoretically it has no distro limits
<ogra_> as long as the libs and binaries are on the host
<jdstrand> zyga, Guest72753: fyi, in the advent of snap declarations, plugging (almost all) manually connected interfaces does not trigger a manual review
<ogra_> jdstrand, thats how i understood it initially ... is that true for "reserved2 too ?
<ogra_> *"reserved"
<jdstrand> zyga: the 'Usage: reserved' stuff needs to get cleaned out. it is all in the base declaration now (I can do that)
<jdstrand> ogra_: you too ^
<ogra_> ah
<imexil> ogra_, popey: yes. Well I might give classic a go when the next upstream version of Ipe comes out. For now the PR is send. Thanks again for the help.
<jdstrand> Guest72753: as for electron using ip-- I have tested electron apps and none of them used ip. I'm not sure why yours is...
<ogra_> np
<jdstrand> ogra_: there is no 'reserved' any more. it is all base declaration. there are only a handful of plugs that trigger a manual review because they are deemed 'super-privileged'. eg, docker-support, snapd-control. network-observe is not one of them
<ogra_> ah !
<ogra_> thanks !
<jdstrand> np
<Guest72753> jdstrand, I think because we're trying to detect proxy though one of electron's packages
<jdstrand> Guest72753: that would make sense. and with that, you should plug an appropriate interface that grants that
<jdstrand> zyga: hey, so, on its own, https://github.com/snapcore/snapd/pull/2821 doesn't seem to fix anything because the seccomp profiles are always regenerated and that means they will be regenerated by the new snapd, which means the new policy that snap-confine may not understand. You mentioned a followup PR for compatible seccomp profiles. can you talk to me about that?
<mup> PR snapd#2821: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2821>
<Guest72753> jdstrand: I plugged network-observer as suggested by zyga, and that works, but I was wondering if the user will have to do this manually, or if there's an automated way to do this
<ogra_> the user has to do it
<jdstrand> Guest72753: the user will have to do it manually because network-observe grants privileged access to network information
<ogra_> unless you use your snmap inside an all snap image (i.e. an IoT install or such)
<jdstrand> Guest72753: a gadget snap could also do it
<ogra_> there you coudl define the pre-plugged interfaces in the gadget snap of the image
<jdstrand> Guest72753: you might want to read https://github.com/snapcore/snapd/wiki/Interfaces
<Guest72753> jdstrand: thanks I did a few hours ago
<Guest72753> trying to figure out how everything works
<tsdgeos> Mirv: should "Use eg example 1 from en blog 2016 11 16 snapping-qt-apps but with plugs: network" be "Use eg example 1 from en blog 2016 11 16 snapping-qt-apps but *without* plugs: network"
<jdstrand> Guest72753: ah, there is a blog you might want to read. /me finds it
<jdstrand> Guest72753: https://blog.labix.org/2016/04/22/snappy-interfaces
<Mirv> tsdgeos: thank you
<Mirv> tsdgeos: yes
<zyga> jdstrand: o/
<zyga> jdstrand: noted, thank you
<zyga> jdstrand: question, how would you feel if a snippet of the base declaration was in each interface?
<zyga> jdstrand: right now it's a bit spread out
<mup> Bug #1663175 changed: chroot not allowed in devmode/strict <Snappy:Invalid> <https://launchpad.net/bugs/1663175>
<jdstrand> zyga: I like the way it is because you can see all of them in one place. it is 'the base declaration' that anyone can see and the tests are in one spot. I don't personally view it as a security backend. I also think we have much bigger fish to fry
<zyga> not a backend, a dedicated thing
<zyga> jdstrand: right now it is another thing that everyone has to patch in a secondary file, I wanted to streamline that to just the interface file
<jdstrand> zyga: I know what you want :) you asked my opinion :)
<zyga> jdstrand: ack, thanks
<zyga> jdstrand: I really want to write a few tools like "snap internal policy-dump" or something like that (also for other built-in things)
<mardy> pstolowski: hi! I updated my snapd with your latest changes to the iface hook branch, but now I'm getting this wehn I try to connect: http://paste.ubuntu.com/23960586/
<mardy> pstolowski: did I do something wrong when rebuilding snapd?
<jdstrand> zyga: we do need that, but the base declaration feels different to me. it is something that snapd applies to interfaces
<jdstrand> zyga: as opposed to something interfaces provide
<zyga> jdstrand: kind of but you see why it is connected
<pstolowski> mardy, no, there is a problem (I think it manifests itself if you used edge before) unrelated to my branch which is being adressed today. zyga can you take a look at that pastebin and confirm?
<jdstrand> zyga: but, can we discuss https://github.com/snapcore/snapd/pull/2821 and the followup branch. I have a lot of concerns
<mup> PR snapd#2821: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2821>
<jdstrand> zyga: first off-- you added quatactl-- that is bad. it was never there and is now granting far more than observe to mount-observe
<zyga> pstolowski, mardy: known issue: https://bugs.launchpad.net/snapd/+bug/1662489
<mup> Bug #1662489: snap-confine failed with: hsearch_r failed: No such process <snapd:In Progress by zyga> <https://launchpad.net/bugs/1662489>
<zyga> jdstrand: ah, thanks I can correct that quickly
<zyga> jdstrand: thank you for looking at the current fire, I was about to ask for your review
<jdstrand> zyga: but I'm quite concerned about the approach and where things are going
<zyga> jdstrand: yes, let's discuss this now
<zyga> jdstrand: do you know the context? right now snapd broke everywhere on edge
<jdstrand> yes
<zyga> ok
<jdstrand> I discussed this at length with mvo and in fact triaged the issue to snap-confine vs policy diversion
<jdstrand> so I'm up on it :)
<zyga> jdstrand: not sure I follow
<jdstrand> nm
<jdstrand> I know the issue
<zyga> jdstrand: the issue is that snapd runs snap-confine from the system, right?
<zyga> jdstrand: and that's the old snap-confine
<jdstrand> yes
<jdstrand> yes
<zyga> ok, just checking
 * jdstrand understands the issue
<jdstrand> :)
<jdstrand> so this is only an issue on classic
<jdstrand> because on all-snaps, everything is in the os snap. you get the old stuff, or you get the new stuff
<zyga> jdstrand: it is also an issue on core if you revert
<zyga> (rollback)
<ogra_> yeah
<ogra_> writable is unversioned ...
<jdstrand> (though on all-snaps, I think there is an issue of the policy not being updated on core refresh after reboot, but that is a separate thing)
<pstolowski> mardy, i think the bug 1662817 which is a duplicate has a workaround
<ogra_> not a new prob ...
<mup> Bug #1662817: some snaps stop working after revert the core snap <Snappy:New> <https://launchpad.net/bugs/1662817>
<zyga> jdstrand: it's not that separate, see what I wrote on the internal channel
<zyga> jdstrand: it's a required part of the fix in my eyes
<jdstrand> zyga: so on core, to fix revert *and* updating policy on refresh, we need a way to say 'trigger policy regeneration for these affected snaps'
<ogra_> or have writable live in SNAP_DATA of the core snap ;)
<zyga> jdstrand: we cannot do that cause the core you revert to doesn't know it should generate profiles and the current core cannot generate old security profiles
<jdstrand> zyga: yes, I was typing the same thing as you were :)
<zyga> jdstrand: I think it is fine if stuff is broken for a short while (e.g. rollback now breaks) but we need to plan the general fix
<jdstrand> zyga: you can if it is designed
<ogra_> (that would just make updates really slow since you need to copy all of writable on upgrade)
<zyga> jdstrand: right, I agree; I just mean that nothing we can do now makes old cores capable of doing this
<zyga> (this is what I meant by a short while)
<jdstrand> of course
<zyga> jdstrand: ok, we're in agreement
<jdstrand> zyga: but I suggest we talk about fixing core, and then see how fixing classic falls out of that
<zyga> jdstrand: I think the right fix is to refresh profiles as I described in the card *and* run snap-confine from core
<zyga> jdstrand: that's the generic solution that will always work when it lands
<zyga> jdstrand: what I proposed now was a short-term way to unbreak edge
<jdstrand> let me read the card
<mvo> zyga: how will that fix the revert problem?
 * mvo should also read the card
<zyga> jdstrand: let's chat over a HO
<zyga> https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1
<jdstrand> zyga: your approach is too heavy
<jdstrand> especially when you add apparmor into the mix
<jdstrand> cause every refresh/revert will unconditionally regenerate/recompile everything
<jdstrand> this is not theoretical. we have to be very careful with apparmor policy regeneration on arm with lots profiles (eg, on Personal)
<zyga> jdstrand: not really
<zyga> jdstrand: we only do that if it is different
<ogra_> yeah, we have been bitten badly by that before
<jdstrand> zyga: 'it' is the build id which is different for every refresh, no?
<zyga> jdstrand: sorry, I'm in a hangout with mvo here; it would be easier to discuss this together
<zyga> jdstrand: having two parallel conversations is too much for my head today
<mardy> pstolowski: thanks! Do you know what are the concrete steps for restoring the seccomp profiles?
<zyga> jdstrand: we lost you
<pstolowski> mardy, nope, sorry. they live in /var/lib/snapd/seccomp/profiles but i'm not sure if they will be re-generated if removed manually. zyga will know
<zyga> pstolowski: they will not, I will make that happen today though
<zyga> jdstrand: can you re-review and hopefully adjust the outcome on https://github.com/snapcore/snapd/pull/2821
<mup> PR snapd#2821: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2821>
<zyga> jdstrand: I removed quotactl entirely
<didrocks> sergiusens: hey! Do you have any idea on how I can avoid this workaround: https://github.com/ubuntu/booth-demo-manager/blob/master/snap/plugins/bower.py#L38 ? (with side-effects :/)
<jdstrand> mvo: ok, fyi only, merged master for seccomp-mknod and pushed. My previous merge with master was 23 hours ago. fingers continue to be crossed :)
<elopio> wililupy: ping, are you around to help me confirm that the change lool introduced fixes your problem? https://bugs.launchpad.net/snapcraft/+bug/1658177
<mup> Bug #1658177: snapcraft kernel plugin puts module and firmware under 15.04-era lib/ directory <Snapcraft:Fix Committed by lool> <https://launchpad.net/bugs/1658177>
<lool> elopio: hi
<lool> sergiusens, elopio: I have yet to test whether resulting kernels work as expected; I can say I fixed the layout of the resulting snaps though
<ogra_> lool, i think ppisati tried the fix
<ogra_> (but had other issues)
<elopio> lool: /buffer #ubuntu-mir
<elopio> sorry, wrong command :p
 * ogra_ flushes #ubuntu-mir from lool again
<lool> ogra_: thanks
<ogra_> :)
<elopio> ogra_: why is it that the official kernel snaps are not built using the snapcraft kernel plugin? Is there something you are missing from our side?
<ogra_> elopio, yes, and archive signing key :P
<ogra_> *an
<lool> ppisati: just saw your debug on initrd boot with new kernel snap, did you find the issue?
<ogra_> elopio, we need the signed deb kernels for secureboot to work ...
<lool> elopio: the main difference is that they are built from the original debs
<ogra_> elopio, so we cant build them from source
<lool> instead of from source
<lool> albeit I thought we had a plugin for that too
<ogra_> we have a snapcraft.yaml ansd Makefile the kernel team maintains
<ogra_> fvor the official kernels
<elopio> I see. It would be nice to have a test that builds the official kernel from source, just to check our plugin. And that doesn't need signature.
<ogra_> you can surely do that as long as you dont upload them to the store under the same name
<elopio> of course :D I'll make sure this just builds, the runner won't even have credentials.
<ogra_> note though that we also pull in extra binaries ... like the raspberry-pi wlan firmware package on the pi kernels and linux-firmware on the generic ones
<elopio> ogra_: do you know where is the source for the debs?
<mup> PR snapd#2820 closed: interfaces/builtin: add send/recv syscalls for upower-observe interface as required on ARM <Created by morphis> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2820>
<ogra_> the source for the debs or for the snap builds from debs ?
<ogra_> the git trees are on kernel.ubuntu.com if you mean that
<ogra_> ask the kernel team for the right branch etc though ... i never get that right :PÃ
<elopio> yes, I meant that. Thanks ogra_, I'll ask.
<elopio> ppisati: ping. Can you please tell us about the kernel issues you are still having? We are trying to make a release soon, and it would be great to have all of that fixed.
<sergiusens> ogra_: to be fair you can do the same trick that's done with the deb but with the snap instead
<ogra_> ?
<mup> PR snapd#2813 closed: tests: filter ubuntu-core systems for authenticated find-private test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2813>
<ogra_> trick ?
<ppisati> elopio: loic: with loic's patch applied to snapcraft, i can build a correct kernel snap
<sergiusens> ogra_: the signing
<ogra_> sergiusens, there is no trick
<ppisati> elopio: loic: now i'm fixing the config of the 96boards's snapcraft snapcraft demos, sicne it was missing some required options
<ogra_> sergiusens, the ubuntu-archive key which only gets used during archive builds needs to be used
<sergiusens> ogra_: I was told the deb was built, intercepted or pulled out of the archive, signed and resubmitted
<ppisati> e.g. mmc_sdhci <- no mmc on boot
<ogra_> sergiusens, nope
<sergiusens> ogra_: that's the summary steve gave me
<ppisati> and apparently it's missing something else, but i think it's the ext4=m being the problem here
<ppisati> elopio: lool: i'll send a patch to snapcraft once i'm done
<ogra_> sergiusens, i think you think about the way it is done if you need a *different* kernel
<sergiusens> ogra_: it can still be signed with snapcraft by using an `install` scriptlet
<ogra_> sergiusens, how ?
<lool> ppisati: ok, so board specific issues - cool
<lool> ppisati: thanks for the update
<ogra_> sergiusens, you need *all* the binaries signed with a key you dont have access to
<ogra_> only the archive builders can use this key
<ppisati> elopio: BTW, we have snapcraft.yaml in our kernel tree (at least for xenial)
<ogra_> so you need a deb built in the archive in any case ... sure you can loop that through with snapcraft somehow ... but why
<ppisati> elopio: if you clone the xenial tree, git checkout the raspi2 or snapdragon branch
<ppisati> elopio: you can rebuild a kernel snap from there
<ogra_> ppisati, oh, yeah, if you use ext4=m you need to include ext4 in the initrd with a snapcraft option
<zyga> re
<ogra_> ppisati, can you file a bug, iirc your initrd was just hanging, we can add a check for /proc/filesystems and error out
<ogra_> that would have made this clearer and saved debugging
<lool> didrocks: sorry, might have asked this recently already, but where's the most recent electron snap template I can hand someone?
<lool> morphis_: hey, would you have a gadget.yaml example showing interface connections from gadget?
<lool> (ideally of privileged interfaces)
<didrocks> lool: I don't think we have any. I didn't tackle one myself and was told that all electron apps are different
<didrocks> lool: I guess the telegram one from sergiusens could be handy
<lool> didrocks: oh wow really
<didrocks> sergiusens: did you see my question btw about the bower.py workaround? :)
<lool> didrocks: hmm I dont see electron anywhere in the telegram snap, isn't it qt?
<lool> (https://github.com/sergiusens/telegram-snap/blob/master/snapcraft.yaml)
<didrocks> it's Qt, but I really thought it was electron-based
<didrocks> my bad then
<seb128> Trevinho and flexiondotorg worked on electron examples I think
<seb128> Trevinho, flexiondotorg, ^
<Trevinho> lool: it's all qt...
<Trevinho> lool: check this for an upstreamable version which... I already have
<Trevinho> lool: https://github.com/3v1n0/telegram-snap/
<lool> this is to allow someone to create a webapp snap
<lool> basically they have the URL/HTML and they need to ship a runtime around it
<zyga> jdstrand: I've updated the PR as instructed
<ogra_> lool, why not https://github.com/fcole90/fcole-hexgl-webapp
<ogra_> (uses ubuntu-app-platform though)
<mup> PR snapd#2815 closed: release: don't force devmode on LinuxMint "serena" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2815>
<morphis_> lool: what do you mean by that, a gadget with applications using plugs/slots or a gadget causing plugs/slot of certain snaps automatically connected?
<lool> morphis_: a gadget preinstalling snaps and connecting them to the right plugs/slots
<morphis_> lool: you can't do both from a gadget
<morphis_> preinstalling snaps is a thing ubuntu-image/snap prepare-image does by setting up the seed.yaml in your image
<lool> (in old snappys we used to be able to force certain snaps to remain installed, might be where my confusion comes from)
<lool> morphis_: so I can preinstall snaps in my ubuntu-image call, and I can pre-connect them in the gadget yaml?
<morphis_> that is what you do via an validation assertion
<morphis_> no, no pre-connecitng in gadget.yaml
<morphis_> that is handled via snap-declaration
<lool> so it has to be per snap
<morphis_> yes
<lool> but it could potentially be in the image only and not the store
<morphis_> sure
<morphis_> the image is build with a set of assertions and a set of .snap files
<lool> I guess we can add authorities to the image
<lool> and sign the snap-declaration by whoever
<morphis_> lool: not sure about this, right now the assertions are signed by canonical
<lool> https://github.com/3v1n0/electron-quick-start-snap/blob/master/snapcraft.yaml looks like a good electrn snap template
<morphis_> pedronis can comment on that maybe who is able to sign them
<lool> morphis_: ok
<lool> I think if it's per snap it can probably come from the store anyway
<lool> even if it's preloaded
<Trevinho> lool: I've probably to update it though
<Trevinho> I've not touched it for some time
<morphis_> but as they express some kind of critical policy I guess its only the device maker or the store instance (canonical)
<Trevinho> as per https://github.com/3v1n0/electron-quick-start-snap/issues/1 ...
<Trevinho> probably the launcher should be better to be desktop-gtk2 though,
<ppisati> ogra_: it was more than a single issue
<ogra_> ppisati, well, but missing ext4 is definitely one we can catch
<ogra_> and print a pretty message for you so you dont need to dig
<ppisati> ogra_: the hang was due to missing mmc, it couldn't find it so it was hanging in "wait-for-root" - there are 3 calls, one in fixrtc, another in resize and the third was in the main ubuntu-core fs logic
<ppisati> then there was ext4
<ppisati> and now i'm having a
<ogra_> but wait-for-root has a timeout
<ogra_> it should have returned after 120sec
<Trevinho> lool: actually 've just thested that exampla and still works, so... yeah, you can start from that if needed
<ogra_> or 180 or so
<ppisati> "can't mount loop device: no space left on device" and i think it's the devloop min count too low ( = 8 atm)
<lool> Trevinho: yeah, I actually think I handed it to some folks who told me it was working, wasn't sure it was this exact one
<ogra_> wow, never seen that one
<ppisati> ogra_: yes, but there are 3 in a row, so if you don't wait long enough, you never land in busybox
<Trevinho> lool: that is the one I did long time ago, I've updated it some time ago to use desktop launchers, but it should work
<ogra_> yeah
<ppisati> ogra_: i'm piling up config changes for the snapcraft kernel pluigin example
<ogra_> i guess 180sec are also quite long ...
<ogra_> even a spinning disk should be ready in less than 1min
<ppisati> i put some prints inside initrd scripts to see where it was hanging
<Blu2_> Out of curiosity, are (graphics) drivers snappable?
<ogra_> Blu2_, tricky since they usually have a kernel side component ...
<lool> jdstrand: do we have an official position on a realtime interface for pthread_setschedparam()?
<lool> outside of "just do it and that's privileged and needs a snap-declaration"
<ogra_> Blu2_, but i.e. in case of a whole image it is easily possible ... i.e. the RPi images we have ship the vc4 driver in the kernel snap and snaps that include gallium can use DRM/KMS and GLES
<ogra_> so it depends a bit on the context the snap is used in
<Blu2_> hm.. would be awesome to use for example Open drivers for the desktop and proprietary for specific apps
<ogra_> if that would be possible from a driver POV ... then you could already do it with debs :)
<ogra_> if certain HW is driven by an open driver you wont be able to use the prop. one at the same time with it ...
<ogra_> thats not snap specific though
<Blu2_> Having multiple drivers installed and only grant one access to a snap or something
<ogra_> just a limitation of HW and drivers
<flexiondotorg> seb128 Yes, I'm working on electron stuff. They are a bit variable in terms of what is required.
<Blu2_> I don't know, I'm not too knowledgable about this topic
<flexiondotorg> electron is still using GTK2+ despite lots of requests to move to GTK3+
<ogra_> Blbut if the HW is already being used by one of them, how do you make the snap use the other ?
<lool> Blu2_: what you can do is have two kernels snaps and chose one or the other
<ogra_> yeah, but not dynamically
<lool> or a kernel snap with a config/cli to swap, likely with reboot
<ogra_> that isnt how garphics hardware works
<ogra_> *graphics too
<nacc> right the hw (lowest layer) seems like it wouldn't support non-exclusive usage
<nacc> at least that i know of
<ogra_> yep
<ogra_> i guess you could make it work in SW if you had access to the source of the proprietary driver ... you could split out the common parts and make the higher level switchable ...
<ogra_> but then you have two open drivers in the end :)
<ogra_> (or two closed ones and a vendior that sues you :P )
<ogra_> (because you broke your NDA)
<Blu2_> Hopefully Valve and the community push open drivers further
<Blu2_> btw, no steam snap yet :P
<ogra_> go ahead !
 * ogra_ would use it 
<elopio> joc: ping. The plainbox provider snap fails to build now. https://travis-ci.org/elopio/snapcraft-de-noche/jobs/200009799
<elopio> do you know about that?
<Blu2_> Maybe I'll give a try on the upcoming weekends
<mup> PR snapd#2823 opened: interface/seccomp: sort combined snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/2823>
<joc> elopio: hi, sorry i've been away for a week, i saw i had a few more comments so i'll check it all
<jdstrand> lool: pthread_setschedparam isn't a syscall so I'm going to assume that it is using varous sched_* syscalls. 2.23 will allow snaps to modify the scheduler for the calling process. process-control added several syscalls for adjust the scheduler for anything. so, it is available in process-control when you need more than what is in the template
<lool> jdstrand: yes, it's sched_set_params syscall I think
<jdstrand> lool: yes, that was one that was added to template and process-control
<jdstrand> (template for limited use, process-control for anything)
<elopio> ogra_: this one is for you: https://travis-ci.org/elopio/snapcraft-de-noche/jobs/200009811 We will make sure that snapcraft master builds your kernels every night.
<lool> jdstrand: I dont understand the "added as a template" part
<lool> I see it in interfaces/seccomp/template.go
<lool> and in interfaces/builtin/process_control.go
<jdstrand> lool: you can use sched_setparam(0, ...) in default template, sched_setparam(anything, ...) in process-control
<lool> oh ok
<lool> I need to find what value RR is
<elopio> joc: hey, but this is not related to your branch :) It's the one in git.launchpad.net/~checkbox-dev/plainbox-provider-snappy
<jdstrand> lool: again, this is 2.23
<lool> ack
<ryebot> Is there any interface that will give a snap access to /proc/self/cgroup?
<ogra_> elopio, sexy !
<mup> PR snapcraft#1128 opened:  tests: support bzr branches for external tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1128>
<joc> elopio: aah got you, didn't read that closely enough :)
<joc> elopio: we don't maintain the packaging repo you are using anymore I'm afraid, we now have a dedicated project here: https://code.launchpad.net/checkbox-snappy
<elopio> joc: oh, good. I'll update the script. I think I will just build your master branch nightly, unless you think it would be good to build the others too.
<elopio> ppisati: sorry, I was in a meeting and missed your pings. I'm scrolling back and reading...
<joc> elopio: well we are building master/edge and beta on every landing, and now have release flow for candiate and stable, so up to you
<ppisati> lool: there's a bug in the "moving modules and firmare around" fix
<ppisati> lool: http://paste.ubuntu.com/23961221/ - there are two fw directories now
<ppisati> elopio: our xenial kernel tree contains a snapcraft.yaml, checkout raspi2 or snapdragon and it should be there
<ppisati> elopio: so you can rebuild a kernel.snap from there, althougjh it will be slightly different from what we have in the store
<ppisati> elopio: but it might be a good test for the kernel pluging
<elopio> ppisati: I see it \o/ http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/snapcraft.yaml Just what I was missing.
<ogra_> ppisati, are you sure thats not from inside the dragonboard fw tarball ?
<elopio> ppisati: the default branch is for the pc image?
<ogra_> iirc you unpack a tarball at snap build tiome in this case
<ppisati> elopio: yep
<ppisati> ogra_: yep, that come sfrom the firmware tarball, but if we move the /lib/firmware, we should move everything
<ppisati> ogra_: else wifi won't work
<ogra_> yes, but thats nothing the plugin can handle ... should it ?
<ogra_> it will just untar
<ppisati> ogra_: yep, what i mean
<ppisati> ogra_: before we moved /lib/fw to /fw everything was in one place
<ppisati> ogra_: ah
<ppisati> ...
<ppisati> destination: lib/firmware
<ppisati> i didn't see that
<ppisati> f*ck me
<ogra_> :)
<ppisati> ok
<elopio> :D
<ppisati> https://github.com/snapcore/snapcraft/pull/1129
<mup> PR snapcraft#1129: 96boards: fix the dragonboard example <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1129>
<ppisati> this fixes the dragonboard example
<ppisati> mines the fw destination that i just noticed
<ppisati> *minus
<mup> PR snapcraft#1129 opened: 96boards: fix the dragonboard example <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1129>
<elopio> ogra_: before I forget to remind you, tomorrow 16UTC, bring your nice clothes.
<ogra_> yeah, i'll iron them !
<elopio> you are going the extra mile! so nice of you.
<mup> Bug #1663303 opened: Running snapcraft on Ubuntu 14.04  fails with a traceback <isv> <Snappy:New> <https://launchpad.net/bugs/1663303>
<Cynerva> we're trying to snap kubelet and hitting a lot of permissions problems, anyone available to look at these? https://gist.github.com/Cynerva/9150f379cdf1d41aac9ae233597c1f64
<Cynerva> lotta cgroup stuff, and a couple others
<Cynerva> i'm not seeing any obvious interfaces we can pull in
<Cynerva> any assistance would be appreciated :)
<sborovkov> Hello, did anyone had an experience building a snap that's uysing python and girepository? I added python3-gi to stage-packages. But application using it fails at runtime
<kyrofa> Cynerva, are you familiar with the snappy-debug tool?
<elopio> sborovkov: what's your error?
<sborovkov> elopio: ImportError: cannot import name GLib, introspection typelib not found
<sborovkov> elopio: and this ImportError: cannot import name Gio, introspection typelib not found
<sborovkov> elopio: not sure what it's missing, I see that it has $SNAP/usr/lib/python3/dist-packages/gi
<zyga> Cynerva: today is a bad day for me but come back tomorrow, I'll help you out
<Cynerva> kyrofa: i haven't tried snappy-debug, but i see it in the docs now - thanks!
<Cynerva> zyga: will do, thanks
<zyga> mwhudson: hey, around? I have a question
<kyrofa> Cynerva, no problem, that will hopefully give you more helpful errors
<mup> PR snapd#2821 closed: overlord/ifacestate: setup seccomp security on startup <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2821>
<mup> PR snapd#2823 closed: interface/seccomp: sort combined snippets <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2823>
<King_InuYasha> sergiusens: around?
<elopio> sborovkov: can't you install glib from the deb?
<sborovkov> elopio: error is that introspection typelib is not found though? And I added python3-gi to stage-packages and it's installed.  I also added libglib2.0 to stage packages as well...
<kalikiana> Hrm, I wish Unity didn't remove snaps whenever they're updated. No idea, though, if that's an issue with Unity or what snapd might be doing with the files.
<kalikiana> s/snaps/launchers of snaps/
<kyrofa> kalikiana, I expect snapd is removing them when disabling, and generating new ones when activating
<kyrofa> kalikiana, if you run `sudo snap disable <snap name>` do they also disappear?
<kalikiana> kyrofa: Yep
<elopio> sborovkov: I mentioned the debs because I remember something similar when I mixed debs and pip packages. But if you are using only debs, then scratch that.
<kyrofa> kalikiana, please report that
<kalikiana> Will do
<elopio> sborovkov: so, I don't know. Feel free to share the snapcraft.yaml with us. If you think this is something that snapcraft is doing wrong, please file a bug in bugs.launchpad.net/snapcraft
<kyrofa> It might make sense to remove them on disable, but not upgrade
<sergiusens> King_InuYasha: yes
<sborovkov> elopio: I actually found similar question https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg01513.html
<King_InuYasha> sergiusens: did you have a chance to take a crack at refactoring the stage/build-packages backend over the weekend (you briefly mentioned to me last week you were going to take a stab at it)
<sborovkov> elopio: going to try and see if that helps.
<kyrofa> jdstrand, how would you feel about making ping available in the default profile?
<sergiusens> King_InuYasha: I am going to get it signed off for next week as an official sprint task (yeah we are doing agile now :-/)
<sergiusens> King_InuYasha: I tried to spike it this week but ran out of time
<King_InuYasha> oh dear :(
<sergiusens> it is light weight, but still don't like it
 * King_InuYasha is not much of a fan of agile/scrum/sprint things
<kalikiana> kyrofa: Seems there's bug 1646912 for it already
<mup> Bug #1646912: Snaps disapper from the launcher after an update <Snappy:New> <https://launchpad.net/bugs/1646912>
<sergiusens> me neither
<King_InuYasha> I'm one of those "informally agile" people
<King_InuYasha> the moment you're putting fixed process cycles, it's not really "agile" in my opinion
<mup> Bug #1646912 changed: Snaps disapper from the launcher after an update <snapd:New> <https://launchpad.net/bugs/1646912>
<kalikiana> ogra_: FYI seems there's a snapcraft snap in the store now (oddly enough not the one I wrote) and bug 1663303 is kind of answering my question
<mup> Bug #1663303: Running snapcraft on Ubuntu 14.04  fails with a traceback <isv> <Snappy:New> <https://launchpad.net/bugs/1663303>
<kalikiana> Although I don't know how "sudo apt install snapcraft --classic --edge" is supposed to work
<elopio> sborovkov: interesting.
<ogra_> kalikiana, ah !
<ogra_> ssweeny, bah ... i did miss that your second case option misses the ;;
 * ogra_ does a quick fix 
<ssweeny> ogra_: I've seen the ;; left out after an exit before
<ssweeny> I thought it was valid
<kalikiana> fwiw even an actual "snap install --classic --edge" installs fine but doesn't run on Xenial either
<ogra_> ssweeny, nope, isnt
<ogra_> but at aleast all bits are there now
<ssweeny> ogra_: ah, my apologies then
<ogra_> well, i reviewed it :P no need to apologize
<kyrofa> Huh... I have a bug report some someone who seems to be unable to resolve domain names from within the snap. Has anyone run into that?
<ogra_> nope
<zyga> kyrofa: yes
<zyga> kyrofa: on 14.04
<ogra_> ah
<zyga> kyrofa: is that a classic confinement snap?
<kyrofa> zyga, no, strict, and on 16.10
<kyrofa> Maybe it has something to do with 16.10, I'll fire up a VM
<mup> PR snapd#2824 opened: overlord: make seeding work also on classic, optionally <Created by pedronis> <https://github.com/snapcore/snapd/pull/2824>
<zyga> kyrofa: then no
<zyga> kyrofa: strace would be useful
<kyrofa> zyga, unfortunately that requires bundling that in the snap, which I have not :P
<kyrofa> zyga, can't even ping. Figuring out the issue in the first place was awful
<kyrofa> Still not completely sure that's the issue
<zyga> kyrofa: building what?
<zyga> kyrofa: just nsenter and strace ;)
<kyrofa> zyga, wait...
<kyrofa> Really?
<zyga> kyrofa: strace is at /var/lib/snapd/hostfs/usr/bin/strace
<ogra_> alll this new fangled stuff
<ogra_> nsenter ... tsk
<kyrofa> ogra_, I didn't know about nsenter either :P
<ogra_> yeah
<ogra_> zyga keeps all the secrets !
<zyga> ogra_: job security
<zyga> I just have to stop spilling them on irc :)
<kyrofa> snapd hides the magic, which is cool. I just wish we _also_ hid the magical debug tools
<kyrofa> Hahaha
<zyga> ogra_, kyrofa: nsenter -m/run/snapd/ns/$SNAP_NAME.mnt
<zyga> just don't add space between -m and the path
<zyga> annoging thing
<zyga> that runs without confinement
<ogra_> stop spilling !
<zyga> if you want confinement just snap run --shell
<zyga> and then fire away
<zyga> you will need to copy strace somewhere first
<zyga> but it will work
<ogra_> now all the hackers know our backdoors !
<zyga> same with gdb
<zyga> ogra_: nah, WE HAVE FIREWALL ;)
<ogra_> great FIREWALL ?
<zyga> don't you watch TV
<zyga> it stops _everything_
<zyga> based on the evil bit
<ogra_> lol
<kyrofa> zyga, I wish technology had more boring names for things. Then tv shows would actually have to make up the NAMES for the technology they fabricate as well
<kyrofa> zyga, I want to hear one script that mentions iptables
 * ogra_ is slightly scrated by TV recently ... there is that reality TV clown in the news all the time ... i stream though :)
<zyga> kyrofa: isn't that old-school, iptables got replaced by that ... thing
<jdstrand> kyrofa: that is a long standing discussion point. it mostly had to do with the fact that it is setuid, therefore we had to allow certain things in the profile that weren't appropriate for the default profile. then there was setuid-less ping made possible by upstream kernel, but it needs distro support (tyhicks would have to comment). I was going to see if a combination of apparmor child profile and seccomp arg filtering might make it possible. that 
<ogra_> *scared
<kyrofa> zyga, you must be talking about ip6tables
<kyrofa> zyga, in all seriousness, are you talking about ufw? It's just a pretty wrapper
<jdstrand> actually, I think mr robot may have mentioned iptables
<kyrofa> jdstrand, no way!
<jdstrand> it may have just been on the screen, I can't remember
<jdstrand> what would be cool is if mr robot used ufw :)
<kyrofa> jdstrand, and yeah, ping makes sense. I would also be happy with getent
<kyrofa> I love ufw
<tyhicks> the setuid-less ping support has been in the kernel for a long time and support for the kernel feature was recently merged in upstream iputils
<jdstrand> is getent missing? I think we could at least give it with network
<kyrofa> jdstrand, seems to be
<jdstrand> or maybe it too as a child profile, but I don't want too many child profiles. I could to sibling profiles...
<tyhicks> there's a little bit of distro work needed to enable it but the more important piece of work to do is to understand what old features of setuid ping would regress
<jdstrand> anyway, I'll think about it
<tyhicks> setuid-less ping doesn't support everything
<zyga> kyrofa: no, there's something more recent in the kernel
<jdstrand> tyhicks: sorta thinking snapd could ship profile snap.ping {} # cool profile name!
<zyga> kyrofa: something more generic
<mwhudson> zyga: hello
<zyga> mwhudson: hey!
<jdstrand> tyhicks: then network could Px -> snap.ping
<zyga> mwhudson: I think my question has resolved itself, just bad reading on my part, I incorrectly assumed Elf64_Word is a uint64_t,
<jdstrand> tyhicks: and maybe, ust maybe I can do enough with seccomp arg filtering to make it work
<mwhudson> zyga: ah haha
<jdstrand> s/ust/just/
<zyga> mwhudson: silly elf defined that as uint32_t *because THAT's why*
<tyhicks> jdstrand: do you think spending them time to do that work would be better than enabling setuid-less ping in the distro?
<tyhicks> s/them time/the time/
<jdstrand> anyway, it is something I plan to play with whenlooking at policy for setuid with @euid and @ruid
<jdstrand> tyhicks: well, the problem is that while it would be fantastic to have setuid ping in Ubuntu, other distros won't have it
<jdstrand> tyhicks: but, it would be in our core. I guess we'd just need a new enough kernel. that isn't something new for snappy...
<tyhicks> jdstrand: agreed but no other distros are using confinement
<tyhicks> oh yeah, it would be in our core snap
<jdstrand> tyhicks: today. I suspect by series 18 that will change (pending upstreaming work). Debian and suse should be able to just get it
<zyga> jdstrand: it would be nice to have ping without the +s bit
<tyhicks> true
<jdstrand> zyga: it would
<zyga> jdstrand: maybe just with the capability for the raw socket or maybe the special ping-something-socket (forgot)
<jdstrand> we could supply an alternate ping too, but people would have to know to use it
<tyhicks> jdstrand: on other distros that haven't enabled unpriv ping themselves, snapd would have to write to the special sysctl that sets up the guid's that are allowed to use the unpriv ping
<jdstrand> on core we could update-alternatives it
<jdstrand> anyway, lots of options
<tyhicks> yeah
<jdstrand> tyhicks: ah yes, I forgot that. that is semi-difficult, though possible with snap-confine understanding thing like @ruid and @euid
<jdstrand> things*
 * tyhicks nods
<zyga> jdstrand: hmm, yeah
<tyhicks> zyga: fyi, it is just a special socket(2) domain although I can't remember the name of it right now
<zyga> tyhicks: right, I recall something similar
<zyga> just-for-ping
<jdstrand> kyrofa: I'm sure you know this, but ping is in network-observe if you are blocked
<kyrofa> jdstrand, oh no, not blocked, I'm sorry if I gave the impression
<jdstrand> you didn't, I just wanted to make sure you weren't
<kyrofa> jdstrand, I was trying to figure out what was wrong with someone else's system running my snap, and I realized I had no network debugging facilities!
<kyrofa> jdstrand, it seems like their DNS isn't working from within the snap, so I'm investigating that on my own now, hopefully I can duplicate
<sborovkov> elopio: yeah that export helped. Also had to export PYTHONPATH for some reason with path to the dir it install girepository to (for some reason it's in a separate directory from all other python packages but whatever).
<sborovkov> Hi, what's the policy for naming dbus interfaces on core and on classic? I am getting this on core g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.36" is not allowed to own the service "org.screenly.playlist" due to security policies in the configuration file
<jdstrand> sborovkov: use the "dbus" interface. see https://github.com/snapcore/snapd/wiki/Interfaces#dbus
<jdstrand> sborovkov: you'll want to:
<jdstrand> slots:
<jdstrand>   dbus:
<sborovkov> jdstrand: yeah, but I am in devmode. Seems like I am being prevented from registering this on the system bus by some policy. So I was wondering what's the policy. And what's the policy on the core as we are just in process of migrating to core.
<jdstrand>     name: org.screenly
<jdstrand>     bus: system
<sborovkov> jdstrand: thanks, and this would help me in devmode as well?
<jdstrand> sborovkov: are you using 'bus: session' or bus: system' in your yaml? also, is it a session or system service?
<sborovkov> jdstrand: I was not using anything, just trying to get it running in devmode first. Hmm, we just have daemon: simple so might be that I should register on a session bus? Sorry, last time I was using dbus was like 5 years ago and back then I did not expose any interfaces :-)
<DedSec> quick question, so i have snap created for rclone but iam trying to have my launchpad auto build use the classic containment so rclone can write to disk for the config files located in the home directory.  but as of right now Launchpad's auto build system wont even compile the snap if i use classic instead of strict or devmode
<jdstrand> sborovkov: ok, if this is using 'daemon: simple', then you are running as root. that implies a system service, so you should use 'bus: system'
<jdstrand> sborovkov: with devmode, you still need to specify the interface because the interface is what modifies the dbus bus policy
<jdstrand> sborovkov: so while apparmor would allow it in devmode (it allows everything), dbus-daemon is still going to deny it. dbus-daemon has no concept of devmode, so you need to specify the interfac ein your yaml
 * jdstrand updates the wiki for that point
<jdstrand> sborovkov: fyi, I updated https://github.com/snapcore/snapd/wiki/Interfaces#dbus for the devmode with system bus case
<sborovkov> jdstrand: understood thanks
<sergiusens> slangasek: hey, we added a new feature (plugin) in snapcraft that fails on zesty and it seems to be related to Qt itself and not snapcraft (https://github.com/snapcore/snapcraft/pull/1127). We are still running yakkety-armhf to verify this but I wanted to know what our options were
<mup> PR snapcraft#1127: Release changelog for 2.27 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1127>
<sergiusens> oh great, the yakkety one timed out... :-/
<sborovkov> jdstrand: I did not use not auto-connected interfaces before. So do I need to connect my snap to core:dbus after installation to make it work?
<jdstrand> sborovkov: actually, no. if you read the page you'll see that the slot implementation uses 'slots' to provide the interface to other snaps
<jdstrand> sborovkov: the slot side policy for the dbus snap allows you to bind to the well-known name without have to use snap connect
<jdstrand> having*
<sborovkov> jdstrand: ok, understood. was confused about that.
<mup> PR snapd#2825 opened: osutil/build_id: add package for reading Build-ID <Created by zyga> <https://github.com/snapcore/snapd/pull/2825>
<jdstrand> sborovkov: a client snap that uses:
<jdstrand> plugs:
<jdstrand>   screenly:
<jdstrand>     interface: dbus
<jdstrand>     bus: system
<zyga> mwhudson: would you have a moment to review the build_id branch ^^
<jdstrand>     name: com.screenly
<jdstrand> sborovkov: would need to 'snap connect foo:screenly screenly:dbus'
<jdstrand> sborovkov: which allows 'foo' to talk to your screenly service
<sborovkov> jdstrand: but that's not needed if both services are inside the same snap?
<jdstrand> sborovkov: with 2.23, no
<mup> PR snapd#2707 closed: overlord/snapstate: prepare for using snap-update-ns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2707>
<mup> PR snapd#2776 closed: cmd: use per-snap mount profile to populate the mount namespace <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2776>
<sborovkov> jdstrand: what if I wanted to make a call to dbus interface that is exposed by service not run as a snap? is that possible with this security implementation?
<jdstrand> sborovkov: you'd have to be more specific. dbus is fully mediated by snaps and, like files, you need to use the proper interfaces to allow talking to the system dbus services or the services of other snaps
<sborovkov> jdstrand: alright, understood. and if I have snapd 2.21 I need to use plugs:... code if client and server are both inside the same snap?
<jdstrand> sborovkov: yes, you would need to plugs the slot you are providing. that is the normal case, but as it happens with dbus, 2.23 added a rule that says "any command within the snap can talk to any other command in the snap over dbus"
<jdstrand> (caveat being the snap needs to use dbus interface or similar to bind to a well-known name)
<sborovkov> jdstrand: thanks for assistance and have a good day :)
<jdstrand> sborovkov: you too :)
<DedSec> so iam kind of stuck with this snap i created for rclone,  rclone uses an .rclone.conf file located in an users home directory be deafult, but whenever i try to configure an remote cloud service with rclone, i get  2017/02/09 20:14:27 Failed to save config file: open /root/.rclone.conf: permission denied.  here is what iam using currently with launchbuild to
<DedSec> automaitcally build and upload https://github.com/Dedsec1/rclone/blob/master/snapcraft.yaml
<DedSec> i meant launchpad not launchbuild lol
<zyga> jdstrand: can you please add this to your queue: https://github.com/snapcore/snapd/pull/2775/files
<mup> PR snapd#2775: cmd: add functions to load/save fstab-like files <Created by zyga> <https://github.com/snapcore/snapd/pull/2775>
<zyga> jdstrand: it's for snap-update-ns, not setuid critical
<slangasek> sergiusens: what are you looking for options on?  are you asking about releasing the sru before pushing to zesty-proposed?
<jdstrand> zyga: added to queue. it won't be today though
<kyrofa> jdstrand, if you have a minute, I could use some advice
<kyrofa> jdstrand, I have a user of the nextcloud snap (strictly confined) on 16.10 who seems to have DNS issues only in the snap. I've reached that conclusion using only these tests: http://pastebin.ubuntu.com/23962576/
<kyrofa> jdstrand, do you agree with that conclusion?
<jdstrand> kyrofa: the tracebacks at line 14 and 18 indicate something unrelated to dns. I'm not convinced that the traceback at 22 is dns
<jdstrand> kyrofa: it could be, but it might not be
<jdstrand> kyrofa: (ie, it could be a bad error message)
<kyrofa> jdstrand, how would you explain how the traceback at 44 seems to have gotten out, then?
<kyrofa> i.e. if it wasn't DNS-related, wouldn't it have a similar issue?
<jdstrand> kyrofa: what if you stage-packages bind9-host and use 'host acme-staging.api.letsencrypt.org'?
<kyrofa> jdstrand, I guess I could host that on people.canonical and have him give it a try
<jdstrand> kyrofa: there are no security denials?
<kyrofa> jdstrand, not unusual ones anyway (/proc/<pid>/mounts)
<kyrofa> I get those as well and it works fine for me
<jdstrand> kyrofa: it might be interesting to see the contents of /etc/resolv.conf and friends in the snap and outside
<mwhudson> zyga: looking
<jdstrand> kyrofa: since you mentioned 16.10, that implies classic vs all-snaps since we have no all-snaps 16.10 images. is this correct?
<kyrofa> jdstrand, indeed
<jdstrand> kyrofa: again, sure you know this, but the mounts stuff would go away if plug mount-observe
<kyrofa> jdstrand, yeah it doesn't actually seem to hurt anything, so I've left that off
 * jdstrand nods
<jdstrand> it is usually harmless
<kyrofa> jdstrand, alright thanks for giving me a few more directions... I wasn't sure where to go next there
<kyrofa> I hate debugging stuff that I can't duplicate
<zyga> mwhudson: thanks!
<zyga> jdstrand: thanks, that's all right
<mup> PR snapd#2826 opened: overlord: optional device registration and gadget support <Created by pedronis> <https://github.com/snapcore/snapd/pull/2826>
<mterry> jdstrand: I'm trying to test all the corners of the unity8 plug interface, and I'm having a hard time understanding why I'm seeing an apparmor denial: http://pastebin.ubuntu.com/23962778/
<jdstrand> mterry: where did you put that rule? did you reload the apparmor profile?
<mterry> that rule is from the /var/lib/snapd/apparmor/ file
<jdstrand> mterry: which one?
<mterry>  /var/lib/snapd/apparmor/profiles/snap.webbrowser-app.webbrowser-app
<mterry> I thought it was reloaded -- let me reconnect interface and restart apps
<jdstrand> mterry: ok, if you are reconnecting and stuff, it blows away custom rules
 * mterry does some testing
<jdstrand> mterry: the rule in the paste is correct for the 2nd denial
<zyga> jjohansen: hey, do you know when can we expect the kernel with your fixes out in the wild (in ubuntu)?
<jjohansen> zyga: 2 weeks
<jjohansen> the kernel has a 3 week cadence
<jjohansen> unless you are talking zesty, and then who knows, it could be sooner
<mup> Bug #1545871 changed: Be able to query with multiple terms <Click Package Index:New> <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1545871>
<mterry> jdstrand: ok yeah I was just being dumb -- thanks
<jdstrand> mterry: np. it isn't obvious that changes are blown away on enable/disable/refresh/etc
<zyga> jjohansen: thanks
<mup> PR snapcraft#1130 opened: catkin plugin: produce build-ready staging area <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1130>
<mup> PR snapd#2814 closed: cmd: add helpers for working with mount/umount commands <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2814>
<mup> PR snapd#2827 opened: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
<zyga> jdstrand: please add this to your queue: perhaps before the mount entry (and it's shorter): https://github.com/snapcore/snapd/pull/2827
<mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
<DedSec> anyone know if launchpad supports snap auto build with an snap using confinement: classic?
<jdstrand> zyga: added
<mup> PR snapcraft#1131 opened: lifecycle: hardcode test_core_snap's PATH <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1131>
<kyrofa> DedSec, not yet, but it will in the next snapcraft release (early next week)
<DedSec> oh cool
<DedSec> but for now i can just build it manually and push when needed i guess
<kyrofa> DedSec, indeed
<kyrofa> DedSec, keep an eye out for the snapcraft 2.27 release announcement; you'll know to try again
<DedSec> gotcha
<DedSec> i mean, iam pretty certain i can get rclone to work fully if i can just get the home plug to allow it to read and write an .conf file to an users home directory
<lutostag> if anybody can help, I've having trouble with launchpad building snaps for me on anything > xenial b/c of not being able to verify the gpg key... "NO_PUBKEY F1831DDAFC42E99D" https://code.launchpad.net/~lutostag/+snap/easy2fa/+build/21077/+files/buildlog_snap_ubuntu_yakkety_amd64_easy2fa_BUILDING.txt.gz
<kyrofa> lutostag, we don't recommend doing that anyway-- we don't have a core snap that corresponds to anything other than xenial
<lutostag> hmm, so if I want to snap with some stage packages > xenial, should I make a ppa for them instead?
<kyrofa> lutostag, that's one way. Another would be to build them as another part
<lutostag> I thought someone might say that... ;)
<kyrofa> lutostag, there are a few issues here. One is that you'll be building with a newer libc than the one on which you'll be running
<kyrofa> lutostag, another is that snapcraft uses the core snap corresponding to the release on which you're building to be smart and strip out libraries it knows are included in the core snap. But since there is no yakkety core snap, it won't remove anything
<lutostag> kyrofa: ah, that's why I get the warnings for 'No libraries to exclude from this release', was curious about that
<lutostag> (when built locally)
<kyrofa> lutostag, yep, that's it
<lutostag> kyrofa: ok, I'll see if I can build the prereqs as a part, thanks
<kyrofa> lutostag, no problem. Give a shout if you need some help
<snapster> Anyone used bluez snap?
#snappy 2017-02-10
<mup> PR snapcraft#1132 opened: Revert "qbs plugin: add plugin support for the Qt Build Suite (#1079)" <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1132>
<james0r> how would i go about moving the snap dir out of my home dir?
<mup> PR snapcraft#1120 closed: Update rustup link.  Bug: 1662960 <Created by cholcombe973> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1120>
<Son_Goku> zyga: ping
<Son_Goku> zyga: I found out how to make the selinux policy domain "permissive"
<Son_Goku> so now it won't completely shut down snapd when it violates policy
<Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/4566045b2d4ab6d72cc8991814753997a53f6377
<Son_Goku> anyway, "snap run hello" works in enforcing mode now
<Son_Goku> the AVC denials are still made, but the thing doesn't break
<Son_Goku> zyga: now, you need to update snapd to the latest version and refresh all the patches for snap-confine and snapd
<Son_Goku> and we're *finally* pushing this out to F24+
<Son_Goku> and we need to retire snap-confine and obsolete it with a snap-confine provided by snapd source package
<Son_Goku> zyga: when I wake up tomorrow morning, I hope to see all of this done ;)
<mup> PR snapcraft#1133 opened: tests: fix the test that was modifying the environment variables <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1133>
<mup> PR snapd#2819 closed: packaging/ubuntu-14.04: inform user how to extend PATH with /snap/bin <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2819>
<zyga> Son_Goku: \o/
<zyga> Son_Goku: I'm going to the doctor now, I'll check back later
<zyga> Son_Goku: let's try to roll out the package if we can this weekend
<mardy> pstolowski: hi! So... I tried again with a working snapd, but I still get the same message: error: cannot add authorization: open /home/mardy/.snap/auth.json: permission denied
<mardy> pstolowski: any idea what the message is about?
<pstolowski> mardy, hmm that's a macaroon file used for connections with the store. are the permissions of the file correct? are you trying to do anything unusual from the hooks?
<mardy> pstolowski: no, just snapctl :-) Let me have a look at the file...
<pstolowski> mardy, this auth file is owned by regular user and permissions are 0600 here on my box
<mardy> pstolowski: it's -rw------- for mardy.mardy (my user)
<pstolowski> mardy, yeah, that's fine. does journalctl shows anything interesting?
<mardy> pstolowski: a few denials, let me paste them...
<mardy> pstolowski: http://paste.ubuntu.com/23965752/
<pstolowski> mardy, yeah, these are "expected" and we have a bug opened to get rid of them (we needlessly try to connect to that socket)
<pstolowski> mardy, but that doesn't cause any issues
<pstolowski> mardy, can you push all your changes to that branch you gave me earlier?
<mardy> pstolowski: yup
<mardy> pstolowski: all pushed to lp:~mardy/webapps-core/iface-hook-test
<mardy> pstolowski: let me also push my snapd branch, where I've added the online-accounts interface...
<mardy> pstolowski: this is my snapd branch: https://github.com/mardy/snapd/tree/hook-test
<pstolowski> ok
<mardy> pstolowski: it's snapd master from today, + your branch, + the OA interface
<pstolowski> mardy, and what do you do to trigger that error?
<imexil> Hi, I was wondering, is there a website where I can browse current registered snaps and see which account they are maintained by?
<imexil> Also how can one overtake the maintenance of a snap package that was pushed earlier by another dev that no longer has an interest in maintaining them and agrees to give the rights to me.
<pstolowski> mardy, also.. do you have encrypted home?
<mardy> pstolowski: the error is triggered when I connect the interface
<mardy> pstolowski: no encrypted home here
<pstolowski> mardy, do normal store ops (installing snaps from store) work?
<imexil> ogra_,  popey: FYI The kind of feedback I was already assuming from upstream regarding yesterdays discussion/help from you: https://github.com/otfried/ipe-tools/pull/24#issuecomment-278880408
<mup> PR otfried/ipe-tools#24: Upgrade snap to version 7.2.7 <Created by dietmarw> <Merged by otfried> <https://github.com/otfried/ipe-tools/pull/24>
<pstolowski> mardy, when you say you trigger it when you connect the interface, do you mean you see it immediately on 'snap connect ...', or on any other operation, *after* the interface was connected?
<mup> PR snapd#2828 opened: tests: increase service retries <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2828>
<mup> PR snapcraft#1129 closed: 96boards: fix the dragonboard example <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1129>
<zyga> re
<mardy> pstolowski: sorry, somehow missed your pings :-)
<mardy> pstolowski: yes, I can install snaps from the store (just installed the snappy-debug one)
<mardy> pstolowski: I see it immediately
<mardy> pstolowski: I presume it's part of the stderr of snapctl, but that's only my guess
<mvo> mardy: you are on classic, right? not on an ubuntu-core only system? what is the output of snap version?
<pstolowski> mardy, doesnt that happen only if interface hooks are in use? do you see it with other connect?
<pstolowski> mvo, fyi, he is plying with my hooks branch, and they are using snapctl
<mardy> mvo: classic, zesty
<mardy> pstolowski: let me try to remote the call to snapctl
<mvo> mardy: and snapctl gives you this error?
<mardy> mvo: I think it's coming from invoking snapctl from within the hook; if I remove that call, then the error goes away
<mardy> pstolowski: ^
<mvo> mardy: we fixed this about a week ago but you may need to ensure that your snapctl is the one coming from the branch
<pstolowski> mardy, ok, so we've been discussing it via telegram, apparently this was fixed ~week ago; are you up-to-date?
<mardy> mvo, pstolowski: right, I only rebuilt snapd, not snapctl; let me try...
<mardy> mvo, pstolowski: still getting the same... can you please point me at the commit which fixes it, to make sure that I have it?
<mvo> mardy: https://github.com/snapcore/snapd/pull/2756
<mup> PR snapd#2756: snapctl: add config in client to disable auth and use it in snapctl <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2756>
<mvo> mardy: thinking about this, I think you get the snapctl from the core snap. please try "sudo snap refresh core --edge"
<mvo> mardy: that should give you the latest up-to-date snapctl
<sborovkov> jdstrand: hi, follow up question to my yesterday's question about dbus. I tried the solution you described but I was getting errors when installing snaps about plugs and slots having the same name. Now I changed yaml to this. Did I understand correctly what needs to be done for it to work? https://hastebin.com/ovuxiqiciz.http
<mardy> mvo: mmm... updated, but I still get the same error
<mvo> mardy: hrm, what do you see with "snap version"?
<mup> PR snapd#2829 opened: tests: add libvirt interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2829>
<mardy> snap    2.22+17.04
<mardy> snapd   unknown
<mardy> series  16
<mardy> ubuntu  17.04
<mardy> mvo: ^
<mvo> mardy: let me investigate this a bit more. as a workaround you can do "mount  -o bind /usr/bin/snapctl /snap/core/current/usr/bin/snapctl"
<mvo> mardy: or instead of /usr/bin/snapctl your own build of it
<mardy> mvo: mmm... still the same
<mardy> mvo: I'll now try with my own build
<pedronis> snapd unknown ?
<mvo> pedronis: I think he is running from a build dir
<mardy> mvo: oh, if I bind-mount the one I've built, then it works
<pedronis> mvo: doesn't that then use the one outside
<mvo> mardy: yay
<mardy> mvo: maybe the fix did not land to the core snap yet?
<mardy> mvo, pstolowski: anyway, thanks a lot! Now I've something to work on :-)
<mvo> mardy: I will check that, it should be but obviously there is a disconnect between theory and reality
<pstolowski> mvo, thanks for looking at that!
<mup> PR snapd#2236 closed: interfaces: add realsense interface <Decaying> <Created by swem> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2236>
<Son_Goku> mvo, morning!
<mvo> hey Son_Goku
<Son_Goku> how are you? :)
<mvo> Son_Goku: good, thank you! how are you?
<Son_Goku> a bit groggy, but otherwise fine
<mvo> Son_Goku: ha! I share that feeling, I need a cup of tea :)
<Son_Goku> hehe
<Son_Goku> I'm pleased that we'll *finally* be able to release snapd into Fedora, though
<Son_Goku> unfortunately, I can't do it because there's a bunch of patches that need to be rediffed for snap-confine and snapd, and possibly more patches
<Son_Goku> and unfortunately, none of the patches can be upstreamed :(
<zyga> Son_Goku: hey
<zyga> Son_Goku: I can help
<Son_Goku> I mean, you're going to have to do it :/
<Son_Goku> we're so far behind
<mvo> Son_Goku: meh, that is sad. at the same time, super exciting that it can go in now
<zyga> Son_Goku: I think we need to ship snap-confine setuid root, I've been digging through the kernel but I didn't find the test that fails without it
<Son_Goku> you *can* use setuid
<Son_Goku> it's just not preferred
<zyga> Son_Goku: oh, in that case one issue less off the table
<Son_Goku> file a bug about the cap issue against snapd and we'll switch back once it's fixed
<zyga> Son_Goku: I think we can figure out the caps but I don't want it to block the release
<zyga> Son_Goku: yes, I filed it...
<zyga> https://bugs.launchpad.net/snapd/+bug/1657099
<mup> Bug #1657099:  snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN <snapd:New> <https://launchpad.net/bugs/1657099>
<zyga> that's the issue
<zyga> Son_Goku: btw, did you try to refresh the package to 2.22?
<Son_Goku> not yet
<Son_Goku> I just figured out the selinux policy thing before going to sleep
<zyga> Son_Goku: that's great news, my fedora box is so lonely without snaps :/
<zyga> Son_Goku: I found a way to run snaps with classic confinement on fedora
<zyga> Son_Goku: I didn't code the patch yet but I will as soon as I'm done with content
<Son_Goku> so, it's not a real solution, but it means that AVC denials won't block snapd
<zyga> Son_Goku: let's do that, we can iterate on the policy
<zyga> Son_Goku: but not without being able to use it at the same time
<Son_Goku> that's the point of it :)
<mup> PR snapcraft#1135 opened: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1135>
<Son_Goku> we should have done it in the beginning, but I didn't know about it
<zyga> Son_Goku: I've been fixing some issues in the content interface but this is dragging on due to extra complexity
<Son_Goku> and no one told me
<Son_Goku> I stumbled on it, and realized it resolved our problem
<Son_Goku> I also have some bad-ish news for you regarding openSUSE packaging
<zyga> Son_Goku: yes?
<Son_Goku> they've completely changed how Golang packaging is done
<zyga> !!!
<zyga> do you have a reference?
<Son_Goku> whoo boy do I have one
<zyga> and what did they decide upon?
<Son_Goku> https://github.com/openSUSE/golang-packaging/pull/5
<mup> PR openSUSE/golang-packaging#5: fix for SLE11SP3 <Created by marguerite> <Closed by tboerger> <https://github.com/openSUSE/golang-packaging/pull/5>
<Son_Goku> they're now doing the same thing Fedora does
<Son_Goku> source code only libraries
<Son_Goku> basically, the Docker team and the creator of golang packaging didn't get along
<Son_Goku> so the golang packaging creator was forced out, and now openSUSE packaging is closer to Fedora than before
<zyga> Son_Goku: oh boy
<zyga> Son_Goku: some heavy words fly there
<Son_Goku> yeah
<Son_Goku> and of course, it's all still undocumented :(
<zyga> Son_Goku: after content I should be able to do a deep dive
<zyga> Son_Goku: with debian in good hands (CI will be working on Debian soon, I heard)
<Son_Goku> bah
<zyga> Son_Goku: I plan to split my focus 50/50 on Fedora and Suse
<zyga> Son_Goku: and after Fedora is operational see if we can build for derivatives and CentOS
<Son_Goku> the only obstacle for RHEL and friends is the go compiler
<Son_Goku> if it builds, we're gravy
<Son_Goku> golang libraries will need to be refreshed too...
<zyga> Son_Goku: ok, let's try to win some packages this week; I'm sick but I can hack on this all weekend if we have a chance to solve the problems
<Son_Goku> I'm not sure how available I will be this weekend
<zyga> Son_Goku: I didn't follow the drama/discussion closely
<Son_Goku> I'm going to be at a hackathon on behalf of my company
<zyga> Son_Goku: but I guess I just have to see how it looks like now
<zyga> Son_Goku: woot, nice :)
<zyga> Son_Goku: maybe next week then
<mup> PR snapcraft#1136 opened: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1136>
<Son_Goku> zyga: my bit is done :)
<Son_Goku> you've got to refresh snapd.spec and patches up to 2.22
<Son_Goku> and move snap-confine into being a subpackage of snapd
<zyga> Son_Goku: thank you!!
<zyga> Son_Goku: I'll see if I can get it to all work tonight
<mup> Bug #1663565 opened: Media Keys do not work in strictly confined snaps <isv> <snapd:New> <Snappy:New> <https://launchpad.net/bugs/1663565>
<zyga> Son_Goku: I'm really happy to see progress in this front
<zyga> Son_Goku: btw, what about Mageia?
<Son_Goku> keep in mind that you'll need to have snap-confine subpackage "Obsoletes: snap-confine < 1.0.44-3"
<zyga> Son_Goku: ok, will do
<Son_Goku> as for Mageia, since there's be zero progress on AppArmor upstreaming, it still doesn't work with stock AppArmor :(
<Son_Goku> s/be/been/
<Son_Goku> so no confinement
<Son_Goku> but I can probably get it going derived from the Fedora packages as soon as you've made them and published them
<zyga> Son_Goku: there's a lot of progress, look at's what in mainline now
<zyga> Son_Goku: it's not all there but a good chunk did land
<zyga> Son_Goku: now with the main part out there's been a large number of small fixes (I helped find a few of those :)
<zyga> Son_Goku: they are all going up
<Son_Goku> anyway, it doesn't matter that much since Mageia has no MAC enablement right now
<Son_Goku> that'll have to wait for Mageia 7
<zyga> Son_Goku: can packaging from Fedora be used on Mageia?
<Son_Goku> yes
<zyga> Son_Goku: sounds good
<Son_Goku> we follow the same rules as Fedora
<Son_Goku> zyga: also /writable will need to be moved, if that's still a thing
<zyga> Son_Goku: /writable only exists on core systems
<Son_Goku> can it be moved?
<zyga> Son_Goku: are you talking about making a all-snap image with mageia base?
<zyga> Son_Goku: /writable doesn't show up anywhere on the filesystem
<Son_Goku> potentially, yes
<zyga> Son_Goku: for a core system it is required and I can explain why
<Son_Goku> okay..
<zyga> Son_Goku: it could be "moved" but there's little reason to IMHO (but we can explore that later)
<Son_Goku> it's not something we'll deal with right now
<Son_Goku> I can't make an all-snap system until snapd and snapcraft remove their ubuntu assumptions anyway
<zyga> Son_Goku: ogra keeps thinking about buildroot-based base snap
<Son_Goku> bah
<zyga> Son_Goku: I think we're getting closer to base snaps, maybe around spring?
<ogra_> zyga, well, we have better tools in the distro actually :)
<zyga> Son_Goku: the idea is that a totally separate base opens up a way to experiment
<Son_Goku> I've already made tooling for producing such base snaps :)
<ogra_> i think i'd actually use copy_exec() from initramfs-tools with a file list fed into it
<Son_Goku> oh, man
<Son_Goku> please don't tell me we can't use dracut?!
<Son_Goku> and that Ubuntu Core still doesn't use dracut
<Son_Goku> Debian has stated their intent to retire initramfs-tools for years
<ogra_> Son_Goku, no, we dont use dracut, though there were some changes recently that at least allow you to use it in debian and ubuntu
<Son_Goku> :(
<Son_Goku> if Ubuntu Core is the Ubuntu of the future, it should be using dracut :/
<ogra_> but the above has nothing to do with either ... i just want to use a function from the tools :)
<ogra_> copy_exec resolves reverse binary and lib dependencies automatically ... if you use it to put any file in place you get exactly the bare minimum of libs and binaries needed to execute what you copy
<ogra_> while buildroot is nice and all i think we should not stop using ubuntu binaries for creating core
<Son_Goku> ogra_: well, you can guess what my opinion is :P
<ogra_> we want the binaries but drop the overhead a deb package puts upon us and limit the set of shipped things to the bare minimum ...
<ogra_> the current design doesnt allow that since we use a build tool that completely relies in dpkg
<ogra_> s/in/on
<mup> Bug #1663220 changed: Add support to Secret Service APIs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1663220>
<mup> PR snapd#2723 closed: tests/main: add test case to verify core snap conf option service.ssh.disabled <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/2723>
<jdstrand> sborovkov: hey, gyi, I'm off today so at best 'in and out' (but mostly out :)
<jdstrand> sborovkov: but I saw your question, so, per https://github.com/snapcore/snapd/wiki/Interfaces#dbus, you need to use 'name' on both sides
<jdstrand> sborovkov: your slot looks fine. you need your plugs to also specify 'name: com.screenly'
<jdstrand> sborovkov: also, if you want to rename your slot, you can use:
<jdstrand> slots:
<jdstrand>   something:
<jdstrand>     interface: dbus
<jdstrand>     name: com.screenly
<jdstrand>     bus: system
<jdstrand> then your plugs is fine:
<jdstrand> plugs:
<jdstrand>   somethingelse:
<jdstrand>     interface: dbus
<jdstrand>     name: com.screenly
<jdstrand>     bus: system
<zyga> jdstrand: o/
<jdstrand> sborovkov: but you need to have one of your apps 'plugs: [ somethingelse ]' and one 'slots: [ something ]'. as it is now, since none of the apps use 'slots', they all get your toplevel slots, and since at least one of your apps 'plugs' stuff, none of them will get 'somethingelse'
<jdstrand> sborovkov: see https://git.launchpad.net/~jdstrand/+git/test-hello-dbus/tree/snapcraft.yaml as an example
<jdstrand> zyga: hey, not sure you saw, but I'm off today
<jdstrand> sborovkov: good luck! there are others here who can help you if I don't see your followup questions :)
<zyga> jdstrand: oh, I didn't remember; I'm just saying hi :)
<jdstrand> zyga: heh, ok, hi!
<zyga> jdstrand: nothing to do today :)
<jdstrand> zyga: I think you've conditioned me to expect a code review when you wave at me :P
<sborovkov> jdstrand: thanks :)
<zyga> jdstrand: I'm sorry; I should give you a hug and beer sometimes :)
<zyga> jdstrand: nothing to review :)
<jdstrand> zyga: it's fine! :)
<sborovkov> Hello, can someone help me out and tell me if I got correct syntax here? Want to expose interface by playlist service. And websocket service calls that interface. https://hastebin.com/foluxekeya.pl
<mup> PR snapcraft#1137 opened: Build-depend on git <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1137>
<mup> PR snapd#2830 opened: allow core_support interface to modify /etc/default/swapfile <Created by ogra1> <https://github.com/snapcore/snapd/pull/2830>
<mup> Bug #1663615 opened: snap broken out of the box on 16.04.1 <Snappy:New> <https://launchpad.net/bugs/1663615>
<mup> PR snapd#2831 opened: interfaces: add missing recvfrom syscall to dbus interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2831>
<mup> Bug #1663303 changed: Running snapcraft on Ubuntu 14.04  fails with a traceback <isv> <trusty> <Snapcraft:New> <https://launchpad.net/bugs/1663303>
<sergiusens> slangasek: more like a feature that only works on xenial
<mup> PR snapd#2832 opened: interfaces/builtin: add network-setup-control which allows rw access to netplan <Created by morphis> <https://github.com/snapcore/snapd/pull/2832>
<ara> question for anyone
<ara> if you have a daemon that requires plug foo to be connected in order to work
<mup> PR snapcraft#1131 closed: lifecycle: hardcode test_core_snap's PATH <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1131>
<ara> is there a way to tell snapd to start the daemon only when that plug has been connected?
<kyrofa> ara, unfortunately no
<kyrofa> ara, snapd has no way of knowing that the plug in question is actually required or optional
<ara> kyrofa, OK, thanks for confirming
<kyrofa> ara, e.g. if you managed to write your service such that the plug only extended its functionality
<kyrofa> ara, this is somewhat difficult without seccomp returning ERRNO, but it'll get easier soon
<mup> PR snapcraft#1133 closed: tests: fix the test that was modifying the environment variables <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1133>
<joc> elopio: hey, i got odd failures in tests after updating my PR again
<didrocks> zyga: hey, are you around? I was able to connect 2 content interfaces which have different "content:" name
<kyrofa> didrocks, my gift to you: https://lists.ubuntu.com/archives/snapcraft/2016-December/002189.html
<didrocks> kyrofa: thx! I didn't remember your email :p
<kyrofa> didrocks, haha, no problem
<kyleN> should I always see the browser-support interface now, for example on pi2? (I don't: snapd version 2.21)
<Blu2_> KDE neon to officially support snaps? nice. http://www.omgubuntu.co.uk/2017/02/kde-neon-intergrating-snap-apps
<seb128> kyrofa, Tony asked on the list but is there a launchpad bug about it?
<kyrofa> seb128, not that I logged anyway-- I read that it was a known bug and moved on, but I wonder if it's logged
<seb128> :-/
<kyleN> kyrofa, should I always see the browser-support interface now, for example on pi2? (I don't: snapd version 2.21)
<kyrofa> kyleN, I thought so, but I'm not 100% sure. It's provided by the core snap
<kyrofa> kyleN, once ogra_ is off of his call he can help
<kyleN> kyrofa, yes its a builtin but I don't see it. I have a client that needs to use it and they don't see it either. do you have a recommended next step I should take?
<zyga> didrocks: on a call
<kyleN> ok
<didrocks> zyga: no worry, kyrofa answered. A bug in content interface that you told "known" ;)
<kyleN> kyrofa, ogra_: on browser-support interface not visible, I reported https://bugs.launchpad.net/snapd/+bug/1663656
<mup> Bug #1663656: browser-support interface not reported <snapd:New> <https://launchpad.net/bugs/1663656>
<ogra_> kyleN, not sure thats actualyl a core interface ... jdstrand would know
<ogra_> i think it is tied somehow to unity7/x11
<kyleN> kyrofa, ok. looking for pointers & info here to help a client.
<ogra_> (which we do not have on the core images)
<kyleN> ogra_, hi. ok so I suppose I can dig into why they need that interface and see if there is an existing one they can use, else we are blocked
<ogra_> kyleN, well, lets see what jdstrand says perhaps we should have it in core but that might need some extra bits since we dont have any graphics system by default
<kyleN> ogra_, ok
<EEight> if I want access to a webcam, what should I put in the snap.yaml???
<Blu2_> https://snapcraft.io/docs/reference/interfaces
<brunch875> EEight: https://snapcraft.io/docs/reference/interfaces
<Blu2_> camera
<Blu2_> 1 second faster :D
<brunch875> blast, I never thought I'd take precisely as long to reply
<EEight> This is defined in plugs: right?
<Blu2_> yes
<Blu2_> https://snapcraft.io/docs/snaps/metadata
<brunch875> is it / will it be possible for an user to restrict snap permissions?
<brunch875> thinking twice about it, this is a silly question; since it's always possible to re-package the snap, right? :p
<kyrofa> brunch875, can you be more specific?
<kyrofa> brunch875, no such thing as silly questions!
<brunch875> kyrofa: let's say some developer makes some... social media snap which asks for camera permission. And I want to use the whole social-media thing but I'm very concerned that the piece of software might spy me using the camera. Can I decide to deny access to the camera completely, even if the snap requires camera persmissions?
<kyrofa> brunch875, oh certainly, one of my favorite features
<kyrofa> brunch875, assuming you have any snaps installed, run `snap interfaces`
<brunch875> any IRC snap I can fetch?
<brunch875> oh, I could try telegram
<kyrofa> brunch875, yeah that'll work
<ogra_> theer should be a hexchat snap too
<ogra_> even from the upstream guys afaik
<kyrofa> brunch875, anyway, once you do that, you'll see a list of "slots" on the left and "plugs" on the right
<kyrofa> brunch875, snaps are confined by using these (they're called interfaces). Plugs plug into slots
<kyrofa> brunch875, so if an app "plugs into" the camera interface, you can simply use `snap disconnect` to break that connection
<kyrofa> brunch875, which means it no longer has permission to access the camera
<brunch875> nice!
 * brunch875 applauds
<kyrofa> brunch875, now, take this with a grain of salt: this will deny access, but not all applications will be written to be HAPPY with that
<kyrofa> brunch875, ideally the app would just run and say "Ah, can't access the camera, no matter."
<EEight> last question, is it true that a snap gets refresh automagically after 24h?
<brunch875> and yet applications without exception handling will just [rude remark] themselves
<kyrofa> EEight, four times a day, randomly distributed
<kyrofa> brunch875, heh
<brunch875> this design could allow for fake slots
<kyrofa> brunch875, what would that be, technically?
<brunch875> well, I was thinking of a fake camera device which was just a video on loop
<brunch875> so the snapped application could be fooled to believe it was accessing the camera when it was not
<cholcombe> in my snap plugin is it possible to install another snap that is needed to build the snap?
<kyrofa> brunch875, that sounds difficult to implement in a generic way
<kyrofa> brunch875, but nothing prevents you from writing a snap that provides a camera slot
<brunch875> kyrofa: so could I re-route the slot from one snap to another, then?
<mup> PR snapcraft#1132 closed: Revert "qbs plugin: add plugin support for the Qt Build Suite (#1079)" <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1132>
<kyrofa> brunch875, yes you can
<brunch875> !! So it already is there! Woah
<kyrofa> brunch875, just `snap disconnect` it and `snap connect` it to another slot
<brunch875> brilliant!
<ogra_> sexy, aint it ? :)
<elopio> joc: hey, we got a few issues closing this release. Please rebase with master.
<kyrofa> brunch875, but it's not that easy-- the camera slot provides apparmor/seccomp snippets to allow hardware access. You'll have to fake that out somehow
<brunch875> Wow, I'm really excited about snappy now
<ogra_> welcome to the club :)
<joc> elopio: we've also noticed that when using master our python parts fail to install
<joc> elopio: we get clashes with "RECORD" files
<brunch875> oops, apparently starting a line with !! triggered and ubottu edit request, whatever that means :x
<joc> elopio: e.g. http://paste.ubuntu.com/23967962/ this doesnt happen with 2.26
<elopio> kyrofa: did we change something in the conflicts on this release?
 * elopio tries.
<cholcombe> elopio, so in the rust plugin i'm thinking that if i snap rustup i can install that and it might help resolve my issue and eliminate the script needed to choose the correct rustup version
<elopio> cholcombe: that will make sabdfl very happy.
<cholcombe> elopio, can you install a snap in a plugin to help that plugin?  that seems like it wouldn't work?
<elopio> cholcombe: that's how we want to support go1.7 in the go plugin. So we haven't done it yet, but we will do it soon.
<cholcombe> cool.  is there a bug i can watch for that?
<elopio> cholcombe: https://bugs.launchpad.net/snapcraft/+bug/1616985
<mup> Bug #1616985: the go plugin doesn't support go 1.7 <isv> <plugin> <Snapcraft:Confirmed for sergiusens> <https://launchpad.net/bugs/1616985>
<cholcombe> elopio, cool.  any idea when that might land?  just curious it's not critical or anythign
<elopio> cholcombe: I think it's on top of the backlog for Sergio, but he's down sick today. Early next week.
<cholcombe> elopio, nice.  that's rather quick.  i'll keep an eye on this bug
<elopio> cholcombe: however you can play with that. Take a look how we are installing stage-packages, and change that to call snap install instead of apt install.
<cholcombe> ok
<elopio> that's the gist. The most simple implementation is just that. On debs we do some niceties with caches that would be great to do with snaps, but that can come later.
<cholcombe> yeah
<mup> PR snapd#2833 opened: many: allow core.refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
<cholcombe> yeah i think that gets me out of the jam.  i install the rustup snap for a given architecture and then build as usual
<cholcombe> otherwise i'm patching that bash script
<EEight> ok last last question: when uploading my snap on myapps.developer.ubuntu.com will it ever be listed in Ubnuntu Software Center (under the Category that I put in the snap.yaml)?
<kyrofa> EEight, as long as it is in the stable channel, yes
<kyrofa> Hey ogra_ I can't seem to install ubuntu-image from any channel
<ogra_> kyrofa, hmm, barry maintains it ... did you try devmode ?
<kyrofa> ogra_, "snap not found" for everything. Do you know anything about that? Was it unpublished for some reason?
<kyrofa> Wait... it tells me "not found" if I don't use devmode?!
<kyrofa> Come on...
<ogra_> yeah, thats policy
<ogra_> devmode snaps are never listed in find
<kyrofa> ogra_, I don't care if they're not listed in find. Non-stable snaps aren't listed either
<kyrofa> But if I forgot to pass --devmode, tell me I made a mistake!
<ogra_> well, iirc it "is not desired" that find finds anything devmode
<kyrofa> ogra_, I'm not finding though... I'm trying to install
<ogra_> if it would tell you there is a devmode version that would defeat the purpose
<ogra_> well, i think it is the same for install
<ogra_> talk to mark or gustavo :)
<ogra_> iirc the idea is to discuorage using devmode for actual proted snaps
<ogra_> promoted
<kyrofa> ogra_, that all makes sense for not showing in find
<ogra_> well, but why would install be different here
<kyrofa> ogra_, because that implies I know something is there. Particularly when I'm using a non-stable channel
<ogra_> well, file a bug and lest see ;)
<ogra_> *lets
<kyrofa> ogra_, haha, yeah
<EEight> patcou01
<EEight> it's me
<EEight> not a password
<EEight> :)
<EEight> kyrofa: after how many days will it be listed in ubuntu software center?
<kyrofa> EEight, I _think_ as soon as it makes it to stable. If you can find it with `snap find`, I think it'll be in the software center
<EEight> I can find it using the search bar in the ubuntu software center & also using snap find, but it's not listed in the Categories (for me Games)
<kyrofa> EEight, ahhh, you left that out!
<kyrofa> attente, are snaps not sorted into categories in the software center?
<EEight> furthermore, i don't like the fact that I need to ask my users to create an ubuntu one account to install my apps... others app in the ubuntu software center (under categories) do not ask this
<kyrofa> EEight, I think we all agree with you
<kyrofa> EEight, we're working on making that better
<kyrofa> EEight, for what it's worth, you can install from the terminal with `sudo snap install <snapname>` with no UO account
<EEight> kyrofa: you've been really helpful, thank you. yes i know, but the main idea of deploying to ubuntu was that i would be in the ubuntu software center, simply search in games / kids = install (no terminal, no account)
<kyrofa> EEight, of course, understood
<kyrofa> EEight, can you please log a bug about the categories against https://bugs.launchpad.net/ubuntu/+source/gnome-software ?
<elopio> joc: still here?
<joc> elopio: for a few mins
<elopio> joc: this PR has the fault, but we need it to support classic: https://github.com/snapcore/snapcraft/pull/1093/files#diff-258c2f9c12b9527559611776a87d8ba5R26
<mup> PR snapcraft#1093: python plugin: do the right thing with classic <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1093>
<elopio> joc: could you add those RECORD excludes in your snap before leaving? We'll see if we can fix it before the release, and we will see if it affects others.
<elopio> but as you are about to leave, maybe better if you leave a workaround just in case :)
<joc> elopio: so you would like one of the integration test snaps to trigger the conflict?
<elopio> joc: no, I mean to get https://git.launchpad.net/checkbox-snappy back to green, it needs those exclussions.
<joc> oh i see
<joc> well i might add it to the integration tests anyway so you don't break it in the future ;)
<mup> PR snapd#2513 closed: refactor the dialer init code <Created by teknoraver> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2513>
<ryebot> Is there any way to transfer a snap in the store to another owner? Alternatively, rename or delete a snap in the store?
<kyrofa> ryebot, nessita might be able to help you with that
<ryebot> kyrofa: excellent, thank you :)
<elopio> matiasb: do you know what the python RECORD files are for?
<elopio> nessita: ^
<elopio> I need a python expert :(
<Cynerva> zyga: apologies if i'm too late getting back to you, are you still available today to help me with permissions on the kubelet snap?
<mup> PR snapcraft#1138 opened: python plugin: exclude the RECORD files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1138>
#snappy 2017-02-11
<knight__> Which version of snapcraft did scriptlets show up in?
<knight__> This is great news :)
<mup> Bug #1663787 opened: Libreoffice 5.3 instalado via snapd. NO accede a root ni a la particiÃ³n con ntfs <Snappy:New> <https://launchpad.net/bugs/1663787>
<knight__> How do you cross snap for armhf on x86?
<knight__> I just pushed my first snap
<knight__> "Creating snapcraft-wildly-neat-emu
<knight__> lol
<knight__> How can I build a snap for armhf on my x86?
<OerHeks> easy to find: https://developer.ubuntu.com/en/snappy/guides/cross-build/
<ronn13> hi guys, I created my snap and it works in devmode, but not in strict. Apparmor complains with syscall=92, which is resolved to `shmctl`, anyone knows who to deal with this?
<Skuggen> What interfaces do you have in your snap?
<Skuggen> https://snapcraft.io/docs/reference/interfaces may just need to add one of these (the ones with auto-connect "no" requires manual connection after installing) process-control, maybe?
<ronn13> Skuggen: I have X11, unity7, pulseaudio, opengl, network, home, gsettings and browser-support
<ronn13> is there any way which interface I'm missing?
<Skuggen> I don't know what would cover that command, but you could try adding process-control
<Skuggen> You'll need to run the connect command on it, I think
<ronn13> I use snap.debug and I get:
<ronn13> Syscall: chown
<ronn13> Suggestions:
<ronn13> * don't copy ownership of files (eg, use 'cp -r --preserve=mode' instead of 'cp -a')
<ronn13> * adjust program to not use 'chown'
<ronn13> but I don't use either in my code
<ronn13> it's a electron-based app
<Skuggen> Maybe it tries to change ownership of some files?
<Skuggen> Snappy doesn't support it yet (it's coming, along with the ability to change uid, I think)
<ronn13> ok
<ronn13> thanks Skuggen
<MonkeyDust> hi, ubuntu linux user here ... after installing and removing lxc/lxd and snappy, something is eating my / ... been looking for the culprit for days now, also did 'lsblk -f' ... this is the outcome ... how do i get rid of it? ... http://paste.ubuntu.com/23973829/
<MonkeyDust> *part of the outcome
<MonkeyDust> hi, ubuntu linux user here ... after installing and removing lxc/lxd and snappy, something is eating my / ... been looking for the culprit for days now, also did 'lsblk -f' ... this is a part of the outcome ... how do i get rid of it? ... http://paste.ubuntu.com/23973829/
<knight__> wewp
<knight__> https://developer.ubuntu.com/en/snappy/guides/cross-build/
<knight__> That seems out of date.
<knight__> Trying to install golang-go-linux-arm on an x64 installation of Ubuntu fails to be found.
<knight__> I'd like to be able to build arm snaps on my development machine.
<knight__> hmm
<mup> Bug #1663942 opened: snappy-debug suggests network-control, when network is enough <Snappy:New> <https://launchpad.net/bugs/1663942>
#snappy 2017-02-12
<knight__> why does Ubuntu Core use a raspberry pi 2 kernel for the pi3 image?
<knight__> welike@coinbox:~$ systemctl start avahi.service
<knight__> Failed to start avahi.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
<knight__> hmm
<mup> PR snapd#2822 closed: Added a linux framebuffer interface <Created by femdom> <Closed by femdom> <https://github.com/snapcore/snapd/pull/2822>
<mup> PR snapd#2822 opened: Added a linux framebuffer interface <Created by femdom> <https://github.com/snapcore/snapd/pull/2822>
<deanman> Hiya, running into some networking issues during snap installation on a brand new RPi 3. In detail, won't recognize the Wifi settings and it won't continue with installation. Any hints for me ?
<ogra_> deanman, there is a bug with the wifi driver that makes it work only after you configured a wired network ... do the initial setup with lan cable, after it is properly set up, reboot ... then ssh in, run sudo console-conf, disable lan and configure wlan, reboot again and you should be good
<knight__> Hmm. Still can't find any snapcraft cross-building docs.
<knight__> All these people and almost no activity over 3 days.
<knight__> I've got two snaps published, but would like some help cross-building for arm. When someone has a chance, please reach out. Thanks.
<oky> knight__: weekend, probably
#snappy 2018-02-05
<mborzecki> morning
<mborzecki> zyga: hey
<mborzecki> you around?
<zyga> mborzecki sure, can I help you somehow?
<mborzecki> zyga: nvidia biarch is borked
<mborzecki> let me show you where
<mborzecki> zyga: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support-nvidia.c#L276 the last thing that sc_mkdir_and_mount_and_glob_files() does is remount the target directory ro, so sc_glob_files_only() then fails with filesystem is read only https://paste.ubuntu.com/26523173/
<mborzecki> zyga: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support-nvidia.c#L276 the last thing that sc_mkdir_and_mount_and_glob_files() does is remount the target directory ro, so sc_glob_files_only() then fails with filesystem is read only https://paste.ubuntu.com/26523173/
<zyga> aha
<zyga> this makes sense, feel free to move that outside so that things work correctly
<mborzecki> ok
<zyga> thank you for spotting that
<zyga> it feels like a RC3 though
<mborzecki> yeah, built a new rig, put an old nvidia card inside since prices are absurd, tried to debug the spotify issue some guy raised in a forum and ended up debugging nvidia issues instead :)
<zyga> :-)
<zyga> it's good that you are using nvidia though, most of the laptop developers don't notice that
<zyga> hey mvo
<mvo> hwy zyga
<mvo> hey
<mborzecki> mvo: morning
<mvo> good morning mborzecki
<mup> PR snapd#4603 opened: cmd/snap-confine: fix read-only filesystem when mounting nvidia files in biarch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4603>
<mborzecki> zyga: ^^
<zyga> yep
<zyga> looking
<mborzecki> sadly there are no tests for this code, so i just tested it locally
<mborzecki> the good news is that i can run snaps again :)
<mborzecki> ohmygiraffe works
<kalikiana> good morning, snappers
<mborzecki> kalikiana: morning
<mvo> mborzecki: oh, nice. something for 2.31?
<zyga> mborzecki +1
<zyga> we need to ensure that some round of testing on proprietary nvidia driver is done for 2.31
<mup> PR snapd#4601 closed: tests: update kill-timeout focused on making tests pass on boards <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4601>
<mvo> zyga: is this 2.31 cherry-pick material?
<zyga> yes
<zyga> definitely
<mborzecki> i have an old 9600gt card, so can check with 340xx driver, no vulkan though
<zyga> mvo note that it affects _biarch_ systems
<mvo> zyga: so fedora/solus?
<mborzecki> mvo: yes, otherwise it's not possible to assemble a mount on on my arch box
<zyga> mvo yes
<mvo> ta
 * mvo looks
<mvo> mborzecki: 4598 is ready right? it has a +1 from neal
<mborzecki> mvo: yes
<mup> PR snapd#4598 closed: packaging: create /var/lib/snapd/lib/{gl,gl32,vulkan} as part of packaging <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4598>
<mvo> mborzecki: fwiw, once the tests are green I will merge 4603, my commment about comments can always added later
<mborzecki> mvo: ok
<mvo> mborzecki: I also noticed this is already used in the code without much comment so :)
 * mvo has a wtf moment when he noticed that unsquashfs will return "0" if the unpack fails
<zyga> ....
<zyga> well
<zyga> yeah, that is weird
<mvo> zyga: my thoughts exactly :)
<mvo> zyga: I will send a patch to upstream and to our ppa
<mup> PR snapd#4602 closed: tests: use root path to /home/test/tmp to avoid lack of space issue <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4602>
<mvo> zyga: but holly cow
<mborzecki> mvo: is there anything special about the file?
<zyga> maybe it's _just_ a bug
<mvo> mborzecki: which file? the squashfs file that is unpacked? I unpacked it into a tmpfs
<mvo> mborzecki: and that had not enough space
<mborzecki> mvo: right, the squashfs file
<mborzecki> oh
<mvo> mborzecki: sergio figured out this is what broke the prepare-image test on arm64
<mvo> mborzecki: it uses a tmpfs on /tmp which is not big enough to hold the tmp files we need to prepare the image (the armhf kernel must be unpacked there)
<mvo> zyga: it probably is
<mborzecki> mvo: btw. does it try to clean up the fiels it extracted?
<mborzecki> s/fiels/files/
<mvo> mborzecki: I doubt it, let me check
<mvo> mborzecki: no
<mborzecki> right, don't know what i was expecting
<mborzecki> it'd be funny to put squashfs through afl and see what comes out
<zyga> afl?
<mborzecki> american fuzzy loop
<mborzecki> http://lcamtuf.coredump.cx/afl/
<zyga> oh, cool
<zyga> anyone wants to do a quick HO test with me
<pstolowski> mornings!
<zyga> hey hey
<mborzecki> tak, tak
<mborzecki> wrong window :)
<mborzecki> pstolowski: morning
<zyga> mborzecki tak tak, wrong window
<mborzecki> mvo: restarted the build in 4603, looked like an unrelated failure
<mvo> ok
<Chipaca> mvo: o/
<Chipaca> mvo: looking at 4600, do config changes always end in a *json.RawMessage?
<mvo> Chipaca: I'm not 100% certain, that sounds like something pstolowski may know
<Chipaca> pstolowski: ^?
<Chipaca> pstolowski: in config's transaction.go, do config changes always finish in a *json.RawMessage?
<mvo> Chipaca: fwiw, the PR is a bit of a RFC for gustavo if this is validation we want or not
<Chipaca> mvo: ack
<mvo> ogra_: did things work once the typo in the core.service.rsyslog.disable=true was fixed btw?
<mvo> Chipaca: I mean, don't kill yourself over the review :) it might be in vain :(
<mvo> Chipaca: even though I think it would be good to have this validation
<pstolowski> Chipaca, mvo yes
<Chipaca> pstolowski: ack
<Chipaca> pstolowski: why are they *json.RawMessage, btw? instead of just json.RawMessage i mean
<milp_media> ogra_: you might be right, but that whole ubuntu sso thing seems fishy to me. i dont want to be dependant on any service that is not hosted on my own devices :/
<pstolowski> Chipaca, dunno. I haven't implemented that
<mvo> zyga: I pushed a PR upstream for unsquashfs, I wonder what we should do in the meantime, we could do crzay stuff like compare the targetdir with the unsquahfs -ls output but that sounds slightly crazy. but maybe patience is a virtue and I wait for upstream
<pstolowski> Chipaca, kyrofa might remember ;)
<Chipaca> pstolowski: blame says gustavo
<Chipaca> :-)
<Chipaca> i'll ask
<pstolowski> Chipaca, okay. blame has better memory than me, that's for sure
<mvo> Chipaca: ta
<zyga> mvo: what is the worst thing that can. happen if we use broken unsquashfs?
<mvo> zyga: we unpack a kernel on arm, no space left on /boot but we don't detect the failure, continue and the boot fails (and reverts)
<mvo> zyga: so hopefully its not too bad
<mvo> zyga: but still fugly that we don't detect it when it happens
<Chipaca> mvo: zyga: we found a bug in unsquashfs?
<mborzecki> mvo: shall i merge 4603?
<mvo> Chipaca: bug/feature/missing-thing - unsquashfs does not report anything on unsqushfs failures
<mvo> Chipaca: like exit(0)
<mvo> Chipaca: is what it will always do
<Chipaca> ah
<mvo> Chipaca: which is slightly annoying, we had this bug on arm64 that prepare-image failed and there was a kernel missing
<mvo> Chipaca: and it turns out, tmpfs was too small and unsquashfs told the world: "failed..." on stdoutbut never reported it via exitcode
<mvo> mborzecki: let me look
<mvo> mborzecki: yes please, I will cherry-pick
<mvo> afterwards
<zyga> mvo: could we bundle fixed unsquashfs in the package?
<mvo> zyga: yeah, I think that would work
<mup> PR snapd#4603 closed: cmd/snap-confine: fix read-only filesystem when mounting nvidia files in biarch <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4603>
<mvo> zyga: I was just thinking we could do a strings.Contains("failed", strings.ToLower(string(unsquashfsOutput)))"
<zyga> I mean, the risk is rather small because we check for hashes and the store does validation as well
<mvo> zyga:as a first approximation
<zyga> mvo, a simple "failed" thing works too, yeah
<mvo> zyga: I think I will do that and hope for upstream, once upstram merges it I can SRU it at least into the ubuntu-world
<mvo> zyga: anyway, thanks for the brainstorm :)
<zyga> :-)
 * mvo is also slightly shocked that there is no open upstream bugreport about this
<mup> PR snapd#4604 opened: cmd/snap-confine: create lib/{gl,gl32,vulkan} under /var/lib/snapd and chown as root:root <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4604>
<mborzecki> zyga: ^^ this a workaround for the problem with missing /var//lib/snapd/lib that we had on fedora
<zyga> reading
<zyga> mborzecki one comment
<mborzecki> zyga: uhh right :/ silly me
<Chipaca> pstolowski: want me to add the roundrobin writer to strutil?
<mborzecki> zyga: mvo: is 4604 a 2.31 material too?
<zyga> yes
<pstolowski> Chipaca, no, thanks, I'm on it
<Chipaca> pstolowski: ok
 * Chipaca carries on down the PRs
<mvo> mborzecki: that is only needed for re-exec?
<mvo> mborzecki: and bi-arch? or more generic?
<mborzecki> mvo: bi- and multi- arch, same thing as in #4598 but works around packaging errors
<mup> PR #4598: packaging: create /var/lib/snapd/lib/{gl,gl32,vulkan} as part of packaging <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4598>
<ogra_> mvo, i only tesetd on a pi and it was fine there (on the actual board i'm currently trying to get a grub-uboot implementation going, so have no booting OS atm) ... it was just the typo (and i checked, it wasnt there in a former local iteration of the gadget which explains why it worked before)
<mvo> ogra_: thanks
<mvo> ogra_: fwiw, we are exploring if we can add error reporting for this easily (the general case is harder but we might get away with somehting core specific to catch unknown options)
<ogra_> mvo, that would be awesome
<mvo> ogra_: pr #4600 iirc
<mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
<ogra_> nice round number
 * mvo back to squashfs
<mvo> ogra_: heh, indeed
<ogra_> heh. you too ?
 * ogra_ is banging his head against grubs squashfs implementation on arm
<mvo> ogra_: I am just fixing silly issue around unsquashfs
<ogra_> sadly the u-boot api and grub dont want to play together well ..
<mvo> ogra_: autsch!
<ogra_> would be so nice to have the arm boards read from the snaps diurectly as well ..
<ogra_> (beyond being able to use secureboot from grub)
<mvo> ogra_: oh yes! there were patches for pre-v4 squashfs for u-boot, I guess this never went anywhere? or is the plan to use uboot->grub anyway?
<ogra_> mvo, well, i have to implement a secureboot solution, one option thats known to work is using a uboot.FIT image, but that means essentially all contents of system-boot need to go into a blobby signed image (doesnt work well with split-initrd or de-coupling of any snaps if tehy ship separate parts for system-boot) ...
<ogra_> the other option is grub ... and use signed single files directly from the snaps
<mvo> ogra_: so uboot chainloads to grub?
<mvo> ogra_: that sounds interessting for the main borads as well if this works well
<ogra_> well ... kind of ... uboot keeps running and provides an api to grub ... so it does all the HW heavylifitng ... grub then just uses syscalls to talk to uboot
<ogra_> the prob is the api ... it is a) very young and b) the board i'm currently using has a 2015 u-boot tree as base ... grub works very well until i try to load anything from any disk
<ogra_> so sadly i might have to turn down the idea :/
<ogra_> (i can actually use the loopback feature and list contents of snaps etc ... just the loading explodes completely)
 * mvo nods
 * Chipaca ~> afk (physio)
<mup> PR snapd#4605 opened: snap: detect unsquashfs write failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/4605>
<zyga>  mvo one comment there
 * Chipaca tries again to go to physio
<mvo> zyga: ta
<zyga> mvo nothing strong, just could save (perhaps) some memory
<mvo> zyga: easier to read this way too, I like it
<mvo> zyga: also Chipaca comment is a good one, the amount of output can be huge (because it does not stop and will report and error for every file). so a special writer seems like the better option
<zyga> Cloning into '/home/gopath/.cache/govendor/golang.org/x/crypto'...
<zyga> error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
<zyga> I saw this a few times today
<zyga> brb
<zyga> mvo, can we merge 4576?
<mup> PR snapd#4596 closed: osutil: allow using many globs in EnsureDirState <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4596>
<mup> PR snapd#4606 opened: snap: use custom unsquashfsStderrWriter for unsquashfs error detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/4606>
<mvo> Chipaca: I pushed a potential fix using the custom writer -^
<mborzecki> any idea why snap app services are enabled (but not started) in doLinkSnap() while app socket services are enabled and started in statSnapServices() ?
<oSoMoN> sergiusens, hey, I was talking to Ken about building snaps on 18.04 and he said there's a bug in snapcraft that makes those not run on other ubuntu releases
<oSoMoN> is there a bug report I can subscribe to?
<seb128> sergiusens, he also said you stated you would have it fixed by past-thursday :)
<pedronis> mborzecki: socket services are recent,  where do we start then app services?
<mup> PR snapd#4589 closed: many: remove "content" argument from snaptest.MockSnap() <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4589>
<zyga> Chipaca, I think we should have fewer implementations of mkdirallchown
<zyga> +1 on the patch there but I think we could use the secure variant instead
<zyga> chipaca we could make osutil/secure/ package and stick them there
<mborzecki> pedronis: in 'start-snap-services', but they get enabled in link-snap
<mborzecki> pedronis: the sockets are enabled and started in start-snap-services
<mup> PR snapd#4586 closed: cmd/snap: add completion conversion helper to increase DRY <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4586>
<zyga> Chipaca question on 4581
<pedronis> zyga: what do you mean with empty there?
<zyga> empty byte array
<pedronis> I don't think IÂ understand the question, maybe John will
<zyga> pedronis maybe I misunderstood how that works, I'll talk to john
<pedronis> it's a shortcut, in the case there's no config at all (for any snap) and we are setting to the nil config for this one
<pedronis> there's nothing to do
<pedronis> basically
<zyga> I think I understand that now, snapcfg is the value we want to set, not the data store
<zyga> mvo is 2.31 something that is now living in a branch?
<zyga> I'd like to merge 1st 2.32 PRs that are not ready for 2.31 rc3
<mvo> zyga: 2.31 is in a branch
<mvo> zyga: only cherry-picks
<zyga> excellent
<zyga> I'm chopping various things for sun profiles
<zyga> and trying to figure out how to avoid some duplication and annoying maintenance
<zyga> and since it's not a 2.31 thing anymore I'm doing some improvements to how apparmor backend works
<mvo> zyga: yeah, you can go wild in master
<zyga> cool
<zyga> jdstrand, 4590 needs your +1 then, I'll land the follow-ups on top so that we can see I didn't break what we got working last week
<zyga> and the branches can be nicer when we're not after minimal diffs anymore
<mup> PR snapd#4607 opened: wrappers: cleanup enabled service sockets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4607>
 * Son_Goku sighs
<Son_Goku> I wish people would stop counting on LSM stacking to save their butts
<zyga> hey Son_Goku
<Son_Goku> zyga: hey
 * kalikiana going to have lunch, back in a bit
<pedronis> Chipaca: not super urgent but a review of #4497 would be appreciated
<mup> PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
<pedronis> niemeyer: for later, the PRÂ IÂ mentioned is: #4582
<mup> PR #4582: many: at seeding try to capture cloud information into core config under "cloud" <Created by pedronis> <https://github.com/snapcore/snapd/pull/4582>
<niemeyer> pedronis: Thanks!
<flexiondotorg> zyga: Who can we work with to get snapd updated in openSUSE?
<flexiondotorg> Sadly most desktop application snaps are wearing their sad face when run on openSUSE right now.
<ikey> "lets turn that frown upside down"
<zyga> flexiondotorg me or anyone who will do the packaging
 * ikey remembers his motivational training
<flexiondotorg> zyga: Any chance you could find the time to rev snapd in openSUSE to 2.30?
<flexiondotorg> It's currently 2.27 so doesn't know about the desktop and desktop-legacy interfaces.
<flexiondotorg> ikey: o/
<ikey> \o
<zyga> flexiondotorg let me try tomorrow and if not let's find somoene
<zyga> flexiondotorg I have opensuse ready and booted, just some higher priority things
<zyga> flexiondotorg we don't have anyone on it that's dedicated
<zyga> flexiondotorg I can review PRs to that repo
<flexiondotorg> Thanks zyga
<Chipaca> mvo: indeed partial writes make this a lot harder
<Chipaca> mvo: sorry :-) i'll still get something up for you to look at in case you like it
<mvo> Chipaca: yeah, its a bit annoying
<mvo> Chipaca: sure, happy to have a look how you solved it
<mvo> Chipaca: that reminds me, my test case needs an upper case "Failed to..."
<mup> PR snapd#4582 closed: many: at seeding try to capture cloud information into core config under "cloud" <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4582>
<kalikiana> re
<Chipaca> mvo: https://pastebin.ubuntu.com/26524851/ -- i'm not at all sure this is actually simpler (but i know how to make it more complex :) )
 * Chipaca -> school run
<mvo> Chipaca: in a meeting right now, let me read it but thanks a bunch for looking into this in any case
<mvo> Chipaca: it looks a bit shorter at least
<zyga> jdstrand hello, how was your flight home/
<jdstrand> zyga: uneventful :)
<jdstrand> zyga: I saw the request for 4590 re-review
<zyga> just as it should be
<jdstrand> zyga: exactly :)
<zyga> I didn't do the full thing there, just added your FIXME comments
<zyga> and confirmed with mvo that release is branched off and can merge things
<zyga> I'm chopping my sun profile work into smaller pieces now
<jdstrand> cool
<jdstrand> let me look at 4590 real quick then
<zyga> cool, thanks!
<zyga> oh ... cooooool :)
 * zyga just realised something very useful :)
<pedronis> Chipaca: did you do anything about saving screenshots on install? or still pending
<Chipaca> pedronis: that's phase 2
<Chipaca> pedronis: and requires answers to Questions
<pedronis> Chipaca: phase 2 of what?
<Chipaca> pedronis: of snapshots
<Chipaca> pedronis: phase 1 is just manual
<pedronis> Chipaca: I said screenshots, not snapshots
<pedronis> something discussed in NYC
<Chipaca> pedronis: questions such as "if you snapshot rev2 and upgrade to rev3 and restore what do you even restore"
<Chipaca> pedronis: /o
<Chipaca> pedronis: I did nothing about any metadata
<pedronis> ok, thx
<Chipaca> icons, screenshots, title, description, etc etc etc
<Chipaca> all the same bag imo
<pedronis> Chipaca: because we had some discusions about saving more, saving differently, right?
<pedronis> but hasn't happend, ok
<Chipaca> pedronis: we decided those for all attributes that were per snap not per rev the store is authoritative, and we should keep a cache locally
<Chipaca> correct, no progress
<kyrofa> pstolowski, Chipaca, yeah I got nothing on the *json.RawMessage
<Chipaca> kyrofa: thank you for reminding me :-D
<pstolowski> :)
<Chipaca> niemeyer: in configstate/config we use *json.RawMessage everywhere instead of json.RawMessage. Why?
<Chipaca> niemeyer: (asking you because git blames you)
<mvo> Chipaca: he is in a meeting
<Chipaca> mvo: i am in no rush :-)
 * cachio__ lunch
<mup> PR snapd#4608 opened: cmd/snap-confine: allow snap-update-ns to chown things <Created by zyga> <https://github.com/snapcore/snapd/pull/4608>
<zyga> jdstrand can you please look at ^^
<zyga> it's a two liner
<jdstrand> zyga: done
<zyga> mvo ^
<zyga> I'll work on updates to the tests to check relevant new features as a user, just ran into this by dogfooding
<niemeyer> Chipaca: Heya
<niemeyer> Chipaca: There is/was a serious bug about it in the json package
<niemeyer> Chipaca: It misbehaves wildly in some situations
<Chipaca> ah
<Chipaca> niemeyer: i see
<niemeyer> Chipaca: Let me see if I can find some quick info
<Chipaca> niemeyer: i use json.RawMessage directly in snapshots; let me know if i'll get bitten
<Chipaca> niemeyer: or taht :-D
<niemeyer> Chipaca: https://github.com/golang/go/issues/14493, probably
<pedronis> ah, that
<zyga> + systemctl stop snapd.service snapd.socket
<zyga> Job for snapd.service canceled.
<Chipaca> niemeyer: it's fun reading through that issue how people flip from "meh" to "WTF LETS FIX THIS" as they forget and then get bitten and waste time trying to figure it out
<Chipaca> niemeyer: OTOH, it's fixed, so Â¯\_(ã)_/Â¯
<zyga> so "it will be out in debian 10"
<zyga> in X years
<Chipaca> zyga: it's not go's fault ubuntu always ships a go that is no longer supported by them
<Chipaca> much as it irks me, it really isn't :-)
<Chipaca> and this particular bug has been fixed since 1.8, which is a year old already
<Chipaca> zyga: what do you mean with "fewer implementations of mkdirallchown"?
<zyga> Chipaca we have one in snap-update-ns that's tailored for security
<Chipaca> zyga: ahh... i forget
<Chipaca> zyga: I can take on unifying those two
<Chipaca> i see no reason not to use the securer one everywhere :-)
<zyga> yeah
<zyga> how does osutil/secure sound?
<zyga> those would require jamie review to change
<zyga> but we could just move the current code there first
<zyga> have a look, maybe something about it is silly and unreasonable, maybe not
<Chipaca> zyga: sounds like a good, reasonable plan
<Chipaca> zyga: but, going back a bit, you said "+1 to my changes there", but didn't actually +1 :-D
<zyga> I will add secure symlink next, definitely this week
<zyga> oh, sorry
<zyga> looking
<Chipaca> :-)
<Chipaca> zyga: also your comment on #4581 feels reviewish but doesn't have a +1 either
<mup> PR #4581: overlord/configstate/config: make SetSnapConfig delete on empty <Created by chipaca> <https://github.com/snapcore/snapd/pull/4581>
<Chipaca> zyga: #4587 is the other one fwiw
<mup> PR #4587: osutil: make MkdirAllChown clean the path passed in <Created by chipaca> <https://github.com/snapcore/snapd/pull/4587>
<mup> PR snapd#4581 closed: overlord/configstate/config: make SetSnapConfig delete on empty <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4581>
<mup> PR snapd#4587 closed: osutil: make MkdirAllChown clean the path passed in <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4587>
<Chipaca> yuss
<niemeyer> Chipaca: Yeah, it's fixed.. we just need to check if all the versions of Go we care about are fixed too
<niemeyer> Chipaca: I would guess not
<Chipaca> niemeyer: 1.8+
<niemeyer> Yeah, so risky still
<Chipaca> I'll update snapshots to use *json.RawMessage for now then
<Chipaca> as part of the rebase
<Chipaca> just one more pr to land for that to happen :-)
<zyga> Chipaca one question posted on 4585
<Chipaca> zyga: i confess to not understanding your question :-(
<Chipaca> zyga: care to expand it a little bit?
<zyga> sure
<zyga> sorry about tyhat
<zyga> is there any practical difference between using `inst` there? (instead of the current code that does `&inst`)
<zyga> inst is a function anyway, right?
<Chipaca> zyga: no, inst is the instruction, a thing sent by the user that got decoded a little bit further up
<Chipaca> zyga: op is the function
<zyga> ah, sorry then
<Chipaca> zyga: you couldn't do &foo if foo was a function
<Chipaca> afaik
<Chipaca> ah yes you can
<Chipaca> eh
<pstolowski> Chipaca, no run-hook in snap topical tasks
<Chipaca> pstolowski: i know it's not there currently; should it be?
<Chipaca> pstolowski: or does hookstate have its own conflict thing?
<Chipaca> I suspect you can currently install, remove, refresh snaps that are in the middle of running a hook
<mup> PR snapd#4609 opened: interfaces/apparmor: use a helper to set the scope <Created by zyga> <https://github.com/snapcore/snapd/pull/4609>
<zyga> Chipaca ^
<Chipaca> ack
<Chipaca> zyga: currently looking at one for bboozzoo
<zyga> thanks!
<kalikiana> grrr, python env mocking is tedious
<kalikiana> will have to finish that tomorrow
<zyga> mocking environment?
<zyga> just mock os.environ and os.getenv (probably?)
<kalikiana> zyga: I'm trying to check that a variable is unset via `assert_has_calls` which by default expects my actual env. So I mocked `os.environ` with a {} stanza. Except other calls that aren't related to this now return magic mock values for variables I'm *not* setting there
<kalikiana> Somehow the almost-empty mock env has values in it that I did not set
<pstolowski> Chipaca, hookmgr has a SetBlocked handler which only prevents other hooks from running (there can be one hook at a time). but what you're asking seems entirely possible unless I'm missing something...
<zyga> mocking is tricky, perhaps the import path matters, you may see unmocked environment depending on "how" you look (what's the imported object)
<kalikiana> zyga: Like MagicMock<name=environ.get() id=12345>
<zyga> how did you mock environ?
<kalikiana> Those are the values that show up in other places now
<kalikiana> zyga: patch('os.environ')
<zyga> is anything importing environ locally? patch has its limits as to what it can reference
<kalikiana> zyga: there's os.environ.copy, which works as expected with my {} value. the other code is using os.getenv
<pstolowski> Chipaca, so yes, maybe run-hook should be there. I can look take this
<kalikiana> zyga: the os.getenv seems to be getting those MagicMock values now
 * zyga dinner
<pedronis> Chipaca: are you adding changes that run only hooks?  so far  hooks are taken care by other conflicts, because usually there are other tasks that will conflict
<pedronis> like link-snap
<pstolowski> pedronis, but link-snap can be Done, and configure snap runs afterwards
<pedronis> pstolowski: no
<pedronis> the normal conflict logic
<pedronis> is about full changes
<pedronis> not single tasks
<pedronis> (unless it was changed recently)
<kalikiana> elopio: in case you happen to have any ideas on that... ^^ otherwise I'll be digging in the docs tomorrow morning over my coffee
 * kalikiana wrapping up for today
<zyga> kalikiana I can tell you why this happens
<zyga> and perhaps how to fix it
<zyga> tomorrow would be best :)
<pedronis> pstolowski: it's not about link-snap being done, it's about the full change that has link-snap in it being done
<kalikiana> zyga: Awesome. Let's chat tomorrow then
<pstolowski> pedronis, ah oh you'r right
<pedronis> pstolowski: your new code is a bit different (different tradeoffs there)
<pedronis> and concerns onyl connect/disconnect
<pstolowski> pedronis, yes, that's what put me on a wrong track
<pstolowski> so yeah, we should be good, sorry for confusion Chipaca
<Chipaca> pstolowski: now i'm wondering about configure hooks
<pedronis> they might die, saying that snap is not there anymore I suppose
<pedronis> Chipaca: we dont' seem to do conflict checks around configure/Configure
<pedronis> so there might be an issue there
<pedronis> in some corner cases
<niemeyer> Stepping out for a while
<mup> PR snapd#4609 closed: interfaces/apparmor: use a helper to set the scope <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4609>
<mup> PR snapd#4608 closed: cmd/snap-confine: allow snap-update-ns to chown things <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4608>
<zyga> Chipaca small follow-up if you want to look
<zyga> jdstrand ^
<zyga> jdstrand this is what it would look like, interfaces could now add sun snippets
<mup> PR snapd#4610 opened: interfaces/apparmor: early support for snap-update-ns snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/4610>
<zyga> jdstrand we could even use it to reduce permissions on snap-update-ns (the base set0
<zyga> so even things like content interface would be explicit
<zyga> jdstrand if you can look at that (design, not security related) and +1 that I'll carry on with the backend parts that generate it
<zyga> jdstrand and obviously the layout parts
<jdstrand> zyga: ack
<mup> PR snapd#4585 closed: daemon: refactor snapFooMany helpers a little <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4585>
<kyrofa> jdstrand, dumb question: can you give me a use-case for the fuse-support interface?
<kyrofa> jdstrand, someone is suggesting we add it to the nextcloud snap, but I'm not certain I understand what it does
<jdstrand> kyrofa: fuse allows you to mount userspace filesystems: https://www.kernel.org/doc/Documentation/filesystems/fuse.txt
<jdstrand> kyrofa: the interface has a number of limitations. it would be best to understand the specific use case the request is trying to support
<kyrofa> jdstrand, I haven't quite figured that out, yet. I'll get back in touch once I have a better picture
<kyrofa> jdstrand, looks like someone is `rclone mount`ing into the data dir and hoping Nextcloud can use it
<jdstrand> kyrofa: the interface allows for performing the mount, not consuming one
<jdstrand> I suggest instead the bind mount unit I'm doing, or perhaps the content interface
<kyrofa> jdstrand, so what, use fuse for another directory, and bind-mount that one into the snap?
<jdstrand> I was saying skip fuse altogether. perhaps what you said would work
<kyrofa> jdstrand, yeah fuse might be the only way rclone supports this type of thing (not sure). I'll suggest they try that
 * jdstrand has never used rclone
<kyrofa> Me neither
<jdstrand> kyrofa: it might be interesting to see the denials that nextcloud pops out when they fuse mount something into nextcloud's SNAP_DATA or SNAP_COMMON (that is how I understood your use case anyway)
<kyrofa> Indeed, my understanding as well. I'll ask
<el_tigro1> I'm trying to gain a better understanding of snaps and I have a couple of questions that hopefully someone can answer
<kyrofa> Hey there el_tigro1, welcome!
<kyrofa> Fire away
<el_tigro1> My understanding is that each snap runs in its own mount namespace. So grabbed the PID dockerd (running as a snap) and decided to have some fun with nsenter "sudo nsenter -t <docker_pid> -a bash". If I understand correctly I'm within the dockerd processe's mount namespace, and the filesystem root is ubuntu core
<el_tigro1> kyrofa: thanks
<kyrofa> el_tigro1, indeed, that's my understanding as well
<kyrofa> (if by "ubuntu core" you mean "the core snap")
<el_tigro1> yes that's what I mean
<el_tigro1> So I guess the "pivot_root" system call was used to change the root filesystem?
<el_tigro1> Then from within the namespace, I did "mount -l" to see what is mounted and I can see that the parent namespace's filesystem is mounted read/write on "/var/lib/snapd/hostfs"
<el_tigro1> Doesn't that mean that the dockerd process has read/write access to the parent root filesystem? I'm kind of confused because I thought one of the main purposes of snaps was to sandbox the process
<kyrofa> el_tigro1, note that there are _several_ aspects to this "sandbox"
<kyrofa> el_tigro1, snaps are also confined with apparmor, which will deny any access to that area
<kyrofa> el_tigro1, seccomp is also part of the story, which covers syscalls
<kyrofa> el_tigro1, every `plug` declared by the snap is essentially a snippet of apparmor and allows syscalls
<kyrofa> s/allows/allowed/
<el_tigro1> kyrofa: thanks that makes sense
<kyrofa> el_tigro1, the new rootfs isn't even really part of the security story-- it's part of the "run the same way everywhere" story
<el_tigro1> kyrofa: so I can access that mountpoint from the nsenter shell because the apparmor profile and seccomp are obviously not applied in this case
<kyrofa> Indeed
<kyrofa> el_tigro1, try this
<kyrofa> Install a snap that has an application available to run. I assume the `docker` snap has the `docker` command... right?
<el_tigro1> yes
<kyrofa> el_tigro1, run `snap run --shell docker`
<kyrofa> el_tigro1, instead of running the docker command, it'll give you a shell with the exact same confinement as that command
<kyrofa> el_tigro1, basically what you've already done, but it gives you a clearer picture of what kind of access docker has
<el_tigro1> kyrofa: WOW, very cool
<mup> PR snapd#4611 opened: overlord/configstate/config: make [GS]etSnapConfig use *RawMessage <Created by chipaca> <https://github.com/snapcore/snapd/pull/4611>
<el_tigro1> I'm so happy I just learned that "trick"
<kyrofa> el_tigro1, super handy when debugging as well
<el_tigro1> I have another question related to snaps/lxc/zfs. Could be a bit trickier though
<kyrofa> Hit me. If I can't answer someone here will
<el_tigro1> ok. So I have 2 lxc containers running using 2 different images (centos and ubuntu), both using the default zfs pool. In the parent namespace, I do "zfs list" and can see (using "zfs get all <VOLUME>") that both images have mountpoints and are mounted. The container volumes on the other hand have mountpoints but are NOT mounted. Makes sense so far since the container volumes are mounted within the lxc snap's namespace
<zyga> hey el_tigro1
<zyga> I didn't read the backlog but if you have any questions about the execution environment I'm happy to provide answers
<zyga> (mount namespaces and how they are set up)
<el_tigro1> zyga: thanks a lot!
<zyga> jdstrand so... any direction?
<el_tigro1> I decide to have some more nsenter fun so I grab the PID of the lxcfs process, and do "nsenter -t <lxcfs_pid> -a bash" and now i'm in the lxd snap's mount namespace. I do "df -T" and for some reason I see a mount for each image, and 1 mount for the ubuntu container, but NO mount for the centos container!
<el_tigro1> Here's the line for the ubuntu container's zfs volume mount:
<el_tigro1> "default/containers/juju-ade8fe-0                                                zfs       12882432   774784  12107648   7% /var/snap/lxd/common/lxd/storage-pools/default/containers/juju-ade8fe-0"
<el_tigro1> yet my centos container is running, and I can get a shell in it with "lxc exec <centos_name> bash"
<__chip__> zyga: could you take a look at #4611 please? should be relatively easy
<mup> PR #4611: overlord/configstate/config: make [GS]etSnapConfig use *RawMessage <Created by chipaca> <https://github.com/snapcore/snapd/pull/4611>
<zyga> yes
<__chip__> ta
<zyga> ah, this
<__chip__> :-)
<el_tigro1> kyrofa: what I'm saying is probably poorly explained or doesn't make much sense  :D
<zyga> can you look at https://github.com/snapcore/snapd/pull/4610 ? mabe jamie will look and I can land it
<mup> PR #4610: interfaces/apparmor: early support for snap-update-ns snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/4610>
<__chip__> zyga: yes
<__chip__> el_tigro1: maybe you want stgraber ?
<kyrofa> el_tigro1, hmm, you're right, this is a little beyond me and more specific to lxd. stgraber is the guy you want here
<zyga> el_tigro1 I can answer any question about how snapd use mount namespaces
<zyga> el_tigro1 though I'm not an expert on lxc/lxd which can do its own things
<kyrofa> __chip__, are you like Neal, changing your nick every once in a while to keep people on their toes?
<__chip__> kyrofa: I have different defauts on different boxes
<potato> I need to ... shave!
<potato> *ha*
<zyga> MBUAHAHAHA
<potato> ohhh
<potato> darn
<elvis> __chip__ let's swap nics for 24 hours ;)
<__chip__> kyrofa: I also have Chipakeitor as a fallback
<kyrofa> Haha
<kyrofa> At least you always type the same way
<__chip__> kyrofa: I used to have BeerServ as well, but then they got all "you can't pretend to be a network service"
<kyrofa> Really.
<__chip__> yes
<__chip__> so I keep expecting them to implement an _actual_ BeerServ
<kyrofa> That's what that means to me as well
<__chip__> maybe it's for admins only
<kyrofa> They probably have one, but only to employees
<kyrofa> Yeah
<__chip__> zyga: why is spec.sunSnippet a map[string]map indexed by spec.sunSnippetName?
<__chip__> zyga: if the map's only ever going to have one entry seems daft
<zyga> sunSnippetName?
<__chip__> ehm
<__chip__> snapName
<zyga> right
<zyga> so
<zyga> I think you are right
 * __chip__ 's waiting for the "but..."
<zyga> I think it could be just a layout thing, the spec is in the repo
<zyga> created in the repo
<zyga> there's no but here, I just made it obvious that there is a thing there
<zyga> and if that changes it's not a bug that's quirky
<zyga> though I a gree
<zyga> *agree
<zyga> I think that the scope idea, once improved, could help to make that cleaner, I didn't think that through though
<__chip__> zyga: I'm not sure if it's a bug that you'd keep the sunSnippet for other scopes alive around setScope invocations
<zyga> so yes, there's going to be a few calls
<zyga> but they will all come from one snap
<zyga> so that's why I'm saying you are right that we could perhaps drop the map entirely
<zyga> the good thing is that it doesn't matter for interfaces, just for the backend
<__chip__> zyga: should I +1 this, or should I wait a bit?
<zyga> __chip__ if you mentally +1 and tell me I'll land it when jamie approves
<zyga> just say what you think, no rush
<__chip__> zyga: I mean, I can +1 this as it stands, and my +1 is still valid if you pare down the map
<zyga> ok
<__chip__> zyga: should i do that?
<zyga> yeah
<zyga> omg, sublime text is awesome :-)
<nacc> if I was to use SNAPCRAFT_CONTAINER_BUILDS=1 instead of cleanbuild, and I'm buillding froma  git repository; will `snapcraft` correctly detect my changing branches and needing to change what was put in the container? Or will I need to add some git hooks to remove the container when the branch changnes?
<kalikiana> nacc: the container uses the files straight from your repository, they're not copied - assuming I got your question right
<nacc> kalikiana: they are bind mounted in?
<nacc> kalikiana: how would that work with a remote lxd??
<jdstrand> zyga: I've not been able to look at it yet-- lots of pings and store stuff
<kalikiana> nacc: in that case it's mounting via sshfs
<nacc> kalikiana: magic! :)
<kalikiana> nacc: Yeah :-D bit of a pain to make it work behind the scenes, but awesome when it works
<nacc> kalikiana: ok, so basically cwd's conntents are reflected to the container -- what if that resultls in buildl-deps changing? they willl get built if need be, right? (e.g., a part versionn changed in a branch)
<kalikiana> nacc: same as a "normal" build. the only difference it builds/installs in the container
<nacc> kalikiana: cool, thanks1
<kalikiana> nacc: lemme know how it goes when you try it. I'm always interested in feedback, good or bad
 * kalikiana happens to be the person implementing that feature
<nacc> kalikiana: what happens if multiple builds go on at the same time with S_C_B=1 ?
<kalikiana> nacc: each project (read: source folder) will use its own container
<nacc> kalikiana: right, but if you have two branches in the same git repo
<nacc> they will end up sharing hte container?
<kalikiana> nacc: since you can only checkout one branch at a time, yes
<nacc> kalikiana: not entirely true with work trees :)
<nacc> kalikiana: but yeah ok
<kalikiana> nacc: work trees?
<nacc> kalikiana: `man git-worktee`
<nacc> *`man git-worktree`
<nacc> let's you checkout multiple working trees simultaneously
<kalikiana> hmmm interesting. never used that
<nacc> kalikiana: yeah, it's new-ish
<nacc> really handy for some cases
<kalikiana> nacc: if it's for testing purposes, you could change the name in snapcraft.yaml to get a different container
<nacc> but our use case is that we've added a self-test to our snap for as-snapped testing
<nacc> so our CI builds the snap and then runs that app
<nacc> that build is a bit slow, and most of it is the same between snaps
<kalikiana> yeah. builds would be faster this way, compared to cleanbuild
<kalikiana> just keep in mind that changes in parts will still require you to clean those parts
<nacc> ack
<zyga> jdstrand ack
#snappy 2018-02-06
<mup> PR snapcraft#1915 closed: snap: patch ctypes for the snap <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1915>
<thomi> niemeyer: Oh! I didn't realise I had edit rights to that post myself, or I would have just edited it directly, sorry :D
<niemeyer> thomi: All good! I was still tuning it nevertheless, but yeah, if you want to tweak in the future feel free
<niemeyer> and the magic happens ... https://snapdocs.labix.org/getting-started/3876
<thomi> nice
<mup> PR snapcraft#1912 closed: lxd: unset SNAP to work-around LXD deb thinking it's a snap <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1912>
<niemeyer> Forum going down for maintenance.. assume impact position please.
<niemeyer> Forum is back up
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: mvo_: hey
<mvo_> hey mborzecki - good morning
<zyga> hey guys
<mvo_> hey zyga
<zyga> hey :-)
<mup> PR snapd#4611 closed: overlord/configstate/config: make [GS]etSnapConfig use *RawMessage <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4611>
 * zyga iterates on the feedback from jamie
<zyga> jdstrand thank you :)
<zyga> oh, I have a conflict to resolve first
<mup> PR snapd#4604 closed: cmd/snap-confine: create lib/{gl,gl32,vulkan} under /var/lib/snapd and chown as root:root <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4604>
<mup> PR snapd#4612 opened: snap: exclude `gettimeofday` from `snap run --strace` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4612>
<kalikiana> sliff
<pstolowski> good morning!
<zyga> hey pawel
<mvo_> hey pstolowski !
<zyga> mvo_ 4590 is now ready, I pushed some WIP patches by accident but they are gone now
<zyga> I'll add a spread test before jumping into sun profiles more
<mvo_> zyga: ta
<kalikiana> o/ pstolowski
 * kalikiana coffee
<zyga> jamesh hey
<jamesh> zyga: hi
<zyga> I wanted to catch up with you
<mborzecki> pstolowski: morning
<zyga> how is that branch, I saw jamie gave you a review, are you just waiting on a re-review from him?
<zyga> I also wanted to give you an update on some of the work I'm doing that intersects (though I don't anticipate any problems)
<zyga> we will soon have per-snap profiles for snap-update-ns
<ackk> mvo_, hi, was the updated base-18 with distro-data built?
<zyga> (apparmor profiles that is)
<jamesh> zyga: I still need to get the mountinfo stuff working: I had other things on my plate on Friday, and was flying home on Monday
<mvo_> ackk: it was, iirc it was sitting in the review queue, we need to poke jdstrand about accepting the updated base-18 snap
<ackk> mvo_, oh, I see
<zyga> jamesh did my suggestion help you in any way?
<jamesh> zyga: I still need to think it over a bit more.  I wasn't even looking at the device numbers before.
<zyga> okay
<zyga> my changes for per snap s-u-n profiles will touch snap-confine a little and mostly the backend code
<zyga> there will be some new logic before running s-u-n from C
<zyga> the idea behind sun profiles is that they can be tailored to the given snap and describe the operations we anticipate to perform
<zyga> so that s-u-n doesn't have to carry very broad write and mount permissions
<zyga> jamesh when do you think your branch will be ready for re-review?
<jamesh> zyga: well, I need to be able to add the check jdstrand requested, which so far I haven't been able to implement
<zyga> jamesh ok, I'll look at that part, maybe I can help somehow
<zyga> jamesh do you mind if I push there directly?
<zyga> woot, 4590 is ready for 2nd review
<zyga> ~100 diff
<zyga> (and most of that is in apparmor which was acked by jamie)
<zyga> anyone? :)
<zyga> hey Chipaca
<Chipaca> moin moin
<zyga> Chipaca maybe I can grab you for a 2nd review of about 100 lines
<zyga> https://github.com/snapcore/snapd/pull/4590
<mup> PR #4590: many: allow constructing layouts (phase 1) <Created by zyga> <https://github.com/snapcore/snapd/pull/4590>
<mup> PR snapd#4613 opened: release: snapd 2.31 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4613>
<Chipaca> zyga: missed your message before, looking now
<zyga> thank you
<Chipaca> fmt's widths and precision are pretty messed up
<mup> PR snapd#4614 opened: data/systemd: for debugging/testing use /etc/environment also for snap-repair runs <Created by pedronis> <https://github.com/snapcore/snapd/pull/4614>
<pedronis> mvo_:   ^ trivial fix/tweak to snap-repair  service unit
<mvo_> pedronis: looking
<mvo_> pedronis: ta
<zyga> have we tested repairs for real yet?
<pedronis> zyga: no, they have been tested in staging,  it's been 2nd highest prioritity thing for a while though,  next weeks might be the charm though
<zyga> cool, it's a very important thing to see work as it can save our skin one day
<pedronis> zyga: anyway that PR is the result of me trying to reload state about them
<pedronis> zyga: it's also been delayed by meltdown/spectre, as many other things
<zyga> yeah, timing is not on our side
<ikey> do you guys regret picking go yet? :)
<pedronis> ikey: instead of?
<ikey> i mean in general
<ikey> seems to me the lower down you go with go the more ugly warts are there waiting to be found
<mup> PR snapd#4614 closed: data/systemd: for debugging/testing use /etc/environment also for snap-repair runs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4614>
<mup> PR snapd#4615 opened: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615>
<mborzecki> ikey: how far down?
<ikey> mborzecki, process level attributes and sandboxing
<ikey> namespaces, etc
<ikey> (also process vs thread)
<ikey> sorta stuff we ran into with solbuild in solus, kinda assumed similar brick walls would be hit and worked around with snapd
<mborzecki> right, that doesn't work so well (at all) in go
<ikey> then again i suppose the flipside is not dealing with berkley sockets :]
<pedronis> it mostly affects snap-confine though (wich now is split between C and go helpers)
<ikey> ah so thats why its split, makes sense
<ikey> so the design is more like "bootstrap environment and then exec" in a sense?
<zyga> yes
<zyga> and actually, we managed to move a lot of it to go now
<ikey> neat way of doing it :]
<zyga> snap-update-ns and snap-confine do stuff together
<zyga> and we can move much more to go
<ikey> oh nice
<pedronis> otherwise we mostly hit issues with go threads and exec
<zyga> there are just a handful of things that cannot be done from go
<ikey> yeah go threads are.. special
<zyga> (where C pre-go code doesn't count as "go" ;-)
<mborzecki> there are workaround those
<mborzecki> i mean, iirc libcontainer is all go right?
<ikey> huh spose yea
<mborzecki> probably quite a lot of (un-)lockosthread and maxprocs fun
<ikey> yea
<mborzecki> not that i would like to do it though :)
<ikey> but ofc. :D
<ikey> i think the most evil go issue i had wasn't actually go's fault, cgo/xz
<pedronis> the other issue is that go moves faster than some distros (this one we haven't tackled but probably should somehow)
<ikey> i suspected i had a memory leak but my peanut gallery training told me that nope, that memory will get returned, its just virtual memory
<mborzecki> oh and we haven't done anything with go assembly, which is quite nice actually :)
<ikey> that was until it OOM'd with 30GB used
<ikey> hadn't heard about go assembly, gonna have to google it
<mborzecki> ikey: try this https://talks.golang.org/2016/asm.slide
<zyga> mborzecki note that even with those some things just cannot be done in go (several syscalls require you to have ever only had one thread in a process)
<ikey> mborzecki, danke
<mborzecki> zyga: hm i wonder if that couldn't be doen with GOMAXPROCS=1 and LockOsThread in init()
<ikey> o cheeky
<zyga> no
<zyga> we tried
<zyga> go does stuff in library initialization
<ikey> go needs a -pleasebelikec flag lol
<zyga> and it's too late then
<zyga> hence the magic in snap-update-ns
<zyga> and the split in general
<ikey> so i assume you just wanna do the bare minimum in C land
<ikey> i.e. what cant be done in go
<ikey> er what cant be done /safely/sanely/ *
<mborzecki> if not c then probably d or rust could be used as alternatives
<zyga> I think we'll stick to C
<mborzecki> provided you can actually build those on older systems
<zyga> no need to introduce a new language for a tiny fragment
<zyga> we really need C for pivot_root and some of the early namespace manipulation
<mup> PR snapd#4590 closed: many: allow constructing layouts (phase 1) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4590>
<mup> PR snapd#4616 opened: interfaces/apparmor: remove leaked future layout code <Created by zyga> <https://github.com/snapcore/snapd/pull/4616>
<mvo_> Chipaca: bad news, powerpc is failing since some days and it looks the change is the addition of the osutil/context.go stuff
<Chipaca> mvo_: can i see?
<zyga> mvo_ is that going to block the release?
<zyga> and do you need my powerpc box?
<mvo_> Chipaca: https://launchpadlibrarian.net/355941418/buildlog_ubuntu-xenial-powerpc.snapd_2.31~rc2+git540.4a4ed58~ubuntu16.04.1_BUILDING.txt.gz
<mvo_> zyga: its just master afaict
<Chipaca> so much "reading database"
<mvo_> Chipaca: silly dpkg
<mvo_> Chipaca: we are getting rid of this ;)
<Chipaca> i thought that was apt
<mvo_> Chipaca: that part is dpkg
<mvo_> Chipaca: or, hold on
<mvo_> Chipaca: yeah, thats dpkg
<Chipaca> zyga: mind if i use your powerpc box?
<zyga> not at all
<zyga> please coordinate with mvo, there's just 1GB ram
<mvo_> Chipaca: the backtrace is not helpful at all
<Chipaca> mvo_: are you going to use zyga's powerpc?
<mvo_> Chipaca: yeah, I was about to. but if you are on it, I will leave it, its almost lunchtime anyway
<Chipaca> mvo_: yeah if it's my context thing it's fair that i bash my head on it
<mvo_> Chipaca: it probably is (this is the merge when the builds start to fail). thanks for looking into it!
 * Chipaca sees a 'if runtime.GOARCH == "powerpc" { throw a fit }' in his future
<Chipaca> zyga: do i have sudo on the ppc box?
<zyga> checking
<zyga> yes
<zyga> you should
<Chipaca> zyga: what i might not have is a password :-)
<zyga> aha :D
<mborzecki> your voice is ..
<Chipaca> .. not what it was
<mborzecki> ha ha :)
<Chipaca> ok, I've seen this error once before and thought it was weird gamma ray thing :-) but this being the second time, I need to bring it up
<Chipaca> + mkdir -p /home/test/snap/test-snapd-tools/6/
<Chipaca> + touch '/home/*/snap/test-snapd-tools/6/mock-data'
<Chipaca> touch: cannot touch '/home/*/snap/test-snapd-tools/6/mock-data': No such file or directory
<Chipaca> what the *what*
<ikey> did you quote the wildcard?
 * Chipaca looks at the test
<Chipaca> ikey: that's a good question :-)
<Chipaca> thank you
<ikey> np
<Chipaca> ikey: although if it was that, it wouldn't fail just sometimes
<Chipaca> still, looking
<Chipaca> ikey: the script actually has
<Chipaca>     mkdir -p /home/*/snap/test-snapd-tools/$rev/
<Chipaca>     touch /home/*/snap/test-snapd-tools/$rev/mock-data
<ikey> o
<Chipaca> it expands the first one, but fails to expand the second one
<ikey> but what.
 * ikey scratches head
<zyga> Chipaca concurrent magic?
<Chipaca> in spread?
<zyga> suggestion: get rid of the * and use a one-time expansion to know what the thing is called
<Chipaca> zyga: in the log above, it logs it expanded
<zyga> hmm hmm
<pedronis> Chipaca: you have  '' there
<pedronis> so no * expansion
<pedronis> afaict
<ikey> looks like the set +x escape put the ' in
<pedronis> Chipaca: it might also be, the file doesn't exist, so it doesn't expand
<pedronis> there's no match for that
<Chipaca> hmmmm
<pedronis> but then why it works for the dir
<Chipaca> gasp
<Chipaca> bah
<Chipaca> I'm going to push a PR that changes the test, dunno why we're using a * but it's hard to think about
<Chipaca> meanwhile restarting this individual run should be good enough for now
<Chipaca> thanks
<pstolowski> pedronis, hey, struggling a bit with autoconnect test based on content interface, policy check prevents autoconnect, what to do in my mocked snaps to make it happy?
<pedronis> pstolowski: where are you writing the test?
<pstolowski> pedronis, in overlord/managers_test.go
<pedronis> pstolowski: you need to setup snap declarations from the same publisher, we should have some tests like that there
<pstolowski> pedronis, thanks, looking
<pedronis> pstolowski: it's mostly tedious and long
<pedronis> there are some helpers though
<pedronis> I think
<cachio_> mvo_, hey, unit tests failing in the PR which is removing gettimeofday
<zyga> - Download snap "test-snapd-control-consumer" (2) from channel "stable" (Get https://api.snapcraft.io/api/v1/snaps/download/a8xXlpZKNsesIzT1wxZ4kP0DaCzeDUtj_2.snap: dial tcp 91.189.92.19:443: i/o timeout)
 * zyga restarts
<Chipaca> mvo_: there are many changes in debian/ between what I get via apt, and git
<Chipaca> mvo_: to the point where dpkg-buildpackage from master doesn't work
<mvo_> Chipaca: what version do you get via apt?
<mvo_> Chipaca: try "apt build-dep ./" if build-deps are missing
<Chipaca> mvo_: snapd-2.29.4.2
<mvo_> Chipaca: or are vendor/ dirs missing?
<Chipaca> mvo_: I did, nothing new brought in
<mvo_> Chipaca: what is the failure?
<Chipaca> mvo_: oh i thought dpkg-buildpackage does that?
 * Chipaca does that
<Chipaca> govendor does _not_ like ppc
<Chipaca> powerpc*
<Chipaca> I can't even install govendor :-(
 * Chipaca copies his vendor tree from a reasonable architecture
<pstolowski> pedronis, ok, i see store signing stack is already created in managers_test; it will work if I install snaps via InstallPath and with devmode provide correct SideInfo?
 * zyga found a CD with the doors in one of the boxes yesterday
 * zyga never listened to that
<Chipaca> zyga: the doors! (beep tweedle bip bip)*
<zyga> it sounds nice
<Chipaca> zyga: talk to me when your beep-tweedle-bip-bip counter reaches 10k
<Chipaca> mvo_: it was the vendor tree missing that was thwarting me, silly me, and thank you
<mvo_> Chipaca: happy that it works now
<mup> PR snapd#4617 opened: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617>
<Chipaca> mvo_: hmm. I think you dropped these from around a word there: ââ
<Chipaca> but hey the package is building :) so that's something
<zyga> hmm hmm lunch time
<mup> PR snapcraft#1916 opened: lxd: initialize remote lazily <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1916>
<Chipaca> hmm, gccgo doesn't seem to find things from vendor/
<ackk> hi, I have a snapcraft question: I'm including a python lib from a deb via stage-packages, but the resulting library in the snap seems laid out differently. does snapcraft do anything special?
<ackk>  kalikiana, ^ perhaps you can help?
<pedronis> pstolowski: yes, it should work with SideInfo
<pstolowski> pedronis, thanks, got it working!
<mborzecki> pstolowski: should i restart the travis job in 4584 or will you be pushing more patches to that branch?
<ikey> sadface. looks like snap mounts are regressing my boot
<ikey> blocks early boot: https://ibin.co/3qlqeUao9o5w.png
<pstolowski> mborzecki, yeah, pls restart, thanks, no more commits
<kalikiana> ackk: can you be more specifc? in what sense are the files laid out differently?
<mborzecki> anyone feels like looking at #4615?
<mup> PR #4615: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615>
<ackk> kalikiana, I think I found the issue, locally I have a deb which is more recent than the one in the repo, but snapcraft pulls deb from the archive directly, so it's using a different version fro the one installed locally
<ackk> kalikiana, if I copy my updated deb in .cache/snapcraft/...... will it pick the latest?
<ackk> kalikiana, or does it only use what's in the archive
<zyga> ikey idea: use auto mounts
<ikey> ?
<zyga> ikey they will start only when accessed
<ikey> these are the mount units written by snapd
<ikey> not me
<zyga> 3 min
<zyga> yes
 * ikey blinks
<zyga> it would be a patch
<ikey> oh you mean patch it to mungle it
<ikey> hm
<ikey> could do yeah
<zyga> *chew chew*
<zyga> sorry, I stuffed a sandwitch into my mouth to type
<zyga> so
<zyga> systemd can do that mount lazily by installing an automount unit
<zyga> I believe it's a tiny one word patch in each .mount unit
<zyga> do an experiment
<zyga> let me tell you ...
<zyga> add x.systemd-automount to mount options
<zyga> just edit those mount units and change that
<zyga> and reboot
<zyga> aww, systemd needs foo.automount as unit name
<zyga> but maybe the option will be sufficient
<zyga> (option in a mount unit)
<zyga> ah wait
<zyga> no
<zyga> so reading systemd.automount
<zyga> keep the mount units
<ikey> right
<zyga> just add a .automount unit next to vanilla mount units
<zyga> so if you do that experiment and it works we can consider that as a feature to add
<zyga> it would be nice as it would help boot time and also improve memory use
<ikey> yeah
<ikey> not having every possible snap mounted unless it needs to be
<zyga> yep
<zyga> I believe we could also do automatic deactivation so they would go away over time, when unused
<zyga> maybe there are dragons (because it's tricky what we do) but worth a check
<ikey> aye
<mborzecki> zyga: TimeoutIdleSec= ?
<zyga> yeah
<mborzecki> right, doesn't look like too much work
<kalikiana> ackk: Hmmm why do you have a different version? Do you want to use the local version? You could specify the .deb file in that case
<ackk> kalikiana, yes I wanted to user the newer version I have installed. So, I can specify the path to a deb file instead of just the name in stage-packages?
<kalikiana> ackk: You can use a part with plugin: dump and source: foobar.deb
<kalikiana> ackk: The files will be extracted relative to the part ie. ./usr/bin/foobar
<ackk> kalikiana, does this work for libs too?
<kalikiana> ackk: Sure
<ackk> kalikiana, thanks, TIL
<Chipaca> ikey: zyga: in my experience automount is a pain in the pudenda
<Chipaca> ikey: zyga: maybe you can get the same effect by giving snap .mounts a reasonable After=?
<ikey> possible
<Chipaca> mvo_: so, I have a super easy way for tests to pass on powerpc
<Chipaca> mvo_: (beyond "skip this test" :-)
<Chipaca> but â¦ hmm
<zyga> Chipaca after=5 minutes ;-)
<Chipaca> mvo_: i suspect gccgo has not been well tested [in general but especially] on uniprocessors
<mup> PR snapd#4616 closed: interfaces/apparmor: remove leaked future layout code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4616>
<mup> PR snapd#4618 opened: tests: new snaps to test installs nightly <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4618>
<zyga> mvo_ trivial feedback on https://github.com/snapcore/snapd/pull/4617
<mup> PR #4617: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617>
<mup> PR snapd#4576 closed: cmd/snap-update-ns: large refactor / update of unit tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4576>
<mvo_> zyga: ta
<zyga> for wht?
<zyga> :)
<zyga> oh, meeting
<mvo_> Chipaca: I look forward to the fix
<Chipaca> mvo_: ah, oh, hm
<mvo_> zyga: the feedback in my PR
<Chipaca> mvo_: the fix is "run go test with GOMAXPROCS=<something bigger than 1>"
<mvo_> heh
<Chipaca> mvo_: which I suspect means actual gccgo programs don't work well on uniprocessors
<zyga> Chipaca: buy bigger machine
<Chipaca> mvo_: I need to test this obvs
<mvo_> ok
 * kalikiana lunch
<Chipaca> zyga: "on any supported Fedora system you be good to," -> "on any supported Fedora system you should be good to go,"
<Chipaca> zyga: imho
<zyga> ah
<zyga> should
<zyga> I should add should
<zyga> Thanks for spotting
<zyga> I could use some coffee
 * genii slides zyga a large shiny Ubuntu mug full of strongly brewed Somalian Arabica, at just the right temperature for sipping
<zyga> man
<zyga> I wish there was "snap install coffee"
<genii> :D
<zyga> coffee sounds like a nice name for software
<zyga> what would it do though?
<zyga>  grind?
<genii> Keep you awake, ideally
<Chipaca> zyga: you are a step away from reinventing java
<zyga> oooh
<Chipaca> zyga: are you sure you want to continue [n/N/WTFNO]
<zyga> it could do coffee in containers known as *capsules*
 * zyga stands up and walks to the coffee machine
 * pstolowski lunch
<jdstrand> mvo_: re base-18> as of last night, it wasn't in the review queue. I didn't see it all last week. I feel like I *did* see it at some point and accepted it. yes, r5 was accepted. r6 has some extra 'unusual' files in it. if you request a manual review, I'll accept it
<zyga> hey jamie! thank you for the feedback there
<Saviq> niemeyer: hey, we've had a handful of jobs fail today with spread tasks getting stuck (?) on linode https://travis-ci.org/MirServer/mir/jobs/337880107
<jdstrand> you're welcome. sorry if I was a bit confused :)
<Saviq> niemeyer: shall we add -v on top of the -v to see what's what if this hits us again?
<zyga> I'll have more soon, I'm working on tests for existing, non-hardened implementation
<Chipaca> niemeyer: @attache in the forum (on the planet jumper post) has the exact same cpu/gpu as i do
<Chipaca> and the error is the same
<mup> PR snapd#4619 opened: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <https://github.com/snapcore/snapd/pull/4619>
<jdstrand> mvo_: so, I've add sudo and the ssh binaries to the review tools, but the /var/log/journal setgid dir is weird. did you actually want to include that?
<Chipaca> mvo_: why do we worry so much about powerpc if we don't have a core for it?
<mvo_> jdstrand: aha, good point, will kill it
<mvo_> jdstrand: we don't want this to prevent wear out o
<mvo_> f the mmc
<mvo_> Chipaca: don't ask
<Chipaca> mvo_: OK.
<mvo_> Chipaca: well, I will answer anyway
<Chipaca> mvo_: oops too late, already retracted my question
<Chipaca> I can't undo the undo! the universe will fall apart!
<jdstrand> mvo_: ping me when r7 is uploaded and you request a manual review and I'll push it through
<mvo_> Chipaca: we should stop supporting it, but that means a bit of paperwork, i.e. add this to the exception for our SRU policy etc. which probably needs approval and discussion. the end result is most likely that supporting is cheaper than stopping
<jdstrand> *this* is the week that I will *finally* request a pull of the review tools, but ping me until that is in prod
<mvo_> jdstrand: will do, let me kill that dir, I think it sneaked in due to a systemd change
 * jdstrand nods
<Chipaca> pedronis: niemeyer: is there any obvious (or non-obvious) bug in this: https://pastebin.ubuntu.com/26530120/ ?
<Chipaca> pedronis: niemeyer: symptom I'm seeing is that in some environments it never prints a dot, and hangs forever
<Chipaca> pedronis: niemeyer: gccgo and the playground
<Chipaca> and, where do bugs on gccgo get reported :-)
<mvo_> jdstrand: there is a r7 now for base-18
<mborzecki> niemeyer: https://paste.ubuntu.com/26530133/ TLS handshake timeout, are we abusing linode too much?
<Chipaca> zyga: do you have a bionic system to hand?
<zyga> mborzecki, niemeyer: I updated 4610
<kalikiana> re
<jdstrand> mvo_: can you request a manual review? (if I do, then I can't process it)
<mvo_> jdstrand: ups, sorry, done. thank you
<jdstrand> mvo_: approved but not published to a channel
<mvo_> jdstrand: ta
<mborzecki> niemeyer: edited the https://forum.snapcraft.io/t/core-configuration-options/87 and added info on refresh.timer, feel free to review and redact as needed
<mvo_> ackk: please check the latest base-18 in edge
<ackk> mvo_, ah, thanks, checking now
 * Chipaca bbiab
<mup> PR snapd#4619 closed: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4619>
<pedronis> Chipaca: sounds like a compiler that doesn't put, let's give a chance to other goroutines checkpoints, in some cases ?
<mup> PR snapd#4607 closed: wrappers: cleanup enabled service sockets <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4607>
<mvo_> cachio_: I triggered a new 2.31 core snap build, it seems the builders are quite busy right now, so hopefully in ~1h it will be there
<cachio_> mvo_, great, tx
<cwayne> mvo_: do we expect it in beta today?
<andyrock> mvo_ , niemeyer: hi! In bionic we  are almost ready to push the changes (in udisks2 and gnome-disk-utility) to hide snap loop devices from gnome-disks
<Chipaca> pedronis: yeah, going to file a bug
<zyga> for context, we need a way to refresh existing .mount units to get the benefits for all the snaps people have installed
<Chipaca> pedronis: as soon as i check it isn't yet fixed in a more recent build
<pedronis> didn't we have already something else that required .mount updates?
<Chipaca> hence me asking around for a B
<andyrock> yeah thanks zyga
<zyga> I was thinking we could port that code to use the ensure dir state code so that we can freely change mount units in the future
<zyga> but I wasn't sure where to put the call, probably just like interface manager
<zyga> (on interface startup)
<zyga> er
<zyga> s/interface/overlord/
<ackk> mvo_, so I got further then bafore with base-18, but maas snap now fails with django.db.utils.DataError: invalid value for parameter "TimeZone": "UTC"
<mvo_> ackk: aha, the I think this one if from the timezone database
<mvo_> ackk: if you use the beta core snap, you can probably use "snap run --strace" when starting your app to see what files it tries to access
<ackk> mvo_, so the build you gave a while ago add something that's still missing in edge I guess
 * cachio_ lunch
<mvo_> cwayne: yeah, it should be in beta today
<mvo_> cwayne: builds are a bit slow though
<mvo_> cachio_: i386/amd64/ppc64el are ready
<zyga> mvo_, do you think this can be a 2.32 roadmap item?
<mvo_> ackk: let me check the timezone db, is that something that the snap could ship?
<mvo_> zyga: what is "this"?
<zyga> mvo_ what I described above, a way to refresh .mount units
<ackk> mvo_, maybe yes
<ackk> mvo_, fwiw http://paste.ubuntu.com/26530521/ is the diff between the content of the custom built you gave me and the one in edge
<mvo_> ackk: I think its the -./usr/share/zoneinfo/Etc/UTC zoneinfo stuff
<mvo_> cachio_: armhf/arm64 are ready now too
<Chipaca> pedronis: https://github.com/golang/go/issues/23721 fwiw
<ackk> mvo_, yeah I think so, could that be included too?
<Chipaca> mvo_: ^that's our powerpc issue :-)
<Chipaca> mvo_: workaround coming in a pr rsn
<niemeyer> andyrock: Thanks for that
<andyrock> niemeyer the problem is that this is not going to work for existing mounted snaps
<andyrock> so zyga proposed a way
<andyrock> but we (the desktop team) need to know it this is going to get done before B is released
<mup> PR snapd#4620 opened: debian/rules: workaround for https://github.com/golang/go/issues/23721 <Created by chipaca> <https://github.com/snapcore/snapd/pull/4620>
<mup> PR snapd#4619 opened: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <https://github.com/snapcore/snapd/pull/4619>
<niemeyer> andyrock: I'm a bit out of context about what this is fixing and what we want to achieve at the end. Is there a thread I could read?
<andyrock> niemeyer: https://www.irccloud.com/irc/canonical.com/messages/zyga
<andyrock> sorry
<andyrock> https://github.com/snapcore/snapd/pull/4294
<mup> PR #4294: Mount with x-gdu.hide option <Created by azzar1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4294>
 * zyga raises his ear
<zyga> (feel free to pull me into the conversation)
<zyga> jdstrand replied
<zyga> 37 seconds after you asked :)
<niemeyer> andyrock: Thanks, get it now
<andyrock> niemeyer so zyga proposed this:
<andyrock> https://www.irccloud.com/pastebin/EwM37tE1/
<andyrock> if we know that this is going to be done before B is released we push the changes as they're upstream
<zyga> andyrock why not push the changes already?
<andyrock> otherwise for the moment we apply also a distro patch to work around this (in gnome-disk-utilities)
<andyrock> zyga to avoid pushing twice
 * zyga doesn't get it
<andyrock> first push: the generic fix (already upstream)
<andyrock> second push: the ubuntu specific fix
<zyga> what is the difference between them?
<zyga> I assumed we would just carry the patch in the package
<andyrock> if we know that this is not going to get done we push both
<zyga> aha, I see
<niemeyer> I don't quite see yet.. one way or the other the fix will work out
<zyga> I think the answer is, it will be done, the only question is how soon
<andyrock> in Ubuntu
<andyrock> not in other distros
<niemeyer> In one scenario it gets gradually cleaned, in other it gets cleaned at once
<zyga> and the patch won't hurt, in other places everyone will benefit from new upstream udisks
<niemeyer> For anyone installing 18.04, they have no previous mounts
<zyga> and all new installs are not affected anymore
<niemeyer> I'd actually prefer to do nothing on that basis.. at least for now.. rewriting all mount units feels uncomfortable from a sanity standpoint, if nothing else
<andyrock> seb128: ^^^
<andyrock> so at this point we could just apply the workaround
<jdstrand> andyrock: as an aside, thank you for your work on this. this will be a nice improvement
<seb128> andyrock, in a call atm but I read later, if it's not perfect / have some mounts still showing that clean over time that's not the end of the world
 * jdstrand only just now saw that PR
<andyrock> seb128: kk. So what I suggest is the following:
<andyrock> both in bionic, artful and xenial we distro patch to use the workaround (just hide if the loop backing file has the ".snap" suffix)
<andyrock> the workaround is just in gnome-disk-utilities
<zyga> andyrock is that released? I still see them
<andyrock> upstream will benefits from the upstreamed patches
<seb128> zyga, not yet, should be uploaded to bionic tomorrow
<zyga> ah
<niemeyer> andyrock: Sounds nice
<andyrock> seb128: If you arealdy started the uploading process we can keep it
<andyrock> it can be used somewhere else too
<seb128> andyrock, not, I'm in a call, I'm going to do that tomorrow morning
<seb128> but yours patches are still good/right
<Chipaca> zyga: finished with the powerpc box
<seb128> so why not including them?
<andyrock> kk
<andyrock> but I'll proposed another workaround too
<andyrock> but we can discuss about this in #ubuntu-desktop after the call
<seb128> right, let's discuss that tomorrow morning
<seb128> that call is still ongoing for a while and then I need to go
<zyga> Chipaca glad I could help, sad I could help
<andyrock> kk
<philroche> Is there a way to enable site-packages in the virtualenv in a snap built with the python plugin? I have a requirement python-apt that cannot be installed using pip. I can't see anything in the docs or examples on how to do this
 * kalikiana wrapping up for today
<kalikiana> philroche: not quite an answer to your question, but Snapcraft uses a tarball in requirements.txt to achieve the same thing. See https://github.com/snapcore/snapcraft/blob/master/requirements.txt#L10
<philroche> kalikiana: Interesting. Thank you
<lotuspsychje> good eveing to all
<jdstrand> mvo_: I see new revisions for base-18. can you request manual review for the ones you are interested in?
<lotuspsychje> someone might know why skype doesnt come anywhere latest here? http://feeds.feedburner.com/uAppExplorerNewSnaps
<kyrofa> lotuspsychje, uAppExplorer is a third-party site, we have no control over it
<lotuspsychje> kyrofa: ok, im trying to find an rss the way sudo snap find lists the latest ones, got any idea?
<Chipaca> mvo_: question about #4617
<mup> PR #4617: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617>
<Chipaca> mvo_: if it's survive, and has a reloadcommand, wouldn't you fire that?
<Chipaca> hm, maybe i'll ask it on the pr :-)
 * Chipaca sees it's dinnertime in mvoland
 * Chipaca EOWs (mostly)
<el_tigro1> kurofa: Thanks again for the help yesterday
<el_tigro1> zyga: I ran into this great documentation today which I'm assuming you wrote
<zyga> which documentation was that?
<el_tigro1> zyga: https://github.com/snapcore/snapd/wiki/Snap-Execution-Environment
<zyga> ah, yes
<el_tigro1> Question about the last paragraph "Preserving the mount namespace". The "/run/ns/snapd/" directory doesn't seem to exist on my system
<zyga> sorry, that's backwards, it should be /run/snapd/ns
<zyga> let me fix that
<el_tigro1> Ohh I should have caught that :D
<el_tigro1> zyga: Also I was wondering in what order "snap-confine" does its job. I'm assuming it handles the mount namespace stuff first, and then applies the apparmor/seccomp confinement?
<zyga> it's complicated, I should write something more in depth
<zyga> it handles all of mount namespace handling first, using itself and a helper process (snap-update-sn)
<zyga> it applies seccomp and apparmor and cgroup handling before running the application
<zyga> normally the order should not matter to apps, it should just work
<el_tigro1> really? the reason I assumed that was the order is that I thought apparmor/seccomp could disable the "mount" system call
<el_tigro1> Actually I mean the unshare/clone system calls
<el_tigro1> Actually I'm confused. Just ignore what I'm saying :P
<zyga> yes it can
<zyga> during the whole process the sandbox changes a few times
<zyga> snap-confine itself is confined with one profile
<zyga> snap-update-ns is confined with another profile
<zyga> and the application being started is confined with its own profile
<zyga> (and some of the work I'm doing now will also tailor snap-update-ns to have different profile per snap)
<zyga> all of this is so that it's harder to attack the system and so that super-power wielding things are as confined as possible
<zyga> mount is confined both at syscall level through seccomp and at path/device/options level through apparmor
<el_tigro1> Thanks. I find this stuff really interesting
<el_tigro1> I guess 'snap-confine' uses the 'pivot_root' system call to change its root?
<zyga> yes, that's correct
<zyga> it also jumps in and out of namespaces
<zyga> inspects them, invalidates them when necessary
<zyga> it handles cgroups (freezer and device)
<zyga> it uses snap-update-ns to construct and update existing namespaces
<zyga> and saves them on disk to preserve them across process lifecycle
<el_tigro1> 'pivot_root' takes an 'put_old' argument, which I guess is the '/var/lib/snapd/hostfs'?
<zyga> yes
<el_tigro1> And in that documentation link from above "Certain directories from the host file system are mapped (bind-mounted) to the mount namespace (see below).". They directories are the ones listed below the "The mount profile of the snap is applied (e.g. content sharing uses this)" bullet point right?
<zyga> yes
<zyga> though that's an incomplete list now, it also depends on interfaces
<zyga> and it also depends on nvidia driver being used
<el_tigro1> Wow thanks a lot for your time. You've given me quite a few leads. Back to experimenting/studying :D
<zyga> feel free to ask questions
<zyga> perhaps you would like to contribute back by writing documentation
<zyga> let me know if you'd like to help
<el_tigro1> Defintely. Once I feel like I have a solid enough understanding
<mvo_> ackk: I added tzdata now, it will be part of the next base-18 build
<mvo_> ackk: (sorry for the delay)
<el_tigro1> One thing that I noticed is that older versions of snaps are not removed. For example if I do 'ls /snap/lxd' I see 3 folders and a symbolic link 'current' pointing to the latest version. Would removing the directories containing the older versions be a bad idea?
<zyga> this is on purpose
<zyga> you also have three revisions of the snap installed, but not active
<zyga> (only one is active)
<zyga> when something goes bad and you want to revert to a prior version (e.g. broken update) the data is kept around
<el_tigro1> ahh I see
<zyga> over time old revisions are removed, no need to do that manually
<zyga> niemeyer +1 to merge 4610?
<niemeyer> zyga: Should be.. let me check
<niemeyer> zyga: Looks fine, thanks for double checking
<zyga> great, thank you!
 * zyga gets a coffee and works on some more :)
<mup> PR snapd#4610 closed: interfaces/apparmor: early support for snap-update-ns snippets <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4610>
<philroche> Can anyone see what is wrong with my snapcraft.yaml as I can not get the organize section to work with the python plugin https://github.com/philroche/ubuntu-watch-packages/blob/master/snap/snapcraft.yaml ? Thanks
<nacc_> philroche: i think it's your .'
<nacc_> philroche: so i believe, it's going to be running form the root of your source
<nacc_> it won't find 'wrapper' there
<mup> PR snapd#4621 opened: tests: skip alsa interface test when the system does not have any audio devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4621>
<nacc_> philroche: i put wrappers in their own part that's dump'd into the snap
<nacc_> philroche: alternatively, you put it i your MANIFEST.in
<nacc_> philroche: but otherwise, i don't thinkt he setup.py will see it and soo the python plugin won't
<philroche> nacc_: I tried it with wrapper in root too and the same error "The specified command 'wrapper' defined in the app 'ubuntu-watch-packages' does not exist or is not executable"
<philroche> nacc_: Yeah using a second dump part was my next approach
<nacc_> philroche: i would try that first (the dump part)
<philroche> nacc_: I hadn't thought of using the MANIFEST.in either but that seems a bit dirty by introducing snap stuff to the python package
<nacc_> philroche: yeah i woulldn't recommend it :)
<sergiusens> jdstrand stgraber in case you have a couple of minutes https://forum.snapcraft.io/t/disconnected-issue-a-cocktail-of-running-snapcraft-cleanbuild-in-multipass-with-the-lxd-snap/3891
<philroche> nacc_: Thanks. Trying dump method now
<cachio_> niemeyer, https://travis-ci.org/snapcore/snapd/builds/338037140
<cachio_> Cannot allocate linode:ubuntu-14.04-64: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout
<cachio_> that happened today
<cachio_> it is not so frequent but I see 1 or 2 of those every day
<niemeyer> cachio_: Thanks, also keeping an eye on those
<niemeyer> cachio_: But the most important issue is still the state corruption they seem to observe
<niemeyer> cachio_: Without that sorted we'll need to go elsewhere in the near future.. fingers crossed
<cachio_> niemeyer, good, tx
<kyrofa> zyga, I can't seem to reproduce the LXD issue as of 2.30. I'm not sure what changed
<zyga> maybe lxd shipped some workaround?
<kyrofa> Yeah that's my only clue as well
<zyga> are you sure you are on 2.30?
<kyrofa> Yeah, rev 3748
<kyrofa> (tracking stable)
<mup> Issue snapcraft#1918 opened: Add y/n support for sending errors back <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1918>
<mup> Issue snapcraft#1919 opened: Add Always/neVer support when sending errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1919>
<mup> Issue snapcraft#1920 opened: Design error reporting <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1920>
<mup> PR snapd#4622 opened: strutil: introducing MatchCounter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4622>
<mup> PR snapd#4620 closed: debian/rules: workaround for https://github.com/golang/go/issues/23721 <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4620>
#snappy 2018-02-07
<mup> Bug #1747794 opened: cannot resolve host name  with avahi interface  <Snappy:New> <https://launchpad.net/bugs/1747794>
<mup> Bug #1702095 changed: snap enable removes complain for daemons <Snappy:Expired> <https://launchpad.net/bugs/1702095>
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey
<zyga> -6 outside now
<zyga> so pretty
<zyga> coffee and back to spread
<zyga> I wrote a new feature and a test together
<zyga> need to split those out
<mborzecki> hm tried to reproduce this https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894 but no luck, nothing 'hangs'
<zyga> looking at that I wonder if the original deamon did something "fancy" that made it hang
<zyga> like get stuck on a syscall or whatever
<mborzecki> the next thing that happens after starting the services is running configuration hooks
<mborzecki> wonder if he had any
<mborzecki> oh
<mborzecki> shit
<zyga> oh?
<zyga> did you find something nasty?
<mborzecki> yeah, so whena  snap is installed we run all the services
<mborzecki> this one is 'oneshot'
<zyga> so?
<zyga> it should run and stop
<mborzecki> hahaha
<mborzecki> but it does not
<zyga> is this a regression in 2.31?
<zyga> (do we need rc4) or 2.31.1
<mborzecki> it's named usb_mount, suggesting that's it will mount a usb device, if there's none then it will apparently wait
<zyga> oh
<zyga> so oneshot services block until they exit?
<mborzecki> so i made a simple service that loops infinitely, and it hangs 'Start snap "daemon-oneshot" (unset) services'
<mborzecki> yeah
<zyga> oh, wow
<zyga> that's not great
<mborzecki> we also probably shoulnd't start them when installing a snap
<zyga> actually, what should happen for oneshot services isn't clear to me
<zyga> who should start them?
<zyga> the snap itself?
<mborzecki> the way i used oneshot is either as a dependency before other service (eg. generate ssh keys) or as a response to something that happens (path conditions, or a template unit)
<mborzecki> --no-block may be a reasonable workaround, but this doesn't change the fact that the service should not wait indefinitely
<pstolowski> heyas!
<mborzecki> pstolowski: morning
<kalikiana> moin moin
<mborzecki> everyone joining :) morning mvo & kalikiana
<mvo> good morning mborzecki
<mvo> hey kalikiana
<zyga> hey guys
<zyga> mborzecki is the service bug a regression?
<zyga> if so I bet mvo will want to know
<mvo> zyga: I do want to know
<mborzecki> mvo: https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894
<mborzecki> zyga: not a regression, technically it was there before
<mvo> mborzecki: nice find
<mborzecki> mvo: what happens is that if a oneshot service hangs/loops/does not termine, snapd will be stuck in start-snap-services task
<mborzecki> s/termine/terminate/
<mvo> mborzecki: yeah, I was just readoing it
<mvo> mborzecki: thats really unfortunate, I wonder if --no-block in systemctl might help
<mborzecki> i'm looking at some options, like not starting oneshot tasks, adding --no-block (complicates systemd interface internally), adding TimeoutSec= in *.service (the timeout is fairly arbitrary and probably incorrect in some edge cases)
<mvo> mborzecki: thanks for looking into this
<mborzecki> mvo: frankly i'm leaning towards not starting oneshot services at all
<mup> PR snapd#4621 closed: tests: skip alsa interface test when the system does not have any audio devices <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4621>
<mup> PR snapd#4618 closed: tests: new snaps to test installs nightly <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4618>
 * zyga iterates on layouts and testing 
<zyga> next up: refreshes that change layouts :)
<zyga> *that* will be interesting
<zyga> jamesh, hey, good morning
<zyga> did you guys watch the falcon heavy launch yesterday?
<mvo> zyga: yeah, quite spectacular.
<zyga> I watched it by accident (I got a tip from kissiel) and wow, it was crazy, like watching a sci-fi movie
<zyga> *live*
<kissiel> :)
 * zyga found some bugs in layout validation
<zyga> time to fix that
<zyga> (too conservative)
<zyga> nothing to worry about
<zyga> mvo remember before we had spread?
<zyga> it was like driving blind
<mvo> zyga: I don't, my therapist helped me with that
 * mvo pats the emacs therapist
<zyga> haha, good one
<mvo> zyga: but indeed, totally agree
<zyga> -5C outside, brrr
<zyga> let's rethink that validator
<mup> PR snapd#4623 opened: wrappers: do not start oneshot services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4623>
<mborzecki> there's probably a spread test that will fail as a result of ^^
 * kalikiana coffeeeeee
 * zyga notices a movie crew outside his house
<zyga> kalikiana khaaaaaaan
<zyga> there's a fake police car, fake news crew and fake people doing an interview
<zyga> they use this site for some sitcom or other local TV thing once in a while
<zyga> I wonder if I was in the shot, helping my daughter go to school
<zyga> they didn't stop filming, maybe just a dry run
<mvo> zyga: they are shooting a new sitcom - the big O theory - guess who the starts will be ?
<zyga> haha :)
 * mvo stops being silly and makes more tea
<zyga> is it also freezing for you mvo?
<Chipaca> zyga: a little bit of snow fell this morning, ~5am
<Chipaca> zyga: it's just sitting on the glass patio table, pondering life
<zyga> melting away
<zyga> like all of us
<zyga> ;-)
<Chipaca> no, actually
 * zyga is in a good mood today
<Chipaca> zyga: your comment on my MatchCounter PR, could you expand it?
<zyga> yeah, let me pull the diff tab
<zyga> w.partial is empty
<zyga> oh
<zyga> man
<zyga> I should not comment late at night
<zyga> nothing :)
<zyga> I got rid of it
<zyga> I somehow read that bytes.IndexByte() was called on w.partial
<Chipaca> ueh ueh ueh, or something
<mvo> zyga: its around 0 here
<mvo> Chipaca: I guess you want to rebase my PR on top of this ;)?
<Chipaca> zyga: https://i.imgur.com/Wcj6Swd.png
<Chipaca> zyga: censorship!
<Chipaca> :-)
<zyga> oh?
<zyga> I didn't delete your comment, I just deleted mine
<zyga> I guess it killed your comment that wasn't loaded in my tab
<Chipaca> mvo: more like: if you think it'll improve things, I can push a commit to your PR that uses this
<mvo> Chipaca: its more general than mine, so +1 for this
<Chipaca> mvo: ok, i'll push a commit to yours as soon as this lands
<mvo> ta
<mvo> that was a subtle clue that I should review it, right?
<Chipaca> today I'm going into london, so a lot of time on public transport with little/bad connectivity, and I'm going to miss the standup
<Chipaca> mvo: not at all
<Chipaca> mvo: I mean, I wasn't subtle
<Chipaca> :-D
<mvo> lol
 * mvo hugs Chipaca 
<mborzecki> Chipaca: i have mixed feelings about 4632 too, idk, maybe it'd be best to leave the code as it is now, this guys code is probably wrong
<Chipaca> mborzecki: FWIW i think we _should_ expose startup timeout, and conditionals, and have some extra magic for oneshots where we don't hang but still handle it, but it's a lot of work for something that, in this case, is probably dev error
<Chipaca> I mean: why would a mount process hang
<mborzecki> Chipaca: otoh, it's not really possible to interrupt this, ^C has no effect
<Chipaca> mborzecki: in that abort doesn't abort?
<mborzecki> Chipaca: yeah, i have a snap with an app that loops inside and i cannot abort the installation
<Chipaca> mborzecki: we probably want to make systemctl use the brand new osutil.RunWithContext :-)
<Chipaca> and bubble context into systemd
<Chipaca> OTOH it might be better to make start use --no-block and then poll, like we do with stop
<kalikiana> zyga: what are fake people? robots? ;-)
<Chipaca> (i mean, without it, systemctl is doing the polling)
<zyga> kalikiana just actors ;)
<Chipaca> kalikiana: kardashains
<kalikiana> lol
<mborzecki> Chipaca: hmm right, let me take another look at the code
<mborzecki> s/kardashians/osbournes/
<Chipaca> mborzecki: OTOÂ²H context + (no-block + poll) is probably the real winner
<Chipaca> mborzecki: OTOÂ³H probably a lot of work
<mborzecki> yeah, sounds backlog worthy
<Chipaca> mborzecki: OTOâ´H I'm running out of superscripts
 * sparkiegeek wonders how many hands Chipaca has
<Chipaca> mborzecki: OTOâ½â¿âºÂ¹â¾H, you'll never know
<mborzecki> Chipaca: RunWithContext was merged right?
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: but killing systemctl might not dtrt wrt systemd, which is why i said it might be better to do the more detailed work
<Chipaca> but you could use it as a base, or phase 1, or sth
 * Chipaca gives up, and starts getting ready to leave
<mborzecki> probably better than stalling
<Chipaca> mborzecki: first, see if killing systemctl stops the eternal oneshot
<mborzecki> 'eternal oneshot'
<Chipaca> if so then robert is your mother's brother
<Chipaca> or something
<mborzecki> Chipaca: right, it did, the unit was stopped
<Chipaca> perfect then :-)
<zyga> trivial PR for someone, pretty please
<zyga> 4624
<mup> PR snapd#4624 opened: snap: apply some golint suggestions <Created by zyga> <https://github.com/snapcore/snapd/pull/4624>
<Chipaca> mmm, golint fixes
<Chipaca> zyga: ValidAppName returns true if if given string is a valid application name.
<Chipaca> zyga: and if if not?
<zyga> well, it returns false ;)
<Chipaca> zyga: I mean, too many ifs
<zyga> oh
<zyga> I see now
<zyga> thanks
<Chipaca> this isn't me getting into the "oh it should be whether" thing
<Chipaca> which I have learned is pedantic :-)
<zyga> another good point
<zyga> I never write that word
<zyga> because I'm always afraid I will say weather
<zyga> or actually, write weather
<zyga> if if you see what I mean
<Chipaca> zyga: maybe it's just a tsundere comment
<zyga> a what comment?
<mup> PR snapd#4625 opened: daemon: remove redundant UserOK markings from api commands <Created by mvo5> <https://github.com/snapcore/snapd/pull/4625>
<mvo> Chipaca: ^- is what we talked about last night
<Chipaca> zyga: maybe you don't want to know
<Chipaca> mvo: ack
 * Chipaca looks
<mvo> Chipaca: I hope this makes things for my future self easier to grok
<Chipaca> mvo: when the mythical "no more features, just fixes and cleanup" year arrives, I grab "rewrite daemon"
<Chipaca> anyhow, I need to run
<zyga> o/
<Chipaca> telegram is your best bet to reach me (or whatsapp fwiw)
<zyga> mvo "what the canAccess() policy." ... what?
<mvo> Chipaca: see you
<mvo> zyga: not sure I follow, did I write something in an unclear way?
<zyga> I think it ends abruptly
<zyga> "what the canAccess() policy means." maybe?
<pedronis> unless it was meant to be "polices"  (the verb)
<mup> PR snapd#4626 opened:  daemon: improve ucrednet code for the snap.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/4626>
<pedronis> ah, just the "what"Â is too much
<pstolowski> mvo, hey, #4579 can land, right? it got +1 from security in the old PR?
<mup> PR #4579:  many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4579>
<mvo> pstolowski: I think so, but zyga asked for a tweak (which I can do in a followup if this helps you)
<zyga> mvo can be in a follow-up yeah
<zyga> mvo especially since there's a new function to extract out of that logic
<mvo> pstolowski, zyga I work on the followup and then work on the other two (smaller) ones
<pstolowski> mvo, no, it doesn't change much for me (need other PRs as well), it's just 1 less to look after ;)
<mup> PR snapd#4579 closed:  many: add interfaces.SystemKey() helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4579>
<sparkiegeek> FYI: the snappy store is in a maintenance window until 11:00 UTC (see https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866 )
<zyga> oh, thanks for the heads up sparkiegeek
<mvo> zyga: hm, the release/apparmor.go code is doing the inverse of what I need, so I guess I just move my code there? or am I missing something?
<zyga> yes
<zyga> just move it there and perhaps reuse your code in the computation of what was already there, if feasible
<zyga> hmm, store is doing 503
<zyga> is that expected sparkiegeek
<sparkiegeek> zyga: yes, but it should be coming back up now
<mup> PR snapd#4627 opened: release, interfaces: add new release.AppArmorFeatures helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4627>
<mborzecki> pstolowski: left you a comment about truncation, feel free to ignore it, i think it would complicate the internals a bit too much
<zyga> mvo 4627 is almost good
<pstolowski> mborzecki, thx, will check
<mup> PR snapd#4623 closed: wrappers: do not start oneshot services <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4623>
<zyga> whee
<zyga> spread now passes
<zyga> ok, let's upstream the changes and work on hardening so that jdstrand doesn't turn grey on release day
<sparkiegeek> store maintenance is now over, please report any issues on the forum thread: https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866
<mup> PR snapd#4613 closed: release: snapd 2.31 <Blocked> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4613>
<zyga> woot :)
<cachio_> mvo, hey, we are ready to go to candidate
<zyga> so no more RCs? :)
<cachio_> no
<mvo> cachio_: yes
<mvo> cachio_: actually, give me ~20min to check the autopkgtest results on bionic
<cachio_> mvo, sure
<mvo> cachio_: if these are bad we *migth* need a .1
<mborzecki> uhhn the changes allwoing cancelling of systemctl start are ugly
<mvo> cachio_: looks like we do have some issues in autopkgtest due to the different environment. oh well.
<cachio_> mvo, which is the link?
<cachio_> mvo, could I take a look?
<mvo> cachio_: http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd and follow the bionic links
<mvo> cachio_: one strange one is unit test for TestDoREquestSerialErrorsOnNoHost
<mvo> cachio_: but it looks like a random assortion
<cachio_> mvo, I see that a failure in the interfaces-timeserver-control is breaking the whole suite
<cachio_> for amd64
<mvo> cachio_: yeah, I have not looked into the details yet but it seems there are some failures we need to look at :/
<mvo> cachio_: slightly annoying that its so hard to test autopkgtest for real
<mup> PR snapd#4628 opened: spread: add missing ubuntu-18.04-arm64 to available autopkgtest machines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4628>
<mvo> cachio_: some is rather trivial like -^
<cachio_> mvo, yes, I'll work on that
<mvo> cachio_: thanks
<mvo> zyga: looks like we need an s390x build for snapd-hacker-toolbelt
<mvo> cachio_: and one for test-snapd-kernel-module-consumer for s390x
<mvo> cachio_: but I guess we should focus on amd64/i386 first
<cachio_> mvo, yes, agree
<xnox> mvo, isn't it nice, that s390x is no longer a restricted arch and one can just tick the tickbox for it ;-)
<zyga> mvo aha
<zyga> mvo in a moment, I'm busy for 15 minutes
<cachio_> mvo, not sure if we are able to create a bionic image in linode
<mvo> xnox: it is!
<cachio_> as it is not stable
<mvo> cachio_: I don't think this will help us much
<mvo> cachio_: my feeling is that the images are not the problem
<mvo> cachio_: its that the autopkgtest env is more restricted
<cachio_> mvo, ah, ok
<mvo> cachio_: for whatever reason
<mvo> cachio_: it really should not be, we run in a full VM and added hints that we mess the host up but e.g. timezone setting is denied
<pstolowski> mvo, thanks for 4627!
<cachio_> mvo, how do you do to trigger the tests?
<mvo> cachio_: or maybe it is actually bionic, might be easiest to just run against qemu to see if something in e.g. systemd failed
<mvo> cachio_: s/failed/changed/
<mvo> cachio_: thats the sad part - to trigger the tests I need to upload the package to the real archive
<mvo> cachio_: this is my grief with adt - there is no easy way to test against e.g. a ppa
<cachio_> mvo, ok, I'll start runnig in qemu and then if we have a 100% we can go forward
<mvo> cachio_: great, I keen to know if e.g. the timezone failure is related to bionic or adt
<cachio_> mvo, so, should I promote to candidate?
<cachio_> mvo, I can do it after the standup
<cachio_> mvo, I have a doc appointment now, I'll be bac for the standup
 * cachio_ afk
<zyga> mvo sorry I'm back now
<zyga> I just sold my x250
<zyga> so, about that build for s390x
<zyga> mvo, I wonder how we can build one, will snapcraft.io do it?
<mvo> zyga: launchpad can do it, if you have snap building enabled on it
<mvo> zyga: then you can just click on s390x as an arch
<mvo> pstolowski: the next one (re-generate on system-key change) will arrive as soon as 4627 is green
<pstolowski> mvo, great!
<zyga> mvo, let me look, I honestly don't remember how I built it
<mvo> pstolowski: then i think its just #3471 and its done
<mup> PR #3471: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3471>
<mvo> pstolowski: not sure if you need this piece for your work though
<pstolowski> cool
<zyga> ah, it's on launchpad allright
<zyga> mvo: shall I just rebuild for all arches?
<mvo> zyga: +1
<pstolowski> mvo, ah, if this is only about snap-run then no
<zyga> mvo, man, I can even build for powerpc :)
<zyga> would that work?
<zyga> or is it just fake?
<mvo> zyga: I think it will work
<mvo> zyga: we could even build a core for powerpc now if that is fully enabled
<zyga> https://launchpad.net/~zyga/+snap/snapd-hacker-toolbelt
<zyga> builds are pending
<zyga> that will be an interesting refresh :)
<zyga> I should adopt one of the new features in snapcraft and generate version dynamically
 * pstolowski lunch
<zyga> mvo all done
<zyga> wow,
<mup> PR snapd#4624 closed: snap: apply some golint suggestions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4624>
 * zyga re-reads 4622
<mup> PR snapd#4627 closed: release, interfaces: add new release.AppArmorFeatures helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4627>
<mup> PR snapd#4629 opened: ifacestate: only rewrite security profiles if the system-key changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/4629>
<mup> PR snapd#4630 opened: snap: sort layout elements before validating <Created by zyga> <https://github.com/snapcore/snapd/pull/4630>
<zyga> + systemctl stop snapd.service snapd.socket
<zyga> Job for snapd.socket canceled.
<zyga> I wonder what this was, is this something that we fixed in another context before?
<zyga> ^ cachio_  (perhaps you remember)
<zyga> mvo ^ trivial  4630
<mvo> zyga: ta!
<zyga> I have one more on top, also trivial but separate issue
<zyga> jdstrand 4631 is super trivial but for you
<mup> PR snapd#4631 opened: cmd/snap-confine: allow mounting anywhere, effectively <Created by zyga> <https://github.com/snapcore/snapd/pull/4631>
<zyga> jdstrand this is a side effect of a fully working spread test, which is coming up in two branches from now
<zyga> once the test lands I will start pushing hardening for snap-update-ns, knowing that I didn't break anything
<mup> PR snapd#4626 closed:  daemon: improve ucrednet code for the snap.socket <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4626>
<diddledan> what's a "gated snap"?
<zyga> diddledan snaps can use gating to ensure QA constraints
 * diddledan read the snapcraft --help and found `snapcraft gated` and `snapcraft validate`
<zyga> you can use it to ensure that refreshes will happen only after you sign that off as not breaking your snap
<diddledan> so what's "gating"?
<zyga> so. you can, for example, have a super important snap that you want to support 24/7
<zyga> gating is the whole process
<zyga> and you control your snap so that part is easy
<zyga> but the core snap can introduce bugs so you want to have a way to validate them
<zyga> if you have validation control on the core snap you can say that the core snap will refresh only if you say that your snap works with a given revision of the core snap
<zyga> (core can by any other snap but it's typically core)
<zyga> obviously this only applies if your snap is installed
<zyga> it's a way to check that you can conform to your contractual agreements most likely
<zyga> where you can check each new core revision and "ack" it
<zyga> (for the purpose of your snap)
<zyga> does that make sense?
<diddledan> no
<diddledan> clear as mud :-p
<zyga> can you be more specific?
<diddledan> I'm just thick
<zyga> I can give you an example if that helps
<diddledan> "Get the list of snaps and revisions gating a snap." means nothing to me
<zyga> gets the list of snaps and revisions that _block the snap from refreshing_
<diddledan> can we change the verbiage then?
<zyga> change what, sorry?
<diddledan> "gating" is a term which requires intimate knowledge of what it means to "gate"
<zyga> yes, we use many words that require one specific knowledge
<diddledan> "block", "blocks" and "blocking" are much more appropriate words if that's what is happening
<zyga> but I think that's unavoidable and not a problem as long as they are clearly explained somewhere accessible
<zyga> it's not just blocking, it's more subtle
<diddledan> ... which they're not (explained somewhere accessible)
<zyga> the users can override that
<zyga> diddledan please raised this with kalikiana as I think this is a snapcraft documentation
<mup> PR snapd#4632 opened: Fixing denial for when using avahi-observe slot <Created by kubiko> <https://github.com/snapcore/snapd/pull/4632>
 * zyga -> lunch
<kalikiana> diddledan: It's not really explained there, that's true. Would you mind filing a bug for it?
<zyga> jdstrand thank you, I replied to your question if you want to look at why I needed this
<mup> PR snapd#4631 closed: cmd/snap-confine: allow mounting anywhere, effectively <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4631>
 * kalikiana hopping on a tram towards coffee shop for lunch, back in ~60min max
<mup> PR snapd#4628 closed: spread: add missing ubuntu-18.04-arm64 to available autopkgtest machines <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4628>
<mup> PR snapd#4633 opened:  snap: introduce timer service data types and validation  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633>
<zyga> mborzecki can you please look at 4630, it's tiny and it's just adding sorting + tests
<mborzecki> looking
<zyga> cool, thanks
 * zyga looks at other PRs
<pedronis> mvo: cachio_:  here are the failures for linode:ubuntu-16.04-64:tests/main/... with SPREAD_REMOTE_STORE=staging , IÂ think most of them are missing snaps/old snap revisions,   not sure about the core transition; canonical-livepatch and lxd we could skip though I think, the other it would be good to fix:  https://pastebin.ubuntu.com/26534904/
<zyga> mborzecki you have a conflict on 4633
<zyga> and it looks like what I did, sorry
<mvo> pedronis: I think core-transition, lxd, livepatch we should skip yes
<jdstrand> zyga: /me nods
<zyga> mvo do you think we could disable tests for core transition?
<mvo> zyga: probably
<zyga> jdstrand thanks for acking the dbus fix
<zyga> mvo if you do 2.31.1 I would suggest cherry-picking 4632
<mvo> zyga: we do a .1
<zyga> I'll mark it
<mvo> zyga: ta
<mborzecki> zyga: ok if i rebase?
<zyga> mborzecki quickly :)
<mborzecki> haha ok
<cachio__> pedronis, ok, I'll take a look
<mborzecki> zyga: pushed
<mup> PR snapd#4605 closed: snap: detect unsquashfs write failures <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4605>
<zyga> oh, kids home
<zyga> brb
<mvo> zyga: you reviewed 4491 earlier but did not do a +1 - did you forgot or was the review not complete?
<zyga> checking
<zyga> mvo I need to re-read that
<mup> PR snapd#4634 opened: tests: check if snapd.socket is active before stoping it <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4634>
<andyrock> mvo: I'm trying to allow store login in the installer. One possible solution would be to:
<andyrock> 1) stop/disable snapd.service/snapd.socket (the one running in the live session)
<andyrock> 2) manually start snapd inside the /target chroot
<andyrock> 3) a client can now talk with the chrooted snapd through /run/snapd.socket
<andyrock> Do you think that (1) and/or (2) could create any side effect?
<zyga> andyrock: do you expect to be able to run snaps in the end?
<zyga> andyrock I didn't check what would happen with chroot
<zyga> probably it'd be okay
<zyga> snapd has some logic to reassociate itself with the mount namespace of pid 1
<zyga> but since this is the same namespace, just different chroot, it should not trigger
<andyrock> zyga: that's not necessary
<andyrock> for livepatch we can actually enable it at first run without problems
<andyrock> I just need to login into the store
<andyrock> so that the state.json has the valid entries
<andyrock> I need (1) otherwise the live-session-snapd will activate
<mvo> andyrock: I don't see any immediate problem, give it a go
<andyrock> thanks
<zyga> mvo do you want me to cherry-pick 4632?
<mup> PR snapd#4632 closed: Fixing denial for when using avahi-observe slot <Created by kubiko> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4632>
<mvo> zyga: sure go for it
<zyga> pushed
<kalikiana> re
<Chipaca> mvo: mborzecki: did either of you mean to +1 #4622 and didn't?
<mup> PR #4622: strutil: introducing MatchCounter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4622>
<Chipaca> or -1 or sth :-)
<zyga> Chipaca +1 from me
<zyga> though I didn't comment
<zyga> let me
<zyga> I read it a few times but I was in some wrong zone I guess
<Chipaca> it's fiddly :-)
<Chipaca> rather like round.Robin
<Chipaca> :-)
<zyga> hmmm
<zyga> Chipaca so
<zyga> do you need a flush?
<zyga> on diff line 62 there
<zyga> what guarantees that w.partial will be eventually inspected
<Chipaca> zyga: it only matches full lines
<Chipaca> zyga: either you wrote a full line, and got counted, or you didn't and it's in partial
<Chipaca> \n is a flush, in that sense
<zyga> mhm
<Chipaca> to make it generic and not line-oriented a flush or something would be needed
<zyga> okay
<zyga> I think it's fine, YAGNI untill we need to do that
<zyga> hmm
<zyga> actually
<zyga> you could use it without being line oriented
<zyga> though I don't need that either
<zyga> just wonder if it would be equally genreric
<zyga> *generic
<Chipaca> zyga: it very much uses the \n as the flusher
<zyga> I'll let others comment
<zyga> yeah
<Chipaca> so yes you can use it, but it'd be unpredictable
<zyga> regexpes are hard :)
<Chipaca> and that :-)
<zyga> it could compute the derivative of the re based on the partial input
<zyga> and reset the re when it is empty
<zyga> not needed
<zyga> ;)
<Chipaca> zyga: OTOH, instead of w.Flush() do w.Write([]byte{'\n'}) :-)
<Chipaca> zyga: a more general thing would have two regexps (or deduce one from the other but that's Hard), one for matching, one for deciding whether to keep a chunk
<Chipaca> eh
<zyga> I think you can just use one RE and feed it incrementally (computing the derivative)
<zyga> though I haven't seen any stdlib implementation that does that
<zyga> essentially streaming
<Chipaca> it'd require the regexp be front-anchored though, i think
<Chipaca> i mean, the regexp for the sqlite failures is literally `.*[Ff]ailed.*`
<zyga> mmmm
<Chipaca> (it could be made to be `.*\b[Ff]ailed\b.*` for more nitpickiness)
<zyga> I don't think it would, why would it?
<zyga> derivative is a generic operation
<Chipaca> zyga: because as soon as it starts with .*, you can't decide ahead of time
<Chipaca> the answer always is 'yes this might match'
<zyga> the derivative of ".*" over any character is ".*"
<Chipaca> (aside: I'd love to understand why it's called the derivative)
<zyga> but ".*foo.*" over "f" is "oo.*|.*foo.*" (probably)
<zyga> dunno, you can ask the inventor
<zyga> he's still alive
<Chipaca> 82 and at princeton, huh
 * zyga reads that page again
<zyga> https://en.wikipedia.org/wiki/Brzozowski_derivative
<Chipaca> zyga: but, er, i'm not sure how the derivative would let you decide whether to discard it early
<zyga> I think the re will effectively remember what you threw at it
<Chipaca> ahhh
<Chipaca> I'd misunderstood :-)
 * Chipaca reading pdf
<Chipaca> Suppose we are given an RE r and a string u and we want to determine if u â L[[r]]. We have u â L[[r]] if, and only if, Îµ â L[[âu r]], which is true exactly when Îµ = Î½(âu r). Combining this fact with the definition of âu leads to an algorithm for testing if u â L[[r]].
 * Chipaca puts pdf down
<zyga> Chipaca always read the conclusion first
<zyga> then the abstract
<zyga> then the rest
<zyga> Chipaca I have a problem, wondering if I solved it right
<zyga> https://github.com/zyga/snapd/commit/2784dc9bed05c9afb06ecbcec43328b61563c125
<Chipaca> zyga: am I looking at the problem, or the solution? :-)
<zyga> the solution
<Chipaca> zyga: ok tell me about the problem
<Chipaca> zyga: or is that what's in the commit message?
<zyga> yeah, that
<zyga> feels hackish
<zyga> maybe correct but hackish
<Chipaca> zyga: at what point are these paths getting cleaned?
<zyga> they are not cleaned, they are verified to be clean
<zyga> it's on line 468 in the diff context (left hand side)
<zyga> isAbsAndClean
<Chipaca> zyga: right, so, filepath.Clean drops trailing /s (except for root)
<Chipaca> that is, filepath.Clean("/foo/") is "/foo"
<zyga> yes, right
<zyga> we require that (and check for it)
<Chipaca> ok
<zyga> and then for directories we slam that "/" at the end
<zyga> and where "for directories" I mean for tmpfs mounts and for non-file bind mounts
<Chipaca> zyga: then why the check for trailing /s in effectivePath?
<zyga> ah, good question
<zyga> in case $SNAP expands to /snap/core/123/
<zyga> vs 123
<zyga> I just didn't want to be fragile there
<Chipaca> ok
<Chipaca> zyga: i wasn't concerned about being defensive, i was concerned about a muddled "clean filepath" barrier
<Chipaca> OTOH I suspect whatever expands $SNAP should be cleaning it as well
<zyga> mmm
<zyga> I'm not cleaning there
<zyga> yeah
<zyga> separate patch, let's see it
<zyga> done now
<Chipaca> zyga: isn't this blocking a file /foo/bar if /foo/bartholomew is in the blacklist?
<zyga> aha, indeed
<zyga> hmm hmm :)
<zyga> first, let's add a test so that I know it's broken
<Chipaca> zyga: ExpandSnapVariables does clean its returns fwiw (maybe it should document this)
<zyga> it does?
<zyga> I tweaked it to do it now
<zyga> or are you saying that os.Expand cleans
<Chipaca> zyga: I'm saying it returns things that are the result of filepath.Join
<zyga> as for the /foobarthomesomething, we could check for prefix if the blacklist item ends with /
<Chipaca> zyga: and filepath.Join is documented as cleaning its result
<zyga> and check for equaility otherwise
<zyga> aah
<Chipaca> zyga: would it be hard to keep files and dirs separate?
<zyga> not sure I know how
<zyga> can you be more specific?
<Chipaca> zyga: have two blacklists, and have effectivePath return whether it's one or the other as a bool?
<zyga> hmm
<zyga> but I'd have to check the directory blacklist for files as well
<zyga> if /foo is a tmpfs mount then I must reject /foo/bar
<zyga> even if /foo/bar is a file bind mount
<Chipaca> zyga: hmm
<Chipaca> zyga: another option is for effectivePath to return interfacy things, and use separate concrete classes for one and t'other
<Chipaca> i'm not sure i'm communicating sense
<zyga> such as IsBlacklisted() os something
<zyga> yeah, that would work
<zyga> I mean, I'd still check the same thing but it might be less magic
<Chipaca> zyga: it'd keep the / fiddliness isolated
<Chipaca> zyga: the blacklist check would be 'for interfacyThing in blacklist: interfacyThing.frobbles(otherInterfacyThing)
<Chipaca> or sth
<zyga>   yeah
<zyga> thank you for spotting the bug :)
<Chipaca> heh, np
<zyga> https://github.com/snapcore/snapd/pull/4633 needs a 2nd review
<mup> PR #4633:  snap: introduce  timer service data types and validation  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633>
<mup> PR snapd#4622 closed: strutil: introducing MatchCounter <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4622>
<Chipaca> zyga: tea, and i'll look at it
<zyga> ha
<zyga> I found my old tea
<zyga> from yesterday evening
<zyga> it has rum in it :)
<Chipaca> sadly i have no rum (and it's a little early)
<Chipaca> best i can do is port
<Chipaca> but that doesn't sound like it'd work
<ikey> see also https://www.youtube.com/watch?v=JImcvtJzIK8
<zyga> hehe, someone is triggered on rum :D
<zyga> so
<zyga> the travis log page officially sucks
<zyga> it's horrible
<zyga> it's so slow an iframe would be a godsend
<zyga> and it's forcibly loaded when all I want to do is to hit "retry"
<zyga> Chipaca I wrote the dumb version and I'll rebase and work on the smarter version next
<Chipaca> mvo: you around?
<mvo> Chipaca: ish - what can I do?
<Saviq> niemeyer: hey, a lot of our builds started failing over the past couple of days, it's usually a single run that times out on travis because the task seems stuck at updating apt (https://travis-ci.org/MirServer/mir/builds/338519402) - I tried enabling debugging from spread, but travis didn't like the amount of logging (https://travis-ci.org/MirServer/mir/builds/338550499)
<Chipaca> mvo: i'm tweaking the error output of unsquashfsStderrWriter, thought I'd check with you first
<Saviq> niemeyer: any idea how to proceed?
<Chipaca> Saviq: disable ipv6?
<Chipaca> at a guess
 * Saviq raises brow
<Chipaca> Saviq: we had a lot of hangs in linode during apt update with ipv6 enabled
<Chipaca> Saviq: seems to be a problem with talking with whatever the mirror was? cachio__ might know more
<Saviq> interesting!
<zyga> jhodapp hey
<jhodapp> zyga, hey there
<mvo> Chipaca: sure, tweaking sound sgood
<Chipaca> mvo: any rationale for it being 10 failures long, for example? it seems to result in a rather long message :-)
<zyga> man, travis doesn't love me
<mvo> Chipaca: no good reason, 4 is probably equally fine
<Chipaca> mvo: perfect :-D
<mvo> Chipaca: or 3
<mvo> Chipaca: I just think too little is not ideal as we really have no idea
<Chipaca> mvo: are they always in groups of 3?
<Chipaca> mvo: otherwise, 4 seems better
<mvo> Chipaca: I need to look, I suspect not
<mvo> Chipaca: gtg, but will read backlog
<Chipaca> mvo: ok, if you could at some point, it can be part of your review of this ;-)
 * Chipaca hugs mvo 
<mvo> Chipaca: sure
 * mvo hugs Chipaca and vanishes
<niemeyer> Saviq: That timeout on apt is usually associated with IPv6
<niemeyer> Saviq: Disable IPv6 on the prepare script before trying to use apt and it should work
<Chipaca> Saviq: https://github.com/snapcore/snapd/blob/master/spread.yaml#L294
<Saviq> yeah, /me just stole that
<Saviq> erm
<Saviq> borrowed, you know
<Saviq> I'll give it back
<Chipaca> mvo: https://github.com/mvo5/snappy/pull/17 is the thing (i also pushed a merge of master to your pr directly, to make this one's diff easier on you)
<mup> PR mvo5/snappy#17: snap/squashfs: change unsquashfsStderrWriter to use MatchCounter <Created by chipaca> <https://github.com/mvo5/snappy/pull/17>
<mup> PR snapd#4630 closed: snap: sort layout elements before validating <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4630>
<mup> PR snapd#4635 opened: snap: add support for `snap run --gdb` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4635>
<zyga> oh, cool stuff mvo
<ikey> oo
<zyga> mvo quick review out
<mvo> zyga: cool, thanks
<zyga> Chipaca 4636 is what we talked about sans the interface indirection
<mvo> zyga: good feedback, thank you. will address those, the message also needs tweaking I think. it was mostly a flash of inspiration that I wanted to check if it would work (i.e. use gdb from outside and the shim to break at the right point)
<mup> PR snapd#4636 opened: snap: understand directories in layout blacklist <Created by zyga> <https://github.com/snapcore/snapd/pull/4636>
<cachio> Saviq, sorry for the delay, which images are you using?
<cachio> sabdfl, we have ipv6 disabled in linode images to avoid timeouts/connection issues
<zyga> mvo I looked at your earlier PR but I'm at a stage where thinking requires a 7AM freshness
<mvo> zyga: haha, no worries
<mvo> zyga: I think I could probably untangle them but there will be conflicts
<zyga> no, that's fine
<mvo> zyga: so that stacking was easier
<mvo> zyga: ta!
<zyga> I just need to look at it carefully as it changes a few things in an area that is tricky
<mvo> cachio: do we need 4634 for .31 ?
<mvo> cachio: if we do, please shoot me a quick mail with the commit id and I will cherry-pick
<cachio> mvo, no, it is just for an error that we see in linode
<mvo> cachio: ok
<mup> PR snapd#4634 closed: tests: check if snapd.socket is active before stoping it <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4634>
<zyga> woot, I'm one PR away for spread test for layouts
<cachio> niemeyer, do you have any idea about what could be causing this error on linode? https://paste.ubuntu.com/26537045/
<Chipaca> cachio: probably https://twitter.com/gniemeyer/status/961273050707693569
<cachio> Chipaca, nice
<cachio> tx
 * zyga -> afk
<cachio> niemeyer, I still can't run tests on linode, is it the same issue that we faced previously?
<niemeyer> cachio: I'll soon be with you
<cachio> sure
<sparkiegeek> hmm, potential ux regression in 2.31? https://bugs.launchpad.net/snapd/+bug/1747992
<mup> Bug #1747992: Refreshing to a newly created channel but immediately stopped tracking <snapd:New> <https://launchpad.net/bugs/1747992>
<niemeyer> sparkiegeek: Huh.. weird
<niemeyer> sparkiegeek: Yeah, definitely worth looking into
<niemeyer> cachio: Still there?
<cachio> niemeyer,
<niemeyer> cachio: So yeah, these errors look like Linode breaking down
<cachio> niemeyer, https://paste.ubuntu.com/26537730/
<cachio> these kind of errors I see
<niemeyer> cachio: In general Spread can automatically recover from them, though, and the fact we have several workers per systems means no big deal
<cachio> niemeyer, it is related to the quota limits?
<cachio> niemeyer, it is trying to connect to the vm and nothing
<cachio> it tries until it breaks
<cachio> it fails
<niemeyer> cachio: It's not quota.. it's corruption
<niemeyer> cachio: They have severe bugs in their API services.. apparently races
<cachio> niemeyer, I checked debian-9 and we have ipv6 enabled there
<cachio> I could not check in trusty
<niemeyer> cachio: Let me see which machine is creating problems.. just a sec
<cachio> niemeyer, sure
<niemeyer> cachio: There are machines with an empty plan ID
<niemeyer> cachio: Which gives you an idea of how nice it is
<cachio> niemeyer, ouch
<cachio> niemeyer, are you killing these ones?
<jdstrand> davidcalle (cc sergiusens): fyi, https://docs.snapcraft.io/deprecation-notices/dn5 uses the wrong header 'DN2'. It should be 'DN5'
<niemeyer> cachio: I've run a full pass of garbage collection
<niemeyer> cachio: Please give a shot
<cachio> niemeyer, it is still having same issue
<niemeyer> Okay, hold on
<cachio> niemeyer, well, now got 1 serve
<cachio> r
<niemeyer> cachio: What does that mean?
<cachio> niemeyer, it is workfing now
<niemeyer> cachio: Phew, cool
<cachio> niemeyer, thanks
<niemeyer> cachio: np, let me know if you have more bad cases blocking you
<niemeyer> cachio: I'll need to speed up our move over, likely to Google Compute
<zyga> now to get some rest and fight tomorrow
<slanigan> Hi everyone, I'm struggling to build an Ubuntu Core image as per the steps on the introduction page: https://docs.ubuntu.com/core/en/guides/build-device/image-building
<slanigan> I keep getting COMMAND FAILED: sudo cp -dR --preserve=mode,timestamps,ownership /tmp/tmpuv44url8/root/* /tmp/tmp7yr_gzqx/root-mount  cp: error writing '/tmp/tmp7yr_gzqx/root-mount/system-data/var/lib/snapd/snaps/core_3884.snap': No space left on device cp: error writing '/tmp/tmp7yr_gzqx/root-mount/system-data/var/lib/snapd/snaps/pi2-kernel_22.snap': No space left on device cp: cannot create directory '/tmp/tmp7yr_gzqx/root-mount/s
<slanigan> When I try to do the "ubuntu-image" command
<kyrofa> slanigan, any chance you're out of HD space?
<slanigan> df -h reports this:
<slanigan>     Filesystem Size Used Avail Use% Mounted on     udev 7.8G 0 7.8G 0% /dev     tmpfs 1.6G 9.7M 1.6G 1% /run     /dev/sda1 432G 259G 157G 63% /     tmpfs 7.8G 130M 7.7G 2% /dev/shm     tmpfs 5.0M 4.0K 5.0M 1% /run/lock     tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup     ...     /dev/loop8 3.9M 52K 3.3M 2% /tmp/tmpvn70tzdq/root-mount <<<<<<<<
<slanigan> That's a shortened list, but the /dev/loop8 entry is while ubuntu-image is trying to do its thing
#snappy 2018-02-08
<zyga> good morning
 * zyga preps kids for school
<mborzecki> morning
<zyga> good morning everyone
<zyga> https://forum.snapcraft.io/t/yes-snaps-are-cross-distribution/3906 <- cool stuff :)
<mvo> zyga: good morning
<mup> PR snapd#4637 opened: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4637>
<zyga> huh?
<zyga> mvo can you explain?
<mborzecki> zyga: mvo: morning
<mborzecki> zyga: iirc there's an ongoing story about pickign the right 'unresolvable' domain in the tests, *.test was suppsoed to be the answer, but my guess is some resolvers were trying to resolve it actually
<mborzecki> zyga: /var/lib/snapd/mount is something that was introduced in 2.31 cycle?
<zyga> no
<zyga> far older
<mborzecki> snap-mgmt --purge does not clean it up
<mborzecki> i'm checking snapd aur package and noticed that /var/lib/snapd/mount was left behind when i removed snapd-git
<zyga> mborzecki it's very very old, probably an omission then
<zyga> mvo could we use something like http://unresolvable.snapcraft.io
<zyga> and arrange with people so that it never resolves
<zyga> I'm almost inclined to buy really-nowhere.com ;-)
<mvo> zyga: ups, thanks. so the issue appaears to be that for some daemons artful/bionic returns SERVFAIL instead of NXDOMAIN
<mvo> zyga: its not fully clear yet why, I'm looking into this. we see this on bionic autopkgtests and also on one of my two artful systems
<zyga> mvo can I help somehow, I can setup nothing.zygoon.pl with any config desired
<zyga> how are you testing this?
<mvo> zyga: I have one machine where i can reproduce it
<zyga> is it using systemd-resolved?
<mup> PR snapd#4637 closed: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4637>
<mvo> zyga: I think so, I switched to it a while ago there, I would consider it a fluke without the autopkgtest failure that looks similar
<mvo> zyga: internally we handle SERVFAIL as a temporary error and retry
<zyga> well, my offer stands, let me know if I can help
<mvo> zyga: this is why we see a test failure, this test is expecting an error and it gets a "doing"
<zyga> ack
<mvo> zyga: thanks! I will dig a bit
 * zyga looks for a color scheme appropriate for "gloomy polish morning"
<mborzecki> gloomy, it's fat thursday today
<mborzecki> zyga: did you get your donut yet?
<pedronis> mvo: hi, don't autopkgtest machines  proxy http(s)? that probably gives a different kind of errors
<zyga> mborzecki no, not today
<zyga> mborzecki I will get one in a few days, today is the worst possible day to buy them (unless you make one at home0
<mvo> pedronis: thats an interessting idea, they do that
<kalikiana> o/
<mvo> pedronis: it might be two issues :/ anyway, I get a SERVFAIL in a fresh bionic kvm (which we consider a temp error) so thats something to look into
<pstolowski> morning
<zyga> https://jordaneldredge.com/projects/winamp2-js/ :D
<zyga> (drag and drop music to play)
<mborzecki> zyga: i'll sync snapd-git aur PKGBUILD with that of snapd and open a PR to our repo to sync the recipe in packaging too
<zyga> mborzecki sounds good, thank you
<mup> PR snapd#4638 opened: devicestate: fix autopkgtest failure in TestDoRequestSerialErrorsOnNoHost <Created by mvo5> <https://github.com/snapcore/snapd/pull/4638>
<zyga> anyone (sans chipaca who did) wants to look at https://github.com/snapcore/snapd/pull/4636
<mup> PR #4636: snap: understand directories in layout blacklist <Created by zyga> <https://github.com/snapcore/snapd/pull/4636>
<wiking> i'm wondering snap is being used in the scenario of distributing a library itself. i.e. the package would contain a  standalone app but a library?
<zyga> wiking it's possible using the content interface
<zyga> though we have a constraint that snaps can only share among one snap publisher
<ikey> goooooooooooooooood mornin
<zyga> if someone wants to maintain a snap that is used by others we need to allow that, it's essentially a promise to maintain something correctly
<zyga> ikey happy pÄczki day :-)
<zyga> wiking, for example there's a gnome platform snap (AFAIK) that anyone can use even though it's published by a third party
<zyga> Chipaca morning :)
<ikey> zyga, and thee
<Chipaca> gnome-3-26-1604
<wiking> zyga, yeah i'm trying to avoid keep maintaining a deb/rpm package and possibly just switch to snap
<Chipaca> zyga: moin
<zyga> wiking though for libraries we recommend just making a part that anyone can use
<zyga> parts can be easily embedded into an snap at build time
<Chipaca> the gnome platform snap is gnome-3-26-1604 right now (the name encodes the abi and base libs to make it easier to pick and choose)
<Chipaca> fwiw
<wiking> zyga, ok so i guess i should be looking into 'Sharing a C-level library'
<zyga> wiking so, who would consume your library?
<wiking> anybody who wants to use it? :)
<zyga> snaps, unlike classic packages, typically don't model runtime dependencies as distinct packages for end-users
<zyga> I'm almost certain that you want to make a part instead of a snap
<wiking> oh i see
<zyga> wiking you can ask kalikiana about parts
<zyga> wiking you can maintain a part on a shared pool of parts (I forgot the name)
<zyga> and anyone can build a snap that references your part by name
<wiking> https://docs.snapcraft.io/build-snaps/parts
<wiking> i guess
<zyga> parts are like -dev or -devel packages in classic systems
<zyga> yes
<wiking> k
<wiking> cool thnx for the quick support :)
<zyga> welcome, enjoy snaps :-)
<wiking> thnx
 * ikey needs to assault jdstrand's mindbrain today
 * zyga LOLs a little
<kalikiana> ikey: are you trying to break everyone else's brain by using that weird term? :-P
<ikey> kinda. xD
<mborzecki> #4615 and #4633 are in need of 2nd review
<mup> PR #4615: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615>
<mup> PR #4633:  snap: introduce  timer service data types and validation  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633>
<Chipaca> zyga: your blacklist checking code still has bugs i fear
<zyga> yeah?
<Chipaca> zyga: at least as I understand it
<zyga> I implemented the thing we discussed last night, I'm adjusting tests to match
<zyga> what's the bug?
<Chipaca> zyga: should an entry of /foo stop a later entry of /foo/bar ?
<zyga> if /foo is a file, no
<zyga> if foo is a directory, yes
<Chipaca> yes foo was a file iin this
<Chipaca> why not?
<zyga> I see what you are saying
<zyga> technically it will just fail but it should be validated
<zyga> hmm
<zyga> but that's good, actually :)
<zyga> it means validation gets easier
<Chipaca> it's good that it'd fail, but my experience is the error is nicer if it's caught in a validation step
<zyga> yep
<Chipaca> zyga: does it?
<zyga> thank you, I'll adjust
<zyga> I think so
<zyga> we'll see :)
<Chipaca> you still don't want /foo to block /foolicious
<zyga> sure
<Chipaca> so for files it's "is this file a prefix of any complete prefix of this path"
<Chipaca> where complete prefix is up to a / or o$
<Chipaca> or $*
 * Chipaca is forgetting how to type
 * Chipaca goes to see if coffee is the answer
 * Son_Goku rises from the dead
<zyga> hey hey
<Chipaca> pstolowski: what do you mean with "that's what we do in undoMountSnap"?
<Chipaca> pstolowski: backend.UndoSetupSnap _is_ undoMountSnap
<Chipaca> unless that is exactly what you mean
<Chipaca> (thus my original phrasing)
 * Chipaca seems to be in an argument with himself
<Chipaca> no i'm not
 * Chipaca is too
<pstolowski> Chipaca, I mean, undoMountSnap calls backend.UndoSetupSnap, which does backend.RemoveSnapFiles
<Chipaca> pstolowski: yes
<Chipaca> ah
<Chipaca> pstolowski: now i understood
<Chipaca> pstolowski: and feel dumb :-)
<pstolowski> Chipaca, so, it's the same cleanup that mborzecki does on error
<Chipaca> yes
<Chipaca> pstolowski: I got confused there, sorry, all sorted now (for now!)
<pstolowski> no worries, happens all the time here ;)
<Chipaca> but there's a big difference
<Chipaca> i'll comment on the PR
<mborzecki> Chipaca: please do
<pstolowski> Chipaca, good! you get my curiosity
<zyga> good morning niemeyer
<zyga> you're up early :)
<mborzecki> zyga: can you give 4571 another pass?
<zyga> mmm
<zyga> reading
<zyga> @: :-)
<zyga> I know what it does but ... autotools :)
<zyga> btw, I meant to ask
<zyga> why do we need another configre.ac there? (in data0
<zyga> I never used a tree with more than one
<zyga> could those things be rolled into the main one?
<zyga> mborzecki ^
<mborzecki> zyga: with paths going from cmd to ../data? hm don't know if out of source tree builds with work this way
<zyga> yeah
<mborzecki> zyga: nvm, i can try that
<zyga> I'll read on
<Son_Goku> mborzecki: they don't
<Chipaca> mborzecki: I was wrong
<mborzecki> mvo: RemainAfterExit=yes is interesting, ^C when systemctl start is waitig does not make the service exit, it keeps on working in the background, trying to start it again sort of hangs/hooks to the job that already runs
<mvo> mborzecki: hm, so its not a solution for us?
<Son_Goku> mborzecki: can we please make this so that --libexecdir=/usr/libexec works like it's supposed to?
<Son_Goku> the only reason it doesn't currently is because of inconsistent implementations in makefiles/autofoo
<zyga> mborzecki done
<mborzecki> Son_Goku: have this in a separate branch now, quite a lot of changes, first i'd like to have autotools in data and then fix the libexec (would make the diff smaller also)
<Son_Goku> and please use pkgconfig stuff
<Son_Goku> it's already there since you've autotoolized it
<Son_Goku> no reason not to
<Chipaca> my typing *and* my language (and probably my diction!) are shot to hell today
<mborzecki> mvo: feels like this setting should be exposed in snap.yaml instead, it will change the behavior of the unit a bit, once started it sort-of remains 'active' until you stop it, meaning when ExecStart exits it's still considered active
<Chipaca> mborzecki: still, +1, and maybe even good news :-)
<mborzecki> Chipaca: btw. i recall there was a lp bug about snap try that failed would leave some stuff behind and remember going through this code once already ;) (although i didn't know that undo is only run if task was successful)
<zyga> Chipaca she sells sea shells on the ...
<Chipaca> zyga: she sells sea shells on the sea shore // mollusc moltings mostly make measly money // the lady later lacks lucre and leans on loans // she barters her business to barely bypass bankruptcy // turns out tacky tourist trinkets turn in ten times the take // she shelves t-shirts by the sea shore.
<zyga> wow, I didn't know most of them
<Chipaca> zyga: that's a newer take on the old one
<zyga> must write down for at-the-pub fun
<Chipaca> zyga: https://www.smbc-comics.com/comic/2014-07-23
<Chipaca> zyga: the original is making fun of a very early (and mostly ignored) paleontologist, https://en.wikipedia.org/wiki/Mary_Anning
<mborzecki> it'd be so nice if gnome-shell didn't log an exception every 3 seconds :/
<zyga> better not press ctrl-c
<zyga> it's like "red... no blue YAAAH"
<mborzecki> heh, use log is full of this BS: https://paste.ubuntu.com/26540491/
<mborzecki> and it's not even the extensions
<Chipaca> mborzecki: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887082 /
<Chipaca> ?
<mborzecki> Chipaca: yup, that's the one
<mup> PR snapd#4612 closed: snap: exclude `gettimeofday` from `snap run --strace` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4612>
<mborzecki> mvo: i think we could run `systemctl start --no-block always`, if the unit files are bad (dependencies are wrong, format is incorrect) systemctl fails right away, and then we proceed to stop all the services in the cleanup phase
 * pedronis lunch
<mvo> mborzecki: this does sound good to me
<Chipaca> mborzecki: mvo: is this --no-block + poll?
<mborzecki> mvo: we may consider waiting for a while to see if they do not enter a failed state, but this sounds like a compication and the 'while' may be hard to agree on
<mborzecki> Chipaca: --no-block, with optional poll to see if ActiveState is not 'failed'
<Chipaca> mborzecki: a'ight
<mvo> mborzecki, Chipaca: what kinds of "gurantees" do we currently get from systemctl start? my understanding is that its not that much anyway but should not regress here of course
<Chipaca> mvo: it comes back when the exec of the thing succeeded
<Chipaca> mvo: or when the thing notified it was up, if it's a notifier
<Chipaca> mvo: or when it finishes running, if it's a oneshot
<Chipaca> mvo: or or or
<Chipaca> :-)
<Chipaca> mvo: that's part of the problem :-)
<mvo>  /o\
<mvo> indeed
<Chipaca> no-block + poll lets _us_ decide the vagaries (and makes cancelling cleaner)
<mborzecki> Chipaca: mvo: if i'm reading systemctl source code right, without --no-block, there will be a wait set up, for each of the jobs that failed, if any of those failed systemctl exits with error status
<mup> PR snapd#4619 closed: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4619>
<zyga> Chipaca can you please have a 2nd look at 4636
<zyga> I implemented the thing we discussed last night
<zyga> and you would be the perfect 2nd reviewer
<Chipaca> zyga: i like it
<Chipaca> zyga: i'll go deeper after the standup
<zyga> thank you!
<niemeyer> Chipaca: You coming?
<Chipaca> niemeyer: nah
<kyrofa> zyga, any ideas here? https://askubuntu.com/questions/1004203/installing-snapd-on-14-04-fails
<zyga> yes
<zyga> 3.13
<zyga> install snapd, reboot
<zyga> it works
<Chipaca> would now be a good moment to start freaking out because there's an ubuntu on its way to the asteroid belt
<Chipaca> â¦ and it's not going to be getting updates!!! /o\
<Chipaca> it's going to be _so_ rootkitted by the time it gets back
<zyga> pesky space worms will eat it
<Chipaca> zyga: https://i.imgur.com/vCrOo9e.gifv
<verterok> ctrl-?meta-j29
<verterok> ups, ignore that
<zyga> kyrofa I replied on the forum
 * kalikiana going out for lunch, back later
<cachio_> mvo, hey
<mvo> cachio_: hey
<cachio_> mvo, I see this error compiling snapd on bionic https://paste.ubuntu.com/26541162/
<cachio_> mvo, any guess?
<pedronis> cachio_: hi, did you manage to start uploading some of those snaps that were missing in staging?
<zyga> mvo oh btw, I didn't get that snap to work yesterday
<cachio_> pedronis, yes, the snaps are in the store
<zyga> but it should be ok now
 * pstolowski lunch
<zyga> I noticed that the build got done but upload failed because of stale auth
<pedronis> cachio_: thx, I'll try again with the tests later today
<cachio_> pedronis, still working on some fixes
<pedronis> ok
<mvo> zyga: what snap was that?
<pedronis> cachio_: let me know if IÂ can help, also a couple we can just skip as discussed (lxd, canonical-livepatch and core transition)
<mvo> cachio_: hm, I have not seen this yet
<zyga> mvo the one you poked me about, snapd-hacker-toolbelt
<Chipaca> zyga: #4606 could use your eyes
<mup> PR #4606: snap: use custom unsquashfsStderrWriter for unsquashfs error detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/4606>
<mvo> zyga: aha, irght
<mvo> zyga: right thanks
<zyga> Chipaca sure, opened
<mvo> cachio_: golang in bionic is on 1.9 now, maybe that is the problem, let me check
<mvo> cachio_: hm, no, its like this for some time
<zyga> niemeyer btw, I forced myself not to fullscreen any windows now
<zyga> and I think I'm getting used to it
<zyga> I can fit a few 1080p "big" windows easily and the habit of getting everything maximised is just that, a habit
<mvo> cachio_: let me upgrade to bionic to test
<cachio_> mvo, nice, tx
<cachio_> pedronis, I uploaded 4 snaps
<cachio_> for amd64 and i386
<mvo> cachio_: hm, there was a new golang-1.9 upload during the night it seems
<mvo> cachio_: so maybe/probably that is the reason
<cachio_> mvo, mmm
<mvo> cachio_: but its a point release, should not break like this
<mvo> "should" :)
<mvo> anyway, once my upgrade is done I will know
<cachio_> mvo, btw I am using the cloud image that perhaps has some differences with yours installation
<mvo> cachio_: I have a cloud image vm at hand too which I can try. I assume you did something like "sudo apt build-dep snapd" at some point, i.e. its not something like a missing pkgconfig or something like this (the error indicates its not)
<cachio_> mvo, I updated the prepare-project script to use the external backend to test bionic
<cachio_> mvo, I am using the same code we have to build in linode but in the external backend
<mvo> cachio_: ok
<jdstrand> ikey: hey, steam-support is not forgotten! I traveled last week to the snapcraft sprint and a couple of other things came up, but as of last night, steam-support is back on top of the list so planned on working on it today
<jdstrand> ikey: sorry for the delay
<ikey> yeah no worries bud, just figured id prod
<zyga> hey jdstrand
<jdstrand> it wasn't going to make 2.31 anyway, so still no issues with 2.32
<ikey> yeah figures
<jdstrand> hey zyga :)
<zyga> I'm working on hardening, I won't push anything major for you to review today though
<jdstrand> zyga: cool (on both counts)
<zyga> landing existing stuff is fun enough :)
<jdstrand> it's getting quite close :)
<jdstrand> zyga: let me double check with you. your changes to the content interface recently were a) only about the slot side and b) add a new 'source' attribute that has read and write lists under it, which may not be specified alongside the legacy read and write attributes. read and write legacy attributes are still supported
<jdstrand> zyga: is that a good summary?
<zyga> yes
<zyga> that's accurate
<jdstrand> (I phrased that slightly weird, source is alone, read/write may continue to be used instead of source)
<jdstrand> ok cool
<mup> PR snapd#4639 opened: store: enable deltas for core devices too <Created by mvo5> <https://github.com/snapcore/snapd/pull/4639>
<jdstrand> so, the review-tools now understand this :) (not in prod yet)
<zyga> woot, great
<mvo> cachio_: I can reproduce the error
<cachio_> mvo, good
<jdstrand> I looked at the PR and it was clear enough, I just wanted to double check since the updated docs aren't there yet
<cachio_> mvo, yesterday I was using a prebuilt core
<cachio_> but then I tried to run all in the bionic and I got that error
<zyga> Chipaca replied
<cachio_> pedronis, I see this errror https://paste.ubuntu.com/26541264/
<cachio_> but the weird part is that test-snapd-base-bare snap is uploaded in the staging store
<pedronis> cachio_: ah
 * zyga returns to snapshots
<mvo> cachio_, mwhudson it looks like 1.9.4 #cgo LDFLAGS whitelisting broke snap-seccomp
<cachio_> pedronis, not sure which could be the reason
 * Chipaca hugs zyga 
<pedronis> cachio_:  IÂ dont't see that snap
<pedronis> not in stable?
<pedronis> no, sorry, mistyped
<pedronis> cachio_: wondering if core is too old in that test
<pedronis> cachio_: test-snapd-base-bare  seems to have the wrong type,   it says application and not base
<pedronis> same in prod though
<pedronis> mmh
<mvo> cachio_, mwhudson https://github.com/golang/go/issues/23672 is the issue, our ldflags -Wl,-Bstatic are not longer allowed
<zyga> hmm
<zyga> mvo are we in trouble?
<mvo> zyga: a bit
<zyga> a little bit or the grammatical bit where it's really a bucket full of trouible
<pedronis> mvo: any idea why base snaps would work with the production store, but not staging (IÂ don't know what would be different)
<zyga> *trouble
<mvo> zyga: our static linking in snap-confine of libseecomp no longer works
<zyga> hmmm hmmm
<mvo> pedronis: work in the sense that snap install base-18 from staging does not work?
<zyga> is that related to golang or to something else?
<pedronis> mvo: this  https://paste.ubuntu.com/26541264/
<mvo> zyga: golang upstream change
<pedronis> from cachio_
<mvo> zyga: https://github.com/golang/go/issues/23672
<pedronis> the base snap is there in staging, with the wrong type fwiw,  but it has the wrong type also in production afaict
<mvo> cachio_, pedronis is test-snapd-base-bare published in staging into the stable channel?
<zyga> mvo hold on but snap-confine is in pure c
<zyga> or did you meant snap-seccomp
<mvo> zyga: sorry, snap-seccomp
<zyga> ahh
<zyga> ok
<zyga> well
<zyga> that sucks
<zyga> mvo let me know if you want to discuss options
<zyga> we could dlopen libseccomp from core perhaps
<cachio_> mvo, yes
<zyga> (that would be good on a few levels, at least)
<cachio_> mvo, in staging for all the archs in all the channels
<pedronis> cachio_: what snapd version is in use there,  IÂ suppose master?
<cachio_> pedronis, yes
<mvo> zyga: I need to think a little bit about it, but it sucks
<pedronis> cachio_: I can try as well in a little bit, not sure what would be different in staging though
<cachio_> pedronis, it is weird because I can install test-snapd-base-bare
<cachio_> in the staging store
<cachio_> but if it used as base snap it cannot be found
<mvo> cachio_: quite confusing
<jdstrand> kyrofa: hi! weird: kernel: [1304675.438833] audit: type=1400 audit(1518072222.273:174): apparmor="DENIED" operation="exec" profile="snap.nextcloud.mysql" name="/bin/systemctl" pid=19425 comm="mysql.server" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<jdstrand> kyrofa: I think it is falling back though, since I see: nextcloud.mysql[19403]: Shutting down MySQL
<jdstrand> nextcloud.mysql[19403]: .. *
<jdstrand> systemd[1]: Stopped Service for snap application nextcloud.mysql.
<mborzecki> mvo: zyga: moving each -Wl into separate line does not help I guess?
<mvo> mborzecki: I can try, I think its a whitelist
<mborzecki> right: there's a review for --as-needed https://go-review.googlesource.com/c/go/+/92795
<mborzecki> mvo: and thre are environment variables too
<mborzecki> mvo: https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a
<mborzecki> this piece in particular: https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a%5E%21/#F3
<mborzecki> zyga: tried this in the autotools branch https://paste.ubuntu.com/26541368/ automake went down with some bs error, clearly confused about the relative paths
<zyga> uh
<zyga> mborzecki what if we moved those upstairs
<zyga> that would work, right?
<mborzecki> that would work, but it will also clutter the toplevel dir
<greyback> is there a list of env vars available for use in snippits in snapcraft? (not for snaps themselves)
<zyga> sure
<zyga> Chipaca I added a review to snapshots (half of review really)
<mborzecki> zyga: otoh, it's 3 files at most that need to be kept in the tree -> configure.ac, Makefile.am, autogen.sh, the rest is just temporary artifacts
<zyga> yeah
<zyga> maybe that's the solution
<zyga> mborzecki so
<zyga> mborzecki another idea
<zyga> how about if we add .dot-dot symlink
<zyga> and make data show up as cmd/.dot-dot/data
<zyga> :D
<mborzecki> hmm might work, let me try
<zyga> looking at 4606 now
<mborzecki> mvo: by the looks of it, the arch package does not build due to the go changes atm
<mborzecki> right, pkg-config is broken now too
<mborzecki> go build github.com/snapcore/snapd/cmd/snap-seccomp: invalid pkg-config package name: --static
<mborzecki> zyga: can you take a look at https://github.com/bboozzoo/aur-snapd/pull/3 ?
<mup> PR bboozzoo/aur-snapd#3: snapd: updates <Created by bboozzoo> <https://github.com/bboozzoo/aur-snapd/pull/3>
<mup> Issue snapcraft#1921 opened: Evaluate contents of manifest.txt, add reasons and surface to the user during staging <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1921>
<zyga> yes
<mborzecki> i'll push another fix with a workaround for go1.9.4 in a minute
<zyga> mborzecki done
<mborzecki> zyga: thanks
<zyga> Chipaca +1
<mup> PR snapd#4606 closed: snap: use custom unsquashfsStderrWriter for unsquashfs error detection <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4606>
<zyga> pstolowski which PR should I review first for you?
<pstolowski> zyga, #4401 please, thanks!
<mup> PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
<mup> PR snapd#4636 closed: snap: understand directories in layout blacklist <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4636>
<jdstrand> davidcalle (cc sergiusens): hey did you see my comment yesterday about https://docs.snapcraft.io/deprecation-notices/dn5?
<popey> jdstrand: is this the right report a bug against the snap review tools? https://bugs.launchpad.net/review-tools
<jdstrand> popey: I'd prefer that, yes (at some point soonish we'll deprecate click-reviewers-tools bzr branch and use only the review-tools git banch, so it would be good to get used to it)
<popey> it was the first hit when i googled, :)
<popey> thanks
<jdstrand> popey: before you file, perhaps you could say what the problem is now? quite a few updates are on their way to prod
<popey> jdstrand: I wanted to suggest that we prevent "empty" snaps from landing in the stable channel. In the same way we don't allow grade: devel ones in stable.
<popey> e.g. there is a snap which just landed in stable called "toto". It is entirely empty, contains only a snap.yaml, nothing else.
<popey> this shouldn't be allowed to land in stable IMO
<Chipaca> zyga: woo
<jdstrand> popey: interesting. ok, file away :)
<popey> ta
<jdstrand> popey: note that the review tools aren't run on channel promotions, only the initial upload, so a change tot he review-tools would mean no empty snaps in any channel
 * zyga breaks for back pain
<popey> awww
<zyga> I'll continue reviewing 4401
<zyga> but later
<jdstrand> popey: the snapstore could, in theory, peek back at a previous run for channel promotions. that would need some design and likely help from the review tools
<jdstrand> popey: I'm not sure at what priority that would be. I'm guessing quite low for this particular issue
<jdstrand> popey: tbh, an empty snap seems like it isn't valid in any channel though
<popey> jdstrand: i think some might argue that it's not fair for a new developer to get punched in the face with words like "error" and "reject" as they're starting out with snaps
<jdstrand> jjohansen: hey, do you have a moment to kick around an idea for organizing a new steam-support interface
<jdstrand> popey: well, they'll face all those same words if they do other things wrong. why is that one special?
<jdstrand> eg, the pick an invalid snap name
<jdstrand> they*
<popey> *shrug* emoji
<jdstrand> popey: I'll put it this way. if you file the bug, I will fix it and this will apply to everything. if you don't, I'll conveniently forget about it. if you think the snapstore should support peeking back on channel promotions, then file it against the snapstore and add a review-tools task
<popey> ok
<pstolowski> niemeyer, pedronis could you please take another look at #4401?
<mup> PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
<jjohansen> jdstrand: sorry, yeah I have a few minutes, /me is getting kids ready for school
<niemeyer> pstolowski: SUre thing
<pedronis> pstolowski: likely tomorrow morning
<zyga> jjohansen o/
<pedronis> cachio_: mvo: I think the issue is that /details for test-snapd-busybox-static  doesn't have base set
<pedronis> in staging
<jjohansen> hey zyga
<pedronis> cachio_: mvo: I remember some discussion about needing backfilling for something, and decided it was not worth it, it probably needs to be uploaded again
<pedronis> unless it was just uploaded in which case, something else is going on
<cachio_> pedronis, ok, I'll upload it
<jdstrand> jjohansen: just ping me when ready. it might take up to 15 or so
<jdstrand> maybe faster. I tripled what I thought it might take :)
<pedronis> cachio_: it seems old even in staging, afaict
<pedronis> so re-uploading from prod to staging should help or so IÂ hope
<cachio_> pedronis, I planned to copy the one in prod to staging
<pedronis> sounds good
<cachio_> pedronis, ok
<cachio_> mvo, could you please share test-snapd-busybox-static with me?
<jjohansen> jdstrand: 15 min to discuss or implement?
<jjohansen> :)
<jdstrand> jjohansen: hehe
<jjohansen> jdstrand: shoot I have 15 min
<jdstrand> jjohansen: it's true, I could just say 'you get the wide-open classic template' and *boom* it works :P
<jdstrand> jjohansen: ok, more seriously
<mvo> cachio_: sure, one sec
<jdstrand> jjohansen: architecture is this: steam has a steam client. the client allows you to buy, install, remove and launch games
<cachio_> mvo, tx
 * zyga returns to being off, sorry :/
<mvo> mborzecki: yeah, same problem everywhere I presume, the go change is a security update so I guess its applied everywhere :/
<jdstrand> jjohansen: many steam games use a process lifecycle where they will ptrace child processes
<jdstrand> jjohansen: this is just how it goes (proprietary blobs)
<jjohansen> jdstrand: have I mentioned how much I hate proprietary blobs lately
<mborzecki> mvo: i've pushed a fix to arch package, so that it builds now :/ funny cause it was building in the morning (i was working on it a bit), then ~2pm they pushed an update of go and it broke
<zyga> Chipaca I pushed 4640 with one more layout feature
<mvo> cachio_: on your way
<jdstrand> jjohansen: so I had the idea that it would be nice if the launcher was in one profile, and it would launch games in a different profile. we'll call the launcher profile the client profile and the games profile the game profile
<mup> PR snapd#4640 opened: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640>
<mvo> mborzecki: what fix did you use? CGO_LDFLAGS_ALLOW=.* or similar :) ?
<cachio_> mvo, tx
<jdstrand> jjohansen: the game profile would be under a different label, and it could ptrace itself (let's not worry about seccomp in <4.8 kernels for this discussion) but not the client
<mborzecki> mvo: just this patch https://github.com/bboozzoo/snapd/commit/3286baf646fa7974c165efd9b63c690d08dff6b7 the rest seemd to build just fine
<niemeyer> pstolowski: LGTM I think.. I've skimmed through it, and haven't spent as much time on it as last time, but if pedornis is happy and it works, I'm happy with the change
<mvo> mborzecki: ok
<mborzecki> mvo: and we did disable the static linking in arch anyway as libseccomp is only dynamic
<niemeyer> It's certainly quite nice to have auto-connect on its own task
<mvo> mborzecki: aha, ok
<pstolowski> niemeyer, ty
<jdstrand> jjohansen: so, that is the germ of the design. in terms of implementation, I really want to use a Px rule with a sibling profile, because of the way snapd is architected and generates profiles, that is convenient
<jjohansen> jdstrand: ack, launcher, client, game A, game B, game C, profiles ...
<jdstrand> jjohansen: but I ran into: https://bugs.launchpad.net/apparmor/+bug/1696552
<mup> Bug #1696552: syntax errors when specifying px rules with exec transitions that have '.' in the name <AppArmor:New> <https://launchpad.net/bugs/1696552>
<mborzecki> ok, end of the week for me, cu all on monday
<jjohansen> jdstrand: oh, sorry I meant to have that fixed already, I can add it to todays todo, its an easy fix
<jdstrand> jjohansen: launcher/client are the same, games likely will share a profile in the initial implementation since the steam client (proprietary blob) has no concept of change_profile/etc
<jdstrand> jjohansen: (I would use file rules to transition to the games profile)
<jdstrand> jjohansen: well, I was trying to think through that. yes we should clearly fix the parser. that is a given
<jjohansen> jdstrand: that makes me a sad panda but ack
<jdstrand> jjohansen: but, that means SRUs for Ubuntu (possible) and then updates for suse, solus, Ubuntu derivatives, etc (improbable for the whole list), which means that steam will work on some distros, bt not others (bad for snapd)
<ikey> steam what now
<ikey> ears twitched
<jdstrand> jjohansen: re file rules> yeah. not terribly excited by that, but the secret hope is that if we can improve on steam's security story by preventing games from attacking the client, then maybe, just maybe, they'd be open to building something into their client down the line
<jdstrand> jjohansen: perhaps a pipe-dream, but one can hope :)
<ikey> not outside the realms of possibilities tbh
<jjohansen> jdstrand: yes, sorry wish I could write bug free software, but I seem to be gifted with talents else where
<ikey> we already know they flirted with flatpak in the past purely to look only at bubblewrap re: sandboxing
<jdstrand> jjohansen: because of what I just mentioned with parser and other distros, I started exploring other ideas
<jdstrand> jjohansen: haha, no need to apologize. apparmor is awesome!
<jdstrand> ikey: hey, I was serious that steam-support was on the list for today :)
<ikey> :D
<ikey> kickin ass
<jdstrand> jjohansen: so I came up with an idea to use a child profile
<jjohansen> that can work
<jdstrand> jjohansen: I have two choices with that. one I greatly prefer in terms of snapd architecture
<jdstrand> it can. I did it
<jdstrand> jjohansen: so, I can either generate profiles like this:
<jdstrand> 'profile client { profile { game } }' or I can do 'profile client {} profile client//game {}
<jdstrand> '
<jdstrand> the second is preferred in terms of how snapd is architected. again, I can do the first
<jdstrand> note that in the second, 'client' and 'client//game' are in different files
<jdstrand> which means that I need to be concerned about profile load and remove order
<jjohansen> jdstrand: so the second is supported, you do need to be worried about order to a degree
<jdstrand> I'm able to deal with load ok, but remove generates a parser error because if I unload 'client', it unloads 'client//game' so then when I unload 'client//game' there is an error
<jjohansen> if you remove a parent before its child, the child should get repeated as well, and the 2nd remove should complain with ENOENT
<jdstrand> precisely
<jjohansen> right
<jdstrand> I thought I tried it the other way..
<jdstrand> (too)
<jdstrand> and I think the unload of the parent had a parser error cause the child was already removed
<jdstrand> let me double check that
<jjohansen> that should just work, if not there is a bug
<jjohansen> I also need to fix the parser so that if they are both specified, it just does the right thing
<jdstrand> that makes sense
<jjohansen> it can figure it out, currently it doesn't
<jdstrand> for the snapd case, currently it loads and removes one at a time
<jdstrand> I can change snapd to do things of course
<jjohansen> jdstrand: I need to step away, finish your dump and I'll answer when I get back
<jdstrand> jjohansen: ok, good timing. I couldn't find my profiles so it'll take me a minute
<zyga>  jdstrand anything I can help with?
<Chipaca> not for the first time i find myself trying to use markdown in a go comment
<jdstrand> zyga: not at this time
<ikey> Chipaca, backtick all the things
<Chipaca> ikr
<diddledan> flexiondotorg: I've just promoted audacity to candidate - tell the LNL crew that the last of their three desired snaps is snapped
<ikey> lol
<diddledan> oh ello ikey
<diddledan> :-p
 * diddledan tells ikey directly
<zyga> ikey I had that period where everything was pre-formatted and I could not stand otherwise
<ikey> ello diddledan lol
<ikey> zyga, i went so overboard on it i added a markdown parser to solus SC
<ikey> and it has the markdown in the git tags
<ikey> forms our changelogs :P
<zyga> that's pretty nice
<ikey> ref: https://dev.solus-project.com/R3571:37e7f17508ecdedf13f061cad974b2a09ee10687
<ikey> client side: https://ibin.co/3r15d94CbaGW.png
<ikey> some stuff like the CVE IDs automatically link
<jdstrand> jjohansen: ok, I was wrong: load parent, load child, unload child, unload parent works fine: https://paste.ubuntu.com/26541896/
<jdstrand> jjohansen: if I change the load or unload order, then I get ENOENT
<jdstrand> jjohansen: which means, I can make this child approach work. I'll just need to adjust snapd to do something special with load/unload with this approach
 * jdstrand now checks what apparmor does with the cache files
<jjohansen> jdstrand: the cache file is based on the file name that the child profile is in
<jjohansen> so it will get its own cache file if its in a separate file
<jjohansen> if you put them in the same cache file they will share
<jjohansen> if the compiler merges them into a single cache file
<jjohansen> you will get 2 symlinks to the merged file
<jjohansen> note: you won't see that one happen yet
<jdstrand> jjohansen: interesting. so I could keep the text profiles separate, but have a single cache file
<jdstrand> ?
<jjohansen> jdstrand: uh theoretically, the current parser don't actually handle that yet
<jdstrand> heh, ok, then that is out
<jdstrand> but yes, I could put both into the same text file
<jjohansen> but you can cat the 2 binaries together to get a single, and it will work
<jjohansen> jdstrand: another approach is to do
<jjohansen>   profile A {
<jjohansen>     ...
<jjohansen>   }
<jjohansen>   include "children"
<jjohansen> that would put them in a single text file, and allow you to stash the children profiles in separate files that are out of the regular load path
<jjohansen> err, not single text file, single cache file
<jjohansen> jdstrand: the parser will pickup the ability to merge profiles into a single cache file when they are specified on the same parser invocation and they meet certain criteria, but there are a few other things I need to land first
<jdstrand> jjohansen: so if I do 'profile parent {} profile child {}' in the same file, it doesn't work on unload (ENOENT), regardless of order. (load works both ways)
<jjohansen> oh! that would be a parser bug, I wonder when that broke, and why arekm isn't yelling at me
<jdstrand> jjohansen: to be clear, if I have the parent and child in different cache files, apparmor_parser will be sensitive to load order?
<jdstrand> jjohansen: (this is artful btw)
<jjohansen> jdstrand: yes separate cache files will be load order sensitive
<jdstrand> ok. I *should* be able to lexically sort them for cache loading
<jdstrand> and I *could* adjust snapd for handling load/unload order
<ikey> doesn't apparmor_parser already do that? given that you can apparmor_parser load a directory that is purely a binary cache
<jjohansen> sorry, I'll fix it in the parser too, but that will require and SRU which gets us back to the whole doesn't work every where problem
<ikey> and no source files..
<jdstrand> the question for me then becomes, is that better than profile client { profile game{}}
<jjohansen> dammit why didn't you point this out to me 5 years ago
<jjohansen> :P
<jdstrand> ikey: yes but different init scripts do different things
<ikey> yeah i replaced them with aa-lsm-hook in solus
<jdstrand> I need to make sure this works everywhere
<ikey> for the betters
 * jdstrand nods
<ikey> gotcha
<jjohansen> jdstrand: what of
<jjohansen> profile A {
<jjohansen>    include "children"
<jjohansen> }
<jjohansen> that should work
<jdstrand> let me try that
<jjohansen> and allow you to have the children in separate files
<jdstrand> jjohansen: children is a dir?
<jjohansen> jdstrand: that is up to you
<jdstrand> let me try as a file
<jjohansen> you could specify specific files, or have a dir you just drop stuff in
<jjohansen> come to think of it, I think that is what arekm is doing now, and why he isn't yelling at me for the other being broken
<jdstrand> jjohansen: I can't get that to work
<jdstrand> jjohansen: https://paste.ubuntu.com/26542021/
 * jdstrand tries a dir
<jjohansen> jdstrand: in /tmp/child2
<jjohansen>   lose #include <tunables/global>
<jjohansen>  and rename profile snap.steam-client.steam-client//game to just game
<jdstrand> that makes sense
<jdstrand> ok, that works
<jdstrand> I only have to mess with the parent
<ikey> like any good child would..
<jdstrand> it does mean I have to have snapd not do anything with the child profile though
<jdstrand> (as in, load/unload it itself)
<jdstrand> ok, so several options with the child
<jdstrand> 1. embed the child in parent
<jdstrand> 2. have child separate from parent, figure out load order in snapd
<jdstrand> 3. have child separate from parent via #include, adjust snapd to not fiddle with child in interface connections
<jdstrand> these are options I can work through
<jdstrand> jjohansen: my next question is: is there anything different I could try that we haven't discussed?
<jdstrand> jjohansen: eg, apparmor namespace. I don't *think* so since the Px bug I mentioned was filed when playing with apparmor namespaces
<jjohansen> jdstrand: you could use a namespace, I am not sure you want to atm
<jjohansen> the scope isn't separated from the view, so once you enter the namespace
<jdstrand> jjohansen: yeah, I kept trying to think through if that would help anything, but couldn't
<jjohansen> you can't see the rest of the system profiles etc. It more like in a container or VM
<jdstrand> plus, the status of namespace support across distros might make it problematic
<jjohansen> loading into the namespace has the same issues
<jdstrand> oh yeah, that would likely be a lot of trouble too
<jdstrand> ok
<jdstrand> jjohansen: thanks, this was very helpful
<jjohansen> but you could get away with just tearing down the namespace to remove all its policy
<mwhudson> mvo: doh
<jdstrand> jjohansen: in terms of snapd, that change would not be terribly different that just dealing with the parent in option 3
<jjohansen> jdstrand: that said I very much would like snappy to use a namespace, I just need to land the scope work and have it propagate everywhere first :(
<mwhudson> mvo: feel free to upload any fixes you need or tell me what i need to fix...
<jjohansen> jdstrand: right
<jdstrand> jjohansen: yeah. we'll get there
<mvo> mwhudson: its a good question, I need to think about it and probably look at the go upstream diff
<mvo> mwhudson: the change broke both our pkgconfig usage and our LDFLAGS
 * mwhudson goes back to bed for a bit
<mvo> mwhudson: we use -Wl,-Bstatic
<mvo> mwhudson: heh, do it, its not super urgent, I call it a day soon here
<jdstrand> there is also a variation on one, where I modify snapd such that a snap command could end up as an embedded child profile
<jdstrand> but anyway, that is for me to work through
<jdstrand> jjohansen: thanks for all your help!
<jjohansen> jdstrand: np
<jdstrand> jjohansen: there is actually another option. we fix the parser for Px/px and make the use of the interface conditional on that fix being available
<jdstrand> this way, anyone distro who wanted the fix could pull the patch into their parser
<jdstrand> s/anyone/any/
<jdstrand> I'll bring this up to the snapd team
 * kalikiana wrapping up for the day
<mvo> zyga: we will need is-nfs-home: [yes|no] as part of the system-key
<zyga> mmm
<zyga> yes
<zyga> I think so
<mvo> zyga: tests are breaking
<mvo> zyga: without it
<zyga> hmmm
<jjohansen> jdstrand: that works for me too
<mvo> zyga: I need to check, we have a bit of a recursive import problem, some of this code probably needs to go into osutil or something
<zyga> mvo how did it break, I mean, we test this, right?
<zyga> mvo, I forgot where I put the nfs code but yeah
<mvo> zyga: yes, this is where it breaks, the test restarts snapd and assumes it re-genreates security profiles
<mvo> zyga: and we no longer re-genreate on every restart
<zyga> aha, so not broken in the wild, just in an upcoming branch?
<zyga> or broken in the wild now
<mvo> zyga: not broken in the wild
<mvo> zyga: just in 4629
<zyga> ahh
<zyga> god
<zyga> good :)
<zyga> I can fix that if you want
<zyga> can you look at 4640 when you have some time? I will look at nfs part
<mvo> zyga: I would not say no to this offer :)
<zyga> thank you :)
<mvo> zyga: probably in my morning but yeah, I have a look. I'm bit behind in reviews in general, maybe I can have a review-friday
<mvo> zyga: I also wanted to stop pusing new PRs before my others are landed. but this is really hard
<zyga> yeah
<zyga> after this I only have layout spread PR (it depends on it now) and then I'll switch to hardening
<zyga> Chipaca how about you?
<Chipaca> zyga: what about me?
<zyga> fancy doing 4640?
 * zyga looks at nfs untangling
<Chipaca> zyga: doing it right now
<zyga> thank you
<zyga> I want that spread test out there
<zyga> mvo any objections if I move more stuff to osutil?
<zyga> like more of mount
<zyga> I can move it to osutil/mount so that it doesn't cause a massive cluster of alterations if that makes it better
<Chipaca> zyga: do you find "%[1]s %[1]s" % (a,) clearer than "%s %s" % (a, a)?
<zyga> TBH, not really
<Chipaca> zyga: then use the other ones :)
<Chipaca> I mean, if you were passing around an enormous struct by value, it might be worth it?
<Chipaca> but usually it's not
<Chipaca> (in the common case of the thing being a poiner or a simple value, afaict it's more expensive in both memory and time to use the indexed version)
<Chipaca> (add to that that it's less clear... Â¯\_(ã)_/Â¯ )
<Chipaca> like, 300ns vs 200ns for the two-args version
<Chipaca> not that i'd be insane enough to have measured this
 * Chipaca hides
<zyga> :)
<zyga> hahah
<zyga> thank you Chipaca
<zyga> how long does "time go test ./..." in the root of the project take for you guys/
<zyga> mvo that will be one big branch
<kyrofa> jdstrand, yeah I've looked into that one, even grepped the entire snap and can't find where it calls sytemctl. Wonder if it's in a binary somewhere
<mvo> zyga: I like osutil/mount
<zyga> I moved it to osutil now, we'll see how that looks like
<jdstrand> kyrofa: just looking at the logs, seems to be coming from mysql
<kyrofa> jdstrand, yeah, just none of its scripts. I'll take a quick grep of its src
<mvo> zyga: ok, I was thinking it might be easier to use "mount" just like before but of course if we end up with two "mounts" (one in osutil one in interfaces) that sucks
<zyga> yeah :/
<mvo> zyga: anyway, I will wait for the PR :)
<zyga> I'm not done, let's see how it looks like in the end
<jdstrand> ikey: I responded to the forum. I've pinged niemeyer to comment before I proceed
<jdstrand> niemeyer: and I pre-apologize for the walls of text between https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457/14 and https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457/27, but we're pushing the envelope here
<kyrofa> jdstrand, yeah nothing in the source either. No clue what's causing it
<niemeyer> jdstrand: Appreciated!
<jdstrand> greyback: hey, you probably say, but I reviewed pr 4545. lgtm for my stuff, but the changes from zyga prompted some discussion with him
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<jdstrand> s/say/saw/
 * zyga finished a very boring branch just now
<zyga> man
<zyga> the things we have to do to make it compile ;-)
<mup> PR snapd#4641 opened: many: move mount code to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/4641>
<mup> PR snapd#4642 opened: many: add nfs-home flag to system-key <Created by zyga> <https://github.com/snapcore/snapd/pull/4642>
<zyga> jdstrand hey, do you have a sec
<jdstrand> zyga: what's up?
<zyga> https://github.com/snapcore/snapd/pull/4640
<mup> PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640>
<zyga> 65 lines :)
<zyga> it's something I think we need for layouts and ...
<zyga> ... :)
<zyga> could you please look?
<jdstrand> man github reviews are pretty ugly with the use of '%[1]s'
<zyga> yeah, I will change that to %s %s
<greyback> jdstrand: thanks, I'll wait to be told what to do :)
<jdstrand> zyga: I wasn't necessarily saying that. personally I do find it easier to read as %s %s, but I can do either :)
<jdstrand> that said, I'm fine if you change it :)
<zyga> please review as-is, i'll do that separately
<zyga> cool :-)
 * jdstrand nods
 * ikey clicks the forums
<ikey> apologies for le delay
<ikey> also the forums is making me think there is gonna be some kind of zombie event soon
<ikey> massive letters "12 DAYS LATER"
<zyga> jdstrand updated
<jdstrand> ikey: hehe
<zyga> ikey zombie event?
<jdstrand> zyga: that is much easier on the eyes :)
<ikey> zyga, 28 days later :P
<ikey> yknow, rapid moving shoulder munchers
<jdstrand> of course, where did my pending comments go...
<zyga> ikey, you mean stress-eating during weekends?
<zyga> ;-)
<ikey> no i mean literal zombies :P
<ikey> also its not "stress eating". its uhm.. *thinks*.. weekly hormone rebalance therapy.
<ikey> yeaa...
<zyga> "literal zombies"
 * zyga turns the dishwasher on
<ikey> yeah they chase you and say things like "totally" until *you* groan
<zyga> I think my kids are like zombies sometimes
<zyga> jdstrand: after that PR I have spread test for layouts
<ikey> probably a phone app to figure that one out.. ^^
<zyga> it's pushed, just waiting for the PR to land :)
<zyga> jdstrand replied
<zyga> actually edited my response, sorry
<zyga> jdstrand if that's okay with you I will edit the symlink comment
<zyga> eh
<zyga> new golang broke -everything-
<zyga> not a great tay
<zyga> *day
<zyga> jdstrand do you want me to add the examples you listed to unit tests?
<jdstrand> zyga: please see me comment to your comment. yes, more tests please but note that I didn't enumerate everything in the review
<zyga> jdstrand the one with 'more subtle' cannot be detected
<zyga> as yaml will fold the old value and replace with the new one
<zyga> as for remaining tests, I will add some more but the "bind-file" thing is identical in validation to "symlink" and those have a lot of tests already (though not added in that PR)
<zyga> The case where the same source is treated differently is interesting, that is not handled yet
<zyga> it will fail at runtime but it won't get caught by the validator
<zyga> once master is fixed tomorrow I will add those
<mup> PR snapcraft#1908 closed: tests: update tests to work in adt <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1908>
<jdstrand> zyga: ok, so those are keys to a dictionary. That's fine then. we should have a test that shows only one happened imho
<mwhudson> hi when does snapd do the sd_notify thing to notify systemd that it has started up?
<mwhudson> in particular wrt seeding on first boot
<mwhudson> aha systemd.SdNotify("READY=1")
<mwhudson> hm ok looks like it notifies before seeding is known to be done
<mwhudson> hmm the idea of having snapd write the unit looks better i think
#snappy 2018-02-09
<mwhudson> will you guys be trying to get snapcraft 2.39 into bionic RELEASE?
<zyga> maaan
<zyga> its Friday and we are deep in golang build issues
<zyga_> hello
 * zyga rebuilds systemd due to CVEs, meh
<zyga> I made that branch we talked about
<zyga> https://github.com/snapcore/snapd/pull/4641
<mup> PR #4641: many: move mount code to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/4641>
<zyga> and on top of that: https://github.com/snapcore/snapd/pull/4642
<mup> PR #4642: many: add nfs-home flag to system-key <Created by zyga> <https://github.com/snapcore/snapd/pull/4642>
<mvo> zyga: nice, thanks
<zyga> both of those are red because of golang
 * mvo looks
<zyga> after 4641 we could remove some duplicate code that parsed mountinfo in osutil
<mvo> zyga: that sounds good, let me check
<mvo> zyga: fwiw, it fails because of undefine FindUID
<zyga> it fails in cgo
<mvo> zyga: and undefined FindGID
<zyga> this is a cgo issue
<mvo> zyga: it is?
<zyga> it passes in normal go
<zyga> (I didn't push this without testing0
<mvo> zyga: did this also break with the latest go update?
<zyga> hmm, not sure, I didn't push anything else
<zyga> hmm
<zyga> but FindUID was always in that spot
<zyga> mmm
<zyga> ah
<zyga> snap-update-ns had some exception to build with cgo, right?
<zyga> so
<zyga> quick fix
<zyga> we don't need username lookup in mountentry.go
<zyga> we just need the number
<zyga> let me remove that code
<mvo> zyga: \o/
<mvo> zyga: thanks
<mvo> zyga: this is for the static build of snap-exec
<mvo> zyga: so that things work even without a glibc in the core
<zyga> ok, almost done
<zyga> mvo, while I'm testing
<zyga> quick experiment
<zyga> run htop or similar in one terminal
<zyga> go to root of snapd and run: time go test ./...
<zyga> it seems that we have a part that scales well and a part when CPU is not really busy
<zyga> for me it totals at around 1 minute 30 seconds
<mvo> zyga: let me try with "time ./run-checks --unit"
<zyga> no
<zyga> that's idfferent
<zyga> and faaaaar slower
<zyga> it does sequential test for each package
<zyga> the command I used does it in parallel
<mvo> zyga: aha, go test in the new go skips vendor/ right? iirc 1.6 does not
<zyga> (PR updated)
<mvo> zyga: thanks for the update
<zyga> correct
<zyga> if 4641 passes I will push the same patch ot 4642
<mvo> zyga: go test starts with low cpu for me and then speeds up
<mvo> zyga: for me real is about 0m58, user 2m9 and sys 0m14
<zyga> hmmm, interesting
<zyga> on artful?
<mvo> bionic, go1.9
<pstolowski> morning!
<zyga> ah, I'm on 1.8
<zyga> hey pawel
<mvo> hey pstolowski
<mvo> zyga: that might be it, I can try on an artful machine in a bit
<zyga> looking at the output it did run vendor tests here
<zyga> but in any case, did you see a drop in CPU usage during that period?
<zyga> for me it starts high, then drops to sequential
<zyga> for instance cmd is super slow
<zyga> (nothing happens there)
<zyga> er, sorry, the one *after* cmd
<zyga> cmd/snap
<zyga> 25 seconds
<zyga> client takes 10 seconds
<mvo> zyga: yeah, cmd/snap, daemon, overlord are all slow for me, client too
<mvo> devicestate and snapstaet too, might be worthwhile to look at the reasons at some point
<zyga> http://paste.ubuntu.com/26545336/
<zyga> snap-seccomp
<zyga> 85 seconds
<zyga> I think those are those tests that run gcc, right?
<zyga> I wonder if there's some golang testing trick that would let us spawn those as parallel, indepentend tests
<zyga> maybe even using go() itself
<niemeyer> Hello all
<zyga> hey
<zyga> you're up early :)
<pstolowski> morning!
<niemeyer> Moin! Yeah.. will try to do an early Friday today
<mvo> zyga: yeah, snap-seccomp runs a lot of gcc, might be worth looking at too
<mvo> hey niemeyer, good moooorining
<mvo> and we have the new logo in the forum, looks really nice
<mup> PR snapd#4641 closed: many: move mount code to osutil <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4641>
<kalikiana> good morning, snappy
<mvo> zyga: please update the other PR as well (the system-key one)
<mvo> zyga: nevermind, I pushed it
<niemeyer> mvo: Nice, isn't it? Really enjoyed it too
<niemeyer> mvo: The whole design for the new site (not deployed yet) looks really sweet
<zyga> mvo, re
<zyga> thanks !
<mvo> looking forward to see it :)
<mvo> zyga: thank *you*
<mvo> zyga: lets hope tests are happy
<mvo> zyga: also: great that we have this test, it saved our bacon
<mvo> (or tofu)
<zyga> indeed :-)
<zyga> oh, the new logo!
<zyga> I like the subtle separation of snap from craft
<zyga> mvo thank you for initializing nfs home :)
<zyga> I didn't think about that last night
<zyga> mvo can we land 4049?
<mvo> zyga: yes, I thnk so
<pedronis> pstolowski: there is still a comment IÂ made that seem unadressed in #4401
<mup> PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
<pedronis> pstolowski: I recommented on it
<pstolowski> pedronis, oh,i'm sorry about that, missed that somehow. thanks, will look at this
<pedronis> np, thanks for working through this
<mvo> zyga: hm, a peculiar error in the system-key nfs PR, snap-cofine didn't refuse to run
<zyga> oh
<zyga> looking
<zyga> weird
<zyga> just on the three systems?
<mvo> zyga: yeah, really strange, I have not tried to reproduce yet
<zyga> mvo actually, other systems are disabled there
<zyga> hmm
<zyga> hmm hmm
<zyga> my only idea is that something loads that profile
<zyga> and that's probably one of the changes in the PR
 * zyga reviews diff
<zyga> mvo maybe we are killing the profile in the helper test scripts
<zyga> I mean, system key, not the profile
<zyga> mvo actually
<zyga> so
<zyga> I think I see what's going on
<zyga> apparmor initialize starts up
<zyga> then we get into regenerate all security profiles
<zyga> that doesn't do anything
<zyga> hmm, no wait wrong file
 * zyga gets back to square one :/
<mvo> zyga: oh, so we need to keep the current core snap revision in the system-key?
<mvo> zyga: to ensure we always re-generate for the snap-confine on the core snap
<mvo> zyga: woah, our system key needs a lot of input :/
<zyga> well, that's another perhaps
<zyga> I don't know yet
<zyga> I wonder why it clearly regenerated the profile
<zyga> not why it wouldn't generate a profile
<zyga> let me get a coffee and have a deeper look
<zyga> I think system key is long overdue and I cannot wait to see it in production :)
<mvo> zyga: heh, more thorny than anticipated
<mvo> zyga: I will add the core revision and see if that helps
<mvo> zyga: its needed anyway
<zyga> yeah, ok
<zyga> that's actually true anyway because core revision determines apparmor templates
<zyga> so +1 on that
 * zyga got some coffee
<Chipaca> niemeyer: go to be-e-e-ed
<Chipaca> niemeyer: (thank you for the review though)
<Chipaca> good morning all
<niemeyer> Chipaca: Moin :)
<niemeyer> Chipaca: Should have another section of it soon
 * kalikiana will copy zyga and also get coffee
 * Chipaca loves the new branding
<Chipaca> niemeyer: about homes vs users, thinking about it some more
<Chipaca> niemeyer: the tars are already encoding the uids/gids
<Chipaca> niemeyer: should i just go with the uids, internally, and the username->uid translation on the fly?
<niemeyer> Chipaca: On which side?  I think the API should take the username.. internally we probably need to translate into a home at some point
<niemeyer> Chipaca: It wouldn't hurt to keep the uid as well, though, at least in the metadata
<Chipaca> niemeyer: to be able to alert when things change and restore would mess things up?
<Chipaca> sgtm
<Chipaca> api being username sounds a'ight (although it will mean having to do user lookups, which seems to kill spread on 14.04)
<niemeyer> Chipaca: One more round on your way.. cmd/snap this time
<Chipaca> niemeyer: just seen it
<Chipaca> niemeyer: is the 'internal spacing' about the space in '2m ago', and in 'yyy-mm-dd hh:mm:ss'?
<Chipaca> niemeyer: yes i can make the latter use T instead of space
<Chipaca> niemeyer: for the former, i don't know how to drop the space without it losing meaning
<niemeyer> Chipaca: Yeah, exactly
<mvo> zyga: I added the core rev now but the security-setuid-root will not be fixed with this :/
<niemeyer> Chipaca: 2mins
<Chipaca> (i could cheat and use something that looks like a space but isn't! that'd help machine parsing)
<zyga> yeah, I suspect it's something else
<Chipaca> niemeyer: i mean, i can drop the 'ago' if you think it's obvious
<zyga> I'm really puzzled, it must be something obvious but I cannot see what would cause this from the diff
<Chipaca> i added it because it seemed wrong without
<niemeyer> Chipaca: Right, I think it's fine.. it's implicit from context
<Chipaca> ok
<niemeyer> Chipaca: Thinking about it now, it's probably nicer either way, even if we didn't care about the spacing
<niemeyer> Chipaca: The "ago" will get boring quickly on a long listing
<Chipaca> true
<Chipaca> oops i forgot to change 'lost to the ages' back :-)
<Chipaca> â¦ and the "is probably *fine*" one!
<Chipaca> heh
<mvo> zyga: I have a debug shell now, I see that the apparmor profile for the snap-confine for the core rev is loaded (but not on disk)
<zyga> is it possible that
<zyga> 1) the profile is gone because of the test scripts and how they restore state
<zyga> 2) the profile is in memory because prior test loaded it and we don't unload them in test restore scripts
 * Chipaca waiting for spread to finish so he can fire off another spread, but really should leave for physio
<mvo> zyga: yeah, I think its something like this, the details are still a bit blurry to me, I ran the the test standalone and got no error
<mvo> zyga: eh, got *an* error
<zyga> oh
<zyga> well, that's possible too
<zyga> the prepare for suite would load snapd
<zyga> and that would keep the profile loaded
<zyga> I don't think we actually unload anything in tests, right?
<zyga> oh drat
<zyga> I made the coffee and never picked it up
<mvo> zyga: I think I have an idea, testing it now
<zyga> mvo yeah? let me know once you have the result, I'm curious :)
<alexlarsson> jamesh: Are you around? Or anyone else involved in snappy on the desktop? I would like someone to take a spin with https://github.com/flatpak/xdg-desktop-portal/pull/155
<mup> PR flatpak/xdg-desktop-portal#155: Support snap <Created by alexlarsson> <https://github.com/flatpak/xdg-desktop-portal/pull/155>
<zyga> hey
<zyga> hey alexlarsson :)
<alexlarsson> hey
<jamesh> alexlarsson: hi.  I'll give it a spin
<zyga> oh excellent, jamesh is still up :)
<alexlarsson> It depends on https://github.com/flatpak/xdg-desktop-portal/pull/154
<mup> PR flatpak/xdg-desktop-portal#154: Add application info abstraction <Created by alexlarsson> <https://github.com/flatpak/xdg-desktop-portal/pull/154>
<alexlarsson> Which would be good if it could get separate reviews, but all the commits from that is in the other pr too
<alexlarsson> jamesh: i don't really have a snappy setup so i kinda coded the apparmor stuff blindly
<alexlarsson> jamesh: also, there are some todos that you might want to look at
<ikey> oh shiny
<alexlarsson> I'm hoping we can release a xdg-desktop-portal with the document portal and snappy support next week
<alexlarsson> Then i can do complementary flatpak releases with it removed
 * Chipaca -> physio, finally
<jamesh> alexlarsson: we don't yet have the portal support ready in master yet, so it isn't exactly trivial to test out at the moment
<alexlarsson> jamesh: you can test with gdbus from a snap
<alexlarsson> jamesh: In fact, maybe you can just put https://github.com/matthiasclasen/portal-test in a snap?
<alexlarsson> jamesh: I guess you need dbus aa rules to grant access to org.freedesktop.portal.*
<jamesh> alexlarsson: that's what I used when I was working on a prototype for this last year: https://github.com/jhenstridge/portal-test/blob/snap-pkg/snap/snapcraft.yaml
<alexlarsson> jamesh: But, at the very least you could add some debug printfs in the portal and see if it gets the right app id
<jamesh> I probably need to change that packaging a bit though
<alexlarsson> jamesh: also, i *think* i got the app id validation right by looking at the glob for snap package names, but please verify that
<alexlarsson> gdbus call --session --dest org.freedesktop.portal.Desktop --object-path /org/freedesktop/portal/desktop --method org.freedesktop.portal.OpenURI.OpenURI "" "https://gnome.org" {}
<alexlarsson> is a simple thing to test
<alexlarsson> Well, that actually doesn't really check the app id, so maybe not the best test...
<alexlarsson> But if you combine it with some added printfs to your xdg-desktop-portal you should get some basic validation
<zyga> alexlarsson thank you :-)
<alexlarsson> np
<alexlarsson> I really don't want app developers to have to target multiple apis
<alexlarsson> we need to share this shit
<ikey> not sure anyone was planning anything different, no..?
<zyga> yeah, that's very much true
<jamesh> alexlarsson: agreed.  I don't want to repeat all the work that's been done for GTK and Qt integration.
<alexlarsson> ikey: no, that was always the idea, but it need to also get done
<ikey> ah gotcha
<ikey> set a stable baseline now..
<mvo> zyga: quick question> kernel version as part of system-key: yes/no?
<zyga> ok, I think I got the validation right now
<zyga> oh
<zyga> actually
<zyga> version is not of much use
<zyga> I'd say no unless you have a clear need
<zyga> mvo we could keep bugs: []
<zyga> ;-)
<zyga> if kernel bugs are bugging us
<mvo> zyga: aha, thats good, yeah, we can create: bugs: [foo] when we need it
<mvo> zyga: cool, thank you
 * ogra_ wonder what the new bird logo on the forum is meant to represent
<sparkiegeek> ogra_: it's the snapcraft logo... it represents snappy  :)
<ogra_> haha
<ikey> pretty banging logo though
<zyga> it could animate
<ikey> also it hidpis on the site favicon
 * ikey is happy
<zyga> it's nicely hidpi
<zyga> yeah
<ikey> lol
<zyga> it scales all the way
<ikey> "snappy takes flight" â¢
 * ikey also cringes
<ikey> wait does this make solus (budgie) and snappy birds of a feather? :P
<zyga> twin engine bird
<ikey> lol
<ogra_> hey ... https://docs.ubuntu.com/core/en/reference/interfaces/shows a "network-status" interface but snap interfaces in 2.30 does not ... did we lose something since 2.25 ?
<ogra_> mvo, ^^^
<ogra_> (or zyga )
<zyga> I think I know
<zyga> just checking
<zyga> yeah
<zyga> it's not implicit
<zyga> it's just there but you need an snap to carry it
 * ikey unsubs from mir notifications on github
<ogra_> Trevinho, ^^^
<ikey> just reminds me how little im doing myself..
 * zyga rethinks that validation
<zyga> can be done faster and much more easily than now
<zyga> by tracking source and target constraints separately
<niemeyer> pedronis: Reviewed most of #4497
<mup> PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
<niemeyer> pedronis: Please have a look and let me know if you like the proposal
<niemeyer> pedronis: Will take a coffee break and will review the server end
<pstolowski> pedronis, do you have a moment?
<Chipaca> so many non-powered-off-servers
<pedronis> pstolowski: now, IÂ was having lunch
<pstolowski> pedronis, ok, i need to run to school now, will be back in ~10 min
<pstolowski> pedronis, will ping you for a quick HO before the standup if thats ok
<pedronis> ok
<pedronis> niemeyer: from quick look proposal seems reasonable, it means the client becomes stateful though, will take me a bit to get back to that PR though
<zyga> woot
<zyga> it works :)
<pstolowski> pedronis, can you join standup HO?
<mvo> zyga: fwiw, 4642 is green now
<zyga> oh
<zyga> oh standup
<zyga> mvo so it was the test setup!
<zyga> cool
<zyga> mvo shall we merge it?
<zyga> jdstrand hey
<mvo> zyga: maybe we can look over it again just in case
<zyga> I think pawel or chipaca could look
<mvo> zyga: one independent review would be cool, maybe Chipaca or pstolowski
<mvo> zyga: heh
<zyga> :D
<Chipaca> sure
<zyga> it's funny, no?
<Trevinho> ogra_: oh ok... It was my guess too after re-reading
<Trevinho> Network observer should be enough though
<ogra_> Trevinho, yeah
<Trevinho> But what we'd need is a connection status one
<Trevinho> With auto connection
<Trevinho> Although qt also needs to be fixed not to require too many infos
 * kalikiana going out for lunch, back later
<jdstrand> zyga: hey
<zyga> jdstrand hey, I added the validation we spoke about last night and I will add some more (about things we didn't talk about)
<zyga> well, at least not yesterday
<zyga> I think we mentioned this long ago but we didn't black-list /proc and other similar places
<zyga> I will do that
<jdstrand> zyga: more in that pr or more in a future pr?
<zyga> I also merged master into jamesh branch
<zyga> jdstrand it can be separate, it's not related to that PR directly
<zyga> I will look at one function that was meant to validate if a mount operation worked
<jdstrand> zyga: so, technically /proc isn't a security issue (since they are just putting something they already have read/write access to in there. it isn't going to fakeout the actual kernel), but it is going to be an error
<jdstrand> in the snap if it is doing that
<jdstrand> zyga: so +1 on filtering /proc, /sys, /lost+found, and /dev
<zyga> I agree but I think it's sensible to be conservative
<zyga> oh
<zyga> lost and found
<zyga> good one
<zyga> noted
<jdstrand>  /boot and /run probably also make sense
<zyga> jdstrand as for 3963, I might look at splitting it to help
<jdstrand> but, eh
<jdstrand> we can always open it up more later, so seems safe to block these weird ones
<zyga> yes, that's the principle I think
<zyga> phase 1, conservative approach
 * jdstrand nods
<jdstrand> as for 3963, thank you
<jdstrand> it is *so* close
 * zyga looks at `snap/validate.go:276:20: "compatiblity" is a misspelling of "compatibility"` and sighs
<niemeyer> pedronis: Yeah, we'd update it on every request, whether "maintenance" was set or not
<niemeyer> pedronis: I think that reflects well the semantics on the server end
<zyga> jdstrand the new validation logic resulting from last night's discussion is: https://github.com/snapcore/snapd/pull/4640/files#diff-b76be54ad28535ed9b0ac36a2851516eR240
<mup> PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640>
<jdstrand> zyga: so, I'm seeing things like this:
<jdstrand> if layout.Bind != "" {
<jdstrand> if layout.BineFile != "" {
<jdstrand> and I wonder why that isn't if/else if
<zyga> no reason, but it doesn't change anything
<jdstrand> which makes my wonder if this is not caught:
<pstolowski> zyga, reviewed 4642
<jdstrand>  /foo:
<jdstrand>    bind: ...
<jdstrand>    bind-file: ...
<zyga> this is caught by existing validation that's older than this pr
<zyga> you can barely see it ...
<jdstrand> zyga: are there tests for it?
<zyga> https://github.com/snapcore/snapd/pull/4640/files#diff-b76be54ad28535ed9b0ac36a2851516eR560
<mup> PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640>
<cachio_> pedronis, results on staing https://paste.ubuntu.com/26546594/
<cachio_> still 6 tests failing
<zyga> yes, though not for every possible combination
<zyga> I can add more :)
<zyga> it's been a learning exercise so far
<zyga> https://github.com/snapcore/snapd/pull/4640/files#diff-0c50c794f66e17a6bf61861029a83e21R533
<zyga> actually I did, sorry,
<zyga> I just see it in the diff now
<jdstrand> zyga: right, so that isn't going to catch this:
<jdstrand>  /foo:
<jdstrand>    bind: ...
<jdstrand>    symlink: ...
<zyga> no, it does
<zyga> it catches it
<zyga> you must use exactly one of the kind definers
<jdstrand> oh nused
<jdstrand> I was looking at something different
<zyga> yeah, number of things used
<jdstrand> if you can add a test for that, it would be great
<zyga> yeah, I did for that exact case
<jdstrand> I <3 negative tests
<jdstrand> ok
<zyga> https://github.com/snapcore/snapd/pull/4640/files#diff-0c50c794f66e17a6bf61861029a83e21R533
<mup> PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640>
<zyga> I'm sure there are some things I didn't cover, I will go over it again
<jdstrand> I'm looking only at a particular commit. I'll look at the whole thing again
<zyga> I was thinking how to do the source validation and I was thinking about various options
<zyga> I like one test
<zyga> I'm sure you will love it
<zyga> https://github.com/snapcore/snapd/pull/4640/files#diff-0c50c794f66e17a6bf61861029a83e21R744
<zyga> btw, what _is_ norf and corge?
<jdstrand> I think it is too early for me to review the mind-bending '// Validate mutual compatiblity between otherwise valid layout elements.'
<zyga> hehe
<zyga> that means I can do something about lunch :)
<jdstrand> zyga: extra meta vars beyond foo, bar, baz, qux, quux
<zyga> jdstrand but are those dog naems?
<zyga> *names
<pedronis> cachio_: snap info seems to need some upload,  searching might need uploads and store admin to set featured/sections in staging
<jdstrand> norf certainly isn't
<jdstrand> corge I've wondered on the pronunciation
<jdstrand> looks like corg-y
<jdstrand> I always pronounced it corj
<pedronis> cachio_: create user is not finding mvo on staging, might have other issues as well, not sure
<zyga> oh
<zyga> wait, you found some dead code
<pedronis> cachio_: IÂ don't understand the refresh-amend error, it seems a test vs code mismatch
<zyga> that mutual compatibility thing is supposed to be gone
 * zyga yanks it
<jdstrand> thank goodness
<pedronis> cachio_: IÂ mean, it seems like an error message has changed
<jdstrand> :)
<cachio_> pedronis, yes, it changed recently
<cachio_> I saw the same error on bionic
<mvo> pedronis: uhh, why are we not seeing the error in other spread runs if its a real error due to code change?
<pedronis> cachio_: probably we need to upload a newer core?
<pedronis> other issues look like core is old
<pedronis> IÂ mean tests take core and change snapd etc in it
<mvo> aha, ok
<mvo> old core makes sense
<mvo> sorry for the noise
<pedronis> mvo: well, the amend one is not clear
<pedronis> that is not related to pieces in core
<pedronis> is a bit strange
<pedronis> but IÂ didn't get it either
<pedronis> heere
<pedronis> but xdg-* stuff looks like old core
<cachio_> pedronis, I'll run with the latests changes
<pedronis> cachio_: IÂ mean, it seems like we need to copy over a recent edge core to staging core edge
<pedronis> cachio_: and we need some uploads/reuploads for snap-info
<pedronis> cachio_: searching needs vlc  and to talk with store people about setting some section/featured stuff in staging
<cachio_> pedronis, ah, ok, I'll update the core in staging
<cachio_> pedronis, is it ok if I just update for amd64?
<cachio_> do we need it on other archs?
<pedronis> no just amd64
<pedronis> is fine
<Chipaca> zyga: mvo: you now have too many reviews of #4642
<mup> PR #4642: many: add nfs-home flag to system-key <Created by zyga> <https://github.com/snapcore/snapd/pull/4642>
<mvo> Chipaca: thanks, looking
<kalikiana> re
<jdstrand> zyga: hey, in case you didn't see, I commented on 4640
<zyga> yes, I'm responding now, thanks! :)
<zyga> done
<jdstrand> roadmr: hi! thanks for syncing r1000. to be clear, you will also update the list of packages to install?
<roadmr> jdstrand: yes, that means the merge is a bit more involved than usual. I need to first land the dependency change and ensure it doesn't break staging, then merge the tools bump and test thoroughly
<zyga> jdstrand so I think 4640 is good now, I will work on a new branch that makes special filesystem mount points off limits
<zyga> pstolowski, Chipaca - thank you for the feedback
<pstolowski> zyga, yw
<Saviq> Trevinho: hey, should clicking on links in telegram-desktop work?
<Saviq> seems to be NOOP here
<Saviq> that's GNOME@Wayland@bionic
<jdstrand> roadmr: right. I thought I remembered you saying something to that effect in cape town. thanks!
<roadmr> jdstrand: np! no worries, we'll make this happen
<jdstrand> roadmr: which is also why I went the more formal bug route :)
<jdstrand> zyga: yep, approved. thanks!
<zyga> wooot
<zyga> thank you!
<jdstrand> zyga: it's so close!
<jdstrand> that and user mounts are going to rock
<zyga> yeah, I need to jump onto user mounts
<zyga> but I want to ensure we don't leak the poorly confined snap-update-ns
<zyga> I need to finish that too
<zyga> though it's super close, I have code for most of that now
<zyga> just chopping and reviews
<seb128> Saviq, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1742687 maybe
<mup> Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <AppArmor:New> <D-Bus:New> <snapd (Ubuntu):In Progress> <https://launchpad.net/bugs/1742687>
<seb128> Saviq, what snapd version do you use? the fix is in proposed only
<Trevinho> Saviq: mh,they work here.... let me check
<Trevinho> Saviq: what channel?
<Trevinho> or revision, better
<Saviq> Trevinho, seb128: http://paste.ubuntu.com/26546844/
<seb128> Saviq, and snapd?
<Trevinho> Saviq: you get anything on terminal? Also have you snapd-xdg-open or how it was called or not (I don't)
<Saviq> 2.29.4.2+18.04
<seb128> right, that doesn't include the fix
<seb128> see what I copied before
<seb128> try the snapd from bionic-proposed
<Saviq> ack, tx
 * Saviq tries
<seb128> yw
<seb128> let we know if it fixes it
<Trevinho> seb128: about that...
<Trevinho> seb128: is there any reason why we don't want file:// ... protocol to work when the target is a directroy?
<Trevinho> directory*
<Trevinho> and then opening it with the file-manager?
<Trevinho> as telegram requires that sometimes, and so other apps
<Saviq> Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.1572" (uid=1000 pid=29767 comm="dbus-send --print-reply --session --dest=io.snapcr" label="snap.telegram-desktop.telegram-desktop (enforce)") interface="io.snapcraft.Launcher" member="OpenURL" error name="(unset)" requested_reply="0" destination="io.snapcraft.Launcher" (bus)
<Saviq> Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
<Saviq> sry
<Saviq> Trevinho: I don't see snapd-xdg-open, only xdg-open, and when ran inside `snap run --shell...` it does print â, as does Telegram itself
<seb128> Saviq, dunno what you needs to reload for the snapd update to work, maybe try rebooting?
<Saviq> prolly apparmor profiles or something, will reboot in a mo
<seb128> Trevinho, that would be to check with the security team, I didn't give much thinking of the implications
<Trevinho> mdeslaur: something is popping up in your mind? ^
<mup> PR snapd#4640 closed: snap,interfaces: allow using bind-file layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4640>
<Trevinho> might be the case to ask to jdstrand too when back
<mup> PR snapd#4643 opened: snap: disallow layouts in various special directories <Created by zyga> <https://github.com/snapcore/snapd/pull/4643>
<zyga> jdstrand https://github.com/snapcore/snapd/pull/4643/files
<mup> PR #4643: snap: disallow layouts in various special directories <Created by zyga> <https://github.com/snapcore/snapd/pull/4643>
<zyga> that's the quick list
<zyga> now I realized that mountedTree and mountedFile are exactly the same, I'll simplify them
<mdeslaur> Trevinho: sorry, jdstrand would be best to answer that question
<kalikiana> Damn my greedy organism, need to fetch more water. Don't want to take a break...
<jdstrand> Saviq: the apparmor denial is because the service isn't started yet and the service file doesn't have the magic directive to make it work
<zyga> jdstrand and https://github.com/snapcore/snapd/pull/4644
<mup> PR #4644: tests: add a spread test for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4644>
<zyga> :-)
<jdstrand> Saviq: I didn't read all of backscroll, but you need the dbus service file coming from an updated snapd *deb*. an updated core is not enough
<mup> PR snapd#4644 opened: tests: add a spread test for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4644>
<zyga> jdstrand both are pretty obvious +1's :)
<jdstrand> zyga: ack
<zyga> and with that I'm done on the quick branches
<Saviq> jdstrand: I got snapd from proposed, do I need non-stable core?
<jdstrand> Saviq: this is the pr: https://github.com/snapcore/snapd/pull/4495/files
<mup> PR #4495: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4495>
<jdstrand> Saviq: no, you shouldn't
<Saviq> ack
 * zyga takes an extended break
<jdstrand> Saviq: you have AssumedAppArmorLabel=unconfined in the service files? grep AssumedAppArmorLabel=unconfined /usr/share/dbus-1/services/io.snapcraft.*
<jdstrand> Saviq: did you restart your session?
<Saviq> not yet, doing that now
<jdstrand> Saviq: I think you'll need to restart the session for it to take effect
<Saviq> jdstrand: I rebooted, same problem
<Saviq> and yes I do have this ââ in the service files
<jdstrand> Saviq: that's weird. mvo, iirc, you tested this ^
<jdstrand> Saviq: are there any apparmor denials in the logs?
<Saviq> jdstrand: not in dmesg, yes on the console
<Saviq> exactly what's mentioned in the bug
<jdstrand> Saviq: don't look at dmesg, look at journalctl (dbus denial for the session bus are logged through syslog, not the audit system)
 * jdstrand fires up a vm
<Saviq> lut 09 17:07:23 michal-laptop dbus-daemon[6341]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/io/snapcraft/Launcher" interface="io.snapcraft.Launcher" member="OpenURL" mask="send" name="io.snapcraft.Launcher" pid=2
<Saviq> 1423 label="snap.telegram-desktop.telegram-desktop"
<Saviq> jdstrand: â
<jdstrand> Trevinho: https://forum.snapcraft.io/t/allowing-xdg-open-to-open-files/3789/1
<Saviq> (among a guanoload of gnome shell stack traces...)
<jdstrand> Saviq: can you paste /var/lib/snapd/profiles/snap.telegram-desktop.telegram-desktop ?
<Saviq> jdstrand: https://paste.ubuntu.com/26546956/
<Trevinho> jdstrand: ok, fair... I just was wondering if there some explication on file + directory path though. As I can see that  a single file might be different,but a trusted file-manager could be a different thing
<Trevinho> or just always opening file:// with the file-manager so that it only selects the file, then it's up to the user to open it
<Trevinho> as an interim solution to portals
<jdstrand> Trevinho: feel free to add a comment about opening a directory. I suspect that is a bit trickier since userd is launching the file manager, not the snap, so the filemanager would somehow need to pass on open fd or the security policy would need to be adjusted to allow the open if only the filename is passed back
<jdstrand> Trevinho: which is what portals aims to address
<jdstrand> Trevinho: if you have details on how it could work with existing confinment, please share. note that portals is closer than you might think
<Trevinho> jdstrand: wait, I'm not talking of opening a dir... but showing a file in a dir, does it need to send bak anything?
<Trevinho> jdstrand: I just would like something like the xdg-open does for a browser, but doing it using the file-manager instead
<jdstrand> Trevinho: a snap calls xdg-open on a dir. userd opens nautilus. how does the snap get access to the file the user chooses?
<Trevinho> No, it has not to choose
<Trevinho> like in telegram, when you download a file... It says: "show it on folder" and it would open the filemanager at that position
<Trevinho> like firefox does when you do "open on dir".. or similra
<Trevinho> containing dir I mean
<jdstrand> isn't that when people normally call xdg-open with a dir? this came up in another forum post where a snap was doing precisely this (a poor man's file chooser)
<jdstrand> Trevinho: that specific case would be fine imo
<jdstrand> Trevinho: please comment in the topic. (we want to allow file:// for userd, there is just some work to be done to make sure it is sane. perhaps dir is the first use case)
<Trevinho> we can just redirect all the file://path/foo to call org.freedesktop.filemanager to only show content
<Trevinho> so it won't be any dangerous
<Trevinho> there's a ShowItems call which does it..
<jdstrand> opening a dir so the user can choose the file to open with whatever mime handler is available is totaly fine imo
<Trevinho> ok
<Trevinho> cool
<Trevinho> jdstrand: I could also contribute if you guide me, or... I can leave things to you guys happylier too :D
<jdstrand> I mean, there are phishing attacks where a bad snap could present a directory it controls with malicious stuff and try to get the user to click stuff
<jdstrand> Trevinho: present your ideas in the forum and once there is general agreement, I think pursuing a PR is fine. /me isn't tasked with implementing this, but would review the PR
<Trevinho> jdstrand: mh, right... that's indeed a different thing. However, it's also true that this might happen with a browser too
<jdstrand> very much so
<jdstrand> we'll want to think about that case so that we make an active decision about it
<jdstrand> as in, we ignore that or we try to do something about it
<jdstrand> it is fun to think about pointing a url at a snap's httpd if the user goes to say, bank of america
<jdstrand> the browser has protections on that though-- like, you clearly see the url, EV certs, https verification, etc
<jdstrand> we might be able to rationalize doing nothing if the file browser is clear
<Trevinho> it's beauty of it... Break the system, but your container is the system :D
<cachio_> mvo, is it ok if I register your suer in staging store?
<mvo> cachio_: sure
<cachio_> tx
<cachio_> mvo, perhasps you need to do it
<cachio_> is it requesting ubuntu one authentication
<mvo> cachio_: in a meeting right now, lets talk in 10min
<cachio_> mvo, we need the user with email: mvo@ubuntu.com
<cachio_> mvo, np
<mvo> cachio_: whats the store url? where do  I need to register
<cachio_> mvo, https://login.staging.ubuntu.com/BERkIKYcyn847YYR/+login
<mvo> cachio_: or, the next silly question, what is the staging store url?
<mvo> cachio_: https://dashboard.staging.snapcraft.io/snaps/ - I guess?
<pstolowski> pedronis, i've just addressed the missing bit in autoconnect-tasks PR
<mvo> cachio_: ok, I should be registered now
<cachio_> mvo, tx
 * kalikiana wrapping up for EOD/ EOW
<cachio_> mvo, https://paste.ubuntu.com/26547147/}Getting this error in staging
<cachio_> mvo, creating your user
<cachio_> mvo, any idea why it did not work after you registered it?
<pstolowski> eow o/
<mvo> cachio_: hm, no idea, also error 500 sounds strange, probably worth talking to the store people about it
<mup> PR snapd#4645 opened: snapctl: allow `snapctl get` from any uid <Created by mvo5> <https://github.com/snapcore/snapd/pull/4645>
<jdstrand> Saviq (cc seb128): I was wrong. so, the snapd deb only adds the magic to the Settings service file. if you install the core snap from candidate, it has the updates for both Settings and Launcher, and snapd puts it into place in /usr/share/dbus-1/services
<jdstrand> Saviq: put another way: snap refresh --candidate core, restart your session and it should work
<jdstrand> Saviq: I just verified with the spotify snap
<Saviq> Ack!
 * diddledan makes his presence known by pretending to be a zombie
 * ikey sets fire to ctrl+z
<diddledan> ikey: that sounds like you made a booboo
<diddledan> ?
<ikey> no i was protecting against future zombies
<diddledan> I refuse to use nano because it encourages me to remember ctrl+w as the "find" feature, and then I close random windows when I'm trying to find in other apps
<ikey> lol
 * ikey only uses nano for CLI editing
<ikey> well that and "echo blah >>"
<jdstrand> mvo: you might be interested in what I mentioned to Sav iq ^. basically, what is in bionic-proposed doesn't have the full fix for the launcher not launching. core from candidate does fix things up though
<mvo> jdstrand: oh, that is good to know, thank you
<mvo> jdstrand: hm, i downloaded the bionic-proposed deb and checked io.snapcraft.{Launcher,Settings}.service in gdebi and they have the AssumedApparmorLabel=unconfined
<Chipaca> ikey: CLI editing, as in "oh this command is getting too long, ^X^E"?
<ikey> oh i dont vim
<ikey> or emacs
<ikey> also in my head emacs is a hair removal cream
<ikey> so im totally avoiding it
<jdstrand> mreed: that... is weird. I specifically uploaded to snapd in bionic-proposed and only saw it in settings (this was in a vm). I'm confused
<jdstrand> updated*
<jdstrand> mreed: nvm
<Pharaoh_Atem> :P
<mup> Bug #1748510 opened: shell's test gives false positive on readability of files <Snappy:New> <https://launchpad.net/bugs/1748510>
<Chipaca> ikey|afk: ^X^E on bash opens $EDITOR on current commandline
<Chipaca> ikey|afk: completely unrelated question: is solus' encrypted home a LUKS thing, or is it something more weird?
<ikey|afk> luks
<ikey|afk> we dont do encrypted home, only FDE
<ikey|afk> in future we'll support more specific schems
<ikey|afk> *scherms
<Chipaca> right, encrypted home partition
<ikey|afk> ..
<ikey|afk> *schemes
<ikey|afk> no i mean the entire thing is encrypted
<ikey|afk> its only supported in full disk mode on our installer right now
<ikey|afk> cuz laziness
<ikey|afk> but yeah its just normal LUKS
<Chipaca> cool
<ikey|afk> ok im gonna dash, gotta go make myself look hooman for tonight
<ikey|afk> might take a while ...
<cachio_> pedronis, all the tests passing in staging now
<mup> PR snapcraft#1904 closed: lxd: raw.idmap expects host and container id respectively <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1904>
<mup> PR snapcraft#1913 closed: elf: pyelftools to parse ELF files rather than readelf <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1913>
<pedronis> cachio_: thank you
#snappy 2018-02-10
<mup> PR snapd#4646 opened: snap-seccomp: fix cgo pkg-config and LDFLAGS <Created by stapelberg> <https://github.com/snapcore/snapd/pull/4646>
<thresh> hi.  we're shipping a snap for VLC, which is themed nicely in Ubuntu, but shows a default ugly GTK-looking (?) theme when launched under Kubuntu.  The interface is in Qt.  How do I fix that?
<izznogooood> Is there a way to search for --edge snaps ? Releases by others?
<Chipaca> not at this time
<izznogooood> Thanks.
<erio> hey
<erio> I have a folder meta/gui with appname.desktop and appname.icon
<erio> erh
<erio> appname.png
<erio> but my prime/meta/gui is coming empty
<erio> when I run snapcraft
<erio> do I have to reference meta/gui somewhere in the snapcraft.yaml for it to work?
<erio> https://forum.snapcraft.io/t/love-snap-template-help-for-game/3944/3
<erio> I stated everything in the forum
<erio> :(
<erio>  Sorry, I don't know anything about ircquiet
<erio> got this message
<erio> ?
<erio> hello
#snappy 2018-02-11
<cachio_> pedronis, np, just ping me in case you see any test failinf
<mup> Bug #1619928 changed: snap app: access denied: list a FS tree <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1619928>
<mup> PR snapcraft#1922 opened: elf: fast track when the host used matches the base <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1922>
<mup> PR snapd#4647 opened: cmd/snap: fix UX of snap services <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4647>
#snappy 2019-02-04
<mborzecki> morning
<mvo> hey mborzecki ! good morning!
<mvo> mborzecki: did you had a good weekend?
<mborzecki> mvo: tried to watch some streams from fosdem, but kids didn't give me much chance
<mvo> mborzecki: heh
<mborzecki> lots of snow today :/
<mvo> mborzecki: no snow anymore here - the kids are disappointed
<mborzecki> mvo: any news from zyga yet?
<mup> PR snapd#6387 closed: client, daemon: introduce helper for querying snapd API for the list of slot/plug connections <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6387>
<mborzecki> mvo: do we need to cary any patch for https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814355 in snapd?
<mup> Bug #1814355: snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression) <regression-update> <verification-done> <verification-done-bionic> <snapd (Ubuntu):Confirmed> <snapd (Ubuntu Bionic):Fix Released> <https://launchpad.net/bugs/1814355>
<mvo> mborzecki: yes, PR coming any second
<mborzecki> ok
<mvo> mborzecki: also we broke postgresql which uses /var/lib/postgresql
<mup> PR snapd#6470 opened: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
<mvo> mborzecki: most unfortunate
<mborzecki> heh
<mvo> mborzecki: the PR for the generator fix took a little bit longer because of the spread fix
<mborzecki> mvo: on the upside, once we gather all the workarounds now, these problems won't appear in future relases (hopefully)
<zyga> Hey
<mborzecki> zyga: congratulations!
<zyga> mvo: I will be able to work for half of today
<zyga> Iâm pretty tired, not much sleep due to all the emotions :-)
<zyga> Thank you, the mother and the baby are doing great :-)
<mborzecki> zyga: great news :)
<zyga> mvo: how can I help?
<mvo> zyga: hey, good morning
<mvo> zyga: CONGRATS
<mvo> zyga: take it easy and enjoy this very special time
<zyga> I will have some time for work so I would like to focus on whatever matters the most
<zyga> Do we need another patch for postgresql?
<mvo> zyga: yes, I push something shortly
<zyga> Ok
<mvo> zyga: I push somehting minimal in 5min for review (would love your opinion) and then force-push a spread test once I'm done with it
<zyga> Ok
<zyga> mvo: silly question? How did we break Postgres? Is it classic Postgres running snaps or snapped Postgres?
<mup> PR snapd#6471 opened: [RFC] snap-confine: fix classic snaps for users with /var/lib/* homedirs <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6471>
<mvo> zyga: its a classic snap
<mvo> zyga: ^- this should explain things
<pedronis> zyga: congratulations!
<pedronis> mvo: we are getting this in spread tests (which are also very flaky):  The following packages have unmet dependencies:
<pedronis>  snap-confine : Depends: snapd (= 2.32.5+18.04) but 2.37.1+18.04 is to be installed
<pedronis> E: Unable to correct problems, you have held broken packages.
<pedronis> https://api.travis-ci.org/v3/job/488175953/log.txt
<zyga> pedronis: thank you :-)
<mvo> pedronis: hm, that might be a short glitch when the mirrors got updated, is that recent? let me quickly check
<mvo> pedronis: there was a bit of turmoil over the weekend because the snap generator for systemd broke things (because of bugs in systemd )
<pedronis> mvo: that seems very unfortunate
<mvo> pedronis: archive.u.c seems to be fine, just checked
<mvo> pedronis: it is
<mvo> pedronis: this is why we have 6470 now
<pedronis> mvo: anyway I worked a bit over the weekend, some PR's up, but sprea tests are flaky
<mvo> pedronis: I saw the PRs, thank for those
<mvo> pedronis: yeah, we need to make another push on the tests to make them more robust
<mborzecki> mvo: left a comment in #6470 i can test it locally and push a fix there
<mup> PR #6470: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
<mborzecki> pedronis: morning
<mvo> mborzecki: excellent point, yeah, feel free to push
<mborzecki> mvo: ok
<mvo> mborzecki: then the above exit 0 needs to go as well
<mborzecki> mvo: yup
<mvo> mborzecki: also we are probably fien with [ "18.04" = "$..." ] (no need for bashim with [[ and == here AFAICT - sorry, this is like a hyper nitpick :/ OCD or something on my part)
<mborzecki> mvo: hahah ok :)
<zyga> mvo: ah, indeed, classic
 * mvo hides a bit
<mvo> zyga: yeah, the mount we added in snap-cofine.c I think is actually not needed
<zyga> Hold on
<mvo> zyga: in the original fix
<zyga> For classic snaps /var/lib is the host /var/lib
<zyga> How is it broken?
<mvo> zyga: exactly
<mvo> zyga: we prevent snap-confine to write to it
<mvo> zyga: thats all we need to fix
<mvo> zyga: which is what the new PR is doing
<zyga> I see
<zyga> +1
<zyga> Good idea
<zyga> mvo: your patch looks good
<zyga> mvo: over weekend I iterated on the service regression
<mvo> zyga: thanks
<pstolowski> mornings
<mvo> hey pstolowski - good morning
<pedronis> mvo: anything that I need to review?
<pedronis> in particular
<mvo> pedronis: nothing particular, anything tagged with 2.37 will help
<mborzecki> pstolowski: hey
<marcustomlinson> Happy Birthday pstolowski!
<pstolowski> marcustomlinson: hey marcustomlinson! thanks! :)
<pedronis> mvo: does https://github.com/snapcore/snapd/pull/6470 means that 18.04 will not have /snap/bin in the PATH for a while?
<mup> PR #6470: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
<mvo> pedronis: correct
<pedronis> :/
<pedronis> mvo: is this a systemd  change? is there a systemd bug for this?
<pedronis> I just see snapd bugs
<pedronis> not systemd bugs
<pedronis> mvo: do we need to revert to what we were doing before the generator?
<pedronis> the new situation is not really acceptable
<mvo> pedronis: it was all rather hectic yesterday, there is a reference to a systemd bug (1771858 which has both snapd and sytemd tasks)
<pedronis> mvo: but that's very old
<mvo> pedronis: what is not acceptable?
<pedronis> and most systemd says fix commited
<pedronis> mvo: that we lose /snap/bin
<mvo> pedronis: yes, we need to add a systemd task now
<mvo> pedronis: we never had it on 18.04
<pedronis> heh
<mvo> pedronis: the generator only got added via the SRU and we had trouble getting one in for a while
<mvo> pedronis: so this generator works on 18.10 (there we were successful)
<pedronis> mvo: so /snap/bin was always broken in 18.04 ?
<mvo> pedronis: but the generator never made it to 18.04 until last thursday
<mvo> pedronis: correct for *service* in systemd
<pedronis> but it works here
<pedronis> mvo: this is only about services?
<mvo> pedronis: it works fine for anything that has a shell or uses /etc/environment or /etc/login.defs
<mvo> pedronis: correct, *only* services
<mvo> pedronis: and its also an issue on 16.04 where there are no generators
<mvo> pedronis: so in a sense its not terrible but still quite unfortunate
<mvo> pedronis: also it reminded me how much of a mess the system environment is (or has been, systemd is improving things here)
<mvo> pedronis: should I clarify that in the PR? I will add a systemd bug next
<pedronis> mvo: so this will never work, until we get a newer systemd in 18.04
<pedronis> which will not happen?
<pedronis> mvo: fwiw  the description in https://github.com/snapcore/snapd/pull/6470 is very confusing
<mup> PR #6470: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
<pedronis> that's also why I'm asking this silly questions
<mvo> pedronis: well, apparently there is work to port the fixes to the systemd in 18.04 and SRU them, no not quite never but not right now
<pedronis> ok
<mvo> pedronis: let me fix the description then, sorry for the confusion
<pedronis> mvo: is mostly pointing at bugs
<mvo> pedronis: well, after my meeting
<pedronis> but those bugs are confusing in themselves
<pedronis> mvo: thanks, np, I have a bit issue fatigue atm
 * mvo hugs pedronis 
<Chipaca> pedronis: o/
<Chipaca> pedronis: have you thought of a better name than "rerefresh" for the handler?
<sparkiegeek> reÂ²fresh ?
<pedronis> Chipaca: not so far, too many other things :(
<Chipaca> what the handler does, ideally, is check whether the store thinks anything further needs doing
<Chipaca> "check-pending"? :-/
<pedronis> Chipaca: check-rerefresh ?
<Chipaca> pedronis: is it going to change in any way when it's no longer just rerefresh?
<pedronis> Chipaca: well, in a sens is also checking the refresh
<pedronis> it's doing many things
<mvo> pedronis: I updated the description now (had a meeting before that)
<mvo> pedronis: I hope this is clearer now?
<pedronis> mvo: yes, thank you, I fixed a couple of typos in it
<mvo> pedronis: ta
<pstolowski> pedronis: hey, have you seen my message re ensure-before from friday evening?
<pedronis> pstolowski: no, I saw it now, the fix seems wrong, we already are reading the channel somewher else
<pedronis> so we probably need something a bit different than the default code
<pedronis> suggested
<pstolowski> pedronis: yes, we do in Loop
<pedronis> I tought we discussed that
<pedronis> before
<mborzecki> phew, my rspi3 looked dead for a while
<pedronis> pstolowski: what happens if we simply do  if !Stop() { return }  else { Reset }
<pstolowski> pedronis: i'll check. for now if i only Reset (with slightly modified conditionals)", it works (no slowness with the reproducer scenario).
<mborzecki> need to go out for while, back in ~2h
<pedronis> mvo: thanks for the reviews, I tried to answer some of your comments, but one I'm not sure I'm understand what you are asking
<pstolowski> pedronis: that seems to work
<pedronis> mvo: https://github.com/snapcore/snapd/pull/6467/files#r253412999
<mup> PR #6467: image,cmd/snap,tests:  introduce prepare-image --classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/6467>
<pedronis> Chipaca: btw maybe you could review this ^ as well when you have a moment?
<pedronis> pstolowski: ah
<pedronis> pstolowski: to be clear the idea is that in the !Stop() case, the Loop will do <-C and Reset anyway
<mvo> pedronis: sure, looking
<pstolowski> pedronis: yes, i understand this now, thanks! i'm going to propose what i've right now
<mup> PR snapd#6472 opened: [RFC] overlord: fix ensure before slowness on Retry <Created by stolowski> <https://github.com/snapcore/snapd/pull/6472>
<pedronis> mvo: if we want to change how it looks like it would be a change under snap/seed_yaml.go
<pedronis> there's a Write there and the yaml encoding metadata
<mvo> pedronis: yeah, looking at it again I think its not relevant, just curiosity on my part
<pedronis> about the tests, I'll see once I get a 2nd review, it's also a mixture of two tests, I need to double check if it's not missing some checks
<pedronis> mvo: are we going to cut 2.38 this week? or next at this point?
<mvo> pedronis: probably monday next week, we will do 2.37.2 today (if we get reviews)
<Chipaca> pedronis: in that PR, why is --classic-arch needed?
<Chipaca> pedronis: why can't it be --architecture?
<pedronis> Chipaca: because on core an architecure is mandatory in the model
<pedronis> but in a classic model is optional
<mvo> hrm, hrm, we run into timeouts in travis again
<Chipaca> this is a classic arch: https://upload.wikimedia.org/wikipedia/commons/b/b8/Arc_de_triomphe_frontsimple.jpg
<mvo> Chipaca: lol
<pedronis> Chipaca: --classic-architecture is very long
<Chipaca> pedronis: so just call it --architecture :-)
 * mvo hands the "mr smarty pants" award to Chipaca 
<pedronis> indeed
<pedronis> Chipaca: it's not needed at all for core
<Chipaca> pedronis: so error out if it's provided without classic (or if provided and different from the model?)
<Chipaca> --classic-arch is nasty :-/
<Chipaca> you'll be saying classic twice, for one
<pedronis> Chipaca: we do error out if it's provided without --classic
<Chipaca> alternatively, --classic[=<arch>]
<pedronis> Chipaca: the reverse is that if it's architecure people will give it anyway
<pedronis> tough people are not really meant to call this directly for core
<Chipaca> pedronis: what happens if you use --classic without --classic-arch?
<pedronis> Chipaca: it fails if you model has snaps but not architecture
<pedronis> Chipaca: you can read the code as well
<Chipaca> pedronis: so it's required for classic
<pedronis> no
<pedronis> Chipaca: architecure is in a classic model is optional
<pedronis> not prohibited
<Chipaca> i'm reading the code, seven function calls deep and still don't know if this will error without it
<pedronis> Chipaca: here:  https://github.com/snapcore/snapd/pull/6467/files#diff-da07f373046a0a24e67b18699dc15a70R197, it's actually one level deep
<mup> PR #6467: image,cmd/snap,tests:  introduce prepare-image --classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/6467>
<Chipaca> dammit, missed that
<pedronis> Chipaca: more seriously, if we had to pass architecture to other commands would you spell it --arch or --architecture , I'm in favor of the shorter one
<Chipaca> pedronis: I'm objecting to the repetition of classic, more than to the shortening of architecture
<Chipaca> pedronis: writing as much on the pr
<pedronis> Chipaca: ok
<pstolowski> is Sergio going to be back today?
<mvo> pstolowski: next week iirc
<pstolowski> mvo: ah, ok, thanks
<mborzecki> re
 * Chipaca â lunch
<pedronis> pstolowski: did a first pass over #6465
<mup> PR #6465: overlord/ifacestate: hotplug-add-slot handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
<pedronis> let me know if you have questions
<pstolowski> pedronis: thanks!
<mup> PR snapd#6451 closed: tests: update smoke/sandbox test for armhf <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6451>
<pedronis> Chipaca: I will reconsider the --classic-arch things in a follow up, landing the PR as is for now
<mup> PR snapd#6467 closed: image,cmd/snap,tests:  introduce prepare-image --classic <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6467>
<Chipaca> pstolowski: pedronis: https://forum.snapcraft.io/t/serial-port-hotplug/9773
<kjackal> Hi snappy people, this is driving me crazy. I am trying to find documentation on what happens to SNAP_DATA during a refresh. In particular, is it preserved or not?
<kjackal> I read that is backed up and restored, but it does not say that the contents are preserved/not changed during a refresh
<pedronis> jdstrand: hi,  there is a couple of review of 2.37 PRs https://github.com/snapcore/snapd/milestone/22 that needs your review (first two there)
<jdstrand> I thought I did the 2nd one. anyway, ack
<pedronis> jdstrand: no, I see still voting pending for you in those
<pedronis> jdstrand: I'm referring to: https://github.com/snapcore/snapd/pull/6471
<mup> PR #6471: [RFC] snap-confine: fix classic snaps for users with /var/lib/* homedirs <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6471>
<pedronis> and https://github.com/snapcore/snapd/pull/6466
<mup> PR #6466: cmd/snap-confine: handle death of helper process <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<mup> PR snapd#6468 closed: image: bootstrapToRootDir => setupSeed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6468>
<jdstrand> pedronis: ok, I reviewed 6471 but please see https://github.com/snapcore/snapd/pull/6471#pullrequestreview-199638498
<mup> PR #6471: [RFC] snap-confine: fix classic snaps for users with /var/lib/* homedirs <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6471>
<pedronis> pstolowski: https://github.com/snapcore/snapd/pull/6472 is red,  real issue or just fluke ?
<mup> PR #6472: [RFC] overlord: fix ensure before slowness on Retry <Created by stolowski> <https://github.com/snapcore/snapd/pull/6472>
<pstolowski> pedronis: Successful tasks: 4012 and 2 failures to prepare on s390x ;)
<pstolowski> cheksum errors from apt
<pedronis> jdstrand: I took a note pointing to those comments, yes, sadly we don't have time to design how this should work, it was working by chance so far
<pedronis> and it's a big regression atm
<jdstrand> pedronis: yep, I understand
<greyback> hi folks, I'm experiencing a snap daemon that refuses to die, even after I've removed the snap! I've no idea how it might still be alive, anyone see something obvious https://pastebin.ubuntu.com/p/QPNWGXkxpZ/
<greyback> how is snapfuse mounting a snap if its snap file is missing?
<greyback> this even persists after reboot
<Chipaca> greyback: anything interesting in systemctl list-units --type mount ?
<greyback> Chipaca: nothing referring to multipass anyway (the snap in question)
<Chipaca> greyback: how is that mount surviving reboot, then?
<greyback> Chipaca: no idea
<mup> PR snapd#6473 opened: snap-confine: remove special handling of /var/lib/jenkins <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<greyback> Chipaca: oh I'm an idiot, ignore me. It was running inside an lxd instance
<Chipaca> greyback: and you were checking outside?
<greyback> Chipaca: yeah
<Chipaca> greyback: it's multipass all the way up
<greyback> :)
<greyback> sorry about the noise
<Chipaca> the logo needs to be a turtle seen from underneath
<sil2100> cwayne: hey! I see the latest core18 snap has all the testflinget checkboxes checked, can I promote it to candidate then? ;)
<sil2100> cwayne: (the Ready for Candidate checkbox is not yet checked, which is why I'm asking)
<cwayne> sil2100: can you give us like an hour? We're in the process of adding a new system
<cwayne> Which is why we didn't check it off yet
<sil2100> cwayne: sure!
<Chipaca> mvo: https://forum.snapcraft.io/t/snapd-2-37-1-refresh-broke-layouts-snap-remove-install/9803
<mborzecki> heh, the release just keeps on giving
<pedronis> it doesn't look like a regression tough
<pedronis> more a layout related bug
<sil2100> mvo, pedronis, zyga: hey! With the bionic .2 close, wanted to touch base on the snapd snap - is 2.37.1 the version we want to ship for core18 .2?
<pedronis> sil2100: there is no snapd inside core18
<pedronis> you mean the images ?
<sil2100> pedronis: in the images I mean, for the point-release
<sil2100> We're releasing new images with each point-release
<pedronis> probably need mvo (which is afk) for that discussion
<sil2100> Just wanted to know if we're good to go with the current snapd
<zyga> hey mvo
<zyga> back from the hospital now
<zyga> I noticed https://github.com/snapcore/snapd/pull/6473
<mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<zyga> and I was thinking if we need to drop it
<zyga> if you have a strictly confined snap used in jenkins
<zyga> you will see issues
<zyga> I would keep this patch for now
<zyga> and only drop it in 2.38 cyckle
<zyga> *cycle
<pedronis> zyga: there are other issues with it
<pedronis> I mean it fails later
<zyga> I see
<pedronis> in some cases
<zyga> cannot create user data directory: /var/lib/jenkins/snap/test-snapd-tools/6: Read-only file system
<zyga> this means that /var/lib/jenkins was not mounted from classic world
<zyga> anyway
<zyga> just a quick comment
<zyga> mvo: the bind mount failed because apparmor permissions are incorrect
<zyga> mvo: I think we should fix that rather than undo it
<pedronis> zyga: somebody hit some kind of layout / stale namespace issue: https://forum.snapcraft.io/t/snapd-2-37-1-refresh-broke-layouts-snap-remove-install/9803
<zyga> as otherwise you will still break people using jenkins and using snaps inside the CI loop
<pedronis> zyga: ?
<ijohnson> pedronis, zyga: that was me that hit the layout issue. let me know if you need any more info on it, but since it went away after a reboot it's not a problem for me anymore
<zyga> ijohnson: I just asked in the forum thread
<zyga> ijohnson: sorry, I'm not working in full capacity so my responses may be spotty
<ijohnson> ah got it. No problem, I think this issue is pretty low priority as it seems like an edge case of something
<pedronis> zyga: are you saying that our special-home tests don't do enough
<pedronis> related to keeping the jenkins hack
<zyga> pedronis: the denial seems to suggest the mount mode is incorrect, though this is odd as the test is supposedly exercising this
<zyga> I can recheck to be sure
<pedronis> zyga: do the test try to do something with the accessible bits of HOME ?
<pedronis> you probably need a snap with the home interface
<pedronis> to notice I suppose
<zyga> pedronis: no, since before snap-confine would fail early on permission error; perhaps it should do something more elaborate (e.g. access $SNAP_USER_DATA)
<zyga> ijohnson: thanks
<pedronis> that's my question, do we have not good enough tests?
<zyga> ijohnson: //deleted is a thing done by the kernel
<pedronis> and would have they passed with 2.36
<ijohnson> zyga: interesting, I've never seen that before
<zyga> pedronis: I don't know yet, I haven't tried running that test against 2.36
<zyga> ijohnson: it is also annoying since it's a super weird special state
<pedronis> anyway spread tests are not helping either atm (lot of red from very different reasons)
<zyga> I see
<zyga> ijohnson: https://lwn.net/Articles/265920/ look for //deleted
<zyga> ijohnson: you can get a directory that has been removed
<zyga> ijohnson: it is super annoying
<ijohnson> huh that's so odd
<zyga> ijohnson: because then it is a black hole that cannot be used normally
<pedronis> jdstrand: reminder about #6466
<mup> PR #6466: cmd/snap-confine: handle death of helper process <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<jdstrand> pedronis: I'm looking at it now
<zyga> ijohnson: I will look at this but no promises (baby born yesterday)
<ijohnson> zyga: yeah it's really odd that the directory didn't even have references for "." and ".." in it
<pedronis> jdstrand: thx
<zyga> ijohnson: it's a very weird thing that AFAIK is not documented anywhere
<zyga> (read the fine source they said)
<ijohnson> zyga: no rush at all, it can certainly wait as long as needed, and congrats!
<zyga> ijohnson: I don't think this is a new issue though
<zyga> ijohnson: at leas a quick feeling about the scope of changes in 2.36
<sil2100> cwayne: can you give me a poke once the core18 snap is good to go? ;)
<sil2100> Thanks!
<cwayne> Yep
<pedronis> zyga: the quirks never mounted anything from the host except lxd, I'm looking at the patch that removed them
<zyga> that's correct but it seems that the new code for jenkins doesn't run in practice because of an apparmor denail; I can be wrong, I will check calmly
<zyga> just eating supper, I was starving since noon
<pedronis> zyga: just saying afaik quirks would not have made snap touching home running under a special home dir work
<pedronis> because nothing like a mount of the special home into the snap namespace
<pedronis> was there
<zyga> mmm
<zyga> I see
<zyga> though /var/lib was a tmpfs
<pedronis> yes
<pedronis> filled with bits from core
<pedronis> not the host
<pedronis> except for lxd
<zyga> so it was ephemeral but writable
<pedronis> if I read the code
<pedronis> correctly
<zyga> yes, correct
<pedronis> nothing would bind mount /var/lib/jenkins
<pedronis> except maybe some layout bug
<pedronis> afaict
<zyga> sure
<zyga> but it would create one for ci run
<zyga> maybe that was enough?
<pedronis> the snap itself?
<pedronis> not a lot of code does mkdir $HOME
<zyga> yeah
<zyga> snap-confine mkdir's snap user data
<zyga> mkdirs
<pedronis> inside the the namespace?
<pedronis> or from outside?
<pedronis> if you know from memory
<pedronis> (I can check otherwise)
<zyga> no
<zyga> i think inside
<zyga> but not sure
<pedronis> that would be allowed by the new "fix"
<pedronis> so you would have a wrong home
<pedronis> but some home
<pedronis> inside
<pedronis> if it was from outside
<pedronis> then nothing changes
<zyga> yeah
<zyga> I will look at how 2.36 behaved in reality
<zyga> maybe classic snaps were used
<zyga> like go
<zyga> anyway
<zyga> I'll check what was happening
<zyga> just need a little break
<zyga> no much sleep last night
<zyga> 2.36 + classic snap was probably "working" enough
<zyga> since it would run in real /var/lib/jenkins
<zyga> and since there was no blocking error from snap-confine
<pedronis> yes, classic there is no name space
<pedronis> zyga: yes, it's created after we pivot afaict
<jdstrand> pedronis and zyga: commented on PR6466
<jdstrand> PR 6466
<mup> PR #6466: cmd/snap-confine: handle death of helper process <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<hunterk> Hi, I posted on the snapcraft forum a few days ago asking for info/tips on getting vulkan to work with my snap: https://forum.snapcraft.io/t/problem-with-vulkan-support-in-snaps/9744
<hunterk> but I figured I'd ask here, too :)
<zyga> jdstrand: it is from siginterrupt man page
<zyga> jdstrand: signal vs sigaction, no specific reason, I can use sigaction
<zyga> but SIG_ITG is just shorter
<zyga> IGN
<zyga> hunterk: ask mborzecki here tomorrow morning european time
<jdstrand> zyga: there are a lot of questions in my comments, please ponder and respond in the PR
<zyga> jdstrand:  think you misread the code
<zyga> the parent is where the change is relevant, we don't undo it until after any communication with the child is finished (after we wait and close the pipes)
<hunterk> zyga: okay, will do
<zyga> jdstrand: I will respond in the PR as well, just wanted to bring that up quickly
<jdstrand> maybe I didn't see where you put teardown
 * jdstrand looks again
<pedronis> jdstrand: the tear down is not in the same function
<jdstrand> I did misread that. jeez
<pedronis> the diff artifcat as such is not very clear
<zyga>   jdstrand your comment about read of size zero is, i think, valid but I need to recheck things, I did change it in one of my earlier branches that included more changes but then I dropped that after reading how signals would be delivered (I think we do get EPIPE, not read of size zero then)
<zyga> oh, I noticed mvo changed the branch as well
<pedronis> zyga: we reverted some bits related only to the tests
<zyga> yeah, I see now
<pedronis> zyga: afaiu only write returns EPIPE,  read would indeed return 0
<zyga> pedronis: correct
<jdstrand> pedronis, zyga: ok, I corrected myself and added a new comment
<zyga> thank you
<kenvandine> jdstrand: some of the gnome snaps are getting new app ids upstream so the dbus name is changing
<kenvandine> jdstrand: just FYI
<kenvandine> triggering some manual reviews
<kenvandine> jdstrand: of interest though, the dbus name is changing in the edge channel but not in the candidate/stable channels yet
<kenvandine> jdstrand: we have builds triggered by git commits for quite a few things now.  So master -> edge and gnome-3.30 -> candidate (promoted to stable after QA)
<kenvandine> jdstrand: so both old and new names will need to be allowed for a bit until gnome-3.32
<jdstrand> kenvandine: ack
<jdstrand> kenvandine (cc willcooke): we should be looking at this too: https://gitlab.gnome.org/GNOME/glib/merge_requests/450 / https://blogs.gnome.org/mclasen/2019/01/28/whats-new-in-flatpak-1-2/ (the dconf changes)
<jdstrand> "This will become useful with the next GLib release, when GSettings will no longer be using the dconf backend, allowing us to close an all-to-common sandbox hole"
<kenvandine> jdstrand: interesting, not using d-conf
<kenvandine> we want the new settings portal for sure
<kenvandine> that will help with wayland and themes
<jdstrand> yeah, and being able to not require gsettings forever is a good thing
<kenvandine> yeah
<jdstrand> roadmr: sorry, but can you queue up r1187. that has the 2.37 interfaces in it, among other things
<roadmr> \o/ jdstrand no worries, can do
<mvo> zyga: hey, sorry was away, we can discuss the jenkins thing tomorrow - but confined snaps have never worked for the jenkins user AFAICT, I tested this to double check with an older snapd too. only classic snaps worked and will still work with 6471 - or am I missing something?
<zyga> mvo: that's good, let's discuss tomorrow
<mvo> zyga: yeah, get some rest
 * mvo is also super tired
<mup> PR snapcraft#2460 opened: build providers: recreate instance if base changed <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2460>
<roadmr> jdstrand: ah, can you confirm a new block-devices superprivileged interface was added between 1179 and 1187?
<jdstrand> roadmr: it was in 1180
<roadmr> thanks jdstrand ! It made one of my tests fail, I'll add it to our expected list. No biggie
<jdstrand> roadmr: fyi, https://bugs.launchpad.net/snapstore/+bug/1814592 is probably pretty high priority and low hanging. may want pedronis input though
<mup> Bug #1814592: cannot compile personal-files/system-files snap declaration constraints <Snap Store:New> <https://launchpad.net/bugs/1814592>
<roadmr> jdstrand: ah fun, this might need an update to the assertions service which will be fun.
<jdstrand> roadmr: not that you would do it personally, but just trying to make it visible :)
<roadmr> jdstrand: it's a separate service fwiw, but yes, need pedronis's input on what to do
<jdstrand> ack, thanks
#snappy 2019-02-05
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> mborzecki: hey, good morning
<mvo> mborzecki: how are things? tests look pretty unhappy still :/
<mborzecki> mvo: restarted some jobs
<mborzecki> mvo: i'd think about landing #6422 to see if it helps with random mount errors on core-18
<mvo> mborzecki: did you notice any patterns?
<mup> PR #6422: tests/prepare: prevent console-conf from running <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6422>
<pedronis> mvo: hi, last night we had lots of runs >50mins
<mvo> mborzecki: good idea
<pedronis> but unclear what changed
<mvo> mborzecki: lets see if it helps
<mborzecki> mvo: some kill timeouts, (one in snap run --strace test), some network issues (go get from github fails)
<mup> PR snapd#6422 closed: tests/prepare: prevent console-conf from running <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6422>
<mvo> pedronis: yeah, I noticed that too
<mvo> pedronis: usual time is ~35min these days it seems
<pedronis> mvo: I re-run things a bit, but failed, then I gave up
<pedronis> mvo: I'm landing #6471 and will update #6473
<mup> PR #6471: snap-confine: fix classic snaps for users with /var/lib/* homedirs <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6471>
<mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<pedronis> mvo: jdstrand asked for tweaks to #6466
<mup> PR #6466: cmd/snap-confine: handle death of helper process <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<mvo> pedronis: certainly, looking
<mup> PR snapd#6471 closed: snap-confine: fix classic snaps for users with /var/lib/* homedirs <â  Critical> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6471>
<pedronis> mvo: I'm a bit confused by the test change in #6473
<mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<pedronis> I think we still want both tests
<mup> PR snapd#6474 opened: snap-confine: fix classic snaps for users with /var/lib/* homedirs (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6474>
<mvo> pedronis: you mean we want both "special-home" and "special-home-run-classic-snaps" tests?
<pedronis> yes
<mvo> pedronis: jenkins can no longer run confined snaps after the change
<mvo> pedronis: and it never could before
<mvo> pedronis: it was only ever able to run classic snaps
<pedronis> mvo: that is true, but I tought they would run partially at least?
<pedronis> they break already in snap-confine?
<mvo> pedronis: let me double check
<mvo> pedronis: I think so, let me quickly boot my test vm
<pedronis> mvo: the issue is that they will not have a home dir
<pstolowski> good morning
<pedronis> but it might well be that snap-confine is unhappy
<pedronis> (it does some things related to home after the pivot)
<mvo> pedronis: I will double check again, give me 2min
<pedronis> mvo: thx
<mvo> pedronis: https://github.com/snapcore/snapd/pull/6473#issuecomment-460548241 I will dig a bit into the snap-confine code to double check my empirical findings too, I have the vm running if you have any further questions
<mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<pedronis> mvo: ok
<pedronis> thx
<pedronis> mvo: I updated 6473
<mborzecki> pstolowski: spent some time looking at your pr, feels tricky
<mvo> pedronis: thanks, did I made a dirty merge?
<pedronis> mvo: ?
<mvo> pedronis: I noticed you force pushed 6473, was there anything wrong in the original push?
<pedronis> mvo: no,  but I squash merged the previous one
<pedronis> so I had to
<mvo> pedronis: aha, ok
<pstolowski> mborzecki: yes i can see that. perhaps we should just reduce retry timeout, unless there is some other more obvious fix
<pedronis> mvo: so we get 1 commit each
<mvo> pedronis: +1
<pedronis> mborzecki: tricky in which sense
<mvo> pedronis: I think I did the same earlier but its fine :)
<mborzecki> pedronis: maybe fiddly, had to spent some time figuring out what's happening there
<pedronis> mborzecki: I think the tricky bit is that we need to trust what go says about timers
<pedronis> (which has already changed over time)
<mborzecki> pedronis: that's another story
<pedronis> that indeed is a bit uncomfortable
<mvo> pedronis: I added a comment to 6473 about the code and how things worked before and why strict snaps for non /home users never worked, hope this makes things clear. ideally zyga  would double check 6473 but I'm pretty confident in the findings
<pedronis> mvo: I gave a +1 to #6470, it needs a 2nd review
<mvo> mborzecki: 6470 needs a second review
<mup> PR #6470: packaging: disable systemd environment generator on 18.04 <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
<mvo> pedronis: thank you!
<mvo> mborzecki: you looked at this before so hopefully easy :)
<pedronis> mvo: your comment in 6473 about strict confinement is not ture, we never copied the host into var/lib
<pedronis> we copied core plus host lxd
<mvo> pedronis: we create a writable mimic of the original host, let me search
<pedronis> mvo: no, it's a writable mimic of core plus host lxd
<pedronis> (it's all confusing)
<mvo> pedronis: yeah, re-reading it now
<mup> PR snapd#6470 closed: packaging: disable systemd environment generator on 18.04 <â  Critical> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6470>
<pedronis> mvo: squash merged ^
<pedronis> let me prep a backport
<pedronis> done
<mup> PR snapd#6475 opened: packaging: disable systemd environment generator on 18.04 (2.37) <Created by pedronis> <https://github.com/snapcore/snapd/pull/6475>
<mvo> pedronis: thanks you
<mvo> pedronis: if 6470 can be cherry picked I can just do that, we only need the backport when there are conflicts
<mvo> pedronis: you are right of course, its just the core /var/lib that goes into the namespace
<pedronis> mvo: ah
<mvo> pedronis: which means my testing with jenkins was not ideal as this is now availalbe in the core snap. i retested using postgres and got also a failure but a different one
<pedronis> mvo: ah, we should remove jenkins from the cores
<mvo> pedronis: +1
<mvo> pedronis: if this branch lands, then yes
<mvo> pedronis: https://github.com/snapcore/snapd/pull/6473#issuecomment-460558531 hopefully solves the mystery
<mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<pedronis> mvo: btw I'm *not* working on 6466 because I will need to review it
<mvo> pedronis: I can work on that now
<pedronis> mvo: thx
<pedronis> mvo: one of the backports got red
<pedronis> 6474 :/
<pedronis> mvo: +1 to #6473
<mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<mvo> pedronis: the red is 'protocol' error in mount again :(
<pstolowski> mvo: hey, quick question about apt wrt to nested vm. i'm having an issue where apt install -y ... as part of the test triggers an interactive debconf prompt and hangs there till kill timeout - https://pastebin.ubuntu.com/p/R35sJvhfWH/ ; i'd have though -y takes care of that, i cannot find anything obvious in apt man
<mvo> pedronis: thanks for the review
<mvo> pstolowski: try DEBIAN_FRONTEND=noninteractive in your environment
<pstolowski> mvo: ack, thanks!
<pedronis> mvo: we are back with 50+ mins runs
<pedronis> not sure what changed
<mvo> pedronis: its strange, the results are uneven it seems, some finish in 35min but others overrun quite a bit
<Chipaca> I'd put 2Â¢ on it being images now being old and having to update a lot of stuff
<pedronis> Chipaca: mmh, how do we get the 35 mins run tough?
<pedronis> shouldn't image updating be a constant
<pedronis> or are we saying network perf is very uneven?
<Chipaca> pedronis: I am
<Chipaca> I'm not sure if it accounts for the whole of it, but it's an important chunk when doing qemu runs
<Chipaca> (and my network at home is pretty good at not being variable)
<mvo> pedronis: yeah, that seems plausible - I think Chipaca  is on something, iirc cachio was doing the updates only semi-automatic
<Chipaca> "Chipaca is on something"  only coffee i swear
<Chipaca> and maybe too little sleep
<pedronis> mvo: yes, we need to find a way to have both automatic and safe
<pedronis> I think the "safe" part was why they aren't automatic
 * mvo nods
<pedronis> Chipaca: you are working on the epochs PR, right?
<Chipaca> pedronis: yes
<pedronis> ok
<Chipaca> pedronis: the "have one refresh fail and two others succeed" test is failing all of them
<Chipaca> pedronis: so i'm having "fun"
<pedronis> we all having "fun" I fear, different sort of "fun"
<mvo> indeed, so much fun
<mvo> signal handling in unix ftw
<Chipaca> mvo: you sound like the lispers from the unix hater's handbook :-)
<mvo> Chipaca: thats how I feel!
<Chipaca> mvo: old and crusty and smelling slightly of pizza?
<Chipaca> that's what my copy of it was at least
<Chipaca> :-)
<mvo> Chipaca: hahahaa
<mvo> Chipaca: yeah, except the smell is more of tea but otherwise quite close
 * Chipaca hugs mvo 
<Chipaca> mvo: you'll get through it, i'm sure
 * mvo hugs Chipaca 
<mvo> Chipaca: yeah, its just â¦ oh well
<Chipaca> yeah
 * mvo drinks more to get through it
 * mvo really likes his tea today
<mwhudson> signal handling and threads are no fun
<mwhudson> and go means mandatory threads
<juliank> mvo: Is snapd installing the apt integration on all releases? I think the apt side is only available in bionic+ now, but it will probably migrate back to older releases shortly; though, I don't think it will work correctly for snapd purposes on trusty
<juliank> (IIRC, on the the trusty backport, it can't figure out which packages were not found, but I'll have to do some digging)
<mvo> juliank: we install the hook everywhere, I can disable it on trusty if that is a problem
<juliank> I think it will just do nothing, but I'll test it before doing any SRUing
<mvo> juliank: thank you
<zigford> Wondering if someone could help me get snaps working on Gentoo. I've had it going before, but now setting it up on a new machine and have some kind of issues with apparmor profiles
<zigford> I'm getting the following message: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zigford> i see /snap/core/6350/user/lib/snapd/snap-confine and **snap-confine//mount-namespace-capture-helper listed ad being in enforce mode when running "aa-status"
<zigford> snap version is 2.36.1, series 16, kernel 4.20.6
<zigford> only errors I see in journalctl for snapd is: Apparmor is enabled but some features are missing, dbus, netwok
<zigford> and some stuff about the executable not containing a buildid
<Chipaca> zigford: I'd suggest using the forum for this
<Chipaca> zigford: for one, because the people that can help you might be busy right this instant
<Chipaca> zigford: for two, because then people can find it written down the next time :-)
<pstolowski> pedronis: wrt to ensureUniqueName/proposedName bit, are you ok if in the existing PR i only extract this code into a helper as you suggested, and we will iterate on the details in a followup?
<zigford> I'm okay with waiting, I can leave IRC open for a few days. But i agree with you on the second point.
<pedronis> pstolowski: yes, assuming we can iterate relatively quickly
<zigford> I will update my 'Snaps on Gentoo' blog post when I find the answer for others too. But the forums are probs way more discoverable than my little blog
<Chipaca> zigford: forum.snapcraft.io is the forum i meant fwiw
<zigford> gotcha
<pstolowski> pedronis: yes, should be quick
<pstolowski> ty
<Chipaca> pstolowski: https://forum.snapcraft.io/t/log-snapd-and-btrfs-message/9809
<Chipaca> pstolowski: is that something you know about? udevmon.go thing
<pstolowski> Chipaca: yes. i was wondering if it's going to create a lot of noise. not a bug, just noise for virtual devices that get removed and that we didn't know about
<pstolowski> maybe it should be DEBUG, although initially i wanted to be sure we are not missing something important
<pedronis> mvo: not urgent, when will edge contain prepare-image --classic that landed yesterday?
<pstolowski> Chipaca: i'll reply
<pedronis> mvo: #6474 is green
<mup> PR #6474: snap-confine: fix classic snaps for users with /var/lib/* homedirs (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6474>
<Wimpress> zyga pedronis Please, can you remind me what the status of layouts is in snapd?
<mvo> pedronis: hm, depending on timing either today or tomorrow its trivial for me to kick it
<pedronis> Wimpress: they are not behind a flag anymore, they might not be supported directly (without passthrough) in snapcraft for something without tough, that's a snapcraft question, it's one of our most complex features so I do expect some bugs still
<pedronis> *without base:
<Wimpress> So layouts require `base:`?
<pedronis> Wimpress: as I said, may be, you can passthrough them tough
<pedronis> if you don't have one
<pedronis> Wimpress: a question for snapcraft
<zigford> https://forum.snapcraft.io/t/troubleshooting-snap-confine-and-apparmor-on-gentoo/9812
<Chipaca> zigford: <3
<Chipaca> zigford: where does that funky version string come from?
<Wimpress> degville: See my question above regarding layouts. Is there documentation for how to use layouts?
<pedronis> mvo: no, not urgent just wondering
<Chipaca> zigford: asked in the forum to keep the conversation in one place :-D
<degville> Wimpress: https://docs.snapcraft.io/snap-layouts/7207
<Wimpress> degville: Excellent! Thank you :-)
<mborzecki> troubles with the store?
<mborzecki> https://status.snapcraft.io doesn't seem to work here
<popey> degville: fyi, I just ninjaed the 'snap version' out of https://forum.snapcraft.io/t/installing-snap-on-opensuse/8375
<popey> because no other distro install guide has it, seemed unnecessary
<Wimpress> mborzecki: All green from here. Store appears to be working for me.
<degville> popey: yep, ok. makes sense. maybe the colon too :)
<zigford> Chipaca: What's funky about the version string? What should it look like?
<popey> on it
<degville> thanks!
<popey> np
<mvo> pedronis: I updated 6466 - I added some more comments there, for me the sanity timeout thing is dubious, details in the PR
<mvo> pedronis: but also not relevant for the particular PR
<pstolowski> pedronis: addressed/responded to your 1st pass feedback on #6465 ; now working on a followup for the slot naming
<mup> PR #6465: overlord/ifacestate: hotplug-add-slot handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
<mvo> pedronis: added another comment to 6466 and will stop for now on this one
<mup> PR snapd#6475 closed: packaging: disable systemd environment generator on 18.04 (2.37) <Created by pedronis> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6475>
<mup> PR snapd#6474 closed: snap-confine: fix classic snaps for users with /var/lib/* homedirs (2.37) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6474>
<pedronis> mvo: I reviewed #6466
<mup> PR #6466: cmd/snap-confine: handle death of helper process <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<mvo> pedronis: thank you
<pedronis> pstolowski: thx, I queued to re-review hotplug-add-slot , have some other (older) things to review first plus 2.37.x stuff
<pedronis> though
<Chipaca> mvo: did you see the thing about wekan?
<mup> PR snapcraft#2459 closed: catkin plugin: describe how to build all packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2459>
<Son_Goku> mvo, niemeyer, zyga, uhh
<Son_Goku> we have a problem
<ogra> nah ...
<ogra> you have a "challenge"
<Son_Goku> MongoDB is being removed from Fedora is a bit of a problem
<Son_Goku> the mgo driver currently depends on it
<Son_Goku> which is a snapd dependency
 * ogra wonders why snapd would depend on a database driver
 * Son_Goku shrugs
<ogra> sounds like a failure
<Son_Goku> I think it uses the mgo driver's bson and json code
<ogra> ah
<Son_Goku> and it's only in one place: errtracker
<Chipaca> time to vendor bson
<Son_Goku> well, niemeyer wrote the driver
<Chipaca> Son_Goku: why's mongo being removed from fedora? the licensing thing?
<Son_Goku> yes
<Son_Goku> Debian is doing the same thing, btw
<Son_Goku> and this will affect snapd in the same manner
<ogra> yeah, the license
<Chipaca> Son_Goku: mgo wrote it but afaik no longer maintains it
<ogra> this is the year of the mongodb snap !
<Son_Goku> fuck mongodb
<Chipaca> Son_Goku: er, i meant gustavo, not mgo. I wish mgo wrote things.
<Son_Goku> haha
<Chipaca> that "mongodb is webscale" youtube thing never ever got old
<niemeyer> Yeah, that was part of the problem.. I was trying to convince it to write itself but didn't work
<Son_Goku> XD
<Chipaca> https://www.youtube.com/watch?v=b2F-DItXtZs
<mborzecki> off to pick up the kids
<sil2100> mvo: hey! Once you're back from lunch, just a quick question: we'll be spinning .2 bionic core18 point-release images soonish, is snapd 2.37.1 from stable good-enough for the new images?
<Chipaca> sil2100: I don't have an answer, but I absolutely love that question
<mpt> Hi, Iâm looking for a description of the default snap update frequency. is there anything clearer than the âwithin 6 hoursâ on <https://docs.snapcraft.io/getting-started/3876>?
<mpt> LOL the snap man page gets narrower and narrower until itâs one word per line
<cjwatson> It does?  I don't see that here
<cjwatson> (up-to-date bionic)
<cjwatson> mpt: https://forum.snapcraft.io/t/system-options/87 maybe?
<Chipaca> sparkiegeek: thank you for reminding me about how much license sucks
<Chipaca> mpt: which manpage where?
<sparkiegeek> Chipaca: you're not wrong
<Chipaca> sparkiegeek: i commented on the bug, mostly with a "yeah sucks"
<Chipaca> sparkiegeek: but it's a whole-stack suckage, if that helps Â¯\_(ã)_/Â¯
<mpt> cjwatson, perfect, thanks
<sparkiegeek> Chipaca: well... it doesn't :D
<mpt> Chipaca, âman snapâ for snap 2.37.1 on Ubuntu 14.04
<mpt> Iâm reporting a bug now
<Chipaca> mpt: could you also do
<Chipaca> mpt: snap help --man | man -l -
<Chipaca> mpt: and report whether that looks any better?
<mpt> Chipaca, same result
<Chipaca> mpt: https://i.redd.it/yl57urxpoje21.jpg
 * sparkiegeek reloads https://twitter.com/mptbugs
<mpt> ð
<cjwatson> Super-confused; extracting the man page manually on pepo and piping to man -l - doesn't show that
<Chipaca> ooh ooh
<Chipaca> mpt: snap help --man < /dev/null | man -l -
<Chipaca> mpt: how does that one work
<mpt> Chipaca, same result
<Chipaca> aww
<Chipaca> mpt: I'm all out of "thanks i hate it" images
<Chipaca> cjwatson: 14.04?
<cjwatson> Yes.  Trying a container now
<Chipaca> cjwatson: 2.37.1?
<cjwatson> Yes.  Trying a container now :)
<Chipaca> cjwatson: trying a container now?
 * Chipaca runs
<cjwatson> I sure am
<sparkiegeek> Chipaca: if you want to help move the license handling forward, I believe we still need a response to https://forum.snapcraft.io/t/snap-license-metadata/856/52
<Chipaca> sparkiegeek: dang
<Chipaca> sparkiegeek: let's blame niemeyer
<sparkiegeek> Chipaca: we all do :D
<Chipaca> pedronis: could you pick that up ^ ?
<mpt> https://bugs.launchpad.net/snapd/+bug/1814767
<mup> Bug #1814767: âman snapâ gets narrower and narrower until itâs 1 word/line <snapd:New> <https://launchpad.net/bugs/1814767>
<cjwatson> Oh yes, now I see it
<pedronis> Chipaca: we had a discussion in december how to go a bit forward, but no work on it is planned for right now
<cjwatson> This is surely a groff bug or something, but how was I previously unaware of something like that
<mpt> So this is the kind of Postelâs Law thing that turns into two bugs?
<cjwatson> Oh, it's due to the doubled .TP lines
<mpt> One on groff and one on the man page
<cjwatson> I think the meaning of two .TP lines in a row is probably not especially well-defined
<cjwatson> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=49abd7a9093ae903bb0032eb74d647fb481d2acb
<pedronis> mvo: #6473 is green, I do think we do want it
<mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<pedronis> mvo: the description/commit needs updating tough
<cjwatson> left a diagnosis in 1814767
<Chipaca> cjwatson: thank you
 * mpt applauds
<Chipaca> we already do nasty things to get that manpage, I guess removing excess TP won't be that bad
<cjwatson> For good measure I manually stripped out the doubled .TP requests and confirmed that that fixes it
<Wimpress> zyga pedronis We discussed GPU issues when building snaps against core18. I've been testing the last few days, and so far can't reproduce the issues using snapd 2.37.x
<Wimpress> So far xonotic and ffmpeg migrated to core18 and tested using nvidia and intel on the host.
<Wimpress> Just letting you know, because that bug I said I would file might not be required now.
<pedronis> Wimpress: ah, I was wondering,  I don't see anything we did that actively would have fixed something
<pedronis> but not sure
<pedronis> when zyga is around he might chime in on this
<Wimpress> We do have some failures, but we're investigating because it may not be snapd related.
<Wimpress> Getting ffmpeg working gives me good confidence since it uses all the accelerated capabilities.
<cjwatson> Chipaca: Might be easier to just fix it in go-flags?
<sergiusens> mvo: hey, do you have any experience with aborted tasks from spread? I get aborted, I understand the reason from the docs on why it is good, I just cannot find a reason for it happening
<Chipaca> cjwatson: go-flags author is burstily responsive, and getting the right version everywhere is very slow
<cjwatson> Oh :(
<Chipaca> cjwatson: I'm also wanting to give go-flags support for generating manpages in sections other than 1
<Chipaca> need to revisit the pending PRs and see why they haven't been merged
<pedronis> Chipaca: btw, could you do a first pass over https://github.com/snapcore/snapd/pull/6079 when you have a bit of time
<mup> PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
<sparkiegeek> "Channel latest/beta for multipass is closed; temporarily forwarding to beta." - huh? I guess snapd is not resolving the "lack of track == 'latest'" when interpreting closed channels
<Chipaca> sparkiegeek: that should be fixed in â¦ 2.37? 2.38?
<Chipaca> one of those
<sparkiegeek> Chipaca: ok, well that was from 2.37.1
 * sparkiegeek fights Chipaca in #1814640
<mup> Bug #1814640: snap info showing "unset" license for snaps <snapd:Confirmed> <Snap Store:Invalid> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1814640>
<hunterk> mborzecki: are you available for a couple of questions about getting vulkan working in snaps?
<mup> PR snapcraft#2457 closed: lifecyle: avoid installation of snaps in docker <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2457>
<mborzecki> hunterk: i'm hardly an expert, but feel free to ask
<hunterk> kk, no worries :) I'm just trying to get the vulkan renderer in my snap, RetroArch, to work: https://forum.snapcraft.io/t/problem-with-vulkan-support-in-snaps/9744
<hunterk> as it is, I always get "failed to open vulkan loader", which is the same error I get outside of the snap if I don't have the right libs installed
<hunterk> but I have them listed in the build and stage packages, so I'm not sure if there's anything else I need to do to make them visible/accessible to the snap
<jdstrand> pedronis: fyi, https://bugs.launchpad.net/snapstore/+bug/1814592/comments/5
<mup> Bug #1814592: cannot compile personal-files/system-files snap declaration constraints <Snap Store:New> <https://launchpad.net/bugs/1814592>
<pedronis> jdstrand: I answered
<jdstrand> pedronis: I just pressed Enter on my comment to your answer...
<jdstrand> pedronis: ie, look at comment $5
<jdstrand> #5
<pedronis> jdstrand: we cannot do that change
<pedronis> jdstrand: you need a regexp using |  for the multiple entry case
<pedronis> jdstrand: as I said for a list attribute the regexp needs to much all entries
<jdstrand> pedronis: I know that is the current implementation, but do you acknowledge the awkwardness of the current situation?
<jdstrand> pedronis: this should've come up in PR review for the interfaces. We've never had an attribute that is a list of strings
<jdstrand> pedronis: I mean, we can mark it Won't Fix and just use the awkward syntax if you want
<pedronis> jdstrand: no, we thought about lists
<mup> PR snapd#6476 opened: cmd/snap: tweak man output to have no doubled up .TP lines <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6476>
<Chipaca> mpt, cjwatson ^
<pedronis> it's really designed that for a list the regexp needs to matches all entries
<mpt> \o/
<pedronis> jdstrand: we don't have exact check on lists but we shouldn't not really design something that needs them
<pedronis> as you said is then awkard if you remove things
<pedronis> jdstrand: anyway as also said most of this in the bug itself
<cjwatson> Chipaca: LGTM, thanks
<cjwatson> not that my Go is exactly fluent
<pedronis> jdstrand: so yes from my POV is a won't fix, if you think we should really do something (but as I said is not trivial) we can talk at the sprint
<jdstrand> pedronis: I'm reading the design doc and it seems to indicate that my interpretation would be supported. there is even an example that describes a case that matches my 'awkward if you remove things'
<jdstrand> page 4, "Please note that this logic may be applied also at the top-level. For example:"
<mvo> we need a second review for 6473 and 6466
<pedronis> jdstrand: If the slot or plug attribute value is a list, every element of the list must match the provided regexp.
<jdstrand> pedronis: regardless, the awkwardness of not matching when the snap drops a path is probably enough for this conversation
<pedronis> jdstrand: sorry I understand  your readin, that logic = alt interpretation
<pedronis> that's at least how I read it
<pedronis> I don't understand
<jdstrand> that doc has always been confusing to me on this point
<jdstrand> "If the constraint itself is specified as a list, though, it carries a different meaning"
<jdstrand> it doesn't matter though, the 'Granted' part of my statement is enough to not do what the bug is suggesting so I'll adjust
<pedronis> jdstrand: to be clear I'm not saying that this is not awkward sometimes, but is not unworkable or not fitting how we intended interfaces to use attributes usually
<jdstrand> pedronis: that's fine. I look at this like once every 6 months and didn't write the spec or the snapd code so it isn't completely internalized so when something new comes up, I have to reread. parts of that document I find unclear at times
<jdstrand> the review-tools will need an update unfortunately
<mvo> Chipaca: can I interest you in 6466 and 6473 :)
<Chipaca> mvo: probably
<jdstrand> mvo (cc Chipaca) I reviewed PR 6466 (approved)
<mup> PR #6466: cmd/snap-confine: handle death of helper process <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<Chipaca> jdstrand: mvo: so did I :-p
<mup> PR snapd#6466 closed: cmd/snap-confine: handle death of helper process <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6466>
<mup> PR snapd#6473 closed: snap-confine: remove special handling of /var/lib/jenkins <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6473>
<mvo> Chipaca: \o/
 * mvo hugs Chipaca and jdstrand 
 * Chipaca takes those hugs to the bank
 * jdstrand hugs mvo and Chipaca (group hug!)
 * zyga joins the group hug
<zyga> back from the hospital,
 * jdstrand hugs zyga 
<jdstrand> zyga: I hope everything is ok!
<zyga> jdstrand: yeah just unfortunate to get cold when the newborn is coming home
<zyga> jdstrand: unless something changes they will be back tomorrow
 * jdstrand nods
<jdstrand> zyga: I don't think I said congrats. congrats!
<mup> PR snapcraft#2461 opened: tests: disable legacy runs driven by the python test runner <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2461>
<zyga> thank you, mom did all the hard work :)
<jdstrand> heh :)
 * mvo hugs zyga 
<cwayne> congratulations zyga!!
<zyga> thank you :)
<pstolowski> hey zyga! congratulations!
<zyga> thank you all :)
<pstolowski> pedronis: what do you think about https://paste.ubuntu.com/p/HCj5cdpZtd/ ? the last string in each row is the name returned by hotplugSlotName helper for the inputs on the left?
<pedronis> pstolowski: seems in the right direction
<mup> PR snapd#6477 opened: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6477>
<mborzecki> mvo: ^^
<mvo> mborzecki: \o/ thank you
<mvo> mborzecki: and approved with tiny nitpicks, if pedronis or someone else would have a look at 6477 that would be awesome
<pedronis> mvo: I reviewed it,  I'm also interested if others have opinion where the warning should go (after or before),  Chipaca maybe?
<pedronis> Chipaca: talking about #6477 for clarity
<mup> PR #6477: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6477>
<mup> PR snapd#6478 opened: overlord/ifacestate: tweak logic for generating unique slot names <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6478>
<Chipaca> pedronis: pushed rerefreresh
<pedronis> Chipaca: thanks, any opinion on the warning placement in 6477
<Chipaca> pedronis: before, as you said
<pedronis> ok, we agree
<Chipaca> we do the same with the path warning
<pedronis> Chipaca: yes, this is targeted at 2.37.2
<pedronis> btw
<Chipaca> :+1:
<pedronis> mborzecki: thanks for addressing the feedback quickly
<pedronis> mvo: now we need 6477 to get green
<mvo> pedronis: indeed, I will baby sit it (while listening to jamiroquai
<cwayne> I don't know what that was ^ but I love it
<mborzecki> mvo: pushed a little fix there
<mvo> mborzecki: ta
<mvo> cwayne: people were making fun of me because apparently I look in a HO like these guys in the video - anywayâ¦ :)
<cwayne> hahaha oh that makes it so much better
<mborzecki> mvo: tough luck, the osx job fails for some reason https://travis-ci.org/snapcore/snapd/jobs/489189315
<mup> PR snapcraft#2461 closed: ci: use non virt-enabled gce instances for 16.04 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2461>
<Chipaca> mborzecki: looks like yaml doing 1.10 -> 1.1
<Chipaca> mborzecki:  OSX build and minimal runtime sanity check
<Chipaca>  Go: 1.1
<mborzecki> Chipaca: yeah, but it didn't happen earlier today
<Chipaca> mborzecki: it's not happened until right now :-)
<mborzecki> Chipaca: imo travis guys have deployed a new 'feature'
<Chipaca> mborzecki: I'd laugh if I didn't need to quote version strings in snapcraft.yaml
<mborzecki> Chipaca: hm that may be a good idea
<mborzecki> heh, let's see how that goes
#snappy 2019-02-06
<mup> PR snapd#6477 closed: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6477>
<mup> PR snapd#6479 opened: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6479>
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: there was bit of trouble with osx builds yday, fortunately john reminded me of how yaml is super ambiguous about numerical vs string representation
<mvo> mborzecki: yeah, I saw that, thank you!
<mvo> mborzecki: I updated the 2.37 version now as well and removed esc.bold
<mborzecki> mvo: i think we could cherry-pick the path warning for .2 too
<mborzecki> oh, ok
<mvo> mborzecki: yeah, we could, probably won't hurt either way
<pstolowski> mornings
<mborzecki> pstolowski: hey
<pedronis> hello
<mvo> hey pstolowski and pedronis
<mborzecki> hey pedronis
<mborzecki> we're down to 43 PRs, not bad
<mvo> indeed and 6479 will land as soon as its green so 42 effectively
<mup> PR snapd#6380 closed: interfaces: add more permissions to network-manager slot <Created by alfonsosanchezbeato> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6380>
<mup> PR snapd#5915 opened: interfaces/network-setup-control: allow calling netplan generate/apply <â Blocked> <Created by ogra1> <https://github.com/snapcore/snapd/pull/5915>
 * dot-tobias waves hello
<mup> PR snapd#6479 closed: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined (2.37) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6479>
<Saviq> is there a way to force "prune" of old snap revisions?
<pedronis> Saviq: in which sense?  we keep a fixed number of them per snap
<Chipaca> Saviq: snap list --all, and some scripting
<Chipaca> Saviq: also, you can configure how many to keep, down to a minimum of 2
<Chipaca> Saviq: https://superuser.com/questions/1310825/how-to-remove-old-version-of-installed-snaps
<Saviq> right, that! thanks
<mup> PR snapd#6480 opened: release: 2.37.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6480>
<zyga> hey
<zyga> I'm just popping in briefly now
<zyga> mvo: have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 ?
<mup> Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1814141>
<mvo> zyga: I have not, that sounds alarming
<mvo> zyga: the second user who is affected is using 4.15 so it looks like its not disco only
<zyga> yeah but it's not widespread either, I haven't seen this on any of my machines
<zyga> I bet we're missing something
<mvo> xnox: re 1814141> any denials in dmesg? (cc zyga)
<mvo> zyga: yeah
<zyga> oh, I didn't notice who reported it!
<zyga> mvo: there's a new version of apparmor around 2.13
<zyga> mvo: wonder if that is related
<zyga> mvo: but it doesn't feel like just apparmor, we would die on many other things before
<pedronis> well, the error is very specific
<pedronis> cannot read mount namespace identifier of pid 1
<pedronis> where do we do that?
<zyga> we check if we are in pid-1 mount namespace
<zyga> but
<zyga> we do that after we check if we are confined or not
<zyga> so either we are confined but the profile is no longer sufficient
<zyga> or we are not confined at all (apparmor disabled on boot) but we get denied somehow?
<zyga> perhaps this is a container so outer container profile is too strict
<pedronis> or we lost the setuid bits?
<popey> Chipaca: snap has "pack" - should it not also have an 'unpack'? Which does whatever unsquashfs does?
<zyga> pedronis: I think we need to get more information from xnox
<Chipaca> popey: nobody's asked for it :-)
<pedronis> there is nothing really special into unpacking a snap
<pedronis> zyga: mvo: also we do run tests on disco, no?
<pedronis> but as root?
<zyga> pedronis: no, we don't
<zyga> pedronis: not in typical travis-spread run
<mvo> pedronis: we should start that soon, when sergio is back
<zyga> pedronis: we run many things as root but a single test running as an user would pick this up
<zyga> (if it was totally broken)
<mvo> I think we have some tests that run snaps as user
<pedronis> ok
<pedronis> anyway we need more info
<mvo> yes, at least in the smoke suite some interface tests run as user we should probably add a very simple explict one still
 * mvo does that
<zyga> mvo: fun idea: run prepare/restore as root, run execute as non-root
<mup> PR snapd#6481 opened: tests: run test snap as user in the smoke test <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6481>
<mvo> zyga: hm, interessting idea
<Chipaca> pedronis: thank you for the review
<pstolowski> mvo: will you have time to take a look at https://github.com/snapcore/snapd/pull/6322 (after release stuff is over)?
<mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
<mvo> pstolowski: yeah, sounds like something for later today or tomorrow (assuming 1814141 isn't a new fire :/)
<pstolowski> uhm
<mborzecki> arch package updated
<mvo> mborzecki: \o/
<mvo> pstolowski: we have a new beta 2.37.2 - if you still have the rpi around, helping with the validation would be most welcome, I created a trello card with the individual tasks
<pstolowski> mvo: sure, will do
<pedronis> Chipaca: hi, did you see my ping about doing a review pass on 6079 given you reviewed some of the prereq
<Chipaca> pedronis: I did not
<Chipaca> pedronis: on it now
<pedronis> Chipaca: thank you
<Chipaca> grah, we're being inconsistent with our help strings again :-(
<pedronis> Chipaca: can't we write tests about some of the rules? or is too much NLP?
<Chipaca> pedronis: we do have some tests
<Chipaca> but apparently not one for this :-)
<Chipaca> which makes me think maybe we didn't discuss & agree on it
<pedronis> Chipaca: what is about?
<pedronis> Chipaca: I mean, what more we should be consistent about and aren't ?
<Chipaca> pedronis: sorry didn't see your q
<Chipaca> pedronis: see "snap list --help"
<Chipaca> pedronis: some options' description ends with a period, some don't
<pedronis> Ah
<Chipaca> it's silly but it irks :-)
<pedronis> Chipaca: what is your preference?
<Chipaca> pedronis: with
<Chipaca> bah, in an ideal world with unicorns and flying cars and no climate change, all but the last option description ends with a ;, and the last one with a .
<pedronis> Chipaca:  do we more with or more without
<mup> PR snapcraft#2455 closed: cli: retrieve error data from provider <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2455>
<Chipaca> (fun fact: we'd have to i18n the ;)
<Chipaca> pedronis: dunno, i'll look into this later
<Chipaca> in the middle of the 'connections' pr
<Chipaca> mborzecki: ping
<pedronis> Chipaca: I don't the whole constute a sentence and there is scansion in other ways
<mborzecki> Chipaca: pong
<pedronis> Chipaca: so I don't have a strong opinion
<Chipaca> pedronis: you a verb there
<pedronis> Chipaca: oops, I don't think the whole of options constitue a sentence
<Chipaca> mborzecki: if I disconnect all the connections of a snap, 'snap connections' doesn't notice
<Chipaca> mborzecki: wondering if I'm holding it wrong
<mborzecki> Chipaca: hmm
<Chipaca> bah, "doesn't notice", that's not quite true
<pedronis> Chipaca: fwiw, I'm slightly in favor of without myself ... but I'm interested whether we tended to do one or the other as well
<pedronis> as I said no very strong opinion here, I do agree we shouldn't do both tough
<pedronis> that is just sloppy
<Chipaca> the difference is just very subtle
<Chipaca> pedronis: same here
<mborzecki> Chipaca: doesn't notice how?
<Chipaca> mborzecki: sorry, it does, it's just very subtle
<Chipaca> this is home, when you disconnect it:
<Chipaca> icdiff:home             :home            home             disconnected,manual
<Chipaca> super clear it's disconnected
<Chipaca> this is personal-files, when you disconnect it:
<Chipaca> icdiff:gitconfig        -      personal-files   -
<pedronis> why the difference?
<mborzecki> Chipaca: right, there is no slot, so no connection, we could show 'disconnected' in the notes column to make it clear
<Chipaca> mborzecki: but home does show the slot it would connect to when disconnected
<Chipaca> why are these so different when they're only different in their autoconnection
<Chipaca> and that's just an assertion away
<Chipaca> also, silly question, shouldn't removing a snap reset its connections?
<Chipaca> if I disconnect something, remove the snap, and then install the snap, shouldn't it have the default connections connected?
<mborzecki> Chipaca: afaik we keep the undersired conenctions in case you install it again
<Chipaca> how do I tell it to connect that which it would've connected?
<mborzecki> Chipaca: explicitly with snap connect
<Chipaca> mborzecki: but that leaves it manually connected
<Chipaca> icdiff:home             :home  home             manual
<mborzecki> Chipaca: yes, because it's a manual connection now
<mborzecki> Chipaca: afaiu there's no going back to the intial state now
<Chipaca> so how do i reset it to not be manual?
<Chipaca> :-(
<mborzecki> Chipaca: so the difference in presentation, what about showing (dis|un)connected in the notes column when there was no slot for a plug?
<Chipaca> mborzecki: what does --all do when you specify a snap?
<Chipaca> mborzecki: +1 to show disconnected when it's disconnected
<mborzecki> Chipaca: --all is quite useless when you name a snap unfortunately, but i didn't error out there
<mborzecki> Chipaca: we're back at https://forum.snapcraft.io/t/rfc-snap-connections-command/4296/5 with parameters and presentation
<Chipaca> mborzecki: playing with it "for real" always iterates these things
<mborzecki> Chipaca: mhm
<Chipaca> mborzecki: some more comments on the PR itself
<mborzecki> Chipaca: thanks!
<Chipaca> mborzecki: https://i.imgur.com/9s6nQG4.png ?
<Chipaca> (that is: dim repeated snap names?)
<mborzecki> Chipaca: fancy
<Chipaca> hm, i should add a 'dim' property to escapes, separately
<Chipaca> mborzecki: don't get me wrong the pr looks good
<Chipaca> mborzecki: i'm just wanting to be super nitpicky about ux because we got it wrong three times already :-)
<mborzecki> hahah :)
<mup> PR snapd#6482 opened: [RFC] cmd/snap: make 'snap list' show disabled snaps dimmed <Created by chipaca> <https://github.com/snapcore/snapd/pull/6482>
 * Chipaca had his fun, and now goes for lunch
<jdstrand> mvo, zyga: fyi, I'm going to start looking at apparmor 2.13 for disco soon (assuming I can ever get away from things that keep preempting it :\)
<zyga> ack
<zyga> jdstrand: suse has it now
<jdstrand> so does Debian
<zyga> yes, I think I saw it in sid as well
<pedronis> Chipaca: thanks for #6356,  a few small comments still
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<zyga> mvo: fedora builds under way,  I will keep you posted, going back to bed :/
<roadmr> zyga: bed? are you sick... oh wait I know why you're sleep deprived! hang in there!
<zyga> roadmr: yeah, sick
<roadmr> oh ouch :( get better, zyga
<zyga> thank you :)
<zyga> jdstrand: can you look at https://launchpadlibrarian.net/409976796/journalctl__grep_DENIED__tail.txt
<zyga> this is from https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141
<mup> Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1814141>
<zyga> jdstrand, mvo: I added a hypothesis to that bug report
<pstolowski> jezz pi3 tests are soo sloow, 195/262 and it's already over 3h
<zyga> mborzecki: ping
<Son_Goku> niemeyer, mvo, Chipaca, zyga, mborzecki: so snappy variant is now a thing in fedora-release: https://src.fedoraproject.org/rpms/fedora-release/c/f171adca021ec0a2c599ce7c87f841c7face5f69?branch=master
<Son_Goku> :D
<Chipaca> woop woop :-)
<mborzecki> Son_Goku: nice!
<zyga> thank you, that's a great milestone!
<Son_Goku> now I just need to simplify and rework my tool for building the base snap
<Chipaca> Son_Goku: a SMOP
<Chipaca> :-)
<Son_Goku> ?
<Son_Goku> haha
<Son_Goku> indeed it is
<niemeyer> Son_Goku: Woo, nice!
<Son_Goku> now I just need snapcraft to know how to consume fedora content using dnf
<mvo> Son_Goku: woah, amazing!
 * mvo hugs Son_Goku 
<Son_Goku> ð
<Son_Goku> niemeyer, do you think you could see if snapcraft folks would prioritize integrating support for dnf as a backend as an alternative to apt?
<Son_Goku> I'm fairly confident by now that I'll have fedora releng pushing official base snap stuff for fedora 30
<Son_Goku> I just need to figure out _what_ should be in it :P
<Chipaca> sergiusens: ^
<niemeyer> Son_Goku: It seems reasonably easy.. not sure if the snapcraft folks (e.g. Sergio :-) would do that first, or if it might be easier to just contribute an initial patch that abstracts the package management away
<Son_Goku> I did write a skeleton patch to separate the backend from the interface two years ago
<niemeyer> Son_Goku: If nothing else, that would make it easier to discuss the design
<Son_Goku> I'll need to check how much of that is needed now with snapcraft 3.0
<Son_Goku> sure
<niemeyer> Son_Goku: It probably hasn't changed much, and it should now also be easier to integrate it nicely since we have proper base (IOW, multi image) support
<Son_Goku> right
<Son_Goku> niemeyer, part of this is that if there are problems with DNF interfaces/APIs, we can start poking the DNF team to look at fixing them
<Son_Goku> if we can't fix them ourselves, that is
<Son_Goku> as a package manager developer, you better than anyone else can understand how "weird" snapcraft's use-case is
<niemeyer> Son_Goku: Once you have a better idea of how this should work, feel free to schedule (or ask to) a meeting with you, sergiusens, cmatsuoka, pedronis, and myself
<Son_Goku> will do, though I can't say I know who cmatsuoka is?
<niemeyer> He's hanging here.. Claudio Matsuoka.. he's recently joined the team and will be working on snapcraft in the next few weeks at least
<Son_Goku> nice
<Son_Goku> well, for the moment, I'm focused on getting the base snap work done
<Son_Goku> but it's something that's on my infinitely long TODO :)
<jdstrand> pedronis: hey, I'm looking at https://github.com/snapcore/snapd/blob/master/interfaces/policy/policy.go#L98
<jdstrand> pedronis: meh, nm for the moment
<jdstrand> pedronis: no, actually, that function is checking the slots (snap decl, then base) then checking the plugs (snap decl, then base)
<pedronis> jdstrand: sorry, not following what you are pointing to
<jdstrand> pedronis: such that, if there is an error (aka, aiui, something that would prevent installation), then something in the slots that prevented installation would preempt something in the plugs that might allow it
<jdstrand> pedronis: checkSlot will look at snap then base
<pedronis> jdstrand: that is correct
<pedronis> slots and plugs are orthogonal at that level
<pedronis> it's not like connections
<pedronis> you cannot unblock installing a slot
<jdstrand> I was expecting the logic to be different
<pedronis> by telling something about plugs
<jdstrand> I see
<pedronis> that wouldn't make sense
<pedronis> jdstrand: I mean that logic is correct and doing otherwise feels like would be wrong security wise
<jdstrand> pedronis: ok. basically, I'm rewriting the snap decl checks in the review tools to use the same procedure as snapd. I chose installation since it was before connection in the file, but it has a different algorithm that I don't need to worry about. thanks for clearing that :)
<pedronis> jdstrand: but I can confirm, connection checks and installation checks are very different
<pedronis> jdstrand: for connection is about can this plug be connected to that slot, but sides have a voice
 * jdstrand nods
<pedronis> jdstrand: for installation, is can I install a snap sporting a plug of this interface, can I instal a snap sporting this slot?  and plug and slot of the same interface on a snap are really unrelated for this
<jdstrand> yeah
<jdstrand> that isn't expressed in the spec afaics, so that would be another point to finetune
<jdstrand> ok, thanks! that reminder helps a lot
<pstolowski> mvo: when the beta validation test says "(for snapd promotion)", does it mean anything for the test?
<cmatsuoka> Son_Goku: looking at how dpkg support was implemented, adding support to dnf/rpm shouldn't be too hard
<mvo> pstolowski: its just a reminder for myself
<mvo> pstolowski: this means this particular test is used to test the snapd snap
<mvo> pstolowski: the other tests are about the "core" snap
<Saviq> hey, does `snap` have a way to wait for snapd to be ready?
<mborzecki> Son_Goku: posted karma for EPEL update
<Son_Goku> cmatsuoka, I already contributed support to dump rpms a couple of years ago
<mvo> pstolowski: so in theory we could release core once all tests are done and later snapd (once those tests are done)
<mvo> pstolowski: does that make sense?
<Son_Goku> cmatsuoka, it's just that adding proper support for an rpm distro as a repo source was really hard
<cmatsuoka> Son_Goku: it would certainly require a lot of tests and experimentation after the basic support is in place
<cmatsuoka> Son_Goku: what were the main problems you found back then?
<pstolowski> mvo: hmm, kind of; i don't know how to run "beta validation core18 - fresh install pi3 (for snapd promotion)" then per sergio's instructions
<Son_Goku> cmatsuoka, well, back then, I couldn't figure out how to make the code do the right thing
<Son_Goku> because snapcraft didn't know bases
<pstolowski> mvo: sounds like it's more than just installing beta of core18 on pi3 and running the tests with dev_snapd_pi_18
<cmatsuoka> Son_Goku: oh I see. it should be easier now :)
<Son_Goku> and also, snapcraft goes back and forth between in chroot and out of chroot
<mvo> pstolowski: that should be enough, use the fresh image of UC18 generator with the validator thing and run the dev_snapd_pi_18
<mvo> pstolowski: that should be ok
<Son_Goku> and one other problem is that the package manager likes to record its stuff in the databases in /var/lib/rpm and /var/lib/dnf
<pstolowski> mvo: allright
<pstolowski> mvo: thanks
<Son_Goku> and we _need_ that information to be writable during snap build time
<Son_Goku> or rather $SNAP/var/lib/rpm and $SNAP/var/lib/dnf
<Son_Goku> we can obviously not include them on the layered snap, but the way the package manager works requires that
<Son_Goku> and of course, figuring out how to block "updating" base libraries
<Son_Goku> the last part, I have an idea for, but the others I don't
<cmatsuoka> Son_Goku: so now you could theoretically use a fedora base in the build provider, install all the packages you need there during the snap build
<Son_Goku> right
<cmatsuoka> the build provider being a multipass vm
<Son_Goku> oh right
<Son_Goku> we don't have multipass in Fedora yet...
<cmatsuoka> it's installabe as a snap
<Son_Goku> and in fedora infra, we have to be able to run snapcraft in a chroot
<cmatsuoka> I run multipass on a bare metal fedora, it works well
<Son_Goku> I thought multipass only makes ubuntu VMs?
<Son_Goku> that's not particularly useful in this case
<cmatsuoka> but wait, let me understand exactly what you are trying to accomplish here :)
<Son_Goku> I want:
<Son_Goku> 1. to be able to build snaps using a fedora base
<Son_Goku> 2. to be able to use snapcraft for snaps to be built on top of the fedora base, even officially by fedora packagers
<Son_Goku> 3. to be able to run snapcraft within Koji, the fedora build system
<cmatsuoka> ok. then you need snapcraft to recognize fedora (or a specific version of fedora) as a base. then during the build process snapcraft would instance a fedora VM, install rpm packages, stage, prime and produce the snap
<cmatsuoka> at runtime, you would need a fedora base image to support the snap created on top of the fedora base VM
<Son_Goku> the main issue is that Koji does not allow VM creation
<Son_Goku> Koji instantiates target-specific chroots, and runs the stuff in there
<Son_Goku> and they're not privileged enough to spin up VMs
<cmatsuoka> can we run lxd containers there?
<cmatsuoka> we should have support to lxd providers in some near future
<Son_Goku> no
<Son_Goku> no lxd packaged in fedora, and no support in koji
<Son_Goku> the former would be required for the latter
<cmatsuoka> I also run lxd from snap on my fedora system, but you probably want something more "native"
<cmatsuoka> I can't say for sure if snapcraft would work with a plain chroot provider, perhaps sergiusens could enlighten us here
<sergiusens> cmatsuoka: we have nothing built out for chroots today
<cmatsuoka> sergiusens: but that would be feasible?
<sergiusens> cmatsuoka: I suspect --destructive-mode could work and then it could be just like those docker images people build
<cmatsuoka> sergiusens: yes, that's my feeling as well
<cmatsuoka> Son_Goku: so you could set up your chroot, put snapcraft and the source project there, and run snapcraft in destructive mode inside the chroot
<cmatsuoka> Son_Goku: the dnf-aware snapcraft
<Son_Goku> okay, so there's a mode there
<cmatsuoka> Son_Goku: yes, currently the default is to use a build provider such as multipass (and, in fact, it's the only provider available right now)
<cmatsuoka> Son_Goku: but you can also tell snapcraft to not use the provider, and run in the host environment
<cmatsuoka> this is the "destructive mode"
<Son_Goku> does multipass use libvirt?
<Son_Goku> ah, so it does
<Son_Goku> it'd be cool if it was packaged in Fedora and could use the Fedora-published VM images
<Son_Goku> or at least if the snap could make fedora VMs too
<cmatsuoka> currently multipass itself is packaged as a snap and runs on fedora, but I don't know if there's a fedora image availability
<cmatsuoka> s/availability/available right now/
<Saviq> hey all, is there a `snap waitforready` of some kind that will ensure I'm not calling `snap install` before snapd is ready?
<Chipaca> Saviq: yes
<Chipaca> Saviq: there's even a service that uses that, that we use in cloud? i think?
<Chipaca> Saviq: snapd.seeded.service
<Chipaca> Saviq: does a "snap wait system seed.loaded"
<cmatsuoka> Saviq: do we have any fedora image available for multipass?
<Saviq> Chipaca: the socket doesn't exist yet here so that won't work...
<Chipaca> Saviq: whoa
<Chipaca> Saviq: how does the socket not exist yet? what's starting your thing?
<Saviq> Chipaca: lxd container
<Chipaca> Saviq: 1. wait for the socket (it should get created really early in boot)
<Chipaca> Saviq: 2. as above :-)
<Chipaca> Saviq: is it a systemd unit?
<Saviq> Chipaca: no, just driving snapcraft from outside the container
<Chipaca> Saviq: note the socket gets created before the snapd binary is started
<Saviq> I know, socket activated
<Chipaca> yup
<Chipaca> meaning it's in relatively early boot
<Saviq> but still, I get ENOFILE when trying to install a snap
<hunterk> new installs of my snap package (i.e., not updates) have started complaining about "mkdir: cannot create directory â/home/[username]/snap/[packagename]â: Read-only file system". Does anyone know what would cause this?
<Saviq> oh well, will get bash to wait for the socket
<Saviq> or just try to install a couple times ;P
<Chipaca> pedronis: in laneSnaps, your argument to pass in the tasks seems to mean I should actually pass in the rerefresh task (so the id and tasks are obviously in sync)
<Saviq> cmatsuoka: I've not tried, but https://alt.fedoraproject.org/cloud/ should work
<Saviq> as long as it has cloud-init
<pedronis> Chipaca: that makes sense
<cmatsuoka> Son_Goku: ^^
<Chipaca> pedronis: it's going to break the unit tests :-) but easy to fix
<Son_Goku> it does have cloud-init
<pedronis> Chipaca: yes, it's a change, but I tried to explain why I think it makes sense :)
<Saviq> Son_Goku: `snap install multipass --classic --beta; multipass launch https://...` will tell you soon enough whether it works or not
<Chipaca> pedronis: i agree
<Son_Goku> I'll have to try that later, then :)
<mup> PR snapcraft#2460 closed: build providers: recreate instance if base changed <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2460>
<Saviq> Son_Goku: fwiw the OpenStack image seems to work fine, there's probably rough edges as we're assuming dpkg inside at the moment
<Son_Goku> yeah
<Saviq> also a bug in our snap packaging prevents the `launch https://` from working - need to download the image and `launch file://`
<Saviq> and `dnf makecache` takes quite a while, we should not wait for that
<mup> PR snapcraft#2462 opened: Release changelog for 3.1.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2462>
<Saviq> Son_Goku: feel free to file bugs under https://github.com/CanonicalLtd/multipass/issues/new as you encounter them :)
<Saviq> hey all, we want to transition multipass to core18 and realized there's a case where the upgrade needs user intervention to avoid data loss, what's the state-of-the-art approach to this situation? forcing a rollback (how)? failing one of the hooks (which)?
<Saviq> epochs are not a thing yet, are they? would they be of help?
<JnR> Oh thank god a Snap chat
<JnR> modprobe: FATAL: Module msr not found in directory /lib/modules/4.15.0-45-generic
<JnR> Wtf is msr?
<JnR> I was building a Snap with lxd
<JnR> I have Linux Mint
<JnR> Sorry I meant how do I get the msr. I have an idea what it is
<Saviq> JnR: hey, this module lets you ~interrogate the BIOS to find out about virtualization support
<Saviq> JnR: would you please file an issue in https://github.com/CanonicalLtd/multipass/issues/
<Saviq> JnR: and in the mean time run `kvm-ok` that will guide you through ensuring your system can build snaps through multipass
<Saviq> some reading about why that's needed https://forum.snapcraft.io/t/reasoning-behind-the-move-to-multipass/9648
<JnR> Saviq at what point run kvm-ok? in substitute of snapcraft?
<JnR> I haven't heard that command mention in any articles
<Saviq> JnR: just once, now is fine
<Saviq> the msr module won't be needed if kvm is already set up proper
<mup> PR # closed: snapd#5644, snapd#5915, snapd#5962, snapd#6034, snapd#6079, snapd#6098, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6281, snapd#6313, snapd#6320, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341,
<mup> snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6376, snapd#6381, snapd#6401, snapd#6404, snapd#6406, snapd#6410, snapd#6413, snapd#6418, snapd#6436, snapd#6464, snapd#6465, snapd#6469, snapd#6472, snapd#6476, snapd#6478, snapd#6480, snapd#6481, snapd#6482
<JnR> INFO: /dev/kvm exists
<mup> PR # opened: snapd#5644, snapd#5915, snapd#5962, snapd#6034, snapd#6079, snapd#6098, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6281, snapd#6313, snapd#6320, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341,
<mup> snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6376, snapd#6381, snapd#6401, snapd#6404, snapd#6406, snapd#6410, snapd#6413, snapd#6418, snapd#6436, snapd#6464, snapd#6465, snapd#6469, snapd#6472, snapd#6476, snapd#6478, snapd#6480, snapd#6481, snapd#6482
<JnR> KVM acceleration can be used
<JnR> Is that the appropriate response?
<Saviq> JnR: yes, can you please run snapcraft now and if it fails, please pastebin the whole log?
<JnR> Saviq Yes sir
<JnR> https://pastebin.com/LvAxLmfP
<JnR> I ran it in debug mode
<JnR> https://pastebin.com/RaXcfRFH
<JnR> Sorry I forgot the 2nd half
<ChrisTownsend> The real question is why isn't `/dev/kvm` there?
<ChrisTownsend> That's the first check the script does and if that fails, it detects if the msr module is available, and if not, it tries to load it.
<ChrisTownsend> JnR: Does `/dev/kvm` exist on your machine?
<JnR> ChrisTownsend yes I just ran kvm-ok 5 minutes ago
<JnR> INFO: /dev/kvm exists
<ChrisTownsend> JnR: Ok, hmm...
<JnR> KVM acceleration can be used
<JnR> ChrisTownsend I did read that Linux Mint has problems. I don't know why but it was the only OS they mentioned
<ChrisTownsend> JnR: I wonder if it somehow blocks even classic installed snaps from accessing /dev.
<greyback> JnR: you mentioned you are using lxd? How exactly?
<ChrisTownsend> Just guessing, I have no proof at all.
<ChrisTownsend> greyback: I think multipass is being used and not lxd.
<JnR> https://docs.snapcraft.io/build-on-lxd/4157
<JnR> That's what I was following
<Saviq> yeah with `base: $anything` multipass is used by default these days
<greyback> aha, then that's a problem, as lxd installed from a snap does not have /dev/kvm access
<greyback> running multipass inside lxd fails with that exact error
<JnR> greyback Seriously? No wonder I'm running in circles
<Saviq> oh you're *inside* lxd
<JnR> I thought the snapcraft website would be a good place to start...
<ChrisTownsend> I didn't realize snaps could be installed inside a lxd container...
<ChrisTownsend> But yeah, I guess that makes sense:)
<JnR> No wonder It took me 2 hours to get it to calm down about multipass
<greyback> JnR: unfortunately yeah. You're better off avoiding lxd for now.
<Saviq> sergiusens: https://docs.snapcraft.io/build-on-lxd/4157 seems like could need some love...
<Saviq> s/need/use/
<Chipaca> sergiusens: degville wrt build-on-lxd, maybe just a warning at the top "this only applies if you don't have base:"?
<Chipaca> oh it already has that
<Chipaca> hmm
<Chipaca> Â¯\_(ã)_/Â¯
<degville> Chipaca: mmm... I could make it clearer, rather than easily skipoverable.
<Chipaca> so the problem was that that document explains how to make snapcraft build inside lxd
<Chipaca> which is different from running snapcraft inside lxd to build in whatever
<Chipaca> at least AIUI
<JnR> What's the point of a disclaimer if it's not going to work?
<JnR> Unless the disclaimer said "Doesn't work" of course
<Saviq> JnR: it is going to work, *if* you snapcraft.yaml does not have "base: " stanza in it
<Chipaca> JnR: Saviq: hold on
<Saviq> ok /me backs out anyway
<JnR> Saviq ohhhh ok I have no idea what you mean
<Chipaca> JnR: Saviq: that document that JnR pointed to, explains how to set up snapcraft to build things using lxd instead of multipass
<JnR> Chipaca Was I not supossed to use Multipass at all?
<Chipaca> Saviq: I don't know if the document is still accurate, you know more than (or as much as) I do probably about that
<Chipaca> JnR: what you are trying to do is _something completely different_
<Chipaca> JnR: but, due to the limitations of language, it's hard to explain the difference between getting into a riddle
<Chipaca> JnR: you're running snapcraft inside lxd, and want to use it to build things inside there
<JnR> Chipaca I'm fine with that but I just want to make it a point I followed the guide decently
<Chipaca> JnR: so the question is, how did you follow a guide that tells you how to make snapcraft run lxd, and ended up having lxd run snapcraft
<JnR> Chipaca Of course you're going to make me feel foolish now you know an exponential amount more than me
<Chipaca> JnR: be nice
<Saviq> JnR: if you're already in a container dedicated to this build, run `snapcraft --destructive-mode`
<JnR> Chipaca Sorry I'm kinda joking my bad. But I was not in a container
<Saviq> it is destructive because it will try and install packages in there
<JnR> I started the container I didn't go in it
 * Saviq biab
<JnR> I thought it was basically a virtual environment
<JnR> Sometimes you guys forget what it's like to learn this subject
<ChrisTownsend> JnR: Are you using snapcraft from the archive or from the snapcraft snap?
<JnR> ChrisTownsend I downloaded everything from Snap
<ChrisTownsend> JnR: I see "load_entry_point('snapcraft==2.43.1+18.4', 'console_scripts', 'snapcraft')()" which leads me to believe you are using the archive version.
<ChrisTownsend> JnR: Can you run "which snapcraft" and give me the output?
<JnR> I used snap to download and after some error I refreshed everything as well
<JnR> usr/bin/snapcraft
<ChrisTownsend> JnR: Ah, ok, this is your problem.  It's defaulting to the old, incompatible version.   Can you try `/snap/bin/snapcraft --help` just to see if that is there?
<JnR> ok
<ChrisTownsend> JnR: Also, `/snap/bin` in your $PATH is last, so your system will try to use other executables first.
<JnR> https://pastebin.com/sjHFpYbm
<JnR> Your first request
<JnR> '/snap/bin' is in my path. I put it there and just checked again
<ChrisTownsend> JnR: Ok, that is what we need...but that traceback is due to the exported `SNAPCRAFT_BUILD_ENVIRONMENT=lxd` env var.
<sergiusens> JnR: on lxd, considering that you are on the correct image, you can use `--destructive-mode`
<JnR> I'm assuming that's like --force?
<ChrisTownsend> JnR: Is it first in your path or last?
<ChrisTownsend> `/snap/bin` that is.
<JnR> '/var/lib/snapd/snap/bin:/snap/bin:/var/lib/snapd/snap/bin' this is the end of my $PATH
<JnR> It's a fresh Linux install theres not much
<ChrisTownsend> JnR: Also, let's try to clean up from this and start afresh...
<sergiusens> JnR: yes, in some ways, just more in your face wrt potential damage to the system where it is run on
<ChrisTownsend> JnR: So first, unset `SNAPCRAFT_BUILD_ENVIRONMENT=lxd` by doing `SNAPCRAFT_BUILD_ENVIRONMENT=`.
<ChrisTownsend> JnR: Then do `snapcraft clean` (not the /snap/bin/ version).
<ChrisTownsend> JnR: Then I think you will want to just use multipass instead of lxd since that is the way things are going.  I know, the tutorial you are referring to, but I think it would be better to go the multipass way.
<ChrisTownsend> JnR: Then you can do `export SNAPCRAFT_BUILD_ENVIRONMENT=multipass`
<ChrisTownsend> JnR: And then you should just be able to do `/snap/bin/snapcraft`
<ChrisTownsend> JnR: I hope this helps.
<JnR> But the reason I went towards lxd was the warning about Linux Mint having trouble with the base method
<JnR> Is that not correct?
<JnR> I'm pretty much quoting
<ChrisTownsend> JnR: I'm not familiar with that warning.  Do you have a link I can read or the such?
<ChrisTownsend> JnR: Also, which snap are you trying to build?  I'd like to look at its snapcraft.yaml and see if it's defining a base.
<JnR> ChrisTownsend Actually I tried a guide previously that mentioned Mint... Damn it was probably outdated. My snapcraft.yaml is terrible I was using trial and error when I hit that bump. I just ran snapcraft again and it went great except for some of my files being misplaced
<JnR> ChrisTownsend I mean I mistyped their location
<JnR> An error occurred when trying to execute 'sudo -i snapcraft snap' with 'multipass': returned exit code 2.
<JnR> I did get this error though
<JnR> I didn't use sudo I swear
<ChrisTownsend> JnR: Sorry, I got disconnected...could you repeat the last couple of things you said?
<JnR> An error occurred when trying to execute 'sudo -i snapcraft snap' with 'multipass': returned exit code 2.
<JnR> That was the only real error I got that wasn't my misspelling
<sergiusens> Chipaca: btw, for the highly requested `--use-lxd` I would need a non root user way to retrieve the currenly installed snapcraft and its base (or core).
<JnR> I didn't use sudo
<JnR> Nvm it went away on debug. All is well
<JnR> Thanks for the help
<ChrisTownsend> JnR: So it's working?
<sergiusens> mvo: hey there! Just a reminder that you never got back to me on https://bugs.launchpad.net/snapcraft/+bug/1805219
<mup> Bug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1805219>
<JnR> ChrisTownsend My only problem left is just that it's saying my binary files don't exist. Probably just a typo
<JnR> I'm not using to referring to exe files in linux
<pedronis> mborzecki: are you reusing anything from #6464 in the end?
<mup> PR #6464: [RFC] many: add simple performance measure tool mostly for firstboot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6464>
<ChrisTownsend> JnR: Ok, good luck!
<JnR> ChrisTownsend Sorry I'm so close and I'm clearly not formatting this file correctly. One more favor
<JnR> https://pastebin.com/DKV7cjjS
<JnR> I know it's probably totally jacked up I just kinda went with trial and error
<JnR> I can't load the files properly
<ondra> sergiusens seems like passthrough is not passing through. is there some extra level of intelligence in passthrough?
<ChrisTownsend> JnR: Well, the 'base: core18' in there explains why multipass was being used in your example.  But as far as the snapcraft.yaml, yeah, I'm not really sure what you are trying to accomplish there.  Maybe someone else here that is an expert on this can help???
<pedronis> pstolowski: I did (re)reviews of the current hotplug PRs
<pstolowski> pedronis: great, thank you
<mvo> sergiusens: thanks, looking
<pstolowski> pedronis: replied
<pstolowski> (to some suggestions, not all)
<pstolowski> mvo: pi3 just finished for me, two failures this time - smoke/install and sanbox; these are the ones that failed 2.37.1 validation right?
<pstolowski> *pi3 tests
<mvo> pstolowski: I look at the failures
<mvo> pstolowski: can you please paste me the failures?
<pstolowski> mvo: http://paste.ubuntu.com/p/K84f6yWmmq/
<mvo> pstolowski: those look like test issues to me, re-running those would be great
<mvo> pstolowski: maybe tomorrow?
<pstolowski> mvo: sure
<pstolowski> eod for now, cu
<mvo> pstolowski|afk: just the two that failed, I'm almost 100% positive this will be fine
<mvo> pstolowski|afk: enjoy - thanks for your help today!
<pstolowski|afk> o/
<Saviq> hey all, we want to transition multipass to core18 and realized there's a case where the upgrade needs user intervention to avoid data loss, what's the state-of-the-art approach to this situation? forcing a rollback (how)? failing one of the hooks (which)?
<Saviq> epochs are not a thing yet, are they? would they be of help?
<mup> PR snapd#6464 closed: [RFC] many: add simple performance measure tool mostly for firstboot <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6464>
<mup> PR snapcraft#2463 opened: Pass --work-dir param for out-of-tree builds <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2463>
<pedronis> Chipaca: I answered your question, also somehow I missed the FileName suggestion, anyway I would keep Filename
<Chipaca> k
<Chipaca> pedronis: thanks
<Chipaca> pedronis: i'm going to ignore it until the morning :-)
<bashfulrobot> Quick question I hope. With snapcraft 3, the cleanbuild command  is not longer allows when using the base keyword. What is the proper way to build with a clean environment?
<bashfulrobot> oh, think I found it. set `SNAPCRAFT_BUILD_ENVIRONMENT multipass` and then simply the `snapcraft` command.
<roadmr> bashfulrobot: jeopardy answer (I don't know, just throwing it out there so it sticks on the wall maybe?) - all builds are done in a multipass vm and so are a "clean environment" by default
<bashfulrobot> roadmr: I think you are right
<roadmr> \o/
<bashfulrobot> Unless you set 'host', 'managed-host', or 'multipass'
<roadmr> ah, I didn't know about those :)
<sergiusens> bashfulrobot: cleanbuild is still there if not using bases, no need to play with those environment variables
<JnR> Apparently since earlier I've been stuck in some VMX ROOT MODE
<mup> Bug #1814971 opened: 'up arrows' in snap info version list are hard to read and parse <Snappy:New> <https://launchpad.net/bugs/1814971>
#snappy 2019-02-07
<mup> PR snapcraft#2462 closed: Release changelog for 3.1.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2462>
<mborzecki> morning
<mborzecki> mvo: hey
<mborzecki> mvo: #6480 can land, right?
<mup> PR #6480: release: 2.37.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6480>
<mvo> mborzecki: good morning! yes, the changelog can land
<mup> PR snapd#6480 closed: release: 2.37.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6480>
<pstolowski> mornings
<pedronis> hello
<mvo> hey pstolowski and predronis
<mwhudson> mvo: should i (or someone) upload 2.37.2 to debian?
<mvo> mwhudson: that would be great, yes
<mvo> mwhudson: it fixes some small regressions around classic snaps and special users
<mwhudson> mvo: have you managed to import the debian packaging into snapd upstream?
<mvo> mwhudson: there is a PR for this https://github.com/snapcore/snapd/pull/6413 but it needs one more review
<mup> PR #6413: packaging: import debian salsa packaging work, add sbuild test and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
<mvo> mwhudson: with this the packaging updates would be super trivial because we can just keep in sync this way and we (upstream) detects any dependency issues very early, we even could have a real "debian" branch so that the release is literally just "gbp"
<mwhudson> mvo: would my uploading 2.37.2 the old way make your life harder?
<mvo> mwhudson: I initially imported with all history from salsa but there is a bad commit in there that breaks something, iirc gbp because of an invalid email address
<mwhudson> is it worth waiting for that to merge?
<mvo> mwhudson: just go ahead
<mwhudson> ok
<mvo> mwhudson: I will just merge your changes
<mvo> mwhudson: and then once its in our master I plan to take the salsa one, merge our master, fix the conflicts and then things should be super smooth
<pstolowski> mvo: i've re-run smoke/install test on pi3 and it failed with same symptoms as yesterday
<pstolowski> mvo: this is probably relevant: snapmgr.go:247: cannot read snap info of snap "core" at revision 6351: cannot find installed snap "core" at revision 6351: missing file /snap/core/6351/meta/snap.yaml
<pstolowski> mvo: and then https://pastebin.ubuntu.com/p/SFjvTQgghK/
<mvo> pstolowski: did you use a fresh image before the re-run?
<pstolowski> mvo: no
<mvo> pstolowski: I think thats the issue, the test scrweed things up
 * mvo needs to be afk for ~10min
<pstolowski> mvo: ah
<pstolowski> mvo: ok, reflashing
<mwhudson> mvo: uploaded
<mvo> mwhudson: thank you!
<mvo> pstolowski: I think the issue is (I saw that in another test) that the restore is doing something wrong sometimes, I saw that there was a "core" snap in the state but not on disk so things got confused
<pstolowski> mvo: sounds plausible
<mvo> pstolowski: don't get me wrong, we need to get to the bottom of it but its not an OMGnow priority :)
<pstolowski> mvo: yes, of course, it's just a test helpers issue
<mvo> exactly
<pstolowski> mvo: hmm, i though i could request individual tests with SPREAD_TESTS=... env when running run_external_device.sh, but it doesn't seem to be the case. is there a way to run the script and have device prepared and only run specific tests?
<pstolowski> *thought
<pstolowski> ah i made a typo, retrying..
<mvo> pstolowski: aha, nice, I was not aware of this option! when I retried so far I was doing it by hand (which is a bit cumbersome). thanks for this
<pstolowski> mvo: nah, ignore it, doesn't work, it's probably an internal variable in the scripts
<pstolowski> mvo: anyway, i re-run the two tests manually and they passed
<mvo> pstolowski: thank you!
<mvo> pstolowski: I had the same the other day (not the same test but same error and symtoms and re-run on a clean image made it pass)
<pstolowski> pedronis: re your comment about renaming/simplyfing RequestedSlotSpec, that could be a separate followup PR i think
<pedronis> pstolowski: yes, but we should probably agree a bit on what, anyway this PRs all need 2nd reviews
<pstolowski> pedronis: indeed
<mvo> I should have time for reviews today
<pstolowski> mvo: do you think you could the 2 hotplug PRs?
<pstolowski> *could review*
<mvo> yeah, I looked at the rename one a bit this morning but need to look at the first one first
<pstolowski> mvo: yeah, #6465 should land first, will make the rest smaller
<mup> PR #6465: overlord/ifacestate: hotplug-add-slot handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
<pedronis> pstolowski: can we have a short HO about in 30 mins about the Spec stuff?
<pstolowski> pedronis: yes
<pedronis> cool
<mborzecki> Chipaca: pushed some tweaks to snap connections
<mborzecki> Chipaca: the help message is likely worse than it was in the beginning :) i'd love some input from you and degville on this
<degville> mborzecki: I'll take a look :)
<mborzecki> drat, i probably need to update the spread test now
<pstolowski> pedronis: standup HO?
<pedronis> yes
<mwhudson> "failed mips build of snapd 2.37.2-1" oh noes
 * mwhudson goes to bed
<mvo> mwhudson: meh, do you have a link to the build log?
<mwhudson> mvo: it's really no concern, it has always failed on mips
<mvo> pedronis: do you think 6413 could land with only a single review? given that its mostly packaging and a little bit of tests?
<mvo> mwhudson: aha, ok
<mwhudson> although if you really want a look https://buildd.debian.org/status/package.php?p=snapd
<mwhudson> -buildmode=pie not supported on linux/mips
<mvo> I see
<mvo> thanks!
<mborzecki> degville: what do you think about this https://paste.ubuntu.com/p/5Znd8JZ7f2/ ?
<Chipaca> mborzecki: problem with that is that you don't clearly say that without a snap it lists all
<Chipaca> mborzecki: maybe the first sentence, ... between plugs and slots >for all snaps< in the system
<Chipaca> mborzecki: and to emphasize it, in the first example, Lists connected and unconnected plugs and slots ~for~ >limited to< the specified snap.
<Chipaca> or something like taht
<mborzecki> Chipaca: degville: how about this one https://paste.ubuntu.com/p/CfcwX7J2Qv/ ?
<Chipaca> mborzecki: winner
<degville> yep!
<mborzecki> Chipaca: degville: ok, updating the code, thanks for the help!
<degville> mborzecki: np!
<pedronis> Chipaca: degville: thanks for the review/inputs on that PR. I will try to my own pass over it later today
<Chipaca> pedronis: pstolowski: would it make sense to have (pre-)refresh hooks know the revision on both sides of the refresh?
<Chipaca> multipass snapshots live VMs on refresh, and the snapshot format isn't compatible between 16 and 18, so they need to block a refresh if a vm is alive and it's trying to go between those two
<pstolowski> Chipaca: imho - yes, that was brought a couple of times but never reached conclusion
<pstolowski> Chipaca: could be snapctl enhancement, or in env
<pedronis> Chipaca: maybe, revisions are not a useful concept to code around tough
<Chipaca> pedronis: yeah, epochs would be better there :-)
<pedronis> Chipaca: well, but if they use epochs and express they can't go from here to ther
<pedronis> they can't never update
<pedronis> unless we had a --foce
<pedronis> s/had/add/
<pedronis> heh, --force
<Chipaca> pedronis: issue for them is that you could, all you need to do is stop your vms (or know they'll be stopped for you?)
<pedronis> Chipaca: yea, epochs don't quite fit that
<Chipaca> pedronis: https://forum.snapcraft.io/t/how-to-cause-a-snap-rollback/9848/8?u=chipaca
<pedronis> yes, I'm aware of that forum post
<pedronis> I haven't had brain cycle to more than skim it so far tough
<Chipaca> :-) no worries
<sparkiegeek> popey: just watching your Snapcraft live - are you familiar with being able to run 'less /path/to/foo.snap' to see what's in there? easy way of peeking to see what's there (maybe don't need to unsquashfs at ~29:00)
<sil2100> mvo: hey! Is the snapd 2.37.1 for cosmic good? I mean, you mentioned that the bionic-visible regression did not affect cosmic, right?
<sil2100> mvo: is it safe to release?
<mvo> sil2100: it is ok, there is a new 2.37.2 available thought that fixes a rare corner case
<mvo> sil2100: I think I would slightly prefer 2.37.2 unless you need the update now
<mvo> sil2100: 2.37.2 is already in *-proposed
<sil2100> mvo: it's fine, I'll wait for 2.37.2 then
<sil2100> btw. it's not yet in -proposed, it's waiting for review o/
<mvo> sil2100: ups, thats what I meant, its waiting for -proposed
<mvo> sil2100: *nudge* *nudge* *wink* *wink* :P
<mvo> sil2100: (no worries, I will wait for the archive-admin of the day)
<sil2100> I'll review it today in a bit hopefully (since it's my shift today ;p)
<mvo> sil2100: thank you
<mup> PR snapd#6483 opened: image,cmd/snap:  simplify --classic-arch to --arch, expose prepare-image <Created by pedronis> <https://github.com/snapcore/snapd/pull/6483>
<pedronis> Chipaca: standup?
<Chipaca> pedronis: nah
<mup> PR core18#116 closed: Support arm64 with efi bootloader <Created by woodrow-shen> <Merged by sil2100> <https://github.com/snapcore/core18/pull/116>
<mup> PR core18#113 closed: hook-tests: add more hook tests <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/113>
<mup> Bug #1576775 changed: Docs: missing command to check a service status and logs <snap-docs> <Snapcraft:Confirmed> <snapd:Fix Released> <https://launchpad.net/bugs/1576775>
<popey> https://forum.snapcraft.io/t/retroarch-help-with-issue-on-first-launch/9869
<popey> that's a bit worrying. Something perhaps broke in 3.27?
<popey> sorry, 2.37 :)
<pedronis> Chipaca: the prepare-image PR is https://github.com/snapcore/snapd/pull/6483
<mup> PR #6483: image,cmd/snap:  simplify --classic-arch to --arch, expose prepare-image <Created by pedronis> <https://github.com/snapcore/snapd/pull/6483>
<ijohnson> hey sil2100, do you have a rough idea of when the arm64 ubuntu server image for raspi will be officially released? Thanks!
<sil2100> ijohnson: hey! It'll be out with the 18.04.2 point-release
<ijohnson> awesome, that's great news
<sil2100> ijohnson: just have in mind that we'll still be improving the experience, with an aim to have a really solid product (hopefully) with disco (19.04)
<sil2100> It's all a bit fresh here right now
<ijohnson> sil2100: ack, thanks for the explanation
<mborzecki> off to pick up the kids
<mup> PR snapd#6476 closed: cmd/snap: tweak man output to have no doubled up .TP lines <Simple ð> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6476>
<mup> PR snapcraft#2448 closed: Swap yaml schema document with json equivalent <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2448>
<diddledan> YEY
<pstolowski> mvo: doh.. https://pastebin.ubuntu.com/p/5bM7W4DQ96/
<mvo> pstolowski: oh, anything interessting on the serial console? I wonder why the read/connect failures
<pstolowski> mvo: nothing there, just login prompt
<mvo> pstolowski: if you ssh to the machine, does that still work?
<pstolowski> mvo: dammit.. my eth cable got loose :(
<pstolowski> that's why it had i/o errors
<mvo> pstolowski: heh - no worries, better that than something deeper
<pstolowski> indeed
<mvo> 6483 needs a second review (easy win)
<mvo> also 6481 (another easy win)
<pedronis> 6483 really needs Chipaca I think
<Chipaca> on it
<Chipaca> got sidetracked by some things in there
<Chipaca> but on it
<pedronis> it's fine
<pedronis> my point was more than I wouldn't land it before your input
<pedronis> I don't think is super urgent either
<Chipaca> pedronis: there
<pedronis> Chipaca: thanks,  you meant vertical space, when you wrote horizontal right?
<Chipaca> pedronis: maybe I had my laptop on its side
<pedronis> :)
<Chipaca> pedronis: yeah
<oneguynick> is there any reason after a snapcraft key creation that it would periodically work? snapcraft list-keys shows it and i can see its active, but executing the snap sign states no key
<Chipaca> pedronis: fwiw image already pulls in i18n ( image -> store  -> i18n, as well as via strutil and timeutil)
<Chipaca> oneguynick: snapcraft key, or snap key?
<oneguynick> snapcraft list-keys
<pedronis> Chipaca: I'm sure it does, it used from cmd/snap anyway, my point is that package itself doesn't import/use it yet
<pedronis> for anything
<oneguynick> snap key doesnt appear to be a valid command
<Chipaca> pedronis: k
<pedronis> Chipaca: pushed btw if you want to look again
<Chipaca> oneguynick: but then you use 'snap sign'?
<oneguynick> cat box-model.json | sed s/%TIMESTAMP%/$TIMESTAMP/ | snap sign -k itbox > box.model
<oneguynick> this is the actual command being executed and failing
<Chipaca> pedronis: thank you
<oneguynick> output is this on the return
<oneguynick> error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key INSERTFAKEKEYINFOHERESINCEITSCUT_N_PASTE --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")
<Chipaca> oneguynick: but this only fails sometimes, you say?
<oneguynick> yeah i just ran it to build an imagine and it randomly functioned
<oneguynick> *image
<Chipaca> oneguynick: do you do the list-keys and the sign with the same user in the same vm / container / machine?
<oneguynick> yes both running as my user
<oneguynick> i only sudo for the ubuntu-image build
<Chipaca> oneguynick: snapcraft list-keys calls 'snap keys --json' (and then does some processing on it)
<oneguynick> snap keys --json shows the key
<oneguynick> snapcraft list-keys lists the same one (as expected it seems)
<Chipaca> oneguynick: 'snap sign' and 'snap keys' use the same logic to find keys
<Chipaca> oneguynick: the same codepath mostly (except one is listing, the other is searching by name)
<oneguynick> any idea why `snap keys` and `snapcraft list-keys` see the key, but not sign?
<Chipaca> oneguynick: so far my only hypothesis is that you're inadvertently using it in different contexts, somehow
<Chipaca> oneguynick: does it fail reliably?
<Chipaca> oneguynick: if so, check that user's ~/.snap/gnupg
<oneguynick> failed at least 10-15 runs recently
<oneguynick> `S.gpg-agent          S.gpg-agent.extra  openpgp-revocs.d   pubring.kbx   trustdb.gpg
<oneguynick> S.gpg-agent.browser  S.gpg-agent.ssh    private-keys-v1.d  pubring.kbx~
<oneguynick> contents are there and ownership correct
<mup> PR snapd#6481 closed: tests: run test snap as user in the smoke test <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6481>
<Chipaca> oneguynick: that's ~/.snap/gnupg ?
<oneguynick> yes
<Chipaca> oneguynick: can you prepend the snap sign with Â«strace -e '!select,pselect6,_newselect,clock_gettime' -f -D -vv -o /tmp/sign.traceÂ» and try again until it fails?
<oneguynick> looks like the gpg is failing on no such key
<ogra> is there any reason you sign your assertion that often ? (you typically only do that once)
<oneguynick> i am in the process of prototyping and rebuilding images
<mup> PR snapd#6483 closed: image,cmd/snap:  simplify --classic-arch to --arch, expose prepare-image <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6483>
<oneguynick> I went ahead and wiped out my keys and started again. Seems to be working better. No idea why
<oneguynick> thanks @Chipaca for your help
<Chipaca> oneguynick: I blame â¦ evil hackers from Serbia.
<mup> PR snapcraft#2464 opened: project_loader: use hardened flags by default <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2464>
<Chipaca> fallback blame in case that one is unacceptable: Our POP server was kidnapped by a weasel.
 * Chipaca stops playing with 'bofh'
<oneguynick> Ð¥Ð²Ð°Ð»Ð° Ð²Ð°Ð¼
#snappy 2019-02-08
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: did you get my messages yesterday?
<mvo> mborzecki: yes, interessting results
<mborzecki> mvo: even though just a few interfaces are connected, we compile bpf for every declared plug
<mvo> mborzecki: yeah, thta seems very wasteful
<mborzecki> mvo: w8, hm i got it wrong, it's compiling bpf for each app, and that snap has plenty of apps
<mborzecki> mvo: still, it's weird, looking at the log, we connect opengl, but still compile new profiles for apps that don't declare opengl
<mvo> mborzecki: oka
<pstolowski> mornings
<mborzecki> pstolowski: hey
<pstolowski> mvo: thanks for the review of hotplug pr!
<mvo> pstolowski: my pleasure
<Chipaca> moin all
<mvo> hey Chipaca - good morning
<pstolowski> mvo: addressed your comments re #6465 ; regarding open points (the Specification stuff), we agreed with pedronis that it will be addressed in a followup, so once you're happy about the resolution of your suggestions this PR can land
<mup> PR #6465: overlord/ifacestate: hotplug-add-slot handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
<mvo> pstolowski: cool, looking
<mvo> pstolowski: I added feedback to 6322 as well (not sure if you saw it)
<pedronis> Chipaca: hi, could double check my last changes to #6469
<mup> PR #6469: image,cmd/snap,tests: introduce support for modern prepare-image --snap <snap>[=<channel>] <Created by pedronis> <https://github.com/snapcore/snapd/pull/6469>
<pstolowski> mvo: yes i saw it, will get to it later today, thank you
<mvo> pstolowski: thanks, no rush
<mup> PR snapd#6465 closed: overlord/ifacestate: hotplug-add-slot handler <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6465>
<pstolowski> yay \o/
<pedronis> great!
 * pstolowski reading my master theis about selinux from 2008. real journey to the past ;)
<mvo> pstolowski: nice
<leinardi> kenvandine: hi Ken, not sure if my message was posted here yesterday because I had connection issues. Any news about building GTK 3.24 for GWE? https://forum.snapcraft.io/t/support-for-gtk-3-24/9782/6
<mup> PR snapd#6484 opened: debian: ensure leftover usr.lib.snapd.snap-confine is gone <Created by mvo5> <https://github.com/snapcore/snapd/pull/6484>
<pstolowski> mvo: review of #6478 would be great
<mup> PR #6478: overlord/ifacestate: tweak logic for generating unique slot names <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6478>
<mvo> pstolowski: have you merged master?
<mvo> xnox: I updated lp 1814141 - if you could double check the PR that would be great
<pstolowski> mvo yes
<mvo> ta
<pedronis> Chipaca: have you applied all feedback to #6034 or is it still wip ?
<mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<pstolowski> mvo: ty!
<Chipaca> pedronis: i think it's ready
<Chipaca> pedronis: "Specify extra snaps from store or local or optionally control the channel to track for a snap"
<Chipaca> pedronis: hmm
<pedronis> Chipaca: it was there before
<Chipaca> pedronis: i missed it before :-)
<pedronis> I mean, I didn't change it in this last commit
<Chipaca> yeah
<pedronis> I moved a bit out
<pedronis> but not changed it
<Chipaca> pedronis: thank you for the value-name change, makes things nicer
<pedronis> yea
<pedronis> Chipaca: about your other PR, I asked because loadStore seems still there ?
<Chipaca> pedronis: we can i18n that if you want, fwiw (would take  abit of coding similar to other things)
<Chipaca> i thought i'd changed that
 * Chipaca checks
<Chipaca> dang
<pedronis> Chipaca: anyway at least that help sentence for --snap should use the singular now
<pedronis> I think
<Chipaca> pedronis: sorry, will fix in a bit
<pedronis> Chipaca: np
<Chipaca> pedronis: maybe, Include this snap (optionally controling the channel it tracks); may be from store or local
<Chipaca> pedronis: but, I'd also say something about repeating it
<Chipaca> because the help doesn't
<Chipaca> I wish it did :-/
<Chipaca> the help sucks
<Chipaca> prepare-image-OPTIONS what
<pedronis> Chipaca: but you can control also the channel of a snap you are not including
<Chipaca> :-/
<pedronis> that is also already included
<Chipaca> yeah
<Chipaca> Have this snap track the given channel (default: latest/stable); if not present, include it from store or local file
<Chipaca> if not already included*?
<mborzecki> re
<pedronis> Chipaca: pushed something
<pedronis> a bit different
<Chipaca> pedronis: +1
<pedronis> Chipaca: yes, the prepare-image-OPTIONS is not beautiful
<pedronis> that's go-flags though, no?
<Chipaca> yes
<Chipaca> and, you'd think we could just set Usage to override that
<Chipaca> but https://github.com/jessevdk/go-flags/issues/264
<pedronis> heh (me has stopped making optimistic/navie assumption about that package long ago)
<Chipaca> yeah, no navy assumptions
<pedronis> naive :P
<Chipaca> no u
<mup> PR snapd#6406 closed: tests: enable debian sid as part of the main suite on travis <Created by sergiocazzolato> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6406>
<mup> PR snapd#6413 closed: packaging: import debian salsa packaging work, add sbuild test and use in spead <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6413>
<mvo> down to 39!
<pedronis> Chipaca: the description (future commit message) needs updating as well
<Chipaca> yep
<Chipaca> it's going to get squashed, but yes
<pedronis> Chipaca: also my two comments about the undo logic seems unanswered
<Chipaca> pedronis: i answered them in my head, does that count?
 * Chipaca looks at the pr again
<pedronis> Chipaca: .5 cookie
 * Chipaca could have second breakfast
<Chipaca> pedronis: actually, which two?
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/6034#discussion_r254207769 and https://github.com/snapcore/snapd/pull/6034#discussion_r254207844
<mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<Chipaca> pedronis: ah, phew
<Chipaca> pedronis: answered
<Chipaca> that wasn't undo, that was cleanup of do
<Chipaca> ;)
<mvo> mwhudson: the debian packaging of salsa is now part of our tree in packaging/debian-sid and we use that for automatic testing - juts fyi - so on the next merge you can hopefully just "git mv package/debian-sid debian" and then we are in sync and we can just cherry-pick/merge your changes back into our tree (and vice-versa)
<mup> PR snapd#6478 closed: overlord/ifacestate: tweak logic for generating unique slot names <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6478>
<pedronis> Chipaca: ah,  this:  TestDoLinkSnapFailureCleansUpAux
<Chipaca> pedronis: ye
<Chipaca> it's a bit chummy with the implementation in how it triggers the failure
<Chipaca> but i reckon it's good enough
<pstolowski> naming tweaks landed as well, and #5962 updated with master and ready for reviews. i'll prep followup with the simplification of spec
<mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<pedronis> Chipaca: +1 with 1 nitpick, it needs a 2nd review tough because I think it changed too much since zygmunt looked at it
<pedronis> (I dismissed already his review)
<Chipaca> pedronis: agreed
<Chipaca> pedronis: there's an obvious followup up to this with categories
<pedronis> Chipaca: btw,  do we really need the store bit in "store/aux" , other things under cache also come from the store already, no?
<Chipaca> pedronis: good point
<pedronis> we could s/aux/aux-info/ if it's clearer, not sure
<mup> PR snapd#6485 opened: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<mborzecki> mvo: ^^
<mborzecki> mvo: there are some numbers in the PR description
<Wimpress> Morning mvo. I have a font related query regarding snapd.
<Wimpress> It doesn't appear to be possible to user installed or user local fonts in classic snaps.
<mborzecki> Wimpress: only in classic snaps?
<Wimpress> For examples, if I install fonts in ~/.fonts, ~/.local/share/fonts or /usr/local/share fonts I am unable to use them in the code-insiders snap, which uses classic confinement.
<Wimpress> mborzecki: Right now, I'm only interested in a classic snaps.
<Chipaca> Wimpress: have you tried using them in a classic snap that doesn't use the desktopy parts?
<Wimpress> Chipaca: There are no desktop helpers in the code-insiders snap.
<Chipaca> ah
<mvo> mborzecki: nice, looking
<mvo> Wimpress: in classic confined snaps, that is slightly unexpected
<Wimpress> Glad you say that, because I thought so too.
<Wimpress> There is an upstream bug raised against VSCode. I am investigating.
<mvo> Wimpress: silly question, what do I need to do to reproduce?
<mvo> Wimpress: I have vscode, how to instlal a local font?
 * mvo feels like a real n00b
<Wimpress> Install a monospaced font to a user location, such as ~/.fonts or ~/.local/share/fonts and then be able to set that font in the VSCode font preferences.
<Chipaca> mvo: git clone https://go.googlesource.com/image
<Wimpress> `Ctrl+,` to open preferences.
<Chipaca> mvo: and copy the resulting image/font/gofont/Go-Mono*.ttf to ~/.fonts
<Chipaca> :-)
<mborzecki> Wimpress: trying that now
<kenvandine> leinardi: we're still working on that.  Once we figure out the gtk build failure in the build snap i'll give you a patch that adds it to  your snap
<kenvandine> leinardi: oSoMoN is looking into that now
<mborzecki> Wimpress: do you know if any other classic snaps are affected too? eg. atom maybe?
<Wimpress> I have checked any others, but I can.
<Wimpress> *haven't
<pstolowski> http://paste.ubuntu.com/p/SCRGVsgCnq/mvo: got external:ubuntu-core-18-arm-32:tests/core18/compat failure on pi3; will re-run manually ; have you seen it failing before? full log:
<Wimpress> The font being referenced in the upstream bug is this - https://github.com/tonsky/FiraCode/releases/download/1.206/FiraCode_1.206.zip
<pstolowski> mvo: http://paste.ubuntu.com/p/SCRGVsgCnq/
<mvo> pstolowski: yes, I think its the same as yesterday, i.e. there is a core installed in the state but not on disk because prepare/restore do crazy stuff
<Wimpress> I've also tried rebuiling font cahces using `fc-cache -f -v` and `/snap/core/current/bin/fc-cache-v6 -f -v` and `/snap/core/current/bin/fc-cache-v7 -f -v`
<mvo> Wimpress: this is slightly mysterious, so I ran: "snap run --shell vscode" and in there gnome-font-viewer and I see the go fonts there but I don't have them in vscode
<Wimpress> mvo, Install `code-insider` instead. It is published by Microsoft.
<Wimpress> But yes, I am seeing the same issue.
<Chipaca> code-insiders*
<Wimpress> Although I using `mate-font-viewer` ;-)
<Wimpress> Yes, sorry.
<mvo> Wimpress: haha
<mvo> Wimpress: no worries
<Wimpress> Trying the atom snap.
<mvo> Wimpress: trying code-insiders now, *maybe* its related to the framework they use?
<mvo> Wimpress: I will try to run it outside of snap, just from local dir next
<Wimpress> Does fc-cache-v7 and fc-cache-v6 run in the root context when a snap is installed.
<Chipaca> yeah, fc-list works fine inside the snap
<mvo> Wimpress: fwiw, they really should consider using ubuntu mono as their defualt font
<mvo> Wimpress: yes
<Wimpress> Chipaca: You ran that from within the Code terminal, right?
<mvo> Wimpress: it runs as root but that should not matter, its just a cache
<Chipaca> um
<Chipaca> it picks up the font just fine
<Wimpress> Running `fc-list | grep Fira` from within the Code terminal does show me the user installed fonts from ~/.fonts
<mvo> Wimpress: also running vscode without confinement (just ./bin/electron-launch ...) gives me the same result so it looks like its not our fault(tm) :)
<Wimpress> Chipaca: So, if you change the Editor: Font Family in Code, you can see any open files rendered using that font?
<Chipaca> Wimpress: https://i.imgur.com/N333CRv.png
<Wimpress> Chipaca: Please can you confim the Fira Code font also works for you?
<Wimpress> I'll try the Go font you suggested here.
<Chipaca> Wimpress: I don't have Fira
<Chipaca> isn't that the one with all the funky ligatures?
<tomwardill> I use the vscode snap with Fira, if that helps
<Chipaca> Wimpress: does Fira Code work on 16.04?
<Wimpress> tomwardill: Where did you install the Fira font?
<tomwardill> sec, checking
<Wimpress> Chipaca: I can't get the Go font to render.
<Chipaca> Wimpress: what are you putting in settings?
<Wimpress> ...in the code-insiders snap.
<Wimpress> `'Go', 'Droid Sans Mono', 'monospace', 'Droid Sans Fallback'`
<Chipaca> Wimpress: the font is called Go Mono
<tomwardill> Wimpress: I have it install via the apt package
<Wimpress> tomwardill: OK, thanks. system wide fonts are working fine.
<Wimpress> The issue here user installed fonts in ~/.fonts for example.
<tomwardill> ah, sorry, missed that context in scrollback
<Wimpress> np :-)
<Chipaca> Wimpress: https://imgur.com/a/Rz26nPz
<Chipaca> Wimpress: fira code works
<Chipaca> using the fonts-firacode deb package from bionic
<Chipaca> Wimpress: I'm on 16.04
<Chipaca> ah
<Chipaca> oh
<mvo> Chipaca: aha, using the deb
<Wimpress> I am on 18.10
<Chipaca> removing the deb, moving the fonts to local dir, 1 sec
 * mvo also tested on 18.10
<Wimpress> Ah, you have the deb.
<mvo> Chipaca: aha, ok
<Chipaca> mvo: Wimpress: removed the deb, downloaded the .ttf and put them in .fonts, it works
<Wimpress> Works on 16.04?
<Chipaca> yes
<zyga> hey
<Chipaca> Wimpress: what do you have in your fonts dir?
<Chipaca> Wimpress: and, what are you putting in settings
 * zyga pops in briefly for the last day of his "holiday" break
<Chipaca> zyga: shoo go coo at a baby
<zyga> mvo: I will send the patches that you requested in a moment
<zyga> Chipaca: the baby is still at the hospital, not coming home yet, still sick :(
<Chipaca> zyga: :'(
<zyga> Chipaca: not serious but must stay for a few more days
<Wimpress> https://www.irccloud.com/pastebin/xysZGLIn/
<zyga> how are fires this week?
<Wimpress> Those are the fonts I have in ~/.fonts
<mvo> zyga: ta
<zyga> mwhudson: thank you for the debian upload, I was going to make one but I'm super happy to see it's done :)
<mvo> zyga: good luck
<Chipaca> Wimpress: yep, got those also
<mvo> zyga: packaging is merged
<mvo> :)
<Chipaca> Wimpress: and in your settings?
<Wimpress> Chipaca: I will test on a 16.04 VM
<Wimpress> `'Fira Code', 'Droid Sans Mono', 'monospace', 'Droid Sans Fallback'`
<Chipaca> Wimpress: and if you put just: Fira Code
<Chipaca> Wimpress: no quotes, no list, no nuthin'
<Chipaca> (that's what i have)
<Wimpress> It is not Fira Code rendering the test I do that.
<Wimpress> Looks like Courier.
<Chipaca> yeah it's very obvious when it's not finding it
<Chipaca> it uses a proportional font, even, at least here
<Chipaca> (but i probably don't have courier new)
<Chipaca> Wimpress: I'll try on 18.04 here and report back
<Wimpress> Chipaca: thanks. I'll give 16.04 a go.
<Chipaca> Wimpress: works on 18.04 as well
<Chipaca> Wimpress: with both Go Mono and Fira Code
<Chipaca> Wimpress: ligatures and all
<Wimpress> mvo, noted. I'll feed that back.
<Wimpress> regarding  using ubuntu mono as a default.
<mvo> Wimpress: ta
<mvo> Wimpress, Chipaca interessting - works for me on 18.04 as well
<Wimpress> Chipaca: popey confirms Fira Code in working on 18.04 with the code-insiders snap.
<mvo> I tested with the go fonts and vscode snap
<diddledan> broken in 18.10 for me
<popey> https://usercontent.irccloud-cdn.com/file/GGM2tbAk/Bootiful%20font%20on%2018.04
<mvo> yeah, same here, no fun on 18.10
<diddledan> I figured I had configured it wrong all this time >.<
<Wimpress> Thanks for the confirmations.
<popey> i just booted an 18.10 vm...
<diddledan> fc-list from within the code inbuilt shell (ctrl+`) doesn't show the font I've configured
<popey> but i appear to have picked the wrong vm
<popey> https://usercontent.irccloud-cdn.com/file/n1NdD344/does%20this%20support%20snaps%20%3B)%20
<diddledan> from within the inbuilt vscode shell (ctrl+`) https://www.irccloud.com/pastebin/PNe8FQgQ/
<diddledan> oh, I lie, it is there.. just intermixed with all the others even though it is in my locala fonts dir
<diddledan> fura code regular
<diddledan> could it be, in my case, that I'm using an otf font?
<Wimpress> diddledan: I only have "installed" the ttf version oof Fira Code in ~/.fonts
<diddledan> aah ok
<diddledan> I'm using the repacked fira code by nerd fonts
<diddledan> added DejaVu Sans Mono as a fallback when it can't find fura code regular and it looks sooo much better :-p
<diddledan> I think it uses a bitmap font when none of the ones in the list are found
<diddledan> ugly jaggies
<popey> Ok, font looks bad on 18.10
<popey> https://usercontent.irccloud-cdn.com/file/CS7igM08/Screenshot%20from%202019-02-08%2012-15-14.png
<popey> choosing ubuntu mono works fine
<diddledan> yours is decidedly more pretty https://usercontent.irccloud-cdn.com/file/IunzHJTb/image.png
<diddledan> I miss hidpi when I'm on this desktop :-(
<ogra> just move the monitors 2m away
<Chipaca> Wimpress: so
<Chipaca> Wimpress: I can confirm it's not finding the font in 18.10
<Chipaca> Wimpress: but
<Chipaca> Wimpress: putting the full path to the font works
<Wimpress> Whhhhaaaaat?!
<Chipaca> Wimpress: dude try it :-)
<Wimpress> Full path to a ttf?
<Chipaca> yes
<Chipaca> Wimpress: what was another snap that didn't find local fonts in 18.10?
<Wimpress> I can't confirm your workaround.
<Chipaca> Wimpress: why?
<Wimpress> `/home/martin/.fonts/FiraCode-Regular.ttf, 'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback'`
<Wimpress> Does not render using Fira.
<Chipaca> Wimpress: just the path, nothing more
<Chipaca> I have no idea what the rules are for quoting and enumerating in that text entry
<popey> "nothing more"? that *is* the path
<Chipaca> booting the cd up again just in case
<Wimpress> WHat is your font settting?
<Chipaca> popey: all the things after the comma, remove them
<popey> those are the defaults that vscode supports
<Chipaca> doing this in a vm all over again is very slow
<Wimpress> Atom also has the same issue
<Chipaca> booting with kvm, putting just /home/ubuntu/.fonts/FiraCode-Medium.ttf
<Chipaca> it picks it up
<Chipaca> doesn't get ligatures
<Chipaca> in code
<Chipaca> I can try atom next if you want?
<popey> specifying the full path to the font on 18.10 does not work here
<popey> it defaults back to a variable width font
<Wimpress> Just tested with pycharm-community snap. Also classic but implemented using Java, not Electron.
<Wimpress> I can set the editor font to Fira Code on 18.10 just fine.
 * pstolowski lunch
<kravietz> Hello, maybe a silly question - how do I run snapcraft 3 on a VM? It requires multipass but multipass won't run on a VM and all of my build servers run in cloud...
<mup> PR snapd#6469 closed: image,cmd/snap,tests: introduce support for modern prepare-image --snap <snap>[=<channel>] <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6469>
<pedronis> sil2100: ^ https://forum.snapcraft.io/t/evolving-prepare-image-syntax/5988/4 what was mentioned on Tue
<sil2100> pedronis: excellent
<sil2100> I'll pick that up for ubuntu-image, possibly next week
<pedronis> thank you
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98
<dot-tobias> Does someone have experience with network-manager / nmcli calls from a core18 base'd snap? I'm really lost as to what I might be doing wrong â¦ https://forum.snapcraft.io/t/apparmor-denials-for-dbus-objectmanager-network-manager/9885
<ondra> sergiusens is there easy way to tell snapcraft which multipass instance to use for build?
<sergiusens> Wimpress: I followed your instructions for the font with code-insiders on disco and it wasn't picked up
<sergiusens> ondra: what do you mean?
<ondra> sergiusens correct me if I'm wrong, but snapcraft will try to run clean build by creating new multipass instance?
<ondra> sergiusens or is it more instance per-project?
<ondra> sergiusens so is there option instead to tell it to use existing instance I already have?
<sergiusens> ondra: it is, per project
<ondra> sergiusens ah cool, and can I tell it to use specific one?
<sergiusens> ondra: it is simple today, by name, "snapcraft-<snap-name>", but if you do manual things, it could get icky with some things done using cloud-init
<ondra> sergiusens ah OK, so better to map dir and build inside instance directly
<sergiusens> when we have support of some form of "project" from multipass, we will lock it down more
<sergiusens> yes
<ondra> sergiusens cool
<leinardi> kenvandine: cool, thanks a lot
<kenvandine> leinardi: np
<roadmr> jdstrand: hi :)
<mup> PR snapd#6484 closed: debian: ensure leftover usr.lib.snapd.snap-confine is gone <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6484>
<pedronis> mvo: did a first pass on the 1st Remodel PR
<mup> PR snapd#6486 opened: interfaces/hotplug: renamed RequestedSlotSpec to ProposedSlot, removed Specification <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6486>
<mvo> pedronis: thank you
<pedronis> mvo: what's the status of the discussion about where to do things in snapd vs snap-confine, in https://github.com/snapcore/snapd/pull/6418?
<mup> PR #6418: many: allow core as a fallback for core16  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<mvo> pedronis: impas it seems, I would prefer snap-confine.c as we already to something similar there - unless I miss something?
<pedronis> mvo: do we know where in snapd would we do this?
<mvo> pedronis: in cmd_run.go I think
<pedronis> or is that snap-exec or snap run?
<mvo> pedronis: snap run
<mvo> pedronis: I can explore this and push a passtebin with the required work
<pedronis> mvo: just remember my point, we don't want base: core16 not to pivot
<pedronis> it will hide bugs that will hunt us later
<mvo> pedronis: aha, I see
<pedronis> so from that point view no base, base: core16 are not quite the seem
<pedronis> it feels right
<pedronis> but caveats
<mvo> pedronis: yeah, if we do it in snap run this will be less clear
<pedronis> mvo: yes, we cannot turn base: core16 into no base
<pedronis> and be done
<mvo> pedronis: right
<mup> PR snapd#6487 opened: interfaces: add new intel-management-interface interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/6487>
<pstolowski> mvo: i'm going to run "console-conf core16 fresh install pi3", ok?
<mvo> pstolowski: yes, thank you!
<pstolowski> mvo: for console-conf, i need to first configure device manually, then run the tests (and presumably they re-run the setup)?
<mvo> pstolowski: actually I don't know, I think its explained in the README.md, at least I did run this successfully once
<mvo> pstolowski: if you don't figure it out I can look after dinner
<pstolowski> mvo: hmm, it tries to ssh to the given IP, which won't work until pi3 is configured (with my email address). i'm running "DEVICE_USER=stolowski DEVICE_IP=192.168.1.56 scripts/run_external_device.sh dev_cconf_pi3"
<pstolowski> mvo: i'll get back to this on monday, have a nice weekend!
<pedronis> have a great weekend!
<mvo> pstolowski|afk: yeah, sounds reasonable - have a great weekend too
<mup> PR snapcraft#2465 opened: tests: make before/after items an array in schema test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2465>
#snappy 2019-02-09
<FrogCast> Hey is there a snapcraft plugin for qbs or qtcreator?
#snappy 2019-02-10
<mup> PR snapcraft#2466 opened: ruby plugin: support new download URL <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2466>
<mup> PR snapcraft#2465 closed: tests: make before/after items an array in schema test <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2465>
#snappy 2020-02-03
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: in the context of https://forum.snapcraft.io/t/apps-not-in-desktop-search-menu/15275 do you recall why we didn't add a user env generator?
<mvo> mborzecki: hm, I thought we had a generator
<mborzecki> mvo: we have a system-env generator
<mvo> mborzecki: indeed, I think there is no reason then
<mvo> mborzecki: maybe it was because older systemds do not support this yet?
<mborzecki> mvo: mhm, i'll add one and we can ship it selectively if needed
<mvo> mborzecki: +1
<zyga> Hello :-)
<mborzecki> zyga: hey
<mvo> hey zyga
<mborzecki> zyga: do you still have that opensuse vm? https://forum.snapcraft.io/t/error-while-loading-shared-libraries-on-opensuse-tumbleweed/15285
<mup> PR snapd#8073 closed: daemon: drop support for the DELETE method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8073>
<zyga> mborzecki: sure
 * zyga is in the office now
<zyga> weird
<zyga> I'll try
<zyga> mborzecki: offtopic, stuff from weekend: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1095r0.pdf
<zyga> mvo: have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1861648
<mup> Bug #1861648: When booting 20.04 an 'ld-2.23.so' process consumes 100% CPU for minutes <champagne> <focal> <performance> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1861648>
<zyga> mvo: could that be fontconfg?
<zyga>  (or related?)
<pstolowski> morning
<zyga> hey pawel, welcome back
<mborzecki> pstolowski: hey, all rested?
<mvo> zyga: it could be, slightly strange but possible
<mvo> pstolowski: hey, welcome back! we missed you :)
<mvo> pstolowski: (in a good way)
<mborzecki> `error: too early for operation, device not yet seeded or device model not acknowledged` wonder if we could prouce something more friendly instead of this error message
<zyga> mborzecki: oh yeah
<zyga> I saw that a few times
<zyga> and it's very precise and very useless
<mborzecki> zyga: annoying when it happens on `snap install` right after you installed the snapd package
<zyga> yeah, I wonder if snap <foo> from command line could block and hold while stuff like that happens
<zyga> but that's a separate concern from just making a readable message
<zyga> like "snapd is performing first-boot setup process, please wait (10%)"
<zyga> mborzecki: updating suse (882 updates over weekend)
<zyga> mborzecki: I'll try those snaps in a moment
<pstolowski> hey guys! yep, rested, i had great time with my family; i only wish there was more snow
<zyga> pstolowski: I think you had more snow than the rest of poland :)
<zyga> but yeah, I wish this winter was better
<zyga>  mborzecki wow
<zyga> type=AVC msg=audit(1580717508.948:224): apparmor="DENIED" operation="mknod" profile="/usr/lib/snapd/snap-confine" name="/sys/fs/cgroup/devices/snap.poddr.poddr/cgroup.procs" pid=4155 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<zyga> type=AVC msg=audit(1580717508.948:225): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/sys/fs/cgroup/devices/snap.poddr.poddr/cgroup.procs" pid=4155 comm="snap-confine" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
<pstolowski> zyga: yeah.. but temperatures revolving around 0C (only) were not expected
<zyga> mborzecki: we have ... denials?
<zyga> ah. wait, maybe I have two profiles
<zyga> one left over from work
<zyga> sigh
<zyga> mborzecki: replied there, I think leap may be broken, TW is okay
<zyga> I need a 2nd +1 for 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> I'd like to merge it before it drifts
<pstolowski> mvo: how was last week? anything remarkable?
<pstolowski> pedronis: morning!
<pedronis> pstolowski: hi
<mborzecki> it'd be so nice if systemd manpages indicated whic version of systemd given feature first appeared in
<pedronis> pstolowski: I will look at the preseed PRs later today, I fixed some conflicts on the first on Friday.
<pedronis> pstolowski: maybe you could finish reviewing #8036 ?
<mup> PR #8036: snapstate: refactor things to add the re-refresh task last <Created by pedronis> <https://github.com/snapcore/snapd/pull/8036>
<pstolowski> pedronis: sure. and thanks for updating preseed PR
<mborzecki> hmm, so we have /lib/environment.d and /etc/profile/snapd.sh but environment for zsh user is still not getting updated
<pedronis> mborzecki: hi, I can do a follow up about that name, if there's a preference
<mborzecki> pedronis: nah, it's ok, not worth another spread run
<mborzecki> zyga: do you recall whether it's possible to start a user session in the tests somehow?
<zyga> re
<zyga> mborzecki: I think it is
<zyga> mborzecki: I've done something -ish- like that
<zyga> mborzecki: well, I didn't start a full user session but I did start a dbus session bus
<zyga> mborzecki: what I found out is that some PAM / distro / i-dont-know-what settings do start a user session for the test user
<zyga> mborzecki: because we observed that it runs stuff and shuts down asynchronously
<mborzecki> quick errand, back in 30 or so
<zyga> lp timeouts
<zyga> oh well
<zyga> back to work
<pedronis> pstolowski: thanks
<mup> PR snapd#8036 closed: snapstate: refactor things to add the re-refresh task last <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8036>
<mvo> pstolowski: last week was interesting, 2.43 a wee bit delayed but hopefully just 1 week
<pstolowski> mvo: uhm, just browsed last-week standup notes (they are very useful to catch up btw!)
<mvo> pstolowski: yeah, when at the sprint I had the same feeling, very useful
<mup> PR snapd#8080 opened: dirs: manjaro-arm is like manjaro <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8080>
<zyga> mvo: in case 2.43.x will happen ^
<mvo> zyga: thank you
<mborzecki> re
 * zyga goes offline for 2-3 hours
<mup> PR snapd#8081 opened: tests/main/user-session-env: add test verifying environment variables inside the user session <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8081>
<mborzecki> simple test ^^
<mborzecki> still, something is off with zsh as indicated in https://bugs.launchpad.net/ubuntu/+source/zsh/+bug/1640514
<mup> Bug #1640514: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Invalid> <snapd (Ubuntu
<mup> Xenial):Confirmed> <zsh (Ubuntu Xenial):Invalid> <snapd (Ubuntu Bionic):Fix Released> <zsh (Ubuntu Bionic):Invalid> <https://launchpad.net/bugs/1640514>
<mborzecki> zyga: little tweak in #8080
<mborzecki> cachio: hey, welcome back!
<mup> PR #8080: dirs: manjaro-arm is like manjaro <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8080>
<cachio> mborzecki, heu, thanks
<cachio> mborzecki, trying to start again :)
<pstolowski> cachio: hi! have you seen my earlier email re nested vm, and comments under #8046 ?
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<cachio> pstolowski, no yet
<cachio> pstolowski, hello :)
<pstolowski> cachio: ah, you were on vacation as well!
<cachio> pstolowski, yes :)
<cachio> caching up emails, logs and other stuff yet
<cachio> pstolowski, I'll take a look to the PR
<cachio> today for sure
<pstolowski> cachio: i'll deconflict it in a moment
<mup> PR snapd#8082 opened: data, packaging: Add sudoers snippet to allow snaps to be run with sudo <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/8082>
<mvo> cachio: hey, welcome back!
<cachio> mvo
<cachio> hello
<mup> PR snapd#8033 closed: tests: switch mount-ns test to differential data set <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8033>
<cachio> mvo, reading logs for 43.2
<cachio> mvo, is .1 going to stable? or we should go with .2?
<mvo> cachio: we will need .2 instead, it's already in beta
<mvo> cachio: so once beta validation is done it can go into candidate
<mvo> cachio: and then we can release to stable in 1 week
<cachio> mvo, ok
<cachio> mvo, i'll continue with the beta validation in that case
<zyga> mborzecki: thank you!
<zyga> cachio: welcome back :)
<mvo> cachio: thank you!
<cachio> zyga, hi
<Eighth_Doctor> blergh
 * Eighth_Doctor waves
<Eighth_Doctor> it's been a while since I've had to send a patch snapd upstream :P
<Eighth_Doctor> mvo: it's been a while :)
<Eighth_Doctor> mvo, zyga: by the way, I'm surprised you guys haven't reaped the Ubuntu 14.04 packaging from git
<zyga> Eighth_Doctor: it's still supported
<Eighth_Doctor> don't tell me you guys are still building for Ubuntu 14.04?!
<zyga> Eighth_Doctor: have you heard of ESM?
<zyga> Eighth_Doctor: we may have to
<Eighth_Doctor> blergh
<zyga> https://ubuntu.com/esm
<Eighth_Doctor> somebody better giving you a huge bag of money for that
<zyga> "Security updates for 14.04 LTS until 2022"
<Eighth_Doctor> ugh
<zyga> Eighth_Doctor: it's free for personal use
<Eighth_Doctor> I can see that, and that deeply concerns me :(
<zyga> why?
<Eighth_Doctor> disincentive for upgrading
<zyga> Eighth_Doctor: it's enterprise stuff
<zyga> you can upgrade when you are ready
<zyga> Eighth_Doctor: I'm sure that using ESM and paying for it
<Eighth_Doctor> yeah, yeah
<zyga> Eighth_Doctor: versus using the update for free
<zyga> Eighth_Doctor: is a good incentive
<zyga> plus, it keeps developers employed :)
<Eighth_Doctor> heh, sure
<Eighth_Doctor> the only difference between RH/SUSE and this model is that there's a "the first hit is free" thing like Oracle does...
<Eighth_Doctor> I just think it probably introduces a stronger disincentive when it's possible to get it for free
<Eighth_Doctor> zyga: I don't have a problem with the ESM thing, just the fact it is available for free for personal use
<zyga> ah
<zyga> well
<zyga> you can always pay :)
<zyga> you get cool stuff
<Eighth_Doctor> haha
<Eighth_Doctor> I don't have bags of money
<zyga> like kernel live patch
<zyga> it's not expensive
<Eighth_Doctor> the livepatch stuff is interesting though
<ogra> and you get a discount because you met zyga in person ;)
 * Eighth_Doctor still has his legacy KSplice free subscription for Fedora
<Eighth_Doctor> haha
<Eighth_Doctor> sadly, I know how the sausage is made for kernel livepatches
<ogra> shhhh
<Eighth_Doctor> I try very hard to avoid them if I can ;)
 * Eighth_Doctor was once asked to make kernel livepatches using kpatch
<Eighth_Doctor> zyga: if I could afford to, I'd buy subs from all my favorite Linux distro companies :)
<zyga> Eighth_Doctor: if you want to support, $25 gives you desktop ESM license
<Eighth_Doctor> nice
<zyga> you get fips, livepatch, some other fancy acronyms
<Eighth_Doctor> I'll consider it
<zyga> probably desirable in corporate world
<zyga> for somewhat more you get phone support
<zyga> prices for servers and vms are different though
<zyga> but yeah
<zyga> you can just use it for free because it's pretty damn cool :)
<zyga> and it's meant to be adopted by personal users
<zyga> because that makes everyone safer
<Eighth_Doctor> fair
<Eighth_Doctor> zyga: if you guys offered Fedora support... :P
<zyga> Eighth_Doctor: you can run it in a container :)
<Eighth_Doctor> hah
<Eighth_Doctor> I don't think I've run Ubuntu as my desktop OS since 2012
<zyga> Eighth_Doctor: but I think if you want to start supporting fedora IBM will look at you with The Eye
<Eighth_Doctor> actually, they're super weird about this
<zyga> Eighth_Doctor: I heard 20.04 is looking like a sweet system :)
<Eighth_Doctor> they want more people to commercially support Fedora
<pedronis> pstolowski: answered your question in 7590
<pstolowski> thx
<Eighth_Doctor> but some folks give you the stink-eye when you do it for CentOS
<zyga> Eighth_Doctor: are you ubuntu community member? you can get it on up to 50 machines for $0
<Eighth_Doctor> what does that mean?
<zyga> Eighth_Doctor: the fedora/centos/rhel split is still making me dizzy
<Eighth_Doctor> I have an Ubuntu account on LP
<Eighth_Doctor> zyga: it's going to get less confusing in the near future
<zyga> Eighth_Doctor: fedora/rhel would be better, if you had a way to get no-cost unsupported rhel
<zyga> abyway
 * zyga needs to focus
<Eighth_Doctor> fedora -> centos -> rhel
<zyga> fedora -> rhel -> centos?
<zyga> or more like
<Eighth_Doctor> going forward, fedora will branch into centos, and centos will branch into rhel
<zyga> fedora <-> rhel <-> centos <- to fedora ->
<Eighth_Doctor> that's starting with CentOS 8
<Eighth_Doctor> with the CentOS Stream
<Eighth_Doctor> which is essentially what RHers will tell you is rhel-rawhide
<Eighth_Doctor> so Fedora is where the cool shit happens, CentOS Stream is where it stabilizes, RHEL/CentOS Linux is the end state
<Eighth_Doctor> over the next ~6 months, the RHEL development process is being flipped public as part of the CentOS Stream infrastructure bringup
<Eighth_Doctor> zyga: on another note, looking at my LP account, I created it shortly after Ubuntu 5.10 (breezy badger) released
<pstolowski> pedronis: right, ty, i forgot it's for core
<Eighth_Doctor> zyga: it actually predates my FAS account and my openSUSE account by two years ;)
<Eighth_Doctor> https://launchpad.net/~ngompa13
<mborzecki> cachio: can you take a look whther centos-8 is avaialble in gcp already?
<cachio> mborzecki, sure, let me check
<mborzecki> ijohnson: hi, already around? :P
<cachio> mborzecki, it is available now
<mborzecki> cachio: great, would it be possible for you to add it to the project then?
<cachio> do you weant a pr to enable it ??
<cachio> mborzecki, sure
<mborzecki> cachio: i can open a PR once you tell me the image name
 * pstolowski lunch
<cachio> mborzecki, try with centos-8
<mborzecki> cachio: thx
<cachio> mborzecki, but I would need to add it to our pool
<cachio> mborzecki, but in the meantime you can use that one
<mborzecki> cachio: yay, it works             - centos-7-64:
<mborzecki>                 workers: 4
<mborzecki>                 image: centos-7-64
<mborzecki> PRETTY_NAME="CentOS Linux 8 (Core)"
<cachio> mborzecki, centos 7?
<mborzecki> cachio: nah, wrong paste ;)
<mborzecki> cachio: see the PRETTY_PRINT=.. line
<cachio> mborzecki, which is this PRETTY_NAME ?
<cachio> mborzecki, where do you see it?
<mborzecki> cachio: PRETTY_NAME="CentOS Linux 8 (Core)" <--
<mup> PR snapd#8083 opened: spread: add CentOS 8 <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
<cachio> mborzecki, does not work for us that version?
<ijohnson> mborzecki: not quite yet :-)
<cachio> mborzecki, well you said that works
<mborzecki> cachio: i was able to boot a node, so a good sign (?), let's how spread tests will fare
<mborzecki> ijohnson: haha, sure will poke you in a bit
<cachio> mborzecki, nice, the only change we are doing to centos is to set selinux as permissive
<mup> PR snapcraft#2893 closed: [legacy] meta: include environment in hook wrappers <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2893>
<ijohnson> morning folks
<mup> PR snapd#8084 opened: many,randutil: centralize and streamline our random value generation <Created by pedronis> <https://github.com/snapcore/snapd/pull/8084>
<pstolowski> hey ijohnson !
<ijohnson> hey pstolowski did you have a good vacation ?
<pstolowski> ijohnson: yep, thanks for asking!
<ijohnson> nice, I saw your picture of the mountains with the snow, very beautiful :-) it actually got really warm here over the weekend and a bunch of our snow melted
<pstolowski> ijohnson: https://drive.google.com/file/d/1g9I2qGgGfpgYCyLWCHbrXlVzRnrRR_tN/view?usp=sharing
<pstolowski> zyga,mborzecki ^ morskie oko :)
<zyga> mmm
<zyga> I want holidays with snow
<ijohnson> pstolowski: awesome, I'm jealous we don't have mountains nearby me :-)
<Eighth_Doctor> mvo, mborzecki: I think this is officially a sign that snapd has too many tests
<Eighth_Doctor> when the tests fail because it takes too long to run (!)
<mvo> Eighth_Doctor: in a meeting right now, sorry, will get back to you
<mborzecki> Eighth_Doctor: hmm probably snap downloads taking too long
<mborzecki> happens from time to time
<ogra> stgraber, so i tried to build a preseeded image with lxd ... which seems to work fine but then console-conf doesnt allow me to add a default user to the core image at all anymore, seems lxd created a user that console-conf now considers the images system user ... https://imgur.com/a/fqu7xrS
<ogra> stgraber, how did you test your daemon.preseed change ?  i cant really verify it that way ...
<ogra> (this is most likely a console-conf bug, to not ignore such users (i bet docker is the same here) i'm just wondering how you verified the poatch without being able to log into the image)
<ogra> *patch
<cachio> mborzecki, do you need permisive mode on centos-8?
<mborzecki> cachio: yes, we'll probably need it because most tests are not taking care of the labeling properly
<cachio> mb
<cachio> mborzecki, ok
<ogra> pedronis, see above .. if i add lxd to required-snaps in the model (which creates an lxd user in the extrausers db), console-conf doesnt offer me to create a default user ... i assume snapd now considers the image managed, yet it isnt ... would that be a snapd bug, a console-conf one or ... ?
 * ogra isnt sure if console-conf queries for "managed" here 
<ogra> (or if that is even the right conclusion)
<zyga> I figured out why mi microphone was not working
<zyga> I was playing with the wireless headphone charging case
<zyga> and flipping it open pairs the devices
<zyga> so I kept switching the microphone back and forth
<zyga> and that apparently confused hangouts
<mborzecki> hangouts gets confused quite easily
<roadmr> it's so confused it isn't even called hangouts anymore ð
 * zyga goes to check on his son
<zyga> Janek has fever and stayed at home today
<roadmr> zyga: my sympathies and a bowl of warm soup - fever sucks
<zyga> yeah, we just gave him some meds to reduce the fever as it's been too long (since 6AM)
<mup> PR snapd#8085 opened: [RFC] netutil: add default gateway monitor <Created by mvo5> <https://github.com/snapcore/snapd/pull/8085>
<zyga> mvo: looking
<mborzecki> ijohnson: 8082 hit the timeout again?
<ijohnson> mborzecki: uh yes
<ijohnson> did you already restart it before ?
<mborzecki> ijohnson: yeah :/
<ijohnson> I've got a bad feeling about this :-(
<mborzecki> ijohnson: let's see, maybe 3rd time's the charm :P
<zyga> mvo: reviewed
<ijohnson> mborzecki: fingers crossed
<cachio> mborzecki, centos-8 is failing to install yum install system-lsb-core
<cachio> mborzecki, perhaps we could install redhat-lsb-core instead
<zyga> mvo: do you have an LTE modem?
<zyga> mvo: I think it would be great to test it on one
<zyga> mvo: if you need I can test it locally with mine
 * cachio lunch
<mvo> zyga: I have one, haven't used it in a while, can do the test in a wee bit
<zyga> back from lunch
<zyga> mvo: cool, let me know if you want assistance, I can help as well
<mup> PR snapd#8072 closed: daemon, store: better expose single action errors <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8072>
<ijohnson> mmm I've got a really bad feeling about these tests that depend on the store
<zyga> ijohnson: <chewie roar>
<ijohnson> :-)
 * zyga takes a coffee break
<ijohnson> anybody have an idea why all of a sudden LP jobs can't git clone snapd ? https://pastebin.ubuntu.com/p/CDJG8DVyPV/
<ijohnson> hmm I guess I can't clone the master branch in LP either
<cjwatson> yes git.launchpad.net is down, see #is
<cjwatson> ijohnson: ^-
<ijohnson> cjwatson: ah thanks
<cjwatson> (BTW I only see stuff here by chance - if you want LP staff to see stuff it's more reliable to ask in LP channels)
<ijohnson> cjwatson: I checked is-outage and didn't see anything about it in the topic, perhaps #is is a better place to check
<cjwatson> #is-outage isn't a place where customers of IS are supposed to report things, normally
<cjwatson> so I don't :)
<ijohnson> cjwatson: fair enough :-) also did you mean the internal launchpad channel or freenode one?
<cjwatson> Either
<cjwatson> #launchpad-ops on irc.c.c, #launchpad on freenode
<cjwatson> Anyway, should be fixed soonish
<ijohnson> great, thanks
<mup> PR snapd#8082 closed: data, packaging: Add sudoers snippet to allow snaps to be run with sudo <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8082>
<pedronis> ijohnson: I did another pass on 8077
<ijohnson> pedronis: thanks responding now
<pedronis> ijohnson: I'm not sure whether revisions should error on incosistent trySnap vs status
<pedronis> in general we should try not to get stuck
<ijohnson> I guess it would be a question of where we would get stuck
<pedronis> ijohnson: if we are trying or try but there's no try kernel
<pedronis> I suppose we behave like status is just = ""
<pedronis> we should clean it up
<ijohnson> we would get stuck in InUse, and GetCurrentBoot it seems
<pedronis> yea
<pedronis> so no upgrades
<pedronis> we should probably not error
<ijohnson> I think cleaning up in GetCurrentBoot makes sense, but not so sure about InUse, seems odd if InUse auto-cleans things
<pedronis> but make it a task for mark successful
<pedronis> to clean it up
<pedronis> ijohnson: well we always do a mark sucessful pass
<pedronis> before doing other things
<pedronis> it's run early in snapd
<ijohnson> hmm
<ijohnson> that would make sense
<ijohnson> just to clarify, when you say "make it a task for mark successful" you don't mean an actual manager task right? just that mark successful should clean up ?
<pedronis> yes
<ijohnson> ok
<pedronis> I think it has code already in that direction
<pedronis> but in uc20
<pedronis> we have links and status
<pedronis> that are not quite in the same spot
<pedronis> maybe the code is already there
<pedronis> just a matter of having a test
<ijohnson> I'll have a look at that as well
<ijohnson> if you were curious I did go ahead and implement setting kernels in modeenv in bootstate20 quickly and this is the result: https://github.com/anonymouse64/snapd/commit/de7f8fe36cb83da51a400b05100dd37a1b19246f
<ijohnson> it would be quite a bit less changes to the tests if we did it in coreKernel, but it's up to you
<pedronis> that code seems to load modeenv twice for mark succeful?
<pedronis> it's also not dropping them
<ijohnson> pedronis: I don't think it's loading it twice
<pedronis> anyway is probably best to get 8077 in first
<ijohnson> pedronis: also yes that's my big question about when to drop them
<ijohnson> we don't want to drop them in markSuccessful
<pedronis> why not?
<pedronis> ah because of possible undos?
<ijohnson> because then the modeenv won't trust the kernel snap if we reboot?
<ijohnson> yes undos basically
<pedronis> but we never boot anything but the kernel or the try-kernel
<pedronis> by definition
<ijohnson> hmm I guess if we did an undo/revert then setNext() would still be called on the one we are reverting to
<pedronis> so I think it's less complicated than we think
<pedronis> but anyway we need to get 8077 right first
<ijohnson> mmm yes I think you're right I was thinking we would need to be able to rollback further than what is in kernel.efi, but that isn't necessary actually
<ijohnson> re 8077 yes I am refactoring that now
 * cachio afk
<sdhd-sascha> big, big thank you, to jhenstridge ... really great to build snap's on github now:
<sdhd-sascha> https://github.com/sd-hd/termite-snap/runs/423070604
<sdhd-sascha> Next, i hope we can "snap" some wayland-desktop ;-)
<pedronis> mmh, the shellcheck version we use in travis is slightly old and seems to get confused about grep --exlude
<ijohnson> do we not use shellcheck as a snap ?
<pedronis> no, seems we use a package
<mup> PR snapcraft#2901 closed: python plugin: do not leak snapcraft's site-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2901>
<sergiusens> ijohnson: fwiw, we have been using the snap for over a year
<ijohnson> sergiusens: nice yes that what I use on my dev machine is the snap, probably safe enough to switch spread over to use the snap
<pedronis> ijohnson: thanks for the changes, seem the suggestion made sense,  I made a couple more comments to maybe clean up some things a little bit more
<ijohnson> pedronis ok looking now
 * cachio eod
<pedronis> ijohnson: going to call it a day
<ijohnson> pedronis yes probably a good idea considering the time :-)
#snappy 2020-02-04
<mup> PR snapd#8086 opened: daemon: Allow clients to call /v2/logout via Polkit <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/8086>
<mborzecki> morning
<mborzecki> brb, new kernel
<mborzecki> and back
<zyga> Hey
<zyga> Janekâs fever got me
<zyga> Working but sick
<mborzecki> zyga: hey, maybe take some time off?
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> mvo: came up with this to trigger the failure in linking https://paste.ubuntu.com/p/MHYXNkvJzZ/ that could brick the device
<mvo> mborzecki: uh, woah
<mvo> mborzecki: this is where the generator will help?
<mborzecki> mvo: yes, the generator would ensure that the units are there and snapd.service is enabled
<mborzecki> mvo: can you cherry pick https://github.com/snapcore/snapd/pull/8082 to 2.43?
<mup> PR #8082: data, packaging: Add sudoers snippet to allow snaps to be run with sudo <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8082>
<pedronis> do we need a .3 ?
<mborzecki> quick errand at school, back in 30 or so
<mvo> pedronis: I hope not, did I miss something this morning that may require a .3
<mvo> mborzecki: will cherry pick it
<pedronis> mvo: I just wondered why mborzecki asked you to cherry pick
<pedronis> if there's no .3
<mvo> pedronis: I think just in case we do
<pedronis> ah
<mborzecki> re
<mup> PR snapd#8080 closed: dirs: manjaro-arm is like manjaro <Bug> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8080>
<mborzecki> pedronis: mvo: yes, just in case we do a .3
<mup> PR snapd#8087 opened: dirs: variable with distros using alternate snap mount <Created by zyga> <https://github.com/snapcore/snapd/pull/8087>
<pstolowski> pedronis: +2 on #8084 (but travis is unhappy)
<mup> PR #8084: many,randutil: centralize and streamline our random value generation <Created by pedronis> <https://github.com/snapcore/snapd/pull/8084>
<mborzecki> btw #7972 needs a 2nd review
<mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
<pedronis> pstolowski: yes, timeout on ubuntu tests :/
<pedronis> pstolowski: thx for the review
<pstolowski> yw
<mup> PR snapd#8086 closed: daemon: Allow clients to call /v2/logout via Polkit <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8086>
<kbroulik> Hi, I noticed the Telegram Snap reports an incorrect desktop file name in its BAMF_DESKTOP_FILE_HINT. The name it reports is telegram-desktop_telegramdesktop whereas the actual desktop file is telegram-desktop_telegram-desktop - is that a snap bug or an issue on Telegram's side? I recall snap building meddling with desktop file names?
<zyga> Lucy has fever too
<zyga> kbroulik: it could be split between the two, but I don't recall how we generate that line
<zyga> kbroulik: let me check
<pstolowski> i've just checked
<zyga> pstolowski: thanks!
<zyga> mvo: I may need to take today off, I also feel sick today :/
<zyga> (Janek, me and now Lucy too)
<zyga> mvo: gadget bugs don't have a launchpad presence, or do they?
<pstolowski> the exec line is 'Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/telegram-desktop_telegram-desktop.desktop /snap/bin/telegram-desktop -- %u'
<mvo> zyga: in a meeting, will get back to you
<zyga> ok
<pstolowski> and the file under /var/lib/snapd/desktop/applications is telegram-desktop_telegram-desktop.desktop
<pstolowski> ^ kbroulik
<pstolowski> kbroulik: so looks fine here. where are you seeing that wrong hint? also, what versions of snapd and telegram snap do you have?
<zyga> mvo: all good, no need
<kbroulik> pstolowski: oh, possibly the desktop file I have in my autostart is outdated then
<kbroulik> yup. my autostart desktop file is outdated/wrong
<kbroulik> that explains why I was randomly seeing this phenomenon, typically in the morning ;)
<kbroulik> when i start telegram manually it is correct. Oh well, sorry for the noise then
<mborzecki> kbroulik: it should be enough to have a symlink to /var/lib/snapd/desktop/telegram-desktop_telegra-desktop.desktop
<kbroulik> yeah, I was wondering that. However, the file also had a different name, so that wouldnt have helped
<kbroulik> it probably was telegram-desktop_telegramdesktop a few months ago
<mborzecki> right, there might have been some fixes for the autogenerated destop file naming
<pstolowski> kbroulik: great
<kbroulik> I'll see what we can do on the KDE side of things, maybe use a symlink and then show a "could not autostart all programs [configure autostart]" so we fail gracefully rather than silently starting an ever-so-slightly broken version
<mup> PR snapd#8088 opened: tests/lib/prepare-restore: Revert "Continue on errors updating or installing dependencies" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8088>
<mborzecki> our project prepare is flaky ^^ looks like this was masking some errors
<zyga> mborzecki: can you git blame and see what's the reason for the original code?
<zyga> ah
<zyga> I see
<mborzecki> zyga: that's from before we had *-unstable systems
<zyga> we should land or close https://github.com/snapcore/snapd/pull/8047
<mup> PR #8047: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
<mborzecki> zyga: do you recall why we have mock in spread suite package dependencies on fedora?
<zyga> perhaps we used to build with mock?
<zyga> but otherwise no, it should not be there
<mborzecki> can i get some reviews of #8081?
<mup> PR #8081: tests/main/user-session-env: add test verifying environment variables inside the user session <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8081>
<mborzecki> zyga: ^^ maybe?
<zyga> yeah
<mborzecki> it's super simple
<zyga> mborzecki: does su -l or sudo -l setup a session?
<zyga> mborzecki: approved
<zyga> mvo: I'm off, going upstairs to the other sick folks
<pedronis> mvo: I reviewed #8063 and made a slightly annoying comment, sorry
<zyga> I'll be back later to check upon things, if I feel better
<mborzecki> zyga: no, it's weird but they do not, in this sense, afaiu the genrators, /lib/environment.d handling is only done when there's systemd --user involved, something that does not happen with su/sudo
<zyga> I'll skip standup
<mup> PR #8063: cmd/snap: implement 'snap remove-user' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
<mvo> pedronis: thank you, it's fine
<mvo> zyga: get well!
<mup> PR snapd#8089 opened: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
<ijohnson> Morning folks
<mborzecki> ijohnson: hey, you're up early ;)
<ijohnson> mborzecki: indeed!
<pstolowski> hi ijohnson!
<ijohnson> o/ pstolowski
<Chipaca> zyga: WRT #core18/89, I talked with xnox at the sprint and was told it would be fixed Soonâ¢
<Chipaca> core18#89
<mup> Issue core18#89: bash completion not installed if "core" snap is not installed <Created by albertodonato> <https://github.com/snapcore/core18/issue/89>
<xnox> Chipaca:  but did I do it? Not yet!
<Chipaca> xnox: so you're saying it should be Soonâ , not Soonâ¢?
<xnox> hahhaha
<pedronis> mvo: this is a possible smoking gun on the running too long suites:  https://pastebin.ubuntu.com/p/m7cJKkjGjp/
<pedronis> I got a timeout again
<mvo> pedronis: is this just 20.04? or all over the place?
<ijohnson> pedronis: I've seen that before a week or two ago, but wasn't able to find the cause of that
<pedronis> mvo: only 20.04 afaict in my run
<ijohnson> mvo: pedronis: I saw it on 19.10 too https://pastebin.ubuntu.com/p/4Kqpj2CnPb/
<pedronis> mvo: the full log is here: https://api.travis-ci.org/v3/job/645874351/log.txt
<pedronis> anyway it would be good if we made it fail at least
<pedronis> vs hanging
<pedronis> and timeout the whole suite
<ijohnson> hmm actually my failure had a different pulseaudio error
<pedronis> in this one btw afaict the test never finishes
 * mvo scratches head
<pstolowski> pedronis: hey, looking at you comment re #7705: "we should think how to avoid these changes, probably by having a *firstBootBaseTest .."; do you mean having makeSeedChange) in a new firstBootBaseTest?
<mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<pedronis> pstolowski: no, I mean structuring nesting the suite setup a bit differently
<pedronis> pstolowski: let me try to see if I can sketch something to be clearer
<pstolowski> pedronis: thanks
<mborzecki> hm why would it ping bluez in a vm on gcp?
<mborzecki> pedronis: any chance this test was running after one that installs bluez?
<pedronis> pstolowski: this https://github.com/snapcore/snapd/pull/7705/files#r374630332 if it makes any sense
<mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<pstolowski> pedronis: thanks, will play with it
<ijohnson> pedronis: 8077 is ready again, note that it's gotten rather large again, if you'd prefer I can close this and we can land the smaller bits from the PR individually now?
<mborzecki> 8075 and 8076 would be a good start
<pedronis> ijohnson: thx, I'll look and decide, trying to finish something else ATM
<ijohnson> pedronis: no rush, thanks
<mup> PR snapd#7965 closed: DRAFT - tests: enabling main and regression test suites for core20 <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7965>
<mborzecki> ijohnson: some comments in 8076
<ijohnson> mborzecki: thanks looking now
<mborzecki> ijohnson: the part that mounts the kernel tries to use the current kernel as fallback, we should probably do the same for base, and use one that's listed in base= in modeenv (does that make sense?)
<ijohnson> yes that makes sense, I will implement that now
<ijohnson> afk for a little bit
<pedronis> ijohnson: it's a bit hard to judge because of the prereq but it might make sense to try to split out the initramfs bits
<ijohnson> pedronis: the initramfs is already split out - that's 8076
<pedronis> ah
<pedronis> we really need to solve the test snap-bootstrap issue
<mborzecki> pedronis: can we ask nicely for relevant packages and snaps to be rebuilt? :)
<mborzecki> ijohnson probably did that already
<pedronis> not really, this is about the kernel
<pedronis> it cannot be rebuilt that often
<pedronis> we really need to inject in our tests
<mborzecki> pedronis: ah, i see what you mean, we coudl try repacking it in prepare, i can look into that
<pedronis> mborzecki: I think ijohnson has a PR, but is building things and is too slow (5m)
<pedronis> mborzecki: you should sync with mvo on this
<mborzecki> ack
<ijohnson> mborzecki yes the PR is open but it is slow and I had an issue where sometimes it fails to reboot for reasons I don't understand, same thing works locally outside of spread
<mborzecki> ijohnson: ok, let me look at it
<pstolowski> cachio: hey, i've replied to one of your comments under  my new nested vm nests; let me know if you need more info about how preseeding works
<cachio> pstolowski, nice, I'll take a look
<cachio> pstolowski, hey, images created
<cachio> I added the info to the PR
<pstolowski> cachio: oh wow, that was fast, thank you!
<cachio> I can test them on my afternoon if you need help on that
<cachio> after I finish snapd validation
<cachio> pstolowski, if you want I can update the spread.yaml with the new info
<pstolowski> cachio: that would be great, ty
<pstolowski> cachio: are you going to push any spread.yaml changes to my PR, or a separate one?
<cachio> pstolowski, in yours, give me 1 minutes
<pstolowski> cachio: awesome, np
<jdstrand_> pedronis: hey, what kind of coordination needs to happen with the store re plug-names/slot-names (ignoring the review-tools for a moment)? eg, if I issued a snap decl with plugs-names, today, what would happen?
<pedronis> jdstrand: the version they use of the assertion library need to be updated
<jdstrand> pedronis: ok, so it will give version 4. and what happens if the store gives version 4 and snapd still only supports version 3?
<pedronis> jdstrand: it gets the old format answer
<pedronis> it gets the assertion with the highest revision with the old format
<cachio> pstolowski, cant push to your branch
<jdstrand> pedronis: so the store knows to strip out the version 4-only bits?
<cachio> pstolowski, do you want the diff?
<pedronis> jdstrand: so it uses the old value
<pedronis> it uses the old assertion
<pedronis> it doesn't strip things
<jdstrand> pedronis: ah. ok
<pedronis> jdstrand: it filters on format the known revisions
<jdstrand> pedronis: so, in order to start issuing plug-names, we need to make sure that snapd 2.44 has gone to stable (for reexec) and all distros without reexec have 2.44
<pstolowski> cachio: sure you can give me the diff; perhaps you added my git remote with https:// instead of ssh?
<jdstrand> pedronis: (and the assertion library needs updating of course)
<pedronis> jdstrand: yes, we do need 2.44 to be widely released
<jdstrand> pedronis: has the assertion library been updated?
<pedronis> not yet
<pedronis> they were going through a previous update yesterday
<pedronis> I will ask them to, so it's done before 2.44
<jdstrand> pedronis: and in terms of cross distro, it seems that sometimes we don't update everywhere. are you planning to for 2.44?
<jdstrand> (for distros without reexec)
<pedronis> jdstrand: we should try, do you have something particular in mind?
<pedronis> I mean some particular distro?
<jdstrand> pedronis: I'm just trying to document when we can cut over to plug-names for personal-files/system-files and trying to get a feel for the timing
<pedronis> jdstrand: ok, we'll need probably a slightly slow approach to that
<jdstrand> pedronis: I was also wondering if you had plans or thought about updating the base decl policy for this. eg, snapd-control with plug-names: $INTERFACE
<pedronis> jdstrand: yes, but we need to go check how many snaps wouldn't need changes
<cachio> pstolowski, https://paste.ubuntu.com/p/tW7K2pcQ4B/
<jdstrand> pedronis: yes, that is what I've gathered
<pstolowski> cachio: ty
<pedronis> jdstrand: also to be honest changing the base decl is not that useful
<cachio> sorry, my network failed
<pedronis> it mostly says you cannot have those interfaces
<jdstrand> pedronis: oh, yeah. I didn't ask about personal-files because it has an installation contraint, but then, so does snapd-control :)
<pedronis> all the superpriviledge ones says no
<pedronis> so it would be a matter to change the snap-declaration
<jdstrand> pedronis: yes
<pedronis> but we need to check the snaps
<jdstrand> yes
<pedronis> also change the UI
<pedronis> backend
<pedronis> to produce different patterns
<pedronis> that needs store work
<jdstrand> it becomes a process thing
<jdstrand> yes
<jdstrand> ok, thanks
<mborzecki> mvo: ijohnson: this is what i've got so far
<mborzecki> https://paste.ubuntu.com/p/FgcGBHdZkB/
<ijohnson> mborzecki: you can also filter dirs to use when extracting with unsquashfs so you could just do all of them except firmware IIUC
<mborzecki> right, that's the next step :)
<ijohnson> mborzecki: but that all looks good to me, excited to see it work :-)
<mvo> mborzecki: woah, that is pretty far, nice job
<pedronis> ijohnson: thank you, I did a pass on 8077, couple minor things in basestate20.go, we need with mborzecki to unblock the prereqs before getting this one in, also as I mentioned in the standup it probably needs 2 other reviewers as well
 * cachio lunch
<ijohnson> pedronis: ack makes sense
<pedronis> pstolowski: are you blocked on me reviewing something ATM?
<mborzecki> hmm same method of unpacking, but on focal unmkinitramfs works fine but on bionic it says premature end of archive and does not extract the rest of initrd
<pedronis> can't we now make the core 20 based on a focal image ?
<pedronis> sorry, I mean the core 20 tests
<pedronis> it starts with a bionic one
<pedronis> but not sure is needed anymore?
<pstolowski> pedronis: not for today. i've addressed your latest comment to #7705, will need your re-review, and after that a review of #8046 (which i'm currently updating based on feedback from Sergio). but tomorrow i may look at doing something new & wait for reviews. i may start adressing known TODOs for firstboot, but i'm not sure about stacking more stuff on top of the two existing PRs
<mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<pedronis> pstolowski: ok, want to eod a bit earlier than yesterday
<pstolowski> sure
<ijohnson> pedronis: we can't make it based on focal unless cachio creates a uefi image based on focal, not sure how doable that is or not
<ijohnson> mborzecki: that's not surprising, perhaps we could make a simple snap based on core20 with the things we need from focal and install it during the build to prep the image ?
<ijohnson> mborzecki: I did manage to successfully build a snap based on core20 so I could do that if that is necessary/useful
<pstolowski> cachio: the new nested vm tests wotk with 19.10 and 20.04 images \o/
<ijohnson> pstolowski: do you have a second to chat about the disconnect --forget PR? I'm trying to test it locally but whenever I use the --forget option I get "error: invalid empty plug name"
<jdstrand> pedronis: one last question (I'm documenting this for reviewers): suppose the assertion library is updated in the store to support v4. now suppose a reviewer issues a snap decl that only uses v3 and lower items. does the store save that as v3 or v4?
<mborzecki> ijohnson: mvo: need to step out with the kids soonish, i've pushed what i have to ian's branch in #8069
<mup> PR #8069: tests: build the initramfs + kernel snap for UC20 spread tests <Precious Logs> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8069>
<ijohnson> mborzecki: I'll take a look in my PM
<mvo> mborzecki: thank you
<ijohnson> thanks mborzecki !
<pstolowski> ijohnson: sure
<ijohnson> pstolowski: so it seems that whenever the plug is missing and I use the --forget flag the only error message I get is `error: invalid empty plug name`, even though the plug name is there
<jdstrand> pedronis: put another way, does the store save to the lowest format that supports the snap decl or to the highest version the assertion library supports?
<pedronis> jdstrand: the former, v3
<ijohnson> https://www.irccloud.com/pastebin/6WZ4nec3/
<ijohnson> pstolowski: ^
<jdstrand> pedronis: ok, cool. thanks!
<ijohnson> that seems wrong but I can't tell where in the code the issue is from?
<pstolowski> ijohnson: hmm interesting. maybe i missed something, need to check
<pedronis> jdstrand: asserts has feature detection to pick the lowest format
<ijohnson> pstolowski: ok, it's possible I'm doing something wrong to test too, but it seems that error message always shows up for me, no matter the plug name if I use --forget
<pstolowski> ijohnson|lunch: it's possible you are onto something.. cmd disconnect (client side) does something with arg swapping. i'm investigating
<pstolowski> will update my spread test
<jdstrand> pedronis: yeah, cool. that is smart. it allows us the ability to issue an updated v3 and a new v4 declaration (for example) in the store. For reviewers, that is error prone and not particularly transparent (so not recommended in normal work flows), but having the ability just in case is nice
<jdstrand> pedronis: I was doing a thought experiment on 'what if we started using plug-names ahead of good snapd field penetration' and then had questions on how the store does things (fyi, landed on 'just wait' in case you were wondering)
<pedronis> jdstrand: to really to that nicely we would like to put them in the assertion store atomically together
<pedronis> s/to that/do that/
<ackk> hi, I have a prime dir which I previously had "snap try"'d. the snap (maas) requires maas-cli via content interface. after removing both snaps, I can't seem to be able to remove the maas-cli/lib inside the prime dir, not even as root
<ackk> how can I debug what's preventing it?
<ackk> (I get permission denied)
<jdstrand> pedronis: yeah. with different forms or something, I guess. the store can't really guess the intent of the decl though, so I also think it is smart we aren't auto-filtering down
<pedronis> jdstrand: yes, auto-filtering could have strange security implications that are hard to predict
 * pedronis mostly eods
<jdstrand> pedronis: oh, sorry to keep you! enjoy your eod :)
<ijohnson|lunch> pstolowski: cool glad I helped you find a bug :-)
<pstolowski> ijohnson|lunch: just confirmed with a spread test, thanks for catching! something is off with shortened syntax
<cachio> pstolowski, nice, great news
<cachio> ijohnson|lunch, I can update the ubuntu  19.10  created for nested execution and enable uefi in case it is needed
<cachio> ijohnson|lunch, just confirm if you need that and I'll make the change
<ijohnson|lunch> cachio I don't know yet, I'll look after my lunch to see if it's needed and let you know but to confirm you can't do 20.04 yet correct?
<cachio> ijohnson|lunch, good, just ping me in case you need it
<pstolowski> ijohnson|lunch: ok, I think I see the problem. the existing ResolveDisconnect code in repo is very tolerant (specifically, the connected() method). with just 1 argument (the plug side) the client swaps args around (so it becomes a slot and empty plug). this is later "corrected" by the flexibility of ResolveDisconnect/connected, which tries to match by treating the arg as plug-or-slot. it gets very confusing along the way
<pstolowski>  because for most of the time we use plugName, slotName as variables, while sometimes they become plug-or-slot really. i haven't reflected this fuzzyness in my variant of ResolveDisconnect with forget
<pstolowski> i will look at fixing it tomorrow, eod for now
<mup> PR snapd#8088 closed: tests/lib/prepare-restore: Revert "Continue on errors updating or installing dependencies" <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8088>
<mup> PR snapcraft#2909 opened: elf: search for host libraries within search paths <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2909>
<mup> PR snapd#8084 closed: many,randutil: centralize and streamline our random value generation <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8084>
<mup> PR snapd#8090 opened: randutil,o/snapstate,-mkauthors.sh: follow ups to randutil introduction <Created by pedronis> <https://github.com/snapcore/snapd/pull/8090>
<mup> PR snapd#8087 closed: dirs: variable with distros using alternate snap mount <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8087>
#snappy 2020-02-05
<mup> PR snapcraft#2909 closed: elf: search for host libraries within search paths <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2909>
<mborzecki> morning
<mborzecki> driving kids to school, back in 30
<mborzecki> re
<mborzecki> pstolowski: hey
<pstolowski> mornings
<mup> PR snapd#8090 closed: randutil,o/snapstate,-mkauthors.sh: follow ups to randutil introduction <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8090>
<mborzecki> mvo: hey
<mvo> hey mborzecki
<zyga> Still sick. Lucy has 39C all evening. Today somewhat better but we are all still out :/
<zyga> I filed paperwork for yesterday till tomorrow
<zyga> Fingers crossed it passes
<mvo> zyga: I got it now too
<pedronis> our tests seem to ger red easily again
<zyga> Specific test or all over?
<mvo> hm, I see failures in the se-linux-clean test
<mborzecki> mvo: meh cannot find any Google image matching "ubuntu-2004-64-uefi-enabled"
<mvo> mborzecki: booo :(
<mborzecki> mvo: which PR?
<mvo> mborzecki: https://travis-ci.org/snapcore/snapd/builds/645891245?utm_source=github_status&utm_medium=notification
<mvo> - google:fedora-30-64:tests/main/selinux-clean
<mvo>     - google:fedora-31-64:tests/main/selinux-clean
<pedronis> mborzecki: did you the notes by Ian
<pedronis> he worked on someting based on a snap
<mborzecki> pedronis: i'm looking into it already ;)
<pedronis> mborzecki: what should we do about #7414 ?
<mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
<pedronis> it seems there are request to merge something with *-tool but the tool it mentions don't even exists in master
<mborzecki> pedronis: needs reviews, there were some comments about a distro-tool from zyga but i'm not sure we want another *-tool for that, and it's more effort to write one
<pedronis> I have mixed feelings about *-tool because quite a few seem to have just one action, so beind called -tool seems obfuscating a bit
<zyga> https://forum.snapcraft.io/t/snap-is-updating-off-schedule/15323/2 is interesting - any idea why it might trigger off time
<pedronis> we need to investigate, that code is very organic
<mborzecki> zyga: two thins we could do, make the log message about the next refresh time be 'info' rather than 'debug', and actually log why refresh is triggered (i.e. by timer, by user request etc.)
<mborzecki> heh objcopy --update-section corrupts the initrd :/
 * zyga tries to get some sleep
<zyga> Have a good day guys
<pstolowski> pedronis: hi, Ian found a problem with snap disconnect --forget if only a single arg is given; my implementation of resolvedisconnect over conns is not sufficient, the one from repo is smarter. i need to enhance my variant of resolve - unless we want to require both plug & slot to be passed with --forget. wdyt?
<pedronis> pstolowski: they should behave the same
<pedronis> but it also sounds that repo code is confusing
<pedronis> pstolowski: is there something we can improve overall?
<pedronis> pstolowski: my worry here is to have to write clever/confusing code twice as well
<pedronis> pstolowski: do you want to chat quickly on this?
<pstolowski> pedronis: yes let's chat
<pstolowski> pedronis: standup ho?
<pedronis> yes, one sec
<mborzecki> can snapcraft build a snap with base: core20 in multipass?
<pedronis> mvo: sorry for my comment, I will ignore 8085 until you tell me to look again
<mvo> pedronis: my bad, sorry! I pused last night but it was not ready
<mvo> pedronis: I should have marked that in the PR
<mup> Bug #1862007 opened: 'aws-iot-greengrass' snap fails to start due to apparmor <apparmor> <aws> <core> <greengrass> <iot> <libcontainer> <runc> <snap> <ubuntu> <Snappy:New> <https://launchpad.net/bugs/1862007>
<pedronis> mvo: do you understand this bug:  https://bugs.launchpad.net/snapd/+bug/1861901 ? is it a misdetection of the change of base?
<mup> Bug #1861901: Refreshing a snap using core18 to one using core16 confuses the snap apps <snapd:New> <https://launchpad.net/bugs/1861901>
<zyga> pedronis: yes
<pedronis> zyga: should I assign it to you, then?
<zyga> pedronis: reproduced, there's a mis-detection
<mup> Bug #1862007 changed: 'aws-iot-greengrass' snap fails to start due to apparmor deny on mounting of "/proc/latency_stats". [interface/greengrass-support] <apparmor> <aws> <core> <greengrass> <iot> <libcontainer> <runc> <snap> <ubuntu> <snapd:New> <https://launchpad.net/bugs/1862007>
<zyga> pedronis: updated the bug
<zyga> pedronis: I'll look, it should not be happening
<zyga> pedronis: I can look while lucy is sleeping
<mvo> thanks pedronis and zyga
<zyga> diagnosed, updated the bug as well
<zyga> mvo: while the TODO fix is still hard we now have an easy way out
<zyga> mvo: I believe this is sufficient to resolve this
<zyga> https://www.irccloud.com/pastebin/llLwEMeL/
<zyga> I'll add a spread test first, curious why the existing one doesn't spot this
<mup> PR snapd#8091 opened: Bug #1862007: 'aws-iot-greengrass' snap fails to start due to apparmoâ¦ <Created by dostiharise> <https://github.com/snapcore/snapd/pull/8091>
<zyga> perhaps it is a result of our core test setup and repacking
<zyga> pedronis, mvo: wrote a regression test, started and going to check on lucy
<pedronis> pstolowski: reviewed 7705, some final comments, also it conflicts ATM
<pstolowski> pedronis: ah, thanks
<mup> PR snapd#8092 opened: timeutil: add a unit test case for trivial schedule <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8092>
<mborzecki> cachio: hi
<cachio> mborzecki, hi
<mborzecki> cachio: can you create a 20.04 uefi enabled image for use in core-20 tests? right not we're using 18.04 but need to pull in some updated packages
<cachio> mborzecki, we already have this ubuntu-2004-64-virt-uefi-enabled
<cachio> do you need a pr ?
<cachio> or you need it in a pr?
<mborzecki> no that's fine i can set it locally and check whether the code works
<cachio> that you are already coding
<mborzecki> cachio: yay, and it works, thanks!
<cachio> mborzecki, yaw
 * zyga gets back to bed
<mup> PR snapd#8093 opened: cmd/snap-confine: detect base transitions on core16 <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8093>
<zyga> pedronis, mvo: ^
<zyga> mvo: I marked this as aiming at 2.44
<zyga> mvo: but feel free to retarget
<ijohnson> mborzecki: so are you still going to use the ubuntu-core-initramfs snap I made or is the plan still to use your manual object manipulation unpacking/repacking ?
<mvo> zyga: thank you
<zyga> https://www.irccloud.com/pastebin/cBgVrHKy/
<zyga> mvo: ^
<mborzecki> cachio: can you point me to the logs with the link-snap problem?
<cachio> https://paste.ubuntu.com/p/TYVdsbbCQm/
<ijohnson> mborzecki: I merged your PR to ubuntu-core-initramfs-snap and it's been released on edge now
<pstolowski> cachio: #8046 is ready for re-view if you have some time
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<cachio> https://paste.ubuntu.com/p/sPZCNnXMcr/
<cachio> mborzecki, I already have a debug session here
<mborzecki> ijohnson: cool, thanks
<cachio> mborzecki, if you need any other info just ping me
<cachio> pstolowski, nice, I'll take a look
<mvo> zyga: importing internal yield an error for me
<zyga> mvo: my point was the docstring, not the code, the code is used internally anyway
<mvo> zyga: aha, I see
<mborzecki> cachio: can you paste the contents of /var/lib/snapd/sequence/snapd.json?
<mborzecki> ijohnson: trying with `rm -rf firmware/*` xD
<ijohnson> mborzecki: :-) good luck!
<sdhd-sascha> Hi, does anybody has an idea, how to push/delete an git tag on github. With the name of "refs/heads/master" ?
<cachio> mborzecki, {"sequence":[{"name":"snapd","snap-id":"PMrrV4ml8uWuEUDBT8dSGnKUYbevVhc4","revision":"6240","channel":"beta"}],"current":"6240"}
<sdhd-sascha> To delete other git tags, on remote git, was no problem...
<sdhd-sascha> Not sure, how i could create a tag with this name ... "refs/heads/master"
<sdhd-sascha> https://github.com/sd-hd/termite-snap/tree/refs/heads/master
<cjwatson> sdhd-sascha: git push --delete <name of remote that you normally use to push> refs/tags/refs/heads/master
<roadmr> jdstrand: yay, tools 20200203-1915UTC are now in production in the store
<cjwatson> remote name might be "origin", dunno, depends how your local tree is set up
<jdstrand> roadmr: thanks! :)
<sdhd-sascha> cjwatson: thank you :-) seems to work
<mup> PR snapd#8094 opened:  tests: repack thethe initramfs + kernel snap for UC20 spread tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8094>
<mborzecki> ijohnson: opened to #8094 to see if it makes a difference, something must start t work at some point :)
<mup> PR #8094:  tests: repack thethe initramfs + kernel snap for UC20 spread tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8094>
<mborzecki> ijohnson: it'd be better to make 8069 work though
<ijohnson> mborzecki: did that get you a booting image on gce though?
<ijohnson> or is this just to try
<mborzecki> ijohnson: it's still running here
<ijohnson> mborzecki: ah
<mborzecki> it'd be nice to just go with the necessary modules, drop the rest and depmod to make sure what's left is consistent
<ijohnson> oh also mborzecki re: building core20 snaps, snapcraft doesn't support it right now unfortunately
<mborzecki> ijohnson: so the image boots and seeds fine without firmware locally under qemu
<mborzecki> ijohnson: figured, i built eventually in 20.04 vm with --provider=host --destructive-sthsth
<ijohnson> what I do is a bit tricky is `lxc launch ubuntu-daily:20.04 snapcraft-$SNAP_NAME` and then on your host do `snapcraft --use-lxd` and snapcraft will bootstrap the lxc container but still fail somewhere, but then your host tree is mounted inside the container and you can modify stuff on the host and build within the container with just `lxc exec snapcraft-$SNAP_NAME cd project && snapcraft --destructive-mode`
<mborzecki> ijohnson: heh, spread timeout, maybe it's seeding that long after all
<ijohnson> mborzecki: hmm can you try changing the timeout? spread should be able to ssh into it even if seeding fails IIUC
<mborzecki> ijohnson: removing firmware makes the time from `Preparing google:ubuntu-core-20-64` to rebooting go down from 13minutes to just under 7 minutes
<ijohnson> wow nice!
<pedronis> mborzecki: #7588 is the PR I mentioned that needs a 2nd review
<mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<mborzecki> pedronis: cool, thanks
<ijohnson> cachio: is there a way to see the console when we reboot on gce via spread ? i.e. see early boot messages and the like before the machine is available via SSH
<cachio> ijohnson, yes
<mborzecki> ijohnson: hm got the kernel snap down to 29MB, still booting and seeding
<mborzecki> cachio: about that failure, it looks like this failed while installing snapd for the first time
<mborzecki> cachio: was it past seeding?
<cachio> mborzecki, you mean snapd snap could not be installed correctly initially?
<cachio> mborzecki, should wait until snapd is fully seeded to run the tests?
<ijohnson> mborzecki: nice, I'm looking at your spread run for that new PR, cachio got me logs, doesn't look like it's tried to reboot yet
<mborzecki> cachio: can you access the console of feb051525-057526 node?
<cachio> mborzecki, yes
<cachio> mbI am already connected
<cachio> mborzecki,  I am already connected
<mborzecki> cachio: to the device?
<cachio> mborzecki, yes
<cachio> I see -> flash-all-snaps
<cachio> in the menu
<cachio> grub version 2.04
<mborzecki> cachio: screenshot?
<cachio> mborzecki, sent
<cachio> check telegram :)
<ijohnson> mborzecki: I noticed this in the console after it tries to reboot: `error: file '/vmlinuz' not found.`
<ijohnson> why would it be trying to boot /vmlinuz ?
<ijohnson> cachio: do you know if gce uefi first boots it's own grub then chainloads to our grub?
<mborzecki> hmmmm unexpected, and flash-all-snaps?
<cachio> ijohnson, no idea
<ijohnson> yeah I dunno what this flash-all-snaps is
<mborzecki> is it using the right gadget?
<ijohnson> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<ijohnson> it's mvo's fault :-)
<ijohnson> the reflash magic script has a miny grub.cfg that tries to load /vmlinuz but that's not there now
<ijohnson> see line 793ish of prepare.sh
<cachio> :)
<ijohnson> hmm I wonder what the right thing to do now then is
<mborzecki> pffff
<mborzecki> hmmmmm we coudl do soemthing weird
<mborzecki> like pivot to a tmpfs rootfs, wipe and reboot?
<ijohnson> I think all we need to do is probably just to change the linux and initrd parameters for uc20 in that mini grub.cfg
 * cachio lunch
<jdstrand> ijohnson: re test-snapd-ubun
<jdstrand> meh
<jdstrand> ijohnson: re test-snapd-ubuntu-core-initramfs: wouldn't kernel-module-observe be sufficient for reading kernel modules?
<mvo> ijohnson: oh, fun!
<mvo> ijohnson: nice catch
<ijohnson> jdstrand: well so the snap doesn't actually need to read the system's kernel modules, I think it will most of the time be reading modules that are put somewhere in $HOME, etc. because it's a dev tool used on already assembled kernel snaps, but the denial I was seeing was from using depmod or some other tool which wanted to read some things from the host system
<ijohnson> jdstrand: I did add a layout for one thing that it was trying to read so it read the thing I wanted it to and not the host system's, so perhaps that should be done for the other access as well and then it doesn't need hardware-observe
<mup> PR snapcraft#2875 closed: split debug information <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2875>
<mup> PR snapcraft#2910 opened: [experimental] debug splitting <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2910>
<ijohnson> jdstrand: but this is just a test snap to try and unblock uc20 spread testing, but there is a longer term plan on what to do with the ubuntu-core-initramfs snap from xnox and foundations, so perhaps they would be better suited to answer whether kernel-module-observe makes sense for that snap
<ijohnson> mvo: :-) yes it all makes sense now
<jdstrand> ijohnson: what is the denial that you saw that made you want to use hardware-observe? the justification in the forum was "This package requires access to reading kernel modules on the system". That is what kernel-module-observe is for
<jdstrand> ijohnson: I'm prepared to grant the request immediately. I just want to know if there is a bug in the kernel-module-observe interface
<ijohnson> jdstrand: tbh I don't remember, something that was only found in hardware-observe like /etc/modprobe.d maybe ?
<mborzecki> ijohnson: i'm leaving for a meetup, can you push the update to both PRs?
<jdstrand> ijohnson: that is in kernel-module-observe
<ijohnson> mborzecki: yes I'll sort out what to do about that when I figure out the right thing to do
<mborzecki> ijohnson: got some tweaks that drop firmware and modules if you want to try that https://paste.ubuntu.com/p/zmBfpZYWNs/, prepare -> reboot takes 4 minutes now
<jdstrand> ijohnson: I'm willing to fast track this, but it puts me in an awkward position that the justification is for something that is supposed to be handled by another interface
<ijohnson> jdstrand: it's entirely possible that I went searching for an interface that unblocked the snap and just found hardware-observe first and went with that
<ijohnson> jdstrand: if you'd rather I use kernel-module-observe I can do that instead
<jdstrand> ijohnson: please do and I'll grant it. I'll comment in the topic. if you need something more, post in the topic and we can go from there (allowing auto-connect of hardware-observe if needed until the bug is fixed)
<ijohnson> jdstrand: one more wrinkle that perhaps you'd rather deal with now, is that I named the snap test-snapd-ubuntu-core-initramfs because ubuntu-core-initramfs is reserved, and I just wanted to get it working ASAP and so didn't go through the process of requesing that name, would you rather we try to go through that process before granting kernel-module-observe instead?
<jdstrand> ijohnson: I don't have a problem with the name
<ijohnson> jdstrand: ok give me a few minutes to re-build the snap, not sure if upload to the store will get blocked on kernel-module-observe or not
<jdstrand> ijohnson: I'll unblock you. if you end up renaming it for your own reasons, just ping me
<jdstrand> ijohnson: it won't
<jdstrand> (it isn't superprivileged)
<ijohnson> jdstrand: thanks
<jdstrand> ijohnson: but you also now have auto-connect
<ijohnson> jdstrand: alright it's building somewhere up in the clouds now and should be released shortly, I guess the declaration doesn't need a revision uploaded with that plug in order to be granted then?
<jdstrand> ijohnson: nope
<ijohnson> cool
<mup> PR snapd#7490 closed: interfaces/app-launch: support confined snaps launching other snaps <Needs Samuele review> <Created by AlanGriffiths> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7490>
<pedronis> cachio: what's the status of #7983
<mup> PR #7983: tests: adding more tests to core20 test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7983>
<cachio> pedronis, needs reviews
<cachio> I already answer the questions on that one
<ijohnson> pstolowski: do I need to review #8046 before #7705 or vice versa?
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<ijohnson> not sure which PR I should start with
<pstolowski> ijohnson: #7705 first
<ijohnson> pstolowski: ack thanks
<pstolowski> thank you!
<pedronis> mvo: should I re-review 8085, or is not ready yet? skimming it still looks disaligned from udevmonitor
<mvo> pedronis: it's still a bit disalinged my feeling is that udevmonitor could be simplified but maybe worth a look, then you can tell me what I missed in 8085 :)
<mvo> pedronis: what I mean is that if 8085 looks reaonable I could simplify udevmonitor
<pedronis> mvo: I made some comments in 8085
<pedronis> feel free to counter-comment, though the point on Stop waiting is kind what we always do
<pedronis> mvo: actually I'm quite confused by the new code
<pedronis> mvo: I added a comment that maybe helps, sorry if I was confusing before
<mup> PR snapd#8008 closed: render: add the render package and basic widgets <Needs Samuele review> <â Blocked> <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8008>
<pedronis> mvo: did you see this comment: https://github.com/snapcore/snapd/pull/8085#discussion_r375410680 ?
<mup> PR #8085: [RFC] netutil: add default gateway monitor <Created by mvo5> <https://github.com/snapcore/snapd/pull/8085>
<mvo> pedronis: thank you, having a look now
<pedronis> mvo: I'm trying locally, and what I have in mind doesn't quite work
<mvo> pedronis: yeah, this puzzled me
<mvo> pedronis: I assumed (naively) that closing the fd would stop the read
<mvo> pedronis: but this does not work, hence the comment, but maybe I'm just missing something
<mvo> pedronis: fwiw, it seems it's similar in C (https://gist.github.com/mvo5/902a2bedd201cf4670a630b8db4f9171) but again, I'm not at my best today so maybe it's something else. in any case, I suspect that the netlink code we already have has the same issue but we never tested for this
<mvo> pedronis: (and sorry that this is a bit of a rathole :(
<pedronis> mvo: well, man of close kind of says not to do this (close from different thread)
<mvo> pedronis: it does but it's also a bit vague. anyway, a net.FileCon solves this nicely but it's not supported for netlink sockets :(
<mvo> pedronis: (AIUI net uses epoll internally so they notice the change in the fd)
<mvo> pedronis: the alternative would be to use syscall.Select() on the ns.netlinkFd but that quite annoying to do in go it seems
<mvo> pedronis: anyway, sorry for my rambling
<pedronis> mvo: why FileConn doesn't work?
<mvo> pedronis: it checks internally for the type of connection, let me try to find you the code
<mvo> pedronis: https://golang.org/src/net/file_unix.go?s=1840:1887 (line 42ff)
<mvo> pedronis: it checks the peer and the netlink connection is syscall.SockaddrNetlink which is not covered there
<mvo> pedronis: it's annoying because my testcode (the mock uses a AF_UNIX) works fine with the FileConn just not the real thing
<mup> PR snapd#8095 opened: snap-bootstrap: add tpm support <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8095>
<mup> PR snapcraft#2904 closed: meta: move Snap's from_dict() system-username parsing into SystemUser <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2904>
<mup> PR snapd#8096 opened: tests: skip itnerfaces-udisks on ubuntu-20.04-64 due to timing issue <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8096>
<mup> PR snapcraft#2880 closed: package management repository configuration <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2880>
<mup> PR snapcraft#2911 opened: [experimental] package-management repository configuration <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2911>
<diddledan> I made a thing to work alongside jamesh's build and publish GitHub Actions: https://github.com/diddlesnaps/snapcraft-review-action
#snappy 2020-02-06
<bdx> hello
<bdx> I just threw up this question on discourse: https://forum.snapcraft.io/t/lxd-profile-for-content-interface-bind-mounts/15344
<bdx> trying to get some hits
<bdx> possibly ill dig a little deeper and ask on the lxd side of things too as it seems to be more of a lxd/lxc thing
<bdx> thought I would start here
<bdx> thanks!
<mborzecki> morning
<mborzecki> meh, wish we could access the console of spread nodes
<Saviq> hey, is there a way to make snapd skip confinement when:
<Saviq> system does not fully support snapd: apparmor detected but insufficient permissions to use it
<mborzecki> Saviq: i don't think so, where did you get that message?
<pstolowski> morning
<mborzecki> pstolowski: hey
<Saviq> mborzecki: I've a VPS (a container actually) at a friend's
<Saviq> it's his custom kernel, though
<mborzecki> Saviq: looking at the code, we're trying to poke /sys/kernel/security/apparmor/profiles as root with some comments that problems can happen in unprivileged lxd
<mborzecki> Saviq: anyways, it's a sanity check so further snapd operation will be blocked sadly, we dont' really have a mechanism to degrade apparmor support in this scenario
<Saviq> ack, thanks :/
<Saviq> mborzecki: so the solution would be to get permissions to actually set up apparmor inside the container?
<mborzecki> Saviq: yes, i believe so
<mborzecki> Saviq: simplest check would be to run aa-status as root inside the container
<Saviq> "You do not have enough privilege to read the profile set."
<mborzecki> Saviq: yeah, that's what snapd is hitting too, maybe zyga remembers more details about that
<mborzecki> mvo: pedronis: hi
<mvo> hey mborzecki
<mvo> and good morning pedronis
<Saviq> mborzecki: thanks, will negotiate with the hoster ;)
<mborzecki> mvo: i was looking through 'reflash magic' setup, did an update to grub script, but there's more problems
<mvo> mborzecki: uh, like what?
<pedronis> mvo: I fixed Stop, bit ugly (indeed it needs to use syscall.Select)
<mborzecki> mvo: ah, w8, maybe not :P sorry to cause panic, thought we added --image-size <somelargesize> to the u-i
<mvo> pedronis: thank you, did you push it already?
<pedronis> mvo: no, I need to clean up what I have
<mvo> pedronis: cool
<mvo> pedronis: yeah, sleeping over it I think without a proper fix this is too nasty so thank you so much for fixing it
<pedronis> mvo: I don't know about nasty, but is definitely confusing
<pedronis> because a Stop that doesn't stop is confusing :)
<mvo> pedronis: exactly :)
<mborzecki> mvo: have you tried this maybe https://gist.github.com/mvo5/fa14638782fe30949998096d7b3c6314#gistcomment-3167661?
<mvo> mborzecki: did you try it for the netlink socket?
<mvo> mborzecki: let me quickly give it a  go
<mvo> mborzecki: I think the issue is that go is "smart" and determines if it can poll the socket or not and for netlink there is just no support
<mborzecki> mvo: right, the change i did is make it nonblocking before wrappint ig as os.NewFile(), the implementation chceks whether the fd i non-blocking and sets up a poller for it
<pedronis> mvo: I tried that
<pedronis> sorry
<pedronis> mborzecki: I tried that
<pedronis> but go doesn't consider it non-blocking
<pedronis> and doesn't set up netpoll for it
<pedronis> for a netlink socket
<pedronis> because it's actually the reverse
<mborzecki> pedronis: i stepped through it with debugger, and was hitting the non-block kind
<mborzecki> pedronis: which go version did you use?
<pedronis> mborzecki: yea, but that's not relevant
<pedronis> it's whether netpoll is happy with
<pedronis> which it isn't indeed
<pedronis> go wil set up non blocking itself
<pedronis> if netpoll is happy
<mvo> it's interessting, I tried mborzecki version with netlink and it seems to stop the socket https://paste.ubuntu.com/p/Y2z9dh8rDT/
 * mvo scatches head
<pedronis> different go versions?
<mvo> pedronis: I have 1.12 on one and 1.13 on the other, let me try again
<pedronis> on 1.10
<pedronis> it didn't work for me
 * mvo tries that too
<mborzecki> pedronis: mvo: https://github.com/golang/go/commit/ea5825b0b64e1a017a76eac0ad734e11ff557c8e 1.11+
<mborzecki> that would explain what pedronis saw
<pedronis> anyway we are still 1.9
<mborzecki> :/
<mvo> yeah
<mvo> that makes sense now
<mvo> slightly sad
<mborzecki> mvo: do we care if it leaks though?
<pedronis> mborzecki: it's messy interface wise
<pedronis> especially in tests
<pedronis> we would need to change the interface to not have a Stop
<pedronis> etc
<pedronis> it's not pleasant to reason about
<mborzecki> pedronis: maybe we could do some extra mocking for tests
<pedronis> mborzecki: as I said I have a fix
<pedronis> is not beatiful, but I will make localized and leave a TODO for when we are 1.11+ or something
<mborzecki> pedronis: mvo: do we need to check udev monitor as well?
<pedronis> mborzecki: there's an indirection there that doesn't make the problem apparent
<pedronis> but yes osutil/udev has the same kind of bug
<mborzecki> mvo: do you know if there's a way to access the console of spread system when cachio is not around yet?
<mvo> mborzecki: afaik there is none :(
<mup> PR snapd#8097 opened: tests/lib/prepare: fix hardcoded loopback device names for UC images <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8097>
<mborzecki> mvo: trivial change ^^
<mvo> mborzecki: ta, looking
<mup> PR snapd#8092 closed: timeutil: add a unit test case for trivial schedule <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8092>
<mup> PR snapd#8098 opened: httputil: remove workaround for redirect handling in go1.7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8098>
<mup> PR snapd#8099 opened: httputil: remove go1.6 transport workaround <Created by mvo5> <https://github.com/snapcore/snapd/pull/8099>
<zyga> Hey, just waving. Still sick and weak. Sorry
<mvo> zyga: hey, nice to see you! get well
<zyga> Uh, I hate this state Iâm in. Iâll check back later.
<mvo> zyga: yeah, being sick sucks
<zyga> pstolowski: could you please re review the uio branch. We removed some code.
<pstolowski> zyga: will do
<pedronis> mvo: I pushed this branch: https://github.com/pedronis/snappy/tree/netlink-channel-n-stop
<mvo> pedronis: thanks, looking
<zyga> pedronis: if you guys want I have a epoll.go package
<mvo> pedronis: this is super nice, thanks for this
<mborzecki>         cp -a "$SNAPD_UNPACK_DIR/usr/lib/snapd/snap-bootstrap" unpacked-initrd/main/usr/lib/snapd/snap-bootstrap
<mborzecki> #8097 trivial pr, needs 2nd review
<mup> PR #8097: tests/lib/prepare: fix hardcoded loopback device names for UC images <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8097>
<mborzecki> and a bit of my clipboard :)
<mvo> mborzecki: haha
<mvo> pedronis: do you want to propose it as a separate pr or should I cherry pick it into my netlink pr?
<mborzecki> mvo: what's funny is that the same repackign code running in qemu builds a working kernel snap, but one on gcp panics with no init, probably borked initrd
<pedronis> mvo: mmh,  ideally we should split in everyhting but the new netlink bits
<pedronis> and then you could pick those
<mborzecki> glad at least we can download the build uc20 image from spread system
<mvo> pedronis: sounds good,I can take your code and chunk it into smaller PRs, I guess this is what you asked?
<pedronis> mvo: yes, one PR with the non netlink-bits
<pedronis> and the rest picked up by your PR
<pedronis> mvo: thanks if you can do that, I'm doing spec work atm
<pedronis> mvo: sorry, I mean the not new netutil netlinks bits
<pedronis> basically osutil/udev and o/ifacestate
<mvo> pedronis: thanks, yeah, happy to do that
<mup> PR snapd#8097 closed: tests/lib/prepare: fix hardcoded loopback device names for UC images <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8097>
<jamesh> sergiusens: did you see my query on the forum? (re. github actions)
<pedronis> jamesh: hi, did you see my last bit of comments on #7456 ?
<mup> PR #7456: usersession/client: add a client library for the user session agent <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7456>
<jamesh> pedronis: yeah.  I'm just tidying up some of the tests for it.  In these cases we have an error message from the agent, so I'm not sure whether we want to lose that when the error value is badly formed
<mup> PR snapd#8100 opened: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100>
<mup> PR snapd#8054 closed: snap: add `snap pack --compression=<comp>` options <Performance ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8054>
<ijohnson> mborzecki: I'll miss SU today and be out for 2ish hours, so if you want me to try anything more on uc20 spread testing, let me know, I might not be back til after your EOD
<pedronis> mvo: are you going to tweak those comments you commented on? when you make the PRs
 * pedronis lunch
<mborzecki> ijohnson: i'll leave notes in the standup doc for you
<ijohnson> Sounds good
<mvo> pedronis: yes, happy to
<mup> PR snapd#8101 opened: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<mborzecki> meh, more uc20 image woes https://paste.ubuntu.com/p/S3TP4BBPQT/
<mvo> mborzecki: did the kernel/initrd change or is this in the dev branch?
<mborzecki> mvo: nothing changed, supposedly the same kernel image i'm using, somehow when built on gcp this does not mount
<mvo> mborzecki: so this is the repackaging and it's not quite working?
<mvo> mborzecki: is this with the new snap-bootstrap? maybe we regressed here :(
<mup> PR snapd#8102 opened: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<mborzecki> mvo: i called snap-bootstrap manually, and the line is correct, tells to mount /dev/disk/by-label/ubuntu-seed under /run/mnt/ubuntu-seed
<pstolowski> pedronis: ^ i hope this captures the idea we discussed
<pedronis> pstolowski: thanks, will look
<mvo> pedronis: re 8100> picking up the certs immediately, we could do what we do for the proxy and have a "Certs func(*http.Request) (*x509.CertPool)" (just like we do for proxy. is that what you have in mind here?
<pstolowski> bbiab
<pedronis> mvo: I don't know , just fearing it will be a bit messy
<mvo> pedronis: I can explore the callback option, then at least it's equally messy to how we support the proxy :)
<pedronis> mvo: thanks for pushing #8101, of course I cannot review it :)
<mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<mborzecki> hmm i think i know what's going on
<pedronis> pstolowski: see #8101
<mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<pedronis> pstolowski: is this correct https://github.com/snapcore/snapd/pull/7863#discussion_r375827782 ?
<mup> PR #7863: interfaces: add uio interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7863>
<mborzecki> yay, got a working image in gcp
<pedronis> \o/
<pstolowski> re
<mborzecki> well, at least i did manage to download the image and make sure it boots and seeds inside qemu locally ;)
<mborzecki> haha too soon, seeding not complete
<mup> PR snapd#8103 opened: snap-bootstrap: store encrypted partition recovery key <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
<mborzecki> at least a familiar problem https://i.imgur.com/BOn7yOX.png
<mborzecki> but it did work on gcp
<mborzecki> yay!
<mup> PR snapcraft#2912 opened: meta: do not prime commands with adapter == "none" <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2912>
<mup> PR snapcraft#2913 opened: spread: disable journal debug dump unless configured <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2913>
<ijohnson> mborzecki: any progress ?
 * ijohnson is around for a little while
<mborzecki> ijohnson: got it to work
<mborzecki> ijohnson: pushing changes
<mborzecki> ijohnson: still something off about ubuntu-core-initramfs, somehow i need to use the /usr/lib/ubunto-core-initramfs/main as skeleton of the rootfs, not the unpacked one
<ijohnson> mborzecki: that's great that you got it to work
<ijohnson> are you booting from 20.04 now or did you revert to 18.04 ?
<mborzecki> ijohnson: 20.04
<mborzecki> ijohnson: it needed a little tweak in grub script
<ijohnson> ah okay, you fixed the grub.cfg and script then
<ijohnson> great
<mborzecki> ijohnson: please take a look at the PR, i've tried to comment all the quirks
<ijohnson> looking now
<mborzecki> need to leave now, back in 2h or so
<ijohnson> ack
<mup> PR snapd#8098 closed: httputil: remove workaround for redirect handling in go1.7 <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8098>
<mup> PR snapd#8099 closed: httputil: remove go1.6 transport workaround <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8099>
<jdstrand> mvo: hey, I don't know the status of 2.43 point releases, but if you are doing another one, cherry-picking https://github.com/snapcore/snapd/pull/8091#issuecomment-582935623 might make sense. we have (at least) two different forum topics and a bug on it...
<mup> PR #8091: interfaces/greengrass-support: add /dev/null -> /proc/latency_stats mount <Created by dostiharise> <https://github.com/snapcore/snapd/pull/8091>
<jdstrand> mvo: and the url above is to a comment discussing that possibility in case you want to respond
<mvo> jdstrand: thanks, will cherry pick
<mvo> jdstrand: there will be another one to include uio
<mvo> jdstrand: I added the 2.43 milestone, than kyou
<pedronis> mvo: having a break and then will work on the uio backporting prep
<jdstrand> mvo: thank *you* :)
<mvo> pedronis: thank you, I focus on reviews and download now
<jdstrand> pedronis, mvo: fyi, I have one more 2.44 review (it's a big one though). I hope to do that tomorrow. I'll then make a concerted effort to squeeze in the non-2.44 reviews while I work on other things
 * cachio lunch
<mvo> jdstrand: thanks
<mup> PR snapd#8104 opened: interfaces/builtin: backport verifySlotPathAttribute (2.43) <Created by pedronis> <https://github.com/snapcore/snapd/pull/8104>
<pedronis> ijohnson: #8091 can be merged, right? and then backported
<mup> PR #8091: interfaces/greengrass-support: add /dev/null -> /proc/latency_stats mount <Created by dostiharise> <https://github.com/snapcore/snapd/pull/8091>
<ijohnson> sorry was a bit afk
<ijohnson> pedronis: let me look at the PR, but did it change?
<pedronis> ijohnson: ?
<ijohnson> pedronis: that PR is fine, it can be merged I wasn't sure why you were asking me if it could be merged
<pedronis> ijohnson: because I haven't looked into it at all, but you reviewed and is all green
<ijohnson> pedronis: yes it has +1 from jdstrand so it's fine
<pedronis> I tend to not merge things that I didn't even skim
<pedronis> even if they are all green
<ijohnson> ack, np
<jdstrand> I can merge it
<ijohnson> thanks jdstrand
<jdstrand> I've been told I can merge simple things like that :)
<jdstrand> ijohnson: but note, I discussed this with mv o eralier and he will cherrypick
<ijohnson> jdstrand: cool yeah I was just going to say I defer to mvo about 2.43 vs 2.44
<jdstrand> ijohnson: done. it is milestoned for 2.43 (by mvo)
<mvo> yeah
<pedronis> mvo: sorry, seems I wasn't clear in #8063, anyway I can work on it at some point soon
<mup> PR #8063: cmd/snap: implement 'snap remove-user' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
<mup> PR snapd#8091 closed: interfaces/greengrass-support: add /dev/null -> /proc/latency_stats mount <Created by dostiharise> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/8091>
<mvo> 8091 is now cherry picked
<mvo> pedronis: oh, sorry, I misunderstood
<mvo> pedronis: I can look at this too (or download) either way is fine
<pedronis> mvo: download probably needs more attention giving it seems we need to understand if we have a bug or not
<pedronis> *given
<mvo> pedronis: ok, I'm looking at this right now anyway so I will just keep doing that
<mvo> pedronis: fwiw, I also see what john sees, I don't get 206 from the cdn, only 200 with the old and the new code, investigating now
<pedronis> mvo: fun with FdSet being platform dependent in the netlink stuff, trying to see if I can avoid need +build stuff
<mvo> pedronis: uh, fun :(
<mborzecki> re
<ijohnson> hey mborzecki I ran a spread test of your branch and it passed on gce for me
<ijohnson> \o/
<mborzecki> yay :P
<ijohnson> I don't think the tests on travis have been run yet however
<mborzecki> that's ok, they'll get their chance
<ijohnson> yeah still in "received" state
<mborzecki> ijohnson: but i understand the base/modeenv branch worked for you right?
<ijohnson> it would be good to get someone else to +1 your branch and I can merge it in my PM when it goes green (hopefully ð¤)
<ijohnson> mborzecki: which PR ?
<ijohnson> 8073
<ijohnson> err
<ijohnson> #8076?
<mup> PR #8076: boot: add TryBase and BaseStatus to modeenv; use in snap-bootstrap <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8076>
<mborzecki> ijohnson: 8075++
<ijohnson> haha, I have not tried it in spread, but it worked locally with qemu before, I was going to merge master into thos PR's after the spread tests are working so hopefully we can get a real spread test of the changes
<pedronis> ijohnson: are 8075 and 8076 even landable alone, or we can only land 8077 ?
<ijohnson> pedronis: 8075 is fine because kernel= in the modeenv is not used anywhere anymore
<ijohnson> pedronis: 8076 is fine because it's just snap-bootstrap reading base_status and try_base, but nothing will write those into the modeenv until 8077
<ijohnson> so yes both of those PR's are standalone
<ijohnson> I still need a 2nd review on 8076 however
<ijohnson> 8075 could be merged today if mbrozecki's branch is green
<ijohnson> (it has 2 +1s)
<pedronis> ijohnson: my plan was to review 8076 after 8075 is in
<ijohnson> pedronis: sounds good, I am hopefully I can get 8075 in today so you could review 8076 tomorrow
<pedronis> mvo: mabye I fixed it, cross/go-build passes now
<mvo> hm, so "curl -v -L -o /dev/null  -r 1000000 https://api.snapcraft.io/api/v1/snaps/download/TJEfggNhgEJ4XKJ8o7ahsvRklz5kRK5w_29.snap" does not seems to work, it seems our cdn just ignores the range header
 * mvo is puzzled if he misses anyhing
<mvo> pedronis: oh, nice!
<pedronis> mvo: maybe ask the store people
<mvo> pedronis: yeah, asking there now
<mup> PR snapd#8069 closed: tests: build the initramfs + kernel snap for UC20 spread tests <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8069>
<mup> PR snapcraft#2914 opened: meta: ensure Application passthrough is scrubbed for snap.yaml <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2914>
<mborzecki> ijohnson: i'm logging out for today, feel free to push fixes to 8094 if needed and land it, once it's merge i'd like to investigate why there's a problem using unpacked initrd 'main' root, perhaps we're still missing something there (or just a bug in u-c-i)
<pedronis> mvo: of course it needs to do something sane even if range doesn't work
<pstolowski> pedronis, mvo i'm having failure of nested/classic/hotplug tests on 8101; i'm going to check if it regressed with master too. fwtw i see this: Feb 06 17:30:26 feb061718-477082 snapd[11297]: udevmon.go:110: udev monitor stopping timed out
<pstolowski> Feb 06 17:30:27 feb061718-477082 snapd[11478]: udevmon.go:148: udev event error: Internal error: bad file descriptor
<pstolowski> but perhaps it's shutdown code and unrelated to the test failure
<pedronis> pstolowski: that migh be a prexisting behavior
<mvo> pedronis: yeah, part of the problem is that we don't check for 206 on range so we already do the wrong ting
<pstolowski> cachio: can you check if  we're running nested tests for hotplug nightly?
<pedronis> pstolowski: I think the disconnect in udevmon might be a bit of a hammer
<cachio> pstolowski, passed 14h ago
<cachio> https://travis-ci.org/snapcore/spread-cron/builds/646683311
<pedronis> pstolowski: it might need more tweaks
<pstolowski> cachio: thanks, we're running it on 16.04 only though?
<cachio> pstolowski, 16 and 18
<pstolowski> cachio: i don't see 18 in that log, is it a separate log?
<cachio> pstolowski, 16 -> core and classic
<cachio> 18 -> core
<cachio> pstolowski, https://travis-ci.org/snapcore/spread-cron/builds/646683311#L5829
<pstolowski> cachio: was there a specific reason we don't run it on 18 classic
<pstolowski> ?
<ijohnson> pedronis: cachio: what are your thoughts on organizing the spread tests to have a dir "tests/core/..." with all the UC specific tests in there and then having tests in there specific to say uc20 just be named so like "tests/core/uc20-basic" and filter with systems: in the task.yaml ?
<pedronis> ijohnson: yes, something like that
<ijohnson> I just found a couple of tests that still are only run on uc16, but really should be run on uc18 as well as now uc20, and I think organizing the tests that way would make it less likely we run into this kind of thing for uc20 and uc22 etc.
<pstolowski> cachio: hmm maybe it was something with qemu, i don't remember anymore...
<ijohnson> I may prototype that a bit this PM
<cachio> pstolowski, checking
<cachio> pstolowski, we are running ../bin/spread -v google:tests/nightly/ google-nested:ubuntu-16.04-64:tests/nested/classic/ google-nested:ubuntu-16.04-64:tests/nested/core/ google-nested:ubuntu-18.04-64:tests/nested/core/
<cachio> I don't rememer why we are not running classic suite on 18
<pedronis> pstolowski: from those logs  it sounds like it was stuck in ReadEvent, which means the select was confused, or ReadEvent isn't quite doing what we expect
<pstolowski> cachio: yeah that's weird, it's even listed in spread.yaml under nested/classic
<cachio> pstolowski, I can add it
<cachio> pstolowski, in 1 minutes
<pstolowski> cachio: it may fail right now, i'm checking it with master
<pedronis> pstolowski: you might have to add more logging to understand what is happening
<cachio> pstolowski, added
<pstolowski> pedronis: it didn't fail on master
<pstolowski> pedronis: but i'll re-run it a couple of time with & without the changes
<pstolowski> spread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug
<pstolowski> ^ for the record
<pstolowski> cachio: thanks
<cachio> pstolowski, np
<pedronis> pstolowski: as I said it's quite possibly that is not working, consider that udevmon tests fake the underlying bits
<pedronis> pstolowski: you'll need more debuggin logs in conn.go to know what's happening
<pstolowski> pedronis: yep, i'll invesitgate, will pick it up tomorrow morning
<pedronis> pstolowski: thank you
<mup> PR snapd#8104 closed: interfaces/builtin: backport verifySlotPathAttribute (2.43) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8104>
<mup> PR snapd#8105 opened: store: detect if server does not support http range headers <Created by mvo5> <https://github.com/snapcore/snapd/pull/8105>
<mvo> pedronis: thanks so much for 8104
<mvo> pedronis: sorry that I had to open another PR but I think we need to deal with 200 vs 206 better
<pedronis> was #8080 backported ?
<mup> PR #8080: dirs: manjaro-arm is like manjaro <Bug> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8080>
<ijohnson> pedronis: mvo: are there any high priority PR's for me to review? I'm still reviewing pawel's preseed PR, but seems there are other things in motion right now that might be important to review too ?
<ijohnson> oh I guess mvo is offline now
<pedronis> ijohnson: mostly Pawel's PRs atm, and anything old that can be reviewed or things about test themselves
<ijohnson> pedronis: ack
<pedronis> ijohnson: there's quite a bit of in-progress stuff that is not yet ready for review
<ijohnson> right
 * ijohnson is waiting on many spread runs to test fixes for the uc20 spread PR
<mup> PR snapcraft#2912 closed: meta: do not prime commands with adapter == "none" <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2912>
<mup> PR snapcraft#2913 closed: spread: disable journal debug dump unless configured <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2913>
<mup> PR snapcraft#2915 opened: rust plugin: respect Cargo.lock if present in project <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2915>
<pedronis> ijohnson: I think #8105 can also be reviewed
<mup> PR #8105: store: detect if server does not support http range headers <Created by mvo5> <https://github.com/snapcore/snapd/pull/8105>
<ijohnson> pedronis: ack, I'm almost done with 7705
 * cachio afk
<roadmr> er... snapcraft...
<roadmr> You are required to register this snap before continuing. Refer to 'snapcraft help register' for more options.
<roadmr> Would you like to register 'hello-roadmr-1' with the Snap Store? [y/N]: y
<roadmr> You already own the name 'hello-roadmr-1'.
<roadmr> O_o
<ijohnson> Error: the name 'hello-roadmr-1' already owns you
<mup> PR snapcraft#2916 opened: status: implement using the new channel-map endpoint <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2916>
<sergiusens> roadmr: interesting, was that for push?
<roadmr> sergiusens: yep - it's working now, all I had to do was change the snap's version from 2020-02-06-01 to 2020-02-06-02 O_o
<roadmr> sergiusens: I'm filing a bug about license: not being validated by snapcraft; looks like if base: core18, the expected snap client to validate the license isn't found, apparently a hardcoded path
<roadmr> sergiusens: snapcraft says  "Could not find '/snap/core/current/usr/bin/snap', validation of the license string will only take place once pushed to the store."
<sergiusens> roadmr: yeah, at the time of implementation when discussed with chipaca way back, this was the only path for snapd, we probably need to consider the snapd snap now too
<roadmr> sergiusens: ok - if you don't have a bug and want one, maybe you can add a snapcraft task to this one https://bugs.launchpad.net/snapstore/+bug/1862242
<mup> Bug #1862242: license: field in meta/snap.yaml is not validated store-side <Snap Store:New> <https://launchpad.net/bugs/1862242>
<roadmr> (we need store-side validation anyway so it's up to you how to handle this snapcraft-side)
<sergiusens> roadmr: strange thing about your error though, we check the error codes and ask for registration if the result contains resource-not-found
<roadmr> sergiusens: yes, that other thing is super weird :/ but somehow I got past it
<mup> Issue core20#20 opened: Unpublish the core20 snap for i386 <Created by anonymouse64> <https://github.com/snapcore/core20/issue/20>
<mup> PR snapd#8106 opened: tests: add "core" suite for UC specific tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8106>
<mup> PR snapd#8094 closed:  tests: repack the initramfs + kernel snap for UC20 spread tests <UC20> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8094>
#snappy 2020-02-07
<mborzecki> morning
<mborzecki> driving kids to school, back in 30
<mborzecki> re
<mborzecki> git pull
<mborzecki> pff wrong window
<mup> PR snapd#7863 closed: interfaces: add uio interface <Squash-merge> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7863>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapd#8107 opened: tests/lib/prepare: use a local copy of uc20 initramfs skeleton <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8107>
<mup> PR snapd#8075 closed: boot: don't use "kernel" from the modeenv anymore <Simple ð> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8075>
<mborzecki> pedronis: hey, thanks for merging 8075, there's some conflicts in #8076 now but i'll push an update there
<mup> PR #8076: boot: add TryBase and BaseStatus to modeenv; use in snap-bootstrap <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8076>
<pedronis> mborzecki: thank you
<pedronis> mborzecki: and hi, reminder about reviewing #7588
<mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<mborzecki> pedronis: yeah, got it in my queue, wanted to push out the uc20 kernel thing first
<pedronis> mborzecki: makes sense, but we are over the of hump of getting snap-bootstrap injected/things booting
<mborzecki> pedronis: yeah, finally
<uajain> No snap packaging for Dropbox?
<mborzecki> 8076 needs a 2nd review
<pedronis> mborzecki: I'll look at it in a bit
<pedronis> pstolowski: hi, did a pass on #8102
<pedronis> thank you for it
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<pstolowski> pedronis: hey, thanks!
<mborzecki> mvo took a sick day?
<pstolowski> mborzecki: not sure about the reason, but he said he would be off today
<mborzecki> wonder if https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1861648 is snapd running xdelta maybe
<mup> Bug #1861648: When booting 20.04 an 'ld-2.23.so' process consumes 100% CPU for minutes <champagne> <focal> <performance> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1861648>
<zyga> o/
<Saviq> hey all, do you guys know if there's API to trigger builds on build.snapcraft.io?
<Lukewh> Saviq you'd need to use the launchpad API directly I think
<mup> PR snapd#8093 closed: cmd/snap-confine: detect base transitions on core16 <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8093>
<Saviq> Lukewh: right, so I'd need a recipe on LP, that we do know
<Lukewh> to answer your question directly though - build.snapcraft.io doesn't have an api :)
<Lukewh> probably should have started with that
<zyga> pedronis: good morning! did mvo decide to do another 2.43.x?
<pedronis> zyga: yes, but he is off today, there's a couple of things marked from 2.43 that are not backported yet, that we should discuss with him whether to backport or not
<zyga> aha, I see
<zyga> thanks, I'll add a launchpad milestone then
<pedronis> mborzecki: pstolowski: I think it was planned either way for him to be off, he is using a swap day from CPT
<pedronis> same as me on Monday
<zyga> pedronis: thank you for backporting uio dependencies and working on the feedback, I read the comments now
<pstolowski> ack
<pstolowski> hey zyga !
<zyga> I didn't notice the uio hotplug leftover, thanks for chasing that
<zyga> hey pawel :)
<mborzecki> zyga: hey! feeling better?
<zyga> mborzecki: yeah, no more fever, just some cough left
<zyga> mborzecki: kind of wished I was sick next week but what can you do
<zyga> looking at the list of open PRs I have this feeling: https://imgflip.com/i/3ogq6y
<mborzecki> hmmm, taken from environment.d manpage: `If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence` and we have `990-snapd.conf`
<pstolowski> pedronis: found the bug in rawsockstopper, details coming shortly
<pedronis> pstolowski: thx
 * pedronis lunch
 * zyga did first real c20 review in a while https://github.com/snapcore/snapd/pull/8103#pullrequestreview-355082288
<mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
<pstolowski> pedronis: commented on 8101
<zyga> pedronis, pstolowski: I did a pass over https://github.com/snapcore/snapd/pull/8102#issuecomment-583352987
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<pstolowski> zyga: yep, just saw it, thank oyu
<pstolowski> *you
<pstolowski> zyga: interesting remark about KeepAlive
<pstolowski> didn't know about it
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8101#issuecomment-583354904
<mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<zyga> pstolowski: yeah, golang is full of that
<pstolowski> zyga: afaiu setting non-blocking mode is not possible here until go-1.11 (see PR desc)
<zyga> pstolowski: why?
<zyga> pstolowski: I mean, we do syscall* everything
<zyga> so we can just do it too
<zyga> pstolowski: but regardless of what go provides, my comment stands, it's a system, not go, property
<zyga> pstolowski: we can use non-blocking IO without wrapping it in existing structs
<mborzecki> zyga: did land the code to parse the snap apparmor labels (or just security labels)?
<pstolowski> zyga: i don't know the details of why non-blocking is problematic, pedronis / mvo investigated this
<zyga> mborzecki: I don't recall us having such code
<mborzecki> zyga: i recall us-2 discussing the need to have such code in the context of cgroupv2, but i don't remember whether anything was written actually
<zyga> mborzecki: no, my code needs review
<zyga> mborzecki: can you look, I can iterate once it lands :/
<zyga> https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<jdstrand> zyga: fyi, that PR is high on the list. I hoped today, likely monday now
<jdstrand> zyga: it is a big one for me
<zyga> jdstrand: hey :)
<zyga> jdstrand: thanks,
<zyga> jdstrand: big note: that's still behind a feature flag
<jdstrand> so I need a big chunk of time to devote to it
<zyga> jdstrand: and I want to iterate on more {features,tests,stuff}
<zyga> jdstrand: so please keep that in mind, I just want to make progress
<zyga> jdstrand: understood (on time)
<jdstrand> zyga: I understand. code and future work is one thing, but the design is novel (to me) and I want to make sure I give your code due respect :)
<zyga> yep :)
<jdstrand> but ack
<zyga> I'm just saying there are TODOs there and I know :)
 * jdstrand nods
<jdstrand> I'm not concerned with that bit
<jdstrand> this is milestoned for 2.44
<jdstrand> I'm just letting you know I haven't forgotten about it
<zyga> sure :)
<zyga> jdstrand: given you are here, is my response to https://github.com/snapcore/snapd/pull/7614#issuecomment-580649998 sensible?
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<jdstrand> zyga: yes
 * jdstrand thumbs ups the comment
<mborzecki> pedronis: some comments in #7588, but nothing large, i can push some fixes there
<mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<mborzecki> pedronis: wdyt about https://github.com/snapcore/snapd/pull/7588#discussion_r376358272 ?
<mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<pedronis> grumble, google:ubuntu-20.04-64:tests/main/interfaces-pulseaudio
<mborzecki> heh, again?
<pedronis> mborzecki: we have context things for snaps,  I still think SnapApp is what we want
<mborzecki> ok
<mborzecki> pstolowski: is pulseaudio trying to poke bluez again?
<pedronis> mborzecki: I commented in the PR as well
<pstolowski> mborzecki: i've no idea
<pedronis> pstolowski: thanks for finding that issue out, I will try to do a pass also taking zyga comment into account later today
<pstolowski> pedronis: yw, and thanks for investigating it further
 * zyga reads about x509
<mborzecki> zyga: have headache pills ready
<zyga> mborzecki: hmm?
<zyga> are you sending a long review :D ?
<mborzecki> zyga: for x509
<zyga> ah :)
<pedronis> #8063 needs reviews, at this point both mvo and me have added code to it
<mup> PR #8063: cmd/snap: implement 'snap remove-user' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
<zyga> pedronis: just after 8100
<zyga> wrapping up
 * zyga is very happy with the "viewed" tick on gh
<mborzecki> pedronis: do you have logs from the stuck pulseaudio interfaces test?
<zyga> pedronis: doing remove-user review now
<pedronis> mborzecki: this one failed, not stuck, but yes
<pedronis> mborzecki: here, https://api.travis-ci.org/v3/job/647158169/log.txt
<pedronis> is the other jamesh PR
<mborzecki> pedronis: thx
<mborzecki> ok, let's see if the test order matters
<mup> PR snapcraft#2914 closed: meta: ensure Application passthrough is scrubbed for snap.yaml <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2914>
<mup> PR snapcraft#2915 closed: rust plugin: respect Cargo.lock if present in project <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2915>
<ijohnson> hey all o/
<zyga> good morning Ian
<ijohnson> morning zyga
<ijohnson> or afternoon :-)
<ijohnson> are you feeling better today ?
<zyga> indeed, it's half past two for me
<zyga> yeah, I think I had the easiest ride out of our bunch
<zyga> $wife took $baby to the doc to check up on her
<zyga> now that she's better and safer to handle
<zyga> $son is pretty happy to have skipped this week, now that it's just cough and no fever :)
<zyga> fever sucks, makes you useless
<zyga> just sleep all day
<ijohnson> yeah fevers are pretty bad
<ijohnson> glad to hear that you're doing better, I hope the rest of your family does likewise
<zyga> yeah, it's passing now, I only worry it will jump to $olderdaughter just as winter holidays start
<ijohnson> yeah getting sick over holidays isn't fun, I was sick the latter half of holidays this past christmas, no bueno
<ijohnson> pedronis: is it okay to add the TODO:UC20: comment you requested in 8076 to 8077 instead? 8076 is green with 2 +1s now, so would be good to merge I think :-)
<pedronis> ijohnson: yes, it's fine
<ijohnson> pedronis: ack
<mup> PR snapd#8076 closed: boot: add TryBase and BaseStatus to modeenv; use in snap-bootstrap <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8076>
<zyga> brb, door
<mborzecki> ijohnson: thanks for cleanups un #8097!
<mup> PR #8097: tests/lib/prepare: fix hardcoded loopback device names for UC images <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8097>
<mborzecki> uh meant #8094 :)
<mup> PR #8094:  tests: repack the initramfs + kernel snap for UC20 spread tests <UC20> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8094>
<ijohnson> mborzecki: yes I'm happy we have working tests now, but I'm a bit worried that it's going to lead to more timeouts though
<ijohnson> I think we should look at your firmware dropping changes ASAP
<mborzecki> ijohnson: firmare is already dropped, we can enable dropping the kernel modules too though
<ijohnson> mborzecki: oh right, well in addition to that we should probably also not even extract the firmware given how big it is, the tests are probably getting slowed down by decompressing all of that as well
<mborzecki> ijohnson: oh and #8107 should interest you
<mup> PR #8107: tests/lib/prepare: use a local copy of uc20 initramfs skeleton <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8107>
<ijohnson> mborzecki: yes I was looking at that this morning
<mborzecki> ijohnson: i think something's getting broken when the initrd is extracted by unmkinitramfs, there's a log about cpio stripping ../../ prefixes form hardlinks (?!)
<ijohnson> mborzecki: have you asked xnox about that yet?
<mborzecki> ijohnson: no, looks like he's busy with other stuff, and we have a workaround for now
<ijohnson> mborzecki: ack, I might try to add a PR which doesn't extract the firmware at least to see if that helps
<mborzecki> ijohnson: we need to extrac to get the modules (probably could hack a solution that uses the actual kernel snap modules), but i supose there may be something fishy in the way that unmkinitramfs does it
<xnox> ouch
<ijohnson> mborzecki: but we shouldn't need to extract the firmware at all should we ?
<ijohnson> (from the kernel snap that is)
<mborzecki> ijohnson: i think we could skip it, if we build the right directory structure with lib/modules/<kver> to satisfy dracut ;)
<zyga> 2fa
<pedronis> cachio: standup?
<mup> PR snapcraft#2917 opened: rust plugin: fetch correct (locked) crates during pull <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2917>
<zyga> cachio: I sent a small review for the udisks test
<ijohnson> mborzecki: I sent you an invite to colloborate on the ubuntu-core-initramfs-snap github repo
<ijohnson> so you can push to it directly
<mborzecki> ijohnson: cool, thanks!
<ijohnson> (and I merged your PR you opened as well)
<cachio> zyga, tx
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8063#pullrequestreview-355155796
<mup> PR #8063: cmd/snap: implement 'snap remove-user' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
<zyga> cmatsuoka: thanks for the replies on cryptsetup PR, I only have one follow-up https://github.com/snapcore/snapd/pull/8103#discussion_r376425353
<mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
<cmatsuoka> zyga: thanks, I'm still verifying the cryptsetup kill thing, will check that after lunch and the parents meeting at the school
<pedronis> zyga: some it is more for mvo, we are behind documenting our API
<ijohnson> cachio: any idea what might be the cause of the failure on https://github.com/snapcore/snapd/pull/8106 ?
<mup> PR #8106: tests: add "core" suite for UC specific tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8106>
<cachio> ijohnson, let me see
<ijohnson> cachio: it seems to be that the new "core" suite directory isn't getting copied over, but it only happens for uc18 and uc16 confusingly, uc20 is fine
<zyga> ijohnson: that's so weird
<zyga> ijohnson: maybe it's something unrelated, like an exclude mechanism?
<ijohnson> yeah I looked at all our excludes and couldn't find anything
<ijohnson> though note it only happens when we go to reboot, so I think it might be something with how we prepare the new image before we reflash that
<cachio> ijohnson, first time I see that, let me check a bit more
 * zyga has hot soup for lunch
<cachio> ijohnson, I am running the tests here
<cachio> ijohnson, I see that hte core20 directory is still created in tests dir
<ijohnson> hmmm interesting
<ijohnson> are you running on google or via qemu ?
<ijohnson> I wonder if it has something to do with the repack git thing we do to reduce delta when running on google
<ijohnson> cachio: ^
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8102#pullrequestreview-355216316
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
 * cachio lunch
<ijohnson> cachio: the reason that it's not copied over is due to the `-C` option we pass to rsync in setup_reflash_magic
<ijohnson> not sure what's the implications of removing that, nor why rsync following CVS (?!?!?) exclude patterns makes tests/core/ be ignored
<ijohnson> silly CVS.... https://stackoverflow.com/questions/8746419/using-cvs-exclude-in-rsync-suddenly-ignores-core-folder
 * zyga goes afk for a while
<ijohnson> it doesn't happen for uc20 because we don't use rsync for uc20, we create a tar archive instead which is extracted after the img is reflashed
<pstolowski> zyga: thanks for the review
<zyga> ah
<cachio> ijohnson, ahh, not sure, did you tried removing it?
<ijohnson> cachio: I added `--include core` and it worked on my local run, seeing what travis spread does now
<ijohnson> afk little bit
<cachio> ijohnson, nice, thanks!!
<pstolowski> can we land https://github.com/snapcore/snapd/pull/8058 ?
<mup> PR #8058: run-checks, travis: allow skipping spread jobs by adding a label <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8058>
<pstolowski> zyga: ^ do you know?
<zyga> I don't mind
<zyga> but I think it should be acked by cachio
<cachio> pstolowski, zyga checking
<pedronis> ijohnson: #8077 seems to need a merge, there's conflicts now
<mup> PR #8077: boot: enable base snap updates in bootstate20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>
<cachio> pstolowski, zyga I see this is a bit dangerous, is there any way to just allow to some people to add this labels?
<ijohnson> pedronis: yes resolving now just a few minutes
<zyga> cachio: no, it's all or nothing
<cachio> zyga, I would like to discuss it on monday during standup
<zyga> that's reasonable, let's hold it until
<cachio> just to make sure all agree with this
<pstolowski> sure
<cachio> nice, thanks
<pstolowski> cachio: mark it blocked then
<cachio> pstolowski, done
<pstolowski> thx
<ijohnson> pedronis: resolved now, I also made one more small tweak to `snap-bootstrap initramfs-mounts`, where we don't read the modeenv if the base is already mounted
<ijohnson> pedronis: what do you think of that? it makes sense to me because it removes unnecessary read/write cycles when we don't need it
<pedronis> ijohnson: makes sense, but when we get the valid kernel thing next will need to tweak again
<ijohnson> pedronis: oh right I forgot about that
<ijohnson> hmm oh well I already pushed the commit, so I will just undo that change when we get to the valid kernel thing
<ijohnson> pedronis: thoughts on what to name the modeenv setting for the kernels ? I had current_kernels but was thinking maybe something like trusted_kernels is better ?
<ijohnson> pstolowski: I approved #7705, not sure if that's ready to go in now then, but it's green now :-)
<mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<pstolowski> ijohnson: yay, thank you!
<ijohnson> pstolowski: you're very welcome
<ijohnson> pstolowski: pedronis: which is the next preseeding/services PR I should look at?
<pstolowski> ijohnson: #8046, give me a sec, i'll merge master
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<mup> PR snapd#7705 closed: o/devicestate: handle preseed in firstboot <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<ijohnson> ack, I probably won't get to it til my PM
<pstolowski> updated
<pstolowski> .. and eow. cu!
<mup> PR snapd#7983 closed: tests: adding more tests to core20 test suite <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7983>
<cachio> ijohnson, a question in #8106
<mup> PR #8106: tests: add "core" suite for UC specific tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8106>
<cachio> the rest is ok for me
<ijohnson> cachio: I didn't try "core/", I can try locally after my lunch
<ijohnson> cachio: if it works I'll update the PR
<cachio> ijohnson, nice, thanks
 * cachio afk
<mup> PR snapcraft#2917 closed: rust plugin: fetch correct (locked) crates during pull <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2917>
<mup> PR snapcraft#2918 opened: elf: ensure _GNU_VERSION_R section is of type GNUVerNeedSection <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2918>
<mup> PR snapcraft#2800 closed: introduce `--apt-mirror` build provider flag <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2800>
<mup> PR snapcraft#2819 closed: isort: automatic formatting/sorting of imports <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2819>
<zyga> cjp256: hey
<zyga> cjp256: question about python stuff
<zyga> cjp256: is isort doing something that black is not?
<zyga> cjp256: should I stick to black or is there more beyond that?
<roadmr> zyga: isort does something black does not do
<cjp256> yeah, it organizes imports.  black really just controls the spacing between them, but doesn't sort by pep8 rules
<roadmr> ... yes that :)
<zyga> I see, thanks!
<cjp256> the problem is historically is that isort does not currently fully support black formatting, so the two fight each other in some cases - they have a 5.0 release coming up which should work well together with black
<techalchemy> cjp256, you can just fix that though
<techalchemy> it's pretty simple
<cjp256> techalchemy: there was one edge case affecting snapcraft they fixed but won't be in until 5.0: https://github.com/psf/black/issues/251
<cjp256> but yeah, you can get it pretty close in config
<techalchemy> cjp256, oh that's interesting actually
<cjp256> i'm a big fan of automatic formatting, so I'm gonna reopen that PR once it lands..
<techalchemy> I never bothered looking into it but it makes perfect sense because of how the introspection works
<techalchemy> I just use # fmt: off
<cjp256> ah
<techalchemy> cjp256, https://github.com/sarugaku/vistir/blob/master/src/vistir/compat.py#L135 <- like this
 * sergiusens is not a fan of fmt: off
<sergiusens> so glad we got rid of that with our move to python "greater-than" 3.5
<techalchemy> i rather use fmt: off for a line here and there than have 0 automated formatting :)
<techalchemy> sometimes it is necessary
<mup> PR snapcraft#2919 opened: sanity_checks: fix sanity check on Windows <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2919>
<mup> PR snapcraft#2920 opened: meta: initialize Snap at once in from_dict() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2920>
<mup> PR snapcraft#2921 opened: storeapi: remove exposure of series <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2921>
#snappy 2020-02-08
<mup> PR snapd#7456 closed: usersession/client: add a client library for the user session agent <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7456>
<sdhd-sascha> I'm just testing, how i can build a custom snapcraft- and/or snapd-version, with experimental features. But i have trouble to install it, in a oneliner like that:
<sdhd-sascha> snap install --dangerous <(wget -o - https://github.com/sd-hd/snapcraft/releases/download/3.9.9-0sdhd1/snapcraft-snap-3.9.9-0sdhd1 )
<sdhd-sascha> Does anybody has an idea ?
<sdhd-sascha> /me sometimes i don't want to wait for the PRs to be merged
 * sdhd-sascha it's bash (or so) here
<sdhd-sascha> My fault.... wget has additional output, if i called it this way ...
 * sdhd-sascha back
<sdhd-sascha> what do i am wrong:
<sdhd-sascha> ```
<sdhd-sascha> # snap install --dangerous <(wget -q -O- https://github.com/sd-hd/snapcraft/releases/download/3.9.9-0sdhd1/snapcraft-snap-3.9.9-0sdhd1)
<sdhd-sascha> error: cannot perform the following tasks:
<sdhd-sascha> - Mount snap "snapcraft" (unset) (snap "snapcraft" requires classic confinement)
<sdhd-sascha> ```
<sdhd-sascha> ???
<sdhd-sascha> *awkward* sorry
<sdhd-sascha> classic is missing
<sdhd-sascha> :-)
<Cornyst> Hello all! After Looking through all the FAQs, I need to know if there is a special plug-in to CentOS Application Installer that allows it to show SNAP installed Items?
<Intruder777> Hello. I have run into an issue with one of the snaps (Rocketchatserver mongo db issue). In order to fix it I need to revert a snap to a specific revision from a specific channel. How can I do it?
<mup> PR snapcraft#2922 opened: Fix push on Windows <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2922>
#snappy 2020-02-09
<mup> PR snapcraft#2923 opened: requirements: Update PyYAML requirement to 5.3 <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2923>
