#snappy 2015-12-14
<xcub> So I plan on porting software to ubuntu using snapcraft. Can someone verify for me that snapcraft is available for all Ubuntu distributions, and not just Ubuntu Core. I am worried that I may have to install a whole new operating system just to complete a simple task.
<xcub> Also, is any snappy package created using snapcraft compatible to run in all Ubuntu operating systems. The documentation makes it look like snapcraft is exclusive to Ubuntu Core
<woodrowshen> xcub: hi, snapcraft is available via ubuntu 14.04+
<xcub> so if I package something in 15.10, it will be available fore Ubuntu Core and all other Ubuntu versions as well?
<woodrowshen> xcub: i think the snapcraft is a helper to package snap for Ubuntu core, and i'm not sure if it can available for other Ubuntu versions.
<dholbach> good morning
<Chipaca> ogra_: mo'in!
<Chipaca> ogra_: do you remember, when I pulled the "mbuahaha now every file we write uses AtomicWriteFile" malarkey?
<Chipaca> ogra_: you had to scramble to clean up my mess
<Chipaca> ogasawara__: do you remember what it consisted of? was it just watchdog?
<Chipaca> ogra_ i mean
<Chipaca> ogra_: because now we need the same thing done for 15.04 :-)
<ogra_> Chipaca, hmm, i thought 15.04 had it
<Chipaca> ogra_: from what we can tell it does, but as testing this is slow (needs image build), i thought i'd check with you first
<Chipaca> ogra_: the change in ubuntu-core-config is there
<Chipaca> ogra_: was there also a change in the livecd thing?
<ogra_> it is in live-build/ubuntu-core/hooks/08-etc-writable.chroot ... let me check the PPA package
<JamesTait> Good morning all; happy Monday, and happy Monkey Day! ð
<ogra_> Chipaca, xenial vs 15.04 ... looks identical to me http://paste.ubuntu.com/14002856/
<Chipaca> ogra_: diff agrees with you
<ogra_> Chipaca, so whats the symptom you see on 15.04 ?
<Chipaca> ogra_: dinosaurs everywhere! also the air is much more oxigen-rich
<ogra_> lol
<Chipaca> ogra_: seriously though, ricmm and mvo know more. All I know is they need this fix.
<ogra_> well, this fix is there ...
<Chipaca> ogra_: the "use atomic writes everywhere" was not in 15.04
<ogra_> the question is ... are others missing ... i guess
<Chipaca> ogra_: the artifacts were
<Chipaca> that is, livecd and ubuntu-core-config had the right bits
<Chipaca> but we never backported the fix until now
<Chipaca> the _snappy_ fix i mean
<ogra_> well, the watchdog files are definitely prepared for atomic
<Chipaca> yep
<Chipaca> and timezone is a symlink already
<ogra_> like hostname
<Chipaca> yep
<ogra_> Chipaca, mvo_ had an issue with upgradin the initzrd on the weekend ... i belive thats another incarnation of our s-i delta generation bug (the file is always called initrd.img so s-i doesnt consider it for a delta)
<ogra_> this is why sergio once switched everything to named files (which exploded i other ways)
<ogra_> *in
<ogra_> in that light ... the fix could be there but not applied
<ogra_> (oops, my brain silently moved on ... i mean the fix that mounts /etc early in the boot (and makes the files actually writable)
<mvo_> ogra_: either that or a test artifact from me hacking up the system
<ogra_> well, disassemble the running initrd, that will tell
<kyrofa> Chipaca, port negotiation isn't done yet, correct?
<Chipaca> kyrofa: correct. Existence of a ports stanza is used to order services, nothing more
<kyrofa> Chipaca, "order services?" I don't understand
<Chipaca> kyrofa: if your snap says it has an external port, it's started after wait4network
<kyrofa> Ahh
<kyrofa> Chipaca, okay thank you! :)
<kyrofa> Chipaca, one more question: assuming you've thought at all about port negotiation, if I setup my .snap to have the port configurable via snappy config, would I be most of the way there when snappy supports negotiation?
<Chipaca> kyrofa: there's too many open questions for me to hazard an answer i'm afraid
<Chipaca> kyrofa: do whatever is easiest for you today
<kyrofa> Chipaca, understood, thank you
<plars> elopio: did something break with the bbb images? or is it just me? All of my runs seem to be failing on bbb lately
<ogra_> how
<elopio> plars: failed to flash? The channels are giving a hard time to udf.
<plars> elopio: no, failed to boot
<ogra_> yeah, you need /stable appended to the oem name
<plars> ogra_: oh?
<ogra_> but that would fail your build already ... not the boot
<plars> ogra_: so --oem beagleblack/stable
<ogra_> yeah
<ogra_> but that changed a week ago or so
<plars> ogra_: that's about how long it's been failing
<plars> let me try
<ogra_> well, but why does it not fail the build then
<ogra_> u-d-f should bark loudly
<plars> ogra_: not sure, I'll check on that
<kyrofa> elopio, sergiusens you guys are over a half hour late, come on now
<jdstrand> kyrofa: regarding https://launchpad.net/bugs/1466234, the remaining bits the snappy foundations team said they'd handle. mvo, do you recall that? ^
<ubottu> Launchpad bug 1466234 in ubuntu-snappy (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged]
<sergiusens> kyrofa, lol
<sergiusens> kyrofa, are we doing it now?
<kyrofa> sergiusens, yeah, hop in!
<sergiusens> elopio, ^
<sergiusens> kyrofa, let me get some water and I'll join
<kyrofa> sergiusens, sounds good :)
<plars> ogra_: it doesn't seem to complain at all with --oem beagleblack
<plars> https://www.irccloud.com/pastebin/jh4UVv7W/
<ogra_> weird
<ogra_> i definitely need it here
<elopio> fgimenez: give me a couple of minutes.
<fgimenez> elopio, ok i'm not yet there either :)
<elopio> fgimenez: I am now :)
<liuxg> in snappy, why do use "sudo" without inputting a password?
<stevebiscuit> sergiusens, mvo_: https://code.launchpad.net/~stevenwilkin/webdm/use-latest-snappy/+merge/280460
<stevebiscuit> ^^ managed to get webdm building against latest snappy, AppArmor stuff is ropey though
<mvo_> stevebiscuit: nice! good stuff. I need to leave for dinner soon no proper review from me just yet ut from a quick glance it looks good
<stevebiscuit> mvo_: cheers!
<stevebiscuit> mvo_: the next step in getting webdm using the snapd API is to decide wether to extend the client lib in snappy to handle the application endpoint and use that in webdm or to manage all the HTTP-over-unix-socket within webdm itself
<ogra_> stevebiscuit, mvo_, could we make sure to get webdm on arm64 ? (i noticed it isnt in snappy search output)
<beuno> ogra_, we'll likely need the launchpad builders set up for that
<beuno> it's WIP by cjwatson
<ogra_> oh
<beuno> we haven't shipped stevebiscuit any hardware yet
<ogra_> we should ;)
<beuno> if we don't, we might actually fix things properly!
<kyrofa> jdstrand, alright thanks for the update. mvo, safe to assume no progress there?
<plars> ogra_: elopio: So y'all are able to boot from the sd with current snappy on bbb? Out of curiosity, have you tried booting with the s2 button held down so you actually load the bootloader off of the sd?
<ogra_> plars, i havent booted a BBB in a while, but i cant build any imae here without appending /stable to the oem
<ogra_> how exactly does your boot fail ?
<mvo_> kyrofa: no progress on #1466234 no
<mvo_> jdstrand: -^
<kyrofa> Alright, thanks mvo_ :)
<mvo_> kyrofa: will you fix it? if so \o/
<jdstrand> mvo_: thanks
<marchesini> hi! im trying do some stuff on the raspberry pi with ubuntu core, but the new package manager "snappy" doesn't have the package apache, lighhtp, glassfish or mysql... how can i install this apps on my raspb?
<kyrofa> mvo_, I'd be happy to. Are you in tomorrow? Maybe we can sync real quick about it?
<kyrofa> (tomorrow I mean, I know you're essentially out today)
<mvo_> kyrofa: unfortunately not, we could catchup quickly when I'm back later, I play hockey now
<kyrofa> mvo_, that would be great if you can swing it :)
<mvo_> kyrofa: I ping you when I'm back :)
<plars> ogra_: elopio: This is what I'm seeing: http://paste.ubuntu.com/14008126/
<kyrofa> mvo_, excellent, talk then. Enjoy hockey!
<mvo_> I will, thanks
<sergiusens> stevebiscuit, will check in a bit
<ogra_> plars, well, thats clearly the kernel
<stevebiscuit> sergiusens: appreciated!
<marchesini> before when i work with apt-get i only need write apt-get install apache2 on the console, and all will be done. but now with this snappy the things is little bit confusing
<ogra_> marchesini, you would have to create a snap package that contains what you need
<marchesini> ogra_, you mean that i need download the DEB packages of apache and rebuild with the snappy format?
<ogra_> no, there is a tool that can do it for you ...
<ogra_> but you wouldnt just build an apache snap
<marchesini> i see on my raspb that it have the dpkg, i can install deb packages with dpkg?
<ogra_> but rather work a little more project oriented ... i.e. you want to run a forum that requires to use apache, mysql, php, then you would build a forum.snap package that contains all of them and creates a good default setup
<ogra_> not in snappy, no
<ogra_> there is work going on that supports a mode where you can use debs too, to have an environment to create snap packages more easily
<ogra_> but you wont be able to use deb right inside snappy itself
<marchesini> well, if i understand what you say, the snappy manager have built for newbies to install a full environment on the system. like if i need wordpress, then someone already build a package with mysql, php, apache and wordpress...
<marchesini> it's a new way to do common things
<marchesini> but I keep thinking that this system should have a package manager like apt-get
<elopio> plars: is that bbb rolling edge #255?
<plars> elopio: yes
<elopio> plars: yes, Fixing recursive fault but reboot is needed. Please report a bug.
<plars> elopio: are you able to reproduce that? or is it something funny with my setup?
<elopio> plars: I've just reproduced it.
<plars> elopio: will do, one sec and I'll send you the link
<plars> elopio: https://bugs.launchpad.net/snappy/+bug/1526027
<ubottu> Launchpad bug 1526027 in Snappy "[BBB] Fixing recursive fault but reboot is needed!" [Undecided,New]
<sergiusens> elopio, can you explain this to me? it works locally https://travis-ci.org/ubuntu-core/snapcraft/jobs/96815858
<Rob1507>  Hello there. Anyone online
<Rob1507> ?
<beuno> Rob1507, sure what's up?
<Rob1507> I am beginner and want to use Snapcraft. I need to choose go project but don't have idea which one is fine. Can you help?
<beuno> Rob1507, we can try. What part are you stuck on?
<Rob1507> beuno, I understood everything, but it is hard to find a good project to try everything by myself.
<beuno> Rob1507, you'll need to be more specific
<beuno> I don't really know what to help you with
<Rob1507> beuno, Can you suggest a project that is like ones in snapcraft-examples?
<wililupy> Can we not "setcap" in snappy?
<jdstrand> sergiusens: hey, so I'm preparing a review tools update for xenial that understands all snaps
<jdstrand> sergiusens: we discussed me putting them in tools-proposed, but I want to make sure I put them in the right place. iirc, snapcraft for all snaps isn't being put everywhere. can you clarify?
<mvo> kyrofa: uh, I forgot to ping you, sorry. I'm here now (for ~45min or so)
<jdstrand> mvo: hey, do you want me to approve canonical-pc.canonical?
<jdstrand> mvo: and canonical-linux-pc.canonical? (I thought kernels were going to start with linux-...)
<jdstrand> mvo: note, your kernel snap should be using 'architectures'
<jdstrand> pindonga: hey, fyi, uploaded review tools 0.35 to xenial. this is at r562. there are a couple of very minor fixes in there. fyi for a pull at your convenience
<sergiusens> jdstrand, snapcraft for all snaps is going to be xenial only
<codeofdusk> Need help packaging something for Snapcraft, not sure about best practices.
#snappy 2015-12-15
<xcub_> Hi, I have a question about using snapcraft if anyone wants to help
<tzununbekov> Hi all. We have package that mounts Btrfs volume in SNAP_DATA_PATH. When we update this package, all data is copied from old data path to new, but volume is still mounted in old one. Is there any way to handle it?
<tzununbekov> asac, Chipaca, ogra_ this causes a doubling of used disk space
<dholbach> good morning
<fgimenez> good morning
<JamesTait> Good morning all; happy Tuesday and happy Cat Herders Day! ð¼
 * Chipaca is happy not being a car herder
<davmor2> Chipaca: car herder is just a posh name for a carpark attendant right
<Chipaca> davmor2: i read it as "manager"
<Chipaca> davmor2: so yes
<tzununbekov> Hi all. We have package that mounts Btrfs volume in SNAP_DATA_PATH. When we update this package, all data is copied from old data path to new, but volume is still mounted in old one. This causes a doubling of used disk space. asac , ogra_ , Chipaca , is there any way to handle it?
<Chipaca> tzununbekov: at the moment unfortunately no, but there will be soon
<ogra_> i guess only by mounting your volume one level up (which you cant do from your snap i guess)
<ogra_> if you work on a standalone device you could also just label your btrfs volume "writable", copy the actual writable partition content into it and drop the label from the original writable partitions
<ogra_> -s
<Chipaca> tzununbekov: that is, there is going to be a place where you can put things to not have them copied over, but it's not there yet
<ogra_> right
<ogra_> in the current setup you can only mangle stuff on a system level to make it work
<ogra_> (it ould still be duplicated but you have both copies in your btrfs)
<ogra_> *would
<tzununbekov> ogra_, as workaround, we are mounting btrfs into /mnt but we think it's not Snappy way :)
<ogra_> well, the snappy way is very flexible :)
<ogra_> if you build an appliance i guess /mnt is suitable
<tzununbekov> Chipaca, when we can wait for this feature?
<ogra_> if you build a snap package just for the store, expecting /mnt is indeed imposssible
<Chipaca> ogra_: but then so is mounting something
<ogra_> right
<tzununbekov> ogra_, is there any way to have our own store for appliance if we need updates?
<ogra_> you can have some sub-store for your product, yes
<ogra_> beuno is your man for this :)
<tzununbekov> nice, where can we read more about sub-store thing?
<beuno> tzununbekov, hi!  Yes, I can hook you up with some of our commercial folks to help you with that
<beuno> tzununbekov, drop an email to: maarten.ectors@canonical.com
<beuno> he'll get you sorted
<tzununbekov> beuno, sub-store is commercial product? :D
<beuno> tzununbekov, it depends on what you need from it. I'd suggest you discuss it a bit and see what the options are
<beuno> we generally prefer software is widely available for all devices, but if someone wants to build a self-contained product we have some tools to help them out
<tzununbekov> thank you, guys, we should discuss it in our team :)
<jdstrand> sergiusens: re xenial/all snaps. ok, well, the review tools that understand all snaps is in xenial now. if you wnat them somewhere else too, let me know
<sergiusens> jdstrand, no worries, and I am off today all through Wednesday and Thursday so I have no rush at all :-)
<stevebiscuit> Chipaca: just a small MP if you could be so kind - https://code.launchpad.net/~stevenwilkin/webdm/snaps-always-have-origins/+merge/280595
 * Chipaca looks at the mp
 * Chipaca looks at stevebiscuit 
<Chipaca> stevebiscuit: I don't know enough about webdm to know whether this will blow up all over the place or not
<Chipaca> stevebiscuit: are you working on webdm now? that is, if this blows up, are all the pieces yours?
<beuno> Chipaca, he is
<stevebiscuit> :D
<Chipaca> i'm happy to rubber stamp this; i'd be happier if sergio could give it a look at least at first
<Chipaca> but he's not around and i don't want to block steve
<beuno> Chipaca, to be fair, nothing breaks until a snap is uploaded
<Chipaca> exactly why i'm so lackadaisical about this :-)
<stevebiscuit> Chipaca: ta. Sergio had commented yesterday about snaps always having origins which would eventually become assertions
<kyrofa> elopio, sorry, computer crash
<plars> fgimenez: elopio: I tried a merge of the no_init and the gocheck_list branch here, and it doesn't seem to work right for me, but could be something I'm messing up. Also I'm just running it on my local machine, since all I'm trying to do right now is get a list of tests
<Chipaca> stevebiscuit: while the snaps themselves have an origin in the theoretical sense, the system as it stands doesn't always use that origin to address things, and some parts will break if you try to use a full name where a bare name is expected
<Chipaca> stevebiscuit: if webdm is abstracting that stuff away, then good job :-)
<plars> elopio: first, go test -c ./integration-tests/tests -o ./integration-tests/bin/integration.test doesn't seem to produce a binary in ./integration-tests/bin, it just produces ./tests.test instead
<Chipaca> stevebiscuit: the REST API also hides that, and only shows full names (or tries to!)
<Chipaca> stevebiscuit: so it's the right move _even if it breaks things right now_
<plars> elopio: which does seem to show me help, so at least the no_init bits seem ok, but trying to run it with -gocheck.list or -check.list gets me nothing, it seems to try to run instead
<Chipaca> stevebiscuit: but you still get to keep the pieces :-)
<Chipaca> stevebiscuit: also, as you move to the rest api, please do poke me if anything doesn't work as expected, or is awkward, or could be cleaner or better or ...
<fgimenez> plars, about the -o flag not working, that might be related with the go version, iirc it have being added more or less recently
<stevebiscuit> Chipaca: will do. Cheers for the background. I'm happy to keep tracking things and picking up the pieces to get webdm to 16.04 :)
<fgimenez> plars, does "./tests.test -gocheck.list" work?
<plars> fgimenez: not as far as I can tell, it seem to try to start executing tests
<fgimenez> plars, it seems that not all the changes proposed have been merged then
<fgimenez> plars, you should have in place the changes from the two branches
<plars> fgimenez: all I did was take a current branch of trunk, and merge those two branches from elopio
<fgimenez> plars, that should be enough, can you check if integration-tests/testutils/runner/runner.go, integration-tests/tests/base_test.go and integration-tests/testutils/common/common.go have the proposed changes?
<plars> fgimenez: yes, they are all there
<elopio> plars: cd integration-tests/tests && go test -check.list
<elopio> also go test -c ./integration-tests/tests/ && ./tests.test -check.list
<elopio> both work here.
<plars> elopio: flag provided but not defined: -test.list
<elopio> plars: -check.list
<plars> elopio: could this all be because I'm using go from trusty instead of something newer?
<elopio> fgimenez: hello! I have small branches for you.
<elopio> plars: yes, that could be a problem.
<plars> elopio: with -check.list it just gives me a lot of test failures, seems to try to run
<plars> elopio: which are you using then? the one from wily?
<elopio> plars: wily and xenial.
<plars> ok, I'll try with a newer version after the standup, thanks
<plars> elopio: is this something to do with go itself? or gocheck? or what?
<elopio> plars: I don't know, I haven't tried it on trusty. I'm just saying that it could be your machine, because it's working here.
<elopio> plars: let me know how it goes in x for you.
<plars> will do
<Chipaca> plars: i think there's a ppa with trusty stuff you can use if you need to
<Chipaca> mvo knows more but he's away today and tomorrow
<Chipaca> plars: basically, everything changed, from go to libraries
<Chipaca> so a lot of backports
<Chipaca> i think right now there's a build failure in trusty because of crypto moving
<Chipaca> but i haven't checked
<fgimenez> elopio, ok, i have a couple of them for you too :)
<elopio> fgimenez: I'm looking at them.
<elopio> fgimenez: https://github.com/testing-cabal/subunit-go/pull/3
<elopio> fgimenez: https://github.com/testing-cabal/subunit-go/pull/4
<elopio> fgimenez: get yourself a smiley sticker for that urltrigger.
<fgimenez> elopio, yes, it will be useful in terms of resource usage, and also the reports for the image builds will be more meaningful
<elopio> fgimenez: and I'm not sure if you saw the ping here: https://github.com/ubuntu-core/snappy/pull/257
<elopio> I hope I didn't duplicate your work.
<fgimenez> elopio, sure http://162.213.35.179:8080/job/stress/ i was waiting until we have that straight line long enough :D
<elopio> woot
<elopio> fgimenez: I did some runs yesterday and got permission error on docker ifconfig. I'm glad that doesn't seem to be happening in there.
<fgimenez> elopio, the ubuntuFan suite is excluded in that executions using the tag
<elopio> fgimenez: so when you are happy with the stress testing, you'll land the PR and enable the comments in github??? ^_^
<fgimenez> elopio, i think so, i wanted to coordinate with you, but we are ready to go
<elopio> fgimenez: go for it! I'm picturing an image of you pushing a huge red button.
<elopio> fgimenez: I'll try to reproduce the fan problem and report a bug if it's still happening.
<Chipaca> elopio: we could get fgimenez a http://www.amazon.co.uk/dp/B004D18MCK
<fgimenez> elopio, for doing the PR thing properly we should create a bot user in github, and one of the owners should add it as a collaborator in the project
<fgimenez> Chipaca, elopio please!
<elopio> +1, he's earned it.
<elopio> fgimenez: Chipaca is owner.
 * Chipaca owns ALL the things
<fgimenez> Chipaca, elopio ok, any github user will do, you should send me the username and pass to put them in jenkins, once the user is a collaborator of the project all should be working
<fgimenez> Chipaca, elopio i can create the user, but perhaps the email should be one owned by the team? also i'm not good with bot names :)
<elopio> Chipaca: who's your favourite robot?
<Chipaca> elopio: what's this robot doing?
<Chipaca> elopio: 'm-o' might be a bad github name :-)
<elopio> Chipaca: triggering jenkins runs and reporting the results back.
<elopio> m-o is great :) Already taken.
<elopio> fgimenez: lets call it snappy-m-o.
<Chipaca> or snappy-bo
<elopio> I'm not sure if that's a joke or you like a robot called bo.
<Chipaca> elopio: nah, it's just a diminutive suffix (which sorta sounds like "bot")
<fgimenez> Chipaca, elopio snappy-bo then? about the email, should i put Chipaca's? or snappy-internal? this is important in order to be able to reset the password
<elopio> fgimenez: I'm creating snappy-m-o. I'm using the u1test@canonical.com email.
<fgimenez> elopio, ok thx! send me the pass when you have it
<elopio> Chipaca: please add it to the org https://github.com/snappy-m-o
<balloons> is anyone about who might be able to help review some snapcraft packages and provide help and insight?
<elopio> balloons: shoot. kyrofa and I might be able to help.
<elopio> and if we can't, sergio comes tomorrow.
<Chipaca> elopio: as a contributor, or as a member?
<kyrofa> balloons, yeah we're here :)
<Chipaca> elopio: if the former, to what project?
<balloons> excellent. So I've been helping a couple students package some go applications with snapcraft. But click-review tools is failing them due to missing hooks. Let me give you the link
<kyrofa> balloons, alright
<balloons> Also, my own personal question. I don't see anywhere in the guides on how to test a snap package you create. I was thinking of copying it to my snappy installation and installing it, but is there a recommended way?
<balloons> ohh.. I just now see Sideloading your snap
<kyrofa> balloons, yeah I just sideload into a virtualized install
<balloons> the first is here: https://github.com/RGA15071999/martini-gorm-snapcraft
<elopio> Chipaca: it must have push rights, so it needs push & pull rights on the org.
<kyrofa> balloons, although we're adding a "try"
<Chipaca> elopio: you can push as a collaborator, you don't need to be an owner, but it's per-project instead of per-org
<balloons> xcub, feel free to ask questions as well. These folks know more than me :-)
<Chipaca> elopio: hence my question as to on what do you want it to operate
<elopio> Chipaca: yes, collaborator to snappy.
<kyrofa> Hey xcub :)
<balloons> can you link to your source so they can view it also?
<elopio> no need to make it owner.
<xcub> https://github.com/trustmaster/gochat
<balloons> xcub, right, but where's your yaml file
<fgimenez> Chipaca, elopio it's explained here https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
<fgimenez> Chipaca, elopio the hooks have been already set up, no need for administrator rights
<xcub> i'm on my chromebook right now and haven't pushed it to my repository, but all it really is is just a single parts: with plugin: go and source: https://github.com/trustmaster/gochat
<Chipaca> fgimenez: so what do i need to do?
<kyrofa> balloons, xcub and if I understand correctly, the .snap builds fine but click-review doesn't like it?
<fgimenez> Chipaca, just invite snappy-m-o to join as collaborator, it should receive an email to confirm
<balloons> kyrofa, yes that's correct. The review gives ERROR: could not find required 'hooks' in manifest:
<kyrofa> Hmm... yeah we've been moving away from click underlying snappy
<balloons> ohh, what do i need install for snappy-remote? snappy-remote: command not found
<kyrofa> elopio, should the click review tools still be working for snappy?
<Chipaca> fgimenez: there, i think
<elopio> yes, mail received.
<Chipaca> kyrofa: yes, they should
<elopio> kyrofa: yes.
<Chipaca> kyrofa: you might need a very recent one though
<jdstrand> zyga: hi! fyi, I'm starting to create the agreed to capabilities. My plan is to simply upload ubuntu-core-security with all the new ones and the renamed existing ones, with symlinks from the old-named ones to the renamed ones, ideally today. This will allow people to use 'caps' in the current yaml format for everything
<kyrofa> balloons, snappy-remote should be in here: https://launchpad.net/~snappy-dev/+archive/ubuntu/tools
<jdstrand> zyga: and we can transition away from the symlinks after the holidays
<elopio> balloons: what's your ubuntu version?
<balloons> xenial, with no snappy ppa's
<jdstrand> zyga: I think in this new world it makes sense to change the paths to not have the paltform version in the path, but I don't want to change that before the holidays and we can discuss that later
<jdstrand> tyhicks: (fyi my last 3 comments)
<zyga> jdstrand: hi
<elopio> balloons: if you want to run the snaps in 15.04, you need to generate them in vivid.
<zyga> jdstrand: that sounds good to me
<balloons> elopio, sure, but I didn't make the snap I want to run, heh
<elopio> balloons: I do it in an lxc.
<zyga> jdstrand: I'm proceeding with capability type system, with plugs for apparmor, seccomp, dbus and kernel capabilities
<balloons> elopio, ack.
<zyga> jdstrand: I'll show you what I have tomorrow
<elopio> balloons: right, just saying... :)
<zyga> jdstrand: (I've manually migrated the old bool-file type)
<elopio> I'll give it a try.
<zyga> jdstrand: I'm also working on a way for us to cooperate around the source code
<jdstrand> zyga: cool. I figured, the fewer code changes that need to be coordinated before the holidays, the better. that way, you can focus on code and I can policy. you can depend on where stuff lives for now, and we'll adjust after the holidays
<balloons> Chipaca, kyrofa, so how can we know what metadata is missing? the review tools don't really say
<jdstrand> zyga: ack, sounds fine
<elopio> balloons: I get Issues while validating snapcraft.yaml: 'icon.png' is not a 'icon-path'
<Chipaca> ummm
<Chipaca> wait, you're running review-tools on snapcraft.yaml?
<Chipaca> that doesn't sound right?
<kyrofa> elopio, is that a 2.0 thing?
<elopio> balloons: that's a weird way to say that you need an icon.png in the repo.
<ogra_> elopio, "touch icon.png"
<ogra_> :)
<elopio> right, or that ^ :)
<zyga> jdstrand: note that I'm still not sure gustavo will agree to standalone capabilities (as in, not baked into snappy)
<zyga> jdstrand: though that will have to wait till next month since everyone is shutting down
<jdstrand> zyga: you mentioned apparmor and seccomp as distinct things. today they are two things that are referenced with a single name (I know you know that). I bring this up because if they are distict as I understand your suggestion (as opposed to being combined in one 'security policy' capability), then perhaps that makes things more complicated
<jdstrand> zyga: also, if we ever decide to change/add to the security mechanisms, then the names 'apparmor' and 'seccomp' might not make sense
<jdstrand> zyga: food for thought-- all this can be worked out after the holiday too
<zyga> jdstrand: they are only distinct as in concepts
<zyga> jdstrand: it's all one thing behind each capability type
<jdstrand> ok, cool
<zyga> jdstrand: I haven't looked at capabilities (linux) yet
<zyga> jdstrand: are they somehow baked into apparmor?
<zyga> jdstrand: (dbus is standalone from what I understand)
<jdstrand> apparmor mediates linux capabilities, yes
<balloons> Rob1507, so elopio is saying you need an icon.png
<jdstrand> I think you can ignore them for now
<elopio> hello Rob1507
<elopio> after adding the icon, I could generate the snap.
<Rob1507> hello elopio
<elopio> I am running xenial, so I'm doing the build in a vivid lxc.
<Rob1507> yeah
<Rob1507> elopio, because I haven't uploaded icon :D
<Rob1507> I was able to generate it at home, because icon was in place
<zyga> jdstrand: that sounds good, thanks
<jdstrand> zyga: dbus is a little muddier. apparmor mediates dbus, but dbus bus policy (separate from apparmor) needs to be set up first
<elopio> Rob1507: cool. So when are you getting the review tools error?
<kyrofa> elopio, do the review tools pass after that, then?
<zyga> jdstrand: yes, that is my understanding
<zyga> jdstrand: from my POV, there's a bit of code that knows how to do that given some template that's associated with the type
<zyga> jdstrand: the language in the template is different but that's all
<Rob1507> elopio, some kind of NodeJS errors I think.
<elopio> kyrofa: nop.
<Rob1507>  elopio, you mean software center errors right?
<jdstrand> zyga: sounds good
<balloons> xcub, feel free to just you pastebin.com to paste your yaml file and share it too
<elopio> Rob1507: hum, not trying anything related with software center here. I mean that I see your error now
<elopio> http://pastebin.ubuntu.com/14029192/
<balloons> elopio, right, that's what i got.
<xcub> this is my yaml file: http://pastebin.com/0eMUYzDq
<elopio> balloons: Rob1507: that doesn't prevent you to install the generated snap.
<elopio> it should pass, so we probably got snapcraft out of sync with the reviewer tools.
<elopio> Rob1507: now what you are missing is a binary or a service.
<elopio> hello xcub
<fgimenez> Chipaca, elopio something is wrong, snappy-m-o should have write access to the repo http://paste.ubuntu.com/14029244/
<elopio> xcub: I could also generate a gochat snap with your yaml, after adding the icon.
<plars> elopio: so go 1.5.1 in wily doesn't seem to be new enough either, or else something else is wrong
<xcub> i could generate a snap as well, its just that the ubuntu software center rejects it due to some json error
<plars> elopio: I noticed that I get different (but still failed output) if I do not only -gocheck.list but -gocheck.vv, so it's at least catching args
<xcub> And I don't know anway to test the validity of the package
<Rob1507> elopio, the same thing is for me
<fgimenez> Chipaca, elopio if just giving write access to the repo is not possible (not sure about how to do this) adding the bot as a member of the organization worked fine for me in the tests
<Chipaca> fgimenez: elopio: try this way?
<Chipaca> (invitation pending)
<Rob1507>  elopio, can you see which binary or service is missing
<elopio> Chipaca: fgimenez: accepted.
<Chipaca> fgimenez: try now?
<balloons> xcub, Rob1507 install click-reviewers-tools if you want to run the review on your snaps
<elopio> Rob1507: no, I mean that for your snap to do something useful, it needs to expose a binary or service.
<fgimenez> Chipaca, elopio so cute! :D https://github.com/ubuntu-core
<xcub> what do you mean by expose a binary or service?
<Rob1507> elopio, If i want to snap a number converter program, which service i need to expose?
<elopio> xcub: Rob1507: take a look at https://github.com/ubuntu-core/snapcraft/blob/master/examples/godd/snapcraft.yaml
<elopio> see how it defines a binaries section, and in there it tells how to execute the program.
<elopio> without that, the snap files will be installed but there will be nothing to run.
<Rob1507> elopio, It makes sense, I will take a look now :)
<elopio> balloons: I'm not sure what is this about the software store.
<elopio> there is a bug somewhere with the review, clearly, but I can upload the snap to myapps.
<xcub> ohhh, so after I run snapcraft the first time, I can take a look in the snap directory and see where the binary is, the update the .yaml file to where it is?
<elopio> ahh, there I see the json error.
<elopio> okay, I'll report the bug.
<Chipaca> fgimenez: is it working?
<balloons> elopio, I asked them to upload the apps to myapps for publishing
<fgimenez> Chipaca, yes, it can connect :) https://github.com/ubuntu-core/snappy/pull/253, here, clicking in "Show all checks" there's a new "integration test" entry written by the bot
<elopio> Rob1507: xcub: balloons: once you add the binary, the click review passes.
<elopio> so the bug is that the error message when you don't define a binary is terrible.
<Chipaca> fgimenez: woop woop
<fgimenez> Chipaca, we'll see it working with the next PR, including a link to the jenkins job in the VPN
<Rob1507> elopio, sorry for that
<elopio> Rob1507: hey, not your fault at all.
<elopio> thanks for finding a bug.
<xcub> thank you for your help, elopio.
<plars> elopio: fgimenez: this is what I get: http://paste.ubuntu.com/14029558/
<elopio> plars: right, it's running the setup for you. Give me a second to set it up in wily again.
<elopio> dholbach: kyrofa: Now we have some docs about python and java in parts.md, and docs about ros in ros.md.
<elopio> should we put all of them in parts.md, or separate all of them in different files?
<dholbach> elopio: I think if we have more content for a particular part we can move it into its own file(?)
<dholbach> elopio: the bits about java and python looked to me like they only illustrated what parts can look like
<dholbach> so like an extension of the article
<dholbach> that's also how it was structured in the app developer manual
<dholbach> (where I stole the docs from :-))
<elopio> dholbach: that makes sense. ros is too big to put it in there.
<dholbach> yep
<dholbach> all rightie... I call it a day - see you all tomorrow :)
<kyrofa> elopio, yeah that would make for a massive file, especially as we have more documented plugins
<elopio> plars: this is on wily: http://paste.ubuntu.com/14030135/
<kyrofa> elopio, can you take another look at https://github.com/ubuntu-core/snapcraft/pull/163 when you're able? It should be ready to go-ish
<elopio> kyrofa: sure, I'm just missing to review the tests. I'll do that after lunch.
<elopio> kyrofa: I'm +1 on landing it, but I'm not sure if Sergio's comment meant he wanted to give it a full review.
<kyrofa> elopio, ah right, forgot about that
<Rob1507> elopio, sorry, but can you just remind which package I need to use for review?
<elopio> Rob1507: install click-reviewers-tools, and then run click-review /path/to/file.snap
<Rob1507> elopio, ok thanks
<Rob1507> elopio, and what result should I have?
<Rob1507> pass?
<elopio> Rob1507: yup, pass.
<elopio> then when you upload to myapss, it will pass too. It's the same tool they use to check.
<Rob1507> elopio, wonderful, thanks for great help ^_^
<elopio> Rob1507: np. Thanks to you.
<plars> elopio: so did you have to do something different?
<plars> elopio: doing it that way, for me, gives me exactly the same as the pastebin I sent earlier
<Rob1507> elopio, can I ask something?
<kyrofa> Rob1507, you never need to ask :)
<kyrofa> Rob1507, rather, ask to ask, heh
<Rob1507> kyrofa, I want to port a go app, but cannot find any application that may be useful. Can you suggest one?
<kyrofa> Rob1507, just any go app? Oof
<kyrofa> Rob1507, when you say "port," do you mean package as a .snap?
<Rob1507> kyrofa,
<Rob1507> kyrofa, Yes, creating .snap
<Rob1507> kyrofa, I have done one. It is working but it was testing program. I want to take one that may be useful for others
<kyrofa> Rob1507, I don't have one off the top of my head, but it might be useful to look at the trending GitHub repos written in Go: https://github.com/trending?l=go
<Rob1507> kyrofa, I look at them. Actually I choosed test program from there :D . What do you think, may goplay be useful?
<Rob1507> it is html5 player
<kyrofa> Rob1507, I've not seen that one
<kyrofa> https://github.com/otium/ytdl might be useful
<Rob1507> kyrofa, great suggestion, thanks :D
<kyrofa> Rob1507, sure thing
<plars> elopio: I also tried putting it on snappy and running it from there, I still get the same errors
<plars> elopio: do I need to set up this json config file first for it or something? It complains a lot about that
<Rob1507> kyrofa, https://myapps.developer.ubuntu.com/dev/click-apps/4184/
<kyrofa> Rob1507, I don't have permission to access that page
<kyrofa> Rob1507, I assume that's only yours?
<Rob1507> kyrofa, sorry :D
<Rob1507> kyrofa, One more thing. I published work on myapps. Can you access it?
<kyrofa> Rob1507, to the length of my knowledge, myapps only shows your own apps
<kyrofa> Rob1507, so: no. I can only see mine :)
<Rob1507> kyrofa, how can I share it?
<Rob1507> GitHub?
<kyrofa> Rob1507, you did in fact publish it? Then it should be in the store once the approval passes
<Rob1507> it's status is published
<kyrofa> Grrr.... elopio I need your help
<Rob1507> kyrofa, I can send you .snap
<kyrofa> Rob1507, if it's published I can grab it from the store. Are you wanting me to do something with it?
<Rob1507> yes just test it
<kyrofa> elopio, ah, nevermind, I went another direction with it
<kyrofa> elopio, I think there's a bug somewhere with python coverage with respect to exceptions
<plars> elopio: ok, so I figured out what was wrong, and managed to fix it for me, but there *must* be a better way than what I did
<xcub_> elopio, can you review my task: https://codein.withgoogle.com/dashboard/task-instances/5486692492378112/
<camako> ted, we were talking about the rasp pi2 graphics drivers yesterday. Do you know where I'd get the android drivers?
<camako> tedg ^
<tedg> camako: I don't know about the android ones, but there are X ones. I think that ogra_  has instructions on using,them, but I'm not sure where they are. Probably a bit late for him.
<camako> tedg, o ok.. mesa drivers perhaps? I'll ask him tomorrow. thanks..
#snappy 2015-12-16
<dholbach> good morning
<fgimenez> good morning
<zyga> hey fgimenez :)
<fgimenez> hi zyga! :)
<dshihovtsev> Chipaca, ogra_  hey guys. Is there any way to set nofile limits for service before snap packages install, in package.yaml or somewhere else?
<JamesTait> Good morning all; happy Wednesday, and happy Day Of Reconciliation! ð
<ogra_> dshihovtsev, i doubt that ... the new "capabilities" implementation miht change that in the future though
<ogra_> but probably Chipaca knows more
<Chipaca> dshihovtsev: no. I'd expect the gadget (in 15.04: oem) snap to do that, fwiw
<dshihovtsev> Chipaca, ogra_ got it, thanks
<stevebiscuit> Chipaca: for your pleasure: https://github.com/ubuntu-core/snappy/pull/258
<kyrofa> elopio, having trouble?
<kyrofa> elopio, you must be, heh. Ping me when you get back :)
<fgimenez> Chipaca, regarding snappy-m-o's comment https://github.com/janinko/ghprb
<jdstrand> Chipaca: hi!
<jdstrand> Chipaca: I had a couple of questions regarding all snaps. are you around?
<kgunn> stgraber: hey there, i've been using lxc reliably and had lxcbr0 working....but after just updating my xenial host last night, not lxc fails to start
<kgunn> i've reinstalled
<kgunn> and tried to delete, and launch new containers...
<kgunn> all fail to start with the same err
<kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFQ0tDZjh4YVJlVlk/view?usp=sharing
<kgunn> stgraber: that's my lxc info --showlog ^
<stgraber> kgunn: looks like the problem is that cgmanager isn't running or not working
<stgraber> kgunn: do you have lxcbr0 on your system?
<kgunn> stgraber: nope, it's weird and it fails to start if i try to ifup manually....
<kgunn> stgraber: full disclosure, i've also got it tied to static ip....wondering if i need to reboot my router ?
 * kgunn is a networking noob
<stgraber> kgunn: can you run "sudo /usr/lib/x86_64-linux-gnu/lxc/lxc-net restart", see if lxcbr0 comes back up
<kgunn> will try that in a sec...actually on a HO :)
<kgunn> oh..lxc, can do now
<kgunn> stgraber: ah...yeah, i see it's up now
<kgunn> stgraber: fwiw, also...that command spewed back
<kgunn> https://pastebin.canonical.com/146291/
<kgunn> even tho lxcbr0 came up...
<kgunn> dunno if that matters
<kgunn> stgraber: thanks btw, back in biz
<plars> elopio: around? Did you see that I got it working yesterday?
<elopio> plars: I am now.
<elopio> plars: I didn't, but that's great news :)
<elopio> kyrofa: hey, sorry. There was a blackout all morning, and crappy 3g internet.
<kyrofa> elopio, wow!
<kyrofa> elopio, not a problem at all
<kyrofa> elopio, power back up now?
<plars> elopio: It was building from the downloaded trunk rather than the branch I told it to build, so I had to just symlink my branch after removing the one it pulled down. Do you have some way of automatically dealing with stuff like this? It seems like it would be common to want to use a local copy for testing rather than pulling trunk in every case
<elopio> kyrofa: all good now. I survived :)
<elopio> plars: what was pulling trunk?
<kyrofa> elopio, glad to hear it ;)
<Chipaca> jdstrand: i am around now!
<elopio> balloons: yesterday I reviewed xcub snap and it is installable, but it doesn't do anything.
<Chipaca> stevebiscuit: um ... do you want to go that way?
<Chipaca> stevebiscuit: I would've expected to use the REST API directly?
<plars> elopio: in the go path, from getting the dependencies
<elopio> balloons: if I understand correctly, he's packaging a chat server, so it should be a service that runs on the background, not a binary.
<jdstrand> Chipaca: hey, I was just wondering what the status is of all snaps and 16.04. can I flash an rpi2, bbb, amd64 vm? how? do I need a special snapcraft for all snaps? where is it? will all-snaps os image support installing tar snaps or just squashfs?
<elopio> balloons: when I was about to reply to him, he left. And I don't understand how to leave comments in codein.
<elopio> plars: I'm not sure how do you have your workspace set up. I have workspace/go/src/github.com/ubuntu-core, and there I cloned the git repo.
<Chipaca> jdstrand: i don't know about snapcraft and all-snaps. you do need a special u-d-f for all-snaps. An all-snaps os image will not support ar snaps.
<elopio> so I can checkout a branch that's not master.
<Chipaca> jdstrand: http://people.canonical.com/~mvo/all-snaps/ is what i have for all-snaps
<jdstrand> Chipaca: ok, thanks
<plars> elopio: I just pointed my GOPATH to /tmp/go, and I was hacking on it in ~/code/snappy or something like that, along with git remotes for your repo
<plars> elopio: so it sounds like with go, you either adhere to their way of doing things, and either swap dirs around by hand or manually manage the checkout you have there, or you push symlinks around to hack around the way it pulls things in through GOPATH?
<elopio> plars: yes, my go path and workspace are the same. I suffered a lot with bzr and symlinks trying to keep them separated. git makes it a lot easier.
<plars> I imagine so... for some definition of "easier" :). at least with git you can have multiple branches and just checkout the one you want
<elopio> with symlinks you can do pretty much everything you like, but it becomes messy.
<plars> elopio: so one thing that is still keeping it from running without me manually doing something, is that it seems to want a json testconfig file. Is this something we would need to create by hand? I see it's done in main.go right now, but that's not getting used I think if we just use go test
<elopio> plars: yes, that's how we pass arguments from the host to the testbed.
<stevebiscuit> Chipaca: do you think it would be better to have that code in WebDM itself instead? I saw that work to develop a client lib had already started and thought it wouldn't be great to duplicate effort. I almost had to toss a coin tbh
<Chipaca> stevebiscuit: I ... i honestly don't know. I *do* know that the situation we have now, where webdm needs to be released in lockstep with snappy is a pain (and running webdm on systems with old snappys a nightmare)
<Chipaca> stevebiscuit: I fear we may inadvertently slip into this again even using the rest api if we link against a client in snappy itself
<Chipaca> stevebiscuit: that's why for a while i entertained making client a separate project entirely
<Chipaca> otherwise it's too easy to make it chummy with snappy itself
<Chipaca> and on good days i'll catch those, but on bad days i won't
<stevebiscuit> Chipaca: yeah, separating webdm from snappy is a priority from my pov, currently that client lib is just handling HTTP-over-socket
<stevebiscuit> Chipaca: maybe bite the bullet and create a new snappy-client project now?
<stevebiscuit> Chipaca: as it stands, my PR can be relocated easily
<Chipaca> stevebiscuit: go for it
<Doughball> Hello all. I'm working on a new product that uses the Beaglebone Black as a gateway device. I would really like to use Ubuntu Snappy Core in this product, but I am worried that it is not yet "production" worthy. Is Ubuntu Core completely stable at this point for product use?
<Chipaca> mectors: ^
<Chipaca> Doughball: 15.04 is being used for production by a few folks
<Chipaca> Doughball: I work on rolling, which is most definitely not stable :-)
<Chipaca> because we break it all the time
<Chipaca> Doughball: but 15.04 should be stable enough (and we do fix bugs in it if you find any)
<Chipaca> Doughball: but mectors is probably a better person to talk to if you need commercial guarantees
<stevebiscuit> Chipaca: ok, I'm game, I'll close that PR and work at creating a new project containing the existing commits to the client lib
<Chipaca> stevebiscuit: holler if you need help, as always
<plars> elopio: from what I gather, I mostly just need to give it the release and channel
<Doughball> Chipaca: Thanks.
<Chipaca> zyga: elopio: ^^^ stevebiscuit is going to create a snappy rest api client project
<Chipaca> a lot of the team is out most days until next year (the old âyikes, i never used my holidaysâ dance)
<stevebiscuit> heh
<Chipaca> stevebiscuit: but i guess you know that already
<zyga> Chipaca: mmm?
<elopio> plars: we could probably also get default values if the file doesn't exist.
<zyga> Chipaca: so now bits go to separate project?
<zyga> Chipaca: client bits
<plars> elopio: do the tests actually need them?
<Chipaca> zyga: so webdm and snap both talk to that
<Chipaca> zyga: yarr
<zyga> Chipaca: ok, so I guess 'snap' the executable is going to live there too?
<Chipaca> zyga: and ubuntu-image
<Chipaca> zyga: either there, or in a *third* place
<zyga> Chipaca: so all the capable patches I'll post (har har) will target that
<elopio> plars: we use it to tell the setup to start with an update or rollback. If you don't want those scenarios, then it won't be needed.
<Chipaca> zyga: how deep is your pipeline right now?
<Chipaca> stevebiscuit: hold it
<zyga> Chipaca: well, all the stuff I have now can be neatly dropped on top of trunk, it's entirely self contained
<Chipaca> stevebiscuit: maybe we land zyga's work first, then split, in which case your change could land as is
<zyga> Chipaca: I haven't touched renaming CLI bits and other things we've agreed to
<Chipaca> stevebiscuit: zyga: you guys work it out, i've got to go make kids do homework :-)
<zyga> Chipaca: I don't have any strong feelings about landing it before
<zyga> stevebiscuit: so without reading the backlog, how urgent is this?
<Chipaca> i'm flexible, you both know the forces driving the change, so
<stevebiscuit> Chipaca, zyga: I'm just about to EOD now so wouldn't be starting until tomorrow
<zyga> stevebiscuit: same here
<elopio> stevebiscuit: please involve fgimenez tomorrow.
<Chipaca> ah, ok, let's talk tomorrow then
<Chipaca> fgimenez is like elopio but utc+1
<elopio> we could use the same client for the user tests.
<elopio> and less hair.
<stevebiscuit> heh
<stevebiscuit> ok, I'll start a discussion in the GMT morning and we can decide what's going in and being taken out of where
<elopio> ogra_: would this work even if test exists != 0?
<elopio> test "$(./stage/bin/test)" = "Hello world"
<ogra_> elopio, what are you assigning that hello world to ?
<elopio> ogra_: mmm, nothing. It's just checking the output of the test binary.
<ogra_> test "$(./stage/bin/test)" && echo  "Hello world"
<ogra_> that will echo "hello world" if test exits true
<Chipaca> stevebiscuit|awa: zyga: elopio: ftr niemeyer says we should split it later, to keep the speed, as long as we can keep an eye on the issue of chumminess
<ogra_> test "$(./stage/bin/test)" || echo  "Hello world"
<ogra_> and that if test exits false
<elopio> ogra_: right. But I wanted to know if test "$bin" = "something" would be affected by the exit value of bin.
<elopio> I've just thrown it at travis, we'll see soon.
<ogra_> oh, no, it shouldnt if you exec it in a subshell and just use the output value( i.e. "$(...)"  )
<elopio> damn it. I spend the whole night debugging why the binary failed when run from python.
<elopio> it was not that. It has always failed when run in travis. :@
<balloons> elopio, load https://codein.withgoogle.com/dashboard/task-instances/5486692492378112/, and enter your comments
<kyrofa> elopio, when you're able: https://github.com/ubuntu-core/snapcraft/pull/169/files
<kyrofa> elopio, https://github.com/ubuntu-core/snapcraft/pull/169 rather
<jerryG> tedg are u there?
<tedg> Yup, howdy jerryG
<jerryG> tedg: I'm trying to get pkgconfig working.  How do i use pkg-config-sysroot in snapcraft?
<jerryG> tedg: I found this: https://github.com/ubuntu-core/snapcraft/blob/master/examples/godd/snapcraft.yaml
<jerryG> tedg: but I'm trying to add .pc files
<jerryG> tedg: the .yaml in that example is only .so files
<tedg> jerryG: pkg-config will work generally if you just install it as a stage-package, we'll setup the paths and such.
<tedg> jerryG: Are you trying to mkae a part fo the library with a .pc file?
<jerryG> tedg:  yeah I've got a few .pc files I need to add to pkgconfig
<tedg> jerryG: So if you stage-packages pkgconfig you should be able to install them into the staged area of /usr/lib/pkgconfig
<tedg> jerryG: Make sure to use the after directive to align your parts so they build in order.
<jerryG> tedg:  thank you
<jerryG> tedg: do I put the .pc files under filesets?
<tedg> jerryG: You shouldn't need to worry about that starting out as the default is to copy everything. You'll probably want to filter them later, but don't worry about that at first.
<jerryG> tedg: do u have any examples on pkg-config w/ stage-packages ?
<tedg> jerryG: Hmm, I can't think of one. But I know I fixed a few bugs with it, so we've done it. Doesn't look like the current examples do it though.
<jerryG> tedg: can u send me one?
<jerryG> tedg: :)
<jerryG> tedg: plz
<tedg> jerryG: I don't have one, but if I run across one I can pass it along.
<jerryG> tedg: k thx.  do u need my email?
<tedg> jerryG: Sure, but also you could post a message to snappy-app-dev to see if anyone else has one.
<jerryG> ok
<jerryG> tedg: is that another irc?
<jerryG> tedg: or just mailing list?
<tedg> jerryG: Mailing list
<jerryG> tedg: pastebin.com/raw/wSjA2zVp
<tedg> Got it
<jerryG> tedg: thx
#snappy 2015-12-17
<ePierre> hi there!
<ePierre> I am trying Snappy on a KVM virtual machine, and I would like to have more free space in the image HDD in order to install more snaps. How can I do that? I tried to follow this guide: http://itsignals.cascadia.com.au/?p=28 but when I start gparted live, I have a kernel panic message
<dholbach> good morning
<zyga> good morning, hey dholbach :)
<dholbach> hey zyga
<ePierre> morning zyga  :)
<ePierre> and dholbach :)
<ePierre> zyga, you may have an idea about this:
<ePierre> I am trying Snappy on a KVM virtual machine, and I would like to have more free space in the image HDD in order to install more snaps. How can I do that? I tried to follow this guide: http://itsignals.cascadia.com.au/?p=28 but when I start gparted live, I have a kernel panic message
<dholbach> hi ePierre
<zyga> ePierre: just make a bigger disk
<zyga> ePierre: then snappy expands on first boot
<zyga> ePierre: my recommendation is to use -snapshot all the time
<zyga> ePierre: so each reboot gives you identical environment
<zyga> ePierre: then script any post-boot activities,
<zyga> ePierre: this is great for testing
<ePierre> zyga, let me try this
<ePierre> zyga, hm so I followed everything up to step 8 of that page: http://itsignals.cascadia.com.au/?p=28 ; which supposedely makes my .img file much bigger
<ePierre> zyga, yet when I boot I still have 0 free space
<fgimenez> good morning
<ePierre> Filesystem      Size  Used Avail Use% Mounted on
<ePierre>  /dev/sda6       471M  461M     0 100% /home
<ePierre> zyga, to follow up, my disk is bigger, but snappy won't expand automagically
<ePierre>  /dev/sda6  6569984 19427327 12857344  6.1G Linux filesystem
<zyga> ePierre: try latest images, I think this happens automatically now (it did for me)
<JamesTait> Good morning all; happy Thursday, and happy Wright Brothers Day! â
<fgimenez> Chipaca, hello! i'm getting http://paste.ubuntu.com/14072304/ in 15.04/edge, don't know if you are the right person to ask about this
<Chipaca> fgimenez: that's interesting
<Chipaca> fgimenez: what happens if you disable autopilot using config?
<fgimenez> Chipaca, sorry, how can i do that?
<Chipaca> fgimenez: rolling: echo 'config: {ubuntu-core: {autoupdate: off}}' | sudo snappy config ubuntu-core -
<Chipaca> fgimenez: 15.04: echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core -
<Chipaca> fgimenez: in fact
<Chipaca> fgimenez: echo 'config: {ubuntu-core: {autopilot: off, autoupdate: off}}' | sudo snappy config ubuntu-core - | grep auto
<Chipaca> fgimenez: should work for both
<Chipaca> for now :-)
<Chipaca> (we're going to break this on rolling at some point in the new year)
<fgimenez> Chipaca, "echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core -" works  (config doesn't give the "invalid unit status error" afterwards) but i'm not able to reenable it http://paste.ubuntu.com/14072341/
<Chipaca> fgimenez: echo 'config: {ubuntu-core: {autopilot: off, autoupdate: on}}' | sudo snappy config ubuntu-core - | grep auto
<Chipaca> fgimenez: or, try mask/unmask instead of enable/disable if you need to do it through systemctl
<Chipaca> fgimenez: (fwiw i think this is new, and if the change broke stuff you should blame mvo)
<Chipaca> fgimenez: (mostly because blaming mvo is always fun)
<Chipaca> ahm
<Chipaca> fgimenez: i meant to change both 'off's to 'on's, not just one, fwiw
<Chipaca> elopio: wrt https://github.com/ubuntu-core/snappy/pull/232
<Chipaca> elopio: i don't care whether you use a url or python to make sure the json is valid, but one of the two needs to happen
<mvo> Chipaca, fgimenez: hm, I think you now need to mask/unmask
<Chipaca> mvo: the 'invalid unit status' thing is probably a bug though
<fgimenez> Chipaca, mvo, ok thanks, to continue using systemctl it seems that "sudo systemctl disable snappy-autopilot.timer" is now equivalent to "sudo systemctl disable snappy-autopilot.timer && sudo systemctl mask snappy-autopilot.timer", right?
<Chipaca> mvo: makes me think some people will see breakage on upgrade to this
<Chipaca> fgimenez: no, just mask
<mvo> Chipaca: oh, yeah, for upgrades it is indeed a bug. well, maybe, I think part of the problem is that a disable will not survie a reboot because it gets copied up again :)
<fgimenez> Chipaca, mvo ok, just mask works great, thanks!
<Chipaca> mvo: good point :)
<mvo> Chipaca: sorry for being a smartass, I'm just a bit tired this morning
<Chipaca> mvo: your transgression has been duly noted
<stevebiscuit|awa> Chipaca, zyga, elopio: I've noted the decision to not separate the REST-wrangling client code
<Chipaca> stevebiscuit|awa: *for now* :-) yes
<stevebiscuit> Chipaca: if others want to contribute to fleshing out the client lib then I'm all for it :)
<stevebiscuit> Chipaca: ripping out all the snappy code from webdm will take a while but it'll be worth it
<Chipaca> stevebiscuit: i'll take another pass at your branches in a bit
<Chipaca> --- there are a few others ahead of yours in my pile, is all :-)
<stevebiscuit> Chipaca: appreciated!
<Chipaca> stevebiscuit: you need two +1s to land on master though
<Chipaca> stevebiscuit: (just in case you weren't aware)
<Chipaca> ah! you already have them
<Chipaca> go go go
<Chipaca> merged
<stevebiscuit> Chipaca: gentleman and a scholar, ta!
 * Chipaca straightens his monocle
<Chipaca> indeed
<stevebiscuit> :D
<stevebiscuit> so the concept of a port for a snap service is going to go away?
<stevebiscuit> "fyi TODO we have removed the concept of ports." << from code review by Sergio
<Chipaca> stevebiscuit: i think sergio misused the word 'concept' there
<Chipaca> the *concept* didn't go away
<Chipaca> the plan is to expose it in a different way, probably
<Chipaca> and the underlying problem of actually doing something with the intent expressed in the ports declaration is still present
<Chipaca> but the change should make it feasible to do that something
<Chipaca> we're talking post-16.04 stuff now
<stevebiscuit> Chipaca: ok, so the data will still be available
<pedronis> it's going to be trough capabilities afaiu
<Chipaca> stevebiscuit: if i remember correctly, it'll be an attribute of a capability
<Chipaca> stevebiscuit: but that's a zyga question i think
<Chipaca> he was paying more attention than i
<Chipaca> (because he's the caps guy)
<stevebiscuit> ah, so the service will need the capability to listen on a specif port, makes sense
<jdstrand> beuno, pindonga: hey, I'm getting a 503 when trying to install hello-world in a vm
<beuno> jdstrand, yes
<jdstrand> hello-world failed to install: received an unexpected http response code (503) when trying to download https://public.apps.ubuntu.com/anon/download/canonical/hello-world.canonical/hello-world.canonical_1.0.18_all.snap
<beuno> prodstack going through some heavy turbulance atm
<jdstrand> ok
<kyrofa> elopio, I'm sorry I completely lost track of time
<kyrofa> elopio, do you have power today? :P
<frecel> can someone tell me what oem snaps are supposed to be?
<ogra_> currently they define the hardware and ship all bootloader related bits
<frecel> ogra_: can I put a kernel in an oem snap?
<ogra_> no
<ogra_> today you need a device tarball ...
<ogra_> soon this will all change ...
<ogra_> and you need a kernel snap ...
<ogra_> the oem snap is going away and the bootloader will go into that kernel snap ...
<ogra_> the HW description moves to a so-called gadget snap then
<frecel> oh interesting
<ogra_> today you still need a device tarball and an oem snap though
<frecel> I'm trying to get an image for intel edison
<frecel> ogra_: is there a documentation on what a proper oem snap is supposed to look like?
<frecel> or should I just look at the pi2 snap and try to figure it out
<ogra_> https://developer.ubuntu.com/en/snappy/guides/oem/
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<ogra_> have fun :)
<kyrofa> jdstrand, mvo my take on a fix for bug #1466234: https://github.com/ubuntu-core/snappy/pull/264
<ubottu> bug 1466234 in ubuntu-snappy (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged] https://launchpad.net/bugs/1466234
<kyrofa> Well, as far as snappy itself goes anyway
<frecel> ogra_: I think https://developer.ubuntu.com/en/snappy/guides/porting/ should link to that oem guide
<ogra_> true
<jdstrand> mvo: hi!
<jdstrand> mvo: can you think of why my last comment in https://github.com/ubuntu-core/snappy/pull/264 is happening?
<jdstrand> mvo: ubuntu-core/rolling/edge doesn't have the newest ubuntu-core-security-* packages installed
<jdstrand> mvo: it has 16.04.2, which is from Nov 12, but 16.04.7 is available in xenial
<mvo> jdstrand: is that maybe a xenial vs xenial-proposed thing? without having looked at it
<jdstrand> mvno. 16.04.7 is in xenial release
<jdstrand> err
<jdstrand> mvo: no 16.04.7 is in xenial release
<jdstrand> mvo: since Dec 2
<mvo> hmmm
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-amd64.manifest
<ogra_> i see 16.04.7
<jdstrand> well that's weird
<jdstrand> my vm doesn't have it
<jdstrand> and it claims it is up to date
<jdstrand> mvo: ok, seems to be a local thing
 * jdstrand blows it away and regenerates
<ogra_> jdstrand, and it actually landed on dec 3rd in the image http://people.canonical.com/~ogra/core-image-stats/20151203.changes
<mvo> jdstrand: scary - the buildlog also has it
<ogra_> another delta generation issue ?
<mvo> it might be :/
<mine_field> what is this? o_O https://uappexplorer.com/app/canonical-linux-pc.canonical
<ogra_> well, what the description says :)
<mine_field> no description :D
<mine_field> i understand nothing :(
<mine_field> but is very late so i must sleep now :P
<ogra_> it is the new kernel snap
<mine_field> oh 4.3.0-2-2
<mine_field> got it :d
<ogra_> (currently snappy still uses the system-image technology from the phone for upgrades ... this will change ... all parts of the OS will become snap packages)
<mine_field> skynet 0.1 got it :D
<mine_field> thanks! good night all! ogra_
<Rob1507> Hi there. Can anyone help me with something now?
<kyrofa> jdstrand, I just made a new VM off of 15.04 stable and I'm still getting apparmor denials to /root/apps. Did I misunderstand you when I thought that would be fixed?
<kyrofa> Rob1507, ask away!
<Rob1507> kyrofa, I want to snap NodeJS app but I get error
<Rob1507> Failed doing build for webchat: Command '['/bin/sh', '/tmp/tmp36flb68n', 'npm', 'install', '-g']' returned non-zero exit status 2
<kyrofa> Rob1507, using snapcraft?
<Rob1507> kyrofa, yes
<kyrofa> Rob1507, can you put the code somewhere so I can take a look? And make a pastebin of the entire output from snapcraft
<kyrofa> Rob1507, also, what version of ubuntu are you running?
<jdstrand> kyrofa: is that for an existing app?
<Rob1507> 14.04 LTS
<kyrofa> jdstrand, no just a test case (roscore running as a service)
<kyrofa> jdstrand, but I can tar it up if you want it
<Rob1507> kyrofa, I am snapping one of the examples - shout. Send code or not needed?
<kyrofa> jdstrand, or simplify it
<jdstrand> kyrofa: what is the output of dpkg -l|grep ubuntu-core-security-apparmor
<kyrofa> Rob1507, you're saying a snapcraft example isn't snapping correctly?
<kyrofa> jdstrand, ubuntu-core-security-apparmor 15.04.12~ppa14
<Rob1507> http://pastebin.com/ev5Esfv4
<Rob1507> kyrofa, this is output
<kyrofa> jdstrand, just downloaded the 15.04 stable image and ran snappy update followed by a reboot, no more updates available
<jdstrand> kyrofa: that should have it. did you install your snap prior to snappy update/reboot? (that is what I was trying to ask before)
<kyrofa> jdstrand, oh I see. And no, I updated and rebooted before I tried installing anything
<jdstrand> kyrofa: what is the output of grep HOME /usr/share/apparmor/easyprof/templates/ubuntu-core/15.04/default?
<kyrofa> jdstrand, http://pastebin.ubuntu.com/14077787/
<kyrofa> Rob1507, are you using the snappy-tools ppa to get snapcraft on trusty?
<jdstrand> ok, that's good
<jdstrand> kyrofa: can you paste the denial?
<kyrofa> jdstrand, http://pastebin.ubuntu.com/14077817/
<kyrofa> jdstrand, hmm
<kyrofa> jdstrand, actually that looks like a snappy problem huh
<kyrofa> jdstrand, it's trying to create /root/apps
<jdstrand> kyrofa: indeed
<kyrofa> jdstrand, I'm sorry, I just saw a denial on /root and came to you, I should have investigated further
<kyrofa> jdstrand, so my PR should probably fix that, eh?
<kyrofa> jdstrand, hmm... wonder how to best do that in a systemd conf
<jdstrand> it should, but I thought the launcher was already doing that
<jdstrand> oh, this is in a service, not a binary?
<kyrofa> jdstrand, yes a service
<jdstrand> hmmm
<jdstrand> I'm not sure the best way to handle that
<jdstrand> kyrofa: I think most would probably say that a service should be using SNAP_APP_DATA_PATH and not SNAP_APP_USER_DATA_PATH
<kyrofa> jdstrand, I agree, but that's not always possible
<kyrofa> jdstrand, not to mention having an environment variable point to a dir that doesn't exist seems wrong anyway
<kyrofa> jdstrand, some apps just log to HOME/something, and the person making the .snap can't always change that
<jdstrand> it does
<jdstrand> does it make sense for SNAP_APP_USER_DATA_PATH to point to SNAP_APP_DATA_PATH?
<jdstrand> HOME/something is weird for a service though
<kyrofa> jdstrand, agreed, in the case of a service, I think that would be fine. That's more of an mvo question though
<jdstrand> yes
<kyrofa> jdstrand, okay thanks for trouble-shooting with me :)
<jdstrand> np
<dPragmatist> snapcraft init
<kyrofa> dPragmatist, that may not result in what you'd hoped in this window
<dPragmatist> ha, too many open windows kyrofa
<kyrofa> dPragmatist, haha, it's happened to all of us
<kyrofa> mvo, are you around? It might be a bit late for you
#snappy 2015-12-18
<dholbach> good morning
<fgimenez> good morning
<fgimenez> good morning mvo! i have a quick question
<mvo> fgimenez: sure
<mvo> fgimenez: and good morning
<fgimenez> mvo, in rolling/edge #287 there's no generic-amd64 snap installed, that's ok, right?
<mvo> fgimenez: hm, that smeels like a bug
<mvo> fgimenez: I think its because of the rename of oem and gadget
<fgimenez> mvo, http://paste.ubuntu.com/14086622/
<fgimenez> mvo, this is the failed test http://162.213.35.179:8080/job/snappy-cloud-test/21/consoleFull (search for "FAIL:" in there), when there's a new image available a new snappy-cloud-test is triggered
<mvo> fgimenez: thanks, I will prepare a fix
<fgimenez> mvo, thanks, btw regarding the all-snaps test you mentioned yesterday i've added a card in the old trello board to keep track of it https://trello.com/b/4PQViyUQ/snappy-core-stakeholders-backlog
<mvo> fgimenez: \o/
<fgimenez> mvo, we can't we begin with it with the current rolling/edge, right?
<mvo> fgimenez: I will start thinking about how to port the teests to the new world
<fgimenez> mvo, great, another thing, in case you didn't notice we have integration tests executions with each PR at last \o/
<mvo> fgimenez: rolling/edge is not yet all-snaps, but I guess we should change this RSN :)
<mvo> fgimenez: and yes, I noticed and its super cool, thanks for this!!!
<fgimenez> mvo, np, i really needed to see it happening :) the PRs targeted to master are already working, we need this branch landed for 15.04 to work https://github.com/ubuntu-core/snappy/pull/261
<mvo> fgimenez: I guess you need review for this :) ?
<fgimenez> mvo, well yes, if you have the time it would be great :)
<mvo> fgimenez: I will do my best, the oem snap thing has some complications, I need to think about it a bit more. we changed the directory from /oem to /gadget that is trivial to re-add but we also changed the type from oem to gadget so this involves two places
<mvo> fgimenez: but once oem and sudo are under control I should have time to review
<fgimenez> mvo, great thanks a lot, no rush at all
<JamesTait> Good morning all; happy Friday, and happy Bake Cookies Day! ðª
<morphis> ogra_: you know if there is a way to install a core image going to be 16.04 on the raspberry-pi2?
<morphis> didn't found any images yet
<ogra_> you need to use ubuntu-device-flash and create your own ...
<ogra_> we do not provide any images for rolling
<ogra_> (for none of the arches)
<morphis> ogra_: ah I see
<morphis> so rolling is what 16.04 will be
<morphis> ogra_: so I just pick a device tarball from http://people.canonical.com/~platform/snappy/raspberrypi2/ and generate an image for rolling, right?
<ogra_> no
<ogra_> you only use u-d-f
<morphis> no device tarball anymore?
<ogra_> sudo ubuntu-device-flash core rolling --channel=edge --oem=pi2.canonical/stable --device=armhf_raspi2 --enable-ssh -o myimage.img
<morphis> or oem snap?
<morphis> I see
<ogra_> oem snap comes from the store, device tarball from the system-image server
<morphis> nice
<ogra_> (and soon everything comes from the store as a snap and system-image will be gone)
<morphis> hm, gives me:
<morphis> Device armhf_raspi2 not found on server https://system-image.ubuntu.com channel ubuntu-core/rolling/edge
<ogra_> funny, it is building here
<ogra_> bah
<ogra_> if i would have pasted the correct line from ym terminal it would work at least
<ogra_> :P
<ogra_>  sudo ubuntu-device-flash core rolling --channel=edge --oem=pi2.canonical/stable --device=raspi2_armhf -o myimage.img
<ogra_> try that one
<ogra_> :)
<morphis> :-)
<ogra_> (and --enable-ssh if you want to log in remotely)
<morphis> jupp, works
<kyrofa> mvo, I ran into an issue yesterday I'd like to pass by you
<morphis> ogra_: worked quite nicely :-)
<ogra_> :)
<kyrofa> sergiusens, I've been asked about including #169 in 1.x. Sound okay to you?
<sergiusens> kyrofa, yeah, we should get a list; but we need to cherry pick #169 and #162
<kyrofa> sergiusens, ah, indeed
<sergiusens> kyrofa, want to take that or should I? They should be a direct cherry pick
<sergiusens> kyrofa, btw, nice progress while I was gone
 * sergiusens is happy
<kyrofa> sergiusens, I got it :)
<sergiusens> kyrofa, do you know if Leo is going to be here today?
<kyrofa> sergiusens, should I make a PR for them?
<sergiusens> kyrofa, I guess so, just to be sure the tests pass before pushing it
<kyrofa> sergiusens, I'm not sure honestly. His power/internet has been a little flaky, we haven't connected the last few days
<kyrofa> sergiusens, however, knowing his leave situation, I wouldn't be surprised if he was outta here
<mvo> kyrofa: sure, what is it?
<kyrofa> mvo, Snappy services device the user data path using %h/apps. However, that directory does not seem to be created for services like it is for binary wrappers
<kyrofa> mvo, so anything that tries to use that variable ends up trying to create /root/apps, which obviously can't happen
<mvo> kyrofa: aha, ok
<kyrofa> mvo, how would you feel about remapping the user data path to the app data path for services?
<kyrofa> mvo, or should we actually create the user data path?
<mvo> kyrofa: in a meeting right now, will reply in a wee bit
<kyrofa> mvo, no problem. I'm happy to take care of this, just want to come to an agreement on the proper fix :)
<kyrofa> sergiusens, #170 and #171
<sergiusens> kyrofa, you can't create though, apparmor won't let you
<kyrofa> sergiusens, I mean as a snappy fix
<sergiusens> oh right, that seems logical; maybe it should be in the core launcher though; not sure where the dirs are created these days
<kyrofa> sergiusens, well for binaries it's in the wrapper
<kyrofa> sergiusens, but moving it to the launcher would solve it for both
<kyrofa> sergiusens, not a bad idea
<kyrofa> sergiusens, but it also makes sense to just have services logging to the data path rather than somewhere in /root
<mvo> kyrofa: I think mapping the user-data-path to the app-data-path makes most sense, so +1 from me on that
<mvo> kyrofa: and nice catch!
<kyrofa> mvo, ah, I love the easiest solution
<kyrofa> mvo, no problem-- you'll see a PR soon
<mvo> \o/
<kyrofa> jdstrand, ^^ in case you were curious
 * jdstrand happens to be lurking, but will wander off for sure
<jdstrand> nice!
<sergiusens> kyrofa, question, should I squash `new-cli` before proposing a merge into master?
<kyrofa> sergiusens, nahh
<kyrofa> sergiusens, special case, I'd say
<kyrofa> sergiusens, that's usually to get rid of "oh and do this too" commits
<kyrofa> sergiusens, which you've already done
<sergiusens> kyrofa, k, so just rebase; the reason I ask about elopio is that he targetted the testing change to `new-cli`
<kyrofa> sergiusens, maybe wait an hour and see if he comes to standup?
<sergiusens> sounds good
<kyrofa> sergiusens, how should we update bugs now that the code and bugs are separate? Fix committed when it gets merged, fix released when it's a .deb?
<sergiusens> kyrofa, fix released when the milestone is released
<kyrofa> sergiusens, also, how do we indicate that something is fixed for 2.x but not 1.x?
<kyrofa> sergiusens, hmm... define milestone?
<sergiusens> kyrofa, we need to create series
<sergiusens> kyrofa, https://launchpad.net/snapcraft/+milestone/0.6
<kyrofa> Ah ha
<sergiusens> kyrofa, or the thing on the far right in the bug
<kyrofa> Okay so yeah, fix released when it's in the archives, essentially
<sergiusens> kyrofa, yeah
<kyrofa> Ah, and bugs target them, okay nice I gotcha (not a heavy launchpad user here)
<kyrofa> sergiusens, is creating the series relatively easy?
<sergiusens> kyrofa, already done
<kyrofa> sergiusens, hey, look at you!
<sergiusens> kyrofa, I'll do bug management for a bit
<kyrofa> sergiusens, so if I have a bug where I'd like to track state for both 1.x and 2.x, do I "target to series"?
<sergiusens> kyrofa, like this I guess https://bugs.launchpad.net/snapcraft/trunk/+bug/1523912
<ubottu> Launchpad bug 1523912 in Snapcraft 1.x "Shebang write uses overly broad regex" [Critical,New]
<kyrofa> sergiusens, ah, pretty painless
<sergiusens> kyrofa, we need this merged first for tests to pass https://github.com/ubuntu-core/snapcraft/commit/3ec8328a144c79b158c62ec836c356281f3b080f
<sergiusens> eh, cherry picked
<kyrofa> sergiusens, oh oops. Fixing now
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/172
<sergiusens> kyrofa, merged
<jdstrand> mvo: hey, so, ubuntu-core-security 16.04.9 got all caught up in the perl transition and is still in -proposed. are you planning on making another os all snap image before eoy?
<jdstrand> mvo: that has the new caps from the brazil sprint and would be nice if people are playing with snappy over the holidays if they were there
 * jdstrand isn't really here btw
<kyrofa> sergiusens, alright, rerunning PR tests
<kyrofa> jdstrand, out until the new year?
<mvo> jdstrand: hm, that sounds like  an important reason - so far we build without -proposed but I can build one with -propsoed enabled
<jdstrand> kyrofa: I am
<jdstrand> mvo: well, I expect it to get through proposed sometime today
<mvo> jdstrand: aha, nice. in this case its easy, I can do a new upload today
<ogra_> mvo, not sure thats clever ...
<ogra_> given there sits also a half transitioned perl in -proposed
<ogra_> (building with propoed i mean)
<sergiusens> lool, be tere in a bit
<lool> sergiusens: ok
<sergiusens> lool, I'm in
<skawaii> hello all. Iâm new to snappy and am running into some trouble getting a my snap (which is really just a docker image) to work. if anyone could help me out, Iâd really appreciate it.
<skawaii> my snacraft.yaml: https://gist.github.com/skawaii/5c710b27eb9eac1cc5cc
<skawaii> my exe sh script: https://gist.github.com/skawaii/8f71b3d76498b29ca989
<skawaii> the erro iâm seeing is this:
<skawaii> (amd64)ubuntu@ubuntu-snappy:/apps$ whaley.speak
<skawaii> (amd64)ubuntu@ubuntu-snappy:/apps$ whaley.speak
<skawaii> <path to app>/speak.sh: 2: /apps/whaley.sideload/IIDeccTbeLdT/./bin/speak.sh: docker: Operation not permitted
<skawaii> i can run my docker image outside of the snap via âdocker run skawaii/docker-whaleyâ without problem, so Iâm a little lost here
<kyrofa> mvo: https://github.com/ubuntu-core/snappy/pull/269
<elopio> kyrofa: sergiusens: hello. Just checking in...
<kyrofa> Hey elopio!
<elopio> sergiusens: what do you need me to do with the integration tests branch?
<kyrofa> elopio, are you out?
<elopio> kyrofa: well, I'm in bed, sleeping a lot :D
<kyrofa> elopio, hahaha
<elopio> Today I'm going to start disconecting. I'll send an email.
<davmor2> elopio: how's that different from normal ;)
<elopio> kyrofa: do you need something from me before I start partying? Today is the maker space party, cryptobeers without crypto.
<kyrofa> elopio, that sounds amazing. And no, go away!
<kyrofa> elopio, heads up though if you have a minute: sergiusens said you were targeting the new-cli with some tests
<kyrofa> elopio, but he needed to rebase it to master, so he pushed it to a new branch instead of messing up your tests
<kyrofa> elopio, you might want to retarget that new branch
<elopio> davmor2: holidays are the same as any day, but without alarm clocks.
<elopio> kyrofa: ah, ok, let me see.
<kyrofa> elopio, ah, yeah your py_integration branch I think
<kyrofa> elopio, also, if you have a minute to give https://github.com/ubuntu-core/snapcraft/pull/146 one last look, it's been cleaned up and I think it's good to go, I just want one more pair of eyes before I merge it
<elopio> I'll try a merge with his rebased-new-cli branch.
<elopio> kyrofa: I had already merged it on master. I've just merged this one too.
<elopio> now sergiusens needs to update a lot of docs with his new cli :)
<kyrofa> elopio, excellent, thank you :)
<kyrofa> Haha, yes indeed
<elopio> kyrofa: how do I merge my branch with a branch from sergio? Do I need to add him as a remote?
<kyrofa> elopio, yeah, git remote add sergio_stuff <his fork url> then git fetch --all
<jdstrand> mvo: thanks!
<elopio> kyrofa: got it, the merge seems ok. The commit message and the diff does not. I'm not sure how to turn my change in one single commit on top of sergio's.
<sergiusens> elopio, use 'fixup'
<jdstrand> ogra_ (and mvo): note, ubuntu-core-security doesn't care about perl. it has a Build-Depends on apparmor that needed a rebuild that delayed things
<jdstrand> ogra_ (and mvo): but it doesn't need the rebuilt apparmor or perl
<ogra_> jdstrand, well, its all or nothing ... if you enable proposed you get all packages from there including all breakage too
<kyrofa> elopio, so what you should really do is rebase onto the new cli branch, and you'd have the same commits as before
 * jdstrand nods
<kyrofa> commit messages anyway
<kyrofa> elopio, then you can fixup as sergiusens suggests, or just squash manually if necessary
<elopio> I propose we move to bzr.
<kyrofa> elopio, hahaha
<elopio> sergiusens: kyrofa: https://github.com/sergiusens/snapcraft/pull/1
<elopio> I used cherry-pick, which I learned yesterday. Please tell me if that works.
<kyrofa> elopio, hey that works. The diff looks the same, although making a PR into the fork means the tests don't run on travis right?
<elopio> kyrofa: right. But I suppose sergiusens will make a pr into master, and there they'll run.
<elopio> I confirmed they still pass here.
<kyrofa> elopio, yeah that seems reasonable
<sergiusens> elopio, kyrofa I can push the rebased-new-cli to the official repo, then tests will run
<kyrofa> sergiusens, elopio that might be better just to have a record of that PR on the official project
<kyrofa> But it's not super important to me anyway
<sergiusens> kyrofa, hah, so elopio didn't squash :-P
<sergiusens> kyrofa, https://github.com/sergiusens/snapcraft/pull/1
<kyrofa> Tsk tsk elopio
<sergiusens> kyrofa, elopio ok, so PR to this so tests run
<kyrofa> sergiusens, looks like those cherry-pick tests pass
<kyrofa> elopio, you'll love git before we're done with you
<sergiusens> kyrofa, ah, thought they were merged already..
<elopio> kyrofa: sergiusens: so I got lost. sergiusens PRs his changes to master. We land that, and then I PR my two commits against master?
<kyrofa> sergiusens, nah, I wouldn't do that without at least one more eye
<kyrofa> elopio, no sergiusens just pushed his branch into the official project rather than his fork
<kyrofa> elopio, so make a PR on the official project to that branch instead of the one on his fork
<sergiusens> elopio, and squash
<sergiusens> elopio, which is the only resaon I didn't merge your branch earlier
<elopio> sergiusens: I wanted to keep two commits. The first makes the tests pass in xenial. The second is a workaround for trusty that I want to remove the first day of next year.
<sergiusens> elopio, if the is the case then it is fine
<sergiusens> elopio, let me do the work then
<sergiusens> elopio, meh, I'll leave it to you
<elopio> yes, I got i
<elopio> t
<elopio> or not. Just a second...
<elopio> https://github.com/ubuntu-core/snapcraft/pull/173
<sergiusens> elopio, great
<sergiusens> kyrofa, elopio so maybe today I just update the docs all day long :-P
<kyrofa> sergiusens, yay, fun day
<elopio> green!
<sergiusens> kyrofa, elopio ok, so this is now there https://github.com/ubuntu-core/snapcraft/pull/174
 * sergiusens needs to go out and be a nanny for a bit
<kyrofa> Alright sergiusens, thanks!
<kyrofa> sergiusens, will you do the docs after this merges, then? Or will you put it in this branch?
<sergiusens> kyrofa, I was thinking new branch, this is getting too big; unless you want the docs here
<kyrofa> sergiusens, works for me :)
<kyrofa> sergiusens, is there no snapcraft all anymore?
<kyrofa> sergiusens, or is that now just snapcraft snap?
<kyrofa> sergiusens, oh man... this is already so much better
<kyrofa> sergiusens, excellent work
<balloons> sergiusens, is there a reason snaps seems so big? I have a student working on a nodejs snap and it's 10 mb's
<beuno> balloons, because it includes all of nodejs?  :)
<balloons> beuno, yes, presumably so. It has not external depends
<balloons> the app itself is like 1k, heh
<beuno> right
<beuno> so that's where the 10mb comes from
<beuno> in exchange, once his app works it'll work forever*
<beuno> *ish
<ogra_> balloons, lol 10MB
<ogra_> (Dragonboard)ubuntu@localhost:/mnt/home/linaro/xenial-chroot/upnp-server$ ls -lh upnp-server-arm64_0.1.0_arm64.snap
<ogra_> -rw-r--r-- 1 root root 42M Dec 15 18:43 upnp-server-arm64_0.1.0_arm64.snap
<ogra_> that only has minidlna and lighttpd inside :)
<ogra_> snaps are big by design
<balloons> I suppose I should get used to that.
<balloons> I'm seeing that :-)
<ogra_> i have an unconfined debootstrap snap here that has 150MB ...
<ogra_> simply pulling in a whole base system as deps
<balloons> so it's interesting you can build an i386 snap, and push it to the store. But it can never be used, as there is no i386 image right?
<balloons> money.rga is the example
<ogra_> yeah
<ogra_> no i386 images atm ...
<ogra_> (they might come though, there are IoT platforms that are i386 only ... once we support them we will have to have i386 images)
<ogra_> but til then you have to build for amd64 to get something usable
<ogra_> (or armhf ... and soon arm64)
<sergiusens> balloons, you can build an image, there just isn't one promoted as avail
<sergiusens> with snaps we want everyone to feel like compiling go with gc-go :-P
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/175 . Sort of a "cleaning up nasty things" PR, a tad random I'm afraid
<kyrofa> sergiusens, mostly tests
<sergiusens> kyrofa, got it; too bad you merged the new cli thing
<kyrofa> sergiusens, uh oh, how come?
 * sergiusens mentions he likes to joke and troll, more so on Fridays ;-)
<balloons> argh.. does --allow-unauthenticated fail for anyone else? Trying to sideload a snap and I get a signature verification failed.
 * balloons tries with a different package
<sergiusens> balloons, 15.04 or rolling?
<balloons> 15.04
<sergiusens> kyrofa, so, I was just joking (just in case)
<balloons> well, I'm running ubuntu-core/15.04/edge
<kyrofa> sergiusens, you suck too
<sergiusens> balloons, it should just install
<sergiusens> kyrofa, glad to know
 * sergiusens is probably on Santa's naughty list
<kyrofa> Probably
<davmor2> sergiusens: do you every get off that list?
<kyrofa> You were always that one kid that people actually DID buy that stupid wrapped coal present for
<sergiusens> davmor2, haven't kept track; I just pay attention now as I don't want to splash the naughtiness onto my son
<kyrofa> Does anyone ever buy those?
<davmor2> sergiusens: :)
<sergiusens> kyrofa, I was once gifted a brick for my birthday in this huge box; it was a prank from a friend
<sergiusens> my life forever changed
<kyrofa> Haha, "this is heavy... must be expensive"
<davmor2> sergiusens: yeah only cause you used the brick to smash the windows to get the things you wanted right ;)
<balloons> sergiusens, ok, so I believe I know what the issue is. It's displaying that error when I install a snap with a bad arch. Aka, an arm snap on amd64
<sergiusens> balloons, I don't think there will be user message polish on 15.04, but may be good to know if this is the case on rolling too
<sergiusens> a preemptive bug would be good
<davmor2> sergiusens: now I understand why you are on Santas naughty list, I mean if friends treat you like that :D
<balloons> if someone wishes to do a quick check that would be nice
<balloons> try installing http://people.canonical.com/~nskaggs/money.snap for instance. It should yell at you nicely
<sergiusens> balloons, us snapcrafters aren't really into having the latest and greatest images anymore
<kyrofa> cuz those are broken
<davmor2> balloons: you have a snap that makes money what printer do I need ;)
<balloons> lol.. so we just get elopio to test right? he's qa!
<kyrofa> balloons, there you go!
<sergiusens> balloons, hah, elopio is headed to the jungle now and has no solar powered laptop, much less any internetz ;-)
<balloons> ahh right.. Friday already
<balloons> you guys into github issues now, or lp bugs?
<kyrofa> balloons, lp
<davmor2> balloons: no same as usual bungee cords and post-it notes
<balloons> I guess I'll still give you a bug report. Even on lp
<kyrofa> sergiusens, why lp, by the way?
<kyrofa> sergiusens, just because it's always been there?
<sergiusens> kyrofa, our bdfl suggested it
<kyrofa> sergiusens, ah
<sergiusens> balloons, if you go to snapcraft's issues at least you get pointed to lp; not sure how it is in snappy
 * balloons spins it on it's head and asks why github if lp has git support
<balloons> :p
<kyrofa> balloons, because github contributions/streaks are way cooler than lp karma
<sergiusens> balloons, mentions in reviews :-)
<sergiusens> balloons, a nicer landing page
<sergiusens> balloons, a bigger community
<balloons> sergiusens, I know why you would choose github. It's just simpler and cleaner
<kyrofa> balloons, everyone looks on github for projects before lp, too
<sergiusens> balloons, right
<balloons> just playing DA
<balloons> mostly to point out having half the project one place and half the other is a bit annoying
<kyrofa> balloons, no argument here
<kyrofa> balloons, I'd like to be able to close issues from commit messages
<balloons> ok, snappy playtime is done. Thanks for the responses guys. And enjoy your holidays!
<sergiusens> balloons, that was easy :-P
<ogra_> /whois holidays
<balloons> sergiusens, curl.curl is my favorite snappy package now btw. An IoT device with no cli network tool feels dead
 * ogra_ has a wget-unconfined snap for that :) 
<balloons> ogra_, holidays are those things other people do sometimes. I know, I know. It's weird, but the silence is refreshing
<ogra_> for old-schoolers :)
 * balloons is a wget man
<kyrofa> ogra_, wait a minute... does that mean if I like wget I'm old?
<ogra_> not as old as me i guess :)
<davmor2> ogra_: oh common, you're old school enough to know how to use sed in some archaic manner to get urls and you know it ;)
<ogra_> hah
<ogra_> someone knows me :)
<davmor2> shhhh
<ogra_> yay ... my new kbd just got into delivery !
<davmor2> ogra_: I just have deep seated respect for any developer who lived through the buttons moving wars ;) I mean I'll still treat you with disdain, sarcasm and indifference but know it comes from this deep seeated respect :D
<davmor2> -e
<ogra_> (the christmas present i made myself )
<ogra_> ha
<ogra_> "the button moving wars"
<ogra_> you should write a book ;)
<ogra_> it wasnt actually a war ... that kind of needs two parties ...
<ogra_> after all it was just me whining :)
<ogra_> (and design not reacting)
<davmor2> hahaha
<ogra_> olga paid me a beer as compensation in austin though :)
<ogra_> (in silent agreement)
<davmor2> ogra_: that's a lot of beer I mean austin isn't a little place :D
<ogra_> :D
<kyrofa> sergiusens, yeah I'm all over the place regarding "" versus `` huh
<kyrofa> sergiusens, what do you prefer?
<sergiusens> kyrofa, I was more inclined to use `` just because "markdown"
<kyrofa> sergiusens, agreed. Fixing along with the last `find`
<ogra_> are that double backticks ?
<kyrofa> ogra_, yeah
<ogra_> uuh
<sergiusens> kyrofa, done with the review
<kyrofa> sergiusens, thanks :)
<kyrofa> sergiusens, alright, fixed up
<hathatwhereshat> hey! I messed up, and forgot my password....
<hathatwhereshat> I've been looking for solutions and the only one's I find are for raspbian
<hathatwhereshat> I have a rpi2
<hathatwhereshat> has anybody come across something like this before?
<sergiusens> hathatwhereshat, what are you running?
<hathatwhereshat> snappy
<sergiusens> hathatwhereshat, and you changed the default password of ubuntu?
<hathatwhereshat> cheers for showing interest sergiusens
<hathatwhereshat> yes... I wrote the password on a note, but I wrote it down wrong
<sergiusens> hathatwhereshat, take the sdcard out; go into <writable>/system-data/var/lib/.../extrausers/shadow and edit the password there
<sergiusens> that might be a way, not sure about the exact path to the file as I don't have a system running currently
<hathatwhereshat> that's fantastic news sergiusens! thank you very much
<hathatwhereshat> I'll let you know if I can get in
<sergiusens> kyrofa, no tests have been harmed in this writing https://github.com/ubuntu-core/snapcraft/pull/178
<sergiusens> hathatwhereshat, you jst need to know the format of a shadow file `man shadow`
<hathatwhereshat> sergiusens for some reason I don't have these folders
<sergiusens> hathatwhereshat, it should be in the partition named writable
<hathatwhereshat> oh ok. thank you so much sergiusens
<sergiusens> kyrofa, I'm curious to know if you followed the link from __init__ before I made the comment it was a link
<sergiusens> seemed sneaky after doing it :-P
<hathatwhereshat> hey sergiusens , I've been trying to find this partition (I'm just starting with programming) all over the place but can't find it.. I'm on a mac and I've tried "df -h" to find the volumes, I've also tried "ls -la /Volumes" but I don't find this writable partition
<hathatwhereshat> If you can't help I'm still stupidly grateful for what you've done til now!!
<sergiusens> hathatwhereshat, oh, I have no idea how mountpoints are exposed on a mac, on Ubuntu if you plug the sdcard into a laptop it will show up on /media/<username>/writable
<sergiusens> beowulf, maybe you can help ^ ?
<sergiusens> if around of course
<hathatwhereshat> ok... I'll try a live version of ubuntu then!
<sergiusens> kyrofa, feel free to ping me about whatever, but I am mostly EOY now :-)
<jerryG> any new url for 'snappy gui anyone?'
#snappy 2015-12-19
<davidcalle> jerryG: are you looking for https://docs.google.com/document/d/14msTXe_cFulk9z4jFptEjFJzZx58b1mWU_r4VivLkfA/edit ?
<jerryG> thanks david... I meant... is there an updated doc
<jerryG> since that one says 'outdated' and 'historical'
<davidcalle> jerryG: aah, I don't know :) kgunn ^ ?
#snappy 2016-12-19
<iotenthusiast> What is the format of a snap image . Is it an archive or a binary
<liuxg> iotenthusiast, you can get the answer at http://snapcraft.io/docs/snaps/intro, it is acutally a squashFS file system
<mup> PR snapd#2500 closed: tests: run snap confine tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2500>
<mup> Issue snapd#2502 opened: snap login fails on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/issue/2502>
<mup> PR snapd#2499 closed: tests: add super simple classic confinement test <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2499>
<mup> Issue snapd#2503 opened: chattr code (tests/main/chattr/task.yaml) fails on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/issue/2503>
<mup> Issue snapd#2504 opened: interfaces-upower-observe snap test fails on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/issue/2504>
<alexandersgreat> lmao this sounds so stupid
<alexandersgreat> snally
<alexandersgreat> snappy
<alexandersgreat> lmao
<alexandersgreat> sounds like shit omg
<alexandersgreat> all of you must be virgins lel
<mup> PR snapd#2505 opened: many: behave more consistently when pointed to staging and possibly the fake store <Created by pedronis> <https://github.com/snapcore/snapd/pull/2505>
<mup> PR snapd#2501 closed: tests: enable the ppc64el tests again <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2501>
<mup> Bug #1651090 opened: snap names starting with capital letters aren't supported <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1651090>
<DanChapman> jdstrand: hey. I've received this error from the store "not allowed by 'deny-connection/plug-attributes' in base declaration declaration-snap-v2_plugs_deny-connection (browser-sandbox, browser-support)"  but i'm not sure what it means.
<DanChapman> Have i declared something incorrectly https://git.launchpad.net/dekko/tree/snapcraft.yaml or is it an issue in the store review?
<morphis> DanChapman: it means that by default you're not allowed to use the 'allow-sandbox: true' attribute of the browser-support interface
<morphis> DanChapman: see https://github.com/snapcore/snapd/blob/master/interfaces/builtin/basedeclaration.go#L181
<morphis> DanChapman: you can get around this if you ask during the store review if you can still use it, then the store folks will create a snap-declaration assertion which then allows you to use that attribtute
<vigo_> fgimenez, ping
<mup> PR snapd#2506 opened: cmd/snap-confine: disable old tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2506>
<mup> PR snapd#2507 opened: tests: port first regression test from snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2507>
<DanChapman> morphis: ah ok then, that's great Thanks! :-) I will ask in the review if i can use it.
<morphis> DanChapman: depending on which snapd version you have you can try to connect via $ snap connect --dangerous ...
<fgimenez> hey vigo_ :)
<teoincontatto> Hi, there! I'm in the process of creating the SNAP for ToroDB, a java application that run as a service and replicate/transform data from MongoDB to PorstgreSQL (torodb.com). I have created a first SNAP that run as a "simple daemon".  I don't see any way to run the daemon with another user that is not root. I don't see specific documentation to udenrstand why we can/should not create an user and use it to run the service as when 
<vigo_> fgimenez, how do you flash images for pi3 and db? with dd right?
<fgimenez> vigo_, yes, for all of them
<vigo_> fgimenez, ok and how you do it?
<vigo_> I've noticed that there are different ways to dd the image, in different documents I visited
<fgimenez> vigo_, "sudo dd if=~/Desktop/ubuntu-core-16-pi2.img of=/dev/sdc bs=4M oflag=sync status=noxfer", this is recommended in the db docs and works fine for the pi's too
<vigo_> fgimenez, excellent, that's what I wanted you to confirm :) I use that from setting up the board doc
<olli> sergiusens, kyrofa do you guys have any insights for teoincontatto
<fgimenez> vigo_, great :) there's also the godd snap, probably simpler and more friendly, but haven't tried it yet
<ogra_> vigo_, you need to make pretty sure that the device isnt auto-mounted in the background by nautilus or so before dd'ing ... and you dont need to unxz ... xzcat ubuntu-core-16-pi3.img.xz | sudo dd of=/dev/sdc bs=64M is what i use
<ogra_> but yeah, use the gdodd snap ... fgimenez is correct ... thats definitely the safest
<ogra_> iirc it tests for background mounts and such ... and has a progress bar ;)
<vigo_> ogra_, thanks for confirming, I know from vrruiz that godd also works fine :). I still use dd but sure I'll try also godd
<vigo_> fgimenez, remember those boot logs that sometimes appears in "Press enter to configure" pageÂ¿
<vigo_> is there a bug to track it already?
<mup> PR snapd#2508 opened: interfaces/apparmor: ignore snippets in classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2508>
<mup> PR snapd#2509 opened: overlord/ifacestate: remove stale comments <Created by zyga> <https://github.com/snapcore/snapd/pull/2509>
<mup> Issue snapd#2510 opened: spread tests fail when invoked in a sub-directory (generate-packaging-dir) <Created by zyga> <https://github.com/snapcore/snapd/issue/2510>
<mup> PR snapd#2511 opened: spread: find top-level directory before running generate-packaging-dir <Created by zyga> <https://github.com/snapcore/snapd/pull/2511>
<Elleo> has the syntax for "stage:" changed recently? I get this when attempting to use it as per the docs: "Issues while validating snapcraft.yaml: The 'parts/stage' property does not match the required schema: ['-etc/presage.xml'] is not of type 'object'"
<Elleo> ahh, just had the wrong indentation :)
<mup> PR snapd#2512 opened: Release snapd 2.20.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2512>
<mup> PR snapd#2513 opened: don't use deprecated http.Transport.Dial <Created by teknoraver> <https://github.com/snapcore/snapd/pull/2513>
<jdstrand> DanChapman: 'allow-snadbox: true' is reserved. you can drop that. you might need to set an environment variable to make the chromium sandbox not do its namespace sandbox
<jdstrand> DanChapman: if you are using oxide, there is an env var. you might ask the oxide guys (I don't remember it otoh)
<DanChapman> jdstrand: ok. So it's fine for that to be false, ill change that then. I already set OXIDE_NO_SANDBOX in the launcher script which i think is the env var you mentioned. Thanks!
<jdstrand> DanChapman: yes, please use OXIDE_NO_SANDBOX=1 and drop allow-sandbox: true
<jdstrand> DanChapman: it should work then
<kalikiana_> jdstrand: As you're discussing this I remember wondering before: why is it that the real sandbox can't be used and the recommendation is to disable it? That looks a little upside down to my naive mind
<kalikiana_> Is there more work needed on the snapd side?
<jdstrand> kalikiana_: because the snappy sandbox and the chromium sandbox don't work well together. we have to grant a *lot* of privileges to the snap for it to use the chromium sandbox
<jdstrand> kalikiana_: it is work in the kernel and also in chromium to coordinate better with snapd
<jdstrand> kalikiana_: also, for a web app or webview, the snappy sandbox is more than enough (it is a proper sandbox after all). allow-sandbox if for a trusted browser like chrome, webbrowser-app, etc to be able to do privileged operations to then drop them immediately
<kalikiana_> Hmm okay.
<mup> Issue snapd#2514 opened: snap-confine tests fail on 14.04 <Created by zyga> <https://github.com/snapcore/snapd/issue/2514>
<nacc> kyrofa: thanks!
<mup> PR snapd#2515 opened: snap run: create "current" symlink in user data dir <Created by stolowski> <https://github.com/snapcore/snapd/pull/2515>
<kyrofa> nacc, no problem, hopefully that feature is helpful. I know I'm tired of writing python for one-liners
<nacc> kyrofa: yeah, i have i think three snaps I did a few months ago that become much more obvious and (presumably) a snapcraft.yaml with that change
<mup> PR snapd#2516 opened: tests: cancel the scheduled reboot on ubuntu-core-upgrade-no-gc and restore state <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2516>
<mup> PR snapd#2506 closed: cmd/snap-confine: disable old tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2506>
<mup> PR snapd#2507 closed: tests: port first regression test from snap-confine <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2507>
<joe> hello all
<walidof> hello all
<walidof> i need help for first login to ubuntu core
<walidof> i need localhost login name / pass
<walidof> i try add : ubuntu - ubuntu - toor - root - startx
<walidof> and the problem not solved
<mup> PR snapd#2508 closed: interfaces/apparmor: ignore snippets in classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2508>
<mup> PR snapd#2509 closed: overlord/ifacestate: remove stale comments <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2509>
<mup> PR snapd#2517 opened: tests: add hello-classic test <Created by zyga> <https://github.com/snapcore/snapd/pull/2517>
<mup> PR snapcraft#985 closed: Better message for missing snapcraft.yaml in origins <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/985>
<mfeatherston> During snap installs I keep getting connection reset by peer.  Is there any known issue with the store right now?  I don't get this from apt-get on other systems here.
<mfeatherston> if I retry it eventually goes through
<kyrofa> mfeatherston, the store and the archives are hosted in different places
<kyrofa> nessita, do you know of any store issues?
<nessita> kyrofa, no issues as far as I know
<kyrofa> mfeatherston, ^^ . Alright, thanks nessita :)
<mfeatherston> ok, thanks!
<kyrofa> mfeatherston, http://status.snapcraft.io/ might be helpful
<mfeatherston> heh, good to know, but that came back with "Our service is temporarily unavailable. We are currently working to restore it."
<kyrofa> mfeatherston, huh, interesting, I just visited it
<ssweeny> now we need a status.status.snapcraft.io
<mfeatherston> ahh, I reloaded and it came up
<mfeatherston> heh
<kyrofa> I'm not sure what to say about that :P
<mfeatherston> it's a page from Zoho saying "We'll be right back".  Either way that part is working now.
<kyrofa> nessita, that sounds odd ^^
<mfeatherston> If I look at the packet capture of my snappy system it tries to change the TCP window size and the remote server is sending me a reset
<mfeatherston> I'm wrong about the window size thing, that isn't consistent.  The resets are fairly reproducible and I've tried multiple NICs though.  I'll try this from another Internet connection later tonight.
<mup> PR snapcraft#991 closed: Updated ant plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/991>
<mup> PR snapcraft#1007 opened: lifecycle: clean without parsing if possible <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1007>
<Fohlen1> heya there .. I am trying to build a snapcraft plugin for https://github.com/Fohlen/conan-snapcraft. When using it with https://github.com/inexor-game/code/blob/fohlen/snapcraft/tool/snap/snapcraft.yaml I'm prompted with
<Fohlen1> 'NoneType' object has no attribute 'copy'
<Fohlen1> which is not a quiet detailed error log though .. and I'm a bit stumbling where/how to get started with that
<kyrofa> Fohlen1, can you pastebin the output of running `snapcraft -d`, please? (debug)
<Fohlen1> uh. the help command didn't show that it exists! http://pastebin.com/hpwN49cp
<kyrofa> Ah, Sauerbraten! That brings back memories
<kyrofa> Fohlen1, hmm, what version of Ubuntu are you on?
<Fohlen1> 16.04
<Fohlen1> err. kyrofa. from the autotools example I've just seen that I miss the return statement in schema
<kyrofa> Fohlen1, it's down in the Options of the help page, by the way
<kyrofa> Fohlen1, indeed, if you're not returning a schema it gets None
<kyrofa> Which of course, can't be copied :)
<Fohlen1> kyrofa: lovely! :)
<Fohlen1> kyrofa: is there anywhere a more extensive documentation about the plugins, or will I need to stumble through the source-code myself?
<Fohlen1> (might use code autocompletion for that, but it's still painful)
<kyrofa> Fohlen1, this is the official docs for it: https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md
<kyrofa> Fohlen1, but referring to the in-tree plugins will probably be most helpful
<Fohlen1> alrighty
<Fohlen1> kyrofa: I can happily report that it works now!
<kyrofa> Fohlen1, excellent!
<Fohlen1> maybe sometime soon we can offer a new game using snap! :)
<kyrofa> That'll be great!
<mup> PR snapcraft#1008 opened: Add a simple straightforward conan.io plugin <Created by Fohlen> <https://github.com/snapcore/snapcraft/pull/1008>
<mup> PR snapcraft#999 closed: Updated autotools plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/999>
#snappy 2016-12-20
<Joe_Dong> anyone here?
<Joe_Dong> I have a problem when using snapcraft
<Joe_Dong> https://pastebin.ubuntu.com/23656750/
<Joe_Dong> It seem the source problem. Could anyone help me with that.
<nmahendru> Hello everyone... I just downloaded go and the snapd code and I am running this command
<nmahendru> go build github.com/snapcore/snapd/...
<nmahendru> it finishes in less than a min and doesn't print out any log. and no error message. but it doesn't create anything either.
<nmahendru> any pointers as to what I might be doing wrong. I am new to go and snapd.
<nmahendru> [20:14] <nmahendru> Hello everyone... I just downloaded go and the snapd code and I am running this command [20:14] <nmahendru> go build github.com/snapcore/snapd/... [20:14] <nmahendru> it finishes in less than a min and doesn't print out any log. and no error message. but it doesn't create anything either. [20:16] <nmahendru> any pointers as to what I might be doing wrong. I am new to go and snapd.
<mup> PR snapcraft#1009 opened: Implement push pre-check <Created by squidsoup> <https://github.com/snapcore/snapcraft/pull/1009>
<jdstrand> ogra_: hey, I have a series 16 all snaps vm using the provided images. what is the correct way to setup a swap file? I created the file, did swapon and all that is fine, but fstab is overwritten on boot
<Joe_Dong> http://pastebin.ubuntu.com/23657170/
<mup> PR snapd#2505 closed: many: behave more consistently when pointed to staging and possibly the fake store <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2505>
<vigo> fgimenez, ping
<vigo> fgimenez, some tasks failed yestarday on db
<vigo> https://pastebin.canonical.com/173929/
<vigo> have you seen any of this?
<fgimenez> vigo, hey, you should execute the suite from the release/2.20.1 branch, there's also a fix for the random reboot that haven't landed yet https://github.com/snapcore/snapd/pull/2516/files, could you please rerun applying that patch from the release branch?
<mup> PR snapd#2516: tests: cancel the scheduled reboot on ubuntu-core-upgrade-no-gc and restore state <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2516>
<teoincontatto> Hello! Is there any way to access a unix socket created by an external process (like postgresql) from a SNAP?
<ogra_> jdstrand, that would need either some extra code in initramfs (which creates the fstab) or a dedictaed systemd unit that calls swapon etc
<ogra_> (i think i'd actually opt for the latter)
<mardy> Kaleo: hi! Do you know where the desktop-launch helper is coming from?
<Elleo> mardy: iirc it comes from either the desktop-qt5 or desktop-gtk3 parts, depending on which you use
<mardy> Elleo: I'm browing through https://github.com/ubuntu/snapcraft-desktop-helpers, but I cannot find it
<mardy> Elleo: ah, got it, it's generated by a makefile :-)
<Elleo> mardy: it looks like the launcher-specific file gets installed as it
<mardy> Elleo: like here: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/gtk/Makefile
<Elleo> yeah :)
<morphis> ogra_: where do I file bugs for the pi2 kernel snap?
<jdstrand> ogra_: ack, thanks. I think I'll make a devmode snap for now and think about this over the holiday
 * jdstrand -> back to enjoying holiday :)
<liuxg> elopio, ping
<liuxg> sergiusens, kyrofa do you see this bug at https://bugs.launchpad.net/snapcraft/+bug/1650946.. Now I am trying to build a classic app on 16.04
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:New> <https://launchpad.net/bugs/1650946>
<jacekn> could somebody have a look at https://bugs.launchpad.net/snappy/+bug/1650671 and tell me if there is any info missing? It would be great if content interface could be fixed
<mup> Bug #1650671: Content sharing from snap common is broken <Snappy:New> <https://launchpad.net/bugs/1650671>
<bull_> guys am having issues with nwjs app while snaping it
<bull_> log says adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.*
<bull_> how can i do this please :(
<bull_> zyga: help
<bull_> mhall119: hi bro
<bull_> i also having pulseaudio in my plugs and my app cant produce audio
<jdstrand> ogra_: fyi, https://code.launchpad.net/~jdstrand/+git/swaps
<mup> PR snapd#2517 closed: tests: add hello-classic test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2517>
<jdstrand> ogra_: I know that isn't what you had in mind, but I have a swap file on my vm now ;)
<bull_> how to set $XDG_RUNTIME_DIR in snap??
<bull_> https://bugs.launchpad.net/snap-confine/+bug/1620442
<mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Fix Committed by jdstrand> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1620442>
<ogra_> jdstrand, hah, cool, thats a way cleaner solution :)
<ogra_> (not to far from my second suggestion either ... i didnt think about snapping it ... )
<bull_> ogra_:  export: XDG_RUNTIME_DIR:/dev/shm/snap.simple-gulp.*: bad variable name
<bull_> snapd is still affected by this bug
<ogra_> bull_, uh, what does /dev/shm have to do with XDG ?
<ogra_> thats surely not right
<bull_> ogra_: idont know
<bull_> this is what am getting man
<ogra_> well, why do you ry to set that var to it ?
<ogra_> *try
<bull_> cause https://bugs.launchpad.net/snap-confine/+bug/1620442/comments/7
<mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Fix Committed by jdstrand> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1620442>
<bull_> check this out man
<ogra_> XDG_RUNTIME_DIR needs to point to a user owned dir under /run ... /dev/shm is a memory sharing device ... the two are completely unrelated
<ogra_> (device vs chaching dir for apps)
<bull_> sho what you suggest me to do ?
<bull_> my app not russing cause of this isue
<ogra_> fix your app to write to a subdir of /dev/shm, not to /dev/shm directly
<ogra_> (i think the apparmor message even says so)
<bull_> its based on nwjs man i cant fix that :(
<ogra_> totally not related to any XDG vars
<ogra_> you need to fix your app
<bull_> ogra_:  yes it is
<ogra_> seems it has /dev/shm hardcoded somewhere
<bull_> no man
<bull_> it is a simple nwjs app
<ogra_> it surely does
<ogra_> either your app or whatever interpreter it uses then
<bull_> so am not telling chromium engine to write anything it is configured by them
<bull_> the team
<ogra_> well, read up about the browser interface if you use a browser
<ogra_> again,. totally unrelated to any xdg stuff
<bull_> yes browser interface is there
<bull_> read that bug man
<bull_> that is reproduced by my condition so its a bug :(
<ogra_> your problem is about /dev/shm
<ogra_> read the bug ;)
<ogra_> not related at all
<ogra_> the bug is about dirs under /run
<bull_> how to configure hard coded chromium stuff :D
<ogra_> no idea
<bull_> lol
<bull_> am fkked
<bull_> after making apps they fails at end while packaging :D
<ogra_> i'd read up about the browser interface, about how it handles /dev/shm and about the browser sandboxing
<ogra_> and now i'm back on vacation
 * ogra_ goes back to his soldering iron and multimeter ...
<bull_> you on vacations?
<bull_> everyone is :(
<ogra_> yes
<ogra_> most employees are
<bull_> till ?
<ogra_> new year at least
<bull_> i made same app with qwebengine and failed at last while snapping it :D so i ported to nwjs and same here :(
<bull_> ogra_:  enjoy :D
<ogra_> anyway, that bug is unrelated to your prob (i'm sure there is one about /dev/shm and chromium sandboxes too though
<ogra_> )
<bull_> where r u from ?
<ogra_> germany
<bull_> it is not related to bug :D
<bull_> :D
<bull_> m from india
<bull_> man
<bull_> can how can we - adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.*
<bull_> is /dev/shm/* is allowed to be written by snaps ??
<bull_> ogra_:  :(
<bull_> am going for dinner tyl
<kalikiana_> bull_: only if you use the snappy subfolder
<mup> PR snapcraft#1010 opened: Add 'desktop' and 'icon' entries for apps (LP: #1588359) <Created by oSoMoN> <https://github.com/snapcore/snapcraft/pull/1010>
<bull_> kalikiana_: ??
<bull_> hi ogra_
<shuduo> ogra_: hi, is the 410c's gadget project on github https://github.com/snapcore/dragonboard-gadget the one current image use? I remember old gadget contained meta/snap.yaml file then ubuntu-image use it to find local gadget file. Now how to generate it if no meta/snap.yaml?
<mup> PR snapcraft#1011 opened: travis: use docker run -w option to set working dir <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1011>
<kalikiana_> bull_: You asked if you can write to /dev/shm - if you read the error message again you'll see that it answers your question
<bull_> kalikiana_: i says permission denied
<bull_> it
<bull_> how to adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.*
<bull_> AppArmor  suggest this
<bull_> AppArmor  thinks snaps can write in /dev/shm/*
<bull_> kalikiana_: ?
<kalikiana_> bull_: Yes, exactly
<kalikiana_> You can write to the subfolder
<kalikiana_> But if you try to write somewhere else, say /dev/shm/foobar it won't work
<bull_> kalikiana_  i did this https://pastebin.ubuntu.com/23659442/
<bull_> but it wont affect
<bull_> kalikiana how to set that path that is the ain problem man
<bull_> kalikiana_: firefox team also reported this error :D
<bull_> kalikiana_: https://lists.ubuntu.com/archives/snappy-devel/2016-May/001800.html
<mup> PR snapcraft#1012 opened: travis.yaml: use docker exec to split build phases <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1012>
<bull_> ogra_: https://bugs.launchpad.net/snapcraft/+bug/1577514
<mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
<bull_> ogra_: nwjs is based on chromium too
<mfeatherston> Does anyone recognize this error?  I'm wondering if I missed a kernel patch.  I'm on ubuntu core with a custom kernel:
<mfeatherston> cannot bind-mount the mount namespace file /proc/2236/ns/mnt -> hello-world.mnt. errmsg: Permission denied
<mfeatherston> support process for mount namespace capture exited abnormally
<bull_> zyga: :(
<jacekn> could somebody have a look at https://bugs.launchpad.net/snappy/+bug/1650671 and tell me if there is any info missing? It would be great if content interface could be fixed
<mup> Bug #1650671: Content sharing from snap common is broken <Snappy:New> <https://launchpad.net/bugs/1650671>
<mup> PR snapd#2518 opened: many: put a marker in the User-Agent sent by snapd/snap when under testing <Created by pedronis> <https://github.com/snapcore/snapd/pull/2518>
<hernajua> Hi, I was wondering if I am allowed to create a snap package of software I did not write
<mup> PR snapd#2519 opened: tests: skip packaging dir generation for non-git based autopkgtest runs <Created by mvo5> <https://github.com/snapcore/snapd/pull/2519>
<mup> PR snapcraft#1000 closed: Updated godeps plugin to use get_pull_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1000>
<kyrofa> hernajua, nothing is stopping you. It's possible for upstream to request the name, though
<mfeatherston> is snapcraft expected to build with multiple cores for kernels?
<mfeatherston> ahh, I missed it, it passes -j1 only for the config step but switches to more cores after that
<kyrofa> mfeatherston, indeed
<kyrofa> mfeatherston, pure death otherwise :P
<grapestomper> I am looking for help on how to search all snapcraft.yaml files examples on github with a unique parts section. For instance I would like to search for how others have added subdirectories of git repositores.
<grapestomper> I found something like this before one the canonical pages but I cant seem to find it now
<grapestomper> Diff Question - Is there a way to have a file copied to the "users" home directory, when a snap is installed? For instance - when you install a snap a README.md file is copied to "/home/<user>/"
<kyrofa> grapestomper, I'm not sure what you're asking. subdirectories of git repositories?
<kyrofa> grapestomper, you mean e.g. your Makefile is located in a subdirectory?
<grapestomper> hi kyrofa - in my main git folder I have two sub folders were code that I want to compile lives. The folder structure is only for sanity puposes, but its where the code is
<kyrofa> grapestomper, is it two separate projects, then?
<cachio> jdstrand, hy
<cachio> hi
<cachio> jdstrand, I am getting not allowed by 'deny-connection/slot-attributes' in base declaration declaration-snap-v2_slots_deny-connection (kpi-dbus-signals, dbus)
<grapestomper> :) yes - I could be using git wrong
<cachio> jdstrand, trying to submmit the snap
<cachio> jdstrand, any idea?
<grapestomper> kyrofa - I use subfolders to seperate projects. Maybe its not a good idea?
<kyrofa> grapestomper, so you have a git repository containing two independent projects? Or does one depend on the other?
<grapestomper> kyrofa - two independant projects
<kyrofa> grapestomper, do you only want one in the snap, then?
<grapestomper> kyrofa - yes
<kyrofa> grapestomper, oh, well then, that's easy. Use the `source-subdir` option
<grapestomper> ok - found that in the docs. I was looking for an example of that being used - have you seen one?
<grapestomper> an example that is
<kyrofa> grapestomper, I'm working on one as we speak, actually
<kyrofa> Not an example, but using it rather
<kyrofa> grapestomper, it's pretty simple: just a relative path from the root of the source
<kyrofa> And then snapcraft will run make (or whatever) from there
<hernajua> quit
<mup> PR snapcraft#1001 closed: plugins: update catkin plugin to use get_pull_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1001>
<grapestomper> kyrofa - thanks
<grapestomper> I will give it  go
#snappy 2016-12-21
<grapestomper> Does anyone know how to instruct snapcraft to copy a file to a users home dir (/home/<user>) when a snap is installed?
<kalikiana_> grapestomper: You can do that in the script of the "app" in the snap. Check if it exists, creatie it otherwise
<kalikiana_> At least that's what I've found straight-forward for what I needed
<kalikiana_> tsdgeos: What's the status of https://github.com/ubuntu/snapcraft-desktop-helpers/pull/30 ? Are you also looking into a way of selecting a system-wide theme? Or is it per-snap still?
<mup> PR ubuntu/snapcraft-desktop-helpers#30: [WIP] Add ubuntu-app-themes to paths <Created by tsdgeos> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/30>
<tsdgeos> kalikiana_: there's no status, i sent an email about it to the mailing list asking if that is what the 2 words on the trello card meant
<tsdgeos> and i got no answer
<tsdgeos> so i guess noone really cares
<tsdgeos> so without anyone telling me what we relly need
<tsdgeos> i can't do anything
<tsdgeos> so i just left it to rot
<tsdgeos> kalikiana_: unless you know of someone that actually knows what the 2 words on the trello card mean
<kalikiana_> tsdgeos: The one which just says "themes"? To me your approach definitely looks sensible. There's just two things that are unclear to me a) how do you select a system-wide theme b) can you install theme snaps from third party developers
<tsdgeos> kalikiana_: a) whith the same tool you do it normally (we may need to patch it so that it writes the config to where it is read, but if all was good it would be using XDG_ stuff and it would just work)
<tsdgeos> and b) no afaics
<kalikiana_> I suppose Canonical-provided themes would be a good start anyway, compared to none at all. But it seems like the next step to make it actually usable.
<kalikiana_> jdstrand_: Perhaps you might know about b)? ie. are there any plans to allow content snaps for specific purposes such as theming that come from third parties?
<kalikiana_> Possibly with manual review via declaration?
<vigo> fgimenez, morning!
<vigo> here is the output from yestarda's spread run
<vigo> https://pastebin.canonical.com/174080/
<vigo> only 3 failed
<vigo> it is the first time I see interfaces-bluez failing
<fgimenez> vigo, hi! interfaces-bluez and server-snap:pythonServer are failing in that paste because of timeouts from the store
<fgimenez> vigo, i've seen before the error from ubunto-core-reboot, the snap service is not up on time after a reboot, but haven't been able to reproduce after increasing the waiting time a while ago, maybe we need to adjust it further
<fgimenez> vigo, ubuntu-core-device-reg is different, i've seen it also in pi2 and 3, it seems that the device registration change is not in the changes list, the change with id 1 is missing, need to dig a little bit more into this
<mup> PR snapd#2520 opened: many: fix abbreviated forms of disconnect <Created by zyga> <https://github.com/snapcore/snapd/pull/2520>
<vigo> fgimenez, great thanks for the input
<vigo> I'll start with pi3 and once I got the results I'll share them if something goes wrong. It's a bit hard to have a successful run on db :(
<mup> Bug #1651722 opened: Latest candidate snap breaks running snapcraft in classic snap <Snappy:New> <https://launchpad.net/bugs/1651722>
<arm1e> Can someone please help me with snappy on a different distro. Getting these errors https://hastebin.com/ahadeleboc.sql
<arm1e> Have tried with suda and same error
<arm1e> *sudo
<tsdgeos> arm1e: is snapd running?
<arm1e> should be. hold on
<arm1e> nope https://hastebin.com/ecuralozot.sql
<tsdgeos> then that's the problem
<arm1e> I did set it via systemctl enable snapd.service though
<arm1e> what have I done wrong?
<arm1e> tried to manually start, but still fails with the same error
<arm1e> others are now having the same issue
<mup> PR snapd#2521 opened: interfaces: implement interface to allow read/write access to real-time clock <Created by morphis> <https://github.com/snapcore/snapd/pull/2521>
<mup> PR snapd#2522 opened: tests: optionally use apt proxy for qemu <Created by zyga> <https://github.com/snapcore/snapd/pull/2522>
<arm1e> weirdly the snapd.socket seems to be fine :https://hastebin.com/musahurame.js
<mup> PR snapd#2523 opened: tests: port snap-confine regression test for LP: #1595444 <Created by zyga> <https://github.com/snapcore/snapd/pull/2523>
<arm1e> Got snapd d working in opensuse!
<cachio> jdstrand_, there=
<cachio> ?
<mup> PR snapcraft#1013 opened: Cloudbuild <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1013>
<mup> PR snapd#2524 opened: Overmount <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2524>
<grapestomper> kalikiana - can you point me to an example? I have not seen this done before.
<mup> PR snapd#2525 opened: tests: increase wait time for service to be up <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2525>
<cachio> pedronis, hey
<cachio> pedronis, trying to publish my snap I am getting this ==> not allowed by 'deny-connection/slot-attributes' in base declaration declaration-snap-v2_slots_deny-connection (kpi-dbus-signals, dbus)
<pedronis> cachio: you need a reviewer to approve using the interface, probably jamie but he is already off IÂ think
<cachio> pedronis, ok, any idea when he is back?
<pedronis> cachio: afaict, beginning of next year
<cachio> pedronis, ok, do you know if anyone else is making manual reviews?
<pedronis> there are other reviews, but dbus stuff is fairly new, so not sure who else can approve that atm
<pedronis> s/reviews/reviewers/
<pedronis> I'm not one fwiw
<cachio> pedronis, ok, thanks
<mup> PR snapd#2526 opened: tests: show --version when it matches unknown <Created by zyga> <https://github.com/snapcore/snapd/pull/2526>
<mup> PR snapd#2522 closed: tests: optionally use apt proxy for qemu <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2522>
<pwik> Has anyone tried snapping a mkbundled Mono application that makes secure HTTP requests? I can't seem to find a way for snapcraft to include certificates when building.
<grapestomper> does anyone know the web address of the #snappy conversation archive
<genii> !irclogs
<ubottu> Official channel logs can be found at https://irclogs.ubuntu.com/ . LoCo channels are now logged there too. Meetingology logs at https://ubottu.com/meetingology/logs/
<ToX82> hey there, anyone knows how to translate packages installed with snap? I have vlc installed and I can see the translation files in `/snap/vlc/1/share/locale`, but still the app is in english...
<grapestomper> ubottu - thanks
<ubottu> thanks aliases: thanks!, thank you, thankyou, ty, thanks., thanx, ok, thanks :), domo arigato, thx - added by Mez on 2006-09-09 08:48:38
<mup> PR snapd#2526 closed: tests: show --version when it matches unknown <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2526>
<jacekn> hello. Any snappy devs here? I've spent hours trying to figure out why content interface is broken and could not figure it out
<jacekn> is anybody available to at least triage this bug: https://bugs.launchpad.net/snappy/+bug/1650671 ? I'd like to know if there is any missing info
<mup> Bug #1650671: Content sharing from snap common is broken <Snappy:New> <https://launchpad.net/bugs/1650671>
<arm1e> got snapd running on opensuse, but when snaps have been installed they can not be found or started. I can uninstall no problem. Any ideas?
<arm1e> snapd has not added anything to /etc/profile.d. How can I fix this please?
<nacc> arm1e: on ubuntu, this is what is in /etc/profile.d/apps-bin-path.sh: http://paste.ubuntu.com/23664890/
<nacc> arm1e: i woudl suggest filing a bug with opensuse's snapd package :)
<arm1e> okay. Do they manage the package themselves?
<nacc> arm1e: i have no idea :/
<arm1e> np
<nacc> arm1e: i'm not sure how to figure out who created the opensuse package(s) from cursory googling, but that there's where i'd start
<kyrofa> zyga, do know anything about suse? ^^
<ogra_> ogra@anubis:~$ cat /etc/profile.d/apps-bin-path.sh
<ogra_> # Expand the $PATH to include /snap/bin which is what snappy applications
<ogra_> # use
<ogra_> PATH=$PATH:/snap/bin
<ogra_> arm1e, ^^^ try that
<ogra_> (not sure if the suse package ships such a snippet by default)
<nacc> ogra_: yeah that's what i pastebin'd to them earlier, i think the bug is that perhaps suse's pacakge does not)
<ogra_> yep, i think the same
<arm1e> will try to add manually.
<arm1e> they also failed to add the /var/lib/snapd folder too, which I managed to do manually
<arm1e> added. Do I need to logout and in?
<ogra_> yeah
<arm1e> brb
<arm1e> back again.
<arm1e> tried with speed-test snap but wont run. Complains about lack of root, but sudo speed-test returns command not found
<arm1e> need to run as root or suid. errmsg: No such file or directory
<ogra_> i assume your kernel has not the necessary apparmor patches ... try removing the snap and installing with --devmode
<arm1e> ok
<arm1e> same error
<arm1e> weird
<ogra_> try "sudo /snap/bin/speed-test"
<arm1e> ok
<ogra_> it is likely your sudo doesnt know the path either
<arm1e> cannot bind mount /media to /tmp/snap.rootfs_0x5rWB/media. errmsg: No such file or directory
<ogra_> (the sudo path usually differs from the shell path the user has ... for security reasons added bits get dropped)
<arm1e> any fixes?
<ogra_> (the path is set in /etc/sudoers normally)
<ogra_> ogra@anubis:~$ sudo grep path /etc/sudoers
<ogra_> Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
<ogra_> ogra@anubis:~$
<ogra_> thats what i have on ubuntu
<arm1e> Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin"
<arm1e> suse
<ogra_> yeah, as i expected ... no /snap/bin
<arm1e> so just add to end?
<ogra_> yep, use visudo though, it has a check (to avoid typos that then prevent you from ever sudoing again)
<arm1e> not sure my way around vi
<arm1e> sod it, just used nano
<ogra_> well, then open a second terminal ... run "sudo -s" in there to keep a root shell open ... edit in the other terminal and only close the root term once you are 100% sure you didnt mess up ;)
<AlbertA> ogra_: do you know where the sources are for the rpi2/3 snappy kernel?
<ogra_> that way you have a safety net
<ogra_> AlbertA, somewhere on kernel.ubuntu.com but dont ask me for the exact place :)
<arm1e> tried sudo speed-test but still not found
<AlbertA> ogra_: cool thanks
<ToX82> hey there, anyone knows how to translate packages installed with snap? I have vlc installed and I can see the translation files in `/snap/vlc/1/share/locale`, but still the app is in english...
<ogra_> arm1e, well, not sure if sudo would need a re-login as well (theoretically it should not, but who knows)
<arm1e> brb
<ogra_> ToX82, Bug #1576282
<mup> Bug #1576282: Snaps built from deb can't be gettext translated <personal> <snap-desktop-issue> <Canonical System Image:In Progress> <Snapcraft:New> <Ubuntu
<mup> App Platform:In Progress by tpeeters> <snapcraft (Ubuntu):Confirmed for sergiusens> <unity8 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576282>
<arm1e> nope, still nothing I am afraid :(
<ogra_> so only if you use the full path ? ... sad
<arm1e> I have filed a bug
<arm1e> didnt even work with full path
<ogra_> it said "not found" ?
<ogra_> even with full path ?
<arm1e> cannot bind mount /media to /tmp/snap.rootfs_0x5rWB/media. errmsg: No such file or directory
<mup> PR snapd#2527 opened: tests: fix -reuse and -resend when govendor is missing <Created by zyga> <https://github.com/snapcore/snapd/pull/2527>
<ogra_> right, thats different ... so it then finds it
<ogra_> (there seems to be another bug with the medis mount)
<ToX82> thanks a lot mup, I will follow it!
<ogra_> s/medis/media/
<ogra_> arm1e, i wonder ... what does "snap version" return on suse ?
<mup> PR snapd#2528 opened: tests: speed up update_core_snap_with_snap_exec_snapctl <Created by zyga> <https://github.com/snapcore/snapd/pull/2528>
<ogra_> (i guess you want something like 2.17 at least)
<arm1e> snap version is not a command
<arm1e> is it --?
<arm1e> 2.14
<ogra_> should both work ... only very old versions needed --
<ogra_> yeah, rather old
<arm1e> 2.14.2
<ogra_> so your snapd likely misses features
<arm1e> shit
<ogra_> i.e. the mounting of the media dir
<arm1e> looks like no snapd for a while then
<ogra_> as i said, zyga usually does the cross distro stuff ... but we're all on vacation til end of the year ... so he might not watch IRC much atm
<arm1e> np
<arm1e> thanks for your help
<ogra_> np
<ogra_> thanks for trying snappy ;)
<arm1e> I filed a bug on suse then
<arm1e> your welcome. At least it still works on my other machine
<zyga> ogra_: hey
<ogra_> yo
<zyga> arm1e: yes, I'm pretty off lately
<zyga> arm1e: I suggest using https://rocket.ubuntu.com/channel/snappy as I get notifications there
 * zyga needs to EOD, ttyl
<zyga> feel free to leave me a message there
<mup> Bug #1637934 opened: update install hook documentation <Snappy:New> <https://launchpad.net/bugs/1637934>
<mup> Bug #1619154 opened: Cannot adjust systemd service definition <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1619154>
<mup> PR snapcraft#992 closed: plugins: update make plugin to use get_build_properties()  <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/992>
<mup> PR snapcraft#1014 opened: tests: reorganize plugin tests into subdirectory <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1014>
#snappy 2016-12-22
<mup> PR snapcraft#1015 opened: tests: reorganize command tests into subdirectory <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1015>
<mup> PR snapcraft#996 closed: Updated nodejs plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/996>
<knight__> Ok folks, so how can I run a mkdir in a snapcraft.yaml inside of a part before it builds?
<knight__> shell-command?
<grapestomper> knight - do you know how to make snapcraft execute a shell command during the build process?
<knight__> grapestomper, yes, but i'm not sure if that will fire before, during, or after the build itself
<knight__> it seems that i can create a part focused on shell commands, but i can't run an arbitrary shell command inside of a part itself
<knight__> it looks like i have to make the part a shell plugin and do the compilation manually in shell commands, rather than use the make plugin
<knight__> what version of snapcraft has the new shell plugin?
<grapestomper> knight - kindof greek to me. I have also wanted to know who to do this.
<grapestomper> who = how
<mup> Bug #1651936 opened: autopkgtests fail on ppc64el <Snappy:New> <https://launchpad.net/bugs/1651936>
<grapestomper> first time using snapcraft to compile with make = error
<grapestomper> here is the error I am seeing ->> http://pastebin.com/vSXsAyGB
<grapestomper> here is the source ->> https://github.com/chadyoungdell/Snappy_Ubuntu_Core/tree/master/Snapcraft_2.x/hello_cpp
<grapestomper> would someone mind taking a look?
<grapestomper> the standalone Makefile works fine, but add snapcraft and it pukes
<liuxg> nowadays, I see  a lot of "Use of build-properties in the schema is deprecated" during building a snap project. How can I get rid of the warnin? thanks
<aravinth> system
<aravinth> ignore
<aravinth> ignore_all
<mup> PR snapcraft#1016 opened: cmake: extend parte build properties as it extends make <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1016>
<mup> PR snapcraft#1017 opened: make: add support for cwd path <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1017>
<cachio> ogra_, hey, I am integrating some tests execution in jenkins and I would like to trigger the job when a new core is available in edge channel, do you already have something for that? I mean automatically detect there is a new available version
<ogra_> cachio, not really, you could screen scrape the timestamp from http://people.canonical.com/~ogra/core-builds/ but that only monitors automated builds ...
<ogra_> if you want to do it properly you probably want to write an lp-lib script
<cachio> ogra_, ok
<cachio> ogra_, I'll start checking in that page from jenkins and then I'll og for a lp-lib script
<ogra_> sounds like a plan :)
<cachio> ogra_, yes, kind of
<liuxg> sergiusens, now I have found the same issue as https://bugs.launchpad.net/snapcraft/+bug/1650946, how can I resolve this problem? thanks
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:New> <https://launchpad.net/bugs/1650946>
<grapestomper> looking for help on an error I am seeing ->> http://pastebin.com/vSXsAyGB
<mup> PR snapcraft#1016 closed: cmake: extend parte build properties as it extends make <Created by 3v1n0> <Closed by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1016>
<mup> PR snapcraft#1018 opened: autotools: extend Make plugin instead of repeating code <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1018>
<mup> PR snapd#2529 opened: interfaces: mm: permissions for protocol proxies <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2529>
<mup> PR snapcraft#997 closed: plugins: update go plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/997>
<mup> PR snapcraft#1019 opened: tests: reorganize state tests into subdirectory <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1019>
<mordor> hi all ... can I ask a question ?
<mup> PR snapcraft#1002 closed: plugins: update python plugin to support get_pull_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1002>
<wililupy> Is there an example of using the shell snippets in snapcraft?
<kyrofa> wililupy, yessir, hold on
<wililupy> thanks kyrofa.
<kyrofa> wililupy, well, wait. Are you just wanting to run a shell script? Or run specific parts of the build via shell commands?
<kyrofa> Hmm... those sound the same huh :P
<wililupy> kyrofa: run a shell script.
<kyrofa> wililupy, to do what, exactly. Are we talking fboss here?
<wililupy> kyrofa: yes. I want to see what happens if I run this shell script that was sent to me to build it.
<kyrofa> wililupy, well the `apt install` commands might prove troublesome if you ever want to build on launchpad, so I still recommend extracting those into build/stage packages as necessary
<kyrofa> wililupy, but other than that, I'd wrap the script in a Makefile so you can take care of the install step as well
<kyrofa> (since they don't write any)
<kyrofa> Then you can get rid of your custom plugin
<wililupy> kyrofa, this is just for a test right now. I should be able to use the dump plugin for install since its just the agent and a config file.
<wililupy> oh, and the py for testing the routes.
<kyrofa> wililupy, I'd still do it in a Makefile, just make an install rule that does nothing if you like
<wililupy> kyrofa: Ack.
<mcphail> Hi. I'm trying to use "snapcraft cleanbuild" but I'm getting errors about missing network access as per http://termbin.com/xcfe . I know nothing about setting up networks in lxc. Shouldn't this be handled automatically by snapcraft? How can I fix this?
<grapestomper> mordor - what was your question?
<grapestomper> kyrofa - do you know how to make a file get moved to the users home dir (/home/user) when a snap get installed? if so can you point to an example?
<kyrofa> mcphail, why do you think lxd doesn't configure it?
<kyrofa> (snapcraft doesn't for the same reasons)
<kyrofa> grapestomper, there are a number of ways. You can do it in a wrapper script upon startup, or you can do it in the `configure` hook assuming you're up-to-date enough to use it
<mcphail> kyrofa: this is opaque to me just now. What do I need to understand to resolve it?
<kyrofa> grapestomper, which sounds best to you? Then I can show you an example :)
<kyrofa> mcphail, yeah, ignore snapcraft. Get lxd/lxc working, and once you have that cleanbuild will work
<kyrofa> mcphail, let me find something, hold on
<mcphail> kyrofa: thanks
<kyrofa> mcphail, I think this might help: https://insights.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-explained/
<kyrofa> Hrmm... no wait
<kyrofa> It's not that complex
<kyrofa> mcphail, yeah, just run `sudo lxd init`
<kyrofa> It's a little wizard that'll walk you through setting stuff up
<mcphail> kyrofa: ok, although I'm sure I've played with lxd on this box before...
<kyrofa> mcphail, snapcraft just runs `lxd launch ubuntu:xenial -e` essentially
<kyrofa> Err, lxc
<mcphail> "error: You have existing containers or images. lxd init requires an empty LXD."
<grapestomper> kyrofa - thanks, do you now know were I can start reading about wrapper scripts? I dont see this on the snapcraft page. I will seach for the configure hook on my own.
<kyrofa> grapestomper, there's nothing to read. Let's say you have a binary called X that you wanted to run as a service
<kyrofa> grapestomper, but X requires a config file in $SNAP_DATA (or whatever)
<kyrofa> grapestomper, so instead of using `command: X` in your YAML, you use `command: run-X` and write a script called `run-X` that copies the config file and then runs X
<kyrofa> I forget X is an actual product. I should have used Y
<grapestomper> kyrofa - thanks
<kyrofa> mcphail, I suggest you read up on lxd/lxc, then: https://linuxcontainers.org/lxd/getting-started-cli/
<kyrofa> grapestomper, here's an example: https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml#L35
<kyrofa> grapestomper, that exists for two reasons: to create redis' logging directory, and rewrite its config: https://github.com/nextcloud/nextcloud-snap/blob/master/src/redis/scripts/start-redis-server
<mup> PR snapcraft#993 closed: plugins: update qmake to use get_build_properties and get_pull_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/993>
<mcphail> http://termbin.com/rv2u - this curses-based app prints garbage extra characters to the terminal when run as a snap, but works fine when run from stage/usr/local/bin/sneakers . Any idea what I need to tweak or add to get a curses app to work properly?
#snappy 2016-12-23
<mup> PR snapcraft#998 closed: plugins: update gulp plugin to use get_build_properties() and get_pull_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/998>
<liuxg> has anyone got the alias working on the snapcraft 2.24? I just found that example code at https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/alias/snapcraft.yaml. when I run it, I get the error like "/snap/my-alias/x3/command-hello.wrapper: 5: exec: /snap/my-alias/x3/hello.sh: Permission denied". I tested it on 16.04 desktop
<nholloway> Hi,. guys. I just installed Ubuntu Core in a QEMU/KVM, and can anyone tell me why I can't run 'sudo passwd' without getting an authentication token manipulation error?
<mup> PR snapcraft#995 closed: plugins: update kernel plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/995>
<nholloway> Hi, guys, I'm trying to set up LXD in Ubuntu Core. It tells me lxd is not found. I'm in the lxd group (that I had to create), and it still fails when I run 'sudo lxd init'. Can anybody help me out?
<mup> PR snapcraft#1020 opened: Change hello.sh to be executable <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/1020>
<mup> Bug #1635584 changed: "snap interfaces" output hides some magical, essential package name <Snappy:Expired> <https://launchpad.net/bugs/1635584>
<liuxg> does anyone know how to enable alias for snap application? thanks
<zyga> liuxg: hey
<zyga> liuxg: do you mean the new aliases feature?
<liuxg> zyga, yeah, I just figured it out.
<zyga> liuxg: ah, great, I haven't used it yet
<liuxg> zyga, I have to enable it using commands, and I wrote a blog for it at http://blog.csdn.net/ubuntutouch/article/details/53839566
<liuxg> zyga, thanks for answering :)
<mup> PR snapd#2530 opened: tests: use MATCH in install-remove-multi <Created by zyga> <https://github.com/snapcore/snapd/pull/2530>
<mup> PR snapd#2531 opened: tests: make debug-each succeed if DENIED doesn't match <Created by zyga> <https://github.com/snapcore/snapd/pull/2531>
<mcphail> http://termbin.com/rv2u - this curses-based app prints garbage extra characters to the terminal when run as a snap, but works fine when run from stage/usr/local/bin/sneakers . Any idea what I need to tweak or add to get a curses app to work properly?
<zyga> mcphail: perhaps it cannot access terminal profiles under hardcoded path in /usr/lib or /usr/share
<zyga> as they are most likely in the core snap
<mcphail> zyga: do you know of any workarounds?
<zyga> mcphail: patch ncurses in your snap to look for those profiles elsewhere
<mcphail> zyga: hmm. Would be better to have a more generic solution for curses apps, dont you think?
<zyga> mcphail: such as?
<zyga> ideally curses upstream would understand and use the $SNAP environment variable
<mcphail> zyga: perhaps a "curses" snap interface which exposes the correct directories?
<zyga> mcphail: exposes them from where?
<mcphail> zyga: from the host os
<zyga> mcphail: the host os can be just snappy core, then you don't have them
<zyga> mcphail: or they can be in a wrong format (different major version of curses)
<zyga> mcphail: I think they have to be in the snap
<mcphail> zyga: surely snappt core has them as well?
<zyga> mcphail: if it did you'd have no problems
<zyga> mcphail: as your app works against the core snap today
<zyga> mcphail: perhaps the core has some basic profiles but I bet it doesn't have all the various profiles people get with extra packages
<mcphail> zyga: aah. I see
<zyga> mcphail: the overmount interface can be of some help
<zyga> mcphail: but that's a hack IMHO
<mcphail> zyga: ok. Thanks. That gives me something to explore
<zyga> mcphail: https://github.com/snapcore/snapd/pull/2524
<mup> PR snapd#2524: Overmount <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2524>
<ogra_> mcphail, https://github.com/ogra1/nethack ... (old but most likely still relevant)
<zyga> mcphail: that's not merged yet
<mcphail> ogra_: cheers. Will have a look
<ogra_> :)
<mcphail> ogra_: I'll try adding those stage-packages. The names sound promising!
 * ogra_ notes that most of his snaps need updating ... but i try to stay away from my computer during vacation 
<ogra_> mcphail, also look at the wrapper
<longsleep> ogra_: moin folks, i just built a snappy edge image and only get RuntimeError: nl_get_multicast_ids failed: -2 when trying to configure - http://paste.ubuntu.com/23672389/ - known bug?
<ogra_> longsleep, not to me ... sounds like a missing bit in the netwrok interface
<ogra_> oh, sorry ... i should hav clicked the paste first ... definitely a bug !
<longsleep> ogra_: ok, is there anything i can do to access the thing to get some more debug?
<zyga> longsleep: report it on subiquity please
<ogra_> yeah
<longsleep> zyga: subiwhat? :)
<longsleep> i had to google that :P
<ogra_> if its an arm board with SD there should be subiquity debug logs
<ogra_> you could pull them off the SD
<longsleep> ah yeah, its on sd
<ogra_> in /var/log/console-conf/
<ogra_> (on the writable partition obviously)
<longsleep> zyga: but now that zyga is there, please tell me that that the apparmor confinement changes have landed in snapd and are already released in stable channel :)
<longsleep> then i might be able to actually release a useful snappy image today for pine64
<ogra_> candidate should surely have everything in the latest iteration ...
<ogra_> not sure about stable ... i think the last snapd still waits for $people_coming_back_from_vacation
<longsleep> ogra_: ok i will try candidate channel next then
<ogra_> (the deb is definitely only in -proposed atm)
<longsleep> ogra_: searching for logs on on this subiquity - should it be in syslog?
<ogra_> in /var/log/console-conf/ like i said above
<longsleep> oh sorry
<ogra_> :)
<longsleep> ogra_, zyga: http://paste.ubuntu.com/23672411/ full log
<ogra_> my guess is an ipv6 issue ... thats mwhudson territory though
<ogra_> file a bug with the log attached for starters
<longsleep> ogra_: where should i file the issue? https://github.com/CanonicalLtd/subiquity/issues
<ogra_> launchpad ...
<longsleep> ogra_: or some place launchpad?
<ogra_> there is a subiquity package
<ogra_> and the snappy project (see topic)
<ogra_> open tasks against both
<longsleep> ok
<zyga> ogra_: hmm, are you sure? id just file it against subiquity
<zyga> anyway
<zyga> longsleep: you can now file bugs on snappy on github too AFAIK
<ogra_> for non snapd projects ?
<ogra_> i thought only snapd wernt on its own
<ogra_> *went
 * ogra_ hasnt heard anything about foundations owned projects using GH issues 
<ogra_> (and i highly doubt they'd move)
<mup> PR snapd#2532 opened: tests: port refresh-all-undo to MATCH <Created by zyga> <https://github.com/snapcore/snapd/pull/2532>
<longsleep> ogra_: all right, i tried my best in getting the meta data right, https://bugs.launchpad.net/snappy/+bug/1652262
<mup> Bug #1652262: subiquitycore exception in controller.run <snappy> <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1652262>
<ogra_> looks good
<mup> Bug #1652262 opened: subiquitycore exception in controller.run <snappy> <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1652262>
 * ogra_ is off 
<zyga> ogra_: enjoy your holidsys :)
<zyga> holidays*
<longsleep> ogra_: yes have fun away from computers :)
<longsleep> zyga: issue also happens on candidate channel, so it might be either my network or the device
 * longsleep removes wifi
<longsleep> mhm did not help :(
<longsleep> also when LAN is not connected ever its the same issue
<longsleep> means no snappy image for xmas :)
<mup> PR snapd#2533 opened: tets: improve snap connect test <Created by zyga> <https://github.com/snapcore/snapd/pull/2533>
<zyga> longsleep: which device is that?
<mup> Bug #1652265 opened: Initialization changes are removed right after first boot <Snappy:New> <https://launchpad.net/bugs/1652265>
<mcphail> ogra_: zyga: thanks - got the curses app to work perfectly!
<zyga> mcphail: woot, great
<zyga> mcphail: what was the key?
<zyga> mcphail: maybe we can add a section to snapcraft wiki
<zyga> mcphail: and document classes of workarounds there (e.g. the curses workaround)
<mcphail> zyga: basically, the extra console-setup-linux, locales and libc-bin stage-packages plus a wrapper script to set up a sane locale on first launch. A bit ugly, but it works. I just copies it from ogra's repo
<mup> PR snapd#2523 closed: tests: port additional snap-confine regression tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2523>
<longsleep> zyga: pine64
<zyga> longsleep: oh, interesting
<zyga> longsleep: maybe the wifi driver is broken, which kernel are you using?
<mup> Bug #1652273 opened: Ubuntu Core 16.04 Docker Seg Faults 139 <Snappy:New> <https://launchpad.net/bugs/1652273>
<mup> PR snapd#2533 closed: tests: improve snap connect test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2533>
<mup> PR snapd#2519 closed: tests: skip packaging dir generation for non-git based autopkgtest runs <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2519>
<mup> PR snapd#2532 closed: tests: port refresh-all-undo to MATCH <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2532>
<mup> PR snapd#2531 closed: tests: make debug-each succeed if DENIED doesn't match <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2531>
<longsleep> zyga: 3.10.104, its a tree i maintain at https://github.com/longsleep/linux-pine64
<longsleep> zyga: some of the wifi drivers in there are broken by design yes, but wifi works generally
<mup> PR snapd#2525 closed: tests: increase wait time for service to be up <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2525>
<zyga> longsleep: interesting, where do you keep your gadget and kernel snaps?
<zyga> longsleep: I'd like to build a public project hub (on github) for community snappy systems
<zyga> a place where one can easily find all the gadges/kernels
<longsleep> zyga: its part of my image building gear - https://github.com/longsleep/build-pine64-image/tree/master/snappy
<longsleep> zyga: any chance you might be able to help me get my key registered on the store?
<longsleep> zyga: i have asked for help a couple of times before in this channel, never found anyone who might be able to do anything. I am always getting "Key registration failed: The account-key-request assertion is not valid."  with snapcraft register-key
<longsleep> zyga: i would really like to upload my gadget and kernel snaps to the store :)
<longsleep> and be able to sign the model would be cool too
<zyga> longsleep: for that I cannot help, you want sergiusens or nessita I suspect
<zyga> longsleep: I'd love to have your kernel and gadget in the store too :)
<zyga> longsleep: I'm interested in making it easy to find the sources of all the kernels and gadgets that are public
<zyga> longsleep: another one in the list is beagleboneblack
<zyga> longsleep: (maintained by ogra_)
<zyga> longsleep: and I plan to maintain something for beagle c4
<longsleep> zyga: yes that would be good
<zyga> longsleep: I'll try to make something like this soon
<longsleep> zyga: having a meta data reference in the snaps to some repository, similar to docker hup would be cool imho
<longsleep> docker hub
<zyga> longsleep: yes, that's on sergiusens's roadmap already
<ogra_> zyga, well, the bbb kernel is just linux-generic (effectively just an armhf build of the of the pc kernel snap)
<ogra_> i just didnt want to steal the name which is why i called it linux-generic-bbb
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/linux-generic-bbb
<zyga> ogra_: that's fine, what we need are the snapcraft files, the readme's and the place to file bugs
<ogra_> i'll set up a project on LP
<zyga> ogra_: and a place for everyone to play nice in one community where they can join easily and learn from each other
<zyga> ogra_: I'd really prefer github for everything (for various reasons) but I won't stop you as you know :)
<ogra_> need to update the stuff too
<ogra_> well, i do 99.99% of my bugtracking on LP ... and githubs mail handling (at least for branches) is 100% unusable i do all my bug and branch tracking through mail
<ogra_> unless they fix that i'll keep the projects i own on LP for bugs ... sorry
<zyga> ogra_: what is the problem with github issue tracking email notifications?
<ogra_> dunno, i havent done issue tracking on GH yet ... but the mail tracking for branches is completely unusable ... i simply suspect the issue tracking to not be different
<ogra_> but i guess i'll see that soon, once i get snapd issue mails ;)
<zyga> ogra_: ah, issue tracking for branches
<zyga> ogra_: can you tell me more about that?
<ogra_> as long as i have to work with the archive, debs, builds on LP i'll not mive for the bits i dont have to move
<zyga> ogra_: I misread your earlier message
<ogra_> **move
<ogra_> well, the branch tracking simply has no info in the mails (compare them to LP branch changes where you get the diff inside the mail etc) it only has very limited amounts of info in it ... i.e. the conversation
<ogra_> it forces me to have another 500 tabs open in my browser since i can only see the diffs via web UI
<ogra_> (and i already have 500 tabs ... not really suitable)
<ogra_> very rarely someone comments inline where you get a very small snippet of the diff that has been commented on in the mail ... and there seems to be no way to change it in the GH mail settings
<zyga> ogra_: so you'd like to get diffs whenver someone pushes to a branch?
<ogra_> i'd like to have the same handling i get from LP
<ogra_> diffs inline without having to open a browser etc
<ogra_> also, it get a mail for every fart someone lets in a branch ... its like 5x the spam i get from LP without any benefit
<ogra_> as someone who has to deal with 300-600 mails per day that is simply ineffective
<zyga> ogra_: would you get that traffic on from two repos that have a snapcraft.yaml inside, each?
<ogra_> if you make any comment or change it sends a mail
<ogra_> without anything inside but "zyga made a change ... here is a link to the diff"
<ogra_> and that link to the diff just gets me to the web UI frontend ... i still have to click through to the file changes
<ogra_> GH just adds a lot more steps to my workflow
<zyga> ogra_: note that you'd be the only person that can make changes to those repos
<ogra_> where Lp is perfectly effective
<zyga> ogra_: I could comment on your repos but other than that, I'd have to open pull requests
<ogra_> right
<zyga> ogra_: but LP is pretty unsocial and people just don't like it, if I'd like to build a hub for all the open source gadgets and kernels, building thato on LP seems like a bad idea
<ogra_> where the above applies ... to see your changes i'D have to do another 5-10 clicks in the browser
<ogra_> LP is unsocial ?
<ogra_> heh
<zyga> ogra_: well, 5-10 is a bit exaggerated IMHO
<ogra_> not sure how you get that impression
<ogra_> staring from clicking in the mail to seeing the change its at least 5 clicks ...
<zyga> ogra_: really? it's usually just one
<ogra_> if you have changed multiple files i even need to open multiple tabs
<zyga> ogra_: that's not true, if I send you a pull request you just see the diff there
<ogra_> the click in the mail only gets you to the PR frontpage
<ogra_> anyway, you really wont convince me
<zyga> ogra_: with all the files combined, you can click to see individual files and commits
<zyga> ogra_: too bad, I reall wish to have a place where all the code is easy to find
<ogra_> and as long as i do still distro work LP is my choice for my own projects
<ogra_> GH is just way to painful and unfrieendly
<ogra_> i'm fine to follow suit where i need to (snapd, snapcraft etc etc)
<ogra_> but not for my own work
<ogra_> all my image building, deb management, archive work are on LP ... snap stuff is still a very small minority of my day to day work ...  splitting that off to a rather un-userfirendly tool doesnt really help
<ogra_> (along with my browser keeping my fans running when i have GH pages open ... tzanks to their use of flash to create zip files on demand)
<zyga> ogra_: I have a few doezen github tabs open and 1% cpu use on firefox
<zyga> ogra_: maybe check if that's really github that's doing this
<ogra_> tell my laptop :P
<ogra_> yes it is
<zyga> ogra_: can you share link, maybe it's not happening on all pages
<ogra_> if you diable flash the "download tarball" button asks you to enable it
<zyga> ogra_: and that keeps your CPU busy?
<zyga> ogra_: I don't have flash installed
<ogra_> its the big green button you get on branches on the top right
<ogra_> hmm, probably they dropped that recently
<ogra_> anyway, you wont make me a GH fan ... :)
<ogra_> i find it as userfriendly as git itself ...
<ogra_> along with the fact that there is a team i have direct access to to fix any LP issues in no time for me if i hit any
<ogra_> (and i really like to support my colleagues by using in-house stuff too)
<zyga> ogra_: that I understand and respect
<zyga> ogra_: I really wish lp was nearly as popular as gh, or had similar features
<ogra_> haha, i'd state the same sentence the other way around :)
<ogra_> (minus the popular but :) )
<zyga> ogra_: review tools are way better on gh :/
<ogra_> i also dont see how we will ever have any customer projects on GH
<zyga> ogra_: I don't use email much so perhaps that's why our views differ
<ogra_> i.e. any private stuff
<zyga> ogra_: sure but "use the best tool for the job"
<ogra_> and i work a lot with these guys every day
<zyga> when building a community hub for snappy sources
<zyga> ogra_: btw, distro question, how can I get this fix released into xenial-updates (for autopkgtest package):
<zyga> https://github.com/zyga/spread-qemu-images/blob/master/autopkgtest-fix.patch
<zyga> it's an obvious bug, the URL changed, adt-builvm-ubuntu-cloud doesn't work with zesty or yakkety releases when invoked from zenial
<zyga> xenial
<zyga> it was a pitti project but I don't know where to send ths to
<ogra_> yeah, i dont know where it moved to ... ask infinity perhaps
<ogra_> it used to be a branch under his account before
<zyga> can I distro-patch this somehow quickly
<zyga> it's super annoying that this is broken and the fix is trivial
<mup> PR snapd#2530 closed: tests: use MATCH in install-remove-multi <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2530>
<zyga> I'll chase infinity after xmas
<ogra_> i guess you'd need to SRU it ...
<ogra_> so not "quickly"
<zyga> I cannot even upload it, what should I do?
<ogra_> (but perhaps the autopkgtest package isnt that strict regarding SRUs given it needs to move fast)
<zyga> I'm not a core developer
<zyga> can you do it somehow?
<ogra_> hmm, they seem to actually use backports ... looking at https://launchpad.net/ubuntu/xenial/+source/autopkgtest
<zyga> there are backports too, this patch is for the package in xenial-updates
<zyga> (the backport is fixed but not everyone is on it)
<ogra_> i could surely upload the package but i dont know the process and would not like to cause extra work (i.e. i dont know if you need to commit to bzr or git first etc)
<zyga> ogra_: ah, this is a native package
<zyga> darn
<ogra_> it doesnt look like there were any uploads to xenial-updates ever
<ogra_> since release day
<zyga> ar, right
<zyga> odd
<zyga> so?
<ogra_> so it seems the backports are used everywhere by default
<zyga> but "apt install autopkgtest" doesn't use backports, does it?
<zyga> everyone that pulls in this package will get the broken version
<ogra_> and the distro package seems to only have been synced from debian around release day
<ogra_> it even has "unstable" in the changelog
<ogra_> yes, if you just apt install it on your xenial desktop you get the outdated one
<ogra_> but who does that ?
<zyga> well, everyone that gets it through dependencies or apt-get installs it?
<ogra_> adt is part of a bitter infrastructure
<zyga> ogra_: it's just broken
<ogra_> *bigger
<zyga> ogra_: sure but whatever the infra, adt is broken and I want to fix it :)
<ogra_> is anyone running it locally (i assume you need a complete local archive for the dependency checking etc)
<ogra_> running it at home doesnt seem to make much sense (ICBW indeed)
<ogra_> out of the setup it needs to run in at least ... and i would expect the official setup to default to use the backport
<zyga> ogra_: you can use it to get `adt-buildvm-ubuntu-image`
<zyga> ogra_: and then you can use it locally in many interesting ways
<zyga> ogra_: you don't need the archive at home
<ogra_> ah, i didnt know that ... i only know atd-run in context of proposed migration in the archive
<ogra_> **adt-run
<ogra_> (i helped pitti to set up the containers and chroots years ago, but didnt touch it further ... apart from watching the actual run for packages at times)
<zyga> ogra_: for some context: https://github.com/zyga/spread-qemu-images
<longsleep> zyga: is there a bug tracker somewhere where i can add my failure to register a key on the store, seems the snappy channel is not sufficient to get that resolved :)
<zyga> longsleep: I don't know, this is something we should be better at (FAQ somewhere)
<zyga> longsleep: report a bug on snappy or snapcraft, we'll move it later when we triage it
<ogra_> zyga, well, as long as "install -t ${VERSION_CODENAME}-backports autopkgtest" works ...
<longsleep> zyga: ok - will do thanks :)
<ogra_> zyga, as a quick hack you could put the first few lines from the code in the readme inside a setul.sh script ... then the user isnt bothered with the apt install stuff ;)
<ogra_> *setup.sh
<ogra_> i.e: run "./setup.sh" ... then run "make -C ~/spread/qemu"
<mup> PR snapd#2534 opened: debian: open 2.21 for development <Created by zyga> <https://github.com/snapcore/snapd/pull/2534>
<zyga> ogra_: sure but that's more magic, I wanted to make it transparent as to what is going on
<zyga> ogra_: I may end up snapping this, we'll see
<ogra_> i assume there is a reason why adt isnt SRUed ...
<ogra_> so you will always have that backports bit
<zyga> (SRU is a pain)
<zyga> that's why
<zyga> new features
<zyga> nah
<ogra_> zyga, you need to trust your colleagues !!!
<zyga> get exceptions and stuff
<ogra_> :P
<zyga> ogra_: I trust them
<zyga> but they used this hack, not me ;)
<zyga> we all instinctively sidestep distro process issue
<zyga> issues*
<ogra_> (that was an inside joke referring to mark teasing me in vancouver when i said SRUs arent really an option :P )
<zyga> hehe, I assumed it was :)
<zyga> but wanted to be honest too
<zyga> I got the reference instantly
<snapper> hi everyone
<longsleep> zyga: https://bugs.launchpad.net/snapcraft/+bug/1652302 created, it would be awesome if you could asign it to someone who might actually be able to help
<mup> Bug #1652302: Key registration failed: The account-key-request assertion is not valid. <Snapcraft:New> <https://launchpad.net/bugs/1652302>
<ogra_> SRUs *are* a pain ... but as long as we have the package in the distro and need to use it there, there is sadly no way around them
<ogra_> i think weven the fast path setup we have for snapd today is awful ... but its the best we can get
<ogra_> yay ... my resistor pack finally arrived from the UK ...
 * ogra_ will spend christmas with soldering iron and multimeter :)
<longsleep> lucky you, today the DHL guy did come without any change so i could not pay customs tax :/
<ogra_> crap
<ogra_> but i guess you can still pick it up tomorrow at a store, no ?
<longsleep> he promised to come later again, but later has been an hour ago :)
<ogra_> good luck ... mine was actually supposed to arrive on tue... i didnt even expect it today
<longsleep> yeah, but i leave for holidays tonight - so either i leave without my personal tech presents from china or the guy stays true to his promise
<ogra_> oh man
<longsleep> in any case, i packed my soldering iron already
<ogra_> lol
 * ogra_ woundlt be able to actually travel with the stuff he builds ... 
<ogra_> *wouldn*t
<ogra_> http://imgur.com/jnoLQd5
<ogra_> the output transformers alone weight ~15kg
<longsleep> lol what is that
<ogra_> a tube amp
<ogra_> old hobby i revived this year
<longsleep> for music?
<ogra_> yeah
<zyga> ogra_: cool, what are you building?
<ogra_> too many low voltage boards in my life, i had to do something with 300+ volts again ;)
<ogra_> zyga, see above i pasted a pic
<longsleep> do those tubes glow when on?
<ogra_> its the first time i use a pre-made case though ...
<ogra_> usualyl i build the whole thing from a piece of sheet metal
<zyga> oh, nice!
<ogra_> indeed they glow
<longsleep> awesome
<ogra_> and they sound awesome ...
<longsleep> try it with x-mas songs :P
<ogra_> (very expensive though ... what you see in the pic is already in the 800â¬ range )
<ogra_> heh
<ogra_> i will
<snapper> is it just me, or there is a problem that you cannot find some apps on a ubuntu core system? for example I was trying to search for an app on Rasberry Pi, and I can't find it, but I can find the app when I search on a non-ubuntu core system
<ogra_> snapper, how do you try to find it on both systems ?
<snapper> snap find <snap_name>
<ogra_> also ... is the non pi system x86 ? perhaps the package only exists for x86
<ogra_> it is really up to the packager if he wants to offfer his packages for arm
<snapper> hum
<snapper> the non-pi system I'm using a regular ubuntu
<ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy
<ogra_> you can search for it there ...
<snapper> I thought that the snaps were universal
<ogra_> if you click on the snap there is an "architectures" field in the description
<snapper> I'll take a look, thanks :)
<snapper> sosorry I have no idea about this, but for the pi, then I would have to pack it differently?
<ogra_> snaps are uploaded as binaries ... unlike debs
<ogra_> so you need to build the binary for the target arch (or use LP to build it)
<ogra_> some uloaders only build for PC ...
<longsleep> x-mas is save, DHL just came with change - yay!
<ogra_> *uploaders
<snapper> i did find it there, it is as amd64 architacture
<ogra_> longsleep, yay, congrats !
<ogra_> snapper, yeah, then you wont find it on the pi
<longsleep> ogra_: thanks, DHL express is pretty awesome
<snapper> ok, thanks :)
 * ogra_ thinks we should make x86 binaries executable on arm 
<longsleep> ogra_: use windows :P
<snapper> :)
<ogra_> well, i wrote qemu-user-static originally ;) ... there is no reason that shouldnt work the other way around (with limitations for sure, but basics should work)
<ogra_> thogh i doubt you could make amd64 work on arm32 ... would have to be i386
 * zyga -> lunch
 * ogra_ goes afk as well
<mup> PR snapd#2535 opened: tests: port more snap-confine regression tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2535>
<iliv> what is the difference between stage-package and build-packages? I'm looking at documentation and snapcraft.io and it says stage-packages "support the part creation." whereas build-packages "aid in building the part.".
<iliv> this sounds kind of synonymous
<iliv> what is exactly "part creation"?
<zyga> iliv: hey
<iliv> hi zyga
<zyga> iliv: the difference is that stage-packages are automatically staged (added) to your snap
<zyga> iliv: while build packages are just installed on your systems
<zyga> iliv: so that you can build your snap
<zyga> iliv: typically you'd see various -dev packages in build-packages
<mcphail> iliv: the build-packages are the things which are needed to build the binaries (e.g. the -dev packages), whereas the stage packages are the things needed to run your binaries (the libs)
<iliv> are stage-packages essentially runtime dependencies?
<mcphail> iliv: yes, I think so
<zyga> iliv: it's "add this blob to my package"
<zyga> it's not strictly "runtime deps" as nothing apart from unpack is done
<iliv> I see
<iliv> thank you
<mup> PR snapd#2536 opened: overlord/snapstate: use keyed fields on literals <Created by zyga> <https://github.com/snapcore/snapd/pull/2536>
<kyrofa> iliv, the important difference is that build-packages get installed on the system building the snap (i.e. they don't go into the snap), whereas stage-packages are unpacked directly into the snap
<iliv> got it
<kyrofa> iliv, stage-packages are unpacked before pull, however, so they can also be build-time dependencies that you also want in your snap
<mup> PR snapcraft#1020 closed: Change hello.sh to be executable <Created by liu-xiao-guo> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1020>
<mup> PR snapcraft#1021 opened: integration tests: add alias integration test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1021>
<grapestomper> kyrofa - you around?
<kyrofa> grapestomper, I am, how can I help?
<grapestomper> kyrofa - I looked at the example you gave yesterday - try to run sh as a service
<grapestomper> to copy fie at snap install
<kyrofa> grapestomper, run into troubles?
<grapestomper> I tried but no dice - when I install the snap I cannot find the sh file in the common or usr dir for the service to run
<kyrofa> grapestomper, do you have the code pushed anywhere? Let me take a look
<grapestomper> just a sec
<grapestomper>  I will push to git and send a link
<grapestomper> https://github.com/chadyoungdell/Snappy_Ubuntu_Core/tree/master/Snapcraft_2.x/Shell/SystemInfo
<kyrofa> grapestomper, alright just looking at the snapcraft.yaml I see something fishy
<kyrofa> grapestomper, the organize at the bottom: `copyreadme: $SNAP_DATA`
<kyrofa> grapestomper, $SNAP_DATA is only available at runtime for the snap, not at build time (i.e. snapcraft can't put anything there for you)
<kyrofa> grapestomper, so you need to put a cp <file> $SNAP_DATA in a script that is run within the snap, when it's installed
<grapestomper> hmmm - so thats what I am trying to figure ouy :)
<grapestomper> out
<grapestomper> where in the snapcraft to I tell it bout that script
<kyrofa> grapestomper, you make it an app
<kyrofa> grapestomper, so in the nextcloud snap, mysql is an app
<kyrofa> grapestomper, a daemon
<kyrofa> grapestomper, but mysql isn't run directly, a helper script is called
<kyrofa> https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml#L20
<mup> PR snapd#2536 closed: overlord/snapstate: use keyed fields on literals <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2536>
<grapestomper> but isnt that what is on L23
<kyrofa> grapestomper, a script named "start_mysql"
<kyrofa> grapestomper, indeed, but copyreadme doesn't do anything
<grapestomper> hmm I will take a look again - back in a few min
<kyrofa> grapestomper, at the bottom of copyreadme you should do `cp README_systeminfo.md $SNAP_DATA/` or something
<mup> PR snapcraft#1022 opened: plugins: update copy plugin to use get_build_properties() <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1022>
<grapestomper> Kyrofa - Thank you, I will hack at it some more
<matteo> in this snap.yaml, I wish a content interface named control: http://pastebin.ubuntu.com/23674170/
<matteo> what hÃ¬I have to rename, the inner or out content? I think the first one
<matteo> but what about the one in the last line? that's the interface type or the plug name?
<kyrofa> matteo, first of all, you don't technically need the `plugs` at the bottom in this case. If it has no plugs it'll get the ones declared globally
<kyrofa> matteo, when you talk about having to rename... what do you mean? Why do you have to rename?
<matteo> I have created a plug named content
<kyrofa> Indeed
<mup> PR snapd#2534 closed: tests: debug zesty autopkgtest failures <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2534>
<matteo> I want to name it "control"
<kyrofa> matteo, ah, easy
<mup> PR snapd#2516 closed: tests: cancel the scheduled reboot on ubuntu-core-upgrade-no-gc and restore state <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2516>
<kyrofa> matteo, the outer name ("content") in this case can be changed to whatever you like, and that'll be the name of the plug
<kyrofa> matteo, however, if you change it away from "content" you need to also specify `interface: content` in the definition
<matteo> ah ok
<matteo> trying
<matteo> kyrofa: great!
<matteo> now, when I connect it I should see a bind mount somewhere?
<kyrofa> matteo, you asked the bind mount to be on top of $SNAP_DATA. I'm not 100% sure that'll work
<matteo> I'll create a subdir then
<matteo> maybe sockets/
<kyrofa> matteo, I've only used absolute paths (e.g. /bar) that end up being relative to $SNAP
<kyrofa> matteo, yeah, whatever you use, make sure that directory exists
<matteo> so, just "/sockets" ?
<matteo> or $SNAP/sockets
<kyrofa> If you use /sockets it'll be relative to $SNAP (I think supporting $SNAP is a relatively new feature, not sure what release)
<matteo> ok
<kyrofa> so /sockets will be more backward compatible
<matteo> I have to create the directory
<kyrofa> Yeah, it's a bind mount. It needs to have a mount point
<kyrofa> Unless it's advanced beyond that since I played with it (possible)
<matteo> ok
<kyrofa> Although if it makes its own mount points, you'll have to use a writable area
<kyrofa> So I suspect that supported in v2.20
<matteo> ok
<matteo> I'll go for the readonly one
<matteo> cannot mount /var/snap/wifi-ap/x1/sockets at /snap/wifiap-consumer/x1/sockets with options bind: Permission denied
<matteo> mmm
<kyrofa> What gave you that error?
<matteo> snap connect wifiap-consumer:control wifi-ap:control
<kyrofa> matteo, and /snap/wifiap-consumer/x1/socket is an existing directory?
<matteo> drwxrwxr-x 2 test test   31 Dec 23 18:15 /snap/wifiap-consumer/x1/sockets
<matteo> drwxr-xr-x 2 root root 4096 Dec 23 18:18 /var/snap/wifi-ap/x1/sockets
<matteo> maybe some directory permissions?
<kyrofa> matteo, ah, are you `snap try`ing?
<matteo> yes
<matteo> I'm spreading
<kyrofa> matteo, try actually installing it, I've noticed weird issues with that type of thing as well
<matteo> it's installed with dangerous
<kyrofa> But you've got it installed via `snap try`, no?
<matteo> sorry, plain snap install
<matteo>     snap install --dangerous $snapfile
<kyrofa> Ah, I misunderstood. Huh, I figured everything would be owned by root there
<kyrofa> Oh oh
<kyrofa> Did you `sudo snap connect`?
<matteo> snap connect wifiap-consumer:control wifi-ap:control
<kyrofa> Try it with sudo
<matteo> # snap interfaces |grep :control
<matteo> wifi-ap:control         wifiap-consumer
<matteo> I'm root
<kyrofa> matteo, how did you create the `sockets` directory in your snap?
<matteo> in the squashfs file
<kyrofa> matteo, manually? i.e. not via snapcraft?
<matteo> I use mksquahfs
<matteo> it's an example snap to test an interface
<matteo> the socket dir is in the FS
<kyrofa> matteo, ah, probably not with all required parameters
<matteo> located at /snap/wifiap-consumer/current/sockets/
<kyrofa> matteo, instead of using mksquashfs, use `snapcraft snap <dir>`
<matteo> no, I don't have snapcraft in the spread VM
<kyrofa> Is this using the snapd codebase?
<matteo> it's a spread test
<kyrofa> Within snapd?
<matteo> no, in wifi-ap
<kyrofa> Ah, okay. Let me get you the exact instantiation you need, then
<matteo> ok
<kyrofa> Because whatever you used looks wrong
<kyrofa> Yeah, `mksquashfs -noappend -comp xz -no-xattrs -all-root`
<kyrofa> matteo, note that if you can install snapcraft in the spread VM you won't have to track that if it changes again
<kyrofa> Just to it in the project-wide prepare
<matteo> ok
<kyrofa> s/to/do/
<matteo> Permission denied
<matteo> kyrofa: I want to try to mount it by hand
<matteo> mount --bind /var/snap/wifi-ap/x1/sockets /snap/wifiap-consumer/x1/sockets
<matteo> it works
<kyrofa> matteo, unfortunately snaps have their own private namespace for that stuff
<kyrofa> matteo, does syslog say anything when you get permission denied?
<matteo> [  216.884517] audit: type=1400 audit(1482518231.065:41): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/snap/wifiap-consumer/x1/sockets/" pid=1807 comm="snap-confine" srcname="/var/snap/wifi-ap/x1/sockets/" flags="rw, bind"
<matteo> ah it's snap-confine
<kyrofa> Huh. What version of snapd and snap-confine do you have?
<matteo> snap    2.20
<matteo> snapd   2.20
<kyrofa> How about snap-confine?
<kyrofa> matteo, also, can you pastebin the slot side?
<matteo> yes
<matteo> http://pastebin.ubuntu.com/23674393/
<kyrofa> matteo, just out of curiosity, what happens if you make that `read`?
<matteo> I can try
<matteo> but there was a discussion about sockets having to be write
<kyrofa> matteo, oh yeah, it'll definitely break
<kyrofa> matteo, but I'm curious if the mount succeeds
<matteo> it fails
<iliv> how long may it take for Launchpad project to import a github repo? I'm looking at 19 minutes already and it seems like something went down wrong somewhere...
<kyrofa> iliv, in my experience it checks for updates once every 5 hours or so
<kyrofa> iliv, but you can ask it to check sooner
<kyrofa> iliv, though if it's the first time you set it up it should be more or less immediate
<iliv> yeah, it has been that in my case
<iliv> just not this time
<kyrofa> matteo, huh, same error message (minus the rw)?
<iliv> I see it has finally imported code
<iliv> took about 20 minutes this time
<kyrofa> iliv, perhaps there was a bit of a backlog
<matteo> didn't check the syslog, just the output
<matteo> cannot mount /var/snap/wifi-ap/x1/sockets at /snap/wifiap-consumer/x1/sockets with options bind: Permission denied
<kyrofa> matteo, huh, I'm afraid you've moved beyond my experience. I suggest emailing the snapcraft list
<kyrofa> matteo, most people are on vacation, but we still check the mailing list
<matteo> thank you
<matteo> I think I'll go on vacations too, starting now :)
<matteo> merry christmas, and snappy new year :D
<kyrofa> You too matteo!
<mup> PR snapd#2535 closed: tests: port more snap-confine regression tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2535>
<mup> Bug #1652369 opened: Cannot connect to ubuntu-app-platform package on consecutive installs <Snappy:New> <https://launchpad.net/bugs/1652369>
<iliv> hm, I have a build that works locally just fine but Launchpad shows this error message: local source (parts/pgpool/build/src/) is not a directory
<iliv> complete buildlog https://launchpadlibrarian.net/299818200/buildlog_snap_ubuntu_xenial_i386_postgresql95-pgpool2-35_BUILDING.txt.gz
<kyrofa> iliv, is your code public? May I see it?
<iliv> yes
<iliv> https://github.com/commandprompt/postgresql95-pgpool2_35-snap
<iliv> kyrofa, specifically https://github.com/commandprompt/postgresql95-pgpool2_35-snap/tree/3.5.4
<kyrofa> iliv, hmm, we highly recommend keeping parts independent
<kyrofa> iliv, using other parts as sources isn't supported
<iliv> well, it works locally
<kyrofa> iliv, it won't everywhere, and it won't always
<kyrofa> iliv, so this pgpool part has extra bits that it doesn't build?
<iliv> it's a thing with PostgreSQL projects apparently... they like to have mini sub-projects, in this case pgpool-II extensions. you build pgpool-II, the main application, then if you want/need to build extensions you cd src/sql/$EXTENSION_NAME and run the usual make && make install
<kyrofa> iliv, no option to say "build this for me too, please?"
<iliv> no, unfortunately
<kyrofa> iliv, do the extensions require the built pgpool?
<iliv> in fact, PGDG ships these extensions as individual packages in APT repo
<iliv> I'm not 100% sure but they might not
<kyrofa> iliv, yeah that's normal, but actually having completely separate build systems in the same tree seems odd
<kyrofa> iliv, if they don't, the easiest thing to do would be to simply use the same `source` for all the parts
<kyrofa> It'll redownload, which is annoying, but it'll work
<kyrofa> iliv, oh wait, actually
<kyrofa> iliv, what version of snapcraft are you on?
<iliv> Launchpad kyrofa
<kyrofa> iliv, I assume you're testing locally first, no?
<iliv> correct
<kyrofa> iliv, if only launchpad, building against xenial and updates pocket?
<iliv> $ snapcraft -v
<iliv> 2.22.1
<kyrofa> iliv, so locally, what version?
<kyrofa> Can you update?
<kyrofa> v2.24 introduced a new feature you can probably use here
<iliv> already updating.. one momen
<iliv> moment *
<iliv> what is the feature?
<Son_Goku> kyrofa: well, given that snapd has gone down this bucket of insanity, why the heck not, eh? >:(
<kyrofa> Son_Goku, what are we talking about? :P
<Son_Goku> (having multiple build systems inside of a single source tree that are not interdependent)
<kyrofa> Son_Goku, ugh
<Son_Goku> (but yet nothing works without everything built)
<Son_Goku> all I can say is: I tried
<Son_Goku> but I was the lone voice for sanity in a sea of crazy
<kyrofa> Son_Goku, hahaha
<kyrofa> Son_Goku, I gave up long ago
 * Son_Goku shrugs
<kyrofa> Son_Goku, good effort, though
<kyrofa> iliv, alright, sorry, back to you
<kyrofa> iliv, I'm making a paste for you
<screwed> plz help i lost my administrator password
<iliv> $ snapcraft -v
<iliv> 2.24
<kyrofa> screwed, on what?
<screwed> how the hell do i fix this its pissing me off
<kyrofa> iliv, alright good deal
<screwed> forgot admin password
<iliv> screwed, to what?
<screwed> i forgot admin password to my laptop
<screwed> im running ubuntu
<iliv> screwed, wrong channel
<iliv> screwed, try #ubuntu or better google "how to reset lost password ubuntu"
<kyrofa> screwed, you might try in #ubuntu
<screwed> i figured who ever is on here may know enough to help me. ive tried everything i can think of or have access too
<screwed> did that
<iliv> kyrofa, so what is the feature you mentioned?
<kyrofa> iliv, here you go: http://pastebin.ubuntu.com/23674584/
<kyrofa> iliv, I'm not tested that, but it should give you the idea
<kyrofa> iliv, v2.24 introduced three new keywords: prepare, build, and install
<iliv> where can I learn more about them?
<kyrofa> iliv, `prepare` runs before the plugin builds, `build` replaces the plugin build/install, and `install` runs after the build/install
<iliv> it's a shame snapcraft still doesn't have a man page
<kyrofa> iliv, at this point snapcraft needs a book :P
<iliv> alright, thank you kyrofa
<iliv> I'll try that approach next year :P
<iliv> and now is the time for some vacation and winter holidays
<kyrofa> iliv, enjoy! I'll be joining you shortly
<screwed> no its time to help me
<kyrofa> iliv, that sounded creepier than it did in my head
<iliv> :)
<kyrofa> screwed, did you ask on #ubuntu?
<screwed> yes
<iliv> I think he may be a troll
<iliv> aren't you screwed?
<kyrofa> iliv, that's okay :)
<screwed> im not a troll
<kyrofa> screwed, did you see https://askubuntu.com/questions/24006/how-do-i-reset-a-lost-administrative-password ?
<screwed> im dead serious
<nacc> screwed: you're in the wrong channel, afaict
<screwed> yep i tgried the grub loader thing
<kyrofa> screwed, if that doesn't work I'm afraid no one here is qualified to help you. We're all Windows geeks around here
<kyrofa> There. Sorry guys
<Son_Goku> I'm sad that worked
<kyrofa> Son_Goku, what, back in your day trolls put in more effort? ;)
<Son_Goku> sadly, yes
<Son_Goku> they were heartier trolls!
<Son_Goku> and also, they at least read the topic to realize what you said was a flat out lie
<kyrofa> :P
<mup> PR snapcraft#1022 closed: plugins: update copy plugin to use get_build_properties() <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1022>
<mup> PR snapcraft#761 closed: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/761>
<mup> PR snapcraft#836 closed: Deal with 404 responses from the store's snap status endpoint <Created by thomir> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/836>
<mup> PR snapcraft#929 closed: Snap snapcraft (based on pylxd branch) <Created by kalikiana> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/929>
<mup> PR snapcraft#1013 closed: Cloudbuild (based on pylxd branch) <Created by kalikiana> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1013>
<kyrofa> Alright, EOY for me. Merry Christmas everyone!
<mcphail> kyrofa: Merry Christmas :)
#snappy 2016-12-24
<snouto> Hello everyone , i have downloaded ubuntu core and i am really amazed by snap tool
<snouto> i would like to know from where snap tool gets its snaps programs to download and install , in addition to this , is there an option to modify the source from where snap gets its packages from
<snouto> in other words , i would like to modify the snap tool to get only snappy programs from my own cloud server not from snapcraft , is this possible ????
<Son_Goku> snouto: yes, but not easy
<Son_Goku> Canonical's implementation of the store/repository/source is not freely available
<Son_Goku> and snapd needs to be modified in its own sources to point to your server
<Son_Goku> and then you rebuild snapd for that
<Son_Goku> you *can* pass the address as a variable, as well, I think
<Son_Goku> but I only recall modifying the source as a surefire way to do it
<Son_Goku> snouto: this is the only open source snap repository implementation I know of: https://github.com/noise/snapstore
<snouto> son_Goku, Deep thanks for your help , let me check it
<snouto> Son_Goku , i think if you just edited your environment by putting this variable , there is no need to change snapd source , SNAPPY_FORCE_CPI_URL
<snouto> What do you think ?
<Son_Goku> that may work
<Andrew> Hi, I recently installed ubuntu core on a rpi2. I'd like to use it to host a snap or two, but I cannot install webdm or snapd. Are there bugs?
<Andrew> I am also quite confused by the new system. Can I use wget by installing the wget snap, or is it a demo snap?
<Andrew> Thanks, in advance for any info or suggestions!
<grapestomper> Andrew - when you say you cannot install webdm - what is the error?
<grapestomper> Andrew - Also paste the /var/log/syslog to pastebin or something similar
#snappy 2016-12-25
<mup> Bug #1635925 changed: Snappy Error - QOwnNotes Error with NTFS <ntfs> <qownnotes> <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1635925>
<mup> Issue snapd#2537 opened: error: daemon is missing the listener for /run/snapd.socket <Created by kozec> <https://github.com/snapcore/snapd/issue/2537>
<bulld> why my app cant use 7z when it is packed in snap package ??
<bulld> neither it can read usr/bin/7z nor /usr/lib/p7zip/7z
<bulld> wtf going on with 7z and snap ???
<bulld> i even wrote a code inmy app to check if it can see those binaries and app cant find them while they are there @@
<bulld> it is very embarrassing
<bulld> any one on?
<bulld> zyga, ogra_ help
<mup> Bug #1652530 opened: Why my app cant use 7z when it is packed in snap package ?? <snap> <snapcraft> <snapd> <Snappy:New> <https://launchpad.net/bugs/1652530>
<mup> Bug #1652530 changed: Why my app cant use 7z when it is packed in snap package ?? <snap> <snapcraft> <snapd> <Snappy:Invalid> <https://launchpad.net/bugs/1652530>
<mup> Issue snapd#2537 closed: error: daemon is missing the listener for /run/snapd.socket <Created by kozec> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2537>
<chatter> hey guys
<chatter> allah is doing
<chatter> sun is not doing allah is doing
<chatter> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<mup> PR snapcraft#1023 opened: Fix to nodejs pluginâs dependency installation <Created by jonathon-love> <https://github.com/snapcore/snapcraft/pull/1023>
#snappy 2017-12-18
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETrmfashk: jibel AmarokNelg zoni Pharaoh_Atem mdeslaur ahrs kristbaum karlthane snappy-m-o diarpi Guest73776 chrisccoulson fdcx stgraber robert_ancell slangasek chrome0 juergh gsilvapt wgrant ahasenack ejat movie-monad robertliu F
<sorcer82> ââââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETpwfqqwwar: kjackal_bot binchen Riddell jibel davidcalle movie-monad Guest73776 jkridner pedronis jjohansen rharper ahasenack Haxxa wgrant chrome0 stgraber daniellimws mdeslaur ogasawara Pharaoh_Atem enoch85 juergh kris
<sorcer82> âââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETbmovnu: pedronis fdcx zoni Kaleo ahrs vila kristbaum snappy-m-o stgraber glimcoil ahasenack chrisccoulson karlthane jjohansen slangasek diarpi SamYaple bschaefer Guest73776 rharper binchen sbeattie Riddell jibel chrome0 King_InuYasha juergh zeroedo
<sorcer82> ââââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETnwcgyi: ahrs jibel zeroedout Pharaoh_Atem robert_ancell stgraber Son_Goku King_InuYasha Fohlen hurricanehrndz fdcx ahasenack Haxxa rharper sbeattie binchen diarpi bschaefer slangasek glimcoil robertliu ogasawara juergh
<sorcer82> ââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETxsjpemsa: glimcoil Kaleo slangasek stgraber robert_ancell bschaefer ahasenack kjackal_bot Haxxa binchen ejat gsilvapt kristbaum diarpi zoni juergh zeroedout pedronis AmarokNelg sbeattie rharper jkridner ogasawara enoch85 Fohlen robertliu jibel King_InuYasha iliv Riddell Guest73776 chrisccoulson mo
<sorcer82> âââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETiqxrfxf: diarpi wgrant daniellimws snappy-m-o Fohlen rharper robert_ancell pedronis movie-monad jibel gsilvapt sbeattie iliv Son_Goku enoch85 binchen Kaleo davidcalle chrisccoulson Riddell jkridner jjohansen ogasawara kristbaum juergh Guest73776 ahrs AmarokNelg robert
<sorcer82> ââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETbxtrcwgom: Guest73776 Pharaoh_Atem King_InuYasha iliv vila gsilvapt daniellimws davidcalle glimcoil mdeslaur robertliu Riddell zoni chrisccoulson ahrs hurricanehrndz zeroedout ogasawara jjohansen kjackal_bot snappy-m-o bschaefer juergh chrome0 jkridner Fohlen Haxxa robert_ancel
<sorcer82> ââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETtdytntlvin: pedronis snappy-m-o chrome0 King_InuYasha jkridner Pharaoh_Atem zeroedout Riddell daniellimws gsilvapt iliv stgraber SamYaple fdcx Guest73776 jjohansen juergh rharper binchen AmarokNelg zoni Son_Goku kristbaum ogasawara jibel Haxxa hurricanehrndz
<sorcer82> âââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETwpodhgphk: binchen pedronis gsilvapt stgraber diarpi Son_Goku iliv zeroedout robert_ancell SamYaple kristbaum kyleN robertliu mdeslaur movie-monad fdcx Kaleo kjackal_bot snappy-m-o enoch85 zoni bschaefer ogasawara ahrs Haxxa chrome0 ahasenack King_InuYasha rharper AmarokNelg Guest73776 j
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETarbfitek: Guest73776 slangasek ejat chrisccoulson Fohlen Pharaoh_Atem glimcoil robertliu zeroedout ahasenack bschaefer karlthane vila AmarokNelg stgraber davidcalle mdeslaur chrome0 robert_ancell movie-monad Son_Goku pedronis da
<sorcer82> ââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETkhdtn: davidcalle fdcx movie-monad kjackal_bot iliv hurricanehrndz snappy-m-o ahasenack enoch85 ahrs ejat daniellimws SamYaple jjohansen karlthane chrome0 diarpi rharper vila binchen bschaefer sbeattie jibel chrisccoulson pedronis Fohlen Kaleo Pharaoh_Atem ogasawara robert_ancell zoni Riddell stgr
<sorcer82> âââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETlekuibuf: kjackal_bot pedronis jkridner mdeslaur zoni ejat ahasenack Guest73776 slangasek vila karlthane ahrs Haxxa jjohansen zeroedout enoch85 AmarokNelg movie-monad kristbaum chrome0 Riddell ogasawara jibel wgrant chrisccoulson sbeattie Son_Goku Kaleo gsilvapt Phara
<sorcer82> âââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETfqdmg: Fohlen jibel ejat kristbaum Pharaoh_Atem chrome0 bschaefer pedronis snappy-m-o zeroedout ahasenack glimcoil movie-monad kjackal_bot Guest73776 iliv slangasek AmarokNelg robertliu stgraber jkridner King_InuYasha vila juergh karlthane fdcx mde
<sorcer82> ââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETlerjfiqq: Son_Goku enoch85 mdeslaur kyleN gsilvapt chrisccoulson ahrs robert_ancell slangasek Haxxa chrome0 iliv davidcalle jjohansen rharper sbeattie Fohlen jibel zeroedout hurricanehrndz movie-monad Guest73776 juergh AmarokNelg King_InuYasha ejat karlthane
<sorcer82> âââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETxpioqws: SamYaple rharper glimcoil karlthane wgrant Son_Goku zoni Pharaoh_Atem ogasawara jjohansen diarpi kristbaum Riddell sbeattie hurricanehrndz fdcx chrisccoulson ejat chrome0 slangasek snappy-m-o Kaleo binchen robert_ancell Guest73776 mdeslaur robertliu enoch85 ahasenack AmarokNelg
<sorcer82> âââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETqpytaupapv: vila snappy-m-o jjohansen iliv Fohlen fdcx wgrant AmarokNelg sbeattie rharper chrisccoulson jkridner zeroedout King_InuYasha kristbaum glimcoil Riddell ejat karlthane Son_Goku gsilvapt Pharaoh_Atem chrome0 ahrs mdeslaur davidcalle Guest73776 ahasenack daniellimws movie-monad
<sorcer82> âââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETgbagvyfpw: pedronis Son_Goku vila ogasawara Kaleo fdcx jibel binchen AmarokNelg gsilvapt kjackal_bot glimcoil juergh diarpi jkridner robertliu bschaefer SamYaple movie-monad wgrant kristbaum zeroedout chrisccoulson jjohansen iliv davidcalle ahasenack kyleN slangasek s
<sorcer82> âââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETmvszyp: daniellimws diarpi Riddell Fohlen King_InuYasha Haxxa ejat snappy-m-o sbeattie bschaefer movie-monad Guest73776 pedronis ogasawara Son_Goku robertliu fdcx davidcalle SamYaple mdeslaur vila Pharaoh_Atem stgraber rharper glimcoil wgrant zeroedout robert_ancell Kaleo slangasek kjack
<sorcer82> âââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETubzbn: chrome0 stgraber rharper vila diarpi wgrant ejat ahrs snappy-m-o hurricanehrndz zoni bschaefer Guest73776 kristbaum sbeattie jibel slangasek Haxxa Kaleo robertliu jjohansen fdcx daniellimws Fohlen juergh ahasenack mdeslaur Pharaoh_Atem Riddell jkridner Son_Goku SamYaple chrisccoul
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETcocmq: ahasenack pedronis gsilvapt chrisccoulson glimcoil davidcalle Kaleo robert_ancell binchen rharper Riddell bschaefer chrome0 daniellimws iliv ahrs fdcx hurricanehrndz Fohlen kjackal_bot kyleN sbeattie ogasawara slangasek z
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETdxrtc: diarpi kyleN robert_ancell jjohansen SamYaple ahasenack hurricanehrndz chrome0 zeroedout kjackal_bot wgrant snappy-m-o ahrs karlthane gsilvapt stgraber fdcx ejat pedronis kristbaum glimcoil Haxxa vila mdeslaur AmarokNelg
<sorcer82> âââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNEThtgxnjmthy: enoch85 jjohansen robert_ancell Fohlen chrome0 binchen movie-monad davidcalle jibel hurricanehrndz rharper ejat ogasawara gsilvapt AmarokNelg pedronis ahrs zeroedout kjackal_bot juergh glimcoil chrisccoulson Riddell mdeslaur zoni SamYap
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETasfsrxmbji: Son_Goku mdeslaur ahrs movie-monad AmarokNelg snappy-m-o karlthane davidcalle zeroedout kristbaum fdcx juergh Guest73776 sbeattie enoch85 King_InuYasha kjackal_bot bschaefer chrisccoulson daniellimws jjohansen Fohlen
<sorcer82> ââââââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETqkcsbyrsp: robert_ancell iliv juergh SamYaple ahrs daniellimws binchen slangasek kjackal_bot robertliu jjohansen enoch85 Pharaoh_Atem vila diarpi gsilvapt zeroedout bschaefer jibel wgrant pedronis s
<sorcer82> âââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETnsbunkty: binchen fdcx juergh SamYaple zoni davidcalle hurricanehrndz kyleN Riddell King_InuYasha movie-monad chrome0 Son_Goku iliv enoch85 ogasawara robertliu rharper Fohlen mdeslaur Kaleo wgrant Pharaoh_Atem Guest73776 jkridner AmarokNelg ahrs ah
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETjtrgojgda: ahrs slangasek Fohlen robert_ancell jkridner Guest73776 chrisccoulson ogasawara rharper wgrant kjackal_bot davidcalle sbeattie Kaleo ejat movie-monad iliv karlthane zeroedout ahasenack juergh daniellimws AmarokNelg ji
<sorcer82> âââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETpjbryaaf: glimcoil kjackal_bot iliv davidcalle vila pedronis Kaleo Fohlen bschaefer Pharaoh_Atem Riddell diarpi zoni chrisccoulson robertliu robert_ancell kyleN Haxxa gsilvapt movie-monad jibel binchen hurricanehrndz Son_Goku ahasenack daniellimws
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETkrvxfpldj: bschaefer SamYaple AmarokNelg vila stgraber Kaleo chrisccoulson fdcx jjohansen pedronis ejat Haxxa jibel karlthane enoch85 slangasek rharper davidcalle sbeattie binchen daniellimws King_InuYasha Pharaoh_Atem Son_Goku
<sorcer82> âââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETsahrz: movie-monad zoni jkridner iliv robertliu Kaleo enoch85 karlthane bschaefer snappy-m-o zeroedout wgrant kjackal_bot binchen Haxxa ahrs jibel jjohansen daniellimws stgraber fdcx pedronis vila kyleN ogasawara ahasenack SamYaple Son_Goku Pharaoh
<sorcer82> âââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETchcwtvfmy: Son_Goku snappy-m-o sbeattie Fohlen stgraber jkridner fdcx Pharaoh_Atem zeroedout pedronis kjackal_bot iliv movie-monad ahrs ogasawara robert_ancell daniellimws kristbaum binchen zoni jjohansen glimcoil chrome0 wgrant
<sorcer82> âââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETljalpnxs: ejat kjackal_bot diarpi juergh snappy-m-o jibel glimcoil fdcx hurricanehrndz sbeattie zeroedout robert_ancell wgrant daniellimws Guest73776 robertliu Riddell ogasawara enoch85 AmarokNelg jkridner Pharaoh_Atem Haxxa Fohlen chrisccoulson King_InuYasha ahrs ped
<sorcer82> ââââââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETunbpazkl: glimcoil slangasek Riddell fdcx Fohlen juergh diarpi SamYaple Guest73776 hurricanehrndz King_InuYasha snappy-m-o zeroedout Son_Goku robertliu jjohansen Kaleo jibel AmarokNelg karlthane aha
<sorcer82> ââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETtcqkzkzgu: davidcalle robert_ancell enoch85 movie-monad daniellimws karlthane binchen chrisccoulson iliv wgrant fdcx King_InuYasha Son_Goku gsilvapt rharper Haxxa vila SamYaple Guest73776 ahasenack stgraber Fohlen pedronis slangasek chrome0 ogasawara kristba
<sorcer82> ââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETzcsknrm: Kaleo enoch85 robert_ancell chrome0 karlthane zoni gsilvapt iliv jjohansen kjackal_bot Haxxa vila Son_Goku Guest73776 pedronis binchen hurricanehrndz davidcalle kyleN movie-monad chrisccoulson ejat stgraber Pharaoh_Atem ahrs AmarokNelg glimcoil Riddell bschaefer SamYaple King_InuYasha kri
<yosh900> ââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETzyqwaiang: Pharaoh_Atem wgrant kjackal_bot vila robertliu daniellimws jkridner binchen diarpi fdcx axino ejat iliv hurricanehrndz dgadomski juergh dpb1 movie-monad Fohlen Riddell chrome0 jibel pedronis zeroedout AmarokNelg kyrofa kyleN ahasenack mdeslaur snappy-m-o robert_ancell Unit193 SamYaple b
<yosh900> âââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETdhnysz: chrome0 binchen SamYaple robert_ancell ahasenack ejat zoni dpb1 kjackal_bot kristbaum stgraber mdeslaur hurricanehrndz chrisccoulson ahrs bschaefer ogasawara davidcalle fdcx enoch85 pedronis elopio slangasek snappy-m-o Riddell AmarokNelg Unit193 zeroedout Haxx
<yosh900> ââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETsyriiopn: sbeattie ahasenack kyrofa kyleN rharper stgraber SamYaple bschaefer kjackal_bot chrome0 snappy-m-o Unit193 diarpi davidcalle Pharaoh_Atem elopio robertliu AmarokNelg Riddell mdeslaur enoch85 Fohlen binchen ahrs axino zoni wgrant chrisccoulson jjoha
<yosh900> ââââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETglpozsot: ahrs chrome0 kjackal_bot hurricanehrndz Haxxa AmarokNelg Pharaoh_Atem ejat snappy-m-o iliv ahasenack diarpi robert_ancell movie-monad dpb1 jkridner pedronis sbeattie kyleN chrisccoulson jibel davidcalle stgra
<yosh900> ââââââââââââââââââââ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL 415-349-5666 #LRH EFNETojnitysfb: zeroedout kyrofa davidcalle daniellimws ahrs kjackal_bot kyleN iliv chrome0 robert_ancell Riddell wgrant AmarokNelg movie-monad pedronis kristbaum jibel vila binchen enoch85 Guest73776 jk
<mborzecki> morning
<kalikiana> morning snappy folks
<mborzecki> kalikiana: morning
<mborzecki> pstolowski: hey
<pstolowski> morning!
<mup> PR snapcraft#1809 closed: static tests: add type hints to formatting_utils <codein> <Created by konrad11901> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1809>
<kalikiana> note to self: pay attention to battery and have a plug ready before it runs out
<kalikiana> coffee break should be a good idea
<cachio_> pstolowski, I'll be 5 minutes late for the standup
<pstolowski> cachio_, np
 * kalikiana FYI going to go for an earlier lunch today
<mup> PR snapcraft#1814 opened: Update test_os_release.py <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1814>
<mborzecki> snap with pkttyagent: https://asciinema.org/a/2StNXfXzVDEatEtEeBUzSuU4j
<mup> PR snapd#4402 closed: tests: save the snapd-state without compression <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4402>
 * pstolowski lunch
<mup> PR snapcraft#1813 closed: tests: add more unit tests for formatting_utils <codein> <Created by konrad11901> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1813>
<kalikiana> re
<King_InuYasha> kalikiana: so... I'm now on vacation :D
<King_InuYasha> after I spend a week with my family, I'll finally be able to spend some time on snapcraft
<King_InuYasha> which, imo, is long overdue
<kalikiana> awesome
<King_InuYasha> mborzecki: you have no idea how happy I am that someone other than me actually looked into the snapd selinux policy and proposed a fix
<King_InuYasha> thank you so much for doing that
<King_InuYasha> I've been slammed and so busy that I haven't been able to dedicate much time toward it
<mborzecki> yeah, had to refresh my selinux foo
<mup> PR snapcraft#1812 closed: Add typings to some modules <codein> <Created by IvanFon> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1812>
<kalikiana> kyrofa: when you're online, I'd like to pick up on our conversation about grammar
<mup> PR snapd#4408 opened: release: snapd 2.30 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4408>
<kyrofa> kalikiana, I'm online, but currently uncaffeinated. Give me a few
<kalikiana> kyrofa: sure. I'll take inspiration from that and have a coffee break as well actually
<kyrofa> It's quiet in here
<Son_Goku> kyrofa: too quiet :)
<kalikiana> kyrofa: shall we use the weekly?
<daniellimws> hello can someone help me regarding snapraft?
<daniellimws> every time I run snapcraft cleanbuild it eats up 1gb on my dis
<daniellimws> disk* weirdly the created containers do not show up when I run lxc list
<daniellimws> because I'm on dualboot, I'm now in a pretty crappy state as I have 400MB disk space left after calling cleanbuild multiple times
<daniellimws> any ideas?
<kyrofa> daniellimws, the containers snapcraft creates are ephemeral, they go away once the run is complete
<kyrofa> Sorry kalikiana, almost done
<daniellimws> kyrofa oh then I think it is cached somewhere on my disk? im not too sure but I think I lost 8gb from this
<kalikiana> daniellimws: images are cached, containers would be removed (unless, and this should be rare, things go really bad)
<kalikiana> daniellimws: can you check ~/snap/lxd/common ? you might have files from snapcraft there, rather than lxd containers
<daniellimws> ok thanks will try that out
<daniellimws> it is empty
<kyrofa> Alright kalikiana, I'm ready now
<kalikiana> yay
 * kalikiana in the weekly
 * kalikiana wrapping up for today
<kalikiana> o/
<daniellimws> kalikiana: that did not solve my problem but somehow uninstalling lxd gave me back 7gbs of space
<kalikiana> daniellimws: oh wow
<daniellimws> by the way, just curious, what's the weekly
<kalikiana> daniellimws: the meeting of the snapcraft team - tho in this case I was just talking about re-using the same hangout name
<daniellimws> oh ok
<kyrofa> Hey cprov, you around?
<kyrofa> Would like to discuss macaroon expiry
<emm> I'm here  http://bit.ly/2BGAQ1i
<cprov> kyrofa: hey
<kyrofa> cprov, hey!
<kyrofa> cprov, quick question: the macaroon expiration, do I just add an `expires` key to the json data being passed to acl/ when getting the macaroon?
<kyrofa> (alongside packages, channels, and permissions)
<oSoMoN> kyrofa, awesome blog post and video!
<cprov> kyrofa: correct, when requesting the root macaroon.
<kyrofa> cprov, will acl/verify/ return the expiration date, I assume?
<kyrofa> oSoMoN, hey, thank you!
<oSoMoN> content is great, and editing is very clean
<cprov> kyrofa: yes, it will display the  "expires" key with the given value
<kyrofa> cprov, sweet, sounds easy. ev was saying that there's some interest formats I can use though, like 'today + 6m'
<oSoMoN> btw, have you guys seen https://www.indiegogo.com/projects/erle-spider-the-ubuntu-drone-with-legs/#/ ? (might be old news around here, but I came across it today and found it cool)
<kyrofa> cprov, is that documented anywhere so I can validate input?
<kyrofa> oSoMoN, yeah that's pretty old. I think we have one in the office, if I remember correctly
<cprov> kyrofa: https://dashboard.snapcraft.io/docs/api/macaroon.html#post--dev-api-acl-
<oSoMoN> hu ho, IÂ didn't check the timestamps, that's old indeed
<oSoMoN> too bad it didn't make it to their funding goal
<kyrofa> cprov, oh, ISO8601? So is using "today+<something>" invalid?
<kyrofa> cprov, those docs sound like absolute expiration time, not duration from today
<cprov> kyrofa: ehe, no, iso8601 is 'YYYY-MM-DD'
<kyrofa> cprov, okay easy enough. I'll start out supporting just that, then
<kyrofa> cprov, does the store return an error if one requests a date past a year from today, though?
<cprov> kyrofa: the discharge expiration will take precedence, in this case
<kyrofa> Ah, okay
<kyrofa> cprov, should I be seeing an "expires" key even if I don't set one in the post? Set for a year from now?
<kyrofa> (I don't)
<kyrofa> (from acl/verify/ I mean)
<kyrofa> And indeed, it doesn't look documented either: https://dashboard.snapcraft.io/docs/api/macaroon.html#validate-a-discharged-macaroon
<cprov> kyrofa: yes, the verify endpoint doesn't show 'expires', just return 'allowed: False' when it's already expired
<kyrofa> cprov, is there any way for me to present to the user that, indeed, the macaroon they just requested expire at a specific time will actually expire at that time?
<kyrofa> (and a way I can verify that things are being set correctly?)
<cprov> kyrofa: one can inspect the macaroon caveats, not ideal ... I can fix the verify endpoint
<kyrofa> cprov, that would be very helpful if it's not too hard. We get all our other data from there as well
<kyrofa> cprov, when do you think you'd be able to do that? I know we're ending EOY here
<mup> PR snapcraft#1815 opened: repo: handle invalid snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1815>
<kyrofa> s/ending/reaching/
<sergiusens> kyrofa can you look at that? ^
<sergiusens> and hello
<kyrofa> sergiusens, hey there! Sure :)
<cprov> kyrofa: it should be in prod on Wed, last release of the year
<kyrofa> cprov, sweet, thank you!
<cprov> kyrofa: https://github.com/cprov/surl/blob/master/surl.py#L96, to illustrate the format
<kyrofa> cprov, perfect
<sergiusens> kyrofa also snapcraft#1802
<mup> PR snapcraft#1802: metadata: extract metadata from appstream <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1802>
<zyga-ubuntu> hello
<zyga-ubuntu> niemeyer: hey :)
<zyga-ubuntu> niemeyer: how are things?
<zyga-ubuntu> niemeyer: I'm still off this week, though I'm past the phase of total idleness
#snappy 2017-12-19
<mup> Issue snapcraft#1816 opened: snapcraft update won't fetch from `SNAPCRAFT_PARTS_URI` <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1816>
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mvo> mborzecki: how are you?
<mvo> what did I miss
<mborzecki> good, thank you
<mborzecki> hm the test infra is basically failing most of the time
<mvo> :(
<mvo> sucks
<mvo> mborzecki: what about your matrix idea? was that discussed?
<mborzecki> maybe not infra, the travis jobs are mostly failing
<mvo> any pattern emerging in the failures? or all random?
<mborzecki> looks mostly random, i've seen the bug when we try to rm -rf /var/lib/snapd and we get device or resoruce busy
<mborzecki> also the bug when we tar some content under /var/lib/snap (or /snap?) and tar complains that the contents got changed while it was working
<mvo> l,
<mvo> ok
<mborzecki> and i've seen the fuse thing
<mborzecki> i actually have a log somewhere, let me post that quickly
<mvo> hrm, hrm, sounds like a good focus for the rest of the week then, trying to stabelize things again. I'm also keen to discuss the matrix idea with gustavo
<mvo> (your matrix idea for per-distro runs in travis)
<mborzecki> yeah, we can try that
<mborzecki> other than that, there was a silly thing with featured snaps in `snap search --section=database`, the output changed and the tests started failing, the test got fixed
<mvo> heh
<mvo> thanks for fixing it
<mborzecki> also there was a thing with selinux on fedora, dbus silently dropping reply messages from polkit to snapd due to selinux policy, i have a PR open #4404, but i've restarted the travis job like 5 times already, no success
<mup> PR #4404: data/selinux: allow messages from policykit <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4404>
<mborzecki> there's a PR from tyler, #4396 it'd be good to merge it once the tests are green
<mup> PR #4396: snap: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapd/pull/4396>
<mborzecki> mvo: https://paste.ubuntu.com/26213459/ line 9420
<mborzecki> i think it's from your PR btw
<mvo> mborzecki: looking
<mvo> mborzecki: interessting, lots of PIDs hanging around, but that should give us some ideas for a fix hopefully, or at least how to debug further
<mvo> jdstrand: is 4406 something we should pull into the release/2.30 branch (in case there is a 2.30.1?)
<mvo> elopio: hey, if you are around, do you have an idea about the regressions in http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd for snapcraft? afaict it fails with snapcraft.internal.errors.SnapcraftPartConflictError: Parts 'python-part' and 'catkin-part' have the following file paths in common which have different contents"
<mvo> elopio: but it passed on "2017-11-23 21:29:41 UTC" in autopkgtest. did the part change out-of-band? i.e. does it come from an external resource?
<mvo> kalikiana: maybe you have an idea -^ ?
<mup> PR snapd#4406 closed: interfaces/dbus: adjust slot policy for listen, accept and accept4 syscalls <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4406>
<kalikiana> morning
<kalikiana> mvo: leo is on hols. kyle knows about ros
<mvo> kalikiana: a bit of a meta question is if these parts change outside of the deb - I guess the answer is yes? which would explain why things worked ~4 weeks ago and stopped today(?)
<kalikiana> mvo: they pull in packages from pip, which might've changed
 * mvo nods
<mvo> mborzecki: can you have a look at 4408 please?
<mborzecki> mvo: looking
<mvo> mborzecki: I guess the only interessting bit for you is the PKGBUILD change for arch
<mup> PR snapd#4408 closed: release: snapd 2.30 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4408>
<mborzecki> mvo: i'll add a bit more debugging to the fuse interfaces problem
<mvo> ta
<mup> PR snapd#4409 opened: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4409>
<mborzecki> mvo: have you seen anything like this https://api.travis-ci.org/v3/job/317950947/log.txt ?
<mvo> mborzecki: you mean "internal error, please report: running "test-snapd-tools.echo" failed: cannot find installed snap "test-snapd-tools" at revision 6" ? and friends? I saw it this morning, have not seen it before. its slightly strange
<mvo> mborzecki: do you happen to know if this is reproducible ?
<mvo> mborzecki: or is it a one-off thing?
<mborzecki> don't know, i've restarted this build a couple of times already, each time it's failing with somethig, but i have not coollected the logs from each run
<mborzecki> i'll try to run debian-sid-64 suite on linode manually, see what comes up
<mvo> mborzecki: sounds good
<mup> PR snapd#4410 opened: tests: make journalctl check wait a bit for output <Created by mvo5> <https://github.com/snapcore/snapd/pull/4410>
<mborzecki> mvo: looks like we were looking into the same snapd-reexec test
<mvo> mborzecki: yeah, my "fix" is very naive, but maybe it helps
<mborzecki> mvo: i'm thinkgin we should probably disable all rate limit in journald as well
<mvo> mborzecki: +1 for that
<mvo> mborzecki: heh, my PR is breaking on interfaces-fuse_support
<mvo> mborzecki: two pids
<mborzecki> hahah
<mborzecki> and #4409 has some extra debugs for that
<mup> PR #4409: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4409>
<mvo> mborzecki: but you added some debug already, right? so I should probably just merge it
<mvo> mborzecki: aha, great
 * mvo waits to see what else fails
<sergiusens> mvo that regression you mention in the tests is something kyrofa fixed/looked at, I don't recall right now though. It is not about pip, but ros uses its own archive
 * sergiusens waves
<mvo> sergiusens: thanks and good morning
<sergiusens> kalikiana hey I assigned a new task for you
<mvo> sergiusens: the important part (to me) is that its not caused by snapd :) so I will ask the sru team to ignore this failure
<sergiusens> mvo no it is not :-) You should only worry really bad if any of the ones using build-snaps or lxd/cleanbuild fail :-)
<sergiusens> there are also snapd tests in there where we install what we build
<sergiusens> it would be great if we could add filters to adt depending on the rev dep being tested to only run what is relevant :-)
<kalikiana> sergiusens: Yup, saw it.  It's on my list
<mborzecki> mvo: can you review #4409? the build is green, so we could merge it if the change is ok
<mup> PR #4409: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4409>
<mvo> mborzecki: sure, nice to see its green
<mwhudson> gnar gnar, something about reexec-ing breaks in a live session
<mup> PR snapd#4409 closed: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4409>
<mborzecki> mvo: thanks
 * kalikiana coffee break
<mwhudson> did a new core snap get released recently?
<mup> PR snapd#4411 opened: tests/lib/prepare-restore: disable rate limiting in journald <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4411>
<mvo> mwhudson: not recently, why?
<mwhudson> mvo: ah, red herring i think
<mwhudson> it's late and i'm confused :)
<mvo> mwhudson: puh, ok :)
 * kalikiana starting at the same code for too long without finding the problem, going for a break
<mup> PR snapd#4412 opened: tests/main/postrm-purge: stop snapd before purge and reinstall the package in restore <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4412>
<mborzecki> mvo: ^^ think this test might have left the worker in a broken state
<niemeyer> Hellos!
<mborzecki> niemeyer: hey
<mup> PR snapcraft#1817 opened: grammar: support strings <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1817>
<kalikiana> hey niemeyer
<sergiusens> mvo is `environment` an ordered dict?
<sergiusens> wondering if I can get away with that and not do variable replacements in snapcraft
<sergiusens> it is not a big problem if it is not (aside from ordered it would need to apply the entries in a stepped manner too)
<jamesh> any comments on https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 would be appreciated
<niemeyer> kalikiana: Hey
<niemeyer> kalikiana: Happy to talk today after the meeting, or in the forum if you'd prefer that
<jdstrand> mvo: if you're respinning it, sure. if you're not, it can wait if it has to
<jdstrand> do you want me to create a 2.30 PR?
<kalikiana> niemeyer: Cool! I'd say have a look at the forum first, and see if it's clear enough. If more context is needed we can have a quick hangout about it
<niemeyer> kalikiana: Okay, let me look into the forum and respond first.. we can have a call later today if there's still a need
<kalikiana> Okay. Thanks!
<mvo> mborzecki: oh, nice
<mvo> sergiusens: yeah, env should be ordered iirc
<mup> PR snapd#4412 closed: tests/main/postrm-purge: stop snapd before purge and reinstall the package in restore <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4412>
<kalikiana> sergiusens: FYI I added more details to snapcraft#1807 wrt patchelf; I'm running the tests locally to verify if test_container_builds also passes
<mup> PR snapcraft#1807: tests: run test_cleanbuild in LXD on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1807>
<kalikiana> will be going for lunch in ~10, let's see if the tests can pass before I leave
 * kalikiana will go have lunch, back in ~1 hour
<mup> PR snapd#4413 opened: tests/main/postrm-purge: stop snapd before purge <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4413>
<sergiusens> mvo but is each processed individually and applied? As in, if I have FOO=my-arch and the next entry is LD_LIBRARY_PATH=$SNAP/lib/$FOO, will that work?
<mborzecki> mvo: https://paste.ubuntu.com/26215262/ empty cmdline?
<mvo> sergiusens: that should work
<mvo> sergiusens: I think there is even a test for this, I can look
<mvo> sergiusens: but it will only resolve things top-down
<sergiusens> mvo oh, this is great news! I will try it out; probably next year as this year is running low on time
<mvo> so FOO=my-arch\nBAR=$FOO/x will work but not the other way around
<mvo> mborzecki: that sounds like a race, I bet /proc/28456 does not exit anymore
<mvo> mborzecki: at the point this runs
<mborzecki> or it's a kernel thread :/
<mborzecki> but that shouldn't match the regex
<mborzecki> oh, w8, not, there's no such file or directory, uhh i'm staring at the logs for too long
<mvo> mborzecki: :)
<mvo> mborzecki: no worries
<mup> PR snapd#4414 opened: tests/main/interfaces-fuse_support: workaround multiple matching processes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4414>
<cachio__> mvo, I lost the machine where I reproduced the error, I'll trying to reproduce it again and share that to you
<mvo> cachio__: thank you
<kalikiana> re
<mup> PR snapcraft#1818 opened: meta: create XDG_RUNTIME_DIR in wrappers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1818>
<mup> PR snapd#4391 closed: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4391>
<mup> PR snapd#4393 closed: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
<mborzecki> mvo: can you take a look at #4413 and #4414 later on?
<mup> PR #4413: tests/main/postrm-purge: stop snapd before purge <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4413>
<mup> PR #4414: tests/main/interfaces-fuse_support: workaround multiple matching processes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4414>
<sergiusens> snappy-m-o autopkgtest 1815 xenial:armhf
<snappy-m-o> sergiusens: I've just triggered your test.
<mvo> mborzecki: ssure
<mup> Issue snapcraft#1819 opened: Detect and clear executable stack binaries <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1819>
<niemeyer> mvo: Is there a way to install local .deb files with apt-get so it resolves dependencies?
<niemeyer> mvo: It was possible with apt-rpm, but I don't recall if that ever got ported over
<sergiusens> niemeyer apt install ./<deb>
<sergiusens> but the deb has to be in cwd
<niemeyer> Sweet
<mvo> niemeyer: what sergiusens said, it should not be needed to be in cwd, but apt expects an absolute path
<sergiusens> mvo oh, abs path; I had issues with not working out of cwd in the past
<mvo> sergiusens: hm, that might be a bug, the rule is basicly it needs to look like a path so that it is distinguishable (in principle) from a deb from the archive
<mup> PR snapcraft#1820 opened: Update test_lxd.py <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1820>
<niemeyer> mvo, sergiusens: Brilliant, it worked fine, thanks!
<kalikiana> niemeyer: ping
<niemeyer> kalikiana: pong
<kalikiana> niemeyer: I'll be eod'ing in 30min - can we have a quick chat still about the arch stuff?
<niemeyer> kalikiana: I'm having a call (or trying to) with JamieBennett right now, but soon maybe
<kalikiana> ok
<ikey> btw re: arch i believe nvidia stuff is wonky there
<ikey> im terrified that i might actually have to install arch
<ikey> ._.
<niemeyer> kalikiana: Jamie is having network issues and I have 8 minutes before he's ready.. want to have a quick chat?
<kalikiana> niemeyer: yes!
<kalikiana> ikey: I think we're talking about different things. I meant arch as in architecture( grammar in snapcraft)
<kalikiana> like "on amd64 to armhf:" syntax
<ikey> i saw arch and twitched. :p
<kalikiana> :-D
 * kalikiana wrapping up for eod in ~15min - trying to finish one more test case before heading out
<mup> PR snapd#4415 opened: Set debian-sid-64 system as manual <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4415>
<kalikiana> Alright, time to call it a day
<kalikiana> o/
<ikey> i broke delta service: https://hastebin.com/jixayuxoki.sql
 * ikey nukes deltas and uploads the old fashioned way
<kyrofa> ikey, yeah, how dare you remove the 1 required positional argument
<ikey> ikr? lol
<sergiusens> ikey interesting
<sergiusens> thomi whose in charge of deltas these days https://hastebin.com/jixayuxoki.sql (on one side I want to understand the error on the other update snapcraft to handle the error message better)
<thomi> sergiusens: blr is the person you want for upload deltas, but if it's an emergency I can probably do some digging for you
<thomi> did this happen recently?
<sergiusens> thomi not an emergency, happened today; I think, ikey can confirm
<ikey> yeah no emergency
<ikey> just nuked the deltas and went full upload
<thomi> hmm, this is the second report of upload deltas breaking in the last week.
<thomi> I know blr looked in to the last report, but I don't know what he found (he's on holiday ATM, so I can't ask him)
<mup> PR snapcraft#1786 closed: lxd: always install squashfuse <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1786>
<mup> PR snapd#4415 closed: Set debian-sid-64 system as manual <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4415>
<sergiusens> snappy-m-o autopkgtest 1815 xenial:armhf
<snappy-m-o> sergiusens: I've just triggered your test.
#snappy 2017-12-20
<mup> PR snapcraft#1818 closed: meta: create XDG_RUNTIME_DIR in wrappers <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1818>
<mup> PR snapcraft#1821 opened: tests: use a simpler test for bzr and python <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1821>
<mup> PR snapd#4416 opened: tests: performance measurements for basic snapd commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4416>
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki, good morning!
<mborzecki> mvo: i was playing a bit with interfaces-fuse_support test yesterday, and we may have a bigger problem at hand
<mvo> mborzecki: oh? tell me more
<mborzecki> the 'create' will try to remove fuse mount when you kill it
<mborzecki> it tries 2 things, first it attempts to do an unmount and if that fails it will try to run fusermount -u <mount-point>
<mborzecki> and it works nicely like this when I run it on my laptop
<mborzecki> when running as snap, it gets a 'bad system call' and shuts down without cleaning the mount point
<mvo> mborzecki: ohhhh
<mvo> mborzecki: so a confinement issue!
<mborzecki> the mount point is still visible in mount namespace of the snap, and any attempts to fusermount -u <path> end up with a 'bad system call'
<mvo> mborzecki: interessting
<mborzecki> yeah, i'd like to try strace today and see where it fails exactly
<mvo> mborzecki: whats slightly odd is that it appears the test sometimes works and sometimes dosn't
<mvo> mborzecki: sounds great, thanks for looking into this
<mborzecki> i think there are 2 things
<mborzecki> the mount point in mount namespace, don't know if it's a problem during the cleanup (maybe not?)
<mborzecki> and the other thing is that create command forks like 3-4 times
<mborzecki> `ps aux | awk '/[t]est-..` is called  right after running the command, so it's possible that we may pick up the forks
 * mvo nods
<mvo> mborzecki: yeah, thats interessting as well
<mborzecki> mvo: otoh, is it possible to force a specific order of tests in spread (given 1 worker)?
<mvo> mborzecki: yes, it prints something like "use -seed=1234" at the start
<mvo> mborzecki: this way you can re-create the order
<mvo> mborzecki: afaik you cannot force a specific order in the sense of run test: "a,b,c"
<mborzecki> ah, ok
<mup> PR snapd#4410 closed: tests: make journalctl check wait a bit for output <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4410>
<mup> PR snapd#4417 opened: tests: fix catalog-update wait loop <Created by mvo5> <https://github.com/snapcore/snapd/pull/4417>
<mborzecki> mvo: https://paste.ubuntu.com/26219568/ apparently we pick up snappy-app-dev helper too
<mborzecki> mvo: https://paste.ubuntu.com/26219598/ SIGSYS
<mvo> mborzecki: hm, interessting, smells like seccomp
<mborzecki> mvo: fixed seccomp rules by hand, added umount2, compiled with snap-seccomp and the mount point gets cleaned up properly now, though I'm not sure jdstrand will be happy about that
<mvo> mborzecki: what interface is the test currently using?
<mborzecki> fuse-support
 * mvo nods
<mvo> mborzecki: hm, I think if we extend the interface and allow umount/umount2 in seccomp and add an appamror umount fstype=fuse.* rule that should be ok
<mvo> mborzecki: afaict apparmor supports umount restrictions
<mvo> mborzecki: plus it seems odd that we give people the ability to fuse-mount stuff but not umount this again :)
<mborzecki> mvo: afaiu it goes like this: libfuse tries unmount2 -> gets -EPERM -> tries setuid fusermount helper (fusermount -u <mount-path)
<mvo> mborzecki: right, except thta in our case we don't get EPERM but SIGSYS
<mborzecki> but in our case it's, umount2 -> SIGKILL (seccompt)
<mborzecki> yup
 * mvo nods
<mvo> mborzecki: so we could probably just allow the syscall and apparor would deny
<mvo> mborzecki: and then things would work as apparmor give eperm
<mborzecki> btw. i don't see any support for specifying alternative action in snap-seccomp rules :)
<mvo> mborzecki: alternative action like what?
<mvo> mborzecki: eperm instead of sigsys?
<mborzecki> errno
<mvo> right
<mvo> there is a PR for that https://github.com/snapcore/snapd/pull/3998
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<mvo> mborzecki: well, not *exactly* what you want, its still not configurable but switches to errno
<mborzecki> right
<mvo> mborzecki: please let me know if I should help with the interface update
<mborzecki> mvo: is fuse-consumer apparmor profile kept in the filesystem?
<kalikiana> good morning ^_^
<mborzecki> kalikiana: morning
<kalikiana> hey mborzecki
<mvo> mborzecki: yes, it should be there in /var/lib/snapd/profiles/apparmor
<mvo> mborzecki: ups, the other way around /var/lib/snapd/apparmor/profiles
<mvo> mborzecki: you will need to "sudo apparmor_parser -r /path/.../file" load it
<mvo> mborzecki: (if you modify it)
<mborzecki> mvo: hm i may be missing something, the plug is connected, but snap.test-snapd-fuse-consumer.create profile does not contain any rules from fuse_support.go
<mvo> mborzecki: hm, strange. what distro/release are you on right now?
<mborzecki> our spread debian-sid image
<mvo> mborzecki: hm, that should be fully apparmor supported
<mborzecki> uhh `Dec 20 06:42:24 debian snapd[8236]: AppArmor status: apparmor is enabled but some features are missing: dbus, mount, network, signal`
<jjohansen> mborzecki: it will depend on your kernel
<jjohansen> or should, 4.13 has ptrace, 4.14 signal and mount, unfortunately there were problems with 4.14 so network and dbus didn't make it
<mvo> mborzecki: aha, I think in this case we just enable "partial" support, which irrc means we confine snap-confine itself but not not apply full confinement for the snaps
<jjohansen> those will be tried again in 4.1
<mvo> thanks jjohansen
<jjohansen> make that 4.16
<mborzecki> jjohansen: ta
<mborzecki> mvo: yeah, the rules are listed for ubuntu 16.04 image
<mborzecki> mvo: take that back, i can see that the profile has some/many rules, but none of the fuse specific ones we have in the source code
<mvo> mborzecki: hm, that is odd, let me see
<mborzecki> mvo: nvm, got it now, damn, forgot that the interface was not connected yet
<mvo> mborzecki: aha, good :) I was worried for a second
<mborzecki> mvo: ok, eveything seems to work fine, i've punched rule through seccomp (whitelisted umount2)  and apparmor (umount fstype=fuse.* <fuse-mountpoints>)
<mborzecki> the spread test should be fixed as well
<mvo> mborzecki: yay
<mvo> mborzecki: thanks for finding this!
 * sergiusens waves from the early morning
<mup> PR snapcraft#1821 closed: tests: use a simpler test for bzr and python <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1821>
<mup> PR snapd#4413 closed: tests/main/postrm-purge: stop snapd before purge <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4413>
<mup> PR snapd#4390 closed: tests: change interfaces-fuse_support to be debug friendly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4390>
 * kalikiana coffee break
<mborzecki> mvo_: since #4390 was merged, if you don't mind, i'll rebase #4414 on top of master
<mup> PR #4390: tests: change interfaces-fuse_support to be debug friendly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4390>
<mup> PR #4414: tests/main/interfaces-fuse_support: workaround multiple matching processes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4414>
<mvo_> mborzecki: sure
<Chipaca> mvo_: hello from the south of france :-D
<mvo_> Chipaca: hello my friend! great to see you, I hope you are just here to make us jealous :) ? I assume you are on vac?
<Chipaca> mvo_: I am on vac, yes
<mborzecki> Chipaca: how many degrees today? :)
<mvo_> Chipaca: send us a picture of beautiful sun or something :)
<Chipaca> mvo_: but this Walk thing which i started as a friday bugged me so i pushed a fix
<Chipaca> it's a cold 9C today, terrible
<Chipaca> mvo_: mborzecki: yesterday, https://i.imgur.com/DM3GLCO.jpg
<Chipaca> that's in the woods around Valbonne
<mborzecki> nice
<mvo_> Chipaca: looks great!
<Chipaca> mvo_: are the tests still mostly failing?
<mvo_> Chipaca: *slightly* better but still pretty bad, but some progress
<mborzecki> mvo_: i've updated #4414
<mup> PR #4414: tests/main/interfaces-fuse_support: fix confinement, allow unmount, fix spread tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4414>
<mvo_> mborzecki: very nice, thank you
<mvo_> mborzecki: I requested a review from jdstrand  for 4414, he will be the right person to double check the apparmor rules
<mborzecki> mvo_: great, thanks
<mborzecki> mvo_: have you seen this? https://forum.snapcraft.io/t/yocto-rocko-core-snap-kernel-panic/3261
<mborzecki> > github.com/snapcore/snapd/overlord/state.(*State).writing(0xe3f)
<niemeyer> Mornings
<mborzecki> *State address looks bogus
<mborzecki> niemeyer: hey
<mvo_> hey niemeyer
<mvo_> mborzecki: yeah, "writing(0xe3f)" looks suspicious
<mup> Bug #1623125 changed: fixrtc script does not catch "Last mount time: n/a" string <rls-aa-incoming> <Snappy:Fix Released by ogra> <initramfs-tools (Ubuntu):In Progress by smb> <initramfs-tools-ubuntu-core (Ubuntu):Triaged by ogra> <initramfs-tools (Ubuntu Xenial):New> <initramfs-tools-ubuntu-core
<mup> (Ubuntu Xenial):New> <https://launchpad.net/bugs/1623125>
<niemeyer> mborzecki, mvo_: o/
<niemeyer> cachio__: I've just updated the travis spread binary to drop support for compression.. let's see if it makes any difference
<mvo_> mborzecki: your reply seems to be the best option - maybe we can figure out more with the image
<niemeyer> Chipaca: Are you working today?
<Chipaca> niemeyer: not unless you count pushing code to github as working
<niemeyer> Chipaca: I'm wondering if you'd have any insights about this issue: https://forum.snapcraft.io/t/yocto-rocko-core-snap-kernel-panic/3261
<niemeyer> Chipaca: The reason why I'm asking you specifically is because the segfault comes from the progress bar
<niemeyer> Which was touched recently, so seems suspect
<Chipaca> niemeyer: i'll take a look (not now though)
<niemeyer> Chipaca: Thanks!
<niemeyer> mborzecki: You've asked for some information on that thread.. did you dig through the traceback to have an idea of what was going on?
<niemeyer> (mostly wondering about what we know)
<mborzecki> niemeyer: from what i understand there may be 2 things, first there's a segfault when the task has completed, for some reasong *State in task looks weird, then there's a mount which returned 127 exit code (awfully similar to command not found in the shell)
<niemeyer> mborzecki: Yeah, the mount failing isn't so concerning.. they're playing with a new environment and there might be things going on
<niemeyer> mborzecki: But that segfault is worth making sure is not something on our plate
<niemeyer> mborzecki: On quick inspection, I cannot see how to land there
<niemeyer> But I won't spoil with my train of thinking as there might be something else going on that I'm not seeing
<mborzecki> fwiw i thinking it has just downloaded the 'core' snap
<mborzecki> going through the backtrace, there's this tuple `0x966ca248, 0x4`, in places where a string is passed, 'core' is 4 characters, it's downloaded first and the mount error in `snap install ..` output also mentiones 'core', so it must be the same code path
<mup> PR snapcraft#1815 closed: repo: handle invalid snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1815>
<jdstrand> mvo_, mborzecki: I reviewed 4414. note that not allowing umount2 and umount was very intentional
<kalikiana> meh, with all this test stuff today, I'm looking forward to my lunch break
<jdstrand> kenvandine: why does thunderbird need allow-sandbox: true?
<mborzecki> jdstrand: thanks for the review, any suggestions what to do with mount points being left behind?
<mup> PR snapcraft#1822 opened: tests: skip classic confined tests on armhf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1822>
<sergiusens> kalikiana have you updated any of your PRs?
<kalikiana> sergiusens: I addressed the remaining points on snapcraft#1817 - still running on Travis, though
<mup> PR snapcraft#1817: grammar: support strings <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1817>
<kalikiana> adding those unit tests was surprisingly tedious :-/
 * kalikiana leaving for lunch now - more investigating test failures to look forward to after that
<sergiusens> kalikiana I've added comments to your PR; all related to the same potential root cause
<kalikiana> sergiusens: Thanks! Will address them after lunch
<jdstrand> mborzecki: there is nothing that can be done with the way it is mounted.
<jdstrand> mborzecki: if this is causing test failures, then mark the test as manual
<jdstrand> mborzecki: well, you could fiddle with allow_root (man fuse) so root could unmount it outside of the snap, but this would not be a totally representative test
<jdstrand> mborzecki: but it is arguably better than disabling the test
<mborzecki> jdstrand: we store the mount namespace, so `nsenter --mount=/run/snapd/ns/test-snapd-fuse-consumer.mnt umount /var/snap/test-snapd-fuse-consumer/16/mount_point` from the test seems to do the trick of unmounting
<jdstrand> mborzecki: is it actually removed though?
<mborzecki> jdstrand: fwiw `nsenter --mount=/run/snapd/ns/test-snapd-fuse-consumer.mnt mount` does not list it anymore
<mborzecki> jdstrand: can i do something else to verify that it's gone-gone?
 * jdstrand notes that to set allow_root, you'd have to modify the security policy within the test to allow reading /etc/fuse.conf
<jdstrand> mborzecki: oh, are you running the snap as root?
<mborzecki> yes
<jdstrand> mborzecki: and unmounting as root?
<jdstrand> ok, phew
<jdstrand> that should be fine then
<mborzecki> ok, great
<jdstrand> I thought you were running the snap as non-root, which allowed the fuse mount, then were able to unmount as root outside the snap, which would've been bad (the kernel is supposed to deny that)
<jdstrand> mborzecki: so now you are using kill -9, then using nsenter ... umount ... from outside the snap?
<mborzecki> jdstrand: i'm doing create $MOUNTPOINT & ; read the file ; kill job-pid ; wait (will expect to exit with a failure now); nsenter .. mount (veirfy that the moint point is left behind) ; nsenter umount (to be added as well)
<mborzecki> jdstrand: i'll drop the policy update patch (we can revisit it later perhaps) and just update the test
<jdstrand> mborzecki: sounds good. that will test the interface in how it is expected to behave. note, we shouldn't change that interface with the policy you have, but we could introduce fuse-control (but no one from the field has requested this so I suggest waiting til someone does)
<mborzecki> jdstrand: ack, thanks
<Chipaca> niemeyer: ok i have a bit of time to look at that traceback now
<Chipaca> niemeyer: is that still needed?
<niemeyer> Chipaca: Yeah, but not sure if we can do much without further data
<niemeyer> Chipaca: I had a quick look and the code path smells like it should be impossible
<Chipaca> niemeyer: it's a custom build, dunno what version / patches it has
<Chipaca> niemeyer: the bits about progress there in any case are not new code
<Chipaca> they're the task progress adapter thing
<niemeyer> Right, that's one of the questions to ask
<niemeyer> mborzecki asked a few others
<mborzecki> in theory their layer and the recipe should carry all the patches
<Chipaca> do we know if the '586' in the name implies anything?
<Chipaca> niemeyer: in any case, give me a shout on telegram if it comes back and you'd like my eyes again
<Chipaca> i might not be on irc much :-)
<niemeyer> Chipaca: Thank you!
<Chipaca> no probs
<Chipaca> mvo_: I don't know how my #4394 is special, but it's green every time :-D
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<mvo_> Chipaca: haha
<mvo_> Chipaca: while you are here, what is the tl;dr summary for command-not-found and snap integration? where do we stand currently?
<mvo_> Chipaca: just asking to help, no pressure
<kalikiana> re
<mup> PR snapd#4411 closed: tests/lib/prepare-restore: disable rate limiting in journald <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4411>
<mup> PR snapd#4417 closed: tests: fix catalog-update wait loop <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4417>
<mup> PR snapd#4404 closed: data/selinux: allow messages from policykit <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4404>
<mup> PR snapd#4396 closed: snap: use the -no-fragments mksquashfs option <Created by tyhicks> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4396>
<kalikiana> sergiusens: I added tests for verifying passing-through of properties as per your suggestion and also added a .copy() there. Thanks for catching that!
<kyrofa> Huh. I've been wondering why my computer mouse has been getting worse and worse
<kyrofa> Last night I realized that my laptop lid doesn't close all the way
<kyrofa> I think my battery is expanding
<sergiusens> kyrofa you need to deplete it from time to time
<sergiusens> I unplug often
<sergiusens> this is all anecdotal; but it was the xp with the test phones during the ubuntu touch days
<kyrofa> sergiusens, I do deplete it, but not tremendously often. The battery life is pretty bad these days
<kyrofa> However, this laptop is dreadful enough I got an extended warranty
<kyrofa> I've lost track of the number of screens I've had replaced
<kyrofa> Even had the lower body replaced once
<sergiusens> kyrofa you should get an xps 13 or a surface laptop :-P
<kyrofa> sergiusens, I got a dell m3800, another of their Ubuntu offerings
<kyrofa> It's terrible, but the XPS13 I got back in... what... 2012... is still trucking along
<mup> PR snapd#4418 opened: tests: enabling opensuse for tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4418>
 * kalikiana going to wrap up for the not so productive day soon
<Son_Goku> kyrofa: you should check your redhat bugzilla bugs :)
<kyrofa> Son_Goku, huh, I haven't received any emails
<kyrofa> I'll take a look
<Son_Goku> you probably don't have email stuff set up ;)
<niemeyer> Chipaca: Thank you!
<niemeyer> Oops.. bad key, but thanks again anyway! :)
<niemeyer> Forum software was just updated, please ping if there are issues.
<kyrofa> Son_Goku, NOW I got notified
<kyrofa> Just a bit behind apparently
<mup> PR snapd#4419 opened: tests: fix snapctl configure core tests for rpi2 and 3 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4419>
<j605> I installed the spotify snap in Arch Linux, and when trying to play audio I get:
<j605> ALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.confALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
<j605> anyone else facing this issue?
<kyrofa> jdstrand, you're the alsa pro in my book. Any ideas there?
<j605> also I am using snapd git master
<jdstrand> kyrofa: wow, you're in a jam if I'm the alsa pro :P
<kyrofa> jdstrand, :D
<jdstrand> j605: fyi, I am not a pro, but I was able to get alsa working in a test snap and put the instructions in a bug. let me get that for you
<jdstrand> j605: hopefully this will help you: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5
<mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1598309>
<jdstrand> kyrofa: fyi, for a fun project I bought one of those wdc nextcloud box thingies
<kyrofa> jdstrand, oh yeah? Awesome!
<jdstrand> kyrofa: I don't have it yet, but looking forward to playing with it
<kyrofa> I'll warn you in advance: it's not the most performant option
<kyrofa> The RAM is pretty low and, of course, overall it's slow
<jdstrand> kyrofa: it should be fine as a file server certainly though, yeah?
<kyrofa> jdstrand, yeah should be
<kyrofa> jdstrand, but before too long, you'll find yourself thinking "I should be using RAID..."
<jdstrand> I wonder if the rpi3 would be better... I have an rpi2 I was planning to use
<kyrofa> I hear it's a bit faster
<kyrofa> Haven't hooked mine up yet
<jdstrand> anyway, it should be fun
<kyrofa> (I use a slightly more beefy server for my nextcloud instance: https://pasteboard.co/GZ7SdxM.jpg)
<kyrofa> Yeah! Thanks for letting me know :)
<jdstrand> oh wow, yes :)
<jdstrand> I'm all about small these days. though, that isn't that big
<kyrofa> Downside of being a camera junky. RAW photos and video take so much space
<jdstrand> oh yeah
<kyrofa> Yeah it's a micro. I just needed the hard drives more than anything
<jdstrand> kyrofa: do you do edits over the network?
<j605> jdstrand: but I though spotify was using pulseaudio and it should just work
<j605> is this comment related to my problem, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/16
<mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1598309>
<jdstrand> j605: sorry, I didn't read backscroll. I'm using the spotify snap it and it is working with pulseaudio
<jdstrand> j605: is pulseaudio running on your system?
<kyrofa> jdstrand, not typically. I probably could if I was using ethernet, but I usually have at least one or two projects on my local disk that I'm working on. Once they're complete, I transfer them off to only live on the server
<jdstrand> j605: is the pulseaudio interfacec connected?
<j605> jdstrand: yeah I use pulseaudio
<jdstrand> j605: does 'snap interfaces' show that spotify has pulseaudio connected?
<sergiusens> kyrofa how's that work going?
<kyrofa> sergiusens, good, just finishing up
<sergiusens> nice
<sergiusens> kyrofa should we close elopio's PRs or are you going to overwrite them?
<kyrofa> sergiusens, I'll close them once I have the alternative up
<kyrofa> I was going to re-use, but they've diverged pretty far at this point
<j605> jdstrand: it has this ":pulseaudio                spotify"
<j605> I tried snap connect spotify:pulseaudio :pulseaudio but audio still doesn't work
<jdstrand> j605: what is the output of 'sudo journalctl | grep audit'. feel free to paste it in paste.ubuntu.com
<jdstrand> ogra_: hey-- oddly when I did 'sudo snap refresh core --candidate' (from stable) on my bbb, on reboot it dropped me to a uboot shell. not knowing what to do, I simply typed 'reset' (cpu reset) and it booted fine. have you ever seen that?
<j605> jdstrand: there is nothing to paste
<jdstrand> j605: oh right, this is arch
<j605> closing spotify does not exit the program, crtl+c on snap run causes a segfault
<j605> :(
<jdstrand> j605: I don't use arch so my best advice would be to create a topic on https://forum.snapcraft.io/
<jdstrand> j605: that said... if you run it from a terminal, what output do you see?
<jdstrand> j605: and what is the output of 'snap version'?
<j605>  2.30.r282.ge1eddad26-1
<j605> it is git master
<jdstrand> ok, it's good that you have a new snapd
<Odd_Bloke> kyrofa: sergiusens: Your thoughts on https://forum.snapcraft.io/t/snapcraft-support-for-pipenv/3264 would be appreciated. :)
<sergiusens> kyrofa I'd just close his PRs then :-)
<kyrofa> sergiusens, yeah that's the plan
<sergiusens> kyrofa I'll be almost done with DT NEEDED later tonight, also taking a bit of a detour to simplify things
<kyrofa> sergiusens, hopefully not detouring into meta or pluginhandler? :D
<sergiusens> kyrofa just a bit, on the call to load_dependencies; trivial if conflicts show
<kyrofa> Okay good deal
<j605> jdstrand: https://forum.snapcraft.io/t/spotify-does-not-play-audio/3266 the backtrace looks interesting
<j605> after reboot into lts kernel, I tried snap again and this time I got a better backtrace when it crashed
<wililupy> I want to use scriptlets in my snapcraft.yaml to install a kernel patch before build. Is there any examples of this?
<wililupy> I basically want to run gzip -cd patch.tar.gz | patch -p1 but I worry that it won't go to the correct directory where the kernel source is located. Are there any env variables I can use to ensure that it is patched properly?
<kenvandine> jdstrand, i can try it without.  It wouldn't launch at all without the browser-support interface
<kenvandine> but that might not be related
<jdstrand> kenvandine: I expect it to need the browser-support interface. I wasn't necessarily expecting that allow-sandbox: true was needed. Can you just change that to 'allow-sandbox: false' and see if it works?
<jdstrand> kenvandine: it might need it, but I want to confirm it
<jdstrand> and understand why
<cachio__> kenvandine, hey, I am trying to make a gsettings snap work in a linode image, any idea which packages should I install to allow it to work?
<kenvandine> jdstrand, confirmed it doesn't start without allow-sandbox
<kenvandine> hey cachio__
<cachio__> kenvandine, hey
<kenvandine> it depends on which schemas it needs to access.  Just schemas provided by the snap?
<cachio__> kenvandine, yes
<kenvandine> cachio__, probably just libglib2.0-0
<kenvandine> cachio__, and of course include gsettings in plugs
<cachio__> kenvandine, ok, I'll try with thtat
<kenvandine> cachio__, good luck
 * kenvandine runs out again
<jdstrand> kenvandine: ok. what are the denials?
#snappy 2017-12-21
<ikey> is it ok for me to make a new snapd interface?
<ikey> think im gonna need one for steam..
<sergiusens> ikey I am just going to mention jdstrand here so he can look in the morning; or maybe it makes itself into a forum post; if its simple enough I'd just create a PR
<ikey> ok
<ikey> it looks like i have no choice but to make one
<ikey> we have weird requirements
<ikey> the one im struggling with is the mknod denial..
<ikey> ok nvm fixed that one. lol
<mup> PR snapcraft#1802 closed: metadata: extract metadata from appstream <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1802>
<mup> PR snapcraft#1823 opened: elf: search for DT_NEEDED in prime and the base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1823>
<erkan982> âââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEnfdpyaaxi: dasjoe Trevinho Shibe benoitc iatrou fnordahl rob-oi-ma Ama
<erkan982> âââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEcgfhe: tanimislam iatrou fnordahl icey nottrobin m
<erkan982> âââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEpzzivqqi: kyrofa joedborg Stan
<erkan982> ââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODErsoty: iatrou StanleyHsiao paulmey matiasb marcoceppi_ cavea
<erkan982> âââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEeylvicwdq: Trevinho mpontillo caveat Cust0sLimen sdrobertw StanleyHsiao lfaraone petevg joedborg atriv jacekn
<erkan982> ââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEfrromdwkuq: JamieBennett AmarokNelg rob-
<erkan982> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEqddcwzw: StanleyHsiao petevg mardy nottrobin dragly cprov la_juyis Kaleo lfaraon
<erkan982> ââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEevivcj: lool tianon dragly dkessel la_juyis Kaleo petevg rob
<erkan982> âââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEesoaz: philroche joedborg dragly rob-oi-ma dasjoe Shibe ahayzen ralsin
<erkan982> âââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEywjvgmzgqn: iatrou icey jamespage AmarokNelg faenil stgraber Shibe loo
<erkan982> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEvxypasdzpn: matiasb JamieBennett Trevinho lool mardy tianon iatrou petevg AndyWo
<erkan982> âââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODExzsyqeboid: mardy ralsina abne
<erkan982> ââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEqqdzr: benoitc ahayzen marcoceppi_ blood
<erkan982> âââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEfcqoxefk: lool jacekn coreycb asac la_juyis matiasb Son_Goku mardy AndyWojo Trevinho paulm
<erkan982> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEmqivq: la_juyis icey jamespage magicaltrout Shibe tianon abner marcoceppi_ Cust0
<erkan982> âââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEuvhdqcp: AmarokNelg ahayzen coreycb magicaltrout philroche la_juyis cprov dkessel StanleyHsiao mpontillo icey
<erkan982> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEdsospbl: thibautr__ mardy kyrofa tanimislam paulmey Kaleo jacekn rob-oi-ma corey
<erkan982> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODErpely: coreycb ralsina paulmey iatrou ahayzen moon127 dkessel petevg bloodearnes
<erkan982> ââââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEnrdbnbutfu: mpontill
<erkan982> ââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEzfven: ahayzen om26er bloodearnest mpontillo la_juyis ahrs icey iatrou coreycb Cust0sLimen stgraber nottrobin fnordahl K
<erkan982> ââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEsfcxopsh: ahrs benoitc Son_Goku AndyWojo coreycb tianon la_juyis bloodearnest asac tanimislam rob-oi
<erkan982> âââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEwylbxiacm: StanleyHsiao joedborg Shibe icey Trevinho bloodearnest cprov caveat sdrobertw paulmey mpontillo la_
<erkan982> ââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEbsjxao: stgraber philroche caveat m4sk1n_ kyrofa tanimislam cprov JamieBennett petevg mardy StanleyHsiao thibautr__ drag
<erkan982> ââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEianpmabyg: faenil thibautr__ dasjoe StanleyHsiao bloodearnes
<erkan982> ââââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEextdkd: mpontillo ma
<erkan982> âââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEgfiegfqa: magicaltrout thibautr__ om26er cprov philroche dkessel Trevinho Kaleo paulmey ah
<erkan982> âââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEqsxsmvtya: dasjoe matiasb Kale
<mborzecki> morning
<kalikiana> good morning
<mborzecki> kalikiana: morning
<mborzecki> j605: hi, did you manage to start spotify with libpulse logs?
<mborzecki> mvo: morning
<mvo> hey mborzecki, good morning
<mvo> mborzecki: how are you?
<mborzecki> mvo: good, thank you
<mborzecki> seems like with debian-sid-64 gone, we can actually complete the tests
<mvo> mborzecki: yeah, the PRs look much nicer this morning
<mup> PR snapd#4414 closed: tests/main/interfaces-fuse_support: fix confinement, allow unmount, fix spread tests <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4414>
<mborzecki> mvo: do you have any idea why systemd-remount-fs might be failing like this? https://paste.ubuntu.com/26225909/
<mborzecki> it's happening in the image that the guy from yocto forum thread uploaded
<mvo> mborzecki: hm, we have not touched this at all for core, the message is also strange. something wrong with the permissions maybe in ls -l /lib/systemd/systemd-remount-fs ?
<mvo> mborzecki: stracing it might be nice, especially with -e trace=execve -s1024 to see what it passes to mount
<mborzecki> what's funny, in the console, id gives: uid=0(root) gid=0(root)
<mborzecki> mount /dev/hda2 /mnt: mount: only root can do that (effective UID is 1000)
<mborzecki> hmm ok
<mborzecki> but i'm in the maintenance shell started by systemd that could not complete system init :/
<mvo> mborzecki: uhh
<mvo> mborzecki: that is strange indeed
<mborzecki> -rwxr-xr-x    1 1000     1000       1148876 Dec 14 10:23 /lib/systemd/systemd
<mvo> mborzecki: aha!
<mvo> mborzecki: I bet most of the FS is owned by uid 1000 instead 0
<mborzecki> it is
<mborzecki> nevertheless, the kernel starts init with uid/gid 0 right?
<mvo> mborzecki: yes, your /bin/shell is also owned by 1000:1000 I pressume so it seems like this makes the euid also 1000 (which is new to me but I never dealt with a system with wonky permissions like this before)
<j605> mborzecki: this log is with the debug flags, https://ptpb.pw/VbIw
<mborzecki> Trying to connect to /run/user/1000/snap.spotify/pulse/native...
<mborzecki> connect(): No such file or directory (2)
<mborzecki> this ^^ is interesting
<mborzecki> j605: can you `ls -l /run/user/1000/pulse/` ?
<j605> the directory is empty
<mborzecki> j605: `ps -ef|grep pulse` is there a pulseaudio daemon workign for your user?
<j605> mborzecki: jagan     1960  1954  1 Dec20 ?        00:12:49 /usr/bin/pulseaudio --daemonize=nojagan     1978  1960  0 Dec20 ?        00:00:00 /usr/lib/pulse/gconf-helper
<j605> from systemctl --user status pulseaudio.socket, "Listen: /run/user/1000/pulse/native (Stream)"
<mborzecki> j605: can you try pulseaudio -k && pulseaudio --start and check if a socket appears under /run/user/1000/pulse/native ?
<j605> the socket already exists
<j605> it doesn't exist under snap.spotify
<j605> > srw-rw-rw- 1 jagan jagan 0 Dec 20 20:57 native=
<mborzecki> j605: can you run `snap run --shell spotify` and then `ls -l /run/user/$(id -u)/pulse` inside that shell?
<j605> mborzecki: https://paste.ubuntu.com/26226041/
<mborzecki> j605: this is using snapd-git right?
<j605> mborzecki: yes
<mborzecki> j605: in your log, spotify is trying /run/user/1000/snap.spotify/pulse/native, can you also `snap run --shell spotify` and ls -l this path?
<j605> mborzecki: it is empty
<mborzecki> mvo: XDG_RUNTIME_DIR is something we populate right?
<j605> mborzecki: is that directory a symlink to /run/user/1000/pulse if it works correctly?
<mvo> mborzecki: yes, we set this
<mvo> mborzecki: via the `snap run` mechanism
<mborzecki> mvo: ^^ i guess it's a bind mount or sth?
<mvo> mborzecki: I need to check, there was some discussion in the context of wayland and things changed a bit, let me see
<mvo> mborzecki: is that the problem for j605 ? that the pulse socket is in xdg_runtime_dir but because we change it spotify cannot find it?
<mvo> mborzecki: https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186 was the discussion I had in mind
<mborzecki> mvo: something weird, XDG_RUNTIME_DIR=/run/user/1000/snap.spotify and for j605 libpulse tries that location, in my case it's completely ignored and instead /run/user/1000/pulse/native is used
<mvo> mborzecki: yeah, so one easy fix would be in the spotify snap to do what is done for the wayland socket, i.e. a tiny snippet that creates a symlink
<j605> for me that is never tried, after snap.spotify it goes to /var/run/pulse/native
<mvo> j605: out of curiosity, if you create a symlink from /var/run/pulse/native to /run/user/1000/pulse/native - does that work?
<mvo> (not as a permanent fix, more out of curiosity)
<j605> seems messy since I need to be root for this but pulse is started per user
<j605> mvo: it works
<j605> may snapd should look into the user dir before going to /var/run/pulse
<mvo> j605: thanks for confirming! yeah, the symlink is not a "solution", just to see if that was the only piece in the puzzle to make things work
<mvo> j605: I think we have various ways to fix this, one is to ask spotify to modify the snap (as outlined above) or we could manually migrate the pulse socket into "our" runtime dir
<mvo> j605, mborzecki thanks for getting to the bottom of this! will you update the forum topic with the findings? I can quickly create a PR to make the socket appear in the right dir
<j605> I am not sure how it worked for popey in Manjaor. May be it is doing things differently
<j605> may be a log from him would be nice to see
<j605> mvo: sure
<mvo> j605: yeah, its all a bit odd, also that it works for mborzecki who is also using arch AIUI. but its fine, we figured it out, now we just need to implement the fix :)
<mvo> j605: he should be around soon, we can ask him for logs
<mborzecki> i'm grabbing a cofee :) bb in a while
<mborzecki> mvo: just a thought, but shouldn't pulseaudio 'interface' be doing this? i mean bind mount /run/user/$(id -u)/pulse to $XDG_RUNTIME_DIR/pulse inside the snap?
<j605> so that fixes vlc as well :)
<mborzecki> yay
<mvo> mborzecki: tying it to the interface would be ideal, not sure how feasible this is with the current structure we have
<mborzecki> btw. still a mystery why it looks in a different location here
<mborzecki> hmm
<mborzecki> or
<mborzecki> mvo: do you need any help with the PR?
<mvo> mborzecki: I have not even started yet, I was starring at command-not-found, feel free to pick it up if you want
<mborzecki> mvo: hm i don't exactly see where we could put the symlink part in current code, maybe snap-confine, there's some xdg setup code but it's currently disabled
<mvo> mborzecki: yeah, snap-confine was my thinking, the same way we make the Xauthority file available
<mborzecki> it'd be great to have per-interface exec hooks that are part of snapd
 * kalikiana coffee break
<sergiusens> diddledan corebird all of the sudden does not launch for me, I tried a reinstall (refresh data on snap info is no wrong though :-P); I don't see anything wrong, did anyone else mention it not working anymore?
<kalikiana> sergiusens: which version are you using? the version on edge launches for me (r88), despite errors about libopenh264.so.bz2 and libgstalsa.so - I don't use it much, but it's showing tweets fine
 * kalikiana FYI going to have lunch in ~15min
<mickesummer> Hi, I have installed the RPI2 and PRI3 image for ubuntu core. Both on a RPI2 and RPI3. I boot up the PI, follow the instructions. Logon with SSH to the PI with the SSO (ubuntu ont account). After a reboot, I cant logon. The account has disapeard. I have to run the "wizard" again. Any ideas?
<kalikiana> bbl
<mborzecki> i'm off to pick up the kids
<mup> PR snapcraft#1822 closed: tests: skip classic confined tests on armhf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1822>
<mup> PR snapcraft#1807 closed: tests: run test_cleanbuild in LXD on Travis <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1807>
<jdstrand> ikey: anyone can propose an interface. if it is easy/straightforward, just submit a PR. if you think there needs to be discussion, I'd suggest a forum topic
<jdstrand> ikey: do note that many of us are either on holidya or going on holiday soon
<kalikiana> re
<ikey> jdstrand, yeah no worries bud :D
<ikey> i got the vast majority of it up and running last night
<ikey> in the end i couldnt see any other way than the creation of a new interface
<ikey> i preliminarily named it "steam" but ill likely rename it "steam-support"
<ikey> and its already full of ugly steam specifics: https://hastebin.com/usadagasug.bash
<jdstrand> ikey: interesting. I don't see anything conceptually wrong with a steam-support interface (esp for the shm accesses). we might want to move some rules around/etc, but feel free to send up when you're happy and we can iterate
<ikey> sure :D
<ikey> it needs some work yet and fleshing out
<ikey> *but* i did finally manage to get steam working under full confinement
<jdstrand> cool. thanks for working on it :)
<jdstrand> that's awesome :)
<ikey> only real bug i need to work out is why i cant execute things on another partition
<ikey> and i think my snapd version is bugged truthfully
<ikey> i ran "snap run --shell linux-steam-integration" with fresh installs last night
<ikey> hit "ctrl+d"
<ikey> then i got invalid syscall errors
<jdstrand> ikey: if you don't know about this already: sudo sysctl -w kernel.printk_ratelimit=0
<ikey> and it was impossible to run "--shell" again
<jdstrand> sometimes denials get rate limited
<ikey> aah
<ikey> ty ty
<jdstrand> snappy-debug will do that for you, but if you are just taling the log, you'll want to do that
<ikey> yeah
<ikey> "what went boom"
<jdstrand> ikey: I have an alias for: sudo sysctl -w kernel.printk_ratelimit=0 ; journalctl --follow
<ikey> heh
<ikey> i think apparmor is gonna need new variables once im done with this.. :p
<jdstrand> heh
<ikey> having uid/pgrpid could be useful..
<jdstrand> yeah
<jdstrand> kernel side variables would be super handy
<jdstrand> it's on the roadmap
<ikey> oh fantastic
<ikey> i see someone let /usr/share/themes through too
<ikey> must be for gnome bases?
<ikey> because my bundled themes kept working :p
<ikey> was quite happy about that lol
<jdstrand> jhenstridge has been improving fonts, themes, etc
<jdstrand> hehe
<jdstrand> nice!
<ikey> ah right - saved me a whole bunch of bother then
<jdstrand> I think if you use the desktop interface with updated desktop snapcraft parts, you get more and more goodness
<ikey> oh right
<ikey> atm we're not actually using desktop snapcraft at all
<ikey> so i might need to merge behaviours
<ikey> we have a main entry point, "$SNAP/linux-steam-integration"
<ikey> which has lots of magical shim entry work
<jdstrand> I think the biggest improvement lately was the gschemas work
<jdstrand> so you don't have a slow first startup
<ikey> AOT compilation?
<ikey> tbh i think im even safe in that regard
<ikey> all my schemas are inside the runtime
<ikey> and the LSI snap is tiny - just the shim and zenity and mesa-demos and such
 * jdstrand nods
<ikey> i think once this confinement story is solved i can move onto the last challenges like udev + joystick improvements
<ikey> then we could see steam "done" early '18
<jdstrand> that would be great :)
<ikey> didnt mean for it to take so long :/
<kyrofa> kalikiana, sergiusens I'll be right there
<sergiusens> firefox isn't working fwiw
<kyrofa> Oh darn, I saw a tweet about it and wanted to try
<cprov> kyrofa: bug #1739260 fix just got released.
<mup> Bug #1739260: Add macaroon expiration date to acl/verify endpoint <Snap Store:Fix Released by cprov> <https://launchpad.net/bugs/1739260>
<diddledan> sergiusens: I had a report a week or so ago, but they rebooted and it started working again (ref: Corebird not working)
<diddledan> sounds scarily like windows behaviour to me :-p
<diddledan> ikey: did you get zenity to work in snap? the ubuntu variant has hardcoded it's location so you can't get ubuntu snaps to use zenity
<ikey> yeah i have some patches
<diddledan> aha
<ikey> here lemme find linky
<om26er> popey: ping
<ikey> https://github.com/solus-project/runtime-snaps/tree/master/support_packages/zenity/files
<ikey> the most important patch is the 0001 patch
<diddledan> I wonder if we could get those upstreamed... *scratchy head*
<ikey> it allows us to build a relocatable zenity binary with gresource compiled in
<om26er> popey: thoughts on promoting sublime-text and android-studio to 'stable' channel ?
<ikey> id like to for zenity but i couldnt get distcheck unbroken lol
<popey> om26er: how robust are they both?
<popey> Any feedback from users?
<om26er> popey: there was an issue with sublime that was fixed quite a few days ago.
<om26er> popey: Android Studio seems to be running solid. I gave it a try on a clean VM today, just to be sure.
<popey> Nice one. I will do the same
<mcphail> Out of interest, why does the "joystick" interface not autoconnect? it would seem like a much smaller security risk than "network"...
<ikey> not sure as for the why right now, but i imagine joystick is going to grow in future
<ikey> i.e. to support wheels and steam controller
<ikey> though some of that is likely up in hidraw too..
<kyrofa> mcphail, can't speak for the security team (I'll let jdstrand speak up), but it's my understanding that all interfaces are considered risky. We don't want to speak for the users regarding the risk they're willing to accept as much as possible
<kyrofa> mcphail, there are some interfaces we auto-connect as snaps would be useless without them
<kyrofa> But the rest, we leave up to them
<mcphail> kyrofa: yes, i think paranoia by default is sensible. but, as a user, i'd be more worried by the network interface than the joystick one. and the syntax to connect these things is pretty horrible. are there plans for a gui so users could drag and drop connections?
<kyrofa> mcphail, yeah I actually dislike some of the ones we autoconnect as well: https://forum.snapcraft.io/t/autoconnection-override/2465/4
<kyrofa> Regarding the GUI, I think so, but you'll need to talk to the desktop folks
<kyrofa> (or maybe jdstrand has more insight there)
<mcphail> aah. it'd be nice to have a panel in the gnome settings thingy where users could set their own defaults, then separate tabs for individual snaps
<mcphail> i'd probably have joystick as an autoconnect and network as manual on my default panel :)
<kalikiana> kyrofa: wrt snapcraft#1817 ironically, the raw properties are not preserved in pluginhandler, but preprocessed with default values... so I added another property with the original properties and a check if it was specified... lemme know what you think
<mup> PR snapcraft#1817: grammar: support strings <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1817>
<jdstrand> the gui will make that better. it is best to not autoconnect hardware by default. we can use snap declarations for autoconnection, but very much looking forward to the gui
<mcphail> jdstrand: cool. thanks!
<sergiusens> jdstrand once apps don't get sigkilled autoconnection wouldn't be such a big problem
<sergiusens> not having autoconnection
<jdstrand> well, people will always want this or that (not everything is sigkilled-- mostly just process-control)
<jdstrand> I'm looking forward to that PR too :)
<kalikiana> sergiusens: kyrofa wrapping for the year now. FYI confirmed lxd/core from stable work fine with persistent containers, whatever is broken with edge will need to be investigated in the new year
<kyrofa> Alright kalikiana, thank you!
<jdstrand> kalikiana: enjoy your holiday :)
<kalikiana> Cheers
<kalikiana> Same to you (soon)
<kalikiana> o/
<sergiusens> kyrofa #1823 is good for a review
<mup> PR #1823: overlord/devicestate: try to fetch/refresh the signing key of serial (also in case is not there yet) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1823>
<sergiusens> kyrofa a final one, the snapcraft one, not that
<diddledan> looks like another of my snaps made it to the 10 featured in the monthly summary: https://insights.ubuntu.com/2017/12/20/top-snaps-in-november
<diddledan> specifically mars the ridiculous shooter
<kenvandine> diddledan, awesome
<popey> ogra_: do you know what work is needed to make your wine snap strict?
<diddledan> I vote for whips and chains
<cachio> kenvandine, I am running in a linode image a gsettings app and it is not creating the dconf dir in ~/snap/test-snapd-gsettings/27/.config/
<cachio> kenvandine, any idea why it could be happening?
<kenvandine> cachio, do you have a user session running?
<kenvandine> cachio, can i see your yaml?
<cachio> kenvandine, https://paste.ubuntu.com/26228811/
<cachio> in the test I create a user
<cachio> and execute the gesettings command from that user session
<kenvandine> cachio, so dbus is running?
<cachio> https://paste.ubuntu.com/26228820/
<cachio> kenvandine, this is what I see
<kenvandine> cachio, iirc you need to do something like this
<kenvandine> eval `dbus-launch --sh-syntax`
<kenvandine> cachio, https://dbus.freedesktop.org/doc/dbus-launch.1.html
<kenvandine> cachio, oh... this is interesting
<kenvandine> To start a D-Bus session within a text-mode session, do not use dbus-launch. Instead, see dbus-run-session(1).
<cachio> ok, trying it
<kenvandine> cachio, read the man page on that
<kenvandine>        dbus-run-session -- bash
<kenvandine> might be what you want
<kenvandine> or... in your snap
<cachio> kenvandine, shoiuld I run it as part of the snap command?
<kenvandine> command: dbus-run-session -- desktop-launch desktop-launch $SNAP/gsettings "$@"
<kenvandine> maybe :)
<kenvandine> if not, you probably need to use dbus-run-session to setup the environment before executing the snap
<kenvandine> cachio, if you add it to the command in the snap, it won't behave well for tests trying to run on the desktop
<cachio> kenvandine, i'll try this dbus-run-session -- desktop-launch $SNAP/gsettings "$@"
<cachio> kenvandine, I am getting dbus-run-session: Permission denied
<kenvandine> dunno
<cachio> kenvandine, should I plug another interface?
<kenvandine> i think you need to run that before running your snap
<kenvandine> so pull it out of the yaml
<kenvandine> dbus-run-session -- bash
<kenvandine> before running the snap
<kenvandine> i think that might work
<cachio> ok
<cachio> kenvandine, nothing
<cachio> kenvandine, it is not saving the values
<cachio> I save a value for a key and it is not saved
<cachio> but I can access to the default value
<cachio> kenvandine, is there any log to see?
<kenvandine> cachio, oh.. it can read the the values?
<cachio> kenvandine, yes, but the default ones
<cachio> kenvandine, it is not able to save
<kenvandine> must be using the memory backend
<kenvandine> cachio, is this file getting created?
<kenvandine> ~/snap/test-snapd-gsettings/current/.config/dconf/user
<cachio> kenvandine, no
<cachio> kenvandine, this dir does not exist ~/snap/test-snapd-gsettings/current/.config/dconf
<kenvandine> does  ~/snap/test-snapd-gsettings/current/.config ?
<cachio> yes
<cachio> https://paste.ubuntu.com/26229018/
<kenvandine> cachio, what do you have in /run/user/$(id -u)/
<cachio> kenvandine, I manually created the dir snap.test-snapd-gsettings on there
<cachio> kenvandine, https://paste.ubuntu.com/26229029/
<kenvandine> cachio, and in your snap, is gsettings a script or binary?
<cachio> kenvandine, it is a script
<kenvandine> can you try running it without the snap?
<kenvandine> rule out any of the desktop helpers or snap
<kenvandine> maybe it's related to the session
<cachio> I'll try it
<cachio> kenvandine, not working
<kenvandine> ok, so that rules out the snap itself
<cachio> I am executing the script and it is not saving the valus
<kenvandine> yeah, it's probably falling back to the memory backend
<cachio> and if I run /usr/bin/gsettings it works
<kenvandine> not sure how to set that
<kenvandine> cachio, can i see your script?
<cachio> kenvandine, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/test-snapd-gsettings/files
<mup> PR snapcraft#1824 opened: Update test_rpm.py <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1824>
<mup> Issue snapcraft#1664 closed: Search prime for DT_NEEDED and add rpath <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1664>
<mup> PR snapcraft#1823 closed: elf: search for DT_NEEDED in prime and the base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1823>
<kenvandine> cachio, i think you need new_with_backend there
<kenvandine> https://people.gnome.org/~gcampagna/docs/Gio-2.0/Gio.Settings.new_with_backend.html
<cachio> kenvandine, ok
<kenvandine> cachio, better docs https://lazka.github.io/pgi-docs/Gio-2.0/classes/Settings.html#Gio.Settings.new_with_backend
<kenvandine> cachio, oh... that might not be the issue at all
<kenvandine> you don't have a main loop
<kenvandine> your script is going to exit before the change can be made
<kenvandine> i think
<kenvandine> for gsettings, you really need a main loop and wait until you get the changed notification from gsettings before exiting
<cachio> kenvandine, ok, I'll work on that
<cachio> kenvandine, I'll ping you tomorrow
<kenvandine> cachio, i'm off tomorrow :)
<cachio> kenvandine, ok :(
<kenvandine> cachio, hopefully you won't need me tomorrow :)
<cachio> kenvandine, hopefully
<cachio> thanks for helping me
<kenvandine> happy to help
 * cachio afk
<mup> PR snapcraft#1825 opened: metadata: add infrastructure for extracting metadata from parts <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1825>
<mup> Issue snapcraft#1686 closed: Support strings in grammar <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1686>
<cmiles74> I'm working on getting snap/snapd working under NixOS. When a snap is mounted, it tries to create a symlink to /etc/system/d/system representing the mount... On NixOS, most of /etc (including this path) is read-only. Can I set a flag or something to get the systemd unit written somewhere else? I could maybe link a directory in and get it working that way.
<Son_Goku> cmiles74: no
<Son_Goku> you'll need to patch it to put it somewhere else
<Son_Goku> snapd assumes it has control of the system
<cmiles74> Son_Goku: Thank you. This seems like something I could make work, like it would work. Does that seem reasonable? I'm hoping it won't lead to another issue, etc.
<Son_Goku> cmiles74: it's possible, at least you're not trying to rip out systemd requirements like the Slackware guys...
<Son_Goku> snapd heavily leverages systemd functionality
<Son_Goku> but if you've got a different writable path, you'll need to patch systemd to use that path instead
<Son_Goku> also note that snapd has to operate privileged
<Son_Goku> as it manipulates seccomp filters, among other things
<cmiles74> Son_Goku: I don't want to remove systemd, but NixOS has some pretty particular ideas about how things in /etc, /lib, and so on should be managed. I can write things in there at install time, but at run time writing things to /etc isn't allowed. My idea is to get snap to write the system files to another location and then I will symlink them into the proper location in /etc afterwards.
<Son_Goku> if snapd is running as root, it should have write access to /etc
<jdstrand> kyrofa: hey, would you mind voting on https://forum.snapcraft.io/t/alias-request-for-snap-john-the-ripper/3169/2?
<kyrofa> jdstrand, sure, let me take a look
<jdstrand> kyrofa: it should be all of 10 seconds. pinging directly since so many or on holiday
<jdstrand> s/or/are/
<kyrofa> jdstrand, you never need to apologize for pinging me :)
<jdstrand> thanks :)
<kyrofa> jdstrand, how high-traffic is that topic? I'm not subscribed, but perhaps I should be
<kyrofa> Er, not topic, but category
<jdstrand> not very
<kyrofa> Alright, subscribed
<jdstrand> cool. thanks for the vote
<jdstrand> and with that, I am eoy
<jdstrand> happy holidays everyone :)
<mcphail> jdstrand: Happy christmas and a guid new year!
<ikey> but not a setguid new year
<kyrofa> Seeya in the new year, jdstrand. Merry Christmas!
<mup> Issue snapcraft#1687 closed: Make source grammar-powered <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1687>
<mup> PR snapcraft#1817 closed: grammar: support strings <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1817>
<mup> PR snapcraft#1826 opened: appstream: extract appstream metadata from parts <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1826>
#snappy 2017-12-22
<mborzecki> morning
<mvo> hey mborzecki
<mvo> good morning
<mborzecki> last day this year :)
<mborzecki> mvo: are you aware of any documentation for snapd that might list kernel config options that we require?
<mvo> mborzecki: yeah, last day!
<mvo> mborzecki: I don't think we have such a list yet
<mvo> mborzecki: sounds like a good forum topic
<mvo> mborzecki: there is a "docs" tag in the forum
<mborzecki> there's a guy right here, clearly having some issue with the kernel missing features that we need, https://forum.snapcraft.io/t/mount-of-core-failed-to-setup-loop-device/3267/8
<mvo> mborzecki: yeah, just looked over this and indeed, he probably missed squashfs first and now cgroup freezer
<mborzecki> i'm writing a reply, just wanted to double check if we have something i could point him to
 * mvo nods
<mup> Issue snapcraft#1827 opened: cross-compilation support for catkin plugin <Created by Timple> <https://github.com/snapcore/snapcraft/issue/1827>
<mup> PR snapd#4420 opened: cmd: clarify "This leaves %s tracking %s." message <Created by mvo5> <https://github.com/snapcore/snapd/pull/4420>
<mborzecki> hmm now i have 2 spotifys installed, so picking the icon from gnome dashboard i have no clue which one will start
<mvo> mborzecki: yeah, thats annoying
<mup> PR snapd#4421 opened: daemon: add new polkit action to manage interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/4421>
<mborzecki> mvo: on arch there's no locale set by default so it's C, we override it in tests and set it C.UTF-8 (which doesn't work btw), now if i do `LC_ALL=C snap info` i'll get utf-8 characters anyway (the arrow pointing upwards)
<ikey> C.UTF-8 is a Debuntuism
<ikey> Doesn't exist anywhere else
<mborzecki> yup, we've discussed this :)
<mborzecki> small patch on glibc side, but unlikely to hit arch unless upstream merges it
<ikey> was it ever sent upstream? not tryna be funny just generally curious
<ikey> i know gnu projects are terrible at responding to patches in general
<mborzecki> ikey: https://sourceware.org/bugzilla/show_bug.cgi?id=17318
<ikey> 3 years, not bad
<ikey> i figured if it was it was maybe 4, in my head, lol
<mborzecki> idk, glibc has become much more civlized since leadership change
<ikey> glibc itself has yes, but GNU projects still have a certain way around them.. ^^
<ikey> 'cept nano. nano is just cool
 * ikey goes off to steal utf8 patch for solus
<ikey> erm imean borrow
<mborzecki> ikey: it's all free software after all, right? :)
<ikey> indeed :D
<mborzecki> anyways, i suppose we shouldn't output utf-8 unless the it's allowed by locale
<mvo> mborzecki: yeah, this looks iffy, thanks for noticing
<mup> Issue snapcraft#1693 closed: Develop metadata handler system <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1693>
<mup> PR snapcraft#1825 closed: metadata: add infrastructure for extracting metadata from parts <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1825>
<ikey> q: i see that the metadata can be extracted *from* appstream, but is the appstream raw data available separately somehow?
<ikey> i.e. for software center integration and non broken screenshots
<mup> Issue snapcraft#1828 opened: Support desktop and icon in appstream handler <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1828>
<sergiusens> ikey that is a simpler part once the bike shedding on what to call the entry ends :-)
<ikey> ah
<sergiusens> so, maybe, it is the hardest part as it involves people :-P
<ikey> yeaa
 * sergiusens goes off to run some errands
<mup> PR snapd#4422 opened: packaging/arch: disable services when removing <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4422>
<mvo> mborzecki: slightly sad that the last two PRs are unhappy again
<mborzecki> mvo: which ones?
<mvo> mborzecki: my last two, one looks real, so my fault but one had a spurious test failure. oh well
<mvo> mborzecki: but things in general are better, its just a single failure at least :)
<mvo> mborzecki: thanks for spotting the extra whitespace btw
<mborzecki> nothing compared to what we had with debian sid :)
<mborzecki> sure
<mborzecki> fwiw, i think it'd be nice to renable debian sid at some point, it's possible that we were causing the instability after all :P
<mvo> mborzecki: yeah, definitely, we need to investigate that
<mvo> mborzecki: its also likely that real users on sid have problems :(
<mvo> mborzecki: but then, sid is by nature unstable but still
<mborzecki> 'real users', you mean debian devs? :D
<mvo> lol
<mvo> *cough* yes
<mborzecki> mvo: #4404 selinux PR that i mentioned
<mup> PR #4404: data/selinux: allow messages from policykit <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4404>
<mup> Issue snapcraft#1694 closed: Develop appstream handler <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1694>
<mup> PR snapcraft#1826 closed: extractors: support appstream metadata in parts <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1826>
<mborzecki> mvo: the exact forum topic is https://forum.snapcraft.io/t/selinux-blocking-snapd-since-update-on-fedora-27/3002 shall I tag it?
 * sergiusens waves again
<mvo> mborzecki: thanks, I cherry-pick it
<mborzecki> mvo: great
<mvo> mborzecki: cherry-picked, thanks for the reminder
<mborzecki> sure
 * Son_Goku hopes that now people other than him will actually help fix snapd-selinux things
<ikey> people use selinux?
<ikey> *runs*
<mup> PR snapd#4423 opened: snap: provide more meaningful errors for installMany and friends <Created by mvo5> <https://github.com/snapcore/snapd/pull/4423>
<ikey> i meant *merry christmas
<ikey> common typo
<Son_Goku> ikey: your sarcasm is noted and ignored
<Son_Goku> it's not quite Christmas yet, so Happy Holidays :)
<ikey> i expected no less :P
<ikey> yep. merry christmas. :)
<ikey> ( :P )
 * ikey doesn't buy into the happy holidays thing
<Son_Goku> well, technically we're in Hanukkah right now
<ikey> oh right
<ikey> happy harmonica
<Son_Goku> :D
 * ikey is cultured
 * mvo is impressed
<Son_Goku> at one point, I've celebrated both
<ikey> oh cool
<Son_Goku> used to hang out with a Jewish family a lot as a kid
<Son_Goku> so we did both
<ikey> ah
<Son_Goku> my family isn't Christian (not too surprising), so we were okay with doing both
<ikey> irish catholic family so we had a different approach altogether
<ikey> if something went wrong it was probably our fault and thats why god doesnt love us :P
<Son_Goku> ...
<Son_Goku> that's, terrifying
<ikey> hey we got chocolates
<ikey> was worth it
<ikey> xD
<Son_Goku> heh
<ikey> besides, it didn't have any lasting effects
 * ikey settles the eye twitch
<Son_Goku> you know, I'm not so sure...
<ikey> lmao
<mborzecki> Son_Goku: fwiw, i'll do what i can on the snapd-selinux front :)
<Son_Goku> the only other thing I hope for is someone to implement an selinux backend for the snappy security rules HLL
<oSoMoN> Iâve finally taken the time to rename the play0ad snap to "0ad", now that this is a valid name, wondering if there's a mechanism in place to transition existing users to the new snap?
<mup> PR snapcraft#1829 opened: pluginhandler: warn the inclusion of libraries from the host <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1829>
<sergiusens> ikey don't buy into the happy holidays or the happy part of it? :-)
<ikey> the not saying christmas part of it
<sergiusens> ah, yeah, over here it's around 40 Celsius, the vibe is totally different than in the north
 * sergiusens just realized that George R. R. might have had a vision; if that wall gets built and we see the "Day after tomorrow" happen; will there be white walkers?
<Son_Goku> ikey: when it's actually Christmas, I'll say "Merry Christmas" :)
<Son_Goku> but as most people I know aren't Jewish, Happy Hanukkah doesn't quite work and some people get offended
<mborzecki> ok, i'm done for today and this year :) enjoy your holidays, see you around in 2018
<mvo> mborzecki: thank you! enjoy the holidays
<mup> PR snapd#4424 opened: corecfg: pam_env can only handle 1024 byte <Created by mvo5> <https://github.com/snapcore/snapd/pull/4424>
<mup> PR snapd#4425 opened: config: add support for `snap set core proxy.no_proxy=...` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4425>
<mvo> popey: if you are still around, I'm trying to reproduce the xdg-open from classic snap crash currently, do you know if we have any electron classic snap in the store that I can try?
<popey> mvo: hmm. flexiondotorg might have a better list...
<mvo> popey: thanks, I tried with electron-quick-start but when I create a link there it uses the internal browser, it does not luanch anything external
<cachio> mvo, in opensuse it is happening that if I remove and install the snapd.rpm then the snapd.service is not started automatically
<cachio> and it is making hte test snap-set-core-w-no-core to fail
<mvo> cachio: oh, that is strange. maybe morphis knows more, iirc he did the initial opensuse packaging. or zyga
<cachio> mvo, sure, thanks
<popey> mvo: i might have a private snap I could share with you which exhibits the issue?
<mvo> popey: sure, that would work
<flexiondotorg> mvo popey I've fixed most of the classic Electron snaps in the store.
<mvo> flexiondotorg: oh? what did that involve?
<mvo> flexiondotorg: fwiw, context is https://bugs.launchpad.net/snapd/+bug/1736925
<mup> Bug #1736925: SIGSEGV while calling xdg-open from classic snap of Electron application <snapd:Incomplete> <https://launchpad.net/bugs/1736925>
<popey> flexiondotorg: even the one where the voip client would crash on loading firefox?
<popey> mvo: answered https://bugs.launchpad.net/snapd/+bug/1736939
<mup> Bug #1736939: Classic snaps do not work on some Linux distros <snapd:Incomplete> <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1736939>
<popey> it's not missing /snap
<Son_Goku> it doesn't matter because classic snaps won't work anyway
<Son_Goku> even if the redirections are working, they'll fail due to ABI incompat
<Son_Goku> there are several issues that the snapcraft guys and I noticed about classic snaps leaking and pulling stuff from the host libraries instead of the base snap
<Son_Goku> it also broke classic snaps with Ubuntu 17.10 too, if I remember correctly
<Son_Goku> popey: and this is why I don't *ever* suggest making classic snaps work in Fedora
<Son_Goku> the whole classic snaps thing is fundamentally broken
<popey> Ok :)
<Son_Goku> there a bunch of things that need to change to make classic snaps saner, but unfortunately, as niemeyer and I discussed it a while back, it's pretty hard to fix
<flexiondotorg> popey: Yes, the voip client opening the browser is fixed by using snapcraft 2.30 from the beta channel. Confirmed upstream.
<flexiondotorg> Son_Goku: The issue you describe should be resolved with snapcraft 2.30, which is currently in the beta channel.
<Son_Goku> but most snaps aren't built with it
<flexiondotorg> Right, but we are contacting the publishers who are affected.
<flexiondotorg> Many are already fixed in the store.
<mup> PR snapcraft#1829 closed: pluginhandler: warn the inclusion of libraries from the host <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1829>
<mvo> flexiondotorg: \o/ for fixing the world!
<flexiondotorg> mvo: Thank sergiusens :-)
 * mvo hugs sergiusens 
<sergiusens> hey, glad to help! meta-team effort as always though! :-)
<mup> Issue snapcraft#1827 closed: cross-compilation support for catkin plugin <Created by Timple> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1827>
<kyrofa> cprov, any chance you're around?
<kyrofa> cprov, unping. Got it
<kyrofa> Although cprov, the time returned from acl/verify does not seem to have timezone information in it
<flexiondotorg> sergiusens: What snapcraft LP bug actually closes this? - https://bugs.launchpad.net/snapd/+bug/1736925
<mup> Bug #1736925: SIGSEGV while calling xdg-open from classic snap of Electron application <snapd:Incomplete> <https://launchpad.net/bugs/1736925>
<mup> PR snapd#4426 opened: snap: print friendly message if `snap keys` is empty <Created by mvo5> <https://github.com/snapcore/snapd/pull/4426>
<mup> PR snapcraft#1830 opened: Release changelog for 2.38 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1830>
<mup> PR snapcraft#1831 opened: cli: add expiration option to export-login <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1831>
<mup> PR snapcraft#1830 closed: Release changelog for 2.38 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1830>
<sergiusens> ikey by any chance do you know of any cli project using appstream?
<Son_Goku> sergiusens: there's a few web projects that use it
<Son_Goku> off the top of my head, while AppStream supports console apps, GNOME Software and Plasma Discover will exclude all of them from the view or search
<cmiles74> I have snapd running and it'll download and mount snaps, the mount unit files appear in systemd and systemd returns their status correctly. Still, I'm seeing an error "Mount snap 'core' (3604) (internal error: could not unmarshal state entry 'snap-type': invalid snap type '')". Does anyone know what might be causing the issue? I'm on kernel 4.9.70; I am seeing complains from snapd at startup about apparmor
<cmiles74> being enabled but some features are missing (dbus, mount, namespaces, network, ptrace, signal).
<kyrofa> cmiles74, I always get that until I reboot at least once after creating a lxd container
<cmiles74> kyrofa: Thank you, that is easy to test! :-D
<kyrofa> Not sure what the issue is, but something doesn't get setup until I reboot
<kyrofa> cmiles74, I'm crossing my fingers for you!
<cmiles74> kyrofa: I have a pretty non-standard setup, I'm working on the NixOS module. My expectations are... low.
<kyrofa> cmiles74, hey, pretty awesome progress though
<cmiles74> kyrofa: Thank you for the encouragement. :-)
<jjohansen> cmiles74: what kernel are you using?
<cmiles74> jjohansen: kernel 4.9.70. Do you know if that's too old?
<jjohansen> cmiles74: so not too old on an ubuntu kernel but
<jjohansen> the namespaces stuff primarily landed in upstream 4.10 and 4.11
<jjohansen> ptrace in 4.13
<jjohansen> mount and signal in 4.14
<jjohansen> unfortunately there were issues with network and dbus stuff in 4.14 so that part got reverted and we are trying again for 4.16
<cmiles74> jjohansen: Thank you. I'll try moving up to 4.14.7 and see if that makes a difference... I think there's a 4.15-rc1 package as well.
<mup> Bug #1738295 changed: snap auto-refresh re-installs removed snaps <Snappy:Invalid> <https://launchpad.net/bugs/1738295>
#snappy 2017-12-23
<mup> Bug #1579268 opened: Mouse cursor is different inside graphical windows of snaps (snaps not using system theme) <Snappy:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1579268>
<cprov> kyrofa: hey, re. expires TZ, it doesn't record timezones atm and is interpreted as utc.
<cprov> kyrofa: and sorry I wasn't around yesterday.
<kyrofa> cprov, no problem! Would it be possible to return UTC TZ?
<cprov> kyrofa: yes, there is a general problem with timestamps in the API, some are naive (no tz info) and some are RFC3339 (appended 'Z'), we will have to clean this up
<cprov> kyrofa: but for the time being, there is nothing blocking you parse them as UTC, right ?
<ikey> hoping this means anything to anyone because it baffles me
<ikey> Dec 23 16:52:00 ironhide audit[3513]: SECCOMP auid=1000 uid=1000 gid=1000 ses=2 pid=3513 comm="F12017" exe=2F72756E2F6D656469612F6269676469736B2F67616D65732F737465616D617070732F636F6D6D6F6E2F463120323031372F62696E2F463132303137 sig=31 arch=c000003e syscall=101 compat=0 ip=0x7f72201b4e72 code=0x0
<ikey> it seems to be the thing breaking feral games
<ikey> if im reading this right 101 is ioperm
<ikey> snap run --shell linux-steam-integration
<ikey> [1]    11726 invalid system call  snap run --shell linux-steam-integration
<ikey> k thats janky.
<ikey> i dont seem to be getting any apparmor denials or library errors yet under confinement feral games arent working
<ikey> and i cant figure out why they break
<mcphail> isn't 101 ptrace?
<mcphail> https://github.com/torvalds/linux/blob/9c294ec08408ed90c0f2d994a7979366675e3734/arch/x86/entry/syscalls/syscall_64.tbl#L110 - for 64-bit, anyway
<ikey> yeah
<ikey> also chown is causing --shell to die
<ikey> when it chowns .bash_history
<ikey> and the error message seems consistent..
<ikey> chown ufee1dead:ufee1dead lol
<ikey> Bad system call
<ikey> so i guess i just need to allow ptrace in the new interface..
<kyrofa> cprov, I'm just leaving them naive for now, but if you promise me that assuming naive datetimesnamps from the store are UTC, then that's also easy
<kyrofa> promise me that doing so is safe, I mean
<ikey> i cant seem to make this dmesg go away whatever i do..
<ikey> snappy-debug is apparently not portable either..
<kyrofa> ikey, what are you seeing?
<ikey> kyrofa, snappy-debug or my snap issue?
<ikey> cuz my snap issue is https://forum.snapcraft.io/t/unable-to-use-ptrace-in-confinement/3297
<kyrofa> ikey, both, haha
<ikey> and my snappy-debug issue is it absolutely requires /var/log/syslog
<ikey> solus doesn't use syslogd we just have journald
<kyrofa> ikey, yeah, seccomp denials are totally different from apparmor ones
<ikey> yeah this is alien territory to me
<ikey> only just got used to doing apparmor rules
<kyrofa> ikey, seccomp doesn't support logging if we use the ERRNO method, so we've chosen to use KILL for now while upstreaming the logging capability
<ikey> ah ok
<kyrofa> ikey, which means if you make a disallowed syscall, unlike apparmor which gives you a nice denial and sends you on your way, you're dead dead dead
<ikey> right
<ikey> and this is happening within the tree of a multiprocess app so it go boom
<kyrofa> ikey, yep
<ikey> ok looking at the bpf ptrace is definitely missing
<kyrofa> Yeah probably need to add something there
<ikey> i thought capability sys_ptrace would do that, guessing not
<ikey> and i dont see any of the bpf explicitly setting ptrace on
<kyrofa> Yeah, that I don't know
<ikey> wonder if this is a kernel issue now.
 * ikey tries a reboot
<ikey> aha
<ikey> i manually recompiled the bpf and added ptrace to it
<ikey> and that was enough to make it "work"
<kyrofa> Nice! Though I'm sure there are security ramifications there
<ikey> yeah we'll need to add some initial deny ptrace lines in apparmor profile and then some explicit allows
<ikey> that way we wont be able to ptrace unrelated peers
<ikey> boom: https://twitter.com/ufee1dead/status/944666111810965504
<cprov> kyrofa: yup, assume utc for now
<mcphail> ikey: love it
<ikey> the browser interface is causing me some trouble by breaking my ptrace
<ikey> as it has a deny all
<ikey> and is inserted after my own rules..
#snappy 2017-12-24
<mup> PR # closed: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4313, snapd#4315, snapd#4326, snapd#4329, snapd#4334, snapd#4336, snapd#4337, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357,
<mup> snapd#4358, snapd#4365, snapd#4369, snapd#4373, snapd#4380, snapd#4382, snapd#4387, snapd#4389, snapd#4392, snapd#4394, snapd#4399, snapd#4401, snapd#4403, snapd#4405, snapd#4416, snapd#4418, snapd#4419, snapd#4420, snapd#4421, snapd#4422, snapd#4423, snapd#4424, snapd#4425, snapd#4426
<mup> PR # opened: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4313, snapd#4315, snapd#4326, snapd#4329, snapd#4334, snapd#4336, snapd#4337, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357,
<mup> snapd#4358, snapd#4365, snapd#4369, snapd#4373, snapd#4380, snapd#4382, snapd#4387, snapd#4389, snapd#4392, snapd#4394, snapd#4399, snapd#4401, snapd#4403, snapd#4405, snapd#4416, snapd#4418, snapd#4419, snapd#4420, snapd#4421, snapd#4422, snapd#4423, snapd#4424, snapd#4425, snapd#4426
#snappy 2018-12-17
<koala_man> I have a github tag v0.6.0 on revision cb57b4a. Why does the snapcraft build say "v0.5.0+git104.cb57b4a" instead of just "v0.6.0"?
<popey> koala_man: good question. one for sergiusens :)
<popey> koala_man: might want to bring it up on the forum. I have wondered this myself
<popey> (also, thanks for making shellcheck. it's made my shell scripts a thousand times better)
<koala_man> aww, I'm glad you've found it useful ^^
<amurray> koala_man: how are you declaring the version in your snap?
<amurray> koala_man: and is this using build.snapcraft.io ?
<popey> amurray: https://github.com/koalaman/shellcheck/blob/master/snap/snapcraft.yaml#L25
<popey> version: git
<amurray> interesting... I use https://github.com/alexmurray/indicator-sensors/blob/master/snap/snapcraft.yaml#L3
<amurray> So that I get the latest tag plus a commit id if it has advanced beyond that
<popey> yeah, we have used that in some snapcrafters repos
<amurray> (I recall I stole this from some other snapcraft.yaml but I don't recall the original source...)
<popey> or adopt-info
<popey> :)
<amurray> So ideally version: git would do-the-right-thing ?
<sergiusens> amurray popey koala_man the version is like that as `version: script` works with annotated tags... From the git man pages "Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (likeÂ git describe) will ignore lightweight tags by default."
<sergiusens> You can use `snapcraft tal set-version` instead for more custom versions
<koala_man> sergiusens: but my tag is annotated
<sergiusens> Does it show with `git describe`?
<koala_man> on that revision it says v0.6.0
<sergiusens> Not sure then, and not at a computer until Thursday to help out. If you send a forum post and ping me if no one has looked by then I can help
<koala_man> how do I rebuild a certain revision via build.snapcraft.io?
<mborzecki> morning
<mborzecki> zyga: https://fedoraproject.org/wiki/Changes/FontconfigCacheDirChange so it's a 'recent' change and fedora specific
<mborzecki> zyga: and the core policy is incomplete, filed a bug https://bugzilla.redhat.com/show_bug.cgi?id=1659905
<sil2100> o/
<sil2100> zyga: do you know if mvo will be around today?
<pstolowski> mornings
<mborzecki> sil2100: he's supposed to be taking vacation, if it's urgent you can telegram him
<mborzecki> pstolowski: hey
<sil2100> Ah, I see he's on holidays
<sil2100> mborzecki: thanks
<zyga> sil2100: I donât believe so
<zyga> Hey guys
<zyga> Iâm thinking of skipping today
<mborzecki> zyga: if you could take a quick look at https://github.com/snapcore/snapd/pull/6286
<mup> PR #6286: release: support probing SELinux state <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6286>
<mborzecki> zyga: oh, and can you upload release tarballs to https://github.com/snapcore/snapd/releases ?
<sil2100> zyga: we'll need a new snapd in the stable channel today - is that something that's being worked on today?
<zyga> sil2100: I donât know. Perhaps Sergio knows.
<zyga> mborzecki: not now, I need to burn some holidays and Iâm on my way to school with my son
<mup> PR snapd#6314 opened: cmd/snap-discard-ns: fix umount(2) typo <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6314>
<mborzecki> zyga: well, i'm taking days of myself, starting wednesday
<mborzecki> Chipaca: morning sir
<zyga> Hey hey
<zyga> Iâm taking today off
<zyga> Grabbing some breakfast in the city now
<zyga> I went to buy some lights for the tree
<Chipaca> mborzecki: zyga: hiya
<Chipaca> zyga: set it on fire, it's the traditional way
<zyga> Almos did
<zyga> Almost
<zyga> Iâll explain in a
<zyga> sec
<zyga> All the Xmas lights we had at home were ancient incandescent lights
<zyga> With 220V AC flowing through hair thin wires
<zyga> So they went to the bin
<zyga> pstolowski: hey
<zyga> I think I merged some of your branches prematurely on Friday
<mborzecki> zyga: make note to dispose the tree in the right fashion too https://i.imgur.com/Awm2h5T.jpg
<pstolowski> hey zyga & Chipaca
<Chipaca> zyga: make the xmas tree metal, and make the lights with a nice glowy tesla coil
<zyga> I didnât remember pedronis wanted to read each one
<Chipaca> zyga: you can even get it to play music for you!
<zyga> Haha
<zyga> Chipaca: Iâll just hang our tree this way till spring ;-)
<Chipaca> zyga: https://www.youtube.com/watch?v=08elfo7YNGU fwiw
<zyga> Is it safe to watch in a public place?
<zyga> Holly smokes :-)
 * Chipaca goes to the gym for a bit
 * Chipaca tries to really go to the gym now
<mborzecki> hm something off about our images, some file transitiions don't seem to work, but they work locally in a vm
<pstolowski> pedronis: hey, i've just posted https://forum.snapcraft.io/t/confusing-behavior-of-snapctl-get/9028 ; can you have a look when you have some time?
<mup> PR snapd#6100 closed: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6100>
<Wimpress> Can someone confirm this bug please.
<Wimpress> I'm on 18.10, but also tested by popey on 18.04. Both using snapd 2.36.2 from core in stable.
<Wimpress> snap remove foosnap barsnap
<Wimpress> When trying to remove multiple snaps in one operation the removal never completed.
<Wimpress> Spins forever on resolving conflicting changes.
<mborzecki> pstolowski: ^^
<pstolowski> Wimpress: what snaps exactly?
<pstolowski> any?
<mborzecki> off to pick up the kids
<popey> pstolowski: it doesnt matter
<popey> I just tried to remove two snaps and it say forever.
<cachio> popey, with stable core snap?
<popey> with two random snaps I had installed, one was dangerous, one from the store
<popey> yes, stable core
<popey> s/say/sat/
<cachio> popey, https://paste.ubuntu.com/p/KRWgWtqt4W/
<cachio> it worked well for me
<cachio> could you please tell me the snaps you used?
<cachio> and if you refreshed the core after install the snaps and before remove them?
<popey> i didnt refresh anything
<popey> I don't believe it's snap specific, so me giving you two won't necessarily help
<popey> Common factor was one was a sideloaded snap
<popey> (between me and wimpy)
<Wimpress> I'll reproduce this and test with locally built installed snaps and snaps from the store.
<popey> repeated the command and it magically worked this time
<popey> 2018-12-17T13:21:42Z INFO Waiting for conflicting change in progress...
<popey> it says that once, but previously it said that repeatedly and just sat there
<popey> https://www.irccloud.com/pastebin/8t7NXR4U/
<popey> https://paste.ubuntu.com/p/6jR2fgD3gY/
<cachio> popey, trying to reproduce it here
<popey> wonder if it's the order of them, as that's the only difference
<cachio> popey, I cant find this grin snap, is the one you built manually?
<popey> yes
<popey> https://github.com/popey/grin/tree/add-snapcraft
<cachio> popey, ok, I'll build it
<pstolowski> popey, Wimpress i couldn't reproduce with 2 random snaps that I tried (one was a locally installed snap). did you by any chance run a ~pre release of core recently?
<mborzecki> pstolowski: you think it's something in the state?
<pstolowski> popey: when you said "forever", did you mean hours? or a few minutes after which you concluded it's stuck?
<popey> minutes
<pstolowski> allright!
<popey> martin had it longer as he went afk
<pstolowski> hmm
<pstolowski> popey: if minutes, then https://bugs.launchpad.net/snapd/+bug/1806447
<mup> Bug #1806447: Sophisticated snap remove retries a lot and becomes very slow <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1806447>
<Chipaca> off to get the boys
<pstolowski> (most likely)
<Chipaca> ttfn
<pedronis> zyga: yes, I want to read all/most the hotplug PRs unless they are really trivial
<pstolowski> pedronis: nb, i'll address the comment you made to that already landed hotplug PR
<popey> I don't understand how there is a conflict between two completely unrelated apps
<popey> they're not using content snaps or anything like that
<pstolowski> popey: but they may have interfaces with core
<popey> they will both have interfaces with core, yes
<pstolowski> ?
<popey> how is that a conflict?
<pstolowski> popey: we're regenerating profiles, and conflict arises if either plug- or slot- side snap is common
<popey> huh, okay. i don't get it but I believe you :)
<pstolowski> popey: the more interfaces the worse it gets, due to that bug. after a fix it will be faster
<popey> ok
<pstolowski> popey: but. i cannot exlude another problem is in play, such as coming for a buggy ~pre release from last weeks
<pstolowski> popey: which we fixed but some people were affected
<mborzecki> pedronis: heh https://github.com/systemd/systemd/issues/9997
<diddledan> zyga: the snapd layout bug that you wanted me to file is here https://bugs.launchpad.net/snapd/+bug/1808821
<mup> Bug #1808821: snap with layout cannot be updated multiple times <snapd:New> <https://launchpad.net/bugs/1808821>
 * cachio lunch
<zyga> diddledan: thank you
<zyga> pedronis: ack, I remembered after the fact when you send that mail
 * zyga returned to the office to do some paperwork
<mborzecki> another bug in RHBZ https://bugzilla.redhat.com/show_bug.cgi?id=1660141
<mup> PR snapd#6315 opened: overlord/ifacestate: include interface name in the hotplug-disconnect task summary <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6315>
<pstolowski> mborzecki: trivial, if you have a second ^ ?
<mborzecki> pstolowski: done
<pstolowski> thx
<sil2100> zyga, cachio: hey! Do you guys know what's the status of snapd for stable?
<zyga> no, I don't
<sil2100> zyga, cachio: mvo wanted to have the new snapd in stable for the core18 images
<zyga> ack, I remember
<zyga> just not sure what happened since
<sil2100> I'd like to kick new image builds soonish, I guess snapd is the only thing missing right now
<sil2100> cachio: ^
<zyga> sil2100: hey
<zyga> I noticed I have a mail from Sergio from the 15th
<zyga> but you are on CC
<sil2100> zyga: that was regarding core18, I mean snapd
<zyga> I have nothing further than that
<sil2100> Who's usually doing the promotion of snapd from beta to candidate and to stable? Is that automated?
<sil2100> Is there someone driving that usually?
<zyga> sil2100: that's cachio
<sil2100> Ah, ok, so I'll just wait for him to answer then
<sil2100> Thanks!
<sil2100> cachio: the cert team gave a +1 on snapd for candidate
<cachio> sil2100, lyes
<cachio> sil2100, lets go to candidate
<sil2100> cachio: when can we expect snapd to land in stable?
<sil2100> Is it still possible to happen today?
<cachio> sil2100, we already gave the +1 to go to stable
<cachio> so just need QA confirmation
<cachio> cwayne, do you know what's missing?
<cachio> I saw the +1 to go to candidate
<sil2100> \o/
<sil2100> That's good news, let's see what cwayne says then
<pedronis> sil2100: I can promote snapd to stable
<sil2100> cachio: ^
<cachio> pedronis, sil2100 it is in stable now
<cachio> I just coordinated with store team and I did it
<cachio> so, we are ready to create images
<sil2100> Excellent
<sil2100> I see it now
<sil2100> cachio: thanks!
<cachio> sil2100, great
<pedronis> cachio: thanks, I see it now
<cachio> pedronis, sil2100 yaw
<cachio> I am gonna run smoke test on stable now
<sil2100> cachio: thanks! I just kicked off the first build just now, let's see how it goes
<sil2100> I don't think we did any core image builds on disco yet so fingers crossed that it'll all just work
<cachio> sil2100, fingers crossed
<sil2100> cachio: succeeded!
<sil2100> I'll do a quick boot test and then share the link
<cachio> sil2100, awesome
<sil2100> cachio: looking good so far!
<sil2100> I need to go AFK and EODish now, but the images are in and test request sent
<sil2100> I'll be monitoring IRC still for a while in case something blows up
 * cachio afk
#snappy 2018-12-18
<rbasak> sergiusens: around? I'm having trouble with the python plugin, setting requirements.txt. Documentation says it's a string, but the code says it's a list. I can't seem to give it a list.
<rbasak> I tried using override-pull to dynamically create a requirements.txt concatenating my own list, but snapcraft seems to fail to read a generated requirements.txt _before_ override-pull runs, even though it complains after (based on what strace says).
<rbasak> The underlying problem I'm trying to solve is: https://pastebin.ubuntu.com/p/7yknPXQG7G/
<rbasak> Upstream aren't sure that it's correct to include an == for setuptools in requirements.txt.
<rbasak> But it might work for me here. Except I can't figure out how to get snapcraft to let me interfere with the requirements.txt before it uses it.
<mup> PR snapd#6316 opened: tests: skip snapd snap on reser for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6316>
<mborzecki> morning
<zyga> Hello
<zyga> I will be in the office shortly, just need to take the dog out
<mborzecki> zyga: hey
<zyga> re :)
<zyga> hey hey
<zyga> I feel *much* better than yesterday
<zyga> mborzecki: was the sky overcast last night around your place?
<mborzecki> zyga: idk, didn't pay much attention, probably yes
<zyga> I want to take a chance to see the comet
<zyga> but lights and clouds make it hard to do so :/
<mborzecki> zyga: hah, the worst time of year if you ask me
<zyga> right?
<zyga> mid summer would be awesome
<mborzecki> zyga: or super cold weather
<zyga> mborzecki: any highlights from yesterday?
<mborzecki> the test suite is givig headaches
<mborzecki> zyga: couldn't even get https://github.com/snapcore/snapd/pull/6314 to land
<mup> PR #6314: cmd/snap-discard-ns: fix umount(2) typo <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6314>
<zyga> yeah, I'm looking at taht now
<zyga> but that's hardly new problem :/
<mborzecki> and it's a damn typo
<zyga> + test-snapd-udev-input-subsystem.slot
<zyga> cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_tdsBnR//dev: No such file or directory
<pstolowski> heyas
<zyga> this means that core snap is empty
<zyga> which probably signifies another bug in test restore somewhere
<zyga> eh
<zyga> pstolowski: hey
<zyga> pstolowski: did you see the comet?
<mborzecki> zyga: on a side not, pulled in the latest updates today, linux-firmware got updated to 20181216 version and my vega stopped working :/
<zyga> uh?
<zyga> :|
<zyga> new vega firmware?
<pstolowski> zyga: oh, no; did you?
<zyga> maybe it requires new kernel too
<zyga> pstolowski: no, sky is totally covered with clouds
<zyga> pstolowski: but I want to
<mborzecki> zyga: i'm at 4.19.9
<zyga> pstolowski: I learned a thing yesterday
<mborzecki> zyga: tought the kernel update was botched, but reverting firmware was enough to make it work again
<zyga> pstolowski: downloaded mojave installer app, rebooted (required somehow), created a new vm with fusion and the mojave installer, clicked through everything, rebooted, held command+r to enter recovery, disabled system integrity protection (root is real root now), rebooted back to the system, now I can dtrace system binaries or use dtruss to see the system calls; I wanted to understand what fuels readdir on macos, and I found out
<zyga> :)
<zyga> (and it is not getdents)
<pstolowski> zyga: :D
<mborzecki> zyga: can you upload the source tarballs to github releases page?
<zyga> mborzecki: yeah, I'm looking into that now
<mborzecki> zyga: thanks!
<zyga> mborzecki: btw, some good stuff over weekend
<zyga> I, by accident, got the attention of the suse golang stack maintainer
<zyga> and they will remove the global environment variables
<zyga> which means we will not only get fixed go in suse
<zyga> but have a simple way out of the current problem
<zyga> (just unset the damn GO* mess)
<zyga> mborzecki: tweeting with a rant actually solved a problem :)
<mborzecki> zyga: nice
<zyga> FK
<zyga> firefox ate my release page
<zyga> f*****
<zyga> went "back"
<zyga> moronic feature
<mborzecki> nom nom nom
<zyga> mborzecki: release page updated
<zyga> I'll do opensuse next
<zyga> then look at bugfixes for layout bug
<zyga> I would love if we did 0 features and made the test suite stable
<zyga> any ideas apply
<mborzecki> zyga: thanks
<mborzecki> i'm seeing this on arch: gru 18 09:29:09 galeon snapd[24323]: link.go:75: cannot update fontconfig cache: cannot get fc-cache-v6 from core: open /var/lib/snapd/snap/core/current/bin/fc-cache-v6: no such file or directory
<mborzecki> uhh
<zyga> dunno
<mborzecki> zyga: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/backend/link.go#L62..L94 i think this is wrong
<zyga> I low how we ship TODO/XXX but discuss ad infinitum about variable names
<zyga> mborzecki: can you walk me through your thought process
<mborzecki> zyga: it's using CommandFromCore, which does mountDir+core/current, but the symlink is updated only at the end
<mborzecki> zyga: so it's trying to call fc-cache-v6 from the old 'current' of the core snap
<zyga> indeed!
<zyga> uh
<zyga> please file a bug
<mborzecki> zyga: only visible when switching between !edge & edge
<pedronis> zyga: I don't know of anything that isn't tiny that doesn't ship with TODOs
<mborzecki> zyga: better yet, i'll open a PR :P
<zyga> pedronis: that was not my point :)
<zyga> pstolowski: is this expected? 2.36.3  https://www.irccloud.com/pastebin/Yxx3gjEC/
<mup> PR snapd#6314 closed: cmd/snap-discard-ns: fix umount(2) typo <Simple ð> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6314>
<mup> PR snapd#6316 closed: tests: skip snapd snap on reset for core systems <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6316>
<mborzecki> zyga: just on .3?
<zyga> yep
<zyga> mborzecki: happens each time
<mborzecki> zyga: hm don't see this here
<zyga> "osc build"
<pstolowski> zyga: no, failures are not expected ;). i don't know, looks like mvo touched this test a few days ago. do you see it consistently?
<zyga> yes
<zyga> each time
<pstolowski> interesting
<pstolowski> zyga: let me look
<zyga> mborzecki: I sent this to obs
<zyga> it will fail there
<mborzecki> zyga: go version?
<zyga> https://build.opensuse.org/package/show/system:snappy/snapd
<zyga> 1.11.2
<zyga> mborzecki: note, it happens in osc build
<zyga> I don't see this in "go test ./..."
<mborzecki> zyga: wasn't there something with network being disabled in obs builds and that causing some werid issues?
<zyga> I don't know
<zyga> presumably maybe so
<mborzecki> zyga: i recall something like this when you were updating snapd with that other opensuse community guy
<zyga> hmmmm
<zyga> http://nonexistingserver909123.com/
<pstolowski> zyga: i'm looking at this test right now. running in httputil/ tests in a loop, so far no failure, so perhaps flaky?
<zyga> pstolowski: no
<zyga> perhaps flaky assumption
<zyga> it fails each time in obs build
<zyga> https://build.opensuse.org/package/show/system:snappy/snapd
<zyga> we are assuming a specific answer for a domain name
<zyga> the problem is that the test can run in arbitrary environment, including one with proxies
<zyga> not a unit test
<zyga> we test the system
<pstolowski> zyga: i see. also looking at comments in e3db0504f5b28029e4a253614782244150ebeb50, go versions introduce variances here...
<zyga> pstolowski: https://build.opensuse.org/package/show/system:snappy/snapd failed across all suse versions
<pstolowski> uhm
<pstolowski> zyga: i think we should c.Skip this test then for the time being, and try come up with a better one
<zyga> pstolowski: agreed
<zyga> pstolowski: perhaps we should spawn our own server and return the expected error code
<zyga> otherwise we can really see anything the system crafts
<pstolowski> +1
<pstolowski> zyga: shall i prep quick PR against 2.36?
<zyga> pstolowski: I can cherry pick as well, thank you for looking
<zyga> if you can, please try to improve the test
<pstolowski> zyga: ok
<zyga> sorry, that came out confusing and ambiguous
<pstolowski> zyga: ok, for master then
<zyga> I mean I will do the skip
<pstolowski> ah ok
<zyga> and you can look at changing the test properly for master
<zyga> I will carry a distro patch
<pstolowski> zyga: perhaps c.Skip conditional on suse?
<zyga> pstolowski: no, I mean I will just skip this unconditionally in distro packaging
<zyga> we should not special case any distribution here
<pedronis> pstolowski: zyga: we already have a test like that somewhere else
<pedronis> we don't skip generically
<pedronis> pstolowski: see TestDoRequestSerialErrorsOnNoHost  in devicestate_test.go
<pedronis> zyga: ^
<zyga> looking
<pstolowski> ah!
<pstolowski> pedronis: nice
<zyga> yep
<zyga> +1
<zyga> though I would really argue those are not unit tests
<zyga> but camouflaged integration tests
<pedronis> zyga:  we have some _test.go files with integration tests (of various kind), yes
<zyga> uh, heads up: I need  to go and do paperwork (today and tomorrow) for the car that has finally arrived
<zyga> perhaps I can skip today
<zyga> I'll learn more soon
<pedronis> zyga: heh, two full days of papework?  that sounds annoying
<zyga> no, just two instances
<zyga> insurance today
<zyga> and final pickup tomorrow
<zyga> I just need to be there to sign the papers
<zyga> though we're trying to do the insurance remotely to avoid going there for really silly reason
<pedronis> we are seeing this kind of error often:  cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_niWil9//dev: No such file or directory
<pedronis> zyga: ^ any idea?
<zyga> yes
<zyga> so this fails if either of the things happen
<pstolowski> yeah i just see it as well
<zyga> a /tmp/snap.rootfs_niWil9/dev (which we make ourselves just prior to that call) doesn't eixst
<zyga> or if /dev doesn't exist
<zyga> I did see this a few  times
<zyga> let me think
<zyga> unit test failure https://www.irccloud.com/pastebin/5TCsf2ae/
<pedronis> btw were we sure this was solid now:  https://github.com/snapcore/snapd/pull/6217
<mup> PR #6217: tests: reset snapd state on tests restore <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6217>
<pedronis> zyga: do we need more logging around that error? to know which it is?  /dev or the directory we just created (that sounds scary)
<zyga> pedronis: I think it was okay, the problem is that our test suite has interlocking issues that sometimes mask each other, fixing something has impact that uncovers another thing that is broken; it's not good because we have no way to measure anything
<zyga> pedronis: ish, logging anything is notoriously difficult in snap-confine because of fear of string ops; I spent about a month discussing how to do it with jdstrand with no result other than "only in debug builds, too scary in production builds"
<mup> PR snapd#6317 opened: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6317>
<mborzecki> zyga: pedronis: ^^
<pstolowski> pedronis: i'll work on that snapctl get bug if that's ok?
<pedronis> pstolowski: are you blocked on hot plug?
<pstolowski> pedronis: 2 hotplug PRs need reviews (i'm deconflicting one of them atm)
<pedronis> pstolowski: we need to write the main respond to events? handle enumeration? is that right?
<pedronis> is that work blocked?
<zyga> mborzecki: I'm wondering about something
<zyga> your patch looks good
<zyga> I wonder if we should release an update with this in distro patches
<pstolowski> pedronis: that's all implemented in the big hotplug branch already (i'm not deconflicting it until the smaller ones land though)
<pedronis> pstolowski: so the idea is to shrink that? and then ask for a review of it?
<pstolowski> pedronis: yes, i'd like the smaller ones to land, otherwise it's constant battle with de-conflicting
<pedronis> ok
<pstolowski> pedronis: otherwise what remains todo is the open questions (camera etc.), polishing around naming, better summaries (what we discuessed ~yesterday)
<pstolowski> naming = slot naming
<pedronis> ok, sounds good
<pedronis> I'll see if I get to review a bit more of those open ones
<pstolowski> pedronis: ah, and the gadget-declared slots discussed last week
<pedronis> yes
 * Chipaca shakes his fist at conflict detection, and goes for more coffee
<Chipaca> actually scratch that, i'll go for a walk instead
<Chipaca> bbiab
<Chipaca> pedronis: I suspect this bit won't pass review: https://pastebin.ubuntu.com/p/QDbNMmmWh2/
<pedronis> Chipaca: indeed, but there is probably something we can
<pedronis> do
<pedronis> Chipaca: we can have a quick chat once you are back if it can help
<Chipaca> pedronis: I think I need to generalise doInstall to take a current-change, and pass that in to the conflict checker
<Chipaca> pedronis: hopefully I can do it without breaking all the doInstall tests :-)
<pedronis> we don't have direct doInstall tests I think
<Chipaca> bonus :-)
<Chipaca> anyway, walk to clear head, bbiab
<mup> PR snapd#6318 opened: release-tools: display self-help <Created by zyga> <https://github.com/snapcore/snapd/pull/6318>
 * pstolowski gets xmax haircut, bbl
<pstolowski> *xmas even
<mborzecki> cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_Nb69ea//dev: No such file or directory
<mborzecki> this thing pops up quite often
<pedronis> mborzecki: yes
<mborzecki> zyga: any clue what that might be?
<pedronis> mborzecki: are we removing /dev somehow?
<mborzecki> pedronis: not that i know of
<pedronis> or is some cgroup handling problem?
<mborzecki> idk, this comes from s-c, looking at things, we have a scratch dir (otherwise it'd die earlier), the we mount the rootfs (core in this case), and proceed to setup individual mounts, /dev is the first one
<mborzecki> \/dev is in core, there's probably one on the host too
<pedronis> mborzecki: zyga: I fear but it seems it started with landing of #6217
<mup> PR #6217: tests: reset snapd state on tests restore <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6217>
<zyga> pedronis: hmmmm, let me think
<zyga> I donât mind reverting that now
<zyga> I have enough state to work locally
<pedronis> given where we have are timewise, I would revert it
<pedronis> s/have//
<pedronis> mborzecki: can you prepare a revert?
<mborzecki> pedronis: ok, let's do this
<pedronis> mborzecki: if the revert itself fails that way we learn something either way
<mup> PR snapd#6319 opened: Revert "Merge pull request #6217 from sergiocazzolato/tests-reorg-prepare-restore" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6319>
<pedronis> let's see how it goes
<pedronis> mborzecki: thx
<popey> Has *anyone* actually got audio (alsa or pulse) working on core?
<popey> I have tried everything i can, and never get any audio over either
<popey> Followed every tip / trick I can, and am losing the will to live
<Chipaca> popey: have some chocolate, go for a walk, play some music or draw something! don't lose your will to live
<popey> :)
<popey> Figure of speech :)
<Chipaca> popey: couldn't risk it
<ogra> popey, what hardware ?
<popey> ogra: a pc
<ogra> it should definitely work through pulse if you installed the pulse snap and connected all inerfaces properly
<popey> the best I can get is apparmor failure on /run/pulse/native which leads to https://forum.snapcraft.io/t/pulseaudio-in-daemon-mode/6606
<popey> it does not
<popey> I would appreciate someone else confirming this. I spent hours on this last night and it should not be this hard.
<ogra> it is quite a while ago that i tested pulse (about  year) and there it used to work ... something might have changed
<Chipaca> what was the name of the mixer that mate ships by default as a snap?
<popey> pulsemixer
<ogra> you might need to switch to the right output device though ... i dont think core picks a proper default
 * Chipaca installs that
<popey> which also doesnt work on core
<Chipaca> popey: I can confirm the DENIEDs
<Chipaca> popey: 'snap logs pulseaudio' talks about cookies
<Chipaca> popey: hmm!
<Chipaca> popey: I can open the mixer just fine with sudo though
<ogra> popey, the pulse snap ships pactl ... (way more low level than pulsemixer and way more cryptic to use but has the same powers)
<Chipaca> ogra: when you say 'the pulse snap', is it called "pulseaudio"?
 * Chipaca assumes so
<ogra> yes
<ogra> https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/pulseaudio/tree/snapcraft.yaml
<Chipaca> k
<Chipaca> popey: so
<Chipaca> popey: I installed pulseaudio
<Chipaca> popey: and mpv
<Chipaca> popey: and copied a music file to /root/snap/mpv/current/
<Chipaca> popey: and mpv plays it
<Chipaca> I get nothing out the speakers but that might be me sucking at kvm
<popey> using sudo?
<Chipaca> popey: yes
<Chipaca> popey: my user isn't part of the audio group
<ogra> that shouldnt matter ... you talk to the daemon, not to the device
<Chipaca> popey: note that the home interface doesn't auto-connect on core
<ogra> you should use paplay for testing
<Chipaca> ogra: can that play oggs?
<ogra> (comes with the pulseaudio snap(
<ogra> i think it should
<Chipaca> it doesn't error out, but as i said i don't have sound in the kvm for whatever reason (might be a core issue -- but might be me sucking at kvm)
<Chipaca> (I had to copy the audio file to /root/snap/pulseaudio/current )
<ogra> either that or pulse uses the wrong audio device
<Chipaca> yeah that could be happening
<Chipaca> popey: has this helped, or are you in the same place still?
<ogra> core has nothing to select a device as default
<ogra> so you might need some pactl tinkering frst
<popey> I cannot get mpv working as user or root either
<ogra> Chipaca, kvm should just need "-soundhw ac97" btw
<popey> so no, no further forward
<Xceed> I've also observed the following... https://forum.snapcraft.io/t/snapcraft-python-plugin-install-wrong-pip-version-during-snap-build/5445 ... however, the thread/issue was never answered/fixed, and I can't seem to find a how-to update pip for building.
<ogra> popey, use paplay
<popey> paplay farts that it needs root
<popey> "This script must be run as root"
<niemeyer> Heya
<Chipaca> popey: how does mpv fail?
<Chipaca> popey: what are you trying  :-)
<niemeyer> Are there any failing tests I could look at that would be fixed by spread#70, or is that random?
<mup> PR spread#70: Reboot on backgraound to avoid spread wait for long time <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
<popey> Chipaca: error opening/initializing the selected video_out (--vo) device.
<popey> is what I get from mpv playing an mp3 in root home folder
<ogra> popey, -vo null
<ogra> or --vo
<Chipaca> popey: do you have x or something? mine didn't even try
<Chipaca> popey: if you do, you might need to connect the x11 interface
<ogra> and equivalently ... --ao pulse
<popey> Chipaca: x11 on core?
<ogra> heh
<Chipaca> popey: it exist
<Chipaca> s
<popey> ok, as sudo, mpv can play audio now. yay
<ogra> yeah
<ogra> if you install some snap that provides it
<Chipaca> popey: i mean: there's an x11 snap somewhere
<popey> Sorry, rewind.
<Chipaca> we added support for running the x server as a snap, on core
<Chipaca> anyway, woo
<popey> User, wants to install a snap that plays audio.
<popey> Currently we have to copy files to a root owned folder, and run as root?
<Chipaca> 1 sec
<ogra> popey, well, core is more focused on headless and userless i guess so nobody thought about that before
<Chipaca> popey: i killed my kvm, need to do the dance again to test something
<ogra> (all clients you'd normally use would run as daemons as well in that case)
<ogra> popey, btw, you could take a look at my video-kiosk snap ...
<ogra> it spawns mplayer as a daemon that uses pulse from the pulseaudio snap and offers a web-ui to play files
<zyga> I added a check for unmounted base snap
<zyga> let's see if I can hit this
<popey> Interesting, thanks ogra.
<popey> I hadn't even considered doing everything as root.
<popey> This gets me further forward, thanks Chipaca / ogra :)
<ogra> https://github.com/krpors/wasp
<ogra> (and https://github.com/ogra1/video-kiosk-snap)
<popey> It does moan that "failed to create secure directory (/run/user/0/snap.(snapname)/pulse: No such file or directory
<popey> but that seems to not be a massive problem, as audio does play
<ogra> well, that sounds like a bug ... with confinement or confinement integration
<popey> sudo pulsemixer also works, as a bonus for fiddling the volumes
<popey> and shows the client connected too.
 * popey is happy
<ogra> :)
<mborzecki> so i'm playing with my gl debugging snap on a system with a vega cards, and there's no gl support at all
<mborzecki> a revision which uses core18 as base is somewhat better
<zyga> mborzecki: we need to implement better driver support
<zyga> mborzecki: it would help if core{16,} got updated driver stack but that's probably unlikely
<mborzecki> zyga: we have a task for opengl and nvidia, but mesa is in bad shape too
<zyga> yes
<zyga> but doing it for nvidia will open up the path for generic support
<zyga> I fully agree though
<pedronis> mborzecki: zyga: that revert is green
<zyga> let's merge it
<mborzecki> or maybe another travis run?
<zyga> I wonder if there's some interplay with another branch
<mup> PR snapd#6319 closed: Revert "Merge pull request #6217 from sergiocazzolato/tests-reorg-prepare-restore" <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6319>
<zyga> depending on pressure, we can run this several times more if you prefer
<pedronis> it cannot make things worse
<Chipaca> pedronis: https://pastebin.ubuntu.com/p/mKhGh4rGcr/ with conflict resolution back on \o/
 * Chipaca ~> lunch
<zyga> Chipaca: "Done    today at 12:23 GMT  today at 12:23 GMT  Run configure hook of "test-snapd-epoch" snap if present" - didn't we have a patch that makes hooks run if they are really present?]
<zyga> if we did, should that just say "running configure hook..."
<Chipaca> https://pastebin.ubuntu.com/p/H6vJfTZRQN/
<Chipaca> ^ two refreshes  with epoch changes in parallel
<Chipaca> zyga: Â¯\_(ã)_/Â¯ no idea
<Chipaca> pstolowski: ^?
 * Chipaca ~> really lunch
<pedronis> Chipaca: :)
<pedronis> zyga: don't think that patch was for all hooks
<pedronis> afaict it was only for interface hooks
<pstolowski> zyga, Chipaca: we did, but for interface hooks only
<zyga> mmm
<zyga> thanks
<pstolowski> since these had the most impact (4 extra task for every connect)
<zyga> hmm
<zyga> the failure with /dev is a bit hard to reproduce
<pstolowski> we can maybe apply this optimization everywhere
<pedronis> zyga: I expect you need some combination of tests and bad restore
<pedronis> if the casue was really that PR
<zyga> didn't this happen on the PR that was fixing a typo as well?
<zyga> I can switch to any ref it someone has an idea
<pedronis> zyga: yes
<pedronis> afaik it happened in some form in all of the master runs
<pedronis> since that PR was merged
<zyga> I'll run one more go
<zyga> and write a spread test for the extra check
<zyga> we can propose it regardless of current occurrence
<pedronis> pstolowski: what's the status of this: https://trello.com/c/KCMZcd5F/74-fix-for-kr-pretty-diff-memleak-affecting-our-tests
<sergiusens> rbasak I am off until Thursday. An email will certainly remind me to get back to you.
<pedronis> zyga: master failed but on a pull and the mount bug, not anymore on the /dev issue
<zyga> so back to where we were, thank you
<pedronis> the mount bug we have ideas
<pedronis> pull of repos, life is hard
<pstolowski> pedronis: radio silence from upstream; he has a bunch of PRs pending reviews..
<mborzecki> off to pick up the kids
<zyga> I guess during my "holidays" I could and should fix the debian package
<zyga> unless there are any takers I will do it
<zyga> but first
<zyga> lunch
<Facu> Hi all! Is there a simple way to make the installed snap "writable"? I just want to debug a Python tool installed through snap... add a couple of "print"s inside the code and run it
<ogra> Facu, you can "cp /snap/foobar/current/bin/my-script ." and then "sudo mount -bind my-script /snap/foobar/current/bin/my-script" ... that gives you an overalyed writable version of the script
<ogra> *overlayed
<Facu> ogra, can I do that with a whole dir? /snap/foobar/current/lib/python3.5/site-packages/foobar/
<Chipaca> Facu: unsqashfs /var/lib/snapd/snaps/the-snap.snap
<Facu> (the script doesn't really do much, all what really happens is inside own libs)
<Chipaca> Facu: snap try squashfs-root
<ogra> you have to copy the whole dir content and it gets really confusing to handle multiple files that way i guess ...
<Chipaca> Facu: squashfs-root is the directory unsquashfs creates (unless you tell it otherwise), it will have the (now rw) contents of the snap
<ogra> but technically you can indeed also overlay a dir that way ... though Chipaca has the better option here
<Chipaca> ogra: if this is your own snap, you can just 'snap try' the prime directory, if you're using an old-style snapcraft.yaml
<Chipaca> the new-style build-in-a-vm snapcraft doesn't leave a 'prime' :-/
<ogra> well, if you have the source :)
<Facu> Chipaca, it complains that  - Montar snap "snapcraft" (unset) (snap "snapcraft" requires classic confinement)
<Facu> Chipaca, I'll try ogra's solution with just the couple of files that I think I need to debug
<pedronis> Facu: you can do snap try --classic
<Facu> pedronis, worked great, thanks!
<pedronis> np
<Chipaca> Facu: snap try --dwim
<Facu> Chipaca, "dwim"? I don't see it in `snap help try`
<Chipaca> Facu: https://en.wikipedia.org/wiki/DWIM
<Facu> ja
<zyga> eh
<zyga> multipass doesn't work on opensuse
<zyga> no group "sudo"
<zyga> ergo
<zyga> no snapcraft
<zyga> ergo
<zyga> sucks :/
<jdstrand> zyga (pedronis): re logging> that's probably overstating things a bit. it is quite true that we want to be careful sending arbitrary strings, but that doesn't mean we can't send anything
<mborzecki> zyga: yes, that should be fixed in edge i think
<zyga> ah, perfect
<mup> PR snapd#6320 opened: tests: install core and save it as part of snapd state <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6320>
<rbasak> sergiusens: thanks. I'm off from tomorrow until the new year. I'll follow up with you in the new year then. Enjoy your time off!
<pedronis> cachio: we had to revert #6217, we really need  to go about this much much more carefully, I am also not sure how much of a priority it is
<mup> PR #6217: tests: reset snapd state on tests restore <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6217>
<cachio> pedronis, it is ok, it is not  high prioriry
<pedronis> zyga: are you joining or skipping?
<zyga> diddledan: hello
<zyga> oh
<zyga> joining!
<zyga> 2fa
<zyga> ready
<zyga> diddledan: so I spent some time on the layout issue
<zyga> and I cannot reproduce it
<zyga> can you still get to that point where it breaks?
<diddledan> weird
<diddledan> yes
<zyga> can you collect /var/lib/snapd/mount/*.fstab file (for layout-test)
<zyga> as well as /run/snapd/ns/*.fstab
<zyga> and lastly
<diddledan> you need to be running on a system that isn't i386 (x86_64, for example) and you need to run the app every install to ensure the mount namespace is set-up
<zyga> I did that
<zyga> lastly nsenter -m/run/snapd/ns/layout-test.mnt
<zyga> and then cat /proc/self/mountinfo
<zyga> (and exit to quit the shell)
<diddledan> which step do you want these from? when it's got to the broken stage, or before?
<zyga> when it is in a broken state
<diddledan> kk
<zyga> thank you
<zyga> I tested with 2.36.3
<zyga> though this should be the same as .2
<zyga> no changes in that area
<diddledan> or maybe I can't?
<diddledan> weirder and weirder
<diddledan> ok, I can't reproduce it any more with my test snap
<zyga> did you perhaps snap-try before
<diddledan> fooey
<zyga> on similar snap name
<diddledan> nope
<zyga> hmmm
<zyga> do you have snap changes
<zyga> that go all the way back when this failed?
<zyga> did core18 refresh in the meantime?
<diddledan> you can see all my testing in this paste (next message)
<diddledan> https://www.irccloud.com/pastebin/7NgxTerq/
<Facu> Chipaca, I finished "trying" my unsquashed snap ... how do I tell snap to resume normal refresh behaviour? (that is, when a new snap is available, to use that one instead the one I was trying)
<diddledan> the ones from yesterday are my attempts that were showing the failure after each third time, and the ones from today aren't failing
<zyga> Chipaca: one small bug related to snap state: https://bugs.launchpad.net/snapd/+bug/1807512
<mup> Bug #1807512: Classic snaps used in --jailmode still use real home directory <snapd:Triaged> <https://launchpad.net/bugs/1807512>
<diddledan> looks like core18 did change overnight https://www.irccloud.com/pastebin/8q3GPA3v/snap-tasks-189
<zyga> ha
<zyga> I bet this is a factor
<zyga> but I cannot explain how this fixed it for you
<diddledan> probably need to mark the bug as resolved for now, and revisit it if it resurfaces?
<zyga> can you revert core and reproduce it?
<zyga> just as a last resort?
 * diddledan tries
<zyga> thank y ou
<zyga> I still think there was more to it
<zyga> not that specific revision of core
<zyga> but perhaps?
<diddledan> yeah, I can't reproduce it after reverting core18
<Chipaca> Facu: snap refresh --amend thesnap
<zyga> diddledan: thank you for checking
<Facu> Chipaca, wonderful, thanks!
<mborzecki> zyga: about no space left on device, take a look at this: https://github.com/snapcore/snapd/blob/master/tests/main/install-store-laaaarge/task.yaml#L3..L17 specifically `umount /tmp || true`
<zyga> or true ;)
<mborzecki> yeah
<zyga> I also worry that we may leak a mount namespace
<zyga> or something equally non obvious
<zyga> that can keep any number of bytes in flight
<zyga> we need to measure leaks
<zyga> we leak a lot of stuff
<mborzecki> zyga: hm simple df -h in debug could be useful
<zyga> mborzecki: yes
<mborzecki> zyga: ok, let me do a quick pr
<zyga> mborzecki: but we should have something that says "this test was not cleaned up correctly: this is what leaked" too
<zyga> mborzecki: but that is harder
<mborzecki> zyga: iff we see a 4k /tmp we'll know :P
<zyga> 4k is too small
<mup> PR snapd#6321 opened: spread: show free space in debug output <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6321>
<mborzecki> zyga: ^^
<Son_Goku> mborzecki, I'm building 2.36.3 now
<zyga> Son_Goku: thank you :)
<Son_Goku> ugh, everything is a bloody mess right now
<mborzecki> Son_Goku: yay!
<Son_Goku> I'm going to deal with the mess of updating F28 and F29 later
<Son_Goku> but at least rawhide and epel7 will be done right now
<pstolowski> cachio: that issue with nightly test you pasted during the standup, was it against 2.36.2?
<cachio> it uses master
<cachio> pstolowski, ~
<cachio> pstolowski, it is part of the snapd main suite
<pstolowski> cachio: i see, thanks
<cachio> pstolowski, it is called install-snaps
<Son_Goku> mborzecki, 2.36.3 built and attached to update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b240f3418f
<Son_Goku> you'll have to grab the rpms from here to test for now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1174149
<pstolowski> cachio: ack
<pstolowski> i'm trying to reproduce manually (with 2.36.2 atm), of course after removing gnome and gtk-common-themes snaps, so far no luck
<cachio> pstolowski, you can try running this test with -debug
<cachio> not sure if it is 100% reproduceable
<zyga> I'm in a debug session, test failed on random network fluke
<zyga> but maybe not really random
<zyga> core snap is not installed
<zyga> and all stuff I try times out
<zyga> what was the magic sequence to dump iptables?
<zyga> https://www.irccloud.com/pastebin/x6lNrfPW/
<zyga> aha
<zyga> we leaked iptables across tests
<zyga> google:ubuntu-16.04-64:tests/main/interfaces-many google:ubuntu-16.04-64:tests/main/remove-errors google:ubuntu-16.04-64:tests/main/install-errors:withreexec google:ubuntu-16.04-64:tests/main/try-snap-goes-away:test_snapd_service google:ubuntu-16.04-64:tests/main/interfaces-gpg-keys google:ubuntu-16.04-64:tests/main/snap-service-after-before google:ubuntu-16.04-64:tests/main/snap-run-alias:testsnapdtoolscat
<zyga> google:ubuntu-16.04-64:tests/main/classic-ubuntu-core-transition-auth google:ubuntu-16.04-64:tests/main/proxy-no-core google:ubuntu-16.04-64 .../tests/runtime-state#
<zyga> one of those tests leaked it
<zyga> or is that expected somehow?
<zyga> pstolowski: is this related to your work recently>?
<pstolowski> zyga: no, the test i added recently added the following rule "iptables -I OUTPUT -p udp --dport 53 -j REJECT --reject-with icmp-port-unreachable"
<pstolowski> zyga: (snap-network-errors test)
<zyga> mmmm
<pstolowski> zyga: iptables-save > ... dumps the rules
<mborzecki> zyga: proxy-no-core does this
<zyga> yeah
<zyga> I just git grepped
<pstolowski> zyga: econnreset is the other test where we have iptables
<pstolowski> nah, it has different rules as well
<zyga> restore is broken?
<zyga> + iptables -D OUTPUT -m owner --uid-owner 12345 -j ACCEPT -p tcp
<zyga> iptables: Bad rule (does a matching rule exist in that chain?).
<zyga> main/snap-network-errors/task.yaml also didn't restore correctly
<pstolowski> zyga: hmm looks identical to the one that inserts the rule, except for the order of args
<zyga> I don't think it's just the restore logic
<zyga> it's not a test that always fails
<zyga> it's something that triggers the castle to fall apart
<mborzecki> Son_Goku: i've installed the packages, will try with some random snaps now
<pstolowski> zyga: where do you see a leftovers from snap-network-errors?
<zyga> pstolowski: just iptables -L
<zyga> https://www.irccloud.com/pastebin/8TX9Hu77/
<zyga> all tests fail so -debug shell is very chatty about it
<pstolowski> zyga: i don't see the dns rule from s-n-errors test there?
<zyga> REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
<zyga> isn't that it?
<pstolowski> no
<pstolowski> zyga: s-n-errors has  iptables -I OUTPUT -p udp --dport 53 -j REJECT --reject-with icmp-port-unreachable (narrowed down to udp, port 53), and in OUTPUT chain, not FORWARD
<zyga> so something went south
<zyga> anywy
<zyga> that's not what I was looking at
<zyga> restarted to see
<zyga> to see if I can reproduce the issue I'm after
<mborzecki> Son_Goku: seems to work fine, +1 karma :)
<Son_Goku> excellent
<pedronis> cachio: having lunch? are you going to work on core promotion after?
<pedronis> mborzecki: I review #6317
<mup> PR #6317: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6317>
<cachio> pedronis, preparing lunch
<cachio> pedronis, core has been promoted to stable
<cachio> pedronis, but store team was dealing with some infra issues
<pedronis> cachio: yes, sorry, I somehow missed in the logs
<cachio> pedronis, np
<Wimpress> Afternoon snapd team :-)
 * cachio lunch
<Wimpress> I remember a pending PR that would make it possible to expose access to defined dot file/directories via an interface.
<Wimpress> What is the status of that?
<pstolowski> Wimpress: hey, this https://github.com/snapcore/snapd/pull/5845 ?
<mup> PR #5845: interface: add new `{personal,system}-files`  interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
<pedronis> Wimpress: it will be in 2.37,  it will need store declaration approval for use tough
<Wimpress> Yep, that is the PR pstolowski ð
<Wimpress> pedronis: OK, no problem.
<Wimpress> I've got some ISVs who are keen to take advantage of this.
<pstolowski> Wimpress: did you manage to find a reproducer for the issue with snap remove taking forever?
<Wimpress> @sergiusens When will Snapcraft grow support for this capability?
<Wimpress> pstolowski: I think so. Let me just comfirm the steps.
<Wimpress> Typically, I can't reproduce the issue now.
<Wimpress> pedronis: What is the ETA for snapd 2.37?
<pedronis> Wimpress: after the break for sure, bit hard to give a precise date right now, core18 work and bug fixes for 2.36.x have delayed it somewhat
<niemeyer> cachio: The proposed reboot command looks a bit suspect
<niemeyer> cachio: The exit on background doesn't do much.. it should be equivalent to doing nothing
<niemeyer> cachio: Then, the reboot isn't being nohup'd, which means if the terminal actually exits it might be killed
<niemeyer> cachio: So I wonder what the actual fix really is
<niemeyer> cachio: The two relevant differences is the use of -f, and the redirect of stdout.. I wonder which of these fixed your problem
<zyga> Re, had to help the kids in the kitchen
<niemeyer> cachio: Ah, it also puts it in background, although it's not clear what effect that has given that we keep the shell alive
<niemeyer> cachio: The force is also unclear.. systemctl's manual says "When used with halt, poweroff, reboot or kexec, execute the selected operation without shutting down all units."
<niemeyer> cachio: Unclear we want that during testing
<niemeyer> cachio: Would you mind to break down this change and do only a single modification at a time, and see which one actually fixed the problem?
<cachio> niemeyer, sure
<cachio> I'll split it
<popey> ogra: got audio working in core on x86 laptop, but pi shows "Dummy Output" like there's no audio card?
<popey> https://usercontent.irccloud-cdn.com/file/LuF1hBWY/Screenshot%20from%202018-12-18%2017-33-53.png
<zyga> images on irc
<zyga> must be 1995
<popey> get off my lawn
<zyga> popey, ogra: not that I should try, I would be interested in alsa status on raspbian
<popey> I am not touching alsa with a 10 foot pole, thanks :)
<pedronis> zyga: "Precious Logs" means do not re-run?
<zyga> yeah
<zyga> I just did that because I wanted the seed written down
<zyga> I'll remove the label now
<zyga> fingers crossed, I really want to understand that test failure
<popey> on raspbian pulsemixer / pulseaudio snaps work
<ogra> popey, you need to set the right output device with pactl
<popey> https://usercontent.irccloud-cdn.com/file/HnIcoVqh/Screenshot%20from%202018-12-18%2017-41-18.png
<popey> ahhh
<ogra> the default is HDMIM out on the pi iirc
<ogra> *HDMI
<popey> pactl list cards lists none
<popey> on raspbian, it lists one
<ogra> hmm, what gadget is that ?
<popey> pi2            16.04-0.17         29    stable    canonicalâ      gadget
<popey> on raspbian sys/devices/platform/soc/soc\:audio/bcm2835_alsa/sound/card0/ exists
<popey> it doesn't exist on core
<ogra> ogra@localhost:~$ cat /proc/asound/cards
<ogra>  0 [ALSA           ]: bcm2835 - bcm2835 ALSA
<ogra>                       bcm2835 ALSA
<popey> proc asound doesn't exist
<ogra> popey, does your gadget have:
<ogra> ogra@localhost:~$ grep audio= /boot/uboot/config.txt
<ogra> dtparam=audio=on
<popey> no
<ogra> aha...
<ogra> the curse f gadgets not updating payload data
<ogra> *of
<zyga> it is scheduled to be fixed this 6-month cycle
<ogra> i assume this is an older installation ?
<popey> i have a pile 'o' pies, no idea which one this is
<popey> it could be, how can I tell when it was installed?
<zyga> you should be able to look at the seed
<zyga> the seed is what was made by ubuntu-image
<zyga> including the revisions
<ogra> (the latest pi gadget has all this fixed ... but config.txt doesnt get upgraded after first install)
<popey> snap changes only goes up to 40
<zyga> ls /var/lib/snapd/seed
<popey> so not that old
<ogra> popey, well, make sure the above line is in confog.txt and reboot
<ogra> *config
<popey> that'll fix it?
<ogra> yes
<ogra> that enables the audio device
<zyga> popey: broken=no
<zyga> ;)
<popey> dtparam=audio=on  in config.txt, right?
<ogra> yeah
<popey> ok, now i see proc/asound
<popey> but pulseaudio didn't start
<popey> ah, i was just impatient :D
<popey> Pi's take a while to boot :)
<popey> \o/ pulsemixer shows the device now \o/
 * ogra just got his first "your month in snaps" 
<ogra> so awesome !
<ogra> though it is worrying how many users my experimental snaps that are not ready for public yet do have ...
<ogra> seems people dont care if something is in edge only :)
<popey> \o/ spotify playing on my core \o/
<ogra> \o/
<ogra> on the pi ?!?
<Wimpress> Thanks for the assist ogra :-)
<ogra> np :)
<popey> https://usercontent.irccloud-cdn.com/file/Oh3iN6Ux/Screenshot%20from%202018-12-18%2017-59-08.png
<popey> Yes, controlled from my desktop, pi connected to speaker
<ogra> awesome !
<popey> yes :D
<popey> blog post coming :D
<ogra> popey, make sure to recommend the most recent image for it, that will have the fixed config.txt
<popey> yeah, will do :D
<mup> PR snapd#6311 closed: image: do not write empty etc/cloud <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6311>
<zyga> chipaca: does this make any sense to you? https://www.irccloud.com/pastebin/ZfOqgk4D/
<zyga> Chipaca: (in case case sensitive notification)
<zyga> also perhaps unexpected file name :)
<zyga> https://www.irccloud.com/pastebin/z2xkvTgz/
<zyga> The file "-" has text "core (bogus/stable) 16-2.36.3+git1063.bbf4a49 from Canonicalâ refreshed"
<zyga> in any case that test is borken
<smoser> o/
<smoser> hey.
<smoser> i'mi trying to update the license at
<smoser>  https://snapcraft.io/image-status/listing
<smoser> i click 'simple'.  hit 'x' on the "Proprietary" tag that is currently there.
<smoser> then type 'GPL' and click the provided "GNU General Public License v2.0 or later"
<smoser> hit 'Save'
<smoser> it says
<smoser> Invalid symbols sequence such as (A B) for token: "-" at position: 7
<smoser> any ideas?
<smoser> also nit pick... there are two entries for 'GNU General Public License v2.0 or later'
<cachio> niemeyer, update done
<niemeyer> cachio: What was the outcome of the test?
<cachio> this test is updating the debian image and running snapd tests on the new one
<cachio> in case the tests pass then that image is promoted to be used on google tests
<cachio> niemeyer, it is also failing on fedora and amazon images
<cachio> I reduced the reboot expression as mucha as possible
<niemeyer> Sorry, I meant to ask what was the actual reason the change done fixed the tests?
<niemeyer> Considering that there were several bundled changes
<cachio> niemeyer, the command reboot was not returning
<cachio> is not returning
<cachio> so ssh command is getting stuck
<cachio> with the & we make sure the ssh finished the execution
<cachio> niemeyer, just to clarify, by doing "reboot" the reboot is done but the ssh command does not finish
<cachio> this is the log https://paste.ubuntu.com/p/x3cyDFZ2nb/
<cachio> niemeyer,  I also added the & to make it work on devices
<cachio> because just with -f is was failing on rpi
<pedronis> zyga: I'm also very confused why that test started failing
<zyga> it failed once
<zyga> I'm running on a loop with the seed from the failure earlier
<pedronis> I see various PR failing with it
<zyga> oh?
<zyga> that's unexpected
<zyga> I mean
<zyga> I think the failure is genuine
<zyga> the redirect is bogus
<zyga> or some fancy shell syntax I'm unfamiliar with
<zyga> and I see a file with "-" in the name
<zyga> so it must be something bad
<zyga> but not sure why it fails
<pedronis> I don't see any recent change that would correlate with that failing
<zyga> I see the same thing, I cannot explain it
<zyga> I would start undoing the layers of the onion
<zyga> let's fix the syntax woes
<pedronis> zyga: I think I know why it's failing
<zyga> oh, do tell please
<Son_Goku> zyga: snapd updates for f28 and f29
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2018-b66c5e0d53
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2018-0aaf48e196
<zyga> Son_Goku: thank you, I will test it tomorrow
<zyga> Son_Goku: any surprises?
<Son_Goku> nah, this just brings us in sync with the epel7 update
<zyga> that's good
<zyga> uneventful stuff is best
<Son_Goku> I had to wait for go-systemd update to be available in f28 buildroot override
<Son_Goku> 2.37 will hopefully be the exciting update
<Son_Goku> I'll be closing somewhere around 50 SELinux policy bugs with that one
<niemeyer> cachio: Does it work with & alone and no other change?
<Son_Goku> not necessarily because they're fixed, but because the policy is rewritten too much to apply anymore
<cachio> niemeyer, it doesn't
<cachio> it failed with debian
<cachio> just with -f it fails in the boards
<cachio> I don't know why the ssh command is getting stuck
<niemeyer> Why?
<cachio> same issue
<niemeyer> Have you read the docs for -f?
<cachio> ssh command does not finish
<niemeyer> Debian systems shouldn't require it for not failing
<niemeyer> cachio: We need to know what the actual issue is
<cachio> ok, I'll continue researching
<cachio> any idea what to look in the debian system?
<cachio> I already checked logs and there is nothing
<cachio> the reboot is done
<niemeyer> cachio: If the reboot is done, it can't possibly be about the -f flag.. this is just a way to force it and ignore what services think about the process
<niemeyer> cachio: It's most likely a matter of timing
<cachio> niemeyer, I mean the reboot is done with -f and without
<cachio> it is allways done
<niemeyer> That's what I mean too
<cachio> ahh
<cachio> sorry
<niemeyer> The -f flag is irrelevant
<niemeyer> Sounds like just shooting stuff on the wall to see what sticks
<cachio> niemeyer, you mean that -f make it reboots slower
<niemeyer> cachio: step zero is understanding *why* it's not working..
<niemeyer> cachio: No, I mean this is one of many possibilities.. we need to not guess and actually understand the real reason
<cachio> niemeyer, ok
<niemeyer> cachio: If the machine is rebooting, the problem is much easier to debug
<cachio> niemeyer, ok
<cachio> I'll work on this
<niemeyer> cachio: Thanks!
<cachio> niemeyer, to you
#snappy 2018-12-19
<Chipaca> zyga: snap refresh to a bogus channel succeeds when the store is throttling connections, because it returns bogus results that snapd thinks are "ok go for it"
<Chipaca> zyga: https://bugs.launchpad.net/snapd/+bug/1804245
<mup> Bug #1804245: empty response from store when throttled allows switch to nonexistent track <snapd:New> <https://launchpad.net/bugs/1804245>
<RickRNF> Where are the logs for the snap version of snapcraft? I get a "Sorry, an error occurred in Snapcraft.Sending an error report" when running snapcraft cleanbuild
<pstolowski> mornings
<pedronis> pstolowski: hi, can you try to merge master into #6315
<mup> PR #6315: overlord/ifacestate: include interface name in the hotplug-disconnect task summary <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6315>
<pstolowski> pedronis: will do
<pstolowski> pushed
<mup> PR snapd#6265 closed: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6265>
<mup> PR snapd#6321 closed: spread: show free space in debug output <Simple ð> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6321>
<mup> PR snapd#6302 closed: wrappers: address review feedback from #6301 <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6302>
<pedronis> pstolowski: could I get a review of #6306 , it has a bit of non-nice hack for tests atm but that should go away with go1.9 (go vet in 1.6 is too picky)
<mup> PR #6306: release: use locking around lazy intialized state <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
<pstolowski> sure
<pedronis> pstolowski: #6315 is green
<mup> PR #6315: overlord/ifacestate: include interface name in the hotplug-disconnect task summary <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6315>
<pstolowski> ty
<mup> PR snapd#6315 closed: overlord/ifacestate: include interface name in the hotplug-disconnect task summary <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6315>
<oSoMoN> is it a known issue that core18 ships a dbus machine-id file?
<oSoMoN> $ cat /snap/core18/current/var/lib/dbus/machine-id
<oSoMoN> a7579438e8b04d97a185d6aeefb83323
<oSoMoN> that breaks a number of things for core18-based snaps
<oSoMoN> including ibus support
<sparkiegeek> $ cat /snap/core18/current/var/lib/dbus/machine-id
<sparkiegeek> a7579438e8b04d97a185d6aeefb83323
<sparkiegeek> SNAP!
<pedronis> sil2100: ^
<pedronis> that's kind of unexpected
<sil2100> Looking
<sil2100> eh
<sil2100> Indeed, we missed that one
<sil2100> The removal of the machine-id was done in livecd-rootfs ;/
<oSoMoN> sil2100, would it be useful if I filed a bug to track the issue? (if so, where?)
<sil2100> oSoMoN: https://bugs.launchpad.net/snap-core18
<sil2100> I'll be fixing it now
<oSoMoN> thanks
<oSoMoN> sil2100, https://bugs.launchpad.net/snap-core18/+bug/1809107
<mup> Bug #1809107: core18 contains var/lib/dbus/machine-id <snap-core18:New> <https://launchpad.net/bugs/1809107>
<sil2100> pedronis: I don't know much about the implications of that, is this a blocker for core18 release you think?
<sil2100> e.g. should I fast-track this through QA to stable and re-spin core18 images today ASAP?
<sil2100> Testing the fix
<pedronis> sil2100: not sure, need to think a bit
<mup> PR core18#107 opened: As per what we did in core16, remove dbus's machine-id <Created by sil2100> <https://github.com/snapcore/core18/pull/107>
<pedronis> oSoMoN: sil2100: I'm a bit confused because afaict snaps don't have access to that file anyway by default
<sil2100> pedronis, oSoMoN: if anything, the PR above seems to do the trick
<sil2100> pedronis, oSoMoN: I'll merge the PR so that the new core18 can go to validation straight away
<mup> PR core18#107 closed: As per what we did in core16, remove dbus's machine-id <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/107>
<sil2100> cachio: hey! Once the new core18 snap appears at the store, could you run your tests on it?
<pedronis> sil2100: what about /etc/machine-id ?
<sil2100> pedronis: I trunkate it
<sil2100> We did the same for core
<sil2100> pedronis: anyway, in case we decide that we want to re-spin for this, could you give Eric a sign?
 * sil2100 AFK for lunch
<cwayne> Another core 18 snap coming?
<pedronis> cwayne: yes
<pedronis> sil2100: is this the only change that we would get since the last core18?
<pedronis> (seems so)
<sil2100> pedronis: yeah, I suppose
<sil2100> cwayne: could your team pick it up?
<cwayne> sil2100: the snap test will be automatically picked up yes
<sil2100> eh, we missed the auto-import window, I triggered it manually, should be there soon
<sil2100> oSoMoN: a new core18 build is in progress, could you test out the new version once it hits the store?
 * sil2100 now really AFK for lunch + vet
<oSoMoN> sil2100, sure, I'll test it as soon as it's out, edge channel IÂ suppose?
<oSoMoN> could it be that revision 520 is it already?
<pedronis> oSoMoN: yes, 520  seems correct, I see no /var/lib/dbus/machine-id and an empty one in /etc
<pedronis> pstolowski: did you foget to submit the commnet in #6306? I don't see anything new there on GH unless I'm confused
<mup> PR #6306: release: use locking around lazy intialized state <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
<pstolowski> pedronis: damn, indeed. now
<pedronis> pstolowski: thanks I see it now
<oSoMoN> sil2100, pedronis: 520 does the job, the regression with ibus that I was observing with the chromium snap is gone
<oSoMoN> thanks for fixing that so promptly!
<oSoMoN> when can I expect 520 to make it to stable?
<pedronis> oSoMoN: we are trying to QA it quickly
<zyga> hey
<zyga> how are things?
 * zyga was freezing his ... ears off outside today
<roadmr> wear earmuffs :)
<zyga> I was wearing everything I could, just have to admit not used to the cold anymore
<Saviq> hey all, can you please tell me which is the right image on http://cdimage.ubuntu.com/ubuntu-core/ to use in Multipass for "core"? http://cdimage.ubuntu.com/ubuntu-core/16/current/ is from April last year, http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ is from August, are there no newer images?
<roadmr> zyga: hehe well, sometimes it is just too cold.
<zyga> I ended up walking most of the way
<sil2100> Saviq: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ is the latest deal
<zyga> the streets are clogged with traffic jams
<zyga> sil2100: is core18 healthy?
<sil2100> Saviq: we basically only re-create new images with every point-release (not counting some really emergency cases)
<sil2100> zyga: core18 is in testing right now
<sil2100> zyga: I'll tell you once I have results!
<sil2100> ;)
<zyga> sounds good, thank you
<sil2100> zyga: certification team gave +1 on the snap, now just waiting for cachio
<sil2100> pedronis: did you talk to Eric?
<Saviq> sil2100: ack, it's kinda surprising since that means it would like to reboot pretty soon after first boot
<sil2100> Indeed
<mup> PR snapd#6322 opened: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
<cachio> sil2100, it is running
<cachio> it is gonna take about 1~2 hrs to complete
<cachio> sil2100, so far so good
 * cachio lunch
<sil2100> eeek
<sil2100> Not good
<cachio> sil2100, perhaps before
<mup> PR core18#108 opened: Remove build-time openssh-server host keys and add service to auto-generating them on boot <Created by sil2100> <https://github.com/snapcore/core18/pull/108>
<om26er> Would it be "sane" to share the whole snap tree using content interface ? I have a snap crossbar (WAMP router) and I want my app (also a snap) to start that router.
<ogra> om26er, i'd call it "unelegant" but there is surely no technical reason to not do that
<sil2100> zyga: hey! You around?
<sil2100> zyga: could you take a look at https://github.com/snapcore/core18/pull/108 ?
<mup> PR core18#108: Remove build-time openssh-server host keys and add service to auto-generating them on boot <Created by sil2100> <https://github.com/snapcore/core18/pull/108>
<mup> PR core18#108 closed: Remove build-time openssh-server host keys and add service to auto-generating them on boot <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/108>
<sil2100> cwayne, plars: hey! New core18 snaps need validation!
<sil2100> cwayne, plars: could someone track that and make sure it's pushed forward?
<cwayne> sil2100: you don't need to tell us, it's done automatically
<cwayne> Images are different though :)
<sil2100> cwayne: thanks ;p Just poking in case of some infra failure
<sil2100> So that someone can poke it with a stick
<pedronis> cachio: are you testing the new core18 (528 etc) ?
<cachio> pedronis, yes
<pedronis> thx
<cachio> tests being executed
<cachio> pedronis, I'll keep you updated
<cachio> sil2100, +1 to go to candidate and stable
<cachio> snapd tests passed
<cwayne> cachio: do you guys do any BT testing, or just the bt snapd interfaces?
<cachio> just interfaces
<cachio> cwayne,
<zyga> sil2100: hey, I'm around now
<cachio> cwayne, I am going to get my son
<cachio> I'll be back in 30 minutes
<cachio> cwayne, do you need anything urgent?
<cwayne> cachio: nope
<cachio> otherwise I'll be back soon
<cachio> cwayne, nice, thanks
<zyga> sil2100: hey
<zyga> sil2100: if I could I would -1 that pull request
<zyga> what there ensures that keys are generated only once?
<sil2100> Too late
<sil2100> That's the mechanism from core16
<zyga> do we have *perl* on the image?
<zyga> there are better ways for first boot systemd units
<cachio> sil2100, hold on
<zyga> I guess it is too late
<cachio> I just saw an error
<zyga> but this doesn't look great
<sil2100> I don't know the details but it works, and works only once
<zyga> looks like a hack
<zyga> I believe you
<sil2100> cachio: ...uh?
<cachio> sil2100, https://paste.ubuntu.com/p/NbXvcW6Vtt/
<zyga> cachio: interesting, any logs that go with the unit?
<cachio> sil2100, seems to be related with the last change, right?
<sil2100> zyga: yes
<sil2100> hmm
<cachio> zyga, no
<cachio> no logs
<cachio> let me try again
<sil2100> I meant, cachio: yes
<cachio> sil2100, https://paste.ubuntu.com/p/DbGGCsc2pt/
<cachio> zyga, ~
<sil2100> cachio: what device is that?
<sil2100> Crap
<cachio> it is a vm with ubuntu core i386
<cachio> sil2100, zyga https://paste.ubuntu.com/p/Dmj2DmtyVp/
<sil2100> What the heck?
<zyga> sil2100: sent my review on https://github.com/snapcore/core18/pull/108#pullrequestreview-186738700
<mup> PR core18#108: Remove build-time openssh-server host keys and add service to auto-generating them on boot <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/108>
<zyga> sil2100: did you test this locally?
<zyga> I'm surprised about the path
<zyga> specifically /usr/lib/snapd/ssh-host-keygen
<sil2100> Why is /usr/lib/snapd/sshd-host-keygen gone? I did and I remembered it worked
<sil2100> But now it doesn't
<zyga> what ships that file?
<cachio> sil2100, could you reproduce that?
<sil2100> I added it in the PR
<zyga> sil2100: ah I see it now
<sil2100> zyga: I took all of this from core-build and live-build hooks
<sil2100> Fuck
<pedronis> core18
<sil2100> zyga: so snapd overrides that directory right?
<zyga> sil2100: I don't remember from the top of my head
<zyga> I presume yes
<pedronis> sil2100: in core18 yes
<pedronis> likely
<zyga> sil2100: perhaps that script should ship in /usr/bin
<sil2100> How did that work, I got working keys
<pedronis> timing?
<zyga> sil2100: we bind mount that whole thing
<sil2100> Let me move it
<sil2100> Probably timing
<pedronis> sil2100: the overriding at first boot is complicated
<pedronis> it invovles services as well
<zyga> sil2100: can you consider my other comments before landing the next revision (at your discretion)
<pedronis> in core18
<pedronis> core was easier snapd was inside it
<zyga> hey pedronis :)
<pedronis> so that dir was fixed
<sil2100> zyga: I would prefer to just do it now, we're REALLY late
<sil2100> This is like REALLY REALLY REALLY late
<zyga> sil2100: as I said, at your discretion
<cachio> sil2100, zyga pedronis  it is a fresh install https://paste.ubuntu.com/p/zZYJ5h4ZD6/
<zyga> sil2100: I'm super worried about shipping ssh keys
<zyga> that we didn't notice this
<zyga> sil2100: can you at least go over the list of files in the core18 snap that is produced
<sil2100> Anyway, the script as-is was in core so it won't be worse than it was already at least
<cachio> zyga, pedronis sil2100 I need to leave, I need to get my son now
<cachio> I'll be back as soon as possible
<cachio> please telegran me
<pedronis> zyga: that script shipped like that in core16, we can improve it, but probably not right now
<zyga> pedronis: sounds good
<zyga> pedronis: but I think whoever is responsible for core18 should eyeball the list of files
<zyga> pedronis: imagine we shipped this
<zyga> with those keys
<pedronis> zyga: that's what sil2100 did, that's how we got here, afaiu
<zyga> that's good
<sil2100> Ok, first boot works, no failures here, trying second boot with the path change'
<sil2100> zyga: ok, I moved the script to /usr/bin/ and it seems to work
<zyga> sil2100: sounds very good
<pedronis> sil2100: it might need a different name there tough, snapd-  ?
<pedronis> when it was in lib/snapd it didn't need a prefix
<mup> PR core18#109 opened: Move the ssh keygen script to /usr/bin <Created by sil2100> <https://github.com/snapcore/core18/pull/109>
<sil2100> pedronis: +1 on that
<sil2100> It's good to change that just in case, let me do that
<sil2100> Maybe to core-?
<sil2100> Since it's not really a snapd thing
<sil2100> Sure, it was in the snapd directory but well, not sure
<sil2100> zyga, pedronis: PR ready for a quick review
<zyga> looking
<sil2100> Thank you guys
<zyga> thank *you* :)
<zyga> +1
<sil2100> \o/
<pedronis> looks good
<sil2100> I'm doing a quick test build and test run to see if the new name didn't have a typo and then we can build the snap
<sil2100> Merging it in the meantime
<mup> PR core18#109 closed: Move the ssh keygen script to /usr/bin <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/109>
<sil2100> Ok, looks good, kicking new builds
<zyga> \o/
<sil2100> I need to go AFK for a bit
<sil2100> I'll be back in ~30 minutes
<cachio> ok, it will take to finish
<sil2100> Back
<sil2100> cachio: how's the testing?
<cachio> sil2100, so far it is ok
<cachio> last time failed 1 test which is failing because an env issue I have
<cachio> the when I checked the error I saw this time it was something different
<cachio> this time I fixed that issue on the environment but it is running slower
<cachio> sil2100, but I need to make sure everything went well before the +1 :)
<sil2100> cachio: sure!
<pedronis> cachio: do you have a sense of how much long it will take?
<cachio> pedronis, it is 60%
<cachio> I think first suite will finish in 30 minutes maximun
<cachio> second in 35
<cachio> with those we will have a good idea
<cachio> so far no errors
<cachio> but last time the last test failed :(
#snappy 2018-12-20
<sil2100> Fingers crossed that this time we're good!
<cachio> sil2100, +1
<sil2100> \o/
<pedronis> good
<cachio> sil2100, pedronis double checked
<cachio> good night for you :)
<sil2100> cachio: goodnight!
<sil2100> I'll still stick around to see the builds finishing and then handing over the images further
<pedronis> sil2100: thanks
<cachio> sil2100, me too, just ping me in case
<cachio> you need something
<pedronis> sil2100: please do send a quick mail with the state of things
<sil2100> pedronis: sure thing
 * sil2100 EODs
<sil2100> o/
<mup> PR snapcraft#2429 opened: cli: fix usage string in help command <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/2429>
 * cachio EOD
<zyga> o/
<pstolowski> mornings
<pstolowski> hey zyga
<zyga> Iâm going to pick up the car now :-)
<pstolowski> pedronis: heh, locomote ceasing operations (see the announcement email)
<pstolowski> zyga: wooah, the new car?
<zyga> Are you working today?
<zyga> Yes
<pstolowski> zyga: yes, last day before holidays
<pstolowski> zyga: awesome :)
<zyga> What is locomotoe?
<pstolowski> zyga: the tool we were supposed to use to book travel
<zyga> Whaaaat
<pstolowski> zyga: so now it's email/phone booking, until something new is set uo
<pstolowski> *up
<zyga> Lol
<pstolowski> which is fine
<zyga> What a joke
<zyga> Took forever to se up
<pstolowski> yeah..
<zyga> Well fun days
<zyga> I will work a little after picking up the car
<zyga> Some rpm things to finish
<zyga> Then some more rpm
<pedronis> pstolowski: morning, I saw that (the irony), I ended up making larger changes to #6306 promted by your request for more tests
<mup> PR #6306: release: use locking around lazy intialized state <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
<pstolowski> pedronis: k, thanks
<pstolowski> yes, it's irony indeed
<pedronis> pstolowski: please take a look at it when you can, there is more structures on the other end the Mock* methods are easier to follow I think
<pstolowski> yes
<pstolowski> pedronis: i'm playing with a potential fix for the retry slowness on remove; it's very fast now, although i need to think a bit still if not's looping too often now or something
<pedronis> pstolowski: I'm looking a bit at your other PRs, otoh I was up working until quite late, so bit of a slow day I expect
<pstolowski> pedronis: sure, i'm not ready to discuss the fix just yet, just sharing the observation :), i think it looks very promising
<pedronis> pstolowski: does getInterfaceSetting  (it's in ctlcmd.go) has the same bug about not merging as the get config code?  the code look similar
<pedronis> sorry, ctlcmd/get.go
<pstolowski> pedronis: hmm good question, i didn't think of it, will need to check
<pstolowski> pedronis: probably not becausause it doesn't use transactions, there is just one map in play, but i need to double check
<pedronis> pstolowski: I left some notes in the hotplug ones,  one seems to be missing tests
<pstolowski> ok, thanks
<pedronis> pstolowski: I looked at #6322, the change is simple enough, but it seems the unit test situation is complicated, because we lose unit test coverage of GetFromChange
<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>
<pstolowski> pedronis: hmm i see, fair point. that method is now only used by interfaces i think. and btw getFromChange / getFromPristine names are probably not very accurate anymore
<pedronis> yea
<pedronis> also not sure what's the exact difference
<pedronis> pstolowski: anyway it's good to have test elsewhere but we also need a unit test about the change itself
<pedronis> the behavior is quite different
<pedronis> there should be something that failed/was different before, works now even at that level
<jamesh> zyga: hi.  If you've got time, do you have any thoughts about https://github.com/snapcore/snapd/pull/6258#issuecomment-448490796 ?
<mup> PR #6258: interfaces: support D-Bus activation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6258>
<jamesh> I've got things working on 14.04, but only by using different paths for the system service files compared to other distros
<zyga> jamesh: hey, I'm on holidays for the next many days
<zyga> but I will look anyway :)
<pedronis> jamesh: hi, I should also very likely review your open PRs, unlikely to happen before the break at this point tough
<zyga> jdstrand: interesting
<zyga> er
<zyga> jamesh: interesting problem
<jamesh> zyga: fair enough.  Have fun!
 * pstolowski lunch
<mup> PR snapd#6323 opened: snap: give Epoch an Equal method <Created by chipaca> <https://github.com/snapcore/snapd/pull/6323>
<pstolowski> pedronis: another question to 6306
<pedronis> pstolowski: I don't understand the question, the equivalent now is appArmorProbe or mockAppArmorProbe kernelError
<pedronis> pstolowski: whis is returned here:  https://github.com/snapcore/snapd/pull/6306/files#diff-a807fe2d471c632368aaab69caa1d77aR261
<mup> PR #6306: release: use locking around lazy intialized state <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
<pedronis> pstolowski: anyway I tried to answer also in the PR
<pstolowski> pedronis: thanks, i misunderstood the code
<pedronis> pstolowski: tbh all those globals were a bit confusing, I suppose the struct are confusing in a different way :)
<pstolowski> pedronis: yeah
<pedronis> pstolowski: :) about Simple, it was false already with the previous iteration by maciej, maybe the first iteration witht he lock was simple
<pedronis> Chipaca: hi,  could you look at #6306 as well?
<mup> PR #6306: release: use locking around lazy intialized state <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6306>
<pstolowski> heh, sure
<pstolowski> pedronis: slow snap removal scenario - with a tentative fix - down to <40seconds from a few minutes
<Chipaca> pedronis: 's nice
<pstolowski> pedronis: and there's just 1 or 2 retries in that period, so it's basically down individual connects/disconnects now (there are lots of them due to number of interfaces)
<mup> PR snapd#6306 closed: release: use locking around lazy intialized state <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6306>
<pedronis> Chipaca: pstolowski: thanks, merged
<mup> PR snapcraft#2429 closed: cli: fix usage string in help command <Created by felicianotech> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2429>
<om26er> Hi! I have a snap that runs a background service `daemon: simple` my process also starts a subprocess but seems that subprocess gets killed instantly
<om26er> So systemd doing that or is there something missing inside snapd ?
<om26er> relevant config here: https://github.com/om26er/screen-brightness-server/blob/master/snap/snapcraft.yaml#L35
<om26er> zyga, ^^
<zyga> om26er: hey
<zyga> om26er: when you say it gets killed instantly
<zyga> how do you know, what do you measure?
<zyga> om26er: snapd is not doing that for sure
<zyga> I suspect it may be systemd
<zyga> do you have any apparmor or seccomp denials?
<om26er> zyga, I see journalctl logs
<zyga> om26er: (disclaimer: I'm on holidays, but  you know how things are sometimes :)
<om26er> zyga, its currently in devmode so I assume apparmor isn't doing something bad
<zyga> that's correct
<zyga> can you reproduce that outside of snapd context?
<zyga> with a service file and your code as is
<om26er> zyga, I haven't tried that, I should probably do that.
<om26er> ...and enjoy your holidays, its not urgent, I'll eventually find a solution
<zyga> Ping me with the logs if you have them
<zyga> Iâll be back in 15 minutes
<zyga> Doing some house work now
<zyga> om26er: looking at your yaml
<zyga> om26er: what is the current working directory?
<zyga> not sure if run is running as subprocess
<zyga> but perhaps it cannot find "start" on path/
<om26er> zyga, here is the log https://paste.ubuntu.com/p/WRBDSDGg5t/
<zyga> Dec 20 19:26:19 X1C6 screen-brightness-server[9149]: 2018-12-20T19:26:19+0500 [Guest        9193] RuntimeError: Event loop stopped before Future completed.
<zyga>  
<zyga> Dec 20 19:26:19 X1C6 screen-brightness-server[9149]: 2018-12-20T19:26:19+0500 [Router       9184] Native worker received SIGTERM - shutting down ..
<om26er> its correctly started line 103 and 104 indicate that
<zyga> so, is your main process exiting?
<om26er> yes that exists as well
<zyga> exits or exists?
<om26er> *exits, sorry
<zyga> my question is this: if you fork, do something in child and exit in the parent
<zyga> then you cannot do this with daemon: simple
<zyga> read on systemd units and service types in particular
<zyga> my recommendation:
<zyga> simplify your code, don't fork
<zyga> just run in the main process
<om26er> from here https://docs.snapcraft.io/snapcraft-app-and-service-metadata/8335
<om26er> I tried simple it gives me above error
<zyga> I don't know your code but I don't believe your issue to be related to snaps in any way
<om26er> I tried forking and notify seems the snap keeps on starting the service
<zyga> I suspect you misuse systemd service units
<zyga> you cannot use notify easily
<zyga> I would recommend to see how your code runs with systemd services first
<zyga> simplify it, as most of the time forking is a legacy concept
<zyga> (forking daemons)
<zyga> may I ask why your code forks?
<zyga> is it for python multiprocessing?
<zyga> (note that multiprocessing, AFAIK, requires a small tweak to work with snap confinement, I believe there's a forum thread about this)
<om26er> generally the crossbar router is run on a different machine and its "clients" run on different. In this case the router and one of the client is running on the same machine.
<zyga> ok
<om26er> so I configured my router to start that client, so hence its forking
<zyga> if the router keeps running
<zyga> then systemd will be happy
<zyga> the main point is that the process that is started must not exit
<zyga> or systemd will consider the unit to have failed and will "restart" it
<om26er> the router indeed keeps running its maybe a bug somewhere inside the router that isn't able to communicate that to crossbar
<zyga> perhaps
<om26er> *communicate that to systemd
<zyga> did you get any interesting stuff in journald?
<zyga> well, systemd just observes the process
<zyga> I don't believe you can fool it this way
<om26er> nothing interesting in journald, I'll the crossbar team regarding that
<om26er> *ask (freaking typos)
<om26er> or may need to re-architect my app
<om26er> creating two different services may also work
<zyga> om26er: nothing at all in journald or nothing just in the service unit of your snap?
<om26er> one starts the router, the other starts the client.
<zyga> denials would go to a different place (just curious if you hit any)
<zyga> om26er: how do the apps communicate?
<om26er> that above paste.ubuntu was from journalctl
<om26er> zyga, over localhost (I may consider using a sock file though)
<zyga> over network sockets?
<zyga> that would work, yeah
<om26er> yeah
<om26er> the client-router in this case talk through websocket btw
<om26er> so ultimately my chrome extension which is also another "client" connects to the router and makes a RPC to increase laptop's screen brightness when Netflix.com goes fullscreen
<zyga>   lol
<zyga> that's some elaborate software :D
<zyga> nice
<om26er> I was initially doing that over http ( was much simpler and worked as well ) but that was too boring and had limits, because I will ultimately enhance this daemon just do a lot more than just increase screen brightness.
<om26er> move laptop cursor using Android app: Check
<om26er> increase/decrease laptop screen brightness using Android app (requested a snapd interface for that already), lock laptop screen (snapd actually have an interface for that) using Android app.
<om26er> You'd say most of those things are done by KDE Connect already, that's true but we (Crossbar.io) wanted to experiment those things using our technology stack.
 * cachio lunch
<popey> Chipaca: where is the source for https://snapcraft.io/test-snapd-complexion ?
<Chipaca> popey: right here
<Chipaca> popey: https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/test-snapd-complexion
<zyga> this is an internal test snap for snapd
<popey> i see no snapcraft.yaml
<zyga> it's not built with one
<zyga> just "snap pack"
<popey> ok, the reason I am asking is because an external developer is asking about completion
<zyga> popey: most of our test snapd are built without snapcraft
<popey> https://forum.snapcraft.io/t/tab-completion-for-snaps/2261
<zyga> Chipaca: ^ ?
<Chipaca> popey: on it
<popey> this documentation refers to it but it's opaque
<zyga> ohai
<Chipaca> oh that's not the developer
<popey> impossible to find the way you as a developer would create a yaml
<popey> what the developer wants is some docs for how to setup completion
<popey> and that doc gives half a story
<Chipaca> popey: you point the 'completer' attribute of the app to the completer
<zyga> (we should merge snapd and snapcraft teams)
<Chipaca> popey: i'm not sure what rest-of-the-story there is
<popey> (I'm after online docs, not answers to questions in irc) :)
<Chipaca> popey: i was quoting from the docs you linked
<popey> right, but people want a whole example
<popey> and that doc links to something that doesnt use the way we usually recommend building snaps (snapcraft.yaml)
<popey> so it's a bit fuzzy to pick up
<Chipaca> popey: if it helps, snapcraft  uses snapcraft to build snapcraft and it has completion
<Chipaca> does http_proxy=http://:8080 work?!?
<Chipaca> looks like yes
<Chipaca> wow
<popey> https://github.com/digitalocean/doctl/blob/hholz/fix-snap-build/snap/snapcraft.yaml
<popey> That's what they're currently doing (line 27/28) does that look sane?
<zyga> I'm intrigued
<zyga> I will add completion support to my app
<zyga> and snap it
<Chipaca> popey: looks like it
<Chipaca> popey: but i don't know enough snapcraft to offer you certainty
<zyga> reinforcing my desire to merge the teams
<zyga> nobody outside of our team looks at snapcradt and snapd as separate things
<Chipaca> zyga: ?
<zyga> that we don't know snapcraft like the back of our hand
<zyga> (is that the right phrase?)
<Chipaca> zyga: how would merging the teams make me use snapcraft to the degree that I'd be able to know if something works just by inspecting the yaml?
<zyga> we'd certainly know it more over time
<Chipaca> zyga: keeping in mind that I'm reviewing snapcraft pull requests every week
<zyga> and we'd ship features in sync more?
<zyga> (woot, that's great)
<zyga> (I'm not)
<Chipaca> popey: is it not working for them?
<popey> no
<pedronis> zyga: I think it would make sense to have somebody that does a bit of both (depends which bits in snapd), merging the teams overall doesn't sound a great idea to me
<Chipaca> popey: why?
<popey> tab does nothing
<popey> i need to debug it further after this meeting
<Chipaca> popey: https://forum.snapcraft.io/t/debugging-tab-completion/4198 fwiw
<Chipaca> popey: is the snap in the store?
<popey> no, we're fixing a bunch of things
<popey> ooh, thats neat, thank you
<Chipaca> popey: I could take a quick look for the usual suspects if you have access to it
<Chipaca> popey: if you do follow the debugging doc, feedback much appreciated
<popey> passed that on, really great thanks
<om26er> How can a snap "wait" for an interface to connect ?
<om26er> I have daemon in my snap, which is useless if a specific interface is not connected, how can I make my daemon wait for that interface to connect ?
<om26er> does snapd provide some sort of helpers for that or is that something I should take care of with my code
<pstolowski> pedronis: pushed missing tests to #6113
<mup> PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113>
<pedronis> pstolowski: thx
<Chipaca> pstolowski: do you have any insight for om26er ^?
<om26er> currently I am toying with this idea: i.e. retrying every 5 seconds to check if that specific interface was connected. https://paste.ubuntu.com/p/7VP2DZdjM9/
<pstolowski> om26er: you can use interface hooks to notify you deamon about interface getting connected
<pstolowski> om26er: https://docs.snapcraft.io/interface-hooks/8214
<om26er> reading into that
<pstolowski> om26er: i hope that helps
<om26er> pstolowski, thanks for the link :-)
<pstolowski> roadmr: hey, u there?
<roadmr> hi pstolowski
<pstolowski> roadmr: hey, i've completely missed your email from a few days ago, sorry about that!
<roadmr> pstolowski: oh! hey, not a problem
<roadmr> pstolowski: I did some experimentation yesterday and have responded to the customer. Things do work and auto-connect the moment the two snaps are in the system; i.e. installation order doesn't matter
<pstolowski> roadmr: now, i don't know all the answers, some of that is not possible for sure, some stuff i need to check/discuss internally. can this wait till after holidays?
<roadmr> pstolowski: yes, not a problem, we can check again once back from EOY
<pstolowski> roadmr: ok, great, thanks, i'll get back to you on that
<roadmr> thanks pstolowski.
<pstolowski> roadmr: np, and sorry i didn't respond earlier
<roadmr> pstolowski: hehe no worries, we all get tons of e-mail,it does happen
<pstolowski> ok, with that i'm gonna wrap up this year, all the best to everyone and have great holidays!
<pstolowski> o/
<cachio> zyga, hey
<cachio> https://travis-ci.org/snapcore/spread-cron/builds/468916546#L3283
<cachio> I am updating the opensuse images and still see errors
<cachio> previously updated and refreshed using zypper
<cachio> any idea if something is missing?
<Chipaca> pedronis: I'll be working a little bit tomorrow morning to try to get this into a PR, it's that close :-)
<Chipaca> EODing now, ttfn
<cachio> zyga, found the problem
 * cachio afk
 * cachio EOD
#snappy 2018-12-21
<probono> hi all. is it possible to make a valid snap "by hand", i.e., using mksquashfs?
<probono> no snapcraft, etc.?
<probono> if so, how?
 * probono is thinking about making a snap that is also an AppImage at the same time...
<ijohnson> You can use `snap pack some-dir` to create the snap file assuming you've prepared the contents of the snap independently
<probono> thanks ijohnson
<probono> Gettig error: cannot pack "./squashfs-root": invalid snap name: "NotepadPlusPlus"
<probono> ok, needs to be all lowercase....
<probono> me@host:~$ snap pack ./squashfs-root
<probono> 2018/12/21 21:07:20.418838 container.go:205: in snap "notepadplusplus": "." should be world-readable and executable, and isn't: drwx------
<probono> error: cannot pack "./squashfs-root": snap is unusable due to bad permissions
<probono> what now?
<ijohnson> you probably need to make that directory "squashfs-root" readable, i.e. `chmod +r squashfs-root`
<probono> me@host:~$ chmod -R +r squashfs-root
<probono> me@host:~$ snap pack ./squashfs-root
<probono> 2018/12/21 21:09:36.736235 container.go:205: in snap "notepadplusplus": "." should be world-readable and executable, and isn't: drwxr--r--
<probono> error: cannot pack "./squashfs-root": snap is unusable due to bad permissions
<ijohnson> maybe you also need `chmod -R +x`
<probono> indeed ijohnson
<probono> now i have a .snap file - how to i run it?
<probono> $ snap run note*.snap
<probono> error: cannot find current revision for snap notepad: readlink /snap/notepad/current: no such file or directory
<probono> me@host:~$ sudo snap install note*snap
<probono> error: cannot find signatures with metadata for snap
<probono>        "notepadplusplus_1.0_all.snap"
<ijohnson> snaps are meant to be installed from the snap store at snapcraft.io, and when you go to run something like `snap install my-snap`, the snap file is downloaded along with assertions for the snap in an .assert file. If you want to install a snap without also installing assertions, as in your case when installing a snap built locally and not uploaded to the store you need to add the `--dangerous` flag
<ijohnson> i.e. run `snap install --dangerous my-snap*.snap`
<probono> me@host:~$ sudo snap install --dangerous note*snap
<probono> error: only one snap file can be installed at a time
<ijohnson> you probably have multiple *.snap files, either remove the ones you aren't trying to install or make the pattern more specific
<probono> stupid me, sorry
<probono> can install now
<probono> but.
<probono> me@host:~$ notepadplusplus
<probono> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<probono> trying
<probono> sudo snap install --devmode --dangerous notepadplusplus_7.6.1_all.snap
<probono> does not seem to help
<probono> how can i disable all "security"?
<ijohnson> the error message about snap-confine is not one I can help debug at the moment unfortunately. I'd recommend posting on the forum at forum.snapcraft.io for more help, as that seems like there may be an issue with your snapd installation
<probono> ok, thanks for your help ijohnson
 * cachio EOY
<probono> https://github.com/probonopd/libhookexecv/issues/4
<probono> me@host:~$ sudo apt purge snapd snap-confine
<probono> me@host:~$ sudo apt install -y snapd
<probono> did the trick
<probono> but now running into new issues
<mup> PR snapcraft#2430 opened: extractors: better appstream support for descriptions <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2430>
<ijohnson> probono: unfortunately I have to take off now, but if you post on the forum you're more likely to get help since most folks won't be watching IRC for the next 2 weeks due to holidays
<ijohnson> good luck!
<probono> ping zyga
<mup> PR snapcraft#2431 opened: tests: re-enable spread tests on gce <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2431>
#snappy 2018-12-22
<mup> PR snapcraft#2390 closed: repo: document package purpose <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2390>
#snappy 2018-12-23
<sborovkov> Hi, got a crash  in the snapcraft - https://hastebin.com/wipeworefi.cs
<sborovkov> I mean unhandled exception
<sborovkov> is this a known issue?
#snappy 2019-12-16
<mup> Bug #1674847 changed: produce package lists for Ubuntu Core versions on the web <Snappy:Expired> <https://launchpad.net/bugs/1674847>
<mborzecki> morning
<mvo> hey mborzecki !
<mvo> mborzecki: good morning, how are you?
<mborzecki> mvo: hey
<zyga> good morning guys
<zyga> mvo: last night I realized I have holidays to burn
<mborzecki> zyga: hey hey
<mborzecki> zyga: you can carry over up to 5 days iirc
<zyga> mvo: I was thinking about EOWking and just soft-working on few loose ends
<zyga> mborzecki: IIRC I have 12-15 ish
<mborzecki> wow
<mvo> hey zyga
<mvo> zyga: uh, GO
<mvo> zyga: like seriously, that is a lot
 * zyga files for a week off
<mborzecki> mvo: we need a trello card for zyga to remind him of taking vacation
<mvo> mborzecki: haha - indeed!
<zyga> :D
<mup> PR snapd#7909 opened: snap: improve squashfs.ReadFile() error <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7909>
<pedronis> morning, mvo: let me know when/if you want to chat about #7908
<mup> PR #7908: [RFC] boot,devicestate: update modenv and extract kernel <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7908>
<mvo> pedronis: not right now, debugging a issue in the initramfs right now :(
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> pstolowski: hey
<pedronis> mvo: ok, I'll start looking at its bits in handlers_install.go
<mvo> pedronis: thank you!
<mvo> pedronis: yeah, let's sync, I think the install steps (the minimal ones) are not that much work
 * zyga goes to check out alternative school for Janek
<mup> PR pc-amd64-gadget#27 opened: grub.cfg-recovery: add run mode chainloading <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/27>
<pedronis> mvo: I pushed some improvements to 7908, not quite fully there, we need to chat a bit about /boot layout
<mvo> pedronis: ok, should we have a HO in some minutes?
<pedronis> mvo: yes
<mvo> pedronis: ok, I am ready in 3min or so
<pedronis> mborzecki: hi, can you do a review of https://github.com/snapcore/snapd/pull/7905 when you have a moment , then mvo can do one as well
<mup> PR #7905: cmd/snap-bootstrap: actually parse snapd_recovery_system label <UC20> <Created by xnox> <https://github.com/snapcore/snapd/pull/7905>
<mborzecki> pedronis: sure, will do
<pedronis> thx
<mup> PR pc-amd64-gadget#28 opened: grub.cfg-normal: set snapd_recovery_mode= run in run mode <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/28>
<pedronis> pstolowski: hi, do we need to chat about services?
<pstolowski> pedronis: hi, yes, that would be great
 * Chipaca steps back from the forum and goes for coffee
<pedronis> pstolowski: now, in a couple of mins?
<pstolowski> pedronis: in 10 ?
<pedronis> ok
<pstolowski> pedronis: i'm in the standup ho
<pedronis> ok
<pedronis> joining
<mup> PR snapd#7910 opened: boot,image: add skeleton boot.makeBootable20RunMode <Created by mvo5> <https://github.com/snapcore/snapd/pull/7910>
<mborzecki> meh, looks like we'll need to pass Device to wrappers
<mborzecki> but probably as a later cleanup
<mup> PR pc-amd64-gadget#27 closed: grub.cfg-recovery: add run mode chainloading <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/27>
<mup> PR pc-amd64-gadget#28 closed: grub.cfg-normal: set snapd_recovery_mode= run in run mode <Created by mvo5> <Closed by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/28>
<pedronis> mvo: Q in 7910
<mvo> pedronis: looking
<mborzecki> mvo: updated #7772
<mup> PR #7772: wrappers: write and undo snapd services on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
<mvo> pedronis: of course, I'm a muppet, fixing and adding a test
<mvo> mborzecki: nice!
<mup> PR snapd#7911 opened: Uc20 shutdown <Created by xnox> <https://github.com/snapcore/snapd/pull/7911>
<cachio> mborzecki, hey
<cachio> mborzecki, about lp:1856073
<cachio> you think it is be manually cleaned during tests?
<mborzecki> cachio: hi, yes, left it in the comment https://bugs.launchpad.net/snapd/+bug/1856073/comments/2
<mup> Bug #1856073: Failed service state recorded by systemd even after snap removal <snapd:Confirmed> <https://launchpad.net/bugs/1856073>
<cachio> mborzecki, yes, I saw that
<cachio> I'll make the change in the tests in that case
<mborzecki> ok
<cachio> mborzecki, thakns
<cachio> zyga, hey, could you please give a second round to #7877
<mup> PR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>
<cachio> thanks
<cachio> mborzecki, another thing
<cachio> mborzecki, I can reproduce this in arch https://paste.ubuntu.com/p/XCwW2VnpXG/
<cachio> mborzecki, I think at some point you reported something similat
<cachio> similar
<pedronis> mvo: reviewed 7910 with some suggestions
<mvo> pedronis: cool, thank you
<mborzecki> cachio: no that was antoher test checking whether access to the socket is mediated by apparmor
<pedronis> pstolowski: reviewed #7658
<mup> PR core20#14 closed: run-snapd-from-snap: check for snapd.service existing too <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/14>
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<mup> PR snapd#7912 opened: boot: write modeenv when creating the run mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7912>
<pstolowski> pedronis: ty!
 * Chipaca gets lunch
<ijohnson> morning folks
<mup> PR snapd#7658 closed: cmd/snap-preseed: add snap-preseed executable <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<cachio> mborzecki, hey
<pstolowski> pedronis, degville i've sent you an email invitation to edit snap-preseed help doc
<cachio> after many tests we left a systemd unit sys-devices-virtual-block-loop1.device
<cachio> mborzecki, is it created by snapd?
<cachio> any idea?
<pedronis> pstolowski: thanks, I'll try to get to it today or tomorrow morning
<mvo> pedronis: 7912 should be a simple one
<mborzecki> cachio: it's probably a loopback device that's left behind, any chance you could run `losetup -l` there?
<pedronis> mvo: ok, I need a short break frist though
<mup> PR snapd#7910 closed: boot,image: add skeleton boot.makeBootable20RunMode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7910>
<pedronis> *first
<cachio> mborzecki, yes, I'll add more info for next run
<mvo> pedronis: yeah, no worries
<mborzecki> cachio: it might be the case that libloop leaves one free device behind as an optimization so that it doesn't need to allocate it again
<cachio> mborzecki, thanks, I added a new check for loop devices
<cachio> and triggered a new run
<cachio> it will be ready on 1 hour aprox
<cachio> afer lunch
 * cachio lunch
<Chipaca> need to go to the boys school for a bit, will bbiab
<mup> PR snapd#7852 closed: devicestate: call boot.MakeRunnable() in devicestate <UC20> <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7852>
<mborzecki> hmm MATCH with multiline input behaves somewhat weird
<mborzecki> err MATCH -v actually
<Chipaca> mborzecki: weird how?
<mborzecki> Chipaca: https://paste.ubuntu.com/p/P3hyRbDmcy/
<mborzecki> Chipaca: we actually have code in tests that does MATCH -v with multiline input
<Chipaca> mborzecki: MATCH -v means "error if there are no lines that don't match" which is a little weird to think about so I wouldn't be surprised if it's used wrong
<mborzecki> Chipaca: heh sooo https://paste.ubuntu.com/p/GD63G4S2sX/
<mborzecki> hmm that lsmod, snap list, virsh checks are likely wrong
<mborzecki> probably the same in cgroups test :/
<mup> PR snapd#7913 opened: boot,bootloader: extract kernel in makeBootable20RunMode  <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7913>
<mup> PR snapd#7914 opened: bootstrap: reduce runmode mounts from 5 to 2 steps <Created by xnox> <https://github.com/snapcore/snapd/pull/7914>
<pedronis> mvo: does 7913 works or we think it works?
<mvo> pedronis: I'm testing it now
<mvo> pedronis: you can mark it blocked if you want
<mvo> pedronis: but it's essentially what I had in mind and tried to describe
<pedronis> mvo: yes, but I said it makes sense to land only if works
<pedronis> also it needs more XXX to it :)
<mvo> pedronis: heh :) yeah, I need to update the other bits from claudios first
<mvo> pedronis: doing this now
<pedronis> mvo: sounds like bootloader.Options.Recovery needs a different name
<pedronis> but that's less of an issue
<mvo> pedronis: yeah, its a bit too confusing, ideas welcome!
<pedronis> I need to look again exactly how it is used
<mvo> pedronis: \o/
<pedronis> mvo: working?
<pedronis> does it seed again?
<mvo> pedronis: yeah, testing if it seeding
<pedronis> what initramfs is it using?
<mvo> pedronis: I mean, unless I miss something (entirely possible) with this PR and the other changes from claudio we should be seeding now
<mvo> pedronis: except that snap-bootstrap in run-mode in initramfs is buggy
<mvo> pedronis: but xnox is on this :)
<pedronis> mvo: but what is putting the kernel and the base in the right place?
<mvo> pedronis: maybe more is missing and I'm missing this - the kernel will be put in place byhttps://github.com/snapcore/snapd/pull/7913/files#diff-06592349bc3e8eaeecc7bc0cafcb3cacR471  and the snap-bootstrap should open the right base in run mode and make it available in /run/mnt/base
<mup> PR #7913: boot,bootloader: extract kernel in makeBootable20RunMode  <UC20> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7913>
<mvo> pedronis: we also have the seed
<pedronis> I probably don't remember what snap-bootstrap run mode is doing then
<pedronis> is probably wrong
<pedronis> somehow
<pedronis> mvo: to be clear, I'm talking about ubuntu-data/var/lib/snapd/snaps
<xnox> mvo:  so for runmode I will do two things, reduce runmode steps from 5 to 2 => see my PR. And actually make it just step 1, as initrd will try to mount the "basic" things meaning in runmode, snap-bootstrap is done and dusted in one step.
<mvo> pedronis: we setup the uc20 seed there and go through normal seeding iirc, no?
<pedronis> mvo: no, something is confusing me
<pedronis> or maybe is right for the first boot but not the other
<pedronis> I need to stare at snap-bootstrap code
<pedronis> I suppose
<pedronis> let me look at it again
<pedronis> mvo: snap-bootstrap expects the base and kernel to be in  filepath.Join(dataDir, "system-data", dirs.SnapBlobDir, modeEnv.Base)
<pedronis> that's the bit I don't undersand
<pedronis> when do we put them there
<pedronis> ??
<pedronis> extracting the kernel doesn't do that
<mvo> pedronis: oh, right - now I see what you mean
<pedronis> so I'm not sure how it works
<pedronis> except magic :) ?
<mvo> pedronis: well, we are not there yet :/
<pedronis> you said it worked ?
<pedronis> work != work
<mvo> pedronis: sorry, I think I miswrote, I wanted to say that I'm trying to see if it works
<mvo> pedronis: and that I need bits from cladio first and that it's a bit of work to get to the point
<pedronis> mvo: heh, it's ok, I got very confused
<pedronis> mvo: I gave some comments in 7913
<mvo> pedronis: but it does sound like another wrench in the gears
<mvo> pedronis: oh well! so much things to fix still
<pedronis> mvo: well, it's easy to fix, we need to copy those snaps
<pedronis> that we knew
<mvo> pedronis: in makebootable
<pedronis> yes
 * mvo nods
<pedronis> like the UC16 makes symlinkes, this one need to do copies
<mvo> right
<mvo> pedronis: sorry, brain is a bit fried - I added a todo for myself here
<pedronis> mvo: anything I can help with?
<mvo> pedronis: hm, maybe (if you haven't done already) point the extra xxx in 7913, other than that I think it's mostly working through stuff now
<mvo> pedronis: I mean, I try to work through the stuff from claudio
<pedronis> mvo: sorry, "point the extra" ? address the extra? add an extra ?
<mvo> pedronis: sorry again! I mean, you mentioned earlier that 7913 will need a bunch of extra XXX beyond the ones I added there
<mvo> pedronis: if you haven't done so already, pointing them out in the PR would be great
<ijohnson> is ubuntu-image expected to build partitions from gadget.yaml for core20 pc gadget yet?
<ijohnson> I just tried building a uc20 image with ubuntu-image with 20/edge snaps and what seems to be a correct dangerous model and I only got the ubuntu-seed partition, the ubuntu-boot partition seems to be missing
<pedronis> ijohnson: that's expected
<pedronis> the images have only seed
<pedronis> boot is added at installation
<ijohnson> pedronis: ah ok so for my purposes then I'll manually create the ubuntu-boot partition since it doesn't seem like trying to get install mode to work just to create that partition
 * cachio afk 10 min 
<mup> PR snapd#7915 opened: lkenv.go: adjust for new location of include file <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7915>
<mup> PR snapd#7916 opened: interfaces/browser-support: add more product/vendor paths <Created by Erick555> <https://github.com/snapcore/snapd/pull/7916>
#snappy 2019-12-17
<mup> PR snapd#7917 opened: snap-bootstrap: trigger udev for new partitions <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7917>
<mup> Bug #1846894 changed: Cannot use PulseAudio in classic confinement <Snappy:Expired> <https://launchpad.net/bugs/1846894>
<mup> PR snapd#7909 closed: snap: improve squashfs.ReadFile() error <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7909>
<mup> PR snapd#7911 closed: systemd: fix uc20 shutdown <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7911>
<mup> PR snapd#7912 closed: boot: write modeenv when creating the run mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7912>
<mup> PR snapd#7915 closed: lkenv.go: adjust for new location of include file <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7915>
<mup> PR snapd#7918 opened: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7918>
<mup> PR snapd#7914 closed: bootstrap: reduce runmode mounts from 5 to 2 steps <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7914>
<mborzecki> morning
<mvo> hey mborzecki
<mup> PR snapd#7919 opened: snapstate: do not try up update bootloader in ephemeral mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7919>
<mborzecki> mvo: hey, any interesting PRs to look at?
<mvo> mborzecki: 7918,7919 are hopefully interessting
<mborzecki> mvo: ok, let me see, i saw some chatter yesterday about that but i may not be familiar with the details
<mup> PR snapd#7920 opened: snapstate: do not try to detect rollback in ephemeral modes <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7920>
<mvo> mborzecki: yeah, all pretty straightforward but probably needs samuele anayway
<mborzecki> mvo: #7916 is quite trivial
<mup> PR #7916: interfaces/browser-support: add more product/vendor paths <Created by Erick555> <https://github.com/snapcore/snapd/pull/7916>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapd#7921 opened: devicestate: run boot.MakeBootable in doSetupRunSystem <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>
<mup> PR snapd#7905 closed: cmd/snap-bootstrap: actually parse snapd_recovery_system label <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7905>
<pedronis> degville: I don't have enough access to make comments or suggestions to the assertions doc
<degville> pedronis: sorry - fixed now. I keep expecting docs to default to edit in share mode.
<Chipaca> degville: ð
<Chipaca> degville: I noticed while on holiday that in the glossary we were mixing up core and core16
<Chipaca> degville: if nobody brought that to your attention, here is me doing so :)
<degville> Chipaca: thanks! pedronis did indeed point it out - hopefully fixed now.
<Chipaca> degville: good good :)
<pedronis> degville: thank you, I did a pass
<degville> pedronis: thank you!
<mup> PR snapd#7922 opened: packaging, tests: stop services in prerm <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7922>
<pedronis> degville: I did some edits to the glossary, please look at the last diff, feel free to reedit if needed
<pedronis> degville: we also should tweak the assertions entry once we have agreement in the main doc
<pedronis> degville: weird, seems for reasons discourse merged my update with your last one
<pedronis> (that is confusing (tm))
<pedronis> degville: pstolowski: I made a couple of suggestions in the preseed help doc
<degville> pedronis: thanks! I'll take a look at the glossary diff and your other comments!
<pstolowski> pedronis: thanks!
<pedronis> pstolowski: the help texts are good for me now
<pstolowski> pedronis: +1, i can prep a PR once degville makes a pass
<pedronis> thx
<degville> pstolowski: looking now, but they're good for me too.
<degville> pstolowski: +1 from me too...  thanks for creating the docs.
<degville> s/docs/doc
<pstolowski> np, thanks for feedback!
<mup> PR snapd#7923 opened: snap-bootstrap: mount filesystems after creation <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7923>
<cachio> Chipaca, hey
<Chipaca> cachio: 'sup
<cachio> last week there was a problem with the apt-hooks test
<cachio> store started rejecting calls to /names api
<cachio> I had to set as manual the test
<cachio> Chipaca, this is the log https://paste.ubuntu.com/p/JY69dz4vwP/
<cachio> Chipaca, do you know if anything chante in snapd that could be causing this?
<Chipaca> cachio: nothing changed in snapd no
<mup> PR snapd#7924 opened: tests: fix use of MATCH -v <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7924>
<cachio> Chipaca, so, somethings changed in the store
<Chipaca> cachio: probably
<Chipaca> cachio: how often were we getting this, and in what timeframe?
<mborzecki> Chipaca: ^^
<mborzecki> fun PR
<Chipaca> mborzecki: yep, nice
<cachio> Chipaca, almost all the runs were failing
<cachio> Chipaca, and if you run now the whole suite it fails too
<mborzecki> cachio: 429 Too Many Requests, store doesn't like us anymore?
<cachio> yesterday I rna the checks pr which wasn't merged to master nad apt-hooks failed
<cachio> mborzecki, aparently not :)
<Chipaca> cachio: when did this start?
<cachio> tuesday / wednesday
<mborzecki> logger.go:74: DEBUG: < "HTTP/1.0 429 Too Many Requests\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n"
<mborzecki> it'd be nice to see the content
<cachio> Chipaca, reviewed the google docs and I see the error started on tuesday
<mborzecki> cachio: this happens when running on gcp?
<cachio> mborzecki, yes
<mborzecki> cachio: ok, trying out something
<cachio> mborzecki, nice, thanks
<mvo> 7904 needs a second review
<mborzecki> cachio: heh, i suppose i can stop spamming api.snapcraft.io, can't reproduce this, maybe curl takes too long between requests
<cachio> mborzecki, perhaps I could add extra logging and run apt hooks test
<cachio> does it make sense?
<mborzecki> cachio: have you seen it pop up in PR travis jobs?
<mup> PR pc-amd64-gadget#29 opened: grub.cfg-normal: go back to the UC16 way of loading the kernel <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/29>
<mup> PR snapd#7925 opened: cmd/snap-preseed: update help strings <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7925>
<mborzecki> cmatsuoka: question for you in 7917
<cmatsuoka> mborzecki: sure
<mborzecki> cmatsuoka: maybe worth trying, provided the spread tests pass
<cmatsuoka> mborzecki: let me check what that does exactly...
<cmatsuoka> mborzecki: so you mean calling it after all nodes are there (and it would act on all block devices, not only the ones we just created)?
<mborzecki> cmatsuoka: no, just adding --subsystem-match=block to the udevadm trigger call
<cachio> mborzecki, yes
<pstolowski> pedronis, degville #7925 is up
<mup> PR #7925: cmd/snap-preseed: update help strings <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7925>
<cachio> mborzecki, initially I saw that in travis
<degville> pstolowski: thank you!
<cachio> then I could reproduce it manually here
<cmatsuoka> mborzecki:  since we're already calling it with a block device target, I think it wouldn't change what it's doing
<cmatsuoka> mborzecki: I'll have a look at the source code to be sure
<mborzecki> cachio: ah, right
<mborzecki> cachio: yeah, so it's fine
<cachio> mborzecki, which should be the best configuration for adding more debug info ?
<cachio> trying to add more debug without touching the code
<cachio> mborzecki, currently we use SNAPD_DEBUG_HTTP=7 SNAPD_DEBUG=1
<mup> PR pc-amd64-gadget#29 closed: grub.cfg-normal: go back to the UC16 way of loading the kernel <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/29>
<mborzecki> cachio: i think that we only dump the outgoing request data
<cachio> mborzecki, now is not failing anymore apt-hooks
<mup> PR snapd#7926 opened: cmd/snap-bootstrap: xxx todos about kernel cross-checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/7926>
<cachio> mvo, about 2.43 on arm64
<cachio> it is not in beta the snapd snap
<mvo> cachio: oh, let me check. maybe there was a mistake :( sorry for that
<mvo> cachio: should be fixed now
<cachio> mvo, thanks
<mborzecki> cachio: pushing some patches to reset the state of failed services after each test run in a couple of minutes
<cachio> mborzecki, nice, I am going to the hospital now, I'll review it there
 * cachio afk
<mup> PR snapcraft#2845 opened: remote-build: configurable timeout/deadline for starting and monitoring build <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2845>
<mup> PR snapd#7925 closed: cmd/snap-preseed: update help strings <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7925>
<mup> PR snapd#7924 closed: tests: fix use of MATCH -v <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7924>
<mvo> hrm, lot's of reds in snapd already
<mvo> eh, travis - has anyone looked?
<thresh> hello. can someone explain to me why I can not see "real" hostfs root from my VLC snap, but still can access it via /var/lib/snapd/hostfs/ ?  i'm on debian, snap/snapd 2.42.5, kernel 5.3.0.  vlc is installed in "strict" mode.
<cachio> mvo, any test that I could take a look?
<cachio> of those reds?
<pstolowski> thresh: the filesystem that snaps see is composed on the fly from core snap (or core18) and various bind-mounted dirs, so it's completely different from the host fs. hostfs is mounted on the side under /var/lib/snapd/hostfs/ for some interfaces (such as system-observer or opengl), but access is controlled by apparmor (which i suppose you don't have)
<thresh> thanks pstolowski
<thresh> I do have apparmor though, and aa-status reports VLC as enforced mode, as well as ps auxZ: snap.vlc.vlc (enforce)          thresh     70717 24.0  0.4 1002360 71556 pts/1   Sl+  18:09   0:00 /snap/vlc/1049/usr/bin/vlc --config=/home/thresh/snap/vlc/common/vlcrc
<mvo> cachio: I have not investigated, just noticed in recent PR runs
<cachio> mvo, ok, your PRs right?
<cachio> I am gonna take a look
<pstolowski> thresh: do you have vlc's opengl plug connected?
<thresh> pstolowski, yes
<mup> PR snapcraft#2846 opened: base plugin: use shlex quoting for logged command in run() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2846>
<pstolowski> thresh: opengl interface gives access to portion of hostfs - see https://github.com/snapcore/snapd/blob/702a637803b1da7f55596e6de3d76057929e5f78/interfaces/builtin/opengl.go#L38
<thresh> pstolowski, I can reproduce the same behaviour e.g. with "jq" snap, which doesnt have any plugs
<pstolowski> thresh: do you mean the snap can access entire var/lib/snapd/hostfs ?
<thresh> and this doesnt really explain why opengl plug allows access to /data/1.mkv in my case
<thresh> well, rather /var/lib/snapd/hostfs/data/1.mkv
<thresh> I mean, it's probably due to debian, and confinement being not full
<thresh> but I'd rather like to understand what exactly causes that
<mvo> cachio: yeah, it may well be it all real, i was too busy to check
<cachio> zyga, could you please take a quick look to #7877
<mup> PR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>
<cachio> it is failing in many prs
<pstolowski> thresh: most likely yes.. i cannot confirm this observation with ubuntu. could you please show the output of:snap debug confinement
<pstolowski> thresh:  snap debug confinement
<pstolowski> thresh: and 'snap debug sandbox-features'
<thresh> pstolowski, https://code.videolan.org/snippets/1118 there you go
<cjp256> anyone have a good example on how to configure opengl for `classic`?
<cjp256> i built an opengl app that just works without any special casing on my nvidia graphics system, but fails on intel.   Interesting that nvidia just works in the classic case?
<pstolowski> thresh: right. that's it
<pstolowski> thresh: on ubuntu it is strict, and for apparmor it's apparmor:             kernel:caps kernel:dbus kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default support-level:full
<pstolowski> thresh: and also confinement-options:  classic devmode strict (yours is missing strict)
<thresh> right, so the differences are: missing kernel:dbus, and policy:downgraded vs policy:default
<thresh> there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500 but that seems to be forgotten, too
<cjp256> zyga: ^ maybe you have some thoughts wrt opengl? :D
<pstolowski> cjp256: zyga is off this week; perhaps mborzecki ? ^
<mborzecki> hm hm?
<cjp256> ah, thanks!
<mborzecki> cjp256: does the snap include relvant mesa libs and drivers?
<cjp256> it does not (yet) - but I assume it should, and should do something like found https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L81
<cjp256> while I'm doing this for specific snap right now, my ultimate goal is to add an "opengl" extension which should just work for classic or strict
<cjp256> though it was interesting that without any mesa stuff, nvidia worked
<pstolowski> thresh: right.. and the last comment there is from zyga.. he may know more where we are with this, but as i just said, he is off
<mborzecki> cjp256: nvidia is handled slightly differently, especially for confined snaps
<mborzecki> cjp256: fwiw that should be transparent for the snap
<cjp256> yeah, this one is classic (alacritty terminal).
<cjp256> the mesa packages should also be staged with classic, correct? don't attempt to use the host's?
<mborzecki> cjp256: looked ad the code again, for classic we don't set up anything nvidia specific, it's only done when snap is confined, but mesa should be part of the snap in both scenarios
<mborzecki> wish we had some time allocated for the gpu support proposal zyga had, but maybe next cycle
<mborzecki> cjp256: if you have thoughts/ideas feel free to review https://forum.snapcraft.io/t/gpu-support-proposal/11247/13 and share them
<cachio> pstolowski, could you take a quick look to #7877 please?
<mup> PR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>
<cjp256> ah, was not aware of that.  thanks mborzecki :)
<cachio> this is constantly failing on master
<pstolowski> cachio: sure
<cachio> pstolowski, thanks
 * cachio lunch
<pstolowski> cachio: a general question there, i'm confused by this change, need more info. if you can provide a more elaborate description it would be super helpful (the sentence "The idea os this test is the rsyslog service when it does not exist." needs fixing)
<tomwardill> hello! Store team here, downloads are currently having a bad time, and you might get errors. We're looking at it :)
<cachio> pstolowski, sure
<pstolowski> cachio: thanks!
<cachio> pstolowski, yaw
<tomwardill> downloads should now be working again!
<roadmr> \o/
<cachio> pstolowski, description updated
<pstolowski> ty
<pstolowski> cachio: the description is fine. have you seen my reply re uc18?
<cachio> pstolowski, yes, I am making hte change
<pstolowski> cachio: i'm about to EOD but don't want to block this PR
<cachio> 1 sec
<cachio> pstolowski, nice, thanks
<pstolowski> ok
<pstolowski> cachio: i can approve, just push the change to limit it to uc18
<pstolowski> before merging
<cachio> pstolowski,  pushed
<pstolowski> k
<vidal72[m]> why in snap users aren't allowed to manually connect slots that aren't declared in manifest?
<cachio> pstolowski, is it ok there or it is better to put is at the begining of the prepare phase?
<cachio> perhaps that's more clear
<vidal72[m]> when some slot is missing and snap maintainer is afk then it's a dead end...
<pstolowski> vidal72[m]: well, that's deliberate, snaps must know what they need and must be upfront about that. otherwise people would start connecting random slots in a hope of getting a broken snap to work. if a snap is missing a slot it should have, it's a bug of the snap like any other bug..
<pstolowski> cachio: yes i think beginning would be better
<pstolowski> cachio: also made one small remark
<vidal72[m]> pstolowski: yes but the bug remains unfixable by user if publisher doesn't cooperate
<cachio> pstolowski, nice, already pushed the change
<cachio> pstolowski, thanks for the review!!!
<cachio> pstolowski, thanks for the +1
<cachio> I'll merge it once it is in gree
<cachio> n
<pstolowski> vidal72[m]: yeah, but that's no different than any other software bug. what you propose has secruity implications. nb, you can try repack that snap yourself and change its manifest, then install it with --dangerous
<cachio> see you tomorrow
<pstolowski> yep, eod, cu!
<mup> PR snapd#7877 closed: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>
<bdx> hello
<bdx> I have just registered the snap name "munge"
<bdx> here is the repo for the snap https://github.com/omnivector-solutions/snap-munge
<bdx> Omnivector is going to be maintaining this snap
<bdx> Can I request an approval on the name please?
<bdx> thanks!
<bdx> (the snap store wont let me push to "munge" until its approved by someone)
<roadmr> hi bdx
<bdx> roadmr: how's it going?
<roadmr> bdx: to be clear, are you as a snap developer going to be maintaining the snap, or do you envision transferring it to another Omnivector account?
<bdx> the https://github.com/omnivector-solutions github account is where it will live as far as I can see
<bdx> there will be others that contribute to the project, but the upstream will always remain https://github.com/omnivector-solutions/snap-munge
<roadmr> bdx: right, I'm thinking in terms of snap store accounts here
<bdx> ahh yes, I dont think I have created a snap store account for omnivector yet
<roadmr> bdx: and no worries, we can approve for your account and then transfer to a more project-centric account
<roadmr> (if desired, of course)
<bdx> ok, I see
<bdx> should I just create the omnivector snap store account now in that case?
<roadmr> bdx: you could, and then I can transfer the name (which I've just granted to you anyway).
<roadmr> bdx: the typical pattern is for the snap to be registered under an e.g. "omnivector" account (for the org/project) which is tied to an e-mail address controlled by the project itself, and then individual people (e.g. you) are attached to the snap as collaborators
<bdx> ahh I see - I was just going to ask abou thtat
<roadmr> bdx: this helps in the case of a snap maintainer not being able to maintain the snap for some reason - it can then be transferred away from that person but it's easier if the transfer is avoided altogether :)
<bdx> entirely - is there a way for me to create the "omnivector" org in the snap store?
<roadmr> bdx: there's no concept of organizations in the snap store :( what you'd do is register an "omnivector" developer account (i.e. set that as the username)
<roadmr> bdx: it does have to have an e-mail address different from yours, though
<bdx> ok, np
<bdx> so, the snapstore wants to use my ubuntu one user
<bdx> should I create the ubuntuone user "omnivector" then
<roadmr> bdx: yes, you'd need to create an altogether new ubuntuone user :/ sorry for the extra hoops
<bdx> roadmr: np
<bdx> roadmr: I've created a snapstore user "omnivector-solutions"
<bdx> is it possible for you to transfer the registered name to this user?
<roadmr> bdx: I'll do so right away :)
<roadmr> bdx: done!
<bdx> roadmr: thats awesome! many thanks!
<roadmr> np, happy to help :)
<bdx> roadmr: I was able to upload a release to stable and install from the snap store!
<bdx> one small quirk ....
<bdx> I think its related to the build functionality
<bdx> If I click into the "build" tab in the web ui
<bdx> I am presented with a page that asks me to login with github
<bdx> after I login with github I am redirected to the jamesbeedy snapstore account
<roadmr> bdx: hmm.
<bdx> so, I get here https://imgur.com/a/HfjbnBJ
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<roadmr> bdx: I'm not super familiar with the build service :/ not sure how it establishes who you are from your github login
<roadmr> oh but that says you're omnivector, right?
<bdx> yeah
<bdx> see in the img ^ it says omnivector
<bdx> but when I click the login weith github button
<bdx> it seems to login my jamesbeedy user https://imgur.com/a/lwQZ6Hk
<bdx> either way, not a big deal for me
<roadmr> oh I see
<bdx> just thought I would mention it
<roadmr> right, we'd have to ask the build service folks, most of them in Europe so probably sleeping now heh
<bdx> yeah no worries
<bdx> I can file a bug for it
<bdx> roadmr: thanks again for your help here
<roadmr> np
<roadmr> build service issues here: https://github.com/canonical-web-and-design/snapcraft.io/issues
<mup> PR snapd#7927 opened: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
<mup> PR snapcraft#2847 opened: Catkin plugin: consider only 'local' workspaces <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2847>
<bdx> I have a few questions about socket-directories using the content interface
<bdx> I have one snap that provides a socket-directory plug https://paste.ubuntu.com/p/N7wchfdYhM/
<roadmr> bdx: (in case you don't get a reply here, you can always post in the forum :) a bit easier for people to see that asynchronously)
<bdx> ok, will do - thx
<bdx> we can see the socket that the munge process creates here https://paste.ubuntu.com/p/FwvQ7JQNZw/ in SNAP_DATA
<bdx> I create another snap to test with munger
<bdx> https://paste.ubuntu.com/p/GtxZkyy9Dq/
<bdx> ^I have one snap that provides a socket-directory slot*
<bdx> the other snap creates the plug
<bdx> I install both of the snaps and connect the content interface plug of one to the content-interface slot of the other https://paste.ubuntu.com/
<bdx> https://paste.ubuntu.com/p/qhrQQGKFq3/
 * cachio eod
<bdx> once both the snaps are connected, I can see the socket in the snap that creates it, but I can't see my socket in the snap that has the consuming plug https://paste.ubuntu.com/p/6tJPVs7x9s/
<bdx> err .. that didn't come across so well
<bdx> I've rephrased it a bit on discourse here https://forum.snapcraft.io/t/the-content-interface/1074/9?u=jamesbeedy
<mup> PR snapd#7928 opened: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7928>
<mup> PR snapd#7926 closed: cmd/snap-bootstrap: xxx todos about kernel cross-checks <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7926>
#snappy 2019-12-18
<mup> PR snapd#7917 closed: snap-bootstrap: trigger udev for new partitions <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7917>
<mup> PR snapd#7919 closed: snapstate: do not try up update bootloader in ephemeral mode <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7919>
<mup> PR snapd#7920 closed: snapstate: do not try to detect rollback in ephemeral modes <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7920>
<mup> PR snapd#7929 opened: boot: always return the trivial boot participant in ephemeral mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7929>
<ctOS> Hi. Iâve installed Firefox via Snap on Fedora 31. Iâve go a 4K display. The mouse cursor is really small inside the Firefox window and the UI font is monospace. Any ideas on how to fix it?
<mvo> hey ctOS, we have some people that might be able to help but it's a bit early in their timezone, the should be around in 2-3h here, might be worth checking in again then
<mup> PR snapd#7923 closed: snap-bootstrap: mount filesystems after creation <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7923>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mvo> mborzecki: how are you?
<mborzecki> mvo: good, i see you've been landind stuff since 6am? :)
<mvo> mborzecki: yeah, deadlines :/
<mvo> mborzecki: but good progress, so I'm quite happy
<mup> PR snapd#7930 opened: run-checks: complain about MATCH -v <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7930>
<mvo> mborzecki: \o/
<mup> PR snapd#7928 closed: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7928>
<mup> PR snapd#7931 opened: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
<mvo> mborzecki: hahaha - 7930 seems to be working!
<mvo> mborzecki: it's *failing* and it looks like the failure is real \o/
 * mvo hugs mborzecki 
<mborzecki> mvo: hah, looks like i haven't updated my master before pushing the branch
<mborzecki> at least we know it works ;)
<mvo> mborzecki: it's a new thing, I think it got pulled in last night/yesterday
<mvo> mborzecki: so really cool that we already found a new incorrect use of this
<mup> PR snapd#7913 closed: boot,bootloader: extract kernel in makeBootable20RunMode  <UC20> <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7913>
<mup> PR snapd#7908 closed: [RFC] boot,devicestate: update modenv and extract kernel <UC20> <Created by cmatsuoka> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7908>
<mup> PR snapd#7932 opened: devicestate: request reboot after successful doSetupRunSystem() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7932>
<mvo> I think that was the last uc20 PR to make seeding work
 * mvo double checks with the WIP branch
<pstolowski> morning
<mvo> hey pstolowski
<pedronis> mvo: hi, ah, you closed 7913,  do we still need to extract the kernel?
<mvo> pedronis: not for the cheat we do
<mvo> pedronis: when we go all the way to uc20 single-kernel name we just revert https://github.com/snapcore/snapd/pull/7931
<mup> PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
<pedronis> mvo: what grub.cfg do we use now?
<pedronis> for run
<mvo> pedronis: the one from uc16
<mvo> pedronis: with updated label, it's in the 20/edge channel of pc
<pedronis> ah
<mvo> pedronis: https://github.com/snapcore/pc-amd64-gadget/blob/20/grub.cfg-normal
<pedronis> that's the part I didn't understand, we use the new label?
<mvo> pedronis: correct, we use "set label=ubuntu-data"
<mvo> pedronis: and we also set snapd_recovery_mode=run
<pedronis> ok
<mvo> pedronis: beside that it's unchanged because we can reuse the grubenv
<pedronis> mvo: I actually made good progress refactoring boot but there was some preexisting messiness that also needs to be cleaned up
<pedronis> also I (re)discovered but BootParticipant probably only need SetNextBoot
<pedronis> our current code is kind of slightly silly in various ways
<mvo> pedronis: heh, great!
<mvo> pedronis: I also have good news, xnox saw a fully seeding system last night
<mvo> pedronis: with my core20-wip branch based snapd snap
<pedronis> great
<pedronis> mvo: btw, when it doesn't annoy current PRs can we move MakeBootable etc to mkbootable.go
<mvo> pedronis: sounds great
<pedronis> boot.go is not big, but is a bit of a kitchen sink atm
<mvo> pedronis: lol - it surely is!
<pedronis> and I'm adding more to it in my PRs
<mborzecki> pstolowski: pedronis: hey
<mborzecki> https://github.com/snapcore/snapd/pull/7906 needs a 2nd review and we can land it
<mup> PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
<mup> PR snapd#7907 closed: snap-bootstrap: append new partitions <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7907>
<mup> PR snapd#7933 opened: snapd.core-fixup.sh: do not run on UC20 at all <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7933>
<mvo> ok - that was really the last one I think
<ctOS> Hi. Iâve installed Firefox via Snap on Fedora 31. Iâve go a 4K display. The mouse cursor is really small inside the Firefox window and the UI font is monospace. Any ideas on how to fix it?
<mborzecki> ctOS: is that a wayland session?
<ctOS> mborzecki: no, x11 kde
<ctOS> looks the same in gnome, though.
<mborzecki> ctOS: you can try that for the fonts https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484/24
<mborzecki> ctOS: but the cursor thing is weird, probably some trouble accessing the x11 cursor or it's not picking up dpi correctly
<ctOS> the mouse cursor looks different (like the default one on Windows, schmaybe) but its also half the normal size (which is more of a problem.
<mborzecki> ctOS: sounds like this problem: https://forum.snapcraft.io/t/small-cursor-in-snap-apps-on-hidpi-display/5220 maybe the snap was not fixed
<ctOS> mborzecki: deleting the fontcache didnât fix the fonts. fonts have loaded for me, but its an unexpected monospace font everywhere.
<mborzecki> ctOS: you can try to run this: `snap run firefox --shell` and then `fc-match 'sans serif'` (or what is the kind of typeface that you expect)
<ctOS> mborzecki: /var/lib/snapd/snap/firefox/287/bin/desktop-launch does not contain this line https://github.com/ubuntu/snapcraft-desktop-helpers/commit/da4d8f878eaeb40c1788789cd034b7142f7d6749
<ctOS> so it appears not to have received that fix.
<ctOS> mborzecki: what does --shell do? should I get a new shell or something to run the second command?
<mborzecki> popey: ^^ anyone can file this with mozilla?
<mborzecki> ctOS: it starts a new shell with the same system view as snap has
<pstolowski> looking at https://github.com/snapcore/snapd/pull/7906
<mup> PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
<ctOS> mborzecki: I donât see anything opening other than firefox when I run it.
<mborzecki> ctOS: duh, `snap run --shell firefox` sry
<ctOS> mborzecki: running it in that shell I get "bash: fc-match: command not found". works in the normal shell and returns DejaVu Sans.
<ctOS> mborzecki: fc<tab> in the Snap shell suggests "fc fc-cache-v6  fc-cache-v7"
<mup> PR snapd#7934 opened: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
<pedronis> pstolowski: ^
<pstolowski> pedronis: thank you
<pstolowski> #7906 +1
<mup> PR #7906: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7906>
<pedronis> thx
<mborzecki> ctOS: had to do some local tweaking, try this in the snap shell: https://paste.ubuntu.com/p/wTw2SG4Pgz/
<mborzecki> ctOS: returns the same font inside and outside of snap shell here on arch
<ctOS> mborzecki:  no go, $SNAP is empty
<ctOS> oh, /var/lib/snapd/snap/
<mborzecki> ctOS: you need to do `snap run --shell firefox` and then run those lines inside that shell
<mborzecki> ctOS: outside of snap shell you can simply run `fc-match <your-typeface>`
<mup> PR snapd#7906 closed: o/devicestate,o/snapstate: move the gadget.yaml check <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7906>
<ctOS> mborzecki: I just realized that. different output. one sec
<ctOS> mborzecki: FreeMono.ttf: "FreeMono" "Regular"
<ctOS> mborzecki: plus these errors https://paste.ubuntu.com/p/Smsh2ZP9sT/
<ctOS> mborzecki: outside snap shell itâs: DejaVuSans.ttf: "DejaVu Sans" "Book"
<pedronis> degville: I looked at your last tweaks to the intro to Assertions, +1, thank you
<pedronis> degville: as I said we should also port that to the glossary
<degville> pedronis: will do, thanks for the review.
<popey> mborzecki: I'd ping kenvandine or oSoMoN for Mozilla things
<mborzecki> heh, firefox has no contact info either, no clue where users can report any problems
<mborzecki> oSoMoN: kenvandine: can you ping mozilla to include the fix for cursors: https://forum.snapcraft.io/t/small-cursor-in-snap-apps-on-hidpi-display/5220/6 ?
<mborzecki> ctOS: can you run fc-match inside the snap shell but with FC_DEBUG=4 this time and post the output somewhere?
<ctOS> mborzecki: here you go https://paste.ubuntu.com/p/t995Sm9H8G/
<mborzecki> ctOS: hm that's surprisingly short, can you run `ls /usr/share/fonts/TTF/Deja*` inside the snap shell? does it list anything?
<ctOS> mborzecki: no, but `/usr/share/fonts/dejavu/*` does.
<ctOS> mborzecki: here is `ls /usr/share/fonts/*/*` https://paste.ubuntu.com/p/4X3VyqKF43/
<mvo> 7918 needs a second review, should be a simple one
<mborzecki> ctOS: ok, can you run `$SNAP/usr/bin/fc-cache -v` inside the snam the same way you ran fc-match (same LD_LIBRARY_PATH exports), check whether it picked up /usr/share/fonts/dejavu and run fc-match again?
<ctOS> mborzecki: Re-scanning /usr/share/fonts: /usr/share/fonts: error scanning \n /var/cache/fontconfig: not cleaning unwritable cache directory \n /snap/firefox/287/usr/bin/fc-cache: failed
<mborzecki> ctOS: and if you run fc-cache -f -v ?
<ctOS> mborzecki: https://paste.ubuntu.com/p/dpz4x3Q2VS/
<mborzecki> ctOS: not sure why it's not building the cache in $HOME/.config/fontconfig, but this is as far as my fontconfig knowledge goes, i would suggest opening a forum topic on https://forum.snapcraft.io with a screenshot, make sure to include the output from fc-match
<mborzecki> perhaps someone from the desktop team will have ideas
<ctOS> mborzecki: I tried `sudo setenforce 0` on a hunch, but made no difference. `$HOME/.config/fontconfig` is also empty outside the snap shell.
<mborzecki> ctOS: afaik selinux wouldn't matter, you're probably running as unconfined_t anyway
<mborzecki> mvo:  little tweak in https://github.com/snapcore/snapd/pull/7918#discussion_r359275116
<mup> PR #7918: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7918>
<ctOS> mborzecki: thanks for all your time and troubleshooting help!
<mborzecki> ctOS: np, these desktop things are ridiculously fragile
<mvo> mborzecki: in a meeting right now, feel free to tweak and push
<mup> PR snapd#7935 opened: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7935>
<pedronis> mvo: mborzecki: Chipac: ^
<pedronis> Chipaca: ^ (sorry)
<Chipaca> pedronis: ack
<pedronis> Chipaca: it touches policy, also with new InUse internals it should be easier to attack the TODO in policy about it, I haven't done so yet though
<mvo> pedronis: yay!
<Chipaca> pedronis: nice
<pedronis> mvo: there is more to it (wip), but that's already quite big and slightly convuluted, though I think the direction is good, apart some complexity a bit not related to the main changes
<mvo> pedronis: ok, I will look at it today
<mvo> pedronis: my uc20 bits are all proposed now so I should have time
<mvo> (still want to start with spread stuff though)
<pedronis> mvo: I think if the plan works as I see it, implementing boot state for run for UC20 on top of this, once we understand what we want and grub.cfg, should be a couple of days
<mvo> pedronis: amazing! let's aim for this before CPT
<mvo> pedronis: should I add uc20 to 7935?
<pedronis> mvo: yes
<mvo> done
 * pstolowski lunch
<vidal72[m]> mborzecki: fyi there was a lot of changes done to firefox like update to core18 recently however they are available only in beta channel atm and probably will be in 72 stable release
<vidal72[m]> https://hg.mozilla.org/mozilla-central/rev/606408df5b4d712c7bf4e80621dd145f1cd82940
<vidal72[m]> pstolowski: what security implications? User can install snap with --dangerous, devmode, can disable apparmor on system but can't add permission to snap...
<vidal72[m]> mborzecki: also bugs in ff snap should go to bugzilla afaik
<mup> PR snapd#7929 closed: boot: always return the trivial boot participant in ephemeral mode <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7929>
<pedronis> mborzecki: https://github.com/snapcore/snapd/pull/7921/commits/46fe5b30aba428f85c94f77e659c7aa508b12e00  also UC20 is not a reason not to have unit tests if they make sense (we might have UC20 todos about going incremental, but testing is important)
<mup> PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>
<mborzecki> pedronis: the travis job is already running, but i can open a follow-up PR adding those tests
<pedronis> mborzecki: there are tests
<pedronis> mborzecki: that link points to tests
<pedronis> am I super confused ?
<pedronis> mvo added them
<mvo> pedronis: uh, maybe I mixed something up
<mborzecki> pedronis: right, thought you're referencing to the comment i made about special casing when there's no base in the model
 * mvo will check later, lunch first
<pedronis> mborzecki: ah, I misunderstood
<pedronis> mborzecki: at test would be good for that
<pedronis> mborzecki: I thought you were referring the whole function
<mborzecki> pedronis: no worries, if the current job is successful we may land it and i'll open a PR adding that missing bit
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7930 ?
<mup> PR #7930: run-checks: complain about MATCH -v <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7930>
<mborzecki> pstolowski: and while at it, maybe this one too: https://github.com/snapcore/snapd/pull/7922
<mup> PR #7922: packaging, tests: stop services in prerm <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7922>
<mup> PR snapd#7936 opened: tests: unmount automounted snap-bootstrap devices <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7936>
<kenvandine> mborzecki, popey, oSoMoN:  that should be fixed in beta
<mborzecki> kenvandine: good to know, thanks!
<mborzecki> ctOS: ^^
<kenvandine> Mozilla has updated the snap to use the gnome-3-28 extension in beta
<kenvandine> and core18
<kenvandine> i haven't tried it yet though
<mborzecki> hm maybe the fonts problem will go away too then
<pstolowski> vidal72[m]: hey, i meant people trying to connect random slots to get such snap working, copying random snap connect receipes from the internet without realizing what they are doing etc. snap can be broken in many ways, missing slot is just one of them. if publisher is not cooperating and fixing/keeping his snaps updated, then it's a bad publisher. but feel free to open a forum topic, it's just my personal view
<abeato> mvo, hey, are proxy settings actually applied for 'snap download'? It seems to work for 'snap install', but not when downloading
<pstolowski> mborzecki: will do
<mup> PR snapd#7930 closed: run-checks: complain about MATCH -v <Simple ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7930>
<mborzecki> pstolowski: thanks
<mup> PR snapd#7937 opened: boot,o/snapstate: SetNextBoot/LinkSnap return whether to reboot, use the information <Created by pedronis> <https://github.com/snapcore/snapd/pull/7937>
<ijohnson> morning folks
<mup> PR snapd#7858 closed: tests: also check nested lxd container <Test Robustness> <Created by anonymouse64> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7858>
<ijohnson> who manages mup? I noticed the other day that when a new issue is created in a github issue such as in pc-amd64-gadget repo, the link that mup posts is wrong, it has "github.com/<org>/<repo>/issue/<num>" when it should be "github.com/<org>/<repo>/issues/<num>"
<pstolowski> ijohnson: Gustavo
<ijohnson> niemeyer: can you change the links that mup outputs for new github issues filed? see my previous comment above, thanks
<ijohnson> thanks pstolowski
 * cachio lunch
<mup> PR snapd#7918 closed: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7918>
<mup> PR snapcraft#2848 opened: common: generate run scripts which can execute independently <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2848>
<pedronis> mborzecki: mvo: +1 to #7921 but the extra suite field is probably not needed
<mup> PR #7921: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>
<niemeyer> ijohnson: Ah, sure, thanks. Do you have a sample message?
<ijohnson> niemeyer: sure I saw one yesterday I think, let me look
<ijohnson> mup> Mup Pet Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#30: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<ijohnson> niemeyer: ^
<niemeyer> Thanks!
<ijohnson> np, happy to help
<niemeyer> pc-amd64-gadget#30
<mup> Issue pc-amd64-gadget#30: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mvo> pedronis: thanks! I can kill it
<mborzecki> mvo: maybe land the PR and cleanup in a followup?
<mborzecki> (it's green right now)
<mvo> matiasb_: works for me
<mvo> mborzecki: works for me
<mvo> matiasb_: sorry, wrong tab-complete
<mvo> mborzecki: in a meeting right now, feel free to take it if its trivial and you have cycles otherwise I will in a bit
<pedronis> mvo: +1 to #7931 with some comments, let me know if they are unclear
<mup> PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
<mvo> pedronis: thanks! looking
<pstolowski> pedronis: updated #7686
<mup> PR #7686: systemd: handle preseed mode <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
<pedronis> pstolowski: thx, I'll try to look at it in a bit
<mup> PR snapd#7921 closed: devicestate: run boot.MakeBootable in doSetupRunSystem <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7921>
<mvo> pedronis: comments make sense I think, will fix in a wee bit
<mup> PR snapd#7938 opened: devicestate: advoid adding mockModel to deviceMgrInstallModeSuite <Created by mvo5> <https://github.com/snapcore/snapd/pull/7938>
<mup> PR snapd#7936 closed: tests: unmount automounted snap-bootstrap devices <Simple ð> <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7936>
<mup> PR snapd#7939 opened: boot,o/devicestate: refactor MarkBootSuccessful over bootState <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
<pedronis> mmh, conflicts
<cmatsuoka> anyone else getting schedule test errors in master?
<cmatsuoka> invalid  distance for schedule "mon1-tue2,10:00" with last refresh "2017-02-06 10:00", now "2017-02-07 11:00", expected 647h-647h, got 648h0m0s, date 2017-03-06 10:00:00 -0300 -03
<cmatsuoka> lunch, bbi30min
<pedronis> pstolowski: did anohter pass on #7686, some small issues
<mup> PR #7686: systemd: handle preseed mode <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
<pstolowski> pedronis: thanks. yes, i can't believe pre-bake was still lurking, grr
<mvo> very silly question - I'm writing a spread test right now and I get dropped into a debug/fail shell in spread when I run "REBOOT" with exitcode 213
<mvo> hm, maybe my spread git is too old
 * mvo update to latest master
<mvo> cachio: we will need to drive google vms very soon in a way that enables uefi (maybe it is already enabled even?). do you think you could have a look what (if anything) we need to do to get a machine that has uefi enabled?
<cachio> mvo, I'll read a bit the documentation
<mvo> ta
<cachio> so far uefi should not be enabled
<mvo> cachio: ok
<mvo> cachio: will enable require a spread change?
<cachio> mvo, I think we will need to update spread
<cachio> mvo, yes
<cachio> the change is simple because it is a parameter when the instance is created
<cachio> I'll imeplmeent the change, is is a new parameter in the system
<pstolowski> pedronis: updated, thanks again
<mvo> cachio: ta
<cachio> mvo, there is also a way to create the image with that enabled by default
<cachio> I think this option is betetr
<mvo> cachio: nice!
<mvo> cachio: I did something hackish for qemu https://github.com/snapcore/spread/compare/master...mvo5:spread-with-uefi?expand=1
<mvo> cachio: and here is my hackish https://github.com/snapcore/snapd/commit/747d06a62deb5069a5ea695b03615a29d2e8bba9 (it's part of https://github.com/snapcore/snapd/compare/master...mvo5:core20-wip-2-spread?expand=1 which merges all of my uc20 prs) but it's not working yet but might be interessting to run against a google backend with uefi (not working because of qemu spread backend
<cachio> mvo, on gce there are 2 ways
<cachio> for customized images like ours
<cachio> it is possible to define is during their creation
<mvo> cachio: cool
<cachio> for predefined images during creation of the instance
<mvo> cachio: I get dinner now, will check back in a bit
<cachio> sure
<mvo> cachio: also very strane, looks like the ubuntu-16.04-64 image does not boot in my uefi qemu, so I changed the core20 base (that does the reflash) to 18.04 locally
 * mvo is really off now
<cachio> mvo, is it needed virtualization enabled on that image?
<pstolowski> eod. happy holidays pedronis !
<pedronis> pstolowski: thx
<pstolowski> cu
<mup> PR pc-amd64-gadget#31 opened: grub.cfg: switch to new style kernel_status failover handling <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/31>
<mvo> cachio: this does not need anything special beside uefi, it's the same style of test as uc16/uc18 in spread
<cachio> mvo, I am creating an image
<mvo> cachio: cool! thanks
<cachio> mvo, ubuntu 18.04
<cachio> should be ready in 5/10 minutes
<mvo> cachio: once you have a name, please let me know and I update my spread config. no rush, I will probably work on this full steam in my morning
<mvo> but not that much tonight
<mup> PR snapd#7933 closed: snapd.core-fixup.sh: do not run on UC20 at all <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7933>
<cachio> mvo, you can use image: ubuntu-1604-64-uefi-enabled
<mvo> cachio: \o/ thanks
<cachio> do you need an image for xenial as well?
<cachio> mvo, sorry
<cachio> hte image is -> image: ubuntu-1804-64-uefi-enabled
<cachio> xenial is not created yet
<mvo> cachio: ubuntu-18.04-64 or 1804 ?
<mvo> cachio: I don't need the 1604 I think
<cachio> mvo, you should add this to the spread.yaml
<cachio>             - ubuntu-18.04-64-uefi-enabled:
<cachio>                 image: ubuntu-1804-64-uefi-enabled
<cachio> that works for me
<mvo> cachio: cool, trying now
<mvo> cachio: it may hang on reboot, so be prepared to kill a machine :/
<cachio> mvo, nice
<mvo> cachio: I don't think the reboot stuff is fully debugged yet
<cachio> mvo, no problem
<mvo> cachio: ta
<cachio> do you have a name?
<cachio> for the instance?
<cachio> mvo, I can share the serial output
<mvo> cachio: one sec, let me find it
 * cmatsuoka very curious about the results
<cachio> mvo, did it work?
<mup> PR snapd#7940 opened: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
<mvo> cachio: no, it looks like it does not connect
<cachio> mvo, I could connect
<cachio> and open a shell device
<cachio> there
<mvo> cachio: is it still in 18.04?
<mvo> cachio: I asked it to reboot to reflash
<cachio> mvo, https://paste.ubuntu.com/p/VkXVV9s38J/
<cachio> this is that validation which I ddi
<cachio> did
<mvo> cachio: aha, ok
<cachio>             - ubuntu-18.04-64-uefi-enabled:
<cachio>                 image: ubuntu-1804-64-uefi-enabled
<cachio> using this configuration in the spread.yaml
<mvo> cachio: yeah, this works, just my core20 test is not yet working
<mvo> cachio: you may need to kill the instance
<mvo> cachio: aha, I think it got killed now
<mvo> cachio: spread timed out
<cachio> do you have the name of the instance?
<cachio> mvo, it is automatically killed after 1h30m aprox
<cachio> in case it is not automatically discarded
<cachio> be spread
<mvo> ok
<mvo> thanks
<mup> PR snapd#7932 closed: devicestate: request reboot after successful doSetupRunSystem() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7932>
 * cachio afk
<mup> PR snapd#6108 closed: many: apparmor support for non-AA rpm distros <:birthday:> <Decaying â¢> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
<mup> PR snapd#7941 opened: snap-bootstrap: read only stdout when parsing the sfdisk json <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7941>
<cmatsuoka> my link is very spotty this afternoon :(
<cmatsuoka> couldn't reach github, let's see if it's stable now...
<mvo> cmatsuoka: once it's back would be great if you could check if we regressed since this morning
<mvo> cmatsuoka: re uc20
<mvo> cmatsuoka: with master+PR#7931 it should still work
<cmatsuoka> mvo: will check that now, just a sec
<mvo> cmatsuoka: no rush
<mvo> cmatsuoka: with https://github.com/snapcore/snapd/compare/master...mvo5:core20-wip-2-spread?expand=1 eventually (still a lot of open issues) we can automate this
<mvo> cmatsuoka: but it needs the kernel on edge first
<cmatsuoka> I want to check out that branch before I lose internet again :)
<mvo> cmatsuoka: and we need 7931 in master
<mvo> cmatsuoka: and then *maybe* it will work in google (qemu backend needs a patch in spread)
<mvo> cmatsuoka: meh, it won't work because xnox needs to finish shutdown first, that hangs right now
<mvo> cmatsuoka: but we are kinda close :)
<mvo> (ish)
<mvo> maybe close is overstating it
<cmatsuoka> Pft, "This site canât be reached - github.com refused to connect."
<cmatsuoka> It looks like some cgnat proxy mess, but it affects two different ISPs
<cmatsuoka> very strange
<cmatsuoka> ok, #7931 checked out
<mup> PR #7931: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7931>
<mup> PR snapd#7942 opened: Nvidia driver microversion <Created by zhuker> <https://github.com/snapcore/snapd/pull/7942>
 * cachio afk
<cmatsuoka> mvo: is master+7931 supposed to work to the end of install stage without manual intervention?
<cmatsuoka> mvo: does it also require changes in the initramfs side? because for me it worked like the previous one, i.e. needs help to create partitions
<cmatsuoka> (using current core, gadget and kernel snaps)
<cmatsuoka> let's see what's in 7931...
<mwhudson> how is parallel installs for classic snaps coming along?
<mup> PR snapcraft#2849 opened: rust plugin: split RUSTUP_HOME and CARGO_HOME <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2849>
<ijohnson> mwhudson: o/ it should be working in edge at least, possibly even stable IIRC
<ijohnson> still experimental however
<mwhudson> ijohnson: oh!
<mup> PR snapd#7938 closed: devicestate: avoid adding mockModel to deviceMgrInstallModeSuite <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7938>
<ijohnson> mwhudson: ah actually looks like it will be next stable I think, so 2.43
<mwhudson> ijohnson: so snap refresh --beta core and i can try it?
<ijohnson> mwhudson: yes
<ijohnson> I have been using it the past few weeks with your go snap to much delight :-)
<ijohnson> note that aliases don't work, so you need to unalias things before the go snap specifically works
<mwhudson> ijohnson: heh that's why i was asking
<mwhudson> ah
<mwhudson> i wanted to tweet about installing go 1.14 beta in parallel to stable
<mwhudson> is there a plan for making aliases work more smoothly?
<ijohnson> mwhudson: https://github.com/snapcore/snapd/pull/7302#pullrequestreview-310225458
<mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7302>
<ijohnson> not on the immediate roadmap unfortunately
<mwhudson> ok
<ijohnson> it's the kind of thing I think is a bit difficult to "do the right thing" automatically, but it's at least a known limitation
<mwhudson> yeah i didn't actually think about it at all before asking that question :)
<ijohnson> :-)
<mwhudson> ijohnson: https://twitter.com/mwhudson/status/1207413478404673536
<ijohnson> mwhudson: nice ð
<mwhudson> ah ffs typo
<ijohnson> ahhh haha
<ijohnson> I see it now too
<mwhudson> deleted and reposted
<ijohnson> mwhudson: did you try with beta core? or only edge?
<ijohnson> AFAIK it should be in beta
<mwhudson> ijohnson: yeah, beta
<mwhudson> oh i put edge in the tweet
<mwhudson> oh well
<mwhudson> not going to delete it again for that :)
 * ijohnson feels nervous having folks switch to snapd edge but it's just twitter so oh well
<pedronis> mwhudson: we discussed the idea that for things that are not the main instance, they would install --unaliased by default. We would also add snap install --prefer to force using the aliases if one wants to
<mwhudson> pedronis: yeah just not setting up aliases for the non-default one seems reasonable on the face of it
<xnox> ijohnson:  i've been on edge channel for months now, since had to work on uc20 =/
<mup> PR snapd#7931 closed: boot: write compat UC16 bootvars in makeBootable20RunMode <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7931>
 * ijohnson pours one out for xnox's computer 
 * ijohnson also builds a monument to xnox's computer for all the hard work on uc20 :-)
 * cmatsuoka frustrated with the unstable internet here today, maybe it's better after dinner...
<cmatsuoka> bbl
#snappy 2019-12-19
<mup> PR snapd#7916 closed: interfaces/browser-support: add more product/vendor paths <Created by Erick555> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7916>
<ctOS> Hi. I may be misunderstanding something. Why can the Firefox snap see contents of file:///home/me/Documents/ ? The :home connection is not connected to a slot. Shouldnât that  stop access?
<ctOS> Au, auto-connections and stuff. Okay, got it.
<mup> PR snapd#7941 closed: snap-bootstrap: read only stdout when parsing the sfdisk json <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7941>
<mup> PR pc-amd64-gadget#32 opened: gadget.yaml: increase default size of ubuntu-data to 3G <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/32>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> mvo: any PRs you'd like me to look at?
<mvo> mborzecki: thank you, all the criticial stuff has landed
<mborzecki> yay :)
<mvo> mborzecki: exactly
<mvo> mborzecki: and I have a (hacked) spread setup that runs hello world in uc20
<mborzecki> mvo: oh cool, as in boots into uc20 and runs a test?
<mvo> mborzecki: correct
<mvo> mborzecki: it's very raw right now (and needs a hacked spread for uefi support with qemu). but it's getting there :)
<mvo> mborzecki: I hope to proposed a slightly cleaned up version today
<mborzecki> mvo: wondering whether gcp supports booting with uefi
<mborzecki> mvo: btw. somebody is trying out gadget updates https://forum.snapcraft.io/t/gadget-schema-for-ubuntu-image-parser-might-be-broken/14723
<mvo> mborzecki: yeah, cachio explored this last night
<mvo> mborzecki: we have a ubuntu-1804-64-uefi-enabled image for this now
<mvo> mborzecki: oh, interessting!
<mvo> mborzecki: looks like we really need to take over ubuntu-image ;)
<mvo> mborzecki: or rather make it use our gadget parser
<mvo> mborzecki: but that's for later
<mborzecki> mvo: yeah, maybe, i can look into adding that to the schema
<mvo> mborzecki: if it's not too much distraction that would be nice
<mvo> mborzecki: I should be able to look at reviews today again, anything you would like me to prioritize?
<mborzecki> mvo: hopefully sil2100 is still around today ;)
<mborzecki> mvo: this one would unblock rest of snapd on core: https://github.com/snapcore/snapd/pull/7772
<mup> PR #7772: wrappers: write and undo snapd services on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
<mvo> mborzecki: cool, I have a look, this is really exctiin g for me
<mborzecki> quick errand, back in 30
<ctOS> mborzecki: (quick follow-up from yday): the beta channel resolved the font issue, but not the tiny mouse cursor.
<mvo> ctOS: nice, thanks for the update. I think for the cursor me need someone from the desktop team to help, maybe kenvandine when he is around (in the US timezone so not up yet)
<mup> PR snapd#7943 opened: tests: add core20 tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7943>
<mvo> mborzecki: when you are back - where is OFMF.fd on fedora/arch?
<mborzecki> re
<mvo> mborzecki: on ubuntu it's /usr/share/OVMF/OVFM_CODE.ms.fd
<mvo> mborzecki: but I wonder if I can build something for spread that is portable
<mborzecki> mvo: let me see
<mborzecki> mvo: ovmf /usr/share/ovmf/x64/OVMF_CODE.fd
<mborzecki> ctOS: if it's not too much hassle, can you check that the cursor fix that was linked yday is include in the firefox snap from beta channel?
<mvo> mborzecki: ta
<ackk> hi, is there any peculiar difference between the environment a snap runs in on ubuntu vs ubuntu core? I have a snap which run sshd and I can ssh in if I install it on my PC. but running it on a rpi with ubuntu core I get disconnected right away (with no error)
<ctOS> mborzecki: the patch is included in the beta (287). Iâve also double-checked that it is indeed not fixed in this version.
<mborzecki> ctOS: thank you!
<mborzecki> mvo: on fedora i have /usr/share/edk2/ovmf/OVMF_CODE.fd and there's also  /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd
<mborzecki> mvo: on arch the package is called 'ovmf', on fedora it's 'edk2-ovmf'
<mvo> mborzecki: thanks
<mvo> mborzecki: still scratching my head about how to do this in a portable way, maybe an environment is the simplest and just documenting it
<mup> PR snapd#7944 opened: test: extract code that modifies "writable" for test prep <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7944>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapd#7686 closed: systemd: handle preseed mode <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7686>
<mvo> hey pstolowski
<mvo> pstolowski: nice to see this merged!
<pstolowski> yeah!
<mup> PR snapd#7945 opened: tests: unify/rename services-related spread tests to start with services- prefix <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7945>
<pstolowski> mvo, mborzecki ^ trivial and hopefully uncontroversial
<mvo> pstolowski: nice
<mborzecki> pstolowski: +1
<pstolowski> thx
<mup> PR pc-amd64-gadget#32 closed: gadget.yaml: increase default size of ubuntu-data to 3G <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/32>
<mvo> niemeyer: when you have some spare cycles a review/feedback on https://github.com/snapcore/spread/pull/95 and https://github.com/snapcore/spread/pull/96 would be great. happy to adjust as needed. we need uefi/virtio for spread testing uc20
<mup> PR spread#95: spread: add support to define a custom bios with the qemu backend <Created by mvo5> <https://github.com/snapcore/spread/pull/95>
<mup> PR spread#96: spread: add support for system specific "flags" and use in qemu <Created by mvo5> <https://github.com/snapcore/spread/pull/96>
<pstolowski> travis is super slow.. or is it my PR?
<mup> PR snapd#7944 closed: test: extract code that modifies "writable" for test prep <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7944>
<niemeyer> mvo: Of course
<niemeyer> mvo: Is that the same thing zyga mentioned last week? I was waiting for the ping on Friday
<mvo> niemeyer: it's slightly different
<mvo> niemeyer: I think zyga wants to stop using "kvm" to launch qemu because it's ubuntu/debian specific. my bit are new features for the qemu backend, i.e. I need the ability to enable uefi/virtio for uc20 testing
<niemeyer> mvo: Ack
<mvo> niemeyer: it's not super critical, I can use my local spread for testing for now but eventually it would be nice to be able to have it as part of the default
<mvo> niemeyer: also does not affect GCE testing so no need to do a new release and all that :)
<niemeyer> Cool, thanks
<mvo> thank you!
<pstolowski> mvo, mborzecki any particular PRs you would like to land today & want reviewed?
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/7772 if you would
<mup> PR #7772: wrappers: write and undo snapd services on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
<pstolowski> sure
<mup> PR snapd#7945 closed: tests: unify/rename services-related spread tests to start with services- prefix <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7945>
<mborzecki> sil2100: hi, any chance you can take a look at this PR before the break? https://github.com/CanonicalLtd/ubuntu-image/pull/180
<mup> PR CanonicalLtd/ubuntu-image#180: ubuntu_image: update schema validator to allow gadget update specific keys & little cleanups <Created by bboozzoo> <https://github.com/CanonicalLtd/ubuntu-image/pull/180>
<sil2100> mborzecki: o/
<mborzecki> sil2100: got one more patch with nicer error messages for all validation, but no clue whether older releases of voluptous raise useful exceptions
<mborzecki> mvo: ^^
<mvo> mborzecki: nice one!
<cmatsuoka> good morning. hopefully my internet will be fast and stable today
<pstolowski> hi cmatsuoka !
<cmatsuoka> because yesterday it was just weird
<cmatsuoka> a friend of mine is moving to Canada and is selling a NUC, I'm checking if it has TPM
<sil2100> mborzecki: do you have an LP bug for the PR? Could you fill in a bug for https://github.com/CanonicalLtd/ubuntu-image/pull/180/ and add a changelog entry to it with the bug linked?
<mup> PR CanonicalLtd/ubuntu-image#180: ubuntu_image: update schema validator to allow gadget update specific keys & little cleanups <Created by bboozzoo> <https://github.com/CanonicalLtd/ubuntu-image/pull/180>
<mborzecki> sil2100: ha, there's one https://bugs.launchpad.net/ubuntu-image/+bug/1856903
<mup> Bug #1856903: ubuntu_image/parser.py Gadget YAML Definition needs updating <gadget> <Ubuntu Image:New> <https://launchpad.net/bugs/1856903>
<sil2100> mborzecki: hah, excellent
<sil2100> mborzecki: could you add a changelog entry for the change with the LP: # added?
<sil2100> mborzecki: or actually, I guess I'll just do that instead, so nevermind o/
<mborzecki> sil2100: cool, thanks!
<sil2100> mborzecki: oh, though some code-style stuff needs to be fixed first
<sil2100> mborzecki: did you run `tox` before submitting the changes? Since the qa test-suite seems to fail due to pep8 errors
<sil2100> mborzecki: example log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-sil2100-ubuntu-image-ci-deps/bionic/amd64/u/ubuntu-image/20191219_124506_43ed7@/log.gz
<mborzecki> sil2100: i run specific tests only, the whole suite never completed on my system
<sil2100> mborzecki: could you address those pep8 errors and re-push?
<mborzecki> sil2100: sure, will do
<sil2100> Thanks!
<mborzecki> sil2100: pushed
<mborzecki> mvo: have you seen something like this: https://paste.ubuntu.com/p/YcrWJxsK5d/
<mborzecki> mvo: that's core18 snapd failover, maybe systemd doesn't like that much when a service changes it's own unit file
<mvo> mborzecki: uh, haven't seen this one
<mborzecki> mvo: i can reproduce it locally
<mborzecki> mvo: https://paste.ubuntu.com/p/y2SWwD38rF/
<mvo> mborzecki: uh, so we need a new strategy for this it seems
<mvo> mborzecki: that's unfortunate
<jdstrand> mborzecki, ijohnson: hey, note, I'm just passing through in the forum (I'm on holiday). fyi since I responded to a couple of topics you responded to
<mborzecki> jdstrand: thanks!
<mborzecki> jdstrand: fyi, that library has setuid set
<jdstrand> mborzecki: yeah, that sounds a bit scary. wonder if it was copy and waste somewhere...
<jdstrand> mborzecki: it could also be an overly ambitious postinst script. grepping /var/lib/dpkg/info/* for the lib might provide a clue
<mborzecki> jdstrand: no happy postinst script, but found this in lintian/overrides: https://paste.ubuntu.com/p/k5Zprvx92V/
<mborzecki> jdstrand: and there are hooks that setup LD_PRELOAD in Xsession.d :/
<jdstrand> mborzecki: that sounds terrible
<jdstrand> mborzecki: what is shipping that?
<mborzecki> jdstrand: https://launchpad.net/ubuntu/+source/gtk3-nocsd
<jdstrand> mborzecki: look at all the lintian overrides. that is a terrible hack
<jdstrand> mborzecki: I would never want arbitrary library for my setuid binaries. ping, snap-confine, nothing
<jdstrand> mborzecki: that has to be against policy. if it isn't, it should be. at best, the packaging should put something in place that allows the user to configure setting the setuid bit, with appropriate warnings
<jdstrand> mborzecki: but not by default
<mborzecki> jdstrand: i can file a bug about it, or would you prefer to do it and include some security perspective?
<jdstrand> mborzecki: perhaps you can file a public security bug that just describes the problem wrt snap-confine, along with the lintian bits. then a member of our team will look at it
<mborzecki> jdstrand: ok
<jdstrand> it's a little more than I want to chase down while on holiday :) either a member of the team will act on it or it will be in my inbox nagging me to do something about it :)
<mborzecki> jdstrand: filed: https://bugs.launchpad.net/ubuntu/+source/gtk3-nocsd/+bug/1857022
<mup> Bug #1857022: gtk3-nocsd preloads a setuid library <gtk3-nocsd (Ubuntu):New> <https://launchpad.net/bugs/1857022>
<jdstrand> mborzecki: thanks!
<mborzecki> jdstrand: np
<kenvandine> ctOS: wayland or X?
<cachio> mvo, https://paste.ubuntu.com/p/h8t4vMYfWv/
<cachio> mvo, dd: writing '/dev/sda': No space left on device
<cachio> this is failing
<cachio> mvo, trying with a metter instance now
<mup> PR snapd#7946 opened: tests: fix partition creation test <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7946>
<cmatsuoka> cachio: it was not the problem I thought it was, it was something much simpler
<cachio> cmatsuoka, yes I saw that
<cachio> I gave +1 already
<cmatsuoka> thanks!
<cachio> mvo, well, with more disk I got this error https://paste.ubuntu.com/p/XYxQpCNKK4/
<cachio> mvo, it is needed a change in the spread.yaml
<cachio> https://paste.ubuntu.com/p/P6tbMRpxMs/
<cachio> it is needed more storage
<cachio> mvo, just changing the storage it seems to work until console conf
<cachio> mvo, this is the full log: https://paste.ubuntu.com/p/3bCZx6dDrw/
<mvo> cachio: in a meeting, will get back to you
<cmatsuoka> cachio: I wasn't completely wrong, after fixing that trivial problem the other one appears, so I'm fixing the other as well
<cmatsuoka> s/fixing/adding a workaround for/
<mvo> cachio: the full log looks kind of ok, I mean, it looks like it going into run mode eventually,
<mvo> cachio: like e.g. [   32.825784] audit: type=1400 audit(1576772640.792:12): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.pc.hook.configure" pid=1585 comm="apparmor_parser" in line 4107
<mvo> cachio: but I guess you don't get a connection to this?
<cachio> mvo, hey
<cachio> I can access to the console
<cachio> mvo, I just triggered a new run
<mvo> cachio: ok, if you have access to a debug console (you can e.g. add "systemd.debug-shell=1" in the grub commandline. then it would be nice to see the output of "snap changes" or journalctl -u snapd-seeding or snapd
<cachio> mvo, sure
<cachio> mvo, is it any way to scape from console-conf?
<cachio> escape
<mvo> cachio: I think not right now - but you should be able ssh into the instance
<cachio> mvo, it does not allow me to ssh
<cachio> mvo, which user/pass should I use?
<cachio> I tried with root and didn't work
<cachio> test user nither
<cachio> neither
<mvo> cachio: meh, ok
<cachio> trying again
<ctOS> kenvandine: x
<mup> PR snapd#7946 closed: tests: fix partition creation test <Simple ð> <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7946>
<cmatsuoka> bbin30min
 * cachio afk
 * cachio afk
<mup> PR snapd#7947 opened: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
<ijohnson> have a nice holiday break everyone!
#snappy 2019-12-20
<mborzecki> morning
<mborzecki> need to drive the kids to school, back in 30 or so
<mborzecki> re
<mup> PR snapd#7948 opened: spread: drop copr repo with F30 build dependencies <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7948>
<pokk> besides the docker snapcraft not seeming to work it's rather fun to build snaps
<pokk> well done everyone!
<sdhd-sascha> Hello, I could need some advice: https://forum.snapcraft.io/t/interface-shared-memory/14759
<sdhd-sascha> Where should a access to a specific shared-mem be added?
<mvo> cachio: hey, good morning! I pushed an update to 7943, but for some reason it's still not not quite working on gce - do you think you could run it with a console again?
<cachio> mvo, hey, sure
<mvo> cachio: thank you!
<cachio> mvo, yaw
<mvo> cachio: i also enabled the smoke test and it works in qemu
<cachio> mvo, I run core20 suite in gce and passed
<cachio> mvo, I also see that it is running well on travis https://travis-ci.org/snapcore/snapd/jobs/627684724#L5851
<cachio> mvo, which error did you see?
<mvo> cachio: \o/
<mvo> cachio: I triggering it locally and saw an issuee connecting to the instance, it looked like it did not come back after a reboot
<cmatsuoka> cachio, mvo: good morning
<mvo> cachio: but maybe it was something local or something rare?
<mvo> cmatsuoka: good morning! happy friday :)
<cmatsuoka> cachio: do you know what this error is? https://pastebin.ubuntu.com/p/YzRSfTrpX7/
<mvo> cmatsuoka: could this be a leftover in parts/* that confused the dpkg-buildpackage run?
<cmatsuoka> mvo: yay, I'm following the irc conversation, congratulations!
<cmatsuoka> mvo: humm maybe, good idea, let me check
<mvo> cmatsuoka: thanks! yeah, if we get a green run in travis that will be an amazing christmas present
<cmatsuoka> indeed it will!
<cachio> mvo, 3 exececutions 2 passed
<cachio> 3/3 sorry
<cachio> all passed
<cachio> I'll test it more to make sure it works well
<cachio> I added a loop to run the tests the whole day
<mup> Bug #1857128 opened: Missing configuration option to allow a snap to openFile without prompting <Snappy:New> <https://launchpad.net/bugs/1857128>
 * cachio afk 10 mins
<mborzecki> mvo: left a question for ian in #7947, aiui bootloader.Options.Recovery triggers the new behavior
<mup> PR #7947: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
<mborzecki> (or should trigger the new behavior)
<cmatsuoka> mborzecki: that udevadm-calls-after-each-operation thing might hold some water, i added an extra trigger --settle after filesystem creation and it's not failing (so far)
<mborzecki> cmatsuoka: hahah
<cmatsuoka> i hate those magical fixes, especially when they work!
 * cmatsuoka really needs to understand how udev works
<mborzecki> cmatsuoka: as we looked at the anaconda/blivet code they did use settle very often after any operation on storage
<cmatsuoka> I don't doubt they did that after being bitten a few times
<mborzecki> hm this is interesting https://bugs.launchpad.net/snappy/+bug/1857128 isn't that covered by the portals too?
<mup> Bug #1857128: Missing configuration option to allow a snap to openFile without prompting <Snappy:New> <https://launchpad.net/bugs/1857128>
<jdstrand> Saviq: hey (I'm not actually here), but I noticed in nautilus a 184M volume. it turns out it is a loopback mount in /media/jamie/disk that is the multipass snap. I did not do this myself. is this intended behavior?
<jdstrand> Saviq: https://paste.ubuntu.com/p/X7bh7QygyQ/
 * jdstrand wanders off
<Saviq> jdstrand: no, we never did this ourselves
<jdstrand> weird
<jdstrand> Saviq: well, fyi in case it comes up again, 2019-12-09T17:23:21.609994Z was the snapcraft-started-at in the manifest.yaml
 * jdstrand unmounts
<mvo> cachio: nice!
<cachio> mvo, so far 100% pass
<mvo> mborzecki: cool, thanks! I still haven't reviewed this pr yet, will try to do some good reviews this aftersoon
<mvo> cachio: very cool
<cachio> 18 executions
<jdstrand> Saviq: looking at the logs, it seems that org.gnome.Shell.HotplugSniffer was involved, so you can disregard
<cmatsuoka> cachio: going to the standup?
<mup> PR snapd#7949 opened: cmd/snap, daemon: stop over-normalising channels <Created by chipaca> <https://github.com/snapcore/snapd/pull/7949>
<mup> PR snapd#7950 opened: overlord/snapstate: tracks are now sticky <Created by chipaca> <https://github.com/snapcore/snapd/pull/7950>
<Chipaca> mvo: mborzecki: two tiny PRs ^
<cachio> Chipaca, mvo cmatsuoka mborzecki could someone please take quick look to #7851
<mup> PR #7851: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7851>
<Chipaca> sure
<cachio> Chipaca, just 36 files changed
<mvo> Chipaca: thanks, looking
<mvo> cachio: yes, looking
<cachio> mvo, thanks!!
<mborzecki> mvo: Chipaca: about portals, the whole diff is: https://paste.ubuntu.com/p/B66tNMNryV/
<Chipaca> cachio: why the change from test-snapd-sh to test-snapd-sh.sh?
<cachio> Chipaca, to be consistent bertween the local snap and the remote snap
<mvo> mborzecki: woah, that's nice and short
<Chipaca> cachio: fair
<cachio> the snap that we download uses test-snapd-sh.sh, so the change makes the local snap use the same
<cachio> mvo, so you need a test-snapd-sh for uc20 right?
<Chipaca> mborzecki: WHen â When :-p
<Chipaca> mborzecki: doesn't that change it over unconditionally? ie without checking whether portals are there?
<mvo> cachio: yeah, I think that will make the test better
<cachio> Chipaca, thanks for the +1
<cachio> mvo, ok, I'll create it after lunch
<mvo> cachio: thank you!
<cachio> the same for test-snapd-tools right?
<mvo> cachio: I'm working on a fix now to not (ab)use snapd-core-fixup.sh to setup the user for spread :)
<mvo> cachio: yes
<mvo> cachio: but maybe we don't need test-snapd-tools anymore now that we have -sh
<mvo> cachio: wdyt?
<mup> PR snapd#7851 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7851>
<cachio> mvo, we use test-snapd-tools-core18 in 2 tests
<mvo> cachio: ok, thanks, I don't remember enough details, you can choose :)
<cachio> mvo, ok, thanks
<mborzecki> Chipaca: we try to ping the service by calling org.freedesktop.DBus.Peer.Ping() if that fails the snapd user session launcher is used
 * cachio lunch
<mup> PR snapd#7951 opened: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 (2.43) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7951>
<mvo> cachio: for later - I ported https://github.com/snapcore/snapd/pull/7951 double check would be great
<mup> PR #7951: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 (2.43) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7951>
<mup> PR snapd#7952 opened: snap-bootstrap: trigger udev after filesystem creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7952>
<mup> PR snapd#7953 opened: tests: use new snapd.spread-tweaks.service unit <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7953>
<roadmr> cachio, sil2100 : did either of you release core18 about 50min ago?
<Chipaca> EOY for me. TTFN, HANEOY, etc etc etc
<Chipaca> ð
<sil2100> roadmr: ok, so it might have been me, but it was a bit earlier than that - since it was phased to 100% at the usual time but wasn't released fully, so I did the final push without phase percentage some time ago - did I break something with that...?
<sil2100> Since I should have done a no-percentage release when we reached 100%, but it popped out of my mind
<sil2100> Probably shouldn't have been trigger happy and doing the no-percentage push now, since I guess 100% phasing != no-phased-percentage
<roadmr> sil2100: did you use phasing for the release?
<roadmr> sil2100: we saw a storm of requests (like when core was released unphased and we'd have to scramble to throttle on our side)
<sil2100> roadmr: yes
<roadmr> sil2100: interesting... so you started at what percentage?
<sil2100> roadmr: and I think it should have been sitting in 100% phasing for a while
<sil2100> roadmr: I think yesterday I started with 20%
<sil2100> roadmr: when did the storm of requests start?
<roadmr> sil2100: aha, that should have been ok
<roadmr> 16:34 UTC first alert, so it probably started shortly before that
<sil2100> roadmr: so my phasing was a bit uneven this time, since yesterday it was 20, then 50, then 70 but with long periods in-between those
<sil2100> But yeah, I'd expect most should have gotten it yesterday regardless
<roadmr> sil2100: right, it makes no sense that the final 30% would break things, everyting else looked stable
<roadmr> sil2100: ok, no problem - your procedure looks correct
<sil2100> roadmr: also, as said, it was sitting on phasing 100% for quite a while, I only did the final no-progressive call those ~2 hours ago
<sil2100> Since I always have to do the final release API call after phasing to 100%
<roadmr> right and we saw the issue about 1h ago, so they don't seem to correlate that well :/
<roadmr> np sil2100, I'll keep digging for what else may have caused it
<roadmr> (it could have been a tail of core18 stragglers + a vscode-insiders release)
<mup> PR snapcraft#2850 opened: hooks: enable command-chain <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2850>
#snappy 2019-12-21
<mup> Bug #1857206 opened: Links don't work on snap <Snappy:New> <https://launchpad.net/bugs/1857206>
#snappy 2019-12-22
<mup> PR pc-amd64-gadget#31 closed: grub.cfg: switch to new style kernel_status failover handling <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/31>
<aiena> WHo maintains the Krita snap is it safe to use?
<jamesh> aiena: it is published by the Krita project  themselves.
<aiena> hmm the krita projects say's only appimages are official
<aiena> so I'm confused lol
<aiena> project
<aiena> or at least when I asked the devs at #krita
<jamesh> "snap info krita" says "publisher: Stichting Krita Foundation (kritaâ)"
<jamesh> the tick means that Canonical has verified that the "krita" publisher account is actually controlled by the Krita Foundation
<jamesh> If the Krita folks say that the snap is not yet at a stage where they recommend it, then I guess  you should trust them
<aiena> ok
<pokk> *hurray* my rsync over ssh with ssh-keys are working
<pokk> now to figure out how to publish it :D
<pokk> well... honestly I don't know if it actually works :| it might just be to good permissions
<pokk> Trying to do a remote-build but get an error "Failed to pull source, command" followed by a git command and "exited with code 128." any ideas on what this might be caused by?
<cjp256> Pokk: do you have a gitconfig with gpg signing enabled by chance ?
<pokk> cjp256: shouldn't have, it's a clean install of ubuntu with no git configured really. But, installed
<cjp256> Try running the command manually and see if you get an error? There is an open PR I put up to improve the error and messaging there, but hasnât been merged yet, unfortunately.
<pokk> cjp256: no, it doesn't run, it complains about \n's I'm guessing that's not the case when actually run
<pokk> oh, it might because it's such a clean git install
<pokk> yepp, that was it :| I had no user.name / user.email
<pokk> when setting that it runs
<cjp256> Ah thanks for the feedback, Iâll have to address that
<pokk> the build targets seem a bit borken as well :( Only able to build one arch
<pokk> cjp256: it's in no way unreasonable to need a user.email / user.name but it wasn't obvious from the error message )
<pokk> :)
<pokk> nice, it did work. But apperantly you can't access it in the way I thought, back to debuging
