#snappy 2015-06-22
<dholbach> good morning
<fgimenez> good morning
<rickspencer3> mvo, https://bugs.launchpad.net/snappy/+bug/1465724
<ubottu> Ubuntu bug 1465724 in Snappy "net_admin apparmor denial when using Go" [Undecided,New]
<JamesTait> Good morning all; happy Monday and happy Onion Rings Day! ð
 * ogra_ grumbles at lool for including HTML tables in mails 
<lool> the joys of HTML emails
<zyga> ogra_: it's the company 2.0
<zyga> ogra_: without shell
<zyga> ogra_: with html
<zyga> ogra_: about the removal of {dpkg,apt,bash,python}
<zyga> ogra_: I'd love to have a roadmap for that
<ogra_> zyga, and without answering inline in emails :P
<zyga> ogra_: for people like me
<zyga> ogra_: to know when something must be ready on my side
<zyga> ogra_: so that my app continues to work
<zyga> ogra_: and I think for everyone in the dev community
<ogra_> zyga, simpoly dont make use of them :P
<zyga> ogra_: as any time you remove stuff from the image
<zyga> ogra_: you break compatiblity
<ogra_> then you wont be bitten by their removal
<zyga> ogra_: that's unrealistic, go rewrite my software for me
<ogra_> no we dont
<zyga> ogra_: sure, that's just reality
<ogra_> we never guranteed compatibility beyond the snappy command
<ogra_> no it is not
<zyga> ogra_: well, then snappy is a lousy thing to target
<zyga> ogra_: it's worse than docker
<zyga> ogra_: just bring your own distro
<ogra_> reality ios that the core system is abused as a dependency where it shouldnt
<zyga> ogra_: well, regardless of what you think about what is in the core and what can be used
<zyga> ogra_: if the core grants you nothing
<zyga> ogra_: then it's not a core
<ogra_> it doesnt
<zyga> ogra_: it's not a thing at all
<ogra_> it is enough OS to boot and to run the snappy command ... that is all it is
<zyga> ogra_: great, who wants that?
<ogra_> and thats all we promise
 * zyga is grumpy about that
<ogra_> thats the design of snppy
<ogra_> *snappy
<ogra_> it hasnt been described differently anywhere
<zyga> ogra_: this is like putting people in an empty room, not giving them any tools to fill the room and say, 'enjoy'
<ogra_> zyga, that is why your snap should include everything it needs, a snap needs to be self contained
<zyga> ogra_: IMO we should have started with the empty room and added stuff, we started with a room with some things labelled "don't touch" (but nobody stopped you if you did)
<ogra_> not dependencies ... not even on core
<zyga> ogra_: microsoft and apple learned the hard way that's not the way to do it
 * zyga feels that snappy is not useful withouy stuff like snapcraft being done on day one
<ogra_> we couldnt start with the empty room ... simply because we use legacy tools in core that we cant immediately replace
<ogra_> i.e. system-image
<zyga> ogra_: ha, but you ask everyone to replace theirs
<zyga> ogra_: I see what you do
<zyga> ogra_: but it's hard to work in this world
<ogra_> we never and nowhere asked anyone to add a dependency on core ... quite the opposite
<zyga> ogra_: the problem is in wording
<zyga> ogra_: show me a link on .ubuntu.com that lists what the core provides
<zyga> ogra_: and a big warning that says everything else is not supported
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/wily-preinstalled-core-armhf.manifest
<zyga> ogra_: and that {insert name of big thing people see and assume it's there} will go away
<zyga> ogra_: be serious
<ogra_> nothing is supported
<zyga> ogra_: I want high-level thing
<zyga> ogra_: on ubuntu.com, in html
<zyga> ogra_: with explanation
<zyga> ogra_: nobody understands snappy because of failure of communication
<ogra_> i am serious, that is the list of bits core provides ... but that doesnt mean you should depend on anything in there ... this isnt dpkg
<zyga> ogra_: of what snappy is and isnt
<zyga> ogra_: and each time you ship a new core that has one bit less, something that works now will break -- and that's fine, it's just a failure to communicate this correctly
<ogra_> if it breaks the creator of that "something else" made a mistake ...
<zyga> ogra_: and all those issues just contribute to the fact that snappy is hard to taget today, because of misunderstandings and missing tooling
<ogra_> since ... again, a snap needs to be self contained
<zyga> ogra_: no, we're all people, nobody cares, if to make something great you need to make it great for developers and all the other people, or nobody will care
<zyga> ogra_: is libc assumed?
<zyga> ogra_: is this written down anywhere? any design doc? a white paper? anything that I can read apart from being grumpy to collegues?
<zyga> (which I'd much much rather not do)
<ogra_> it surely is ... it is the fundamental design principle of snappy
<ogra_> (now dont ask me where in these 100s of google docs ... )
<zyga> so how can anyone write a good snap todaty
<zyga> if we as a company failed to communicate this clearly
<ogra_> by including everything you need for execution inside your snap
<zyga> I shouldn't be doing this, you are not at fault here
<ogra_> well, i'm promoting it ... and on purpose (and i knew that there will be resistance but i want to get peoples minds straight before the world falls apart because we remove something)
<zyga> ogra_: don't mistake resistance
<zyga> ogra_: with walking blindfolded over a minefield
<zyga> ogra_: I'm forced to deliver somthing onto a platform I don't fully understand, that is changing, that has no tooling, that is totally barren (by design) -- this is frustrating as a developer experience
<zyga> ogra_: it seems to me that the best way to do what I want is to just ship a debian chroot until some form of better tooling exists, maybe, someday
<ogra_> zyga, well, one reason for me working on py-snapper (or node-snapper) or ted and mike working on snapcraft, is to solve that ... we are just not there yet with the tooling
<ogra_> you are a pre-early-adopter here ...
<ogra_> you cant ship a debian chroot ... i dont think the security policy will allow chrooting ... you would have to depend on a container framework like docker or lxc
<zyga> ogra_: and one that has a large app to port
<zyga> ogra_: neither py-snapper nor anything like that will help me as my app is just more complex than that and relies on a zoo of tools
<ogra_> then you need to ship that zoo
<zyga> ogra_: in docker?
<ogra_> by using deb2snap or whatnot
<ogra_> or in docker
<zyga> ogra_: deb2snap ~30-50 packages
<zyga> ogra_: into one huge snap (if that's possible by deb2snap)
<zyga> ogra_: then path everything to understand new executable names
<ogra_> i think it is, AFIK deb2snap can take a package list
<ogra_> and it mangles the executable names, preload and library paths for you
<sergiusens> ogra_: zyga 15.04 will not break; rolling on the other hand...
<ogra_> right
<ogra_> but even if it will not break it is wrong to depend on core even there :)
<ogra_> sergiusens, btw, putting files into /system/boot/uboot does indeed not work since we have a-b mounted on top :)
<sergiusens> ogra_: if you are going to put it in /system/boot/uboot maybe just target the file to no where and it will land there (but there would be no a/b logic for these)
<sergiusens> ogra_: you wont ever be able to get anything in the store that relies on dpkg at least
<ogra_> well, i'm pondering to just ship it in /lib/modules somewhere
<ogra_> but we should have some plan for changelogs, configs and licenses
<ogra_> sergiusens, bug 1467474
<ubottu> bug 1467474 in Snappy "hardware.yaml should allow including changelog, kernel-config and license files" [Undecided,New] https://launchpad.net/bugs/1467474
<zyga> ogra_: can I bug you for a moment about snappy and wifi?
<zyga> ogra_: from what you said earlier
<zyga> ogra_: it seems that I need to package things like wpa supplicant and all the IP tools
<zyga> ogra_: is that correct?
<zyga> ogra_: the goal is to make an app that can use wifi
<zyga> ogra_: (and to be precise, for certification, what kind of base feature set should I test for when the hardware says that wifi is supported)
<ogra_> zyga, wpa_supplicant is shipped (hardware enablement is something that goes into core indeed)
<ogra_> (at least generic bits of it )
<zyga> ogra_: ah, so what kind of hardware enablement for wifi can any app rely on?
<ogra_> and you should have all tools needed to make a wlan come up
<zyga> ogra_: or networking in general, what kind of IP tools do we plan on supporting
<zyga> ogra_: ok, that's good to know
<zyga> ogra_: can you tell me how this is all supposed to work according to you
<ogra_> though this should not be done by your snap i guess ... but rather via the owem snap in some way
<ogra_> *oem
<zyga> ogra_: e.g. at which level do apps come in
<zyga> ogra_: and at which level should we test
<zyga> ogra_: the oem snap ships kernel image, modules and support bits, correct? can it also ship commands/scripts?
<ogra_> no, it ships bootloader and dtb files (and their overlays)
<ogra_> kernel is in a separate part
<zyga> ogra_: ah, so everything goes to os snap?
<ogra_> (currently the device tarball)
<zyga> ogra_: note: please separate current limitations
<zyga> ogra_: from the design
<ogra_> (soon to be its own snap too)
<zyga> ogra_: as the cert should work beyond 15.04
<zyga> ogra_: (at least without major changes)
<zyga> ogra_: hmm, wait, new snap? (I though minimal system has three snaps: os + oem + gadget)
<ogra_> so technically -> hardware enablement should happen inside the core image itself via the owm snap ... wifi configuration should happen via snappy config of the core snap i guess ... your app snap should only make use of the preconfigured hardware then
<ogra_> *oem
<ogra_> (whats up with me today not being able to type oem)
<zyga> ogra_: :D
<zyga> ogra_: ok, so snappy config (yaml) is how apps can reconfigure network? (I didn't know about that part)
<ogra_> now there are some grey areas ... where your app snap needs to configure hardware ... (set the default resolution for a webcam that you need to set via echoing into a /sysfs node or some such ... ) not sure how that should be handled
<zyga> ogra_: it depends on a product, if I wanted to build a STB device on top of snappy I'd have to handle network setup
<ogra_> i havent played personally with our hardware access story, i know some bits of that landed though and enable you to use it
<zyga> ogra_: (though perhaps in a private framework for network that my app could talk to)
<zyga> ogra_: for certification, I'm trying to see what's the low level stuff we need to test
<ogra_> yeah, something like that
<zyga> ogra_: and verify through the programme
<zyga> ogra_: when we say "wifi on $product works" what did we test?
<zyga> ogra_: and what did we specifically left out?
<ogra_> the prob here is that all our implementations are still rather theoretic ... while they are there we dont have much code beyond simple examples using them yet
<zyga> ogra_: in the past I assumed we'd be testing at the framework level but that's no longer true
<ogra_> there is a webcam example that might give some insight
<zyga> ogra_: so what would be your advice, to wait and not create the programme?
<zyga> ogra_: or to specify $something and just go with it for 15.04
<ogra_> no, to challenge the current implementation by trying to implement it with whats there
<zyga> ogra_: webcams are going to be under generic USB host capability, along with lots of other products
<ogra_> (would be my way)
<ogra_> to find the flaws and issues with what we created and fix them
<zyga> ogra_: ok, if that's what you say then this is important feedback, so far we've been working on different assumptions
<zyga> ogra_: as in, come up with requirements and start writing tests right now
<zyga> (btw, I used deb2snap for plainbox, got 154MB archive, didn't test it yet)
<zyga> (and it looks quite like a chroot I was thinking about earlier)
<ogra_> yeah, for now snaps will still be rather big :)
<ogra_> deduplication on all levels will help with that some day
<zyga> ogra_: $now + 1 ;-)
<ogra_> (but thats not there yet))
<zyga> ogra_: who's working on the hardware design side of snap
<ogra_> until then i fear we have to live with giantic snaps on disk :)
<ogra_> well, there were some mails from jdstrand_ about that
<zyga> on the mailing list?
<ogra_> yep
<seb128> slangasek, you around to help me with some uefi snappy personal boot issues? ;-)
<ogra_> about time that x86 switches to uboot :P
<seb128> ahah
<ogra_> all these UEFI issues all the time
<seb128> slangasek, the bios lists the usb stick correctly but selecting it displays a "error: file "/boot/" not found" then gives a grub shell rather that the boot menu
<elopio> good morning.
<tedg> Morning elopio!
<elopio> hey tedg!
<elopio> fgimenez: lets skip our call today. I have a good bunch of emails to read.
<fgimenez> hi elopio, ok
<fgimenez> elopio, any luck with the cross compilation?
<elopio> fgimenez: I've just had a successful build, a couple of minutes ago.
<elopio> Chipaca: ^ it seems it was actually a python problem, that maybe barry fixed.
<fgimenez> elopio, great! should it work with the command we were using?
<elopio> fgimenez: oh, wait, no, I've just run it in amd, not cross compile.
 * elopio tries again.
<Chipaca> elopio: i'm shocked. will need to sit down for a bit.
<barry> elopio, Chipaca hi
<elopio> fgimenez: barry: Chipaca: now I get a problem from golang-go: http://paste.ubuntu.com/11757173/
<Chipaca> barry: hi
<Chipaca> elopio: could you pastebin the postinst?
<elopio> Chipaca: http://paste.ubuntu.com/11757206/
<zyga> ogra_: I'm on image .3, I see there's wpa_supplicant there, there's no iw* tools though
<zyga> ogra_: how would one, in practice, get wifi to work?
<ogra_> i think there si some blog post about how thats done
 * ogra_ has never needed wifi yet
<elopio> Chipaca: https://www.goodreads.com/book/show/25676397-designing-connected-products
<zyga> ogra_: any links? I'm looking around but found only similar questions
<ogra_> i think rickspencer3 had one recently
<ogra_> (thats still from before we added wpa_suppl. to the image though, so it has some ill instructions about making the image writable etc ... the second half should just work though)
<zyga> ogra_: wpa_supplicant is there but perhaps that's not enough (iwconfig is not there)
<ogra_> what for aourl you need iwconfig ?
<ogra_> *would
<ogra_> tsk ..
<zyga> ogra_: not sure, probably to set the AP data
<ogra_> you dump your wlan config into /e/n/i.d/ and thats it
<zyga> ogra_: interfaces?
<zyga> ogra_: to /etc/network/interfaces?
<ogra_> there were discussions about moving away from /e/n/i to systemd's network manager tool
<ogra_> interfaces.d ... but yeah
<zyga> ogra_: but that stuff relies on wireless-tools
<zyga> ogra_: and without it the hooks won't do anything
<zyga> ogra_: dpkg -L wireless-tools
<zyga> ogra_: grep | if-post-(up|down)
 * zyga cannot find anything on google about rick's blog post
<ogra_> http://askubuntu.com/questions/585790/how-to-connect-wifi-network-from-raspberry-pi-2-snappy
<ogra_> "then added this file to /etc/network/interfaces.d/wlan0"
<ogra_> you should only need the bit below that line
<ogra_> (as long as you have a kernel compliant device for which a module exists)
<zyga> thanks!, let's see
<ogra_> (forst hit for "ubuntu snappy wireless" on google btw)
<zyga> ogra_: nothing like personalized searches ;-) I was googling for beaglebone wifi"
<zyga> ogra_: works, nice
<zyga> ogra_: thanks
<ogra_> :)
<zyga> ogra_: one less cable for me to manage ^_^
<zyga> I sent a question on how to snapify network-manager to the mailing list, looking forward to see how that could be done
 * elopio walks the dog before it rains.
 * zyga goes to the other desk to desolder some stuff
 * davmor2 sees that zyga is after more cables, or is that not what you are trying to say at all ;)
<zyga> dholbach: haha
<zyga> grr
<zyga> davmor2: ^^
<zyga> davmor2: I want to solder angled headers for serial
<zyga> davmor2: so that I can fit everything in the case I've got
<davmor2> zyga: mad fool you ;)
<zyga> davmor2: why? it's so cute when it fits in the case
<elopio> dholbach: balloons: rsalveti said we want to make a new stable release next week.
<elopio> so we need to start planning for the testing session by the end of this week or beginning of the next one.
<dholbach> elopio, oooooh!
<elopio> both are ok for me. Any preference on your side?
<dholbach> both should be fine for me as well
<balloons> awesome!
<kyrofa> sergiusens, ping
<sergiusens> kyrofa: pong
<sergiusens> bbl pong then :-)
<kyrofa> sergiusens, haha, okay :)
<balloons> elopio, so I was just going to ask you if we would see a release next week. Thanks for the heads up.
<balloons> elopio, so we should probably have a quick chat later this week. Can we pick a date for the open house yet?
<fgimenez> elopio, i've just sent you a catch up email, one more for your pile ;)
<elopio> fgimenez: thanks, I'll check.
<popey> ogra_: do we have a handy guide for putting a snappy image on an sd card to play with on a pi 2?
<ogra_> popey, https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2
<elopio> balloons: yes, we should meet again to get the final details. We can pick a date, and then tell the team to have an RC ready for that date.
<popey> ta
 * balloons notes ogra_ points popey back to d.u.c
<balloons> success!
<ogra_> :D
<fgimenez> nice evening everyone o/
<balloons> elopio, as soon as you have that date, let's meet. I'll get with Daniel tomorrow to kick off the announcements and line up the onair session, etc.. But that's all easier with a date :-)
<elopio> balloons: a part of our team is sprinting this week, so I'm inclined to do it early next week.
<elopio> if they are back on monday, monday sounds good. I'll ask.
<balloons> elopio, ack.
<slangasek> seb128: a grub shell rather than the boot menu, interesting.  show me the contents of the second partition on the USB stick?
<slangasek> certainly, "/boot" is not the expected path
<seb128> slangasek, http://paste.ubuntu.com/11757694/
<seb128> slangasek, http://people.canonical.com/~seb128/video20150622_154059164.mp4 is the video from the bios/grub behaviour
<slangasek> seb128: please pastebin the text of efi/boot/grub.cfg
<seb128> slangasek,
<seb128> set prefix=($root)'/EFI/ubuntu/grub'
<seb128> configfile $prefix/grub.cfg
<seb128> EFI/BOOT/grub.cfg yoy mean right?
<slangasek> yes
<slangasek> it's a fat partition, so it's the same thing ;)
<slangasek> seb128: that all looks correct and expected, and does not explain the error message you got
<seb128> slangasek, the grub cfg is http://paste.ubuntu.com/11757708/
<seb128> well /EFI/ubuntu/grub/grub.cfg
<davmor2> slangasek: calling things fat is so politically incorrect can't we call it larger ;)
<seb128> slangasek, it looks like /boot isn't mounted/it doesn't find the kernel maybe?
<slangasek> seb128: I supposed that's possible.  If you look at sda3 and sda4, do you have the expected /boot contents?
<seb128> slangasek, hum, no
<seb128> wth
<slangasek> so I guess this error is also reproducible when booting under bios ;)
<seb128> slangasek, /system-a/boot has 3.19.0-22 files
<seb128> but the grub config has 3.19.0-10 entries
<seb128> oh, no
<sergiusens> kyrofa: pong
<seb128> I'm reading the wrong section
<seb128> slangasek, seems about right in fact, and that image boots fine under kvm
<seb128> I'm going to try on a non uefi machine in a bit
<seb128> slangasek, should I be able to ls /boot from grub?
<seb128> I wonder if it fails to mount the fs for some reason
<seb128> slangasek, brb, trying on my laptop which is not uefi/signed boot
<kyrofa> Hey sergiusens :)
<kyrofa> sergiusens, one of the things the snapp scope will eventually need to do is actually launch snaps
<kyrofa> sergiusens, but lots of snaps don't have the concept of "launching"
<kyrofa> sergiusens, we need a way to tell which snaps have a GUI, or can be launched
<sergiusens> kyrofa: you want the equivalent of binaries I guess; I thought tvoss was going to be looking into that
<kyrofa> sergiusens, I'm really talking about the snappy API. I assume the store doesn't have a way to tell which snaps are launchable, but will that fit into the API when it does?
<sergiusens> kyrofa: when there is a complete story for it, I guess it will, yes
<kyrofa> sergiusens, alright. I wasn't sure if that would somehow fit into the "type" field or what
<sergiusens> kyrofa: well that's a question for the elders of the internet (aka snappy architects)
<sergiusens> kyrofa: I don't see tvoss here, so maybe olli knows who's dealing with this
<kyrofa> sergiusens, alright, thanks :)
<seb128> re
<seb128> slangasek, that key works fine on my latitude
<seb128> so the issue seems to be with the signed boot
<slangasek> oh?  there's signed boot in place on the images already?
<seb128> slangasek, well, I don't know, maybe it's not properly set up :p
<seb128> slangasek, that image has grub-efi-amd64-signed installed
<seb128> and is built with goget-u-t 0.23 so with working uefi
<seb128> before that the boot menu of the inspiron wouldn't list the device
<seb128> maybe it's just the uefi mode which is misconfigured...
<slangasek> seb128: ok. so if it's booting the signed grub efi binary, one notable difference is that it will not load any modules from the disk but only use those that are built in.  So it's possible that there's something funny with your target device to cause it to require some module that's not currently part of the set we build into the signed grub
<olli> kyrofa, from looking over the thread I think mvo (absent) or alecu can help
<ogra_> olli, where is my armhf mir !!
<ogra_> :)
<seb128> slangasek, how can I tell if there is anything funny/get debug info?
<slangasek> seb128: let me think about that
<slangasek> seb128: I do see that this system has both bootx64.efi and grubx64.efi.  Is SecureBoot enabled on it?
<slangasek> seb128: also, what seed are you building from?  I guess this isn't in ubuntu.wily yet
<kyrofa> olli, alright, thank you
<seb128> slangasek, "Is SecureBoot enabled on it?", how do I tell?
<seb128> slangasek, seed is http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop
<seb128> slangasek, you can see a build log on https://launchpadlibrarian.net/209683596/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz
<slangasek> seb128: checking whether secureboot is enabled: mv /efi/boot/bootx64.efi /efi/boot/bootx64.efi.bak; cp /efi/boot/grubx64.efi /efi/boot/bootx64.efi; try to boot it
<slangasek> seb128: if you get a different error, you know secureboot is enabled :)
<seb128> slangasek, if I do that the device stops being listed as a bootable one
<slangasek> really? that's interesting
<seb128> that inspiron doesn't list non uefi (or non secure) devices
<seb128> like back then I first tried to boot a x86 iso and it never listed the device as bootable
<slangasek> we haven't made it a non-uefi device.
<slangasek> /efi/boot/bootx64.efi is the magic path
<slangasek> and I would not expect the firmware to try to validate the signature on /efi/boot/bootx64.efi before it's been asked to boot it
<seb128> bah
<seb128> sorry, nautilus/fat fail
<seb128> the rename didn't work
<seb128> k, same issue
<seb128> well "same" = file "/boot" not found
<slangasek> ok
<slangasek> so that means secureboot is not enabled on the device, and the problem is not related to failure to load external modules
<seb128> that's something ;-)
<slangasek> you probably want to debug this at the grub shell then
<slangasek> starting with 'ls ($root)'
<seb128> (hd0,gpt2): filesystem is fat
<slangasek> seb128: ok.  'ls $prefix' ?
<seb128> error: disk `(hd0,gpt2' not found
<seb128> ups
<seb128> sorry
<seb128> I had extra ()
<seb128> error: file `/boot/grub' not found.
<seb128> ls / -> efi/
<seb128> not sure if /boot should exist/be mounted
<slangasek> ok that's interesting
<slangasek> echo $prefix ?
<slangasek> seb128: ^^
<seb128> (hfb0,gpt2)/boot/grub
<seb128> grr
<seb128> (hd0,gpt2)/boot/grub
<slangasek> ok
<slangasek> no idea where that came from, because that's not what was specified in /efi/boot/grub.cfg
<slangasek> and your directory listing showed only two grub.cfg on the disk, and both of them appear to be correct
<slangasek> and you said this same image booted successfully on your UEFI-capable laptop in non-secureboot mode?
<seb128> no
<seb128> I've 2 laptop, the inspiron which is uefi and the latitude which is older and non-uefi
<seb128> it boots fine in kvm and on the latitude in non-uefi
<slangasek> ah.
<seb128> it failes to boot on the inspiron
<seb128> secure or not
<slangasek> seb128: what's the precise version of ubuntu-device-flash you used for creating this image, and what commandline did you use? I'd like to try to reproduce locally
<seb128> slangasek, I tried with the hack from http://paste.ubuntu.com/11700710/ but let me try again with trunk, proper support got merged
<seb128> before you spend time debugging
<seb128> though those changes are just partition size extended and using the correct channel
<seb128> so it shouldn't make a difference
<seb128> slangasek, command, the one on top of http://paste.ubuntu.com/11719625/
<slangasek> seb128: ok - but I should wait for you to test the goget-ubuntu-touch trunk before I try to reproduce?
<seb128> slangasek, as you want, I doubt it makes a difference
<seb128> but I'm happy to try and let you know
<seb128> it might be tomorrow morning for me though
<_4M8B_> Hi guys , I was searching howto configure my keyboard layout in snappy but without results... Can somebody help ?
<seb128> slangasek, $ strings EFI/BOOT/grubx64.efi | grep /boot
<seb128> 	set prefix=($root)/boot/grub
<_4M8B_> https://bugs.launchpad.net/snappy/+bug/1464944?comments=all -- seems to have same issue
<ubottu> Ubuntu bug 1464944 in Snappy "no way to configure keyboard layout" [Wishlist,Triaged]
<seb128> unsure where that comes from though
<_4M8B_> ah ok
<_4M8B_> I'll wait thanks
<slangasek> seb128: well, one thing I've confirmed, that grubx64.efi is not the grubx64.efi from the grub-efi-amd64-signed package.
<slangasek> $ strings /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed |grep prefix=
<slangasek> $
<slangasek> for both wily and vivid
<seb128> slangasek, do you get the same issue?
<seb128> slangasek, do you have any idea where the grubx64.efi is coming from then?
<slangasek> seb128: I haven't tried to reproduce it yet, just got udf built from trunk
<slangasek> seb128: the grubx64.efi is being created by grub-install at udf time
<slangasek> (apparently with wrong options)
<slangasek> seb128: I've just run the command from http://paste.ubuntu.com/11719625/ but I don't think it worked, I wound up with cache/ubuntuimages/ubuntu-core/rolling/edge/generic_amd64/version-84.tar.xz.  Is 'AME' really the right variable name?
<slangasek> seb128: looks like that should be UDF_UBUNTU_CORE_NAME but is ignorable; but the command should be 'personal rolling' instead of 'core rolling', since I'm pretty sure you said you were seeing this with personal rather than core
<slangasek> seb128: reproduced that 'strings | grep prefix' output that you showed, by running 'UDF_UBUNTU_CORE_NAME=ubuntu-personal DEBUG_DISK=1 ~/bin/ubuntu-device-flash --verbose personal rolling --channel edge --output amd64-rolling.img --size 10'.  So udf is doing something buggy here
<slangasek> (or else grub-install itself is)
<seb128> slangasek, sorry, I was afaik, yeah unsure about why sergiusens used 'AME' in his command, UDF_UBUNTU_CORE_NAME was the hack name in mvo's patch but I think trunk has a proper option for the new channel?
<slangasek> I don't know what that option is.  So I just reproduced it with the above command
<seb128> k
<seb128> http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/revision/190 was the merge for personal
<slangasek> what is DEBUG_DISK=1 supposed to give me?  doesn't seem to give me much in the way of new output from grub-install
<seb128> the "parted" output I think
<seb128> e.g on http://paste.ubuntu.com/11719625/ the lines 17 to 26
<seb128> I don't think it's useful to debug the grub issue
<seb128> sergiusens suggested it when I was hitting partitioning errors
<seb128> because the partitions were too small for the new image
<slangasek> that's certainly not the cause of this problem.
<seb128> right, that was a previous issue that got resolved by the 10G size bump
<seb128> you can drop that env variable afaik
<slangasek> oh, you mean the grub issue from the pastebin.  Yeah I don't know what that is
<seb128> it's orthogonal, don't worry about it
<seb128> we resolved that one since the pastbin was done
<slangasek> grub-install: info: copying `/usr/lib/grub/x86_64-efi-signed/gcdx64.efi.signed' -> `/boot/efi/EFI/BOOT/grubx64.efi'.
<slangasek> aha
<slangasek> so apparently when passing --removable it's copying the CD image not the disk image
<slangasek> and that's where it gets the prefix=
<slangasek> that may be a regression in grub-install in wily
<slangasek> hmm nope
<slangasek> same behavior in vivid, where it was working fine for me on core
<seb128> slangasek, k, I'm calling it a day and closing IRC but drop me an email or let me know tomorrow if you figure out more about the issue!
#snappy 2015-06-23
<sergiusens> slangasek: seb128 sudo ubuntu-device-flash personal rolling --channel edge --output img.img
<slangasek> sergiusens: ok
<Odd_Bloke> Is there a specific place that we should look for/put snappy logs?
<fgimenez> good morning
<dholbach> good morning
<seb128> good morning snappy world
<ogra_> *snap* *snap*
<seb128> slangasek, did you figure out more about that grub issue?
<JamesTait> Good morning all; happy Let It Go Day! ð
<ogra_> pfft ... go ...
<sergiusens> morning
<Chipaca> sergiusens: mo'in
<Chipaca> sergiusens: fighting some kind of a bug (in my self, not my code)
<ogra_> same here ... and a tooth issue ...
 * Chipaca <- blah
<Chipaca> blahrgh*
<Chipaca> ogra_: ow :(
 * ogra_ will take the rest of the day off ...
<ogra_> hoping it fixes itself, else i'll have to see a dentist tomorrow
<Chipaca> >this< close to doing same, but i'll soldier on for a bit more
<Chipaca> ogra_: take care
<ogra_> you too
<Chipaca> i hate toothaches :(
<ogra_> well, the painkillers at least give me a fuzzy warm feeling
<ogra_> i just cant concentrate on serious stuff :(
 * ogra_ is full of ibuprofen 
<Chipaca> ogra_: time for tea and netflix \o/
<ogra_> heh
<sergiusens> ogra_: heh, I went to the dentist last evening
<ogra_> no netflix for me ... but perhaps a bit TV ...
<sergiusens> Chipaca: did you try bug spray?
<ogra_> (netflix on a 2M line isnt really working)
<sergiusens> Chipaca: I hear Nopol is quite good :P
<Chipaca> sergiusens: :)
<sergiusens> ogra_: popcorn time ;-)
<Chipaca> sergiusens: testosterone keeps the nits away, for now
<ogra_> not with my bad tooth !
<ogra_> :P
<sergiusens> ogra_: although many things are illegal in germany http://thenextweb.com/media/2015/06/22/spanked-by-old-fashioned-laws/
 * sergiusens meant the popcorn time app ;-)
<ogra_> lol
<ogra_> at least you are allowed to still read them when you like ... though who knows when that changes
<sergiusens> ogra_: right, but that means you will need some sort of big brother system to enforce that for the good of knowing you aren't reading anything improper :-P
<ogra_> we'll just ask the NSA for that info
<elopio> good morning.
<fgimenez> hey elopio
<elopio> fgimenez: https://plus.google.com/hangouts/_/canonical.com/ubuntu-qa?authuser=0
<davmor2> elopio: you need to lose the ubuntu-qa from dude seriously ;)
<elopio> davmor2: everybody is invited.
<seb128> sergiusens, hey, any idea when you are going to do a goget-ubuntu-touch update in wily? (to include the personal code)
<balloons> elopio, did you pin Monday as "the" date for open house?
<sergiusens> seb128: let me do that now
<seb128> sergiusens, thanks
<elopio> balloons: I'm asking about that. Either monday or tuesday.
<sergiusens> elopio: we are doing a new release on Monday?
<elopio> sergiusens: rsalveti said next week. If we want to release next week, we need an RC early on the week.
<sergiusens> elopio: with what fixes? :-P
<elopio> sergiusens: we have a small changelog indeed :) That makes it easier. I think what we want is to get a release cadence, even if the version has not changed much.
<balloons> elopio, will you know by the end of today which date it is? So we can plan to meet tomorrow
<balloons> ?
<elopio> balloons: I hope so, but I think rsalveti is busy with sprint meetings. Lets meet tomorrow, and talk about a plan b in case we don't have an answer.
<elopio> maybe we can do the first open house from rolling edge.
<elopio> then we won't need an RC, and it's still a good experiment.
<rsalveti> elopio: I should be able to provide an answer soon
<rsalveti> the most tomorrow
<sergiusens> rsalveti: does that involve our conversation as well?
<rsalveti> sergiusens: yes
<slangasek> seb128: no more progress to report yet
<sergiusens> rsalveti: great, I will hold off on that until then ;-)
<seb128> slangasek, hey, k, let me know if I can help
<rsalveti> sergiusens: sure :-)
<seb128> slangasek, I copied the grubx64.efi from my laptop and use configfile /efi/ubuntu/grub/grub.cfg on the grub prompt and then I can boot the image, so I'm unblocked for local testing at least
<elopio> rsalveti: thanks.
<cyphermox> seb128: hey, I want to look at your booting issue... in grub, could you please run 'echo $cmdpath', then 'echo $root' ?
<balloons> elopio, ack. I'll get it scheduled
<elopio> balloons: if possible, for 14:00 UTC so fgimenez can join us.
<balloons> ck
<fgimenez> sergiusens, are bugs enabled for goget-ubuntu-touch? https://bugs.launchpad.net/goget-ubuntu-touch
<Chipaca> fgimenez: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch
<fgimenez> Chipaca, ok thx :)
<seb128> cyphermox, hey, I'm going to need to restore the buggy files and reboot, can that wait a bit? I'm debugging some other issue on the booted stick atm ... but you can build an image yourself for debugging as well if you want ;-)
<cyphermox> that's already what I'm doing :)
<seb128> k
<cyphermox> do I need something special?
<cyphermox> a different version of ubuntu-device-flash?
<seb128> yes, trunk
<seb128> cyphermox, then use the first line from http://irclogs.ubuntu.com/2015/06/23/%23snappy.html
<skay> I've followed https://developer.ubuntu.com/en/snappy/start/ for the beagle bone black but after waiting > 2 minutes the ssh step doesn't work
<skay> should I be holding down a button when inserting the SD card and powering the device?
<seb128> cyphermox, let me know if you manage to get an image with the issue
<cyphermox> almost done building the image
<cyphermox> I'm building a potential fix too, so I'll be ready to test that as soon as I get an image that reproduces the bug
<cyphermox> seb128: have you filed a bug about this? or do you know if someone else has?
<seb128> cyphermox, no I didn't, but I'm happy to if you tell me against what
<skay> zyga: hey, you successfully got snappy on your bbb, do you have notes on that?
<cyphermox> seb128: so, now if I want to run the image I assume I can do so in qemu?
<seb128> cyphermox, qemu or a machine with a non uefi boot
<seb128> like good legacy bios :p
<cyphermox> right
<cyphermox> well, this bug is uefi specific
<seb128> right
<cyphermox> yup, it fails
<plars> skay: I have it on my bbb, what's the problem?
<plars> skay: oh, just ssh? It's up otherwise? Did you use --enable-ssh?
<skay> plars: I have sadly few details for you
<skay> plars: I can't tell if it's up, since I can't ssh in to it and didn't have a monitor handy
<skay> plars: I did not --enable-ssh
<plars> skay: you'll want to do that when you build your image
<skay> plars: ah, I used the image listed on the start page, I figured I'd follow that
<seb128> cyphermox, let me know if you figure out what the issue is ;-)
<plars> skay: also, if you don't have a monitor (or even if you do) I highly recommend using a usb-ttl cable so you can get serial console
<plars> skay: ah, yeah... always roll your own image :)
<cyphermox> seb128: the issue is some old code in grub to help find the right device for removable install media
<skay> plars: oh yeah! I saw someone using a usb-ttl cable when searching around for blog posts about it
<cyphermox> ie. when you boot the CD in EFI
<skay> plars: I want one
<plars> skay: amazon, they are really cheap if you don't have one already
<skay> plars: if it's better to roll our own images, then someone should update the start page
<skay> plars: I'll try again after building my own image. plus, we have many monitors at the hackerspace and I'll hook one up too
<plars> skay: that's my personal opinion if you are going to be doing the kinds of things we want to do, but it's not the quickest/simplest path assuming you have a tv or monitor to hook it up to, and a keyboard to get things going
<plars> skay: don't forget you'll need a microhdmi-hdmi cable
<plars> skay: something like http://www.amazon.com/Amzer-Micro-HDMI-Speed-Cable/dp/B003OBZSHC
<cyphermox>  sergiusens: is there a minimal memory to run a snappy personal image? I can't seem to start it properly in qemu
<seb128> cyphermox, what's the issue? you need to pick the "ubuntu" line in the grub menu
<seb128> the snappy system-a one just loops reboot
<cyphermox> right, that's what I'm seeing, the kernel loads, panics, reboot
<seb128> cyphermox, try to pick the ubuntu line
<seb128> unsure where the system-a entry is coming from
<cyphermox> grub didn't stop to ask me, but I can play with it some more
<seb128> help debugging that/cleaning it out would be welcome as well ;-)
<cyphermox> I'm still wiating for my grub build to finish
<cyphermox> once grub plays nice, we can debug that
<cyphermox> at least now I know it's not my stuff that is wrong
<cyphermox> (I mean, my qemu settings)
<sergiusens> seb128: fwiw, Chipaca and me just revamped most of the grub code to have a very minimal grub.cfg
<seb128> sergiusens, I hope personal still boots with it ;-)
<cyphermox> sergiusens: is grub.cfg still in /efi/boot/grub.cfg?
<sergiusens> seb128: https://code.launchpad.net/~sergiusens/snappy-hub/grubcfg/+merge/262701
<sergiusens> cyphermox: yes
<cyphermox> alright
<sergiusens> default and timeout need fixing there though
<sergiusens> but I hope you get the gist of it
<seb128> sergiusens, is efi/secure boot going to keep working with that?
<cyphermox> sergiusens: does it really have to be at that location? why not /boot/grub? I'm just curious, as in /boot/grub things would mostly work immediately, whereas /efi/boot will need a special case.
<sergiusens> cyphermox: I don't know, it's all slangasek's work that led to this
<sergiusens> cyphermox: this being grub.cfg in .../efi/...
<cyphermox> heh
<sergiusens> seb128: I think so, but I have no system to prove it
<seb128> sergiusens, I can test those changes if that helps, just not today (in the middle of trying to debug unity8 in a booted session on my key)
<sergiusens> seb128: testing this involves building from 7 branches so I wouldn't advise on testing today ;-)
<seb128> lol, k
<ogra_> sergiusens, do we build the BBB images without --developer-mode ?
<seb128> then when those land in trunk
<seb128> let me know before doing a release
<ogra_> (the conversaition between skay and plars kind of suggest that)
<sergiusens> seb128: sure, for now, I'm releasing those snappy personal things
<ogra_> *suggests
<sergiusens> ogra_: yes, no developer mode by default, why?
<ogra_> ah, k
<ogra_> sergiusens, the start page doesnt mention that ... or that he should manually build the image to have ssh
 * ogra_ makes a note to look over the docs once he is back in business
<sergiusens> ogra_: ssh is disabled by default like on all images; it has been subject of controversy
<ogra_> not on the rpi :)
<plars> I assumed that was by design to keep the getting started page as simple as possible for now, I typically just build my own, but it might not hurt to have a mention that things like ssh will not be enabled if you use the default image
<sergiusens> and mentioned in some of the welcome pages, albeit only the cloud ones; whereas it's common to have ssh disabled by default on any ubuntu install
<plars> with, perhaps, a link to getting into more detail
<ogra_> yeah, probably a sub-page we can link to
<plars> it wasn't obvious to her earlier when she was trying to get it working
<sergiusens> it is expected for images to not have ssh enabled though
<plars> and I suspect a lot of people have this problem of no easy way to attach otherwise
<ogra_> plars, yes, thats what got my attention reading the backlog
<sergiusens> secure by default mantra and all that
<sergiusens> with an 'ubuntu' password ;-)
<ogra_> sergiusens, thats fine, but we need to hint people how to get it enabled :)
<ogra_> haha, yeah
<cyphermox> sergiusens: how can I rebuild the image if I want to use a different gcdx64.efi?
<ogra_> cyphermox, you rebuild the oem snap
<ogra_> cyphermox, (now dont ask me how you get your hands on the oem snap for amd64 :P )
<ogra_> cyphermox, what i do for the RPi: dpkg-deb -x pi2_0.14_all.snap unpack; cd unpack; fiddle ... fiddle ... fiddle; cd ..; snappy build unpack
<cyphermox> ugh
<ogra_> once you have your new oem snap you can just use it with ubuntu-device-flash to build a new image
<sergiusens> cyphermox: isn't that defined by the grub-install from the rootfs?
<sergiusens> ogra_: it could be oem snap related, but we don't do the magic I wish we did as for u-boot (copy files and be done with it)
<ogra_> oh, ok
 * ogra_ didnt know there are still differences
<sergiusens> we magically depend on what grub-install decides for us so the outcome can vary from build to build
<ogra_> oh man
<sergiusens> ogra_: I got rid of most
<sergiusens> ogra_: next is to add all these random files to bootassets :-)
<sergiusens> and we get a nicely contained system
<ogra_> lovely
<cyphermox> sergiusens: I can't update files if I can't boot the system to a working shell
<cyphermox> sergiusens: so far all I ever get is no grub menu, and booting a kernel that panics
<cyphermox> but I do have http://ppa.launchpad.net/mathieu-tl/installer-dev/ubuntu/dists/wily/main/uefi/grub2-amd64/2.02~beta2-25ubuntu2~mtrudel1/ with files that can then be signed :)
<seb128> sergiusens, why do we install openssh-server to disable it by a file in /etc?
<seb128> btw I didn't look at core, but personal is lacking a /etc/default/locale
<seb128> not sure what should create that
<seb128> hum
<seb128> upstart --session doesn't like snappy much
<seb128> if that a known issue?
<seb128> the upstart bridge jobs and other things seem to behave weirdly, not start as they should
<zyga> skay: yes, I have
<zyga> skay: it's rather straightforward, just copy the image, what kind of issues did you see?
<zyga> skay: and most important, do you have a serial cable?
<skay> zyga: hey, plars suggested building my own image. I was just following the instructions on the site, using hte vanilla image
<skay> zyga: I'll update back here if I run in to a problem. I'll prob try it tonight
<sergiusens> seb128: for cloud-init
<sergiusens> seb128: grep for ssh here https://developer.ubuntu.com/en/snappy/start/#snappy-azure
<sergiusens> cyphermox: you can manually put stuff there, just map the image, mount, put, run
<sergiusens> chroot or what not
<sergiusens> elopio: any luck with adt on trusty btw?
<elopio> sergiusens: no sir. I forgot about that, sorry.
<elopio> I'm making a note in my todo to do it after lunch/gym.
<sergiusens> elopio: thanks!
<cyphermox> sergiusens: ok
<cyphermox> map the image?
<cyphermox> nvm, got it
<sergiusens> cyphermox: kpartx
<cyphermox> sergiusens: heh, I used losetup, but I got it already, I'm testing my fix
<slangasek> cyphermox: "why not /boot/grub" for the record, there is also a grub.cfg in /boot/grub, and if the grubcdx64.efi was capable of finding it on its own it would've done so :)
<cyphermox> slangasek: I understand, I'm trying to see if I can't make that work for you
<cyphermox> the answer seems likely to be fixing up the patch I sent to grub-devel so they're happy with it
<plars> ogra_: https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 still hasn't been merged?
<plars> or did lp just miss it somehow?
<sergiusens> plars: there is no automerging for that and it would need to go throught the store as well
<sergiusens> -t
<plars> sergiusens: so who needs to do that?
#snappy 2015-06-24
<dholbach> good morning
<fgimenez> good morning
<Chipaca> mo'in
<Chipaca> sergiusens: when you're around, could use a hand reviewing the grub branches
<Chipaca> getting "does not look like a tar" when using udf
<Chipaca> in other news, feeling much better \o/, and all my house smells delicious because i'm cooking up some chile :)
<Chipaca> ogra_: how're your teeth?
<ogra_> Chipaca, i woke up with nearly no pain at all but a golfball on my jaw :/ ...
<Chipaca> ogra_: so you've gone to see a dentist
<Chipaca> ogra_: right?
<ogra_> yeah, i fear i have to
<Chipaca> ogra_: dude, that's an abscess. you want that sorted asap.
<ogra_> yes
<ogra_> i fear there is not much to sort but get rid of the tooh
<Chipaca> they can turn really nasty. don't google it, just go :)
<Chipaca> ogra_: forget the tooth, it's the ball of rotten pus inches from your brain you should be worrying about now :D
<ogra_> if i open my mouth it is further away though :)
<ogra_> (it is the lower jaw)
<Chipaca> oh, that's alright then
<ogra_> no, not, but not as dangerous :)
<Chipaca> true, true
 * Chipaca decides not to look up statistics
<ogra_> lol
<sergiusens> Chipaca: which branch gives you that?
<sergiusens> Chipaca: does not look like a tar means an improper download maybe
<Chipaca> sergiusens: or maybe i'm using --device-part wrong
<Chipaca> sudo ~/canonical/goget-ubuntu-touch/src/launchpad.net/goget-ubuntu-touch/udf core rolling --device-part=generic-amd64_1.1_all.snap --channel edge -o wily.img --developer-mode
<sergiusens> Chipaca: you are
<sergiusens> Chipaca: that's supposed to be --oem generic-amd64_1.1_all.snap
<sergiusens> :-P
<Chipaca> d'oh
<Chipaca> sergiusens: it worked!
<Chipaca> here, let me pastebin it because it's loverly
<Chipaca> http://pastebin.ubuntu.com/11767162/
<Chipaca> sergiusens: ^
<Chipaca> sergiusens: (it was supposed to panic, right? :-p )
<Chipaca> sergiusens: and you've got a data race
<sergiusens> Chipaca: is that the last branch or one in between?
<Chipaca> sergiusens: the last one
<sergiusens> Chipaca: can you run godeps -u dependencies.tsv and rebuild?
<Chipaca> sergiusens: udf itself?
<sergiusens> Chipaca: yes
<Chipaca> sergiusens: but that'll fail, because i updated snappy manually to point at the branch you mention
<Chipaca> sergiusens: won't it?
<sergiusens> Chipaca: oh, don't use that snappy branch, it's irrelevant to u-d-f; it just needs to be on the image for updates on a running system
<sergiusens> Chipaca: it probably needs another merge from trunk
<sergiusens> Chipaca: and thanks, I will try with that branch in the meantime and figure out what's broken
<Chipaca> i'd pulled trunk and merged that branch, but anyway, rebuilding now
<sergiusens> Chipaca: yeah, this line doesn't feel right launchpad.net/snappy/partition.(*Partition).BootloaderDir(0xc208059700, 0x0, 0x0)
<sergiusens> Chipaca: which is most likely the developer mode stuff that landed
<Chipaca> sergiusens: i'll wait for you to fix then?
<sergiusens> Chipaca: I would want all the other developer-mode branches to land first; just godeps it
<sergiusens> no need to wait
<Chipaca> k
<Chipaca> sergiusens: forwards, or back?
<Chipaca> ah, you mean the godeps you suggested above
<Chipaca> which i've already done
<Chipaca> but still got the error
<Chipaca> because merge
<Chipaca> bzr revert'ed and trying again
<Chipaca> sergiusens: i have good news, and bad news :)
<Chipaca> the good news is that i think it worked :)
<Chipaca> the bad news is i build udf with -race
<Chipaca> and it's not happy
<Chipaca> http://pastebin.ubuntu.com/11767220/
<sergiusens> Chipaca: oh thanks, now I have something fun to do today!
<Chipaca> sergiusens: you're welcome!
 * Chipaca turned his sarcasmeter off
<sergiusens> Chipaca: oh, I am indeed happy :)
<zyga> hey, who'd like to work with me to create a snap out of network manager
<zyga> I tried to get started with deb2snap but it's not possible to handle n-m yet
<zyga> and I kind of wonder what approach to use
<zyga> should I built nm and its dependsncies myself
<zyga> or try to reuse the existing packaging
<zyga> then I wonder how to bridge network hardware to n-m
<zyga> (and keep it dynamic so I can plug hardware later and still see it)
<zyga> and how to start all the deamons that nm needs
<zyga> and how to integrate that with udev on the device
<zyga> sergiusens, ogra_: ^^ any hints?
<verterok> morning
<zyga> ogra_: for networking, I remember what you said earlier about not depending on the core, for testing (wired) networking, should we bundle network tools (ifconfig, ping) or would you consider that to be an overkill
<ogra_> zyga, no idea, thats an "architect" question ...
<zyga> ogra_: who should I ask?
<ogra_> dunno
<ogra_> lool, tvoss or ricmm perhaps
<zyga> lool: ^^
<ogra_> i guess the low level bits will be in the image ... but something as high level as NM might have to become a framework or some such
<ogra_> and it isnt even clear if we keep the if* tools or perhaps switch to systemd's network management daemon
<zyga> ogra_: hence I want to understand how we should rewrite our network tests
<lool> zyga: you should bundle network tools, yup
<zyga> lool: during testing we'll also reconfigure networking
<lool> that's ok
<zyga> lool: will systemd undo/change any of our changes?
<lool> zyga: not systemd
<lool> zyga: it's using ifupdown ATM
<lool> only eth0 comes up automatically
<zyga> yes, I know but I recall that you want to move
<zyga> and ifupdown is rather static
<zyga> but systemd might be more proactive (I don't know)
<lool> zyga: we aren't there yet though
<tomconte> Hi guys, do you know what is the status of Snappy images on Azure? I tried to create a few VMs and they all hang at 'Provisioning' time
<mvo> utlemming: do you know if there is a issue with azure right now? see tomconte questions one line above
<mvo> tomconte: utlemming may know, but he is US timezone so the answer might be delayed
<tomconte> NP thanks! the image I tried was something like Ubuntu-15.04-Snappy-core-amd64-edge-201506190757-94-en-us-30GB
<elopio> hey sergiusens, I could use adt-run from trusty passing the ip of the testbed.
<elopio> can you paste the error you are getting please?
<sergiusens> elopio: I got logged out, I can try again
<sergiusens> Chipaca: hey, forgot to send this your way https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/downloadRace/+merge/262851
<sergiusens> mvo: thanks for getting those MPs in
<mvo> sergiusens: hey, have you tested the lp:~sergiusens/livecd-rootfs/byeByeDebbie ? i.e. will apparmor work?
<mvo> sergiusens: yw!
<sergiusens> mvo: only manually tested; I can do some more live testing than more than hello-world
<sergiusens> with more than*
<sergiusens> mvo: btw, using the partition.new code in developer mode checks broke u-d-f :-P
<mvo> sergiusens: *cough* sorry for that, do you want me to do a branch?
<mvo> sergiusens: if hello-world works, thats probably good enough
<sergiusens> mvo: no, no worries, it just caught me by surprise :-)
<elopio> fgimenez: I changed the hangout name (once again) to not bother davmor2
<elopio> in case you are in the other one.
<fgimenez> elopio, np, one minute
<davmor2> elopio: now I'm going have to beat you for bothering me again,  Consider yourself beaten ;)
<elopio> davmor2: you asked for it
<sergiusens> mvo: btw, ubuntu-snappy is failing to build
<jdstrand> mvo: re byebyeDebbie-- we are talking about dpkg being gone right? /var/lib/dpkg/info/* will still be part of the readonly rootfs?
<sergiusens> mattyw: I found your issue, well there's two actually, one is preventing the install
<sergiusens> mattyw: if you introduce a security-override, aside from the apparmor entry you need to provide a seccomp one as well
<sergiusens> mattyw: additionally, the apparmor profile has a read_path with a relative path, not sure why
<sergiusens> mattyw: wrt seccomp, https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Seccomp
<mattyw> sergiusens, thanks for looking into it, I know very little about apparmor and seccomp - this is my introduction to them :)
<Chipaca> fgimenez: so!
<Chipaca> fgimenez: i am become help
<fgimenez> Chipaca, yes thx! :) let me paste the latests results...
<sergiusens> mattyw: we all do, but luckily jdstrand knows some more, in any case the wiki has a simple yaml example for seccomp. You might also do an initial try on not requiring this apparmor override at all
<fgimenez> Chipaca, well, before of that, i'm creating the chroot with 'mk-sbuild --arch=armhf wily' is that ok?
<mattyw> sergiusens, juju trys to read /etc/os-release - I was getting app armour errors when trying to run it
<sergiusens> mattyw: I see little sense in checking the release there as I guess you enable features depending on that entry and that probably means you toggle a lot of apt stuff which is just not there
<Chipaca> fgimenez: sounds about right :)
<mattyw> sergiusens, that's likely true, but I thought I'd try to get it working in snappy as is, then go back and re examine - it's a good excuse to learn about apparmor etc
<sergiusens> Chipaca: fgimenez are you going to do native qemu driven builds?
<Chipaca> fgimenez: what are we building, btw?
<sergiusens> mattyw: right, just add the leading slash there ;-)
<mattyw> sergiusens, that's just a plain bug, thanks for spotting it :)
<fgimenez> sergiusens, Chipaca i'm trying to build the snappy debs including the test ones using sbuild, not sure if that implies native qemu
<Chipaca> fgimenez: using sbuild, yes, it involves qemu
<sergiusens> elopio: in any case ./run-checks is broken for me on trusty when adt is installed
<Chipaca> at least, i think so
<Chipaca> fgimenez: or it might not! let me to the sbuild here too
<sergiusens> Chipaca: it does if doing native (qemu-static-$arch)
<sergiusens> err qemu-$arch-static
<Chipaca> sergiusens: âThe auto-cross-builder runs in a fairly strict mode: in particular, it does not have qemu-user-static installed in either the host filesystem or the build chroots (previous incarnations did, but that is less useful for porting to new architectures)â
<sergiusens> it may fail plenty
<fgimenez> Chipaca that might explain the error i'm finding, i've read somewhere about it being related to qemu... anyway, here it is: http://paste.ubuntu.com/11768227/
<fgimenez> sergiusens, ^
<Chipaca> ah!
<Chipaca> yes
<Chipaca> yes, that's qemu
<Chipaca> failing
<elopio> sergiusens: I didn't try that directly because I have trusty in a kvm, and I can't create another inside as ./run-checks does.
<elopio> what I did was to take our branch that passes an ip and port instead of installing the image in a vm.
<sergiusens> elopio: oh, the bzr bd part of run-checks is what is bad
<elopio> if your error is building the image, I can try trusty from a live cd. If it is on adt-run, I should be able to reproduce it this way.
<sergiusens> elopio: it ignores what platform you are on so a 15.04 snapshot would be built with wily (or trusty or *) deps when it need be built with vivid ones
<Chipaca> fgimenez: so. You're needing the armhf package to install it in the image?
<elopio> sergiusens: ah, that's because of your customized builder in bazaar conf.
<elopio> or not.
<sergiusens> elopio: it doesn't matter; if I remove that, it would build on trusty but it needs to have been built on a wily system
<fgimenez> Chipaca, yes, until we are able to get the image from the branch we should be able to compile them to install in the boards, what would be a good approach for that?
<elopio> sergiusens: we can specify a --builder in bzr bd to select those options.
<Chipaca> fgimenez: which are the packages you need?
<elopio> and we also copied your flag for receiving debsDir, so if you want to build the debs on your own, you just pass the dir.
<sergiusens> elopio: right, if I build the debs on my own that means it can't really be part of run-checks, can it?
<sergiusens> elopio: the only thing my bazaar.conf does is define a builder ;)
<sergiusens> elopio: but it fails to understand -uc and -us
<fgimenez> Chipaca, we need the ubuntu-snappy packages from a branch, including the tests one to be installed on the boards http://bazaar.launchpad.net/~fgimenez/snappy/cross-compile-debs/view/head:/debian/control for instance
<sergiusens> elopio: and it's something that needs to be built in to run-checks (passing --builder) so we all run the same thing
<elopio> sergiusens: that's because the -uc -us are for debuild, and you are using sbuild.
<elopio> if we always pass --builder debuild -- -uc -us it could work.
<elopio> what I don't know is how to tell debuild to build for vivid or wily.
<sergiusens> elopio: yeh, but I'm saying that using --builder debuild is the wrong thing to do ;-)
<sergiusens> elopio: and the best way to convince you of that is to get you to run your main system on trusty ;-)
<fgimenez> Chipaca, ideally we should be able to build an image with them installed, so that we don't need to install them in a writable partition with dpkg (urgh), this is until we get there
<elopio> trusty, ugh... :)
 * Chipaca building a chroot by hand
 * Chipaca wonders whether making a snappy to build amrhf snaps would win him brownie points
<elopio> sergiusens: we could always use --builder sbuild. But then we have to document on the README the schroots that we need.
<elopio> I see no problem about that.
<sergiusens> elopio: I'll create a branch for that as this basically blocks me from testing anything easily
<elopio> I wonder if this would be easier with .dsc or .changes.
<Chipaca> well
<Chipaca> seems we have a broken wily build right now?
<Chipaca> src/launchpad.net/snappy/cmd/snappy/cmd_login.go:27:2: code in directory /tmp/cross-compile-debs/obj-x86_64-linux-gnu/src/code.google.com/p/go.crypto/ssh/terminal expects import "golang.org/x/crypto/ssh/terminal"
<elopio> sergiusens: thanks.
<elopio> fgimenez: either the test finishes before the reboot and it never happens, or it receives the segkill.
<elopio> the only option I see is to do the reboot outside of the test binary.
<elopio> we can do that with a wrapper script, and leaving a file /tmp/needs-reboot or something.
<fgimenez> elopio, sounds good, it can play well with adt-run
<fgimenez> Chipaca, i saw something similar, in my case it was looking for dependencies in /usr/share/gocode (which belongs to root) instead of the defined $GOPATH, don't know if it might be related
<Chipaca> fgimenez: i got to the point where it got building, but then failed on some bits that don't work for cross-compiling. i'll retry in a bit
<Chipaca> fgimenez: is it bad if i skip the package build tests?
<Chipaca> that is, i don't run the tests during package build of this package
<fgimenez> Chipaca, i think so, elopio? ^
<elopio> Chipaca: not if you are running from ./run-checks.
<elopio> when you ./run-checks, it will run the tests, and then run them again during the bzr bd.
<Chipaca> yep
<Chipaca> except i was hoping to not have to get the tests to pass inside a bodged up chroot :)
<fgimenez> Chipaca, elopio leaving, will catch up tomorrow
<Chipaca> sergiusens: is there a way to make dh_golang specify -ldflags?
<sergiusens> Chipaca: no, I wish there were
<sergiusens> Chipaca: I also wanted to do some neat tricks with package building for autogen'ed stuff
<Chipaca> sergiusens: this will make my evil plan of compiling snappy with musl a lot harder
<sergiusens> Chipaca: heh, if dh_golang had prov and build in different steps it would be rather easy though
<sergiusens> Chipaca: btw https://code.launchpad.net/~sergiusens/snappy/seccomp/+merge/262880
<sergiusens> oh snap, my fingers copied an extra line there :-P
<sergiusens> there we go
<cyphermox> elopio : just checking, do you know if today's snappy personal EFI image booting properly now?
<elopio> cyphermox: I didn't know it wasn't booting properly before. I haven't touched personal yet.
<cyphermox> Ah, OK. sergiusens suggested you'd know :-)
<Chipaca> sergiusens: +1
<Chipaca> and i'm off to have glorious, glorious dinner
 * Chipaca 's been smelling it all day
<elopio> Chipaca: mmm, enjoy.
<sergiusens> cyphermox: oh, you meant personal?
<sergiusens> cyphermox: we don't qa personal, that's on the personal team
<elopio> cyphermox: I can give it a try. I think I just need to build ubuntu-device-flash from source.
<elopio> s/source/trunk.
<sergiusens> elopio: it's in wily now fwiw
<elopio> sergiusens: ah, that's good. Thanks.
<sergiusens> elopio: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.25-0ubuntu1
<elopio> sergiusens: what does that personal-oem contains?
<cyphermox> sergiusens : sorry, I wasn't clear enough, I mean the same image that seb reported didn't boot successfully in UEFI
<cyphermox> I can just as well test it myself later if having it working isn't an omg-fire :-)
<sergiusens> cyphermox: ok, so I have no efi machine, it's just a seb thing :-)
<cyphermox> OK. Well it can be tested with qemu and OVMF, but I'll play with it tonight :-) I don't want to distract you from more important things
<elopio> cyphermox: that sounds interesting, and something we should automate somewhere.
<elopio> I'll make a card to test with https://wiki.ubuntu.com/UEFI/OVMF
<elopio> sergiusens: if we run the selftests on an image with personal-oem and a qemu with ovmf, do you think we should put that in lp:snappy ?
<cyphermox> Elopio : I can share with you the qemu options to use
<elopio> cyphermox: yes, please.
<elopio> https://trello.com/c/I1BSZ6iV/130-run-tests-for-snappy-personal-and-uefi-boot
<tomconte> utlemming: Hi, do you know what is the status of Snappy images on Azure? I tried to create a few VMs and they all hang at 'Provisioning' time
<utlemming> tomconte: which image?
<tomconte> utlemming: the image I tried was something like Ubuntu-15.04-Snappy-core-amd64-edge-201506190757-94-en-us-30GB
<utlemming> tomconte: there is a bug with Snappy on Azure that needs to be fixed, that we have been trying to clear. I'm waiting for feedback from Microsoft.
<utlemming> tomconte: but, yeah, I am waiting that situation. The issue is that the /writable partition is not being seen at boot.
<utlemming> s/waiting/watching/
<tomconte> utlemming: I can try to help, could you forward me the issue or add me to the email loop ?
<tomconte> utlemming: I am from Microsoft :)
<utlemming> tomconte: yeah, let me see if I can dredge up the bug report on it
<sergiusens> Chipaca: do you have a minute for a hangout?
<Chipaca> sergiusens: now i do
<Chipaca> elopio: https://goo.gl/photos/73DdNVzZYeEa1ZMb9
<rsalveti> sergiusens: elopio: so let's target the next stable release for july 10, since next week we're going to have a new kernel
<rsalveti> so target for first RC could be july 6
<rsalveti> elopio: would probably be good to do another round of bug triaging as well, so we can target possible fixes or backports we can still work on during next week
<rsalveti> https://launchpad.net/snappy/+milestone/15.04.2 with the date
<Chipaca> sergiusens: am going to be around for a while, but am officially breaking out the beer in a few
<sergiusens> Chipaca: ok, just wanted to talk about _$version and the future
<sergiusens> Chipaca: https://plus.google.com/hangouts/_/canonical.com/days_of_future_past
<elopio> rsalveti: great, thanks.
<sergiusens> rsalveti: the problem with google docs instead of VCS is that it's hard for people to spot the updates ;-)
<marcoceppi> hello! I have a raspberrypi2 and I'm trying to figure out how to flash it...
<marcoceppi> I found this: http://people.canonical.com/~platform/snappy/raspberrypi2/ but I have no idea what I'm doing
<sergiusens> marcoceppi: http://developer.ubuntu.com/en/snappy/start/#snappy-raspi2
<sergiusens> marcoceppi: with the images you found there
<marcoceppi> sergiusens: thanks!
<sergiusens> alecu: kyrofa do you know how eaasy or hard it is to see changes in a google doc? I was udating here and there
<alecu> sergiusens: we can only see the revision history if we have Edit permission
<alecu> sergiusens: "File->See revision history..."
<sergiusens> alecu: then yiu shall get them!
<sergiusens> alecu: there!
<alecu> sergiusens: the history view is not great, but it aggregates changes that happened close in time, so it's possible to understand what was changed.
<alecu> sergiusens: I'll try reloading, thanks.
<alecu> sergiusens: looks good, thanks.
<rsalveti> sergiusens: Chipaca: elopio: what are we missing for https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 ?
<elopio> rsalveti: one review.
<rsalveti> sergiusens: Chipaca: can either of you guys take another round of review for that branch ^?
<Chipaca> rsalveti: sure
<Chipaca> rsalveti: in the morning :)
<rsalveti> Chipaca: sure :-)
<Chipaca> elopio: for future reference, it's likely i would have reviewed it by now if it weren't asking for a review from mvo explicitly
<Chipaca> or more likely, at least :)
<elopio> Chipaca: I added mvo just this morning, thinking that a direct ping to somebody would speed things up ;)
<Chipaca> elopio: orly?
<Chipaca> elopio: my apologies then!
<marcoceppi> getting an error when trying to boot on the ubuntu matchbox rpi2
<marcoceppi> systemd failes to load default taget: no such file or directory,?
<marcoceppi> https://lh3.googleusercontent.com/kbsG4MKVxq6SbdiCHgKnf1ttfZcSdBUf-f4RAYn1W3dF=w1342-h993-no
#snappy 2015-06-25
<dholbach> good morning
<Chipaca> mo'in
<JamesTait> Good morning all; happy Global Beatles Day! ð
<Chipaca> fgimenez: gave up on cross-compiling
<Chipaca> fgimenez: it'll be easier and quicker to build the packages 'by hand'
<Chipaca> fgimenez: if building on the device is not an option, that is
<Chipaca> fgimenez: now reviewing your funcitonal tests branch
<fgimenez> Chipaca, ok np thanks a lot :)
<fgimenez> Chipaca, i'm also exploring the cross toolchain path, no luck so far either
<Chipaca> fgimenez: give me a shout when you want me to re-review that branch. looks mostly good.
<Chipaca> mostly <=> needs fixing, but minor
<fgimenez> Chipaca, ok, it'll be ready shortly thanks :)
<Chipaca> fgimenez: you realise GOARCH will be arm, not armhf, on arm boards?
<Chipaca> fgimenez: and 386, not i386, on i386 boards
<fgimenez> Chipaca, yes, i've seen the function you mentioned in the helpers, it takes care of the change, do you think we should mimic it's behaviour here?
<Chipaca> fgimenez: what are you using defaultArch for, now and in the future?
<fgimenez> Chipaca, i mean, if we are going to execute the tests from that platforms we need to do the change
<Chipaca> fgimenez: if it's for building the triplet or whatever it is, yes you need to do that
<Chipaca> yeah
<Chipaca> fgimenez: I'd say yes, then
<fgimenez> Chipaca, ok, i'll put the function then
<fgimenez> Chipaca, there's an arch parameter, that's what will be used for building the debs/image, right now the defaultArch helps to determine if you have to cross compile (if defaultArch != arch)
<fgimenez> Chipaca, but indeed 386 != i386
<Chipaca> :)
<fgimenez> Chipaca, :) it'll be ready soon thanks!
<sergiusens> morning
<fgimenez> Chipaca, done
<fgimenez> hey sergiusens
<sergiusens> fgimenez: pretty please can you get rid of the dpkg -i from the tests? This won't work soon-ish
<sergiusens> ogra_: feeling better today?
<sergiusens> ogra_: if you do, mind reviewing https://code.launchpad.net/~sergiusens/livecd-rootfs/no-walinuxagent/+merge/262963 ?
<Chipaca> sergiusens: he hasn't said a peep all day
<sergiusens> Chipaca: he did review one of my MPs :-P
<fgimenez> sergiusens, ok, we are carrying this from the shell version, are there any progress in the image creation from the branch?
<ogra_> sergiusens, only partially... just returned from the dentist and i'm full of painkillers and antibiotics (they can extract the tooth only on monday once i got rid of that golfball on my jaw)
<sergiusens> fgimenez: I am not tracking that, but we want to get rid of dpkg ASAP, even if it means breaking to not go down the path of never being able to remove it like on the phone
<ogra_> but for a code review it will be good enough :)
<sergiusens> ogra_: strong liquor can't get the job done wrt the pain?
<rsalveti> ogra_: :-)
<sergiusens> :-)
<ogra_> sergiusens, i'll try that tonight ... ;)
<fgimenez> sergiusens, ok, i'll put hands on it
<ogra_> sergiusens, what if we need to re-build 15.04 stable azure images ?
 * ogra_ guesses we need to check which livecd-rootfs is used for them ... if its the wily one that code dropping wont work but needs release checks)
<sergiusens> ogra_: there's a livecd-rootfs in the ppa as well
<ogra_> ah, and that is used for 15.04 builds ?
 * ogra_ goes to check the logs 
<ogra_> Get:1 http://ppa.launchpad.net/snappy-dev/image/ubuntu/ vivid/main livecd-rootfs armhf 2.301~ppa7 [32.3 kB]
<ogra_> looks fine then
<sergiusens> ogra_: I was told that was the case, but confirming would be good
<sergiusens> yay :-)
<sergiusens> ogra_: doesn't an image build for vivid pick up the livecd-rootfs for vivid?
<ogra_> yes, but the PPA has higher prio so it doesnt pick the one from the archive
<sergiusens> ogra_: great, in any case this would be pushed to wily only so it doesn't really matter anyways, does it?
<ogra_> no, it is all fine, just wanted to make sure we dont break anything for that case
<sergiusens> \o/
<ogra_> sergiusens, top approved
<sergiusens> ogra_: should I get rsalveti to dput?
<ogra_> sergiusens, nope, on it
<sergiusens> thanks
<sergiusens> ogra_: I might be pushing it, but here's one more ;-) https://code.launchpad.net/~sergiusens/ubuntu-seeds/no-python-for-core/+merge/262966
<ogra_> oh, wow ... well, system-image will still pull in some python i guess
<ogra_> (py3 though)
<sergiusens> ogra_: python3 is still there :-)
<sergiusens> ogra_: they are different languages, one is called python and the other python3 ;-)
<ogra_> yeah
<sergiusens> if they were the same, there would only be 'python' pointing to whatever version :-P
<fgimenez> sergiusens, i've removed dpkg from https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748, the tests are built locally and copied to the testbed, let me know what do you think
<ogra_> sergiusens, i wonder if an announcement mail would make sense before merging https://code.launchpad.net/~sergiusens/livecd-rootfs/byeByeDebbie/+merge/262786 so people are prepared
<Chipaca> sergiusens: i get what dpkg-deb is being kept for; what's dpkg itself kept for?
<sergiusens> Chipaca: I don't know, I know why I'm removing all others
<sergiusens> Chipaca: and it's not that big
<Chipaca> sergiusens: ok :)
<sergiusens> Chipaca: and I don't want to test all over again and maybe it's due to dpkg --print-architecture
<sergiusens> ogra_: nah
<sergiusens> :-)
<sergiusens> it's rolling!
<seb128> sergiusens, ogra_, I wonder if that change should be done to ubuntu-desktop-next at the same time
<sergiusens> seb128: well I did do this one for you guys https://code.launchpad.net/~sergiusens/livecd-rootfs/no-walinuxagent/+merge/262963 :-)
<sergiusens> seb128: although I'm not sure why you had it in the first place ;-)
<seb128> sergiusens, thanks ;-)
<seb128> sergiusens, we copied the ubuntu-core hooks to start
<seb128> so we had it because core had it :p
<sergiusens> seb128: fair enough, wrt dpkg/apt, I don't mind replicating that to desktop next
<seb128> I'm unsure if we decided on what we want the personal image to be
<seb128> having apt is useful for debugging, but I guess people who want it can wget & dpkg(-deb)
<sergiusens> seb128: I would prefer someone being encouraged to bring all these tools to a snap :-)
<sergiusens> but whatever gets the job done!
<seb128> yeah
<seb128> I need to try ubuntu-core to see if /etc/default/locale is missing there as well
<seb128> oh, and if recovery mode is working
<seb128> on personal it just do a normal boot
<sergiusens> seb128: we do have /etc/default/locale on core
<sergiusens> ogra_: oh, adduser is perl...
<seb128> sergiusens, right, you have a live-build/ubuntu-core/hooks/13-set-locale.chroot
<seb128> unsure why we didn't copy that one
<ogra_> sergiusens, yeah :/
<seb128> we should ;-)
<sergiusens> seb128: locale should probably be an ubuntu-core config thing and we should be able to set it up on first boot
 * sergiusens creates teask
<sergiusens> err, task
<seb128> sergiusens, can you include keyboard layout in that?
<sergiusens> seb128: yes
 * seb128 is tired to type loadkeys fr after every boot
<seb128> thanks
<ogra_> seb128, are you doing the locale thing now ?
<seb128> ogra_, adding the file you mean? was about to, but if you have pending commit feel free to get that done first and let me know when I can do the change
<ogra_> seb128, well, i was about to ask if you could merge https://code.launchpad.net/~sergiusens/livecd-rootfs/byeByeDebbie/+merge/262786 along :)
<ogra_> saves wrangling in the branch
<seb128> ogra_, you mean adding the same diff to desktop-next?
<ogra_> and to core ...
<ogra_> i didnt merge it yet
<seb128> oh, if you want sure
<ogra_> thanks
<seb128> yw
<seb128> ogra_, should I wait for it to be top approved though?
<ogra_> you can ... one sec :)
<ogra_> *click*
<ogra_> done ;)
<seb128> :-)
<olli> pardon my stupidity... if I wanted to put the snappy core image onto physical x86 HW, do I just dd the image onto the disk?
<mvo> olli: yes or to a usb stick
<olli> nice
<olli> mvo, also, nw config on core/snappy ... is there any way to set a fixed IP
<olli> not sure I saw that in the wiki
<ogra_> just edit /etc/network/interfaces.d/eth0
<ogra_> (defaults to dhcp usually)
<olli> that's writable
<olli> ok
<olli> great
<seb128> mvo, can you dd to a partition or does it need to take all disk? and how do you configure grub then?
<elopio> fgimenez: meeting.
<mvo> seb128: all disks currently, it relies on a certain partiton layout and partition labels
<ogra_> olli, the whole dir is (in case you want to create a wlan0 or some such at some point)
<seb128> mvo, k
<olli> ogra_, I am covered then
 * ogra_ nods
 * olli is preparing the matchbox to become his home "gateway"
<ogra_> heh, with two USB NICs ?
<olli> hence the ""
<ogra_> :)
<olli> it'll be my inet accessible machine
<ogra_> we need images for alix boards :)
<ogra_> (my favorite home router HW)
<ogra_> rsalveti, sergiusens, any idea why we forcefully install flash-kernel into the snappy armhf rootfs ? (nothing makes use of it in our system design or does it ?)
<sergiusens> ogra_: no, it shouldn't be needed
<elopio> thanks for the review Chipaca!
<elopio> fgimenez_: lets skip our qa show today...
<fgimenez_> elopio, ok, la hora de la calidad will be back tomorrow
<elopio> :)
<fgimenez_> elopio, i've added changes in https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 to remove dpkg, the tests are built locally and copied to the testbed
<fgimenez_> elopio, seems to work good, but it's exercising the snappy shipped in the image of course
<elopio> fgimenez_: yes, for now I would stick with the deb from trunk.
<fgimenez_> elopio, ok, this makes cross compiling a lot easier/possible at all, i'll change that branch too
<elopio> fgimenez_: I think I didn't explain myself correctly. I think we need to build the deb from trunk and install it.
<elopio> but you are right that we don't need to build the deb for the tests, at least not yet.
<elopio> fgimenez_: actually, lets go to the hangout. Sorry :)
<fgimenez_> elopio, ok np :)
<fgimenez_> elopio, pushed
<elopio> fgimenez_: thank you!
<elopio> fgimenez_: last thing, can you please remove the sudo from:
<elopio> 315	+	infoOutput := s.execCommand(c, "sudo", "snappy", "info")
<elopio> that was my mistake.
<fgimenez_> elopio, sure, we can remove also the buildDebs function
<elopio> fgimenez_: +1
<elopio> sergiusens: ^ fixed your bzr bd problem :)
<fgimenez_> elopio, ok, done
<elopio> fgimenez_: bash: /tmp/snappy-test/tests/snappy.tests: No such file or directory
<elopio> this fails because the -o of go test doesn't work.
<elopio> I think you will have to move snappy.tests from cwd to testsDir.
<sergiusens> elopio: go build -o does work
<sergiusens> elopio: go build -o /tmp/snappy ./cmd/snappy
<fgimenez_> elopio, i se it working here
<elopio> fgimenez_: that works, but $ go test -c ./_integration-tests/tests/ -o /tmp doesn't
<sergiusens> elopio: -o needs to be the full output file, not a path
<elopio> sergiusens: $ go test -c ./_integration-tests/tests/ -o /tmp/snappy.test
<elopio> doesn't work either.
<fgimenez_> elopio, http://paste.ubuntu.com/11773748/ with the current code, the binary seems to be there
<fgimenez_> elopio, meeting
<fgimenez_> and Chipaca, ^
<elopio> http://cdn.meme.am/images/84688.jpg
<fgimenez_> sergiusens, ogra_, tedg, elopio sorry guys, trying to reconnect
<ogra_> fgimenez_, we finished
<sergiusens> fgimenez_: no worries, we are done
<elopio> fgimenez_: we are done. You can give two updates tomorrow :)
<tedg> What they said
<fgimenez_> ok, np :)
<elopio> fgimenez_: so, if you run this, do you get the file in tmp? $ go test -c ./_integration-tests/tests/ -o /tmp/snappy.test
<elopio> if I do that on my two machines, I get the file in pwd. Nothing in tmp.
<sergiusens> elopio: go test has no -o though
<elopio> that's why I think it shouldn't work for fgimenez.
<elopio> fgimenez: maybe you already had the test in /tmp/ ?
<fgimenez> elopio, nope, http://paste.ubuntu.com/11773921/
<fgimenez> here mentions the -o flag https://golang.org/cmd/go/#hdr-Test_packages, perhaps it's outdated?
<fgimenez> elopio, what is the output of go help test for you, is the -o flag there?
<elopio> fgimenez: http://paste.ubuntu.com/11773927/
<elopio> I do the same and the file doesn't exist for me. You are on wily, right?
<elopio> what's your golang version?
<elopio> fgimenez: yes, golang test on vivid doesn't have the -o option. On wily it does.
<fgimenez> elopio, ah! ok that makes sense
<elopio> wow, it sucks that go doesn't have mv.
<elopio> fgimenez: this should work for both: http://paste.ubuntu.com/11774045/
<elopio> fgimenez: also, defaultArch, getArchForImage and ubuntuArchitecture are not used.
<fgimenez> elopio, ok pushed, when we will have multiple tests we can parameterize this without problems
<elopio> fgimenez: ok, looks good, thank you.
<kyrofa> sergiusens, ping
<sergiusens> kyrofa: pong
<kyrofa> sergiusens, I'm not sure why I didn't notice this before, but the Snappy REST doc doesn't discuss searching. Is that something you considered?
<kyrofa> The WebDM README discusses it in the v1 API, but that's the only reference I know about
<sergiusens> kyrofa: yes, simple search like today; I guess I need to add it
<sergiusens> kyrofa: do we want crazy elastic search or as it is today? (webdm and cli?)
<sergiusens> I guess the stores elastic search gets encapsulated by the API itself in most of the cases
<sergiusens> if not all
<kyrofa> sergiusens, well, correct me if I'm not mistaken but all we have today is filtering by installed or package type... no?
<sergiusens> kyrofa: no
<sergiusens> kyrofa: http://localhost:4200/api/v2/packages/?q=hello
<sergiusens> kyrofa: http://localhost:4200/api/v2/packages/?q=hello&installed_only=true
<kyrofa> sergiusens, ah, I didn't know about that! Haha
<kyrofa> sergiusens, if someone types a search query into the scope... nothing happens right now :P
<sergiusens> kyrofa: not sure you noticed, but I changed installed_only to sources=[remote,local]
<sergiusens> kyrofa: for the new api; that makes the definition of a resource look better
<kyrofa> sergiusens, I didn't notice, but I agree
<kyrofa> sergiusens, okay, so to answer your question: Can you define what you mean by elastic search?
<sergiusens> kyrofa: and I am debating if PUT should change state (installed,uninstalled) and if we should get rid of DELETE
<kyrofa> sergiusens, you mean turn PUT into a toggle?
<sergiusens> kyrofa: the store allows you to do stuff like https://search.apps.ubuntu.com/api/v1/search?q=content:%22framework%22
<sergiusens> kyrofa: but if the scope is just going to be a random search box (which makes it user friendly), I don't see much use of exposing that directly
<kyrofa> sergiusens, agreed, I don't think the scope can possibly make use of that
<sergiusens> in other words, snappy takes care of that for you
<sergiusens> or should at least
<kyrofa> Yeah, just knowing that I can use the q param fixes my problem
<kyrofa> Want me to add a comment to the REST doc?
<sergiusens> kyrofa: sure, btw, you have edit rights now too so if you want to edit or suggest feel free
<kyrofa> sergiusens, ah good deal!
<elopio> sergiusens: how is it possible that your tarmac catches lint errors that mine locally doesn't?
<elopio> aren't we all getting it from github?
<elopio> I see the errors now, it needed an update.
 * elopio fixes lints.
<sergiusens> elopio: heh, so two things can cause this, the merge causes lint errors (unlikely) or your lint package needs updating
<sergiusens> tarmac installs the latest lint on every merge
<elopio> sergiusens: it seems lint was updated recently and now it catches more errors than before. Which is nice.
<elopio> probably we should make our run_checks smarter, so it updates golint.
<sergiusens> elopio: yeah, I prefer tarmac always grabbing latest instead of having to manually do this every now and then
<sergiusens> elopio: for real success just run ./.tarmac.sh
<sergiusens> elopio: btw, do you QA approve of this https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 ?
<sergiusens> ogra_: did you trigger a new build?
<elopio> sergiusens: I do, yes. As far as I could see, it doesn't affect the reboots, updates, rollbacks.
<sergiusens> elopio: ok, I'll get it into the store in a bit
<elopio> can somebody please take a look at this? https://code.launchpad.net/~elopio/snappy/fix1468846-lint/+merge/263012
<elopio> so we can resume landings.
<sergiusens> sure
<sergiusens> elopio: strange that helpers/touch.go was not errored on before though
<ralsina> Hello! I am trying to setup snappy on kvm using https://developer.ubuntu.com/en/snappy/start/ and it seems to work, except that I can't login into the VM using ubuntu/ubuntu as it says there. Any hints/other passwords? ;-)
<bschaefer> hello, is there a 15.10 daily image of snappy core? Or a 15.10 core image sitting around? (Been testing on 15.04 and want to move up :)
<manik_> bschaefer: you can see the schedule for released images here- https://launchpad.net/snappy
<manik_> bschaefer: 15.04.1 is the latest snappy core available at the moment
<bschaefer> but there should still be a 15.10 image or from the site a rolling image
<bschaefer> manik_, thanks!
#snappy 2015-06-26
<dholbach> good morning
<fgimenez> good morning
<davidcalle> Morning all o/
<Chipaca> mo'in
<ogra_> moin moin
<mvo> hey Chipaca
<Chipaca> mvo: hi there
<Chipaca> mvo: how's the sprint? what have you broken *now*?
<Chipaca> :)
<mvo> Chipaca: sprint is interessting, we can talk next week :)
<Chipaca> mvo: ok
<Chipaca> mvo: wink your left eye if you are held against your will and can't talk about it
<mvo> lol
 * mvo winks
<ogra_> lol
 * Chipaca hopes that was the right eye
<ogra_> wasnt the left eye the right eye ?
<Chipaca> ogra_: only if was held against his will
<JamesTait> Good morning all; happy Friday, and happy Chocolate Pudding Day! ð
<ogra_> yummy !!
<ogra_> though i prefer icecream at this weather
<pitti> ogra_: mmmm, ice cream!
<ogra_> :D
<ogra_> (sadly i cant ... recovering from a jaw infection kind of goes against it :/ )
 * Chipaca -> lunch
<mvo> sergiusens: fwiw, I triggered a build with the new livecd rootfs so that we can test the deb/apt less system
<ogra_> well, semi-deb-less :)
<ogra_> dpkg itself is still there
<ljose> I have just installed snappy in beaggle board, following steps in https://developer.ubuntu.com/en/snappy/start/#try-beaglebone
<ljose> ssh ubuntu@webdm.local
<ljose> ssh: Could not resolve hostname webdm.local: Name or service not known
<ogra_> sergiusens, the shadow patch looks good to me, but i would like to have slangasek take a look before we land that (i think he looked into it before)
<ogra_> ljose, whats the system you run the ssh command on
<ljose> Ubuntu 15.04
<ogra_> (ubuntu ? )
<mvo> ogra_: :)
<ogra_> hmm, that should have the avahi daemon
<ljose> kubuntu actually
<Chipaca> ljose: and you got the 15.04 xz?
<ogra_> webdm.local is resolved using an avahi mDNS request
<ogra_> if both devices are on the same network and your desktop has the avahi bits installed it should just work ...
<Chipaca> ah, kubuntu might not have that, good point
<ogra_> i'm not sure kubuntu installs the avahi parts ... though i wouldnt know why if they dont :)
<Chipaca> kubuntu-desktop pulls it in
<Chipaca> as a task
<ogra_> yeah, would be weird if it didnt
<Chipaca> ljose: could you check you have avahi-daemon installed?
<Chipaca> wait, not the daemon
<Chipaca> hm
<ogra_> ljose, the first setip runs cloud-init to set up the user and ssh keys etc ... that can take a few minutes ... did you wait a while before trying it ?
<Chipaca> libnss-mdns
<Chipaca> ljose: ^
<ogra_> Chipaca, avahi-daemon is also a client :)
<ljose> Chipaca: more than 10 minutes
<ogra_> yeah, after 10min it should be done
<ljose>  /dev/sdd is the device and seems to have any partitions now after "dd"
<Chipaca> ljose: silly question, is the bbb's ethernet plugged in to the network?
<ljose> just USB
<Chipaca> ljose: that won't work then
<ljose> doesn't work like the original image over USB?
<Chipaca> ljose: we don't bring up the usb device
<Chipaca> ljose: no
<Chipaca> ljose: we should, probably/maybe, but right now don't
<ogra_> right, by default only the onboard ethernet is brought up on boot
<Chipaca> the usb one would be so much more convenient
<ljose> let's plug the network and see
<Chipaca> you usually plug the usb in to power the thing anyway
<ogra_> you might need to reboot
<Chipaca> at least while testing :)
<ogra_> i'm not sure webdm will start dynamically if you now plug it in
<ogra_> (geez, whats up in france !! /me just watches the news on the side)
<davmor2> ogra_: France is a big place could you be a little more specific?
<Chipaca> davmor2: beheading close to lyon
<Chipaca> http://www.bbc.co.uk/news/live/world-europe-33287095
<ljose> Same problem after connect network cable, and avahi-daemon is running, any ideas?
<ogra_> did you reboot the BBB ?
<ljose> yep
<ogra_> hmm
<ogra_> can you reach it by IP ?
<ogra_> ssh ubuntu@<IP> should work too
<ljose> I reboot the BBB but there isn't any blinking leds , that seems odd
<ljose> just the power, and network leds
<ogra_> yeah, at least during boot something should blink
<ogra_> do you have a serial cable to check the boot ?
<ljose> usb?
<ogra_> FTDI
<ogra_> something like http://www.amazon.com/Ftdi-TTL-232r-3v3-Serial-Converter-Cable/dp/B00M41OUYA/ref=sr_1_1?ie=UTF8&qid=1432041571&sr=8-1&keywords=FTDI+to+TTL+3.3
<ogra_> (pretty essential when working with embedded boards)
<ljose> I don't have this right now
<ogra_> ah, sad, would have been helpful to see whats goiing on
<ljose> should I see the flash partitions when connect the USB cable?
<ljose> I see /dev/sdd but no partitions there
<Chipaca> ljose: yes, you should see four partitions
<ogra_> no, you shouldnt
<Chipaca> no?
<Chipaca> dah
<ogra_> we dont even enable the USB gadget
<Chipaca> the usb cable
<Chipaca> no
<Chipaca> sorry
<Chipaca> the sd card, yes
<ogra_> i dont get how you see /dev/sdd though
<ogra_> since that driver isnt on in our images it shouldnt create such a device ...
<ogra_> are you sure it is booting from SD at all ?
<ogra_> (try rebooting with the user button (S2) pressed)
<ljose> I just install the image in /dev/sdd , that was the BBB device
<ljose> attached to USB on my computer
<ogra_> uh
<ogra_> thats will liekyl not work
<ljose> ok so I just mess the BBB image?
<ogra_> well, you should be able to restore the internal MMC from some debian-BBB image from beagleboard.org
<ogra_> i'm pretty sure you cant bot from a dd'ed snappy image from the internal MMC yet though ... needs an SD
<ljose> I don't follow, I need an extra SD to use Snappy with my BBB?
<ogra_> yes, currently we have no way for on-board installs
<ljose> What kind of SD? can I use a USB disk?
<ogra_> a micro SD
<ogra_> you could use USB but still ned the bootloader on SD i think
<ogra_> the initrd mounts the partitions by label ... so if you put the image on USB and have only the /boot partition on SD that would also work i guess
<ogra_> but you need the SD for booting
<ogra_> (there are surely ways to hack the /boot partition and bootloader into the MMC, but we have no automatic or userfriendly way yet)
 * ogra_ will at some point take a look at rcn-ee's installed script for the BBB so we can provide an install image 
<ljose> so dos BBB include SD card reader?
<ogra_> yes
<ogra_> well, microSD
<ljose> so I need a microSD and a reader for my PC to load the image?
<ogra_> to write it, yes
<ogra_> and if you work with embedded boards investing the $10 for a proper serial cable makes sense and saves a lot of headdache :)
<ljose> ogra_: Yes I will get one, just my first BBB project
<ogra_> :)
<mvo> meh, image build is broken
<ogra_> oh <?
<ogra_> oh, ! damn ... i saw the mail ... thoght ... ah, arm64 again ... and ignored it
<ogra_> we really really need to do something about these arch names !
<ogra_> +dnsmasq:*:16612:0:99999:7:::
<ogra_> where does that come from ?
<ogra_> did we change seeds ?
<ogra_> (doesnt look like we would want that in the core image)
 * ogra_ wonders if some of seb128's changes leaked into core via seed deps or some such 
<sergiusens> ogra_: might be the addition of ubuntu-fan
<ogra_> ah !
<seb128> ogra_, I doubt that has to do with my changes
<ogra_> still. do we really want a DHCP server preinstalled ?
<sergiusens> ogra_: if we want ubuntu-fan I don't see a way out of it
<seb128> sergiusens, ogra_, btw, tried to build a personal image today for some reason I can't log in with ubuntu/ubuntu
<ogra_> seb128, yeah, not blaming you, rather a mis-setup of our seed deps that is exposed now ... but what sergiusens says is more likely
<ogra_> seb128, well, i doubt you have cloud-init installed ?
<seb128> ogra_, we do
<ogra_> (which sets up the account on first boot)
<seb128> which is creating a boot timeout
<seb128> cf #ubuntu-desktop log from earlier
<ogra_> oh, and do you see it setting up the account ?
<seb128> I guess not
<ogra_> it is quite wordy on console when doing it
<seb128> it errors loop on url_helper warnings about trying to call http://109-04-04/...instance-id
<seb128> then timeout after 90s
<ogra_> sergiusens, well, do we want ubuntu-fan actually *inside* core in the long term ?
<seb128> so I guess that fails
<ogra_> i thought that was only a temporary thing
<sergiusens> ogra_: it's like this, we either need a framework for frameworks or it needs to be in core :-/
<ogra_> then we need a framework
<ogra_> core should really only offer an embedded os ... not fancy stuff imho
<sergiusens> ogra_: a framework that frameworks can depend on
<sergiusens> ogra_: and that breaks the rule for frameworks
<ogra_> yeah, whatever works :)
<sergiusens> ogra_: in any case, you can revert the seed change and we can think of this
 * ogra_ leaves the details to the architects ;) 
<sergiusens> heh, another problem for lool to solve
<sergiusens> :-)
<ogra_> :)
<seb128> I guess cloud-init is not hitting the same timeout errors on core atm?
<seb128> I wonder if that's a local issue
<ogra_> no. it works fine
<seb128> does it need to access the internet to boot?
<ogra_> it might expect an eth0 device
<seb128> not sure what http://109-04-04 is
 * ogra_ neither 
<seb128> but it was working on the image from a week ago
<seb128> weird
<ogra_> i never looked at cloud-init ... i only always see the ton of messages on first boot ...
<ogra_> sergiusens, well, i dont think we should change seeds back right now,  someone might expect fan asap ...
<ogra_> but we should start a discussion, imho adding stuff like dnsmasq is wrong
<ogra_> (what if i ship a snap using isc-dhcpd for netbooting my thin clients from my thin client server snap ... they will clash and break)
<sergiusens> ogra_: right, I would unseed for now, no one was expecting this today
<ogra_> oh, ok
<ogra_> to not be broken over the weekend
<sergiusens> seb128: the only reason I think your login could be broken is if for some reason the ssh host keys failed to be created and it cloud-init bailed on you
<sergiusens> seb128: oh, and why do you have cloud-init?
<ogra_> because he has no user at all otherwise
<seb128> sergiusens, dunno, because core has it and we started from there?
<ogra_> seb128, i guess you want to port the touch user creation bits for now ... and drop cloud-init
<sergiusens> seb128: I would remove it, but we can accomodate for it, I'm not sure the 'personal' target has the nocloud seed creation going on
<seb128> ogra_, sergiusens, unsure what needs changing? seeds? livecd-rootfs?
<ogra_> seb128, seeds to drop cloud-init ... livecd-rootfs to move over the user creation from touch
<seb128> ogra_, k, let me find the user creation bits
<seb128> why is core using cloud-init rather than doing it the touch way?
<ogra_> seb128, 01-setup_user.chroot
<seb128> ogra_, danke
<ogra_> cloud-init brngs the ssh config
<ogra_> *brings
<ogra_> touch has ssh off by default
<sergiusens> mvo: http://paste.ubuntu.com/11778540/
<sergiusens> mvo: I can push that to the ppa if you want (took me 10s to make the code change and 30 minutes to rebuild a test package :-P)
<ogra_> sergiusens, mvo http://paste.ubuntu.com/11778546/ ... that would fix the build error
<ogra_> but not sure if we want that ... or instead revert the seeds and have a proper discussion first
<ogra_> sergiusens, not sure you saw my ping above ... technically it looks correct to me, but i would feel better if someone like slangasek could take a look and sign it off ... he has looked at adduser before
<ogra_> (and might know things we dont)
<sergiusens> ogra_: I saw it, but slangasek will only be avail in 3 hours :-)
<ogra_> (there are twi whitespace changes you might want to fix btw)
<sergiusens> ogra_: and I was just fixing something mvo pointed out :-)
<ogra_> *two
<ogra_> line 135/136 and 144/145
<ogra_> but thats just nitpicking :)
<sergiusens> sure
<sergiusens> but this quilting business is so tiresome :-P
<ogra_> heh
<sergiusens> ogra_: there, vorlon has been _mentioned_ in the card
<ogra_> :)
<sergiusens> ogra_: just for you http://paste.ubuntu.com/11778568/
<ogra_> haha, thanks :)
<ogra_> so much shorter all of a sudden :P
<sergiusens> ogra_: paste needs to learn how to color patches with a patch ;-)
<ogra_> i'm surprised /var/lib/extrausers/shadow is already in defines.h
<sergiusens> ogra_: that's added in debian/patches/1010_extrausers.patch
<sergiusens> ogra_: here you go http://paste.ubuntu.com/11778582/
<ogra_> aha, mterry
<ogra_> ah, thats for the phone
<ogra_> (i think i even signed it off back then :P )
<dholbach> fgimenez, elopio, balloons: https://wiki.ubuntu.com/Snappy
<dholbach> (and subsequent pages)
<dholbach> feel free to change/add as you see fit
<ogra_> oldschool \o/
<ogra_> now we just need a gdoc -> wiki importer :)
<dholbach> haha
 * mvo is in a meeting
<ogra_> poor guy
<balloons> dholbach, woot
<sergiusens> ogra_: I can make the extrausers thing without the toggle thing as well if you want
<ogra_> no, the toogle is good i think
<lool> sergiusens: I'm not a fan of that idea
<lool> the ubuntu-fan framework of frameworks
<sergiusens> lool: no one is
<sergiusens> lool: so in core it is for now
<ogra_> lool, i'm not a fan of shipping a dhcp server :)
<ogra_> (in core that is)
<lool> I'm not a fan of fan in the first place
<ogra_> we might want to consider cloud vs core seeds for snappy
<ogra_> i assume fan has its fans in the cloud :)
<lool> a fan to move the cloud
<lool> fantastic idae
<sergiusens> lol
<ogra_> :D
<mvo> sergiusens: "++	(void) fputs (_("  -E, --extrausers              Use the extra users database\n"), usageout);" the -E is still there in the help output
<ogra_> sergiusens, oh, line 76 could use indentation fixing
<ogra_> hmm, 83 to 85 too
<ogra_> yay for tabs vs spaces
<elopio> good morning.
<elopio> thanks dholbach!
<elopio> do you want to hangout today fgimenez ?
<fgimenez> elopio, as you like, don't have too much to say, all the merges are already done
<elopio> fgimenez: thanks for that.
<elopio> I'll merge yours too.
<fgimenez> elopio, ok thanks
<elopio> fgimenez: lets skip today. I talk too much, you need some free time from me :)
<fgimenez> elopio, ok np :)
<sergiusens> ogra_: hmm, mvo left, the latest diff didn't have that -E
<sergiusens> ogra_: and the whole file is mixed
<sergiusens> ogra_: hmm,
<ogra_> hmm
<sergiusens> I'll fix all of those
<sergiusens> ogra_: mvo http://paste.ubuntu.com/11778888/ (the -E was already fixed in diff you missed)
 * sergiusens raises fist at nothing (the lack of vcs)
<mvo> sergiusens: ta!
<ogra_> sergiusens, heh, but the whitespace change on the two comment lines is back ...
<sergiusens> mvo: and I was thinking if maybe this should be an implicit thing now (more invasive diff though)
<ogra_> just leave it though before it gets messed up again
<sergiusens> ogra_: oh, I need to manually remove those :-P
<sergiusens> ogra_: there you go http://paste.ubuntu.com/11778897/
<ogra_> heh, thanks :)
<sergiusens> mvo: what do you think of implicit vs explicit?
<mvo> sergiusens: hm? sorry, lacking context (plus meetings)
<ogra_> sergiusens, as long as it is *plicit :P
<sergiusens> mvo: instead of -E, if /etc/passwd and friends fail to lock to try and use the extrausers ones
 * ogra_ wouldnt do any automation here ... in case we want to upstream it 
<ogra_> it is more likely to be included if it is swiatchable
<ogra_> -a
<mvo> sergiusens: explicit sounds better to me
<mvo> sergiusens: do we need adduser at all (asking, no idea if yes or no) :)
<ogra_> well, we need some tool to add users ...
<ogra_> if we dont use the default (adduser) as documented everywhere for ubuntu, we need to have specific docs explaining how to add users then
<ogra_> personal might want it though
<ogra_> for multiuser desktops
<sergiusens> mvo: ok, let's keep it explicit, and we need it for cloud init as well
<sergiusens> ok then, we are good to go then
<mvo> sergiusens: ok
<mvo> sergiusens: ta
<ogra_> pitti, so this seed change ... is that a hard req now ?
 * ogra_ feels rather uneasy about it
<ogra_> sergiusens, seed revert done ... (i'll wait one publisher run before kicking the image, not sure when the task generation happens)
<Chipaca> sergiusens: mvo: elopio: fgallina: http://npf.io/2015/06/testing-exec-command/
<elopio> cool, thanks Chipaca.
<elopio> I'm puzzled about this: http://paste.ubuntu.com/11779125/
<elopio> the build works with the default arch, but fails using GOARCH=arm.
<sergiusens> elopio: you need more than just goarch, look at webdm's build script
 * elopio looks.
<Chipaca> elopio: or alternatively read doc/cross-build.md
<Chipaca> sergiusens: ^
<elopio> Chipaca: hah, that's the second time you tell me that. Sorry.
 * elopio bookmarks the cross-build.
<Chipaca> :)
<elopio> I was missing one of the packages.
<fgimenez> nice weekend everyone o/
<slangasek> ogra_, sergiusens: I didn't look at adduser, I only pointed in its direction.  what input did you need from me on it?
<ogra_> slangasek, just a glance over http://paste.ubuntu.com/11778897/ if you see anything insane
<ogra_> technically it looks ok to me ... i'm just not sure about "conceptual" :)
<Chipaca> sergiusens: this grub.cfg should work with both old and new and do the right thing and etc: http://pastebin.ubuntu.com/11779470/
<Chipaca> sergiusens: however, i haven't been able to test the upgrade
<Chipaca> sergiusens: is there a way of testing this without publishing an image with this grub?
<Chipaca> sergiusens: super simple the grub.cfg in the end, and i had all the bits already
<Chipaca> sergiusens: more DRY: http://pastebin.ubuntu.com/11779488/
<Chipaca> sergiusens: and now i'm off to make pizza. will check back later wrt the above.
<slangasek> ogra_: ah, so changing shadow instead of adduser.  hmm.  I think it's a better logical fit in adduser, but clearly doing it in shadow would work
<ogra_> well, i think sergiusens plans to do both
<ogra_> but have shadow do all the work
<ogra_> so adduser needs just the switch enabled
<sergiusens> Chipaca: nice
<sergiusens> Chipaca: ogra_ what if we allow expansion of cmdline with a grubenv?
<sergiusens> slangasek: my worry is that some component in some place will need to do an 'if RO' or 'if snappy' and apply the right switches; is that useradd or cloud-init?
<slangasek> sergiusens: I'd suggest that it should be part of the adduser config
<slangasek> there's not currently an option for this in /etc/adduser.conf, but it could be done
<sergiusens> slangasek: ok, I was thinking of that and don't mind adding it there; thanks
<slangasek> sergiusens: ok, great :)
<balloons> elopio, trying to update to latest snappy edge is giving me an error; if I use snappy update, rather than snappy update ubuntu-core: http://paste.ubuntu.com/11780433/
<balloons> as an aside, will snappy support diff based updating? Or will I always have to grab the entire image?
<sergiusens> slangasek: can you look at https://code.launchpad.net/~sergiusens/ubuntu/wily/adduser/extrausers/+merge/263169 later?
<slangasek> sergiusens: ok, queued for looking
<elopio> balloons: please report a bug for that, I'll try to reproduce it.
<elopio> balloons: I think you are downloading only the delta.
<Guest36352> trying out snappy on the raspberry pi 2, i installed docker and booted a container with "docker run -it -p 4444:4443 nblumoe/rpi-clojure". I installed netcat and ran "echo yo | nc -l 4444". Should I not be able to "nc 127.0.0.1 4443" and get "yo" from the pi?
<Guest36352> i can see the port bound with docker ps "a1cee09fade8        nblumoe/rpi-clojure:latest   "bash"              14 minutes ago      Up 14 minutes       0.0.0.0:4444->4443/tcp   fervent_babbage"
<Guest36352> but no cigar
<damjan> Guest36352: format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
<damjan> Guest36352: so 4444 is the hostPort 4443 is the containerPort
<damjan> so you need to listen to 4443 in the docker container
<damjan> and connect to 4444 from the host
#snappy 2015-06-27
<Guest36352> thanks damjan, got it working
<pitti> ogra_: sorry, don't know much about fan -- I just sponsored; thanks for reverting, if that causes trouble (I assumed sergiusens knew what to do)
<JohnClar_> Hey all
#snappy 2015-06-28
<torg> what does it take to make an installed snappy application service to start on boot? i have ubuntu snappy running on a raspberry pi 2
#snappy 2016-06-27
<Sargun> Can you run a snap "anonymously" (like a Docker container)
<zyga> o/
<ogra_> Sargun, can you elaborate what that means ? snap services usually run as root ... snap app binaries as the user that starts them both in a controlled environment that they can not break out of
<qengho> ogra_: a lot of sevices really hate running as root. I think it would be nice if the system reserved a nonroot uid for such cases. E.h., snapd registers a user, and puts that uid with some name in the shared /etc/passwd file, or something.
<qengho> No, e.h is not a merger of e.g. and meh.
<pmp> for iio-usage I have a snap which will read-only-access sysfs, which is prohibited by snapd
<pmp> Is there an interface for it or should I file a bug requesting an interface?
<pmp> How should sysfs-accesses be handled? Typical IIO-applications will also want to write to sysfs, for example to enable a device or to install a timer.
<Sargun> ogra_: have a use case where developers can anonymously deploy apps throughout my system
<Sargun> imagine kubernetes, or Docker swarm
<Sargun> So, Ideally I'd like to run these as processes
<Sargun> independently from snapd
<popey> dpm: I filed this issue with sergiusens' qt5conf, but yours is affected too.. https://github.com/sergiusens/qt5conf/issues/3 (basically we shouldn't have "cd" in any launchers IMO)
<dpm> thanks popey. I'll look at it during the playpen tomorrow. I just want to make sure removing the 'cd' does not break the Qt apps that are currently using the launcher
<popey> dpm: cool
<ogra_> hmm
<ogra_> why is node-engine not respected in my snapcraft.yaml
<ogra_> oh, it is
<ogra_> seems nw.js is simply built statically against node 6.2.2
<sergiusens> good morning
<sergiusens> hey kyrofa mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/608 ?
<kyrofa> sergiusens, good morning! Sure. Actually, would you mind taking a look at https://github.com/snapcore/snapd/pull/1340 ? Make sure it matches up with what you're thinking for snapcraft
<didrocks> kyrofa: does source-subdir works for you? I'm unsure I'm using it badly or anything, but it seems to me that build/ still reference the root dir and not a subdir
<didrocks> (despite what the help says)
<didrocks> also, unkown source-subdir doesn't trigger anything, it's like if the property wasn't read
<kyrofa> didrocks, it depends up the plugin. I don't think go handles it well, for instance
<kyrofa> depends on*
<sergiusens> kyrofa didrocks the go plugin, from its `help` does not mention it uses the sources implementation from the base plugin
<kyrofa> sergiusens, ah! Good point
<kyrofa> didrocks, but yeah, try the make plugin
<sergiusens> maybe this has become a defacto expected core functionality though
<sergiusens> and we should consider moving source handling to the core
<didrocks> sergiusens: kyrofa: hum, I'm using the make plugin
<kyrofa> didrocks, hmm, let me investigate
<didrocks> kyrofa: want an example I'm expecting to work from the help?
<kyrofa> didrocks, sure
<didrocks> kyrofa: http://paste.ubuntu.com/17969379/
<didrocks> and here parts/gtk/build/ == parts/gtk/src (where I expect from --help parts/gtk/build/ == parts/gtk/src/gtk)
<kyrofa> didrocks, uh oh... there might be a regression here
<didrocks> ah, I'm not crazy :)
<kyrofa> didrocks, indeed, parts/gtk/build should contain everything from the src if my memory serves
<didrocks> also, try to put foo as source-subdir
<didrocks> no complain, nothing
<kyrofa> didrocks, but the plugin's builddir should be in the subdir
<didrocks> yeah
<didrocks> that's what the --help says
<didrocks> kyrofa: also, a fun thing with that, noted that I have to define a make parameter?
<didrocks> it's because symlinks are copied as such
<didrocks> (and when they go out of the src dirâ¦ :p)
<didrocks> ok, that's an edge case, but still ;)
<kyrofa> didrocks, yeah I'm not sure why you're having to do that. Why can't it build in the builddir?
<didrocks> kyrofa: look at the source in gtk/
<didrocks> it's a symlink to common/
<didrocks> and so, that file, once copied in builddir, becomes a dangling symlink
<didrocks> (you can try it with the snapcraft.yaml in gtk/ dir)
<kyrofa> Ah, I see
<kyrofa> didrocks, wait, no, I'm being dumb. This seems to work okay here
<kyrofa> didrocks, including the symlink being okay
<didrocks> kyrofa: symlink or source-subdir?
<didrocks> kyrofa: it does work because of build/ isn't build/gtk
<didrocks> but once it's build/gtk, then ../common doesn't exist
<didrocks> (check the snapcraft.yaml in gtk/ directory for instance)
<kyrofa> didrocks, using what you gave me (and removing the make-params) works
<kyrofa> didrocks, parts/gtk/src is copied into parts/gtk/build, then the plugin runs out of parts/gtk/build/gtk
<didrocks> kyrofa: hum, I'm on 2.11, it doesn't here
<kyrofa> didrocks, which I realize now is actually different than the docs for source-subdir, oops
<didrocks> yeah
<kyrofa> didrocks, but it was done that way for instances like this, where you needed to build in a subdir but you still needed the rest of the project
<didrocks> hum, you're right, it does work because it's different frmo the doc :)
<didrocks> yeah
<kyrofa> didrocks, sorry about that, I fixed that bug ages ago but apparenty never updated the docs
<didrocks> kyrofa: no worry, at least, yeah, it does work and fix the symlink issue (which only appear when snapcraft.yaml is in gtk/)
<didrocks> but I guess as it's referencing something "above the top dir for snapcraft.yaml" that makes sense
<didrocks> (and my Makefile copes with both)
<kyrofa> didrocks, indeed, that would make sense
<didrocks> kyrofa: ok, so only the help needs to be modified :)
<kyrofa> didrocks, indeed
<didrocks> thx!
<kyrofa> didrocks, thank you!
<elopio> fgimenez: can you send me the bots credentials please?
<sergiusens> elopio hey, can you look at 608 again
<sergiusens> elopio I went fixture crazy just to make you happy!
<elopio> sergiusens: that sounds good :) Let me see.
<dholbach> seb128, we have a bug in https://github.com/ubuntu/snappy-playpen/tree/master/atom where the menu is not exported - do you know of the problem?
<didrocks> dholbach: we are just starting looking at it together (as planned ;))
<dholbach> didrocks, I was just wondering if there was a bug for it already
<didrocks> dholbach: we will file one if we can't sort it out today I guess
<dholbach> didrocks, thanks - if the issue persists, it'd be good to add it to https://github.com/ubuntu/snappy-playpen/wiki/Known-issues
<didrocks> yep
<didrocks> Not that I completed README.md with it already
<dholbach> thanks a lot didrocks
<seb128> dholbach, why did you set that gsettings bug to fix released? it's not, the update is still blocked in y-proposed
<seb128> the bugs are going to autoclose when it migrates
<dholbach> seb128, oh?
<seb128> if you want to see those closed get somebody to fix their autopkgtest :p
<dholbach> seb128, sorry, I thought the update had landed already :)
<seb128> dholbach, no worry
<sergiusens> elopio ok, one more look
<sergiusens> elopio so wrt the milestone, where are we on the other tasks?
<elopio> sergiusens: let me move my "in progress" ones to 2.13. And after the search lands, we are good to go. I'm going to see which ones are still missing the template.
<jdstrand> roadmr: hi! would you mind pulling r687 at some convenient time?
<roadmr> jdstrand: sure thing!
<jdstrand> roadmr: it isn't super-critical
<jdstrand> thanks! :)
<fgimenez> elopio, sure one sec
<sergiusens> elopio oh, where is that script you had for me?
<elopio> sergiusens: only tested in staging, so let me know if you see bugs. https://github.com/elopio/snapcraft/blob/launchpad_scripts1/scripts/launchpad/add_series.py
<seb128> dholbach, atom fails to build for me, http://paste.ubuntu.com/17974945/
<dholbach> cwayne, ^
<seb128> didrocks, ^ mentioning it as well
<elopio> kyrofa: I think there's something wrong here: https://github.com/ubuntu-core/snapcraft/pull/580
<elopio> primed_dependencies is only set, never read.
<kyrofa> elopio, heh, sergiusens pointed that out as well. I saved it in primed_dependencies to serve as both documentation and in case we ended up needing to track them, but indeed it's not used. The elsif is the real bugfix there
<kyrofa> elopio, the fact that both of you pointed that out, however, shows that it does _not_ serve as decent documentation
<elopio> kyrofa: ahh, I see.
<elopio> yes, a would have been nice there.
<kyrofa> elopio, should I just skip those instead of keeping track of them?
<kyrofa> Oh, it's already merged, meh
<elopio> kyrofa: I think so. Instead of an assignment, put a comment. But yeah, it might surprise us later but it's ok now.
<kyrofa> elopio, I couldn't come up with a test case for why tracking them might be useful. I'll give that some further thought
<kyrofa> I don't think it is, though
<elopio> sergiusens: kyrofa: I don't like this one: https://bugs.launchpad.net/snapcraft/+bug/1596114
<ubottu> Launchpad bug 1596114 in Ubuntu Yakkety "adt, cannot snapcraft clean without remote parts when in use" [Undecided,New]
<elopio> we need a valid yaml and up-to-date cache in order to clean. Isn't there some fallback we can do?
<kyrofa> Hmm
<elopio> maybe fail if we are trying to clean a specific step or part, but delete everything if no argument is passed?
<kyrofa> Honestly clean could improve a bit by doing exactly that. It would really speed up as well
<kyrofa> elopio, please make a bug, I'll take that one
<sergiusens> kyrofa elopio yeah, not so great, but it wouldn't really hit users, no one really cleans before attempting to build and your are guided into the right direction if you try to build with missing defined parts
<elopio> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1596596
<ubottu> Launchpad bug 1596596 in Snapcraft "in order to clean, the snapcraft.yaml has to be valid and the parts cache up-to-date" [Undecided,New]
<sergiusens> clean can just skip mentioned parts that are undefined
<dholbach> all right - I call it a day - see you all tomorrow!
<sergiusens> elopio kyrofa what worries me more though is renaming a part and losing all knowledge of its existence
<elopio> sergiusens: It hits me often :) But my workflow is not too smart, I agree there.
<elopio> bye dholbach !
<dholbach> bye elopio :)
<sergiusens> elopio kyrofa ie; do a snapcraft prime, remove a part and all your things from the remove part are still staged
<sergiusens> until you clean all
<kyrofa> sergiusens, yeah very true
<kyrofa> sergiusens, how could we improve that?
<sergiusens> kyrofa we need to track outside of the part and track the full yaml
<sergiusens> and/or
<elopio> that sounds like a good bug to report too. Go for it sergiusens :)
<sergiusens> as in "these parts existed on the last run"
<kyrofa> Yeah sounds like a good bug
<kyrofa> I like those papercut ones
<elopio> joc_: I saw you adding parts to the wiki. Heads up that with 2.12, the source page changes: https://bugs.launchpad.net/snapcraft/+bug/1594976
<ubottu> Launchpad bug 1594976 in Ubuntu Yakkety "Use new saved endpoint for wiki parts" [Undecided,New]
<joc_> elopio: thanks for the heads up, i saw some chat earlier about it :)
<joc_> elopio: i'll have another go, this time with the new infrastructure if can get the plainbox plugin to land
<joc_> elopio: all tests have passed btw ;)
<elopio> joc_: nice! :)
<elopio> sergiusens: all bugs ready. I suppose you will need next a script that marks all the bugs in yakkety as commited, and then released. That sounds easy to do while I wait for the SRU.
<dtzWill> Read through lots of the documentation on snaps, parts plugins interfaces... this whole thing looks really useful and exciting!
<sergiusens> elopio no, that is automatic
<sergiusens> elopio what I would like is for the script to add the milestone to xenial
<dtzWill> Unfortunately looking at package list I'm seeing via 'snap find' it seems things are still early in terms of developer buy-in :(. Read that firefox was going to use .snap, are there other indications/plans for more software to be included/shipped this way?
<dtzWill> (regardless of the answer to my question, seriously GJ on all the parts--it's like nix for the real world lol :P)
<elopio> sergiusens: I don't understand that one. Didn't that script already add all the bugs to xenial too?
<sergiusens> elopio yes, but it doesn't add the xenial milestone
<sergiusens> elopio as in https://bugs.launchpad.net/snapcraft/+bug/1596114
<ubottu> Launchpad bug 1596114 in Ubuntu Yakkety "adt, cannot snapcraft clean without remote parts when in use" [Undecided,New]
<sergiusens> elopio the task xenial there has no milestone
<elopio> sergiusens: that's something like xenial-updates, right?
<sergiusens> elopio I just added it now. It doesn't
<elopio> let me see if I can get something similar in staging.
<sergiusens> elopio it is trivial and not important or required though
<elopio> sergiusens: it
<elopio> 's good to automate it all anyway.
<sergiusens> kyrofa elopio https://github.com/ubuntu-core/snapcraft/pull/610
<sergiusens> dtzWill yes, it is early days; these things do take time
<dtzWill> okay, awesome! No worries there, understood.  Hoping to pitch this to my team, scrounging for data/confirmation about its use and future :).
<dtzWill> thanks for the response :).
<sergiusens> dtzWill well it is in the latest ubuntu lts release and will be the best way to deliver the latest and greatest
<sergiusens> dtzWill if there is anything stopping you today that is not a "by design" limitation, we will surely look into it; heck even a design limitation if well thought out can be looked into to or reasoned out
<dtzWill> honestly only 'problem' I foresee is some vague "it's not practical" arguments that aren't technically founded as much as "until other people do it, it might be risky/untested/bad in ways we don't know".... but AFAICT this'll fit our needs technically just fine! :)
<dtzWill> but I'll let y'all know if that's not the case or if we get stuck in some way :).
<ogra_> kyrofa, sergiusens, is there any way to change permissions of a file via the copy plugin ?
<kyrofa> ogra_, no, just a straight copy right now
<ogra_> sad ...
<kyrofa> ogra_, what is your use-case?
<sergiusens> ogra_ it is copy, not `install` ;-)
 * ogra_ has an upstream tarball that ships the main binary with 0600 permissions ... 
<ogra_> inside the snap that is then root owned ...
<ogra_> so i cant exec it
<elopio> sergiusens: maybe this: http://paste.ubuntu.com/17984723/ But I can't even test it in staging.
<plars> So, I'm trying to get snapd working with dragonboard, but ubuntu-core doesn't want to install
<plars> https://www.irccloud.com/pastebin/Gb910zTh/
<sabdfl> hiya
<sabdfl> oh-hi-thar-snappy
<kyrofa> Hey sabdfl, welcome :)
<sergiusens> kyrofa elopio give me 2
<niemeyer> plars: That should have been fixed by now.. what's your version of snapd?
<plars> niemeyer: 2.0.2
<plars> niemeyer: that seems to be the most recent available in the archive for arm64
<niemeyer> That's pretty old
<niemeyer> Can you please try with 2.0.9?
<plars> niemeyer: sure, do we have a build of 2.0.9 somewhere already for snapd?
<plars> niemeyer: or is there a reason why the package in the archive is so old for it?
<niemeyer> plars: Suspect it's autopkgtests not quite working as they should, which is something we're working on
<plars> hmm, looking at lp, it should be there
<plars> maybe updates isn't enabled on this image, let me check
<plars> yep, that's it
<plars> thanks
<niemeyer> plars: Nice, np
<kyrofa> sergiusens, all of a sudden cla-check doesn't build anymore. It doesn't seem to have anything to do with snapcraft as I tried all the way back to 2.9
<kyrofa> sergiusens, it hasn't changed since I published it a few days ago. Can you try to build it and tell me if it's failing for you? Quite baffling
<kyrofa> Wait... it just worked. What the...
<sergiusens> kyrofa good ;-)
<sergiusens> or not ... :-P
<elopio> cprov: travis tests are failing in register with 429, too many requests.
<cprov> elopio: just started ?
<elopio> cprov: I can add a sleep, but I would need to know how ofter are we able to register.
<elopio> cprov: I don't think so. I have just added the debug to the test, but I think the same was happening friday.
<cprov> elopio: let me check the current settings. Are you targeting staging, right ?
<elopio> cprov: yes. But I also want to enable production tests soon.
<cprov> elopio: okay, right back to you with the values.
<zyga> tyhicks: hey
<zyga> tyhicks: do you have a second?
<tyhicks> zyga: hi
<zyga> tyhicks: hey, I'm thinking about safe_mount patches by Serge Hallyn
<zyga> tyhicks: it seems that Serge doesn't work for canonical anymore, do you know if those patches for lxd were written at the time he did?
<tyhicks> zyga: yes, he and I worked on that solution together when he was working for Canonical
<zyga> ah, thanks
<zyga> I was thining that I can reuse that code with few modifications but I was worried about the licensing
<zyga> thank you
<tyhicks> zyga: note that I pointed out some unanswered questions in the original PR
<tyhicks> zyga: will the snap author or the user launching the snap have control of any components in the src or dst paths?
<tyhicks> zyga: if so, the safe_mount() solution (or something like it) will be needed
<zyga> no
<zyga> all of those paths are under our control entirely
<zyga> well
<tyhicks> :)
<zyga> actually, that's not true
<zyga> so we have ultimate control to ensure security but the snap can construct any symlink internally
<tyhicks> right
<zyga> I think we still want something similar to the path traveral code
<zyga> that bails out on symlinks
<zyga> (or maybe not bails out entirely but is more considerate)
<zyga> though I don't quite know what the attack vector there might be given that this code runs after pivot_root
<tyhicks> so they could symlink to some system directory and, without the safe_mount() logic, snap-confine would bind mount over an unintended location
<tyhicks> hmm
<zyga> an after unshare(CLONE_NEWNS)
<tyhicks> good point
<zyga> so technically, yes
<tyhicks> are you sure that's true?
<zyga> they can do "nasty" things
<zyga> yes
<zyga> 100% positive
<zyga> ah, wait
<zyga> it's not true but it should be
 * zyga moves the call around
<zyga> after 1.0.34 I'll drop some ifdefs
<zyga> so code will be easier to follow
<zyga> (dead code will go away)
<tyhicks> ok
<zyga> I also wrote a few integration tess
<zyga> tests*, I don't know if you saw those
<zyga> if you have ideas on things that should be tested please suggest some, it is realy easy to write real integration tests now
<tyhicks> I haven't seen the tests yet
<zyga> https://github.com/snapcore/snap-confine/pull/51/files#diff-7d317bce59e92358d0d5f17f49606cd6
<zyga> (though please click and see various .yaml files, the link is not perfect)
<zyga> all tests pass :)
<tyhicks> those are nice and easy
<zyga> tyhicks: we don't have coverage out of those but it's better than nothing
<zyga> and those are real confine, non-test executables
<zyga> out of the package
<zyga> tyhicks: do you think I should port the safe_mount patches?
<tyhicks> zyga: I was having trouble following you
<tyhicks> zyga: you said that "technically, yes, they can do 'nasty' things"
<tyhicks> zyga: is that not true?
<zyga> tyhicks: I'm sorry, I said "nasty" ironically, because it was not something that exists on the outside anyway
<tyhicks> zyga: ok, let me look at the branch where you moved the code around and see the ordering
<zyga> if you think there is a risk that still applies I will use the safe mount approarch
<zyga> better safe than sorry
<zyga> I'm just looking for guidance
<zyga> I wonder how apparmor and bind mounts combine
<zyga> mmm
<tyhicks> apparmor mediates mounting
<tyhicks> because you can bind mount things around and trick the policy
<zyga> right
<zyga> bit after the bind mount is done, apparmor doesn't see "through it"
<zyga> it's not like a symlink where apparmor sees the truth
<tyhicks> correct
<tyhicks> zyga: the pivot_root() is only called on classic distros
<zyga> yes
<zyga> tyhicks: pivot_root is only used to ensure consistency with all-snap systems
<tyhicks> ok
<zyga> (and so that we don't have to rely on the layout of the host filesystem)
<tyhicks> zyga: that means we're relying on unshare(CLONE_NEWNS) to protect against any bind mount attacks, right? (assuming that we don't do safe_mount())
<zyga> yes
<zyga> again, if you feel that we should do safe_mount, I'll do it
<tyhicks> zyga: understood - I'm reviewing the changes you've made and thinking through the possibilities
<zyga> thanks!
<aatchison> Morning folks
<zyga> aatchison: hey
<aatchison> I was wondering who sergiusens did this "stage: - -usr/lib/python2.7/dist-packages/sphinxbase/*"  What's the signifier of using two dashes?
<aatchison> *why
<zyga> - is a list
<zyga> and 2nd - is "exclude"
<zyga> so a list containing one element that excludes usr/lib/python/...
<aatchison> oh!
<aatchison> That's why it's not included :S
<aatchison> lol, thanks
<sergiusens> elopio adt passed for yakkety on amd64; pushing to xenial now :-)
<LinuxGuy2020> I really want to try and make some snap packages but so far it seems over my head. I'm not wanting to do anything crazy, just take already available debs from a given repository or ppa and turn it into a snap. I have no clue of what I have to put into the yaml file for that. Is there a easy guide for this thats not so cryptic for a non-developer to follow?
<chrisatlee> hi! I'm looking for tips on packaging an app that uses gtk
<zyga> LinuxGuy2020: not sure if you want to do that if you're not a developer, some things can get confusing; try to snap something trivial first
<chrisatlee> hitting similar errors as https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357/comments/4
<zyga> LinuxGuy2020: do snapcraft init
<ubottu> Launchpad bug 1584357 in snapcraft (Ubuntu) "Snappy GTK applications" [Undecided,Confirmed]
<LinuxGuy2020> zyga: Im not publishing for other people. Its just for my own personal use for now.
<zyga> LinuxGuy2020: get one app written (apps are what is runnable from a snap)
<zyga> LinuxGuy2020: then add one part that uses stage-packages to bring the debs you want inside
<zyga> LinuxGuy2020: there are examples like that in snapcraft
<zyga> LinuxGuy2020: sure
<zyga> chrisatlee: sorry, I'm not familiar with all the bits gtk needs to function
<zyga> chrisatlee: I'm sure gtk support will improve a lot soon but not tonight
<tyhicks> zyga: even if we don't port safe_mounts(), we can rely on unshare(CLONE_NEWNS) to protect the system and other snaps from any symlink attacks via mount()
<tyhicks> zyga: a potential problem is that the snap can trick snap-confine into bind mounting over portions of the os snap inside of the app's mount namespace
<tyhicks> zyga: off the top of my head, I can't think of any attacks that it would allow but it does make me uneasy
<zyga> ok, Ill port safe mount then
<zyga> thanks :)
<tyhicks> zyga: I think that's the safest option
<sergiusens> chrisatlee hey, wrt gtk, you might be interested in the snappy-playpen
<chrisatlee> sergiusens: yeah, I've been looking at some examples there
<chrisatlee> using after: [gtkconf]
<sergiusens> chrisatlee https://github.com/ubuntu/snappy-playpen
<chrisatlee> it's a little insane that unspecified parts are pulled from the wiki!
<chrisatlee> is there a way to delete non-current snaps?
<sergiusens> chrisatlee then you will like 2.12 http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
<chrisatlee> any tips on debugging 'bad system call' when running under non-devmode?
<zyga> chrisatlee: yes
<zyga> chrisatlee: please look at syslog (journalctl -f -n 100)
<zyga> chrisatlee: and look for the line that has syscall: 123 on it
<zyga> chrisatlee: 123 is the number of the system call, you can resolve it with various tools
<chrisatlee> 317
<zyga> chrisatlee: is this amd64 or another architecture?
<chrisatlee> amd64
<chrisatlee> sig=31 arch=c000003e syscall=317
<zyga> that's seccomp itselr
<zyga> itself
 * zyga checks something
<zyga> chrisatlee: seccomp is allowed by default
<zyga> chrisatlee: something is not okay, can you report a bug with the line that lists the syscall 317
<zyga> chrisatlee: please open the bug on launchpad.net/snappy
<chrisatlee> yeah, if I add seccomp and unshare to the policy, it kind of works
<chrisatlee> and now it's being denied access to /proc/$PID/task/.../stat
<zyga> chrisatlee: it's better to report a bug on this, I wonder why seccomp was denied in the first place, seccomp is allowed for all programs
<zyga> chrisatlee: (though remember that it only allows you to constrain the profile more, not less)
<zyga> chrisatlee: what is the program you are trying to run?
<chrisatlee> zyga: firefox
<zyga> chrisatlee: firefox fro the package my have a nested apparmor/seccomp profile
<zyga> chrisatlee: those won't work, you'd have to strip them out
<zyga> chrisatlee: and also firefox probably uses seccomp internally but that should work
<zyga> chrisatlee: though it'd be best to report this issue an let us investigate
<chrisatlee> yeah, it uses it internally
<zyga> chrisatlee: if you can, please include the snapcraft.yaml file so that we know what approach you've used
#snappy 2016-06-28
<qengho> Are there any Classic RPi kernel images that support the apparmor snapd requires?
<niemeyer> qengho: ogra_ will know the answer when he's around
<Girish> hello
<Girish> anybody is there?
<qengho> Girish: Why?
<Girish> i have question to ask.
<seb128> what about asking it then?
<seb128> instead of asking if somebody is interested in you to ask
<Girish> how to download source codes for kernel version 3.19.0-15-generic?
<seb128> that's not really a snappy question
<seb128> Girish, unsure if that's the one you want but https://launchpad.net/ubuntu/+source/linux/3.19.0-15.15
<dholbach> hey, good morning!
<seb128> hey dholbach
<dholbach> hey seb128
<didrocks> hey dholbach!
<dholbach> salut didrocks
<qengho> Girish: You should not expect anyone to commit to answering your unasked question. When on IRC, just ask, and say what you tried already to find the answer.
<niemeyer> Morning dholbach, seb128
<dholbach> hey niemeyer
<niemeyer> qengho: Probably a good life advice too, even if a bit raw.. ;)
<tsimonq2> !help | Girish
<ubottu> Girish: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<tsimonq2> qengho: ^ that's a thing :)
<niemeyer> Folks.. that's enough do-not-ask-to-ask advice for a life time :)
<niemeyer> Girish: Sorry about that..
<tsimonq2> yes, I apologize Girish :)
<seb128> hey niemeyer
<niemeyer> seb128: o/
<zyga> good morning
<seb128> hey zyga, how are you today?
<tsimonq2> o/ zyga
<zyga> hey guys, I'm good :-)
<tsimonq2> that's good :)
<ogra_> qengho, http://cdimage.ubuntu.com/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz
<zyga> ara: coming
<ara> zyga, I am running late as well
<Girish> hello anybody is there?
<Girish> how to make a kernel module from a source code ?
<zyga> hi
<zyga> Girish: you have to build the whole kernel snap, you cannot ship one module
<Girish> what does it mean? actually i am new in linux environment
<Girish> actually i have to modify the source code in order to detect a LTE modem in its USB interface but the linux (ubuntu 15.10, kernel version 3.19.0-15-generic) that i m using have option.ko file instead of option.c file so i download the option.c file and modify it now i am confused how do i make its make file?
<Girish> zyag are you there?
<zyga> Girish: yes
<nhaines> Girish: are you doing this for a desktop system or an Ubuntu Core system?
<zyga> Girish: I think the question nhaines asked is crucial
<Girish> actually i m using lenovo desktop which is boot into linux through UEFI/LEGACY
<nhaines> Then this is the wrong channel, although I'm not sure which would be the right one.
<zyga> Girish: then you just want to fix the issue in the ubuntu kernel, snappy is not a part of this
<Girish> how to do this?
<ogra_> Grtry asking in the #ubuntu or #ubuntu-kernel channel then
<zyga> jdstrand: do you think we can allow sched_setparam or switch seccomp to EPERM instead of killing the process?
<zyga> kyrofa: is this something we still want? https://code.launchpad.net/~kyrofa/snap-confine/create_user_common_data/+merge/293555
<sborovkov> Hi. From what I understand currently systemd logs on snappy are written to SD card (in case of RPI at least). Is it possible to configure it to use tmpfs for logs?
<jdstrand> zyga (cc tyhicks): we can probably allow sched_setparam with seccomp arg filtering (sched_setparam 0). as for EPERM, that is on the security team's todo list
<kyrofa> zyga, no. It's no longer necessary with snap run
<ogra_> hmm, do we have any interface that allows setpriority ?
<zyga> jdstrand: thanks
<qengho> ...probably from chromium.
<tsimonq2> kyrofa: changed
<ogra_> qengho, heh, well, i'm packahing nw.js .. so chromium is kind of involved (in case you talked to me above)
<ogra_> runs fine in --devmode ... and makes an awesome webapp container ;)
<jdstrand> niemeyer, zyga: hey, I'm having some trouble with go accessing the data in []interface{}. Can you look at: http://paste.ubuntu.com/18023741/
<zyga> jdstrand: looking
<jdstrand> niemeyer, zyga: I feel like I am being dense or missing a critical piece of info
<jdstrand> zyga, niemeyer: dang it, that had a typo. use this: http://paste.ubuntu.com/18023866/
<zyga> jdstrand: interface{} is "anything" but the real object behind is has its true type, what you want to do is to progressively check that the type is of a given kind until you reach the data you want
<zyga> looking again
<jdstrand> zyga: yes, I have no problem with interface{}. that is easy. eg: something.(string)
<zyga> jdstrand: "baz" is a []interface{} probably
<jdstrand> zyga: the problem is []interface{}. I can't .([]string) it and I can't range or iterate on it
<jdstrand> zyga: it is
<zyga> jdstrand: so you want baz, ok := slot.Attrs.([]interface{})
<jdstrand> I say that in the paste :)
<zyga> and then access items in baz the same way
<jdstrand> ok, let me try that
<zyga> it's not a []string!
<zyga> it's a []interface{}
<zyga> and baz[0] may be a .(string)
<zyga> right?
<zyga> that's distinct from []string
<zyga> because baz[1] may be .(int)
<qengho> Go is still martian to me.
<jdstrand> baz[0] is a .(string), yes. I understand why .([]string) doesn't work. I just couldn't figure out what *would* work
<jdstrand> let me try the thing you mentioned
<jdstrand> zyga: baz, ok := slot.Attrs.([]interface{})
<jdstrand> invalid type assertion: slot.SlotInfo.Attrs.([]<inter>) (non-interface type map[string]interface {} on left)
<jdstrand> for baz, ok := range slot.Attrs.([]interface{}) doesn't work either
<jdstrand> zyga: sorry, I've looked at this for far longer than I care to admit but I just can't seem to pull out the data. it seems like I need to iterate on slot.Attrs["baz"] so I can .(string) on baz[0], baz[1], but I can't figure out how to do that and I'm not sure if I should be doing something else
<zyga> jdstrand: let me help you after the standup
<zyga> jdstrand: can you push something more concrete? do you have a branch with a new interface?
<jdstrand> zyga: well, I have a branch that I am converting to using the yaml as described and it is severely broken because I'm blocked on this, but give me a few minutes and I can push that somewhere
<zyga> jdstrand: ok
<zyga> jdstrand: I'll help you out
<jdstrand> zyga: https://github.com/jdstrand/snapd/tree/dbus-bind-broken
<zyga> jdstrand: thanks
<jdstrand> zyga: I'm using: go build -tags=excludeintegration -v github.com/snapcore/snapd/... && go test -tags=excludeintegration -v github.com/snapcore/snapd/interfaces/builtin
<zyga> FYI, test implies build
<jdstrand> zyga: you'll see soon enough, the problem is in SanitizeSlot
<zyga> jdstrand: looking :)
<sabdfl> zyga, hi
<zyga> sabdfl: hey :-)
<tsimonq2> o/ sabdfl, how are you?
<sabdfl> well thank you, sad at brexit
<sabdfl> understandable frustrations, incomprehensible response
<sabdfl> on the bright side... SNAPS! :)
<tsimonq2> yes! :)
<tsimonq2> sabdfl: have you seen the increasing amout of snaps in the playpen? https://github.com/ubuntu/snappy-playpen
<jamiebennett> sabdfl: lets not mention the England football result either
<tsimonq2> *amount
<sabdfl> jamiebennett, there are some games where one side HAS to lose
<sabdfl> other gae where everybody CAN win
<sabdfl> games, that is
<sabdfl> let's just say this was not a game where penalty shootouts were called for :)
<sabdfl> tsimonq2, yes, great traction, and with distros too
<tsimonq2> sabdfl: I'm curious, speaking of other distros, what's your opinion on Flatpak?
<sabdfl> tsimonq2, it will end up duplicating snaps, judging from the roadmap they announced, unfortunately
<sabdfl> cant really prevent it, the nature of competitive instincts
<tsimonq2> sure, I get it :)
<tsimonq2> just wondering your opinion
<sabdfl> i wish they wouldn't say nasty things about us to try to get support for their own efforts
<sabdfl> it's fine to NIH stuff if you feel you have to do that
<sabdfl> i uspect most fedora / rhel user will choose to use snaps if they are high quality
<tsimonq2> yeah, I recently started contributing to Snapcraft, and now I love snaps. I used to find them confusing, but I became pleasantly surprised
<sabdfl> but it's fine that to have other options too
<sabdfl> tsimonq2, :D
<sabdfl> we just have to blog loudly about the great thinking that underpins the snap architecture
<sabdfl> technology and quality should win these races, and we should challenge the other guys to leave the politics at home
<tsimonq2> yes, agreed
<tsimonq2> it's sort of ironic how we are supposed to have a universal package format now
<tsimonq2> but there is multiple formatsd
<tsimonq2> *formats
<tsimonq2> Snappy, Flatpak, and I hear of more
<ogra_> appimage ?
<tsimonq2> yeah I think that :)
<tsimonq2> sabdfl: on the note of me contributing, I am really glad I decided to work with the people in the Snapcraft team to get som code in
<tsimonq2> *some
<tsimonq2> I've learned a lot
<ogra_> pay it back by teaching someone else in the community later ;)
<tsimonq2> that's my plan :)
<ogra_> :D
<sabdfl> tsimonq2, did you make a plugin?
<tsimonq2> sabdfl: well no, I added Subversion support
<sabdfl> just as useful :)
<tsimonq2> \o/
<tsimonq2> sabdfl: but I have a couple bugs assigned to me right now
<tsimonq2> for example, I'm adding checksum support for tar and zip sources
<sabdfl> that's nice, will help all the different user communities
<sabdfl> gtg
<tsimonq2> o/
<jdstrand> zyga: any luck?
<zyga> jdstrand: I was pulled into a few meetings
<zyga> jdstrand: I have vim open but I didn't touch it much
<jdstrand> heh, ok, no worries
<jdstrand> I have a meeting myself soon
<zyga> jdstrand: ok, I'm more available now
<zyga> jdstrand: sorry, this is a pretty interesting day
<zyga> jdstrand: I'll be with you shortly
<ysionneau> hi, about socket activated services in Snappy. Are they automatically started at bootup?
<ysionneau> Or only when socket is accessed?
<jdstrand> zyga: no worries. out of meeting and have a bunch of other stuff I can work on
<ysionneau> The behaviour I am seeing here is : it's started at bootup. is this normal?
<jdstrand> zyga: I am quite curious what I'm missing though
<zyga> jdstrand: hacking on it now
<zyga> jdstrand: quick note, pulsaudio 9.0.1 changes APIs a lot, we could drop the shm stuff entirely
<zyga> jdstrand: we should have a backlog item for it
<zyga> jdstrand: arch has it today
<sergiusens> elopio hey, thinking about migrating the sources while we wait; is it just a matter of movinf the organization?
<elopio> sergiusens: yes, afaik. You can ask niemeyer if he had to do something else.
<joc_> sergiusens: hey, i'm trying to use the python3 plugin to pull in plainbox to my snaps, as per the plugin discussion, however i don't get entry points for the programs in the package created like i do if just run pip3 on my host - do you know why that might be?
<elopio> sergiusens: oh, and reset the jenkins hook, set the team permissions, that too.
<elopio> re-enable coveralls, update the badges in the README.
<pcoca> Chipaca, Hi! I've been trying to make a snap of httpie
<pcoca> Chipaca, I just realised that you did one a few weeks ago
<pcoca> Chipaca, But with a very different approach.
<pcoca> Chipaca, I am struggling with the relative modules and this snapcraft.yaml: https://github.com/pedrococa/httpie_snap/blob/master/snapcraft.yaml
<niemeyer> sergiusens: Moving the repo? Yeah, it's straightforward, and GH internally maps the old links to the new place
<pcoca> Chipaca, Do you know how to overcome the relative modules issues with httpie, when you point to the repo and use the python3 plugin?
<sergiusens> niemeyer yup. already done ;-) Sent an email and it is kind of cool that redirects happen automatically and all PRs just DTRT
<sergiusens> elopio ok, I can take care of badges et.al. but no idea how to reset the jenkins stuff
<tsimonq2> wooooooooooooah
<tsimonq2> https://github.com/snapcore/snapcraft !!!
<elopio> sergiusens: In setting of the project > hooks. Set http://162.213.35.179:8081/ghprbhook/, with permission to Pull Request and Issue comment.
<elopio> sergiusens: I'm leaving now, I can help when I'm back.
<sergiusens> elopio sure; all good
<sergiusens> elopio heh, lost my admin :-P
<sergiusens> niemeyer can you make me admin of snapcraft?
<niemeyer> @sergiusens Of course
<nothal> niemeyer: No such command!
<sergiusens> joc_ they all have those script entries in setup.py, right?
<niemeyer> Oops :)
<niemeyer> sergiusens: Of course :)
<sergiusens> thanks niemeyer
<joc_> sergiusens: not too familiar with the format of setup.py but i think so, there are entry points declared like this: http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/setup.py#L95
<sergiusens> joc_ yeah, console_scripts should just work, let me try something simpler to see if there's a hidden bug (later today though)
<niemeyer> sergiusens: You and kyrofa are admins, and added the snapcraft-contributors team as write access
<sergiusens> thanks!
<niemeyer> np
<kyrofa> Thanks niemeyer
<joc_> sergiusens: ok thanks
<niemeyer> sergiusens, kyrofa: I've also created a snapcraft-bots team.. not sure what level of access you'll want to give it, but let's please keep real contribs and bots separated
<niemeyer> We've been doing that already on the other teams
<sergiusens> kyrofa lool https://github.com/snapcore/snapcraft/pull/611
<lool> sergiusens: LGTM, do you want me to do something to land it?
<lool> I dont think I'm in the snapcore org
<sergiusens> lool no, just sending your way since you complained ;-)
<sergiusens> lool I will wait for elopio on this one
<lool> sergiusens: I didn't complain!
<lool> I sent you a heads up in case you didn't about it
<sergiusens> elopio btw, the hook is already configured
<sergiusens> lool ah, well, a complaint I took in a positive way ;-)
<lool> sergiusens: FYI snapcraft/tests/test_sources.py mentions the old branches, if real checkouts are made and we ever remove the old branch, you would want to update them to the new one
<ogra_> lool, stop complaining that you didnt complain !
<ogra_> :)
<lool> I'm being harassed by people who pretend I'm complaining, I'll file a complaint
<sergiusens> lool those never reach the checkout phase :-)
<lool> sergiusens: ok, I didn't check
<lool> hence the conditional
<lool> and caveats
<netphreak> Hi, guys!
<Guest32438> hello on  http://snapcraft.io/ there is a little mistake in section Release channels. the channel option is mentioned with a single dash (-) yet in the section beneath it is mentioned with a equal (=) . just happened to see this and thought to inform you. have a nice day!
<zyga> jdstrand: hey
<zyga> jdstrand: sorry it took me so long, really unpredictable day
<zyga> jdstrand: if you pull from my remote you will see how to use this
<zyga> jdstrand: I can expand this anyway you like so please just have a look and tell me if that answers your question
<zyga> jdstrand: and if not let's work on this some more
 * zyga coffee and back to snap-confine
<jdstrand> zyga: thanks! I see what you are doing. man, I was so close
<jdstrand> I almost tried something like that. thanks!
<zyga> jdstrand: syntax can be confusing :)
<jdstrand> zyga: yes, and go's interface{} isn't the most intuitive thing in the world
<zyga> jdstrand: it helps to read how it is implemented
<zyga> jdstrand: it is essentially a proxy that knows how to dispatch each of the methods defined inside (note that {} doesn't have to be empty!)
<netphreak> Any eta. on a release image for Rpi3?
<jdstrand> zyga: yeah, I did read how it was implemented. there was a nice article on it. it was the '[]' part of '[]interface{}' that threw me since I couldn't range it and it seemed like I should be able to
<sergiusens> kyrofa su?
<kyrofa> sergiusens, ah sorry, mentioned on telegram but should have put it here-- I'm not feeling well, I need to lay down
<josepht> kyrofa: I hope you feel better
<sergiusens> kyrofa ah, get better
<kyrofa> Thanks guys
<zyga> jdstrand: you can range it
<zyga> jdstrand: you can range it and each element is a interface{}
<zyga> slangasek: hey, I'm just doing this not to forget
<zyga> slangasek: I'd love if you could commit debian packaging back to snap-confine master, this would help us in tetsing debina
<zyga> slangasek: and then merge the one change back to debian, the change in debian/rules, specifically commit 2b130c575010a6f35a9f05d8683a761c8c02e2a0
<zyga> slangasek: this will become critical when we switch to snap-exec and when snap-confine will be started from a relative path
<zyga> slangasek: which will be essential for core snap updates
<slangasek> zyga: I'm pretty sure I don't have commit rights on snap-confine master fwiw, but I will take time this week to review and raise pull requests
<jdstrand> zyga: that is what I tried to do, but I didn't end up with the right incantation
<zyga> slangasek: just send me a pull request or a branch on alioth that can be merged easily
<zyga> slangasek: I looked at doing this but I gave up because master's weren't compatible
<zyga> jdstrand: ack
<jdstrand> hence the 'so close' comment
<jdstrand> :)
<jdstrand> anyhoo, thanks!
<zyga> jdstrand: my pleasure
<zyga> slangasek: I'd like to upload a sid vm to linode so that we can do per-commit tests on debian too
<zyga> slangasek: and then having dpkg-vendor patches would be essential
<sergiusens> josepht https://bugs.launchpad.net/snapcraft/+bug/1596044
<ubottu> Launchpad bug 1596044 in Snapcraft "Parts loader needs refactoring" [Undecided,New]
<josepht> sergiusens: is that different from the ordering refactoring you mentioned in the SU?
<sergiusens> josepht nope
<elopio> sergiusens: ah, what's missing is to update the jobs. I'm on it.
<josepht> sergiusens: I see.  I was reading it as the "parser's parts loader".  I'll assign to me.
<elopio> sergiusens: the tests can be triggered now. But the user can't update the status on the PR, it says: http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1082/
<elopio> so you need to give snappy-m-o write access.
<sergiusens> elopio ok, write access as in to comment?
<sergiusens> the webhook or the user/bot?
<elopio> sergiusens: the user. Write access as in pushing changes to the repo.
<sergiusens> niemeyer hey, can you add elopio's bot to https://github.com/orgs/snapcore/teams/snapcraft-bots ?
<sergiusens> niemeyer also, can you enable coveralls for snapcore/snapcraft, seems it needs an org admin
<elopio> niemeyer: and please send us the token in case it's needed.
<sergiusens> mhall119 give this a try https://github.com/snapcore/snapcraft/pull/612 you will get further but stuck on the fact you need to export alternate paths for GIR
<sergiusens> attente hey you around? Can you tell me what would be needed to be able to open "resources" using a snap app; like https://telegram.me/joinchat/BQHZRAiN_pnOeE4mT31YCQ in the telegram snap?
<attente> sergiusens: what kind of resources? is it just a url opened via xdg-app?
<sergiusens> attente yeah, probably, going to that link offers tg://join?invite=BQHZRAiN_pnOeE4mT31YCQ
<attente> sergiusens: the snapd-xdg-open helper only allows http, https and mailto
<sergiusens> attente so it is the other way around than from the bug you were working on
<sergiusens> attente right that is from snap to world
<sergiusens> attente I face a much simpler problem now, from world to snap
<attente> sergiusens: that doesn't sound easier. wouldn't we have to hack the default xdg-open script that comes with xdg-utils?
<sergiusens> attente I don't know, hence I am asking you :-)
<sergiusens> attente does xdg-open look for desktop files to figure out uri handlers or are they registered at install time?
<attente> sergiusens: just glancing at the script right now, it looks like it examines the desktop files, so maybe there's some way to prioritize the ones in the snaps
<sergiusens> attente right, right now I click and nothing happens :-)
<attente> sergiusens: maybe that's an apturl problem actually
<attente> sergiusens: er. sorry, never mind
<attente> sergiusens: is there an open bug for this?
<sergiusens> attente no, just brought to my attention by pmcgowan :-)
<attente> sergiusens: is there a general directory where the desktop files of snaps is located? the same way that there's /snap/bin?
<sergiusens> attente yup
<sergiusens> attente /var/lib/snapd/desktop/applications/
<sergiusens> mvo or zyga can correct me if I am wrong here ^
<attente> sergiusens: looks right here
<attente> sergiusens: maybe adding /var/lib/snapd to XDG_DATA_HOME in the session might make the xdg-open script look there first
<sergiusens> attente so as it is right now it should be looking?
<sergiusens> in my case, it is not opening anything at all
<sergiusens> attente what desktop key would I need for this?
<attente> desktop key?
<sergiusens> attente yeah, in the desktop file
<attente> i would've thought MimeType=x-scheme-handler/tg, but your telegram snap already has it
<niemeyer> sergiusens, elopio: Still out for some exercising, but will do
<attente> sergiusens: can you try manually editing ~/.config/mimeapps.list to add x-scheme-handler/tg=telegram-sergiusens_telegram.desktop
<attente> this seemed to launch the snapped telegram for me
<mhall119> sergiusens: that didn't seem to help me any
<mhall119> sergiusens: does snapcraft cleanbuild install snapcraft in the lxc, or does it copy the host's snapcraft install into it?
<pmcgowan> attente, that worked
<pmcgowan> attente, although it seems to always open a new instance
<mhall119> hmmm, looks to install it via apt
<attente> yeah, same here
<mhall119> sergiusens: I'm cowboy-patching snapcraft in the lxc container created by cleanbuild
<mhall119> will see how it goes
 * genii hands mhall119 the lariat
<mhall119> sergiusens: so I patched /root/parts/mail/bin/pkg-config and re-ran "snapcraft snap" and it did indeed get further, but it spit out a whole bunch of cmake warnings about link directories or something
<mhall119> oh wait, it might be something I did
<mhall119> ah ha, yes, I threw an extra print(env) line in there, and evidently something was consuming that
<mhall119> thanks sergiusens, that unblocks me on snapcraft now I think, I'll try and get vala/gir help from the elementary devs tomorrow
#snappy 2016-06-29
<wililupy> Question: With snapcraft, is there a way to run make oldconfig when snapping a kernel?
<wililupy> Or should I do that before and then run make [menu]config and save the config and point to the kconfigfile in my snapcraft.yaml?
<qengho> wililupy: Does "snapcraft help kbuild" answer your question? You should provide your config and snapcraft will run "make oldconfig" after installing it.
<wililupy> qengho: That makes more sense now. I was reading that and wasn't quite sure what it meant.
<wililupy> I'll give it a shot tomorrow to see how that works since I know that defconfig is very minimal, and I need to add a bunch of kconfigs to make my kernel work.
<qengho> wililupy: cool.
<wililupy> It's almost easier for me to just follow the directions here: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild and then in menuconfig, save the config and copy it to my snapcraft.yaml location and build using kconfigfile: in snapcraft.yaml.
<wililupy> qengho: However, I think the way you mention is cleaner and the better way to do it :)
<wililupy> qengho: Or, use the /boot/config-`uname -r` for the kdefconfig: and then use kconfigs: for the specific ones I need since it will then use yes "" | make oldconfig when creating a new .config.
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<dholbach> comment Ã§a va?
<tsimonq2> hey it's dholbach \o/
<tsimonq2> dholbach: how are you?
<dholbach> hi tsimonq2
<dholbach> good good :) how are you?
<tsimonq2> great :)
<tsimonq2> dholbach: look at what I've been working on: https://github.com/tsimonq2/lubuntu-distro-snaps
<tsimonq2> I have the parts defined, now for the apps tag
<seb128> dholbach, good, and you?
<dholbach> seb128, I need a bit more mate tea to fully wake up, but I'm doing well :)
<seb128> :-)
<dholbach> tsimonq2, nice work - so this snap bundles all lubuntu core related packages and their dependencies, is that what it does?
<dholbach> tsimonq2, does it work?
<didrocks> good morning dholbach, tsimonq2
<dholbach> salut didrocks
<tsimonq2> o/ didrocks
<tsimonq2> didrocks: I might as well show you too :) https://github.com/tsimonq2/lubuntu-distro-snaps
<tsimonq2> dholbach: well currently, the lubuntu-core snap is meant to make a very minimal Lubuntu snap
<tsimonq2> dholbach: it is pretty much the lubuntu-core metapackage
<tsimonq2> !info lubuntu-core
<ubottu> lubuntu-core (source: lubuntu-meta): Lubuntu Desktop environment - minimal installation. In component universe, is optional. Version 0.65 (xenial), package size 3 kB, installed size 14 kB (Only available for i386; amd64; powerpc; armhf)
<dholbach> tsimonq2, right
<tsimonq2> dholbach: it doesn't work right now because I don't have apps: tags yet, working on that now
<dholbach> nice
<tsimonq2> but soon :)
<didrocks> tsimonq2: nice! can't wait to see apps there )
<tsimonq2> didrocks: I basically took the .travis.yml and ci-run files from the snappy-playpen repo and modified them to set up Travis for mine
<didrocks> yeah, saw that, sweet reuse! :)
<tsimonq2> so I'm using your docker container if you don't mind ;)
<didrocks> I'm ofc really really upset! :-)
<tsimonq2> :P
<tsimonq2> hmm, how do I do systemd services?
<didrocks> daemon: simple
<didrocks> in your apps declaration
<didrocks> (look at snapcraft.io, there is an example of this)=
<tsimonq2> oh okay thanks :)
<tsimonq2> didrocks: I'm asking because the lubuntu-core snap has lightdm
<didrocks> dholbach: so, here are 2 new "gtk" parts, sharing most of their code. Reviewed with seb128 and pulling the minimum deps needed for the launcher: https://wiki.ubuntu.com/Snappy/Parts
<didrocks> I think I need to migrate it as well to the new wiki for 2.11
<dholbach> yes
<didrocks> I'm going to integrate then qt4 & 5 to it
<didrocks> using the same template
<didrocks> dholbach: who should we set as a maintainer for those parts? it's under the ubuntu/ snapcraft
<didrocks> we can maybe set it under snapcraft.io ML?
<dholbach> didrocks, sounds good
<dholbach> didrocks, seb128: nice work!
<didrocks> will do :)
<didrocks> thx!
<seb128> thanks :-)
<tsimonq2> alright, apps: tag added, waiting for a build on Travis, and if it works, then it's time to test!
<tsimonq2> CC dholbach, didrocks ^
<didrocks> tsimonq2: crossing fingers!
<tsimonq2> didrocks: tell me about it :D
<tsimonq2> didrocks: if you want to cross fingers with me :P https://travis-ci.org/tsimonq2/lubuntu-distro-snaps/builds/141002975
<didrocks> tsimonq2: ahah, I have other stressing builds in progress ;)
<tsimonq2> didrocks: :)
<didrocks> dholbach: do you have snapcraft 2.12 already?
<dholbach> didrocks, https://launchpad.net/ubuntu/+source/snapcraft
<dholbach> it's in -proposed still
<didrocks> dholbach: yeah, the question was if you installed it manually :)
<didrocks> (as I'm still on 2.11 and I saw that the wiki parts are already moved, I wondered if you tried it with it)
<dholbach> yes, I did for testing one of the sru bugs
<didrocks> dholbach: do you mind looking for my "desktop" parts?
<didrocks> and ensuring that desktop.gtk2 and desktop.gtk3 returns content?
<dholbach> didrocks, http://paste.ubuntu.com/18083742/
<didrocks> dholbach: nice!
<didrocks> thanks a lot :)
<tsimonq2> didrocks: I'm on Yakkety, I got it from the archive, FWIW
<didrocks> tsimonq2: sweet! I think the output from dholbach confirms it work, but if you have a minute, do you mind:
<didrocks> 1. git clone https://github.com/ubuntu/snapcraft-desktop-helpers
<didrocks> cd snapcraft-desktop-helpers/demo/gtk3
<didrocks> 2. vi snapcraft.yaml
<tsimonq2> s/vi/vim/ *AHEM* ;)
<didrocks> 3. replacing "gtk3" with "desktop.gtk3" in the after part
<didrocks> 4. trying to snapcraft it :)
<didrocks> didrocks@tidus:~$ ls -l /usr/bin/vi
<didrocks> lrwxrwxrwx 1 root root 20 mai   28  2012 /usr/bin/vi -> /etc/alternatives/vi
<didrocks> didrocks@tidus:~$ ls -l /etc/alternatives/vi
<didrocks> lrwxrwxrwx 1 root root 16 aoÃ»t  12  2013 /etc/alternatives/vi -> /usr/bin/vim.gtk
<didrocks> -> same on my machine :p
<tsimonq2> didrocks: error:
<tsimonq2> $ snapcraft cleanbuild
<tsimonq2> Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop.gtk3'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache
<tsimonq2> I'll run snapcraft update then
<dholbach> it still can't be found
<didrocks> yeah, you need to refresh
<tsimonq2> still :/
<didrocks> hum, interesting
<didrocks> but the definition appears though
<didrocks> as per dholbach's output
<didrocks> can be a snapcraft bug?
<didrocks> sergiusens: once you are back ^
<didrocks> sergiusens: also, I would like to just use the namespace without having to declare a stupid part "desktop, plugin: nil part" ;)
<tsimonq2> didrocks: http://img.ctrlv.in/img/16/06/29/577381bf95606.png
<didrocks> tsimonq2: did you try "snapcraft define desktop" and "snapcraft define desktop.gtk2" for instance?
<tsimonq2> didrocks: http://img.ctrlv.in/img/16/06/29/5773827e686af.png
<didrocks> this is after snapcraft update, right?
<tsimonq2> yep
<didrocks> sergiusens: ^
<didrocks> tsimonq2: mind retrying? We may have scheduled importer
<tsimonq2> didrocks: sure
<tsimonq2> didrocks: \o/ works fine now
<didrocks> phew, that was just an importer cron thingy though
<didrocks> sergiusens: I guess it worth a mention on this on the wiki page or anything ^
<didrocks> thanks tsimonq2
<tsimonq2> np didrocks :)
<zyga> jdstrand: https://bugs.launchpad.net/snappy/+bug/1597259
<ubottu> Launchpad bug 1597259 in Snappy "Access to /lib/ denied" [Undecided,Triaged]
<zyga> jdstrand: feel free to assign to me if you think this should be in the base template
<willcooke> seb128, for my gedit310 snap, I've worked around the missing libs issue, but now I'm getting:
<willcooke> (gedit:20800): GLib-GIO-ERROR **: Settings schema 'org.gnome.gedit.preferences.editor' is not installed
<willcooke> any suggestions for a way I can work around that one?
<ogra_> i think there was work going on for a dbus interface
<ogra_> zyga, ^^
<zyga> mmm
<zyga> so yes, there was some work on gsettings proxy
<zyga> but I don't know if this is actually something the proxy would handle, this seems like it wants to access the schema files
<willcooke> I've just copied the schema files over from my local fs in to the stage dir and am going to rebuild and see if that helps
<seb128> willcooke, do you use the standard gtk wrapper?
<willcooke> seb128, yeah
<seb128> weird
<seb128> can you share the snapcraft.yaml?
<willcooke> seb128, https://github.com/8none1/gedit310
<seb128> willcooke, oh, you coimmented the prefix option, that's the issue
<seb128> it's looking for schemas in the standard location
<seb128> and the default prefix from snappy is buggy in that regard
<seb128> willcooke, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1590831
<ubottu> Launchpad bug 1590831 in snapcraft (Ubuntu) "having prefix='' by default is non standard and confusing" [Undecided,Confirmed]
<willcooke> seb128, hmm, I think I commented them out for a reason, lemme try
<seb128> willcooke, it might create issue, did you try to combine it with the organize I suggested?
<seb128> let me try to build it with those
<willcooke> seb128, hmm
<willcooke> it works now :D
<willcooke> sorry
<seb128> lol
<seb128> no worry
<seb128> you already rebuilt?
<willcooke> seb128, I think I should copy the themes over
<willcooke> ah, but... I had to do
<willcooke> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./usr/lib/gedit/ gedit
<willcooke> so maybe I will need another customer launcher there?
<seb128> likely
<seb128> I don't know if you can add an env like that in the apps: section of the snapcraft.yaml
<willcooke> and for themes, is there and env var for that, and shall I just copy them over from my fs?
<seb128> you can stage light-themes
<seb128> which is what others do
<dpm> hey didrocks, I just noticed your new gtk launchers, good work. Are these ready to replace the 'gtkconf' part?, and if so, do we want to start migrating apps from the playpen to them?
<seb128> willcooke, you should also stage libglib2.0-bin for the schemas compile
<seb128> dconf-gsettings-backend as well for dconf to work
<seb128> willcooke, oh and you want to use the "gsettings" interface, it's not included under unity7
<willcooke> seb128, thank you!! Added and rebuilding
<seb128> yw
<didrocks> dpm: yes and yes :) I just have to give a try at pulseaudio, but the rest is good and should replace yours and so, playpen!
<didrocks> dpm: do you know of a good pulseaudio simple demo btw?
<willcooke> ooh, new gtk launcher?  didrocks what's new in your one?
<dpm> didrocks, cool, you might have done it already, but if not, seb128 had been working on things like translations, you might want to talk to him
<didrocks> willcooke: it's based on the existing ones, just cleaned up (like dynamic gtk2/3 detection, keeping xdg cache on upgrade and such) while being able to share base functionality with Qt ones
<dpm> didrocks, I don't know any short and sweet pulseaudio off the top of my head, sorry :/
<didrocks> dpm: yeah, we did a review on it yesterday evening :)
<dpm> pulseaudio *demo, I mean
<willcooke> nice one, thanks didrocks seb128
<dpm> excellent
<didrocks> yeah, that's my issue, seb128 and I are unsure we need to export LD_LIBRARY_PATH to it
<didrocks> or add the library itself
<didrocks> hence a demo would be great for testing :)
<seb128> didrocks, we can maybe have a simple snap with pavucontrol or something
<seb128> though playing sound and controling the channels etc is not the same
<seb128> so maybe just paplay and ubuntu-sounds
<didrocks> seb128: yeah, I had the same issue with pavumeter
<didrocks> so yeah, let's try paplay + ubuntu-sounds
<seb128> current snapd is buggy though
<seb128> you need https://github.com/snapcore/snapd/pull/1359
<didrocks> ah?
<seb128> which hasn't been rolled out in distro version yet
<didrocks> ok, so next snapd
<seb128> yes
 * didrocks puts that on side thus
<didrocks> let enable me creating a placeholder for now
<seb128> you can probably try a daily snapd if you want
<seb128> is the next version due tomorrow?
<didrocks> I think it is
<didrocks> and I have enough with working on helping others + qt4/5 launchers + converting existing stuff for keeping me occupied until then :)
<seb128> yeah
<didrocks> dpm: willcooke: oh, also another difference on this launcher: it's pulling the base launcher dependencies for you, so no need to overload them anymore in your parts (build- and stages-)
<willcooke> nice!
<willcooke> didrocks, where can I see a list of those?
<didrocks> willcooke: snapcraft 2.11 or 2.12?
<didrocks> it's built in in 2.12, but the definition is taken from https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml
<didrocks> it's strictly the launcher requirements + what flavor you wants (gtk2 or gtk3 here)
<willcooke> didrocks, thanks!
<seb128> didrocks, just curious but what's the desktop part about?
<willcooke> willcooke, grep - new gtk launcher list of packages - ^
<seb128> it only has a nil plugin
<didrocks> seb128: nothing, but it seems to be required to have then desktop.<something> namespace
<didrocks> I feel that's a snapcraft bug, it shouldn't
<seb128> you mean you can't name a part desktop.gtk3?
<seb128> directly
<didrocks> not if there is no desktop part
<seb128> I see
<seb128> but your parts are named gtk2/gtk3
<didrocks> yeah, see https://wiki.ubuntu.com/snapcraft/parts
<seb128> how do they translate to their real name?
<seb128> is that from the wiki?
<didrocks> you have a project-part: desktop
<didrocks> then, for exposing other parts, it's parts: [gtk2, gtk3]
<seb128> I see
<didrocks> which is using the project-part namespace
<seb128> similar to the commands
<didrocks> I read it from http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
<didrocks> yes
<seb128> thanks
<didrocks> I find it counter-intuitive though
<didrocks> yw
<seb128> I'm that blogpost in my list of things to read
<seb128> going to do that now ;-)
<didrocks> and you can even see sergio had the same issue with mttq btw :p
<didrocks> mqtt*
<seb128> :-)
<didrocks> heh, happy reading!
<jdstrand> zyga: 1597259 already has a PR
<jdstrand> zyga: hehe, and you merged it (https://github.com/snapcore/snapd/pull/1435)
<kyrofa> jdstrand, is it a known issue that a home dir mounted via NFS results in u-c-l denials trying to create the user data directory?
<zyga> jdstrand: ohh, right
<zyga> jdstrand: that's good
<zyga> jdstrand: release is today
<willcooke> seb128, halp!  I just did a snapcraft clean and then tried to rebuild that snap....  libtool: warning: 'libgedit-private.la' has not been installed in '/usr/lib/gedit'
<willcooke> I don't get it, it was working find a moment ago :)
<seb128> urg
<seb128> dunno about this one
<willcooke> seb128, I think this is why I commented out the prefix stuff originally
<willcooke> stupid brain can't remember though
<willcooke> Will play with it...
<seb128> doesn't make sense why gedit would fail to build with a prefix
<willcooke> make[3]: Entering directory '/home/will/source/gedit/gedit310/gedit310/parts/gedit/build/gedit'
<willcooke>  /bin/mkdir -p '/usr/bin'
<willcooke>   /bin/bash ../libtool   --mode=install /usr/bin/install -c gedit '/usr/bin'
<willcooke> libtool: warning: 'libgedit-private.la' has not been installed in '/usr/lib/gedit'
<willcooke> libtool: install: /usr/bin/install -c .libs/gedit /usr/bin/gedit
<willcooke> Makefile:879: recipe for target 'install-binPROGRAMS' failed
<willcooke> could be a makefile issue
<jdstrand> kyrofa: heh, that would not surprise me. what is the denial?
<kyrofa> jdstrand, http://pastebin.ubuntu.com/18097641/
<jdstrand> kyrofa: I think that is going to be fixed in the pending upload because that directory will no longer be created by the confined launcher
<kyrofa> jdstrand, ah right, snap run
<kyrofa> jdstrand, that would be operating under a similar profile?
<kyrofa> won't rather
<jdstrand> it is unprivileged
<jdstrand> I don't believe it has a profile
<jdstrand> zyga: can you comment? ^
<kyrofa> Alright good deal
<kyrofa> Thanks jdstrand!
<zyga> jdstrand: looking
<zyga> jdstrand: I'm not sure what to make of it
<zyga> jdstrand: which directory is no longer created, I don't see anything that snap would create?
<jdstrand> zyga: ~/snap/foo/... is no longer created by snap-confine. The question is, what is doing that now (assuming 'snap-run') and is that thing confined (assuming not)
<zyga> hmmmm
<zyga> I don't think it is doing that
<zyga> ah, wait, snap run might be indeed doing that
<juanrubio> hi all, I'm wondering if anyone would know why there is a 'parts/myapp/install' and a 'parts/myapp/installlib' folders?. My app contains a mix of c, c++ and python libs and the python modules show up in the 'installlib' dir.
<mhall119> sergiusens: did you see my response last night?
<sergiusens> mhall119 yes, thanks
<mhall119> sergiusens: will that make it into the next snapcraft release?
<didrocks> tsimonq2: did you retried with 2.12?
<didrocks> retry*
<zyga> jdstrand: what confused me is this: name="/home/xcore/mberger/
<didrocks> sergiusens: hey, I still don't see my desktop. parts appearing on https://parts.snapcraft.io/v1/parts.yaml
<zyga> jdstrand: that's not a $HOME/snap/$SNAP_NAME
<didrocks> sergiusens: should I start getting nervous? :)
<didrocks> (I updated the wiki this morning, like 7h before)
<juanrubio> for some reason I get my python modules in 'parts/mayapp/installlib/python2.7' and I would expected to show up in 'parts/mayapp/install/lib/python2.7'
<juanrubio> .. is this a snapcraft bug?#
<juanrubio> .. is this a snapcraft bug?
<jdstrand> zyga: no, it isn't. the user is using an alternative directory for HOME which would be a problem if the process creating the dir is confined, but it isn't any more aiui
<didrocks> juanrubio: do you use the python plugin? if so, I would says it can be, sergiusens ^
<jdstrand> zyga: fyi, not sure if this could be snuck in: https://github.com/snapcore/snapd/pull/1441
<jdstrand> zyga: if not, 2.0.11 is fine
<zyga> jdstrand: checking
<juanrubio> I'm using the autotools plugin.. all my project built with autotools
<didrocks> ah, and you stage-packages: [python2] ?
<didrocks> I guess if it's in install/ it's due to your build tools installing them there
<juanrubio> when I build everything outside snapcraft with make, make install, the python packages are installed under 'prefix/lib/python2.7'
<juanrubio> didrocks: I stage with a fileset, 'libraries: lib/*', but the python packages got installed in 'parts/installlib/python2.7'
<didrocks> juanrubio: interesting, maybe sergiusens could have a look later in if you post your snapcraft.yaml here :)
<didrocks> and maybe open a bug report against snapcraft on launchpad about it? https://launchpad.net/snapcraft
<didrocks> (post your snapcraft.yaml there)
<juanrubio> my file is here is anyone wants to have a look: https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml
<juanrubio> I've just started with this, so I'm probably getting something wrong...
<didrocks> hum
<didrocks>       modules:
<juanrubio> I'll open the ticket in launchpad as well... thanks
<didrocks>         - installlib/python2.7/dist-packages/*.py
<didrocks> this is due to the wrong install path I guess you are encountering :)
<juanrubio> didrocks: yes, that was an attempt to get the python modules staged, but that does even work... if you remove that line, there is no change
<didrocks> yeah, I guess open the ticket with your clean snapcraft.yaml
<didrocks> (without this then)
<didrocks> I'm sure we'll get to it quickly
<juanrubio> sure, I will, thanks again!
<didrocks> your .yaml looks good otherwise
<didrocks> yw! :)
<didrocks> just a tip: you don't need source-type: git
<didrocks> as you ended up your url with .git, snapcraft is smart enough for this :)
<juanrubio> great, I'll remove that too
<kyrofa> juanrubio, you might try providing --prefix=/ as a configflag to see if anything chnges
<juanrubio> let me try that
<juanrubio> kyrofa: that worked beautifully.. now my python packages are under 'parts/tizonia/install/lib/python2.7/site-packages'
<juanrubio> should I still open the launchpad bug report?. can do if that helps...
<kyrofa> juanrubio, good deal. Means the problem is within the build system for that project, not snapcraft
<juanrubio> I see, I'll have to investigate that...
<juanrubio> ...but for now I have a solution in place... so now on to another question:
<sergiusens> elopio any idea when our infra will catch up with the repo move?
<sergiusens> mhall119 yes
<sergiusens> didrocks did it show?
<sergiusens> didrocks I see some issue from the parser, josepht mind looking?
<juanrubio> what would be the best practice here... my project depends on some pip packages, e.g. gmusicapi, these change rapidly, so no chance I can get them as debs... can I add parts that download and install these python modules using pip?
<ogra_> kyrofa, i'm just answering a question about the nextcloud snap and was wondering if you wouldnt like to add another blog post about how to migrate your data from a former install to the shiny new snappy system
<juanrubio> I could not find a snapcraft 'demo' project with 'pip' in it.. if there is one, I would appreciate pointers..
<kyrofa> ogra_, that's a good idea, thanks!
<ogra_> (for people coming from classic etc)
<elopio> sergiusens: we are waiting for niemeyer to add the bot to the team.
<elopio> everything else seems good.
<niemeyer> Doing that now
<sergiusens> elopio coveralls as well?
<niemeyer> @elopio What bot do you want there?
<nothal> niemeyer: No such command!
<didrocks> sergiusens: thx for looking at it with josepht :)
<niemeyer> sergiusens: What bot do you want there?
<josepht> sergiusens: I'll take a look
<niemeyer> sergiusens: I also added you as a team maintainer now, so you should be able to do that yourself btw
<wililupy> Is there a way to create a udev rule in my snap so that it is installed in /etc/udev/rules.d?
<wililupy> Or should I just use the copy plugin?
<ogra_> how would the copy plugin help ?
<ogra_> you cant copy anything outside of your snap root
<josepht> didrocks, sergiusens: fwiw, there's a tab in the wiki.
<wililupy> Ahh, gotcha ogra_
<sergiusens> niemeyer oh goodie, thanks. For the bot name we have to wait elopio to provide it though
<ogra_> wililupy, i know there were discussions beween zyga and jdstrand about udev rules in snaps, not sure where that ended
<elopio> niemeyer: snappy-m-o.
<niemeyer> sergiusens, elopio: Coveralls enabled, repo token dJaU2S3FSEyMoRkrV4bxhOmIjOUyWMbBq
<elopio> niemeyer: hum, the token should be secret :) Can you regenerate it and send it privately, please?
<niemeyer> elopio: Yeah, I know.. public channel, duh
 * ogra_ lols
<didrocks> josepht: outrageous! :)
<jdstrand> ogra_: what we talked about was less about that and more about enumerating devices and files from udev queries. most of what you referred to would be in the gadget snap realm which afaik is still being designed
<niemeyer> elopio: You got a new one privately
<didrocks> josepht: feel free to change it
<ogra_> jdstrand, ah, i thought there was a discussion about udev rules to allow symlinks so apps find the properly named devices etc
<ogra_> which wuold kind of touch that area
<niemeyer> elopio: Any chance we can stop snappy-m-o from spamming everyone on GH issues?
<josepht> didrocks, sergiusens: nm, that was me being dense.
<niemeyer> Alternatively, can we rename it to spammy-m-o?
<jdstrand> ogra_: I recall that, but that isn't something I'm personally driving is all I meant
<ogra_> ah
<elopio> niemeyer: not if you want to keep the jenkins tests running. If you are ready to disable those tests, I can disable the bot for snapd.
<niemeyer> elopio: I was hoping we could get the bot fixed instead of disabling it
<elopio> niemeyer: that would require patching the jenkins plugin, which is an ugly java thing. We can do it, but not this week. Report a bug and we'll get to it.
<niemeyer> Report where?
<elopio> niemeyer: short term solution, add people to the whitelist.
<elopio> niemeyer: github.com/ubuntu-core/snappy-jenkins
<niemeyer> elopio: Doesn't work.. the bug reference I mentioned to you had "add to whitelist" on the history, and it continued nevertheless
<niemeyer> elopio: https://github.com/snapcore/snapd/pull/1379
<elopio> niemeyer: when you comment add to whitelist, it is stored in the jenkins running instance. But it is redeployed often. In order to add to the whitelist permanently, it needs to be changed in the source of the job: https://github.com/ubuntu-core/snappy-jenkins/tree/master/containers/jenkins-master/config/jobs
<niemeyer> I guess we should just work to take down that tool altogether then..
<elopio> also, people from the team snapcore should be whitelisted, so alternatively you can add people there. I see a bug, that we didn't update from ubuntu-core there, I'll quickly change that.
<elopio> niemeyer: that works too. I don't enjoy jenkins. But we need a tool for general pipelines and triggers.
<niemeyer> I'm talking about that java plugin, not jenkins, to be clear
<josepht> didrocks, sergiusens: I had to upgrade the snapcraft code on the parts service.  The desktop parts are now in the parser output
<didrocks> nice! thanks josepht
<josepht> didrocks: np
<elopio> niemeyer: I'm not sure if there's a way to do it differently. Improve the plugin can be done for sure, but some things are just blocked by jenkins architecture. Like stopping a test if a newer push arrived, that's not doable in a nice way, afaik.
<elopio> sergiusens: niemeyer: PR tests are working as before. Thanks!
<elopio> niemeyer: can you please disable the coveralls comment? There's a switch in the settings page.
<niemeyer> elopio: It's software.. everything is doable.. the question is how much we care to fix it
<niemeyer> elopio: Comments disabled
<elopio> ty.
<niemeyer> https://github.com/ubuntu-core/snappy-jenkins/issues/184, FWIW
<sergiusens> elopio kyrofa please don't merge anything just yet
<elopio> sergiusens: ack
<joc_> sergiusens: with respect to python3 plugin not creating entry_points, i filed a bug, and proposed this alternative to using pip3 --target https://github.com/snapcore/snapcraft/pull/614
<sergiusens> joc_yup cwayne already got me up to speed
<joc_> ah cool
<sergiusens> joc_ I do recall tedg debating wether to use root or target there. I guess this outweighs the original logic
<tedg> sergiusens: Haha, I think I used root and you changed it! ;-)  (I have no clue why I used root though really, probably cargo culted it from somewhere)
<tedg> Interesting that you can pass an install option like that, that was probably the bug with my implementation.
<joc_> sergiusens: tedg obviously would appreciate you checking the command i used
<tedg> joc_: Oh, not me. Everything I know about python is because barry answered a question about it for me.
<elopio> didrocks: you added gtk and gtk3 to the old wiki. 2.12 uses wiki.ubuntu.com/snapcraft/parts instead.
<elopio> didrocks: scratch that, I'm just not subscribed to the new one :)
<elopio> *was
<roadmr> jdstrand: hey, reviewer-tools r687 is live on the store \o/
<didrocks> elopio: heh :)
<jdstrand> roadmr: woohoo! :) thanks
<tsimonq2> elopio: hey, ping, you around?
<tsimonq2> sergiusens: what does it mean to have a bug nominated for a release of snapcraft? does that mean that all the bugs targeted have to be fixed for the release? how does a bug get nominated?
<tsimonq2> sergiusens: ( https://launchpad.net/snapcraft/+milestone/2.13 for example)
<sergiusens> tsimonq2 we like to have a fixed focus to work on
<sergiusens> tsimonq2 nothing is really set in stone though. And yes, the goal is to try and fix them for the next release
<sergiusens> tsimonq2 do you have something in mind that you would want to tackle?
<tsimonq2> sergiusens: just a couple suggestions :) bug 1590807 bug 1596777
<ubottu> bug 1590807 in Snapcraft "doesn't store build logs" [Medium,In progress] https://launchpad.net/bugs/1590807
<ubottu> bug 1596777 in Snapcraft "trying to upload a snap without signing the agreement prints the error twice" [Undecided,In progress] https://launchpad.net/bugs/1596777
<tsimonq2> sergiusens: both assigned to me
<tsimonq2> sergiusens: I'll get them fixed for 2.13, I was just wondering if you wanted to tag them
<sergiusens> tsimonq2 the first one might be tricky to get in to 2.13 timing wise, but yes do work on it
<sergiusens> tsimonq2 I'll just move to 2.14 if not done in time
<sergiusens> tsimonq2 Ideally our milestones last 1 week, give or take depending on holidays, sickness, unexpected issues, etc.
<tsimonq2> sergiusens: ah okay, it's been slow recently?
<tsimonq2> just looking at https://github.com/snapcore/snapcraft/releases :)
<sergiusens> tsimonq2 yes, travel and holidays account for that ;-)
<tsimonq2> sergiusens: alright :)
<tsimonq2> sergiusens: elopio gave a +1 on https://github.com/snapcore/snapcraft/pull/616 , can you second that?
<niemeyer> jdstrand: New spread snap up for review..
<jdstrand> niemeyer: was it not auto-approved? I don't see it
<niemeyer> jdstrand: IT WAS \o/
<jdstrand> nice :)
<jdstrand> the review tools branch landed a bit earlier today for that
<niemeyer> First time in my life I upload something that is available on Ubuntu without manual interaction!
 * niemeyer does the happy dance
<jdstrand> congrats! :)
<niemeyer> jdstrand: ... to us all! ;)
<ogra_> s/happy/snappy/ no ?
<jdstrand> :)
<jospoortvliet> jamiebennett - any clue on the timeline for the first Core release?
<jospoortvliet> as in, a clue you're willing to share, I'm sure you know how/where things stand :D
<jospoortvliet> I'm asking to get an idea when we could do the first Nextcloud Pidrive version for end users ;-)
<jospoortvliet> (the WD Labs collaboration we have, continueing from ownCloud)
<ogra_> jospoortvliet, i'd guess still a few weeks til the first images appear ... and then 4-6 additional weeks til we call it a stable release (provably more, probably less), we explicitly didnt put to many constraints on this to make sure we do it the debian way "when it is ready and rocksolid"
<ogra_> if you need something to play with you can use an rpi server install in the meantime, it comes with snap support too :)
<ogra_> http://cdimage.ubuntu.com/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz ...
<jospoortvliet> ogra_: well the thing is, we want to ship this on a product to users so it's not a great idea to have something we're not 100% confident about ;-)
<jospoortvliet> it isn't a super critical thing on one hand, but upgrades have to work entirely smooth and I'm guessing that that is the hard part right now?!?!
<ogra_> yeah, understood
<ogra_> we are making damned sure that the images we will release will always be upgradeable indeed ;)
<jospoortvliet> it's the big draw of snappy, from my perspective
<ogra_> that is also the reason we are still holding back, kernel and gadget snaps are not 100% finalized ... as long as they can change there is a potential risk you need to re-flash
<jospoortvliet> that way you can have a zero maintenance solution for end users
<ogra_> yeah, thats the plan
<jospoortvliet> excellent
<jospoortvliet> so you're saying 2-3 months still, though
<jospoortvliet> or am I reading it too pessimistically?
<ogra_> i say less than a month for the first images where we can say "yu dont need to re-flash, but it is probably not feature complete and has bugs"
<ogra_> so you could start prototyping by that date ... but not push it to production yet
<jospoortvliet> ach, minor bugs aren't a huge deal, we'll update in production :P
<ogra_> :)
<jospoortvliet> the first 500 devices we'll sell are still kind'a pioneer devices
<jospoortvliet> so that 'under a month' is good enough for us. We just want to be able to fix everything automatically rather than requiring a re-flash
<ogra_> cool ...
<ogra_> dont nail me down on it though :) thats just a guesstimate
<niemeyer> jospoortvliet: What sort of device is it, out of curiosity?
<ogra_> niemeyer, the Wd thingie we worked on with owncloud ... a NAS type device
<jospoortvliet> it is a WD PiDrive with custom box (with Nextcloud logo), 1TB hard drive. On the SD/Harddrive will be Core with Nextcloud.
<jospoortvliet> bring-your-own-Pi
<ogra_> with owncloud preinstalled (now with nextcloud i guess :) )
<jospoortvliet> yeah...
<jospoortvliet> the new box is compattible with oDroid C2, btw, that gives it quite some more power.
<ogra_> niemeyer, https://owncloud.org/blog/wd-labs-raspberry-pi-owncloud-and-ubuntu/
<niemeyer> Thanks, and nice!
<jamiebennett> jospoortvliet: Sorry, was just grabbing dinner. I think ogra_ has told you all the rationale behind the decision to get things right before final release. I would not go to production without our final release though unless your customers are PoC/early adopters. Still, there will be pain. I think by the end of July is optimistic so don't plan around that just yet. Of course you can use classic for now.
<jospoortvliet> well, we're doing a small batch for about 500 people. They will be able to deal with bugs, even a potential dataloss issue (rather not, of course) as long as they don't need too many skills to get it fixed. That is, if the auto-upgrade works and can be used to fix issues, we're good for the early adopters.
<jospoortvliet> after them we will do a bigger batch of course
<jospoortvliet> Basically I'm happy to warn people to not yet use the devices for super important files and backup regularly as long as I can promise that if they just wait the software will improve.
<sergiusens> kyrofa josepht care to review https://github.com/snapcore/snapcraft/pull/615/files ?
<GeoffW> I'm struggling to get the Snappy image working on a Raspberry Pi - anybody know what I'm doing wrong?!
<jamiebennett> jospoortvliet: OK. Happy to work with you on the details nearer the time.
<svij> do I understand correctly that "parts" in snapcraft 2.12 can be some kind of librarys/dependencies of another snap?
<kyrofa> svij, yes, but only build-time dependencies. They still get bundled for run-time
<svij> ah
<svij> that would have been my follow up question :)
<kyrofa> svij, the idea is that library devs can ship parts that essentially tells snapcraft how to best build it
<svij> right
<szszszsz> hi! I have made something bad apparently. After snappy package installation I do not have commands in my path. Do you have any tips?
<szszszsz> It worked before I have purged snapd and used reset script
<szszszsz> By no commands I mean no possibility to run applications installed with snappy from command line
<szszszsz> (mentioned reset script https://github.com/zyga/devtools/blob/master/reset-state)
<szszszsz> alternatively, could someone tell me how to run snap application when its not in the path? should I search /snap/ for a wrapper to run or somewhere else?
<netphreak> what's the latest version of snaps?
<netphreak> snapd?
<sergiusens> netphreak if you are on ubuntu, just run `rmadison snapd`
<sergiusens> for xenial  snapd | 2.0.9       | xenial-updates   | source, amd64, arm64, armhf, i386, ppc64el, s390x
<szszsz_> @szszszsz ^ reboot has helped (its like with windows, yay!)
<nothal> szszsz_: No such command!
<szszsz_> u dont say
<netphreak> thx
<thomi> hi everyone. I'm trying to help an upstream snap something that requires wxPython 2.8. It seems I need to build this from source (it's not in pypi), but that requires building wxPython, wxWidgets, Gtk, glib, atk, gobject-introspection and a whole bunch more.
<thomi> My question is - is there an easier way that creating a part for each library in the chain?
<thomi> I'm guessing the answer is 'no', but thought I'd ask anyway
<mhall119> sergiusens: kyrofa: when a snap's binary looks at /usr/ does it see /snap/<snap>/current/usr/ or the actual /usr/ on the host?
<kyrofa> mhall119, the actual /usr/
<kyrofa> mhall119, we're experimenting with ld preload stuff to change that, but that's the way it is right now
<mhall119> ok, thanks
<sergiusens> thomi can't you use the glib/gtk in xenial
<thomi> sergiusens: no, it's too new (3.x vs 2.x)
<sergiusens> mhall119 kyrofa also, "actual user on the host" is the core snap, not the classic ubuntu system
<thomi> sergiusens: and anyway - wouldn't that break confinement?
<kyrofa> sergiusens, ah yes, thank you
<sergiusens> thomi it wouldn't break confinement, they'd be added to the resulting snap (automagically if using build-packages)
<sergiusens> thomi I have some ideas about prebuilt parts kind of like docker layers
<sergiusens> but that is still in dreamland
<thomi> sergiusens: ahh, gotchya
<mhall119> sergiusens: ok, still doesn't help me though, will find a work-around
<tsimonq2> sergiusens: would you be able to point out the obvious here? I'm not getting how to fix this and it seems really obvious. I have https://github.com/tsimonq2/snapcraft/tree/downloaded-files-checksum-bug-1585913 built on Travis here: https://travis-ci.org/tsimonq2/snapcraft/builds/140983815 and I'm missing where to define source_checksum. It's a work in progress fix of bug 1585913
<ubottu> bug 1585913 in Snapcraft "Snapcraft should allow to verify downloaded files with a sha checksum" [Undecided,In progress] https://launchpad.net/bugs/1585913
<sergiusens> elopio https://github.com/snapcore/snapcraft/pull/617 can you tell me how to get the FakeLogger to not show urllib logs?
<elopio> sergiusens: with a filter maybe? http://stackoverflow.com/a/879937/2665322
<elopio> from that link, I have no idea what you are trying to do.
<sergiusens> tsimonq2 you need to update all the constructors and their call to super https://github.com/tsimonq2/snapcraft/commit/273c8fde9f59dfb3f66f8a68a86911d6aac0b84b#diff-e6205a80af76b4faec1d9241dc3b3b7cR160
<sergiusens> tsimonq2 also, please use the checksum python module instead of subprocess
<sergiusens> tsimonq2 something like https://github.com/snapcore/snapcraft/blob/master/snapcraft/storeapi/__init__.py#L209
<tsimonq2> thanks sergiusens for the feedback :)
 * tsimonq2 sleeps
<sergiusens> elopio the fixture code seems to not like what I have to say
<popey> sergiusens: congratulations on the snapcraft release!
<mcphail> Trying the gedit snap from Will Cooke's G+ posting. There is still an issue with snappy where an invoked snap "cd's" to the install directory, thereby messing up paths supplied as parameters. Is there a plan to fix or change this?
<popey> i filed a bug for that
<mcphail> popey: great. Can you link so I can +1 it?
<popey> hmm
<popey> i filed one against qt launcher
<popey> https://github.com/sergiusens/qt5conf/issues/3
<popey> i guess the gtk-launch also has the issue
<popey> cd $SNAP
<popey> exec "$@"
<popey> yup
<mcphail> Yes, the bug ismore generic than that. I think Imoaned on here about it a year ago when I was making a silversearcher snap
<popey> ok, will poke people tomorrow about it
<popey> it breaks a bunch of things, you're not alone
<mcphail> ta.
<popey> np
<popey> thanks for testing that with the gtk launcher!
<popey> i dont actually know where the upstream for gtk-launch is
<mcphail> looks neat. Don't know how we're going to get around the --devmode flag though
#snappy 2016-06-30
<johangm90> hi guys is there some example of qmake part?
<ned__> I seem to have a problem and need someone's help.  I just did a clean install of Ubuntu 16.04 desktop and I installed the Tiger auditing tool from debian.  After the scan it shows:                               #checking md5sums of installed files  --Fail-- [lin005f] Installed file '/boot/vmlinuz-4.4.0-21-generic'  checksum differs from installed package 'Linux-image-4.4.0-21-generic'.     I am confused as to how this is when granted 
<ned__> I checked the md5sum with microsoft checksum tool and everything was verified, so why is tiger telling me different
<dholbach> hey hey
<seb128> hey dholbach, how are you?
<dholbach> good good - how about yourself?
<seb128> I'm good as well, thanks ;-)
<zyga> o/
<zyga> mwhudson: thank you :)
<zyga> mwhudson: curious, are you interested in snap-confine or just moving closer to snappy bits
 * davidcalle is impressed by the simplicity of the blender snap, would love to see the snapcraft.yaml
<seb128> davidcalle, "simplicity"?
<seb128> you mean the content of the snap itself is like one file?
<mcphail> blender is designed to he self contained. Ideal for a snap
<davidcalle> seb128: no launch wrapper and /snap/blender/meta/snap.yaml is super straightforward
 * mcphail wonders whether the CUDA acceleration would work?
<seb128> davidcalle, it's likely that blender itself is built to be started from random locations and not tight to a linux distro layout
<seb128> I doubt there is snapcraft magic in action there
<seb128> davidcalle, who did the snap? upstream?
<didrocks> yeah, like no appmenu as no standard toolkit
<davidcalle> seb128: https://uappexplorer.com/app/blender-tpaw.tpaw
<seb128> davidcalle, well you have the snapcraft.yaml in the upstream url indicated there, https://github.com/tpaw/snap-repository/blob/master/third-party/blender-tpaw/snapcraft.yaml
<zyga> mcphail: it should work on Arch, I didn't test this on ubuntu as I dont' have the required hardware
<zyga> mcphail: but we could use a dedicated cuda interface for this
<mcphail> zyga: i haven't managed to get any graphical snaps running on an nvidia machine anyway, so I suppose CUDA is a step beyond me at this point ;)
<zyga> mcphail: why not?
<zyga> mcphail: did you try snap-confine 1.0.33 and snapd 2.0.9?
<zyga> mcphail: I have a very old mobile nvidia gpu and it works very well there
<zyga> mcphail: (on ubuntu and arch) with prorietary and free drivers
<mcphail> zyga: just used whatever is stock on 16.04. Always fails with gl error
<zyga> mcphail: I see, may I ask which GPU you have and which drivers are you using?
<dpm> davidcalle, have you tested the blender-tpaw snap?
<mcphail> Not on the machine just now, but it is a 650 using whatever is latest prop driver from defaulr repo (352 i think)
<mcphail> Same problem with a 430 running proprietary driver
<davidcalle> dpm: yep, works great
<dpm> davidcalle, awesome, in --devmode?
<zyga> mcphail: which version of ubuntu-core-launcher or snap-confine do you have now?
<davidcalle> dpm: strict :)
<dpm> oh wow!
<mcphail> zyga: I can't tell you, I'm afraid, as I'm IRCing from my phone
<zyga> mcphail: woot :)
<zyga> mcphail: stay in touch, I worked on a lot of improvements for nvidia
<mcphail> zyga: good stuff. Hope it filters down! Have to steal the wife's laptop for graphical snaps just now :)
<palasso> zyga: when updating the AUR PKGBUILD for the new version, consider updating the snapd.install with http://pastie.org/private/zbhszcpwn40trlthbcg7a
<zyga> palasso: looking
<palasso> zyga: the differences are very small, do a diff to see them ;) 1) removed line 1 2) removed 2 spaces in line 9 3) replaced installation with instructions in line 11
<zyga> palasso: note that the next release will be in the community archive
<zyga> palasso: but I'll pass this along to the maintainer
<palasso> Ahh that's great!
<palasso> Probably he'll remove this then, arch users are expected to check the archwiki or upstream documentation to see if there are any necessary units to enable/start or any kind of cleanup work to do
<zyga> palasso: he's definitely more experienced than I am
<Chipaca> pcoca: why are you making another snap of httpie?
<Chipaca> pcoca: did you do "snap find httpie" before starting?
<Chipaca> pcoca: ah, i missed the bit in the backlog where you said you already knew there was one
<Chipaca> still don't understand why you're doing another though :-)
<Chipaca> pcoca: welcome back
<Chipaca> pcoca: not sure if you saw my answer above before your network awol'ed
<pcoca> Chipaca, Yes, thanks.
<pcoca> Chipaca, The snapcraft that I got is this one: https://github.com/pedrococa/httpie_snap/blob/master/snapcraft.yaml
<pcoca> Chipaca, 1.0.0-dev version
<Chipaca> pcoca: sorry to repeat my question, but why?
<Chipaca> pcoca: is the existing httpie snap bad in some way?
<pcoca> Chipaca, not at all, I just picked httpie as a learning one to make if from scratch and compare with an existing one if i got stuck.
<Chipaca> pcoca: ah ok
<Chipaca> pcoca: maybe it was a bad choice then :-)
<Chipaca> pcoca: the existing httpie snap does not use snapcraft
<Chipaca> pcoca: https://github.com/chipaca/httpie-snap
<Chipaca> pcoca: I'm sure if I started doing it today I *would* use snapcraft
<Chipaca> pcoca: but when I started it wasn't "there" yet
<Chipaca> and now all the work is done, so Â¯\_(ã)_/Â¯
<pcoca> Chipaca, yes, I saw it :) ... I wanted to use snapcraft for my version.
<Chipaca> oh alright then
<pcoca> Chipaca, I got some issues, and didrocks was able to help me.
<Chipaca> pcoca: there are some environment variables that help
<Chipaca> pcoca: look at the python wrapper I wrote
<Chipaca> granted it's a bit messy and does more than set up the environ
<Chipaca> but you've got HTTPIE_CONFIG_DIR
<pcoca> Chipaca, I will, and also as my next learning step I will add the man pages.
<Chipaca> pcoca: if all you are doing is shipping regular httpie, httpie --help is a manpage already, i think?
<pcoca> Chipaca, Yes.
<dpm> didrocks, David C mentioned you were looking at the VLC theming issues. Have you figured out what needs to be done to get the theme working? Is it a matter of having a 'themes' interface?
<didrocks> dpm: I do have some workarounds working for the theme
<didrocks> dpm: I still have 2 issues as of now with my new qt launcher:
<didrocks> 1. appmenu export (works only in devmode)
<didrocks> 2. icon themes (the gtk ones aren't loaded)
<didrocks> I'm going to look at it this afternoon with seb
<didrocks> I have a last idea that I got while running :)
<kyrofa> didrocks, I'm curious to see where you get with that
<kyrofa> Can you let me know if you get it working?
<didrocks> kyrofa: sure! I'm taking your example app btw while working on this :)
<kyrofa> didrocks, yay! That's exactly what I was thinking of fixing with your results :P
<didrocks> ahah, you will be the #1 demo! :)
<kyrofa> Woohoo!
<didrocks> well, there is a difference
<didrocks> I remove your plugin
<kyrofa> Of course
<didrocks> "someone" did the qmake plugin in snapcraft
<didrocks> not sure who is this guy :p
<kyrofa> Yeah that person must have been amazing
<didrocks> exactly!
<didrocks> :)
<didrocks> more seriously, I'll keep you posted
<kyrofa> Thank you :)
<didrocks> the concerning part is that our dependency chain is pulling both gtk2 and gtk3 though
<didrocks> if we want the theme in :p
<kyrofa> Yikes
<didrocks> isn't it?
<didrocks> we need at least one for the theme
<didrocks> the 2â¦ hum :p
<didrocks> (because we don't have compatibility qt theme engine under unity)
<didrocks> it's only the gtk one
<davidcalle> jdstrand: hey, when you have a minute, could you have a look at this: http://paste.ubuntu.com/18166127/ ? This is what happens when using the mpris slot in VLC and trying to look at it with d-feet (I do see it in the list of dbus interfaces, but when I click on it to get details, ths error happens, VLC does not appear in the sound menu as well)
<jdstrand> davidcalle: note that I couldn't get vlc in the sound menu and there were no apparmor denials. I think that must have something to do with the packaging
<jdstrand> davidcalle: as for d-feet-- what version of snapd do you have installed?
<davidcalle> jdstrand: 2.0.10+ppa145-1
<jdstrand> davidcalle: can you paste 'grep audit /var/log/syslog'?
<dholbach> seb128, have you seen this already: https://github.com/ubuntu/snappy-playpen/issues/128?
<seb128> jdstrand, can apps own their dbus name now?
<jdstrand> seb128: not yet: https://github.com/snapcore/snapd/pull/1446
<seb128> dholbach, unsure what he means by url-to-path
<seb128> jdstrand, isn't that needed for mpris?
<dholbach> seb128, me neither
<seb128> dholbach, but I guess gvfs doesn't work, I can have a look now
<jdstrand> seb128: no. mpris is different
<dholbach> seb128, should this be a bug report somewhere else?
<seb128> dholbach, against the snap?
<jdstrand> seb128: mpris needs a different dbus api
<jdstrand> seb128: so it got a different interface
<seb128> jdstrand, k, you mean to get the player listed in the sound menu there?
<dholbach> seb128, oh... I thought it was a more general thing?
<jdstrand> seb128: that is in 2.0.10
<seb128> dholbach, well, it's the same class of issues, snappy forces you to bundle things but that's sort of by design
<jdstrand> seb128: as mentioned to davidcalle-- I could not get vlc to show up in the sound menu. I think it is a packaging issue (no denials)
<jdstrand> davidcalle: can you also paste the meta/snap.yaml for vlc?
<davidcalle> jdstrand: http://paste.ubuntu.com/18167536/  http://paste.ubuntu.com/18167588/
<jdstrand> davidcalle: I don't see any dbus denials
<jdstrand> davidcalle: is this the vlc that is in the store now?
<davidcalle> No, that's what in the store + camera, optical-drive, mpris
<jdstrand> ok, then that's similar to mine
<jdstrand> let me try this locally. I tested d-feet
<jdstrand> so it should work, but maybe I missed something. give me a few minutes
<davidcalle> jdstrand: the source (minus the new interfaces) is here https://github.com/ubuntu/snappy-playpen/tree/master/vlc
<sergiusens> didrocks are you a pkg-config expert?
<seb128> sergiusens, don't ask to ask just ask
<seb128> others might be able to reply
<seb128> and non experts as well
<didrocks> sergiusens: I did play with it quite a lot, but I'm not alone either :)
<didrocks> what's up?
<sergiusens> didrocks I am playing with this https://github.com/snapcore/snapcraft/pull/612/files which allows mhall119 to build pantheon mail but it breaks everything else
<sergiusens> didrocks all due to sysroots most likely, you need to satisfy all your pc deps in the same sysroot
<sergiusens> didrocks I am thinking of biting the bullet and rewriting all .pc files as part of snapcraft to get the correct paths and just forget the use of sysroot and just add to pkg_config_path
<didrocks> let me have a look (in a meeting, but will do just afterwards)
<sergiusens> didrocks k, I would really like to explore the latter approach though :-)
<seb128> sergiusens, easiest way would be to build in a contained env with the local and system /usr merged with a mount namespace?
<sergiusens> seb128 merged or overlayed? I would still need some mechanism to track what came from where while building
<seb128> any, just "merged"
<tsimonq2> elopio: when you get a minute, could you please look at https://github.com/snapcore/snapcraft/pull/619 ?
<didrocks> hum
<didrocks> I maybe don't understand well enough
<didrocks> but you didn't just try to export PKG_CONFIG_PATH?
<didrocks> instead of using the PKG_CONFIG_LIBDIR, which erase system's defaults pc
<didrocks> that way you get those from the sysroot and the stage/ dir?
<popey> sergiusens: do we have a bug for this? It affects a few things I want to package :)
<sergiusens> popey you know I do
<seb128> jdstrand, davidcalle, k, I know why vlc is not listed in the sound menu
<popey> I do? ok.
<sergiusens> didrocks if I don't change the sysroot for each location then the include paths pkg-config returns will be wrong
<sergiusens> which is why seb128 advocates for merging /usr (which opens a different set of problems)
<jdstrand> davidcalle: I can confirm the issue with d-feet. I think there wasn't a log due to kernel rate limiting. 'snappy-debug.security scanlog' would disable that for you, but you can also use sudo sysctl -w kernel.printk_ratelimit=0
<seb128> jdstrand, vlc has its dbus property DesktopEntry = vlc or the snap .desktop is vlc_vlc.desktop, if you rename/copy it as /var/lib/snapd/desktop/applicatons/vlc.desktop it's added as it should, we wouldn't be hitting those bug if we were using upstream .desktop (bug #1576595)
<ubottu> bug 1576595 in snapcraft (Ubuntu) "The upstream .desktop are not used" [Wishlist,New] https://launchpad.net/bugs/1576595
<seb128> sergiusens, ^ can we get that on the next milestone list somewhat?
<seb128> the current design breaks users and doesn't allow for easy translations
<didrocks> sergiusens: sorry, what do you mean for each location? basically your parts sysroots are depending on 3 folders, right? your insider build/, your stage and system root path?
<sergiusens> seb128 I need to have a heated discussion with a couple of people first
<jdstrand> note we are generating the desktop file for safety since the desktop file specification is rich
<sergiusens> didrocks parts/<part>/install, stage and /
<seb128> sergiusens, can I be included? I'm curious to know they argument for reinventing the wheel
 * ogra_ hands sergiusens icecream for the heated discussion
<jdstrand> obviously we should support this case, but taking the upstream file might not be the way to go
<seb128> like we have upstream providing those including translations
<jdstrand> I guess this is all part of said heated discussion
<seb128> jdstrand, no, but taking the upstream one would make sense, we are duplicating it for a non translated copy that get outdated just to be able to change the Exec, why just not copying with a sed?
<sergiusens> seb128 well all this is a snappy thing; there are some comments about doing something smart, but that doesn't cope well with replacing what needs replacing; I want to make it declarative
<seb128> yeah, fine
<seb128> get the yaml to have
<seb128> desktop:
<seb128> command: <bla>
<seb128> icon: <great>
<seb128> and sed those
<seb128> you can also have url:
<seb128> to point to the upstream one you want to sed/copy
<jdstrand> seb128: verifying a rich specification is much harder than generating your own subset
<sergiusens> seb128 yes, that is my idea
<seb128> jdstrand, well, everything in that spec is useful and needed
<seb128> they wouldn't be there is they weren't
<jdstrand> which is why it is the way it is. again, obviously this issue needs to be fixed, I'm just saying why the situation is what it is
<jdstrand> you could say that about anything
<sergiusens> I sent a gazillion emails, requests and even commented on the reviews to not due freaking things by convention as it would be super hard to deal with all the corner cases this would bring
<jdstrand> that spec was not designed for snappy
<jdstrand> it was designed for the old world
<seb128> well, fine
<seb128> copy the Name/Comment from upstream at least
<seb128> those for sure make sense and are safe?
<seb128> that would give you translations
<seb128> and non duplication of strings
 * jdstrand notes that he is not the blocker on this but just knows a bit about the previous conversation and issues
<seb128> jdstrand, do you have any of those keys that you see unfit for snappy though?
<seb128> like ShowOnlyIn is also useful in snappy
<seb128> as are the NotShowIn&co
<seb128> same for MimeType
<seb128> which is another funny/buggy thing today
<seb128> if you snap gedit you can't get it to open files when clicking on those
<jdstrand> what you are suggesting would need proper review of the desktop file specification and design of what is appropriate for snappy and how
<seb128> yes
<jdstrand> I don't have a list of unfit things otoh because that design hasn't happened
<seb128> or review and flag things to filter out
<seb128> my guess there is that it's little or nothing
<jdstrand> better to say what is ok to let in and filter everything else out
<seb128> my guess is that it would have taken less time to do that upfront that redesign a buggy solution temporary solution and dealing with the issues it creates
<jdstrand> seb128: can you tell me exactly what I need to do to test vlc in the sound menu? I was a little confused by your previous comment
<seb128> jdstrand, sudo cp /var/lib/snapd/desktop/applications/vlc_vlc.desktop /var/lib/snapd/desktop/applications/vlc.desktop
<jdstrand> seb128: you are assuming that snappy on classic was a thing when this was implemented
<seb128> jdstrand, then start vlc and play a sound
<seb128> well works at least in devmode here
<jdstrand> weird
<seb128> I didn't try in non-dev because I didn't have my snapd updated yet
<jdstrand> I don't have /var/lib/snapd/desktop/applications/vlc_vlc.desktop
<jdstrand> maybe I have a too old vlc
<seb128> I just did a fresh snap install vlc on and amd64 xenial machine with snappy 2.0.9
<seb128> jdstrand, do you have any .desktop in there?
<jdstrand> krita
<jdstrand> seb128: are you building vlc from snapcraft or installing from the store?
<davidcalle> jdstrand: store vlc has one
<seb128> jdstrand, cf 2 lines up ;-)
<seb128> "snap install vlc"
<seb128> sorry that was meant as typing that command
<seb128> so store version
<jdstrand> yeah, I'm grabbing it
<seb128> cool
<jdstrand> the store one doesn't have the camera, optical-drive or mpris changes
<jdstrand> so I need to grab the store one, unpack, adjust, repack, etc
<jdstrand> I think I just had an old repack
<jdstrand> davidcalle: ok, I see the problem. I think this is only an issue with d-feet's way of introspecting. I added rules to support introspection for 'snap connect'ing vlc to a remote, but not for unconfined on classic. this is a minor bug that I'll fix in a minute
<jdstrand> davidcalle: now that seb128 told me how to test the indicator, I'll test that too. there may be adjustments there as well
<davidcalle> jdstrand: thank you for this
<seb128> dholbach, sorry things got a bit crazy and I think I forgot to reply to you
<seb128> dholbach, or I did, don't remember
<seb128> dholbach, for gvfs my guess is that you need to bundle the gvfs gio .so
<dholbach> seb128, I asked for an example in the bug report
<seb128> k
<jdstrand> davidcalle: meh, the version in the store does something different with mpris :\
<davidcalle> o_o
<jdstrand> actually, maybe not
<davidcalle> jdstrand: most recent commit on vlc master is older than the latest store snap version, there should be no diff there
<jdstrand> davidcalle: ok, strike that, I did something dumb
<jdstrand> davidcalle, seb128: ok, in strict mode after copying the desktop file, it shows up in the indicator and I can stop/play/etc
<jdstrand> davidcalle: so, yes, I'll fix the d-feet issue, but that is minor and specific to d-feet (or anything introspecting, but not the indicator)
<seb128> jdstrand, \o/
<jdstrand> using 'slots: [ mpris ]' of course
<davidcalle> jdstrand: brilliant! Can you paste the desktop file you have now?
<seb128> it's the same
<seb128> just renamed
<seb128> using the upstream name
<jdstrand> davidcalle: all I did was cp vlc_vlc.desktop vlc.desktop like seb128 suggested
<davidcalle> Oh
<jdstrand> it worked fine
<seb128> vlc has a properties that it export over dbus with the name
<seb128> in the mpris interface
<seb128> which has vlc
<davidcalle> I see
<zyga> jdstrand: hey, how is snapd 2.0.10 and vlc?
<jdstrand> zyga: I just reported on that :)
<kyrofa> zyga, jdstrand where is snap-exec?
<jdstrand> zyga: it works great with one thing: the desktop file should be named 'vlc.desktop' instead of 'vlc_vlc.desktop'
<zyga> jdstrand: is the name of the desktop file significant?
<zyga> jdstrand: AFAIR now it is just $SNAP_NAME.$APP_NAME
<zyga> kyrofa: in snapd
<iliv> if my binary is under prime/bin/ what should my apps: definition look like? bin/mybinary?
<zyga> iliv: apps: somename: command: mybinary
<zyga> iliv: (assuming mybinary is on PATH)
<jdstrand> zyga: if vlc adds 'slots : [ mpris ]'. I didn't test camera and optical drive, but I did test that specifying them in the yaml generates the policy
<zyga> jdstrand: I tested both
<zyga> jdstrand: but I'll test everything again if you have a snap handy
<jdstrand> zyga: I don't have a lot of insight into the desktop file name. seb128 indicated it is significant at least for vlc
<zyga> seb128: can you tell me more about that
<zyga> seb128: we can fix that easily for .11
<davidcalle> zyga: for me camera doesn't seem to work
<iliv> zyga, where does the PATH come from? I certainly did not specify it anywhere myself.
<seb128> zyga, in an hangout but basically vlc (and some other program) look for their known .desktop name
<jdstrand> zyga: I do have a snap handy, but it would probably take longer for me to upload and you to download than for you to 'snap install vlc', grab the snap from /var/lib/snapd/snaps, unsquashfs it, modify meta/snap.yaml accordingly, then snapcraft snap ./squashfs-root, then remove/install the new snap
<kyrofa> zyga, ah, it must be u-c-l then. Is that still on LP, or in github nowadays?
<jdstrand> which, I have to say, is a convenient property of snaps
<zyga> kyrofa: no, that's in snapd itself
<davidcalle> zyga: I can push one to the edge channel if you want to, but my network tells me it will be faster for you to do ^ :)
<zyga> kyrofa: in the repo
<kyrofa> zyga, sorry, no-- the problem I'm running into must be u-c-l
<zyga> davidcalle: please push it, I have network issues
<davidcalle> zyga: alright
<zyga> jdstrand: ah
<jdstrand> zyga: is the new u-c-l upload planned? I thought it was going to accompany 2.0.10
<zyga> jdstrand: yes, please share the meta.yaml
<zyga> jdstrand: it is coming
<zyga> jdstrand: just last minute stuff
<jdstrand> zyga: great :)
<jdstrand> zyga: http://paste.ubuntu.com/18171909/
<jdstrand> zyga: if you rename the desktop file, then it shows up in indicator sound and that works :)
<jdstrand> fun stuff :)
<kyrofa> jdstrand, is u-c-l still in LP?
<jdstrand> kyrofa: yes. auiu the snappy team is going to continue to use that name for the source package in xenial
<kyrofa> jdstrand, ah, even when it actually changes to snap-confine?
<jdstrand> yes
<kyrofa> Makes sense
<jdstrand> there will be transition binaries in the xenial packaging
<kyrofa> jdstrand, am I being dumb? I thought it was here: https://launchpad.net/ubuntu-core-launcher
<zyga> jdstrand: I'll look at it in a sec, just in a meeting now
<jdstrand> kyrofa: that is the lp project
<kyrofa> jdstrand, it's a 404 for me
<jdstrand> kyrofa: snap-confine has moved to github
<kyrofa> jdstrand, what's running xenial today? It's still the LP u-c-l, right?
<jdstrand> kyrofa: https://github.com/snapcore/snap-confine
<jdstrand> kyrofa: today it is https://launchpad.net/ubuntu/+source/ubuntu-core-launcher
<kyrofa> Ah, that's what I was looking for, thanks!
<kyrofa> Wait... no source there? I guess I can just pull the source deb
<jdstrand> kyrofa: in other words, the u-c-l LP project is gone and moved to snap-confine on github, but the Ubuntu sources for u-c-l live on in the archive
<kyrofa> Ah, okay that explains my confusion :)
<jdstrand> kyrofa: right, source deb
<jdstrand> and it is the Ubuntu source deb that, aiui, will remain named as u-c-l for xenial, but have the snap-confine code, when that happens (soon I'm told)
<zyga> kyrofa, jdstrand: it's been renamed everywhere except for the source package AFAIK
<jdstrand> right
<zyga> eh. google down :/
<zyga> time to get a coffee
<jdstrand> yeah
<jdstrand> annoying
<zyga> they should adopt snaps, at least there's rollback :)
<kyrofa> zyga, is there though? :P
<kyrofa> zyga, has it been released?
<zyga> kyrofa: hmmm
<zyga> maybe not released, .11 ?
<kyrofa> Indeed. I stopped touting that feature until it actually worked
<kyrofa> Got called on it too many times :P
<kyrofa> zyga, too late to get something into the snap-confine upload?
<tsimonq2> sergiusens: when you get a minute, could you please look at https://github.com/snapcore/snapcraft/pull/619 ?
<zyga> kyrofa: nope
<zyga> kyrofa: gimme!
<kyrofa> zyga, a little modification to the appname whitelist to allow hooks
<zyga> kyrofa: I was planning to do the release at EOD and that's still far a way
<zyga> kyrofa: sure, just send it in
<kyrofa> zyga, alright, will do
<zyga> kyrofa: and <3 hooks :)
<sergiusens> tsimonq2 yeah, enqueued
<tsimonq2> thank you sergiusens
<kyrofa> zyga, also, I see that run-checks only runs spread tests. Are you moving away from the tests dir?
<sergiusens> kyrofa mind looking at https://github.com/snapcore/snapcraft/pull/617
<zyga> kyrofa: that's somewhat confusing, tests/ is ran at package build time
<zyga> kyrofa: which is done by spread
<kyrofa> zyga, oh, haha, okay
<zyga> kyrofa: but yes,  we do move oaway from tests/ today
<zyga> kyrofa: because when snap-exec hits, those will all break
<zyga> kyrofa: and they don't really test the real code entirely, just the seccomp part
<zyga> kyrofa: I plan to port them to spread
<kyrofa> zyga, so there are already whitelist tests in tests/. I was going to just add to that, but I can add a spread test instead if you prefer
<zyga> kyrofa: I'd prefer a spread test
<kyrofa> zyga, okay
<zyga> kyrofa: or a unit test :)
<zyga> kyrofa: if this is easier to do as a unit test
<kyrofa> zyga, where are the units? It probaby would be, yeah
<zyga> kyrofa: or more sane, you pick
<zyga> kyrofa: landing in a sec
<kyrofa> zyga, ah ha :)
<zyga> kyrofa: I was just distracted with arch discussion elsehwere
<kyrofa> zyga, yeah, ping me when that lands and I'll pull and add
<zyga> yep
<davidcalle> zyga: I did domething wrong apparently. Rebuilding the snap... hold on, I'll ping you when it's on the edge channel. :)
<zyga> davidcalle: OK
<zyga> kyrofa: ok, fire away
<zyga> kyrofa: you can run make check in src/ to run unit tests
<zyga> kyrofa: or you can use the appropriate spread task
<zyga> kyrofa: to add one just look at mount-support-test.c
<kyrofa> zyga, excellent, doing now, thanks!
<zyga> kyrofa: you essentially need a static test function
<zyga> kyrofa: and a static initializer that registers it
<kyrofa> zyga, FYI mount-support-test.c copyright is 2015
<ogra_> living in the past
<davidcalle> I can confirm vlc<->mpris and camera work. Can't test dvd. Very slow upload to the edge channel in progress... /me goes pick up the kids in the meantime
<zyga> davidcalle: try an audio CD
<zyga> davidcalle: thanks for testing!
<zyga> ogra_: why? :)
<seb128> tedg, jdstrand, didrocks, debugging appmenu for qt5 with didrocks, seems like with a qt5 example the path is "/MenuBar/1" and not "/MenuBar" which triggers apparmor errors ... would "/MenuBar*" works/be correct? or "/MenuBar/[0-9]*"?
<ogra_> zyga, dunno, you tell me )
<zyga> because you smoke! quit already man :)
<zyga> ;-)
<ogra_> lol
<ogra_> you sound like my dentist
<didrocks> jdstrand: btw, it was puzzling because the denial wasn't in auditlog, but only in syslog. The label was correct though.
<zyga> jdstrand: what's the policy for fix commited on ubuntu tasks?
<zyga> jdstrand: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1595029
<ubottu> Launchpad bug 1595029 in ubuntu-core-launcher (Ubuntu) "ubuntu-core-launcher needs urandom access" [Medium,In progress]
<zyga> jdstrand: can we close this bug: https://bugs.launchpad.net/snap-confine/+bug/1460517
<ubottu> Launchpad bug 1460517 in Snappy Launcher "ubuntu-core-launcher apparmor denial when creating /tmp/snaps" [Undecided,New]
<zyga> kyrofa: is this still applicable to snap-confine? https://bugs.launchpad.net/snap-confine/+bug/1559248
<ubottu> Launchpad bug 1559248 in Snappy Launcher "Support unversioned data directory (i.e. data shared between versions)" [Undecided,New]
<kyrofa> zyga, no, that's done in snap run now
<zyga> kyrofa: cool, let's close the snap-confine task then
<jdstrand> zyga: for Ubuntu, it is marked fix committed when it is in -proposed
<zyga> jdstrand: ah, I see, thanks!
<dholbach> all rightie - I call it a day - see you next week Monday!
<ogra_> enjoy your long weekend !
<zyga> jdstrand: I know we talked about it but if you have a moment, can you write something on https://bugs.launchpad.net/snap-confine/+bug/1595092 -- this is the last current NEW bug on snap-confine
<ubottu> Launchpad bug 1595092 in Snappy Launcher "rpmlint complains about POS36-C" [Critical,New]
<zyga> dholbach: o/
 * zyga envies long weekend :)
 * ogra_ too
<jdstrand> zyga: I closed 1460517 just now
<jdstrand> tyhicks: I can't recall what we said about bug #1595092 - I thought we decided either you or sarnold_ would comment since you did the code review of that part of the code, but maybe I am making that up :)
<ubottu> bug 1595092 in Snappy Launcher "rpmlint complains about POS36-C" [Critical,New] https://launchpad.net/bugs/1595092
<kyrofa> zyga, is there a reason you're not just making a lib and linking to it from the tests?
<kyrofa> Including .c files feels dirty :P
<tyhicks> jdstrand: I don't think I've seen that bug before
<zyga> kyrofa: yes, static function
<zyga> kyrofa: it's a "pick your poison" problem either ifdefs or this
<zyga> kyrofa: I like how it has a -test.c theme that looks closer to go
<zyga> kyrofa: I know it cannot be really go because of translation units vs modules
<zyga> kyrofa: but it's better than nothing :)
<tyhicks> jdstrand: I left a comment and will discuss with Seth some more once he joins
<jdstrand> cool, thanks
<didrocks> seb128: jdstrand: FYI, /MenuBar* doesn't work (/MenuBar/* works), but we need as well /MenuBar for gtk
<jdstrand> tyhicks: I guess you're saying I made that up then? :P
<seb128> didrocks, thanks for trying
<jdstrand> didrocks: please file a bug with steps to reproduce and add the 'snapd-interface' tag
<didrocks> jdstrand: we can even add a PR ;) it's apparmor?
<didrocks> or snapd?
<jdstrand> it's snapd, but if doing a PR, ping me
<didrocks> sure! (a task for tomorrow now, EOD), seb or I will do!
<tyhicks> jdstrand: one of us is forgetful but I'm not sure which one it is :)
<jdstrand> didrocks: fyi, ./interfaces/builtin/unity7.go. note, I'm off tomorrow and Monday, but I'll look at it Tuesday which is more than enough time to get it in 2.0.11. if you need it sooner, you might ask another member of the security team
<tsimonq2> !info default-jdk
<ubottu> default-jdk (source: java-common (0.56ubuntu2)): Standard Java or Java compatible Development Kit. In component main, is optional. Version 2:1.8-56ubuntu2 (xenial), package size 0 kB, installed size 6 kB
<tsimonq2> !info default-jdk wily
<ubottu> default-jdk (source: java-common (0.52)): Standard Java or Java compatible Development Kit. In component main, is optional. Version 2:1.7-52 (wily), package size 0 kB, installed size 21 kB
<davidcalle> zyga: jdstrand: fyi, vlc in edge
<zyga> davidcalle: \o/
<zyga> davidcalle: great, I'll play with it soon
<zyga> kyrofa: will you provide the hook patch today?
<kyrofa> zyga, yeah, almost done
<zyga> kyrofa: I'm looking at a release in 1-2 hours or later after the portugal/poland game
<zyga> kyrofa: thanks!
<kyrofa> zyga, the udev profiles not containing periods is taking me a little while to work around
<kyrofa> Err, the tag rather
<kyrofa> zyga, alright, take a look: https://github.com/snapcore/snap-confine/pull/64
<kyrofa> zyga, I also copied the regex from snapd to reflect it a bit more closely
<zyga> kyrofa: have a look at this one in return please: https://github.com/snapcore/snap-confine/pull/65
<zyga> kyrofa: reviewed
<zyga> kyrofa: just one change and few nitpicks
<kyrofa> zyga, also reviewed yours. By the way, looks like travis isn't able to authenticate to linode?
<zyga> kyrofa: yes, that's my fault; there's something I have to do but I was putting it off
<zyga> kyrofa: spread.yaml doesn't list the key
<zyga> kyrofa: the key is in travis itself
<zyga> kyrofa: but that apparently doesn't work for forks at all
<zyga> kyrofa: to compute a key I can stick into spread.yaml I'd have to install a bunch of ruby stuff
<kyrofa> zyga, haha, I have the travis gem if you want me to do it
<zyga> kyrofa: and I just want to do that in a vm/container that I throw away later
<zyga> kyrofa: if you can, please
<zyga> kyrofa: if you have the spread key
<zyga> kyrofa: please add it
<kyrofa> zyga, I don't actuallly-- want to email it to me? You can encrypt it if you like
<zyga> kyrofa: that's okay, I'll get the gem eventually :)
<kyrofa> Okay
<kyrofa> zyga, I left a few questions for you on my PR
<zyga> kyrofa: checking
<zyga> kyrofa: merged, thank you!
<kyrofa> Thanks zyga!
<juanrubio> \quit
<zyga> kyrofa: can you have a 2nd look on https://github.com/snapcore/snap-confine/pull/65/files
<zyga> kyrofa: something as simple as is_subdir and still can be broken
 * zyga -> off to watch the game
<kyrofa> zyga, done!
<kyrofa> Looks good
<zyga> woot; thanks :)
<thomi> Hey snappy experts: I have a python snap (built with python2 snapcraft plugin) that's really not very happy - I get this when trying to run the command: http://paste.ubuntu.com/18191348/
<thomi> does anyone have any ideas? The same source, when installed to a py2 virtualenv works fine
<zyga> thomi: odd, no idea
<zyga> thomi: can you triple check that your snap ships python2
<thomi> :(
<zyga> thomi: I recommend adding busybox app / part to your snap
<zyga> thomi: then run busybox sh to experiment
<zyga> thomi: you can check environment, etc
<thomi> zyga: /snap/sofastats/x1/usr/bin/python2.7 exists
<thomi> ahh - nice tip
<zyga> sergiusens: ^^
 * zyga off to watch 2nd part of POL vs POR game
<thomi> I didn't know those countries played cricket ;)
<zyga> thomi: heh :)
<thomi> zyga: I think I might be hitting confinement issues - I see apparmor denials in syslog when trying the busybox hack, which is odd, since it's a devmode snap
<thomi> My understanding is that devmode snaps should essentially have confinement turned off?
<zyga> thomi: paste one line here
<thomi> zyga: hmmm - when I try it in a new shell it works fine. Perhaps I had something set that caused breakage
<thomi> zyga: but I can confirm that python is installed, and seems to work
<tyhicks> sarnold: hey - could you double check my comment in bug #1595092?
<ubottu> bug 1595092 in Snappy Launcher "rpmlint complains about POS36-C" [Critical,New] https://launchpad.net/bugs/1595092
<thomi> zyga: ahh, but the #! line on the app still points to the python interpreter in my snapcraft 'parts' directory. Shouldn't that be updated to point to the python installed in /snap/<snapname>/current/usr/bin/ ?
<sergiusens> zyga what?
<thomi> sergiusens: what should the #! line of a python script in a snap be that's been built with the python2 plugin? It should point to the shipped python2 interpreter, right?
<sergiusens> thomi we already had barry log a bug about that on python
<thomi> sergiusens: the bug is in python itself?
<sergiusens> thomi all setup_scripts and such get that; what we are doing in snapcraft is calling python or python3 on the declared command
<sergiusens> thomi setuptools overwrites shebangs and there is no way to disable it
<thomi> sergiusens: ahh ok, so it's probably not the cause of my issue then
<thomi> sergiusens: however, the script is still trying to open the stdlib from my parts directory: Jul  1 08:46:36 thinkpad kernel: [185816.217465] audit: type=1400 audit(1467319596.615:122): apparmor="DENIED" operation="open" profile="snap.sofastats.sofa" name="/home/thomi/code/snapcraft/sofa/parts/sofa/install/usr/lib/python2.7/os.py" pid=19150 comm="sofa"
<thomi> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<thomi> sergiusens: I think it's because the command wrapper ends in "exec "sofa" "$@""
<thomi> sergiusens: so we're not explicitly invoking the python in the snap, but rather using the python mentioned in the scripts !# line
<thomi> does that make sense?
<sergiusens> thomi let me check the code, this was a nice contribution from BjornT_
<sergiusens> kyrofa mind looking at this https://github.com/snapcore/snapcraft/pull/620 ? I am still missing one thing, installdir
<thomi> sergiusens: thanks - I'm on snapcraft version 2.11 BTW
<sergiusens> thomi no worries, everyone should have this fix by now...
<sergiusens> thomi so wait, I might go faster if I see your yaml
<sergiusens> thomi so https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/meta.py#L190 is the logic, it should have the correct statement
<thomi> sergiusens: hmm - this is in snapcraft 2.11?
<sergiusens> thomi but, the command needs to be a full relative path or else... https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/meta.py#L218
<sergiusens> thomi yeah, no worries, you found a bug it seems
<sergiusens> should be easy to fix
<sergiusens> thomi as a workaround though, instead of `command: sofa` try `command: bin/sofa` (or usr/bin or whatever applies)
<thomi> cool
<sergiusens> and that would confirm this
<thomi> sergiusens: will do, thanks
<sergiusens> if you want to log a bug I will fix faster too :-P
<thomi> sergiusens: that workaround does indeed fix the issue
<thomi> sergiusens: sure thing - bugs on github or lp?
<sergiusens> thomi https://bugs.launchpad.net/snapcraft/+filebug
<thomi> ta
<thomi> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1597919 hope that's clear enough
<ubottu> Launchpad bug 1597919 in Snapcraft "python setuptools entry_point scripts have wrong #! line when specified with a relative path" [Undecided,New]
<jdstrand_> davidcalle: fyi, this fixes d-feet with vlc: https://github.com/snapcore/snapd/pull/1460
<mwhudson> wow snappy and go 1.7 do not get on very well
<qengho> mwhudson: how so?
<mwhudson> qengho: some json thing, i'll file a bug in a moment
<mwhudson> hm or maybe my go tip build was out of date
<mwhudson> yes seems so, phew
<mwhudson> https://bugs.launchpad.net/snappy/+bug/1597948 is real though
<ubottu> Launchpad bug 1597948 in Snappy "github.com/snapcore/snapd/cmd/snap TestSnapRunSnapExecEnv fails if HOME is set in environment" [Undecided,New]
#snappy 2016-07-01
<mcphail> Is there a definitive list of what plugs are allowed in snapcraft.yaml, including detail on exactly what they do and don't allow the app to do?
<seb128> mcphail, "snap interfaces" gives you a list, unsure about descriptions
<qengho> ...but those vary by snapd, not the snapcraft version.
<willcooke> hey qengho didrocks
<didrocks> hey willcooke!
<didrocks> so, as we discussed on #ubuntu-desktop, to move your snap to the new launcher desktop
<seb128> popey, hey, on that snaps list document, for gtetrinet you have a systemctl cassandra cmd as "where", I guess that's a copy error?
<willcooke> qengho, it's nice having you around in the morning!  Please move to Taiwan full time.
<didrocks> willcooke: you just need to replace gtk3conf -> desktop/gtk3
<didrocks> and for the command: gtk-launch -> desktop-launch
<didrocks> and that should be it!
<willcooke> oh
<willcooke> wow
<willcooke> nice
<didrocks> if you are using snapcraft 2.12, you need to "snapcraft update" before running "snapcraft"
<willcooke> didrocks, sudo that? ^
<didrocks> no need for sudo
<willcooke> running....
<willcooke> didrocks, do you know if anyone is working on command completion for snapd at all?
<didrocks> willcooke: not that I know of. I would like to have some time to do it, it's part of the dev experience to me :)
<didrocks> (and yeah, we need advanced shell completion)
<willcooke> didrocks, would love to help with that.  Learn a bit of Go too
<willcooke> didrocks, maybe a good 1st job for the new snappy focused desktop team member when we hire them too
<qengho> willcooke: It's tempting! I like it here. But, it's 16:30 now. And I might grow fat because the food is so good.
<popey> seb128: uh, dunno how that got there
<popey> seb128: someone else probably pasted crap in by accident
<seb128> yeah, likely
<seb128> can you put back the right value?
<popey> uhm
<popey> i dont think it had anything in it
<seb128> k, it's in the store?
<popey> no
<mcphail> seb128: qengho: thanks. So is there any way to find this out directly from the running snapd, or do I need to dig into the source of the version of snapd to see what the plugs can and cannot do?
<joc_> didrocks: hey, sorry to bug you, wondered if you were interested in commenting on this PR? (sergio thought you might be) https://github.com/snapcore/snapcraft/pull/614
<seb128> popey, well, I can have a look to the warning if you share the snapcraft.yaml/script with me in some way
<popey> I'll take another look at it. not touched gtetrinet for 2.5 months
<popey> so probably needs to switch to the gtk launcher
<popey> among other things
<qengho> mcphail: plugs are complicated combinations of system-call filters and filesystem/dbus/socket/etc filters, and those are too detailed to make sense in a small list, except where it glosses over a lot of stuff.
<seb128> right
<willcooke> didrocks, quick initial test - settings are now preserved, but menus are not exported
<qengho> mcphail: If the name isn't meaningful, then something is wrong. A plug should fit a whole class of needs. If it doesn't we would love to have a bug report to suggest tweaks. So, use what you see, and tell us if it's wrong or insufficient.
<qengho> mcphail: The short answer is "it changes all the time, and please try it and we'll fix problems."
<mcphail> qengho: ok, if it is a moving target that s fair enough
<didrocks> jdstrand_: https://github.com/snapcore/snapd/pull/1463 here we go, do not hesitate if you have any question! :)
<seb128> I still think that's a valid point
<didrocks> joc_: yeah, I need to give a look, will do before EOD
<seb128> those might be documented
<seb128> didrocks, do you know if interfaces are documented somewhere?
<didrocks> willcooke: yeah, known bug
<joc_> didrocks: ack, thanks
<seb128> like the list of ones available with the version they have been added to and a short description?
<didrocks> seb128: oh wait, no, it's gtkâ¦
<didrocks> oupss
<didrocks> willcooke: ^
<didrocks> willcooke: let's look at it together in a sec
<didrocks> seb128: yeah, there are some descriptions, one sec
<mcphail> qengho: am I right that the "home" plug restricts access to dot files and directories? What is the rationale for that?
<willcooke> didrocks, sure thing, just testing again against the other launcher, where I think it worked.  If so, should be easy to fix
<didrocks> seb128: the best resource we have on this is https://developer.ubuntu.com/en/snappy/guides/interfaces/
<didrocks> willcooke: interestingâ¦ it's a gtk app, right?
<qengho> mcphail: I don't know.
<mcphail> That page is helpful. Thanks didrocks and seb128
<mcphail> qengho: cheers
<didrocks> yw!
<popey> Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'gtkconf'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache
<popey> when doing a cleanbuild ^
<popey> how do you do a snapcraft update inside lxd?
<davmor2> popey: same way surely
<popey> no, that is inside lxd
<davmor2> popey: does the container have an network connection?
<popey> lxd/lxc is clean inside
<popey> yes
<didrocks> popey: yeah, cleanbuild doesn't work inside lxd
<popey> so inside the container it doesn't "know" about gtkconf
<didrocks> sorry
<seb128> didrocks, 'ci
<didrocks> cloud parts don't work inside lxd
<popey> sorry, maybe I meant lxc
<didrocks> AFAIK
<didrocks> unsure anyone opened a bug yet
<popey> hm
<didrocks> I guess it's missing "snapcraft update"
<popey> no
<popey> thats not true
<popey> because I have another one here which works using qt5conf
<popey> but gtkconf fails
<didrocks> and it works? oO
<didrocks> ok, so not that issue
<popey> does snapcraft ship "knowing" about qt5conf?
<mcphail> popey: no
<didrocks> I doubt
<seb128> is gtkconf still a thing?
<popey> is it not? :)
<popey> it works outside the container
<seb128> k, dunno then
<seb128> didrocks superseeded it with a better version
<seb128> but gtkconf should still work I guess
<davidcalle> didrocks speaking of desktop confs, I'm trying your qt5 launcher with vlc, but no dice: the menu disappears from vlc, but never gets exported. No theming either. Do you want the snap?
<popey> http://paste.ubuntu.com/18220245/ is my super simple yaml if anyone wants to reproduce
<popey> snapcraft works, snapcraft cleanbuild does not
<didrocks> davidcalle: ah, no theming is weird
<didrocks> davidcalle: but appmenu not working is expecting
<davidcalle> Ok
<didrocks> see my messages from yesterday
<popey> seb128: ^ fwiw that's as far as I got with gtetrinet - it launches but theme is broken and it doesnt launch properly
<didrocks> davidcalle: snapd needs https://github.com/snapcore/snapd/pull/1463
<didrocks> davidcalle: so yeah, we need to look at the theme
 * davidcalle cat * | grep didrocks
<davidcalle> didrocks: ok :)
<didrocks> davidcalle: do you have the theme unconfined?
<davidcalle> didrocks: nope (but I have the menu)
<didrocks> yeah, menu is expected
<didrocks> theme, ok, we need to look at it together
<didrocks> mind having a HO in like, I don't knowâ¦ 20 minutes ?
<popey> In another app of mine, I am using qt5conf but get this when I launch it:-
<popey> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
<popey> anyone seen that before?
<seb128> popey, did you bundle libgtk2.0-0?
<popey> no
<popey> should I?
<seb128> likely the issue
<popey> ok, thanks
<seb128> if you want the QGtkStyle to work yes
 * popey rebuildificates
<mcphail> Hmm. Is there any way to give a snap access to dotfiles and dotdirectories in $HOME without running completely unconfined? I can't understand the thinking behind this
<seb128> I think didrocks's new launcher handle that for you
<popey> oooh
<popey> new launcher
<didrocks> it does!
<seb128> mcphail, thinking is that apps are not able to steal your gpg or ssh keys or stored password in .config
<didrocks> popey: new launcher*s* :)
<seb128> mcphail, normal apps want to access files/documents, not configs from the system
<mcphail> seb128: there'll be equally valuable credentials stored in normal files, though.
<mcphail> seb128: i need my app to access
<mcphail> .gitignore files etc
<seb128> I'm sure that could be whitelisted
<seb128> open a bug?
<mcphail> seb128: against snapd?
<seb128> mcphail, and "there could be other issues" it's a rational for "don't try to protect the user at all"
<seb128> yes
<seb128> tag it snapd-interface
<seb128> it's *not* a rational
<mcphail> seb128: thanks. will do
<seb128> mcphail, would maybe be better to give access to specific xdg dirs
<seb128> like xdg music/video
<seb128> that would be even less likely to have the issue
<mcphail> Maybe. so many overlapping concerns
<seb128> I think the rational is that usually users don't go browser .config files
<seb128> browse
<seb128> that's system details
<seb128> anyway the proper solution there is to have a file picker interface or a prompt saying "apps try to access ~/.gitignore, auth/nack"
<mcphail> seb128: i'll maybe tidy up my yaml file and ask on mailing list for opinions
<seb128> great
<didrocks> willcooke: want to have a look together at the menu thingy?
<didrocks> if it works with gtkconf
<didrocks> and not with the new launcher
<seb128> didrocks multi-hangouts :p
<didrocks> ahah, oki!
<seb128> didrocks, I can help will while you help david if you want
<didrocks> let's do this!
<willcooke> didrocks, sure thing!
<seb128> cool
<seb128> willcooke, sorry, you are stucked with me helping you :p
<willcooke> :D
<seb128> willcooke, can you push your current version to github?
<willcooke> how shall we do this, hangout or IRC?
<popey> what is the current way to fix theme issues? I have an app which looks like Windows 95
<willcooke> popey, gtk app?
<popey> qt
<didrocks> popey: interesting, with the new launcher?
<seb128> popey, using didiers' launcher?
<didrocks> desktop/qt5?
<popey>     after: [qt5conf]
<popey> ^ doing that
<didrocks> use my launcher
<didrocks> it's supposed to fix it
<popey> how?
<didrocks> replace qt5conf -> desktop/qt5
<didrocks> qt-launch -> desktop-launch
<didrocks> and rebuild
<seb128> willcooke, we can hangout in a few minutes if you want? if you push your changes I can build it here while making some coffee and then we can have a look
<popey> ok
<didrocks> popey: the example qt app is at least themed with it :)
<didrocks> no promise on yours! the painting is still fresh on walls
<popey>  ð
<popey> building!
<willcooke> seb128, pushed: https://github.com/8none1/gedit310
<seb128> good
<willcooke> Friday shared listening:  https://heylisten.io/snappy
<willcooke> popey, ^
<popey> heheh
<popey> didrocks: your launcher seems to be trying to launch something in my home directory
<popey> this is in my snapcraft.yaml:-
<popey>     command: desktop-launch usr/local/bin/bitcoin-qt
<didrocks> popey: hum, I don't cd on purpose, is your stuff in the path?
<popey> and this is what happens when I run it
<seb128> $ sendmykeystodidrocks.sh
<didrocks> you need $SNAP
<popey> /snap/bitcoin/x11/bin/desktop-launch: line 153: /home/alan/Development/Snappy/snappy-playpen/bitcoin/usr/local/bin/bitcoin-qt: No such file or directory
<popey> oh
<popey> in the yaml?
<didrocks> yep
<didrocks> I don't cd $SNAP in the launcher anymore
<popey> okay
<didrocks> I did forgot about it
<didrocks> thanks for reminding me :)
<didrocks> you don't need to rebuild
<popey>     command: desktop-launch $SNAP/usr/local/bin/bitcoin-qt
<popey> ?
<didrocks> you can change the prime directory
<didrocks> yeah
<popey> ok
<didrocks> or if usr/local/bin is in PATH
<didrocks> just desktop-launch bitcoin-qt
<popey> how would that snap be in the path?
<didrocks> $SNAP/usr/bin as $SNAP/bin
<didrocks> are
<popey>  /snap/bin is in the path, but /snap/<snapname>/current/ etc aren't
<popey> O RLY
<didrocks> it is once launched from the u-c-l wrapper
<didrocks> they add those to the PATH :)
<popey> cunning
<popey> okay. thanks
<didrocks> I wonder if we should get usr/local/bin added
<ogra_> just build your app with --prefix=/usr and not with --prefix=/usr/local
<didrocks> ogra_: well, that's the next step :)
<popey> yeah, will do that
<popey> currently using that prefix
<didrocks> let's get it running right now
<didrocks> yeah, we know it's working that way for now, let's see if the theme is fixed then!
<didrocks> seb128: sshhhhhhhhhhh, that was supposed to be a secret malware script ;)
<seb128> :-)
<popey> didrocks: fyi ln: failed to create symbolic link '/home/alan/snap/bitcoin/x12/.themes/themes': Read-only file system
<popey> didrocks: and theme still looks ye olde
<didrocks> hum
<didrocks> do you have your source somewhere?
<popey> didrocks: http://paste.ubuntu.com/18222328/
<didrocks> hum onfigflags: [--prefix=/usr
<didrocks> did you run that version?
<didrocks> (as you still ref usr/local)
<popey> yes
<popey> uh.
<popey> where do I reference usr/local?
<didrocks> broken --prefix option maybe?
<didrocks> ah
<didrocks> sorry, it's commented :)
<didrocks> #    command: qt5-launch usr/local/bin/bitcoin-qt
 * popey sends didrocks to get his eyes tested
<didrocks> popey: I'll send you the bill back :)
<popey>  ð
<seb128> willcooke, hum, the menus work fine here :-/
<willcooke> hmm
<willcooke> seb128, using the new launcher?
<seb128> well, got your git, did snapcraft, installed the snap and typed gedit310
<seb128> got gedit opening with integrated menu and proper look
 * willcooke tries again 
<didrocks> seb128: sure it works, this is a quality launcher! :)
<seb128> lol
<didrocks> not manager-proof though :p
 * didrocks runs away
<seb128> willcooke, just try to snap remove & install?
 * willcooke slaps didrocks with a fish 
<seb128> willcooke, if it's buggy let's debug it together anyway, you keep having things working on every other try which is weird
<didrocks> willcooke: can I choose which kind of fish? :)
<seb128> didrocks, that's because you didn't integrate slides
<didrocks> oh right!
 * didrocks adds slides and attach it to a meeting
<willcooke> please do a spreadsheet as well
<didrocks> and send an email :)
<willcooke> now you're getting it
 * didrocks applies for manager role then
<didrocks> hum, desktop team manager position :)
<willcooke> send your CV in Excel format
<didrocks> heh
<didrocks> finally, bitcon-qt built
<willcooke> \o/
<didrocks> popey: waow, snapcraft is trying to do some magicâ¦
<didrocks> which is failing in that case
<seb128> willcooke, so, works after a remove/install?
<popey> \o/
<didrocks> popey: ah no, it's your fault!
<didrocks>     command: desktop-launch $SNAP/bitcoin-qt
<popey> oh :(
<willcooke> seb128, just waiting for the build to finish
<didrocks> popey: -> command: desktop-launch bitcoin-qt
<seb128> willcooke, you should still have the old .snap could try with that
<seb128> but ok
<popey> oh
<willcooke> seb128, deleted everything just to be sure
<popey> good point
<didrocks> popey: I have a gtk theme here
<popey> hang on didrocks
<didrocks> at least first dialog
<popey> i have command: desktop-launch bitcoin-qt here
<didrocks> what?
<seb128> willcooke, k, I was suggesting to try without deleting, just to see why you get things that don't work until you wipe and rebuild
<seb128> not the first time you need to re-re-build
<didrocks> popey: your pastebin is correct
<popey> http://paste.ubuntu.com/18222328/
<popey> yes
<popey> which I am using
<didrocks> popey: ok, I'm probably stupid and the other me did something while I wasn't looking
<willcooke> if you'd used google docs this wouldnt have happened
<seb128> lol
 * popey looks around the room
<didrocks> :p
<popey> didrocks: so how do you now have the gtk theme?
<didrocks> I think I started to type it while talking about the usr/local prefix thing
<didrocks> popey: the "Welcome screen" is clearly gtk themed
 * didrocks takes screenshot to ensure we talk about the same thing
<popey> http://imgur.com/IkTgAqQ
<popey> thats what I see
<willcooke> seb128, oki, rebuilt, installed -> http://imgur.com/LLPLKAR
<seb128> willcooke, hangout?
<didrocks> popey: my laptop is better than yours!
<popey> bah
<seb128> didrocks 1 - 0 popey
<willcooke> ha!
 * popey #brexits
<seb128> seb128 1 - 0 willcooke
 * didrocks is tempted about making jokes about europe
<seb128> europe 2 - 0 u.k
<didrocks> rohhh, popeyâ¦
<didrocks> :)
<seb128> in your face brexit!
<didrocks> rohhh, seb
<willcooke> seb128, https://hangouts.google.com/hangouts/_/canonical.com/will?authuser=0
<seb128> :-)
<popey> willcooke: music....
 * willcooke loving the Friday 
<didrocks> heh
<willcooke> popey, had to join a HO
<willcooke> popey, soz
<willcooke> #bants
<didrocks> popey: http://imgur.com/a/0ZItS
<didrocks> and I didn't get any warning
<didrocks> popey: snapd version?
<didrocks> 2.0.9 here
<popey> same
<didrocks> and rebooted on the new snapd daemon, I guess?
<popey> maybe I have some crap in my snap home dir due to previous builds
<popey> reboot?
<popey>  /join #windows
<didrocks> well
<didrocks> brought down the snapd service :)
<popey> ok, well, I'll have a play then, thanks for confirming the natural superiority of the French.
<popey> oh, did you install in --devmode?
<popey> (I didn't)
<didrocks> popey: nope!
<didrocks> I didn't
<popey> good
<didrocks> popey: right, we could have done France 2 - 0 UK
<didrocks> well, 1.5 because of seb128 ofc
<popey> aha, deleting ~/snap/bitcoin has 'fixed' it
<didrocks> and give 0.5 to Germany :p
<seb128> lol
<didrocks> popey: ah, hum, did you remove the previous version first?
<popey> no
<didrocks> that's why
<popey> well that sucks
<didrocks> there is a stamp with the launcher
<popey> :)
<didrocks> not really IRL
<didrocks> because here, snapd is reusing the same revision
<popey> http://imgur.com/LJuL5jC  great success!
<didrocks> but once installed from the store, a different revision is issued
<didrocks> \o/
<popey> thank you!
<didrocks> popey: want to confirm the fix for menu?
<didrocks> (if they have any menu)
<popey> the what for the what?
<didrocks> popey: does this application supposed to have menus?
<didrocks> is*
<popey> don't think so
<didrocks> ah ok, so nothing for you then :)
<didrocks> popey: FYI, based deps are brought by the launcher itself
<didrocks> so you can clean some, like the gtk2 one
<didrocks> snapcraft define desktop/qt5
<didrocks> shows them to you
<didrocks> (in case you have some duplicates)
<dpm> didrocks, ooh, do we have a qt5 launcher already?
<didrocks> yep!
<didrocks> desktop/qt5
<didrocks> change qt-launch -> desktop-launch
<didrocks>  /!\ it doesn't cd $SNAP
<didrocks> you have supposively theme support, icon support, img caching
<didrocks> appmenu needs a fix in snapd where a PR is above ^
<didrocks> (funny debugging session yesterday with seb128)
<popey> didrocks: neat!
<seb128> didrocks, https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/gtk/launcher-specific#L25
<seb128> tssss
<popey> lulz
<seb128> didrocks, arch coded,which is why it works for me and not for willcooke :p
<mcphail> http://termbin.com/tfek - if I have a set of headers in the "build-packages" stanza, should I be adding the corresponding libs to the "stage-packages" section?
<popey> didrocks: I do like your new shoes... http://imgur.com/OUU78ly
<popey> mcphail: probably not
<popey> unless it explicitly calls them
<mcphail> popey: the app will call them, but they are "standard" libs
 * popey goes to walk the dogs.
<popey> biab
<ogra_> dogs ?
<didrocks> seb128: ohhhhhhhhhhhhh
<didrocks> sad
<didrocks> so sad :)
<seb128> :-)
<didrocks> ok, fixing
<seb128> thanks
<didrocks> popey: definitively! :-)
<didrocks> that's exactly my style :)
<popey> ogra_: my brother is on holiday, I'm walking his dogs :)
<ogra_> ah
<didrocks> seb128: what arch is willcooke using?
<seb128> didrocks, amd64
<ogra_> enjoy :)
<didrocks> seb128: well, it's this file, right?
<seb128> didrocks, btw if you use desktop/gtk3 it's already gtk3 can't we force from there?
<seb128> didrocks, yeah, it was working for me because it wasn't finding gtk2
<seb128> which made it stay on gtk3
<seb128> which gedit uses
<didrocks> seb128: I can add an arg for this to put a build time option
<didrocks> seb128: I was unsure about this though
<didrocks> ah ok :)
<seb128> didrocks, are you pulling in gtk2-engines-murrine?
<seb128> I don't understand where it comes form
<seb128> from
<didrocks> seb128: not directly
<seb128> that seems what puts gtk2 in the snap
<seb128> but gedit doesn't do it
<seb128> oh, arg
<didrocks> I wonder how our gtk3 demo was working though
<seb128> light-themes does
<seb128> stupid themes
<didrocks> yeah, I was going to sayâ¦
<didrocks> (fixed pushed)
<didrocks> fix*
<didrocks> I wonder though why gtk3-demo is working and themed
<seb128> did we pull light-themes there?
<didrocks> the launcher does
<davmor2> didrocks: because it hates you?
<seb128> oh
<seb128> OH
<seb128> didrocks, gtk3-demo uses gmenumodel proper, no need of the unity-gtk-module exporter, where gedit 3.10 uses old school standard gtk menus and does
<didrocks> ahah
<didrocks> yes! good catch :)
<seb128> so I don't think being clever works
<seb128> also bundling light-themes sucks, it makes everyone get a gtk2 stack
<didrocks> but GTK_MODULES= is exported, right?
<didrocks> ah no
<didrocks> because we fallback to gtk2
<didrocks> because of this files
<seb128> yes
<didrocks> yeah, there is no other way than bundling until we have an interface though, right?
<seb128> well, we could have the desktop/gtk getting the theme from bzr
<seb128> or something
<seb128> rather than installing the deb which install the gtk2 depends
<didrocks> we need the deps though?
<didrocks> like humanity-icon-theme,
<didrocks> ubuntu-mono
<seb128> we don't need gtk2-engine-murine though
<seb128> we could side package those
<didrocks> let's see if those won't pull gtk2
<didrocks> well, it's pulling gtk3
<didrocks> which means the other way around is sucky though
<didrocks> (adwaita-icon-theme)
<didrocks> light-themes needs the engine for gtk2, right?
<seb128> yes
<didrocks> we won't be able dh_scour or such, but I guess, until we have an interface, it's ok
<didrocks> I wonder if we should take the pain to build it from source
<didrocks> (for gtk3)
<didrocks> gtk2 will pull gtk3 anyway, so meh
<didrocks> (through the icon themes)
<didrocks> seb128: what do you think is the best?
<didrocks> I guess that prooves we need to be imperative at build time at least
<didrocks> (and I can change that)
<didrocks> then, for the snap size, I'm unsure (there are other things to fix as well, but in general)
<seb128> didrocks, we have different issues there
<seb128> - the gtk version autodetect is flacky
<seb128> - we pull in too much
<didrocks> yeah, we need to fix #1
<didrocks> and I can
<seb128> how?
<didrocks> for #2, it's a bigger issue
<seb128> just be declarative?
<didrocks> having the makefile taking an arg
<seb128> k
<seb128> let's do that
<didrocks> and so, transparent for the user
<didrocks> yeah
<seb128> if you use /gtk3 then build with that
<didrocks> yep
<seb128> #2 as different possible fixes
<didrocks> right
<didrocks> let's focus on #1
<seb128> k
<didrocks> I have a doctor appointment, but as they are late, I'm bringing my laptop with 3G, will probably work from there
<didrocks> but I'll ping you once I pushed the fixes
<seb128> for #2 we can probably just checkout the theme from bzr and copy it to the right location
<seb128> k
<seb128> thanks
<didrocks> (just maybe I won't test it under 3G, so waiting to go back ;))
<didrocks> seb128: yeah, it will still means that gtk2 apps brings gtk3
<seb128> because of adwaita?
<seb128> but yeah
<seb128> optimization are for later
<seb128> or for shared vendor snaps
<didrocks> yep
<didrocks> because of humanity-icon-theme
<seb128> we might want to fix the theme
<seb128> I don't think adwaita needs to depends on gtk
<seb128> is snapcraft taking recommends?
<didrocks> good question, I never looked closely
 * ogra_ hopes not
<didrocks> using apt-cache
<didrocks>                 self.apt_cache[name].mark_install()
<didrocks> so, following default on your machine
<didrocks> meaning, I guessâ¦ recommends
<didrocks> I don't see after a first quick look any override
<didrocks> oh sorry
<didrocks> there is
<didrocks>     apt.apt_pkg.config.set('Apt::Install-Recommends', 'False')
<didrocks> ok, so no recommends :)
<ogra_> phew
 * didrocks bbl
<seb128> didrocks, great!
<zyga> slangasek: hey
<zyga> slangasek: how can I offload mvo with debian/ubuntu uploads
<ogra_> OsError("XOpenIM failed")
<ogra_> seb128, ^^ do you perhaps have any wrapper setup  that could overcome this ?
<ogra_> (i have tried unsetting XMODIFIERS and forcing LC_CTYPE=C and even added ibus to stage-packages alrady)
<timothy> hi, is there any snap-confine developer here?
<kyrofa> timothy, you want zyga
<kyrofa> timothy, or jdstrand once he's in
<kyrofa> timothy, what's up?
<timothy> I'm creating the official packages of snappy for archlinux (by mainly porting the zyga one)
<kyrofa> timothy, wonderful!
<timothy> but there is a bug that prevent me to do that (https://github.com/snapcore/snap-confine/pull/69)
<timothy> actually I patch this on archlinux package
<timothy> :)
<timothy> just to let you know
<kyrofa> timothy, ah, thanks for the pointer!
<timothy> missing () so only last check is evaluated
<seb128> ogra_, no, when do you hit that one?
<ogra_> seb128, tryingto ackage the servo browser (rust based app)
<ogra_> *package
<seb128> hum, k, I don't know about that stack sorry
<kyrofa> timothy, indeed, I gave it a review
<kyrofa> timothy, but I'll let zyga give it a quick look at merge it
<kyrofa> s/at/and/
<dpm> didrocks, re: qt-launch -> desktop-launch \o/
<didrocks> dpm: working well for you? :-)
<dpm> didrocks, bad news is just that I probably won't be able to test it in my qt snap until next week. Not today or over the weekend :/
<didrocks> dpm: no worry! :)
<didrocks> that will let people getting allll the bugs :)
<didrocks> s/people/popey/
<dpm> didrocks, yeah, it was all planned :)
<didrocks> \o/
<popey> didrocks: trying your gtk2 desktop launcher... not working here. are you in a position to help?
<seb128> didrocks, you trolled popey and now he's making you pay back...
<popey> http://paste.ubuntu.com/18232902/ is my gtetrinet simple yaml, using your desktop/gtk2 launcher. The app launches, but there's a fair number of console errors, and the UI pops up some theme errors, despite it looking okay.
<popey>  ð
<didrocks> arghhhhh ;)
<popey> You're welcome!  ð
<popey> /snap/gtetrinet/x1/bin/desktop-launch: line 72: /snap/gtetrinet/x1/.flavor-select: No such file or directory
<didrocks> popey: errors are not something specifically launcher related
<popey> that kind of thing
<didrocks> popey: ah, you just got this one
<didrocks> yea, it's my current change and I got that
<popey> yay
<didrocks> I'm debugging this as we speak :)
<popey> good good
<didrocks> I think the issue is that the wiki isn't updated
<didrocks> well
<didrocks> the cronjob isn't update
<didrocks> but the source is
<didrocks> and so, it doesn't get the right parameter
<ogra_> didrocks, does any of yuor launcher have handling for input methods yet ?
<didrocks> (should be fixed by itself on next cronjob run)
<didrocks> but I'm checking
<didrocks> ogra_: yes
 * ogra_ tries to overcome OsError("XOpenIM failed") in one app 
<didrocks> popey: and found a snapcraft bug!
<didrocks> sergiusens: it seems you are not staging hidden files
<didrocks> when they are at the root
<didrocks> (of any part)
<ogra_> didrocks, whihc one ? i cant find any twiddling with XMODIFIERS or such in any of them
<didrocks> ogra_: just use one of the launcher
<didrocks> and see how it goes :)
<sergiusens> didrocks that is very much likely to be the case
<sergiusens> didrocks but iirc we os.walk
<ogra_> didrocks, nah, i dont want a full launcher, only the code for me five line wrapper :)
<didrocks> sergiusens: I can have a look, unbreaking menawhile
<didrocks> ogra_: ok, I will help you once I've fixed things and get my launcher working then :)
<didrocks> ogra_: but it's bad in term of maintainance and the idea is to have small launchers as well sharing code
 * sergiusens reads the backlog in the meantime
<ogra_> didrocks, the app uses raw XIM (its a rust based static binary that i can even launch fine from /sbap/<package>/current directly)
<sergiusens> didrocks btw in case you want to give a quick look https://github.com/snapcore/snapcraft/pull/620
<ogra_> didrocks, i dont want the extra 100MB :)
<ogra_> only the right vars to kill off XIM completely
<didrocks> ogra_: unsure then, contribute to the launcher with your minimal ones once you get something :p
<ogra_> i only see GTK_IMMODULES in your code ... which would mean that i would have to include gtk just for that
<ogra_> (the app doesnt use any toolkit)
<sergiusens> popey 2.13 fixes cleanbuild with remote parts
<popey> sergiusens: yay
<didrocks> sergiusens: how often is the importer ran?
<didrocks> sergiusens: been 20 minutes I pushed a change to my snapcraft.yaml
<didrocks> sergiusens: but snapcraft define desktop/gtk2 doesn't reflect it yet
<didrocks> popey: once "snapcraft define desktop/gtk2" shows     make-parameters: ["FLAVOR=gtk2"]
<didrocks> popey: you can snapcraft and it should work correctly
<didrocks> sergiusens: we have an issue due to this cronjob, like new code pushed, but definition not updated ^
<didrocks> and popey just experienced it :)
<didrocks> (that + the hidden file)
<didrocks> seb128: FYI, if you try to build any gtk2 apps for now ^
<didrocks> (the fallback is gtk3)
<seb128> didrocks, fallback you mean default?
 * sergiusens checks again to see if he is not on a #brexit eu vs uk channel
<popey> I love being on the edge of bugs :)
<popey>  ð
<timothy> is zyga working on snapd too?
<sergiusens> didrocks importer, every 10 minutes, but josepht has those numbers
<didrocks> sergiusens: hum, seems it doesn't work that way
<didrocks> josepht: mind having a look? ^
<didrocks> popey: sorry for thisâ¦
<sergiusens> didrocks maybe every hour, I get confused, but here's a little secret https://parts.snapcraft.io/v1/status
<popey> didrocks: it's all good.
<sergiusens> didrocks if you are in a hurry hurry, josepht can probably manually trigger
<didrocks> sergiusens: yeah, updating would be great! I am semi-afaid of premature optimization as here, the wiki page didn't change at all
<didrocks> (it's only the snapcraft.yaml that changed)
<didrocks> + the code ofc
<didrocks> sergiusens: ok, almost done, looking at your branch in a bit
<sergiusens> kyrofa are you around and about?
<kyrofa> sergiusens, yessir
<sergiusens> didrocks sure, my branch is WIP (missing one crucial thing)
<sergiusens> kyrofa the reason I sent an early draft of the branch was to discuss part.installdir and pkgconfig :-)
<didrocks> sergiusens: ah, mind repinging me for the final review if you prefer?
<didrocks> sergiusens: I want to check as well this hidden file staging issue meanwhile
<kyrofa> sergiusens, happy to!
<sergiusens> didrocks sure thing
<sergiusens> kyrofa wanna do a hangout?
<kyrofa> sergiusens, sure, standup url?
<sergiusens> kyrofa ea, give me a minute to brush my teath so you don't smell my bad breath :-P
<kyrofa> sergiusens, haha, yes please, ping me
<sergiusens> kyrofa done :-)
<kyrofa> sergiusens, I'll be right there, I may have had a genius breakthrough and want to test it real quick
<sergiusens> kyrofa k
<kyrofa> sergiusens, coming now
<timothy> hi zyga, I have a couple of push requests for you :P
<niemeyer> Who maintains ubottu?
<didrocks> sergiusens: josepht: I think the importer is broken, it did fetch but didn't reflect the new snapcraft.yaml changes
<didrocks> "snapcraft define desktop/gtk2"
<didrocks> sergiusens: josepht: this is the missing line: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml#L19
<didrocks> popey: FYI ^
<didrocks> thanks zyga for the merge :)
<didrocks> sergiusens: josepht: ok, another snapcraft update and it's in now
<didrocks> popey: you can play after your next snapcraft update ^ :)
<popey> now?
<popey>   make-parameters:
<popey>   - FLAVOR=gtk2
<popey> \o/
<popey> biab, need to get kids from school
<sergiusens> didrocks nice, I was hoping to see the original dual qt/gtk thing solve with build params
<sergiusens> didrocks might as well just offer one and use composition as well ;-)
<didrocks> sergiusens: composition? :)
<didrocks> (it's sourcing some common files)
<didrocks> to avoid too much duplication
<sergiusens> didrocks ignore the self promotion http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
<tyhicks> zyga: hi - the partial confinement branch goes against our previous decision to make confinement all or nothing since all the pieces of confinement depend on each other
<tyhicks> zyga: what was the reasoning for the change?
<kyrofa> sergiusens, can you explain all the checks here? https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources.py#L335
<zyga> tyhicks: that's not reverted in any way, snaps are still in devmode
<kyrofa> sergiusens, I know it's in order to re-pull when the pull failed, but why check to make sure the dir is empty etc.? Now that it's not a symlink, I think I might have to just blow it away. Do you see a downside there?
<zyga> tyhicks: this just lests us see if anything is missing in other distributions
<zyga> tyhicks: snaps still run as before
<zyga> tyhicks: (missing as in build dependencies)
<zyga> tyhicks: with .34 I'm pulling in libudev and libseccomp as build deps
<zyga> tyhicks: confinement is still controlled by snapd and no change was made there
<zyga> tyhicks: what I want to do is to ensure that all the distros have the right userspace parts
<zyga> tyhicks: and I *could* build a fully supported snap-confine
<didrocks> sergiusens: oh that (overriding some parts of the launcher), yeah, that's what decided me to have clean launchers that you can override and putting deps there :)
<didrocks> sergiusens: that's a nice feature!
<didrocks> sergiusens: btw, you lied to me
<zyga> tyhicks: eventually I want snap confine to look the same everywhere, with snapd knowing what to do based on system release and kernel
<didrocks> snapcraft doesn't use walk, but glob.glob() :)
<didrocks> that's why it doesn't like '*'
<sergiusens> didrocks oh, I said most likely, there's a mix of os.walk and glob
<didrocks> yep
<didrocks> trying to think of the best way
<tyhicks> zyga: got it - thanks for explaining it to me :)
<zyga> tyhicks: yep, thanks for being vigilant :)
<iliv> zyga, FYI if binaries are under prime/bin command: has to be bin/$YOURPROGRAM, not just command: $YOURPOGRAM as you said yesterday.
<zyga> iliv: hmm, maybe it was usr/bin, snapcraft does expand and search $PATH
<zyga> iliv: it doesn't hurt to spell out the full path
<zyga> iliv: but you can abbreviate in many cases
<iliv> not without changing something
<iliv> e.g. $PATH etc.
<niemeyer> sergiusens: ping
<zyga> iliv: if bin/ is not on path then I bet sergiusens can fix that
<sergiusens> niemeyer pong
<zyga> I mean this should work, it's probably a bug somewhere
<niemeyer> sergiusens: Heya
 * zyga hugs sergiusens 
<zyga> snapcraft rocks man :)
<niemeyer> sergiusens: Did you ever fix the QTCOMPOSE / Compose file thing on the Telegram snap?
<niemeyer> sergiusens: I'm still getting that warning and Ã£ doesn't work there
<iliv> also, I think app: definitions should support underscore symbol. I was trying to use pg_basebackup: as an app name and that lead to errors about incorrect YAML syntax
<sergiusens> niemeyer hmm, no; just noticing this as Ã¡ works fine
<niemeyer> It works here as well
<sergiusens> but Ã£ and others don't
<zyga> iliv: underscore is reserved, you can use it in the command section internally but on the outside it is not allowed
<iliv> seems harmless really
<iliv> but okay
<iliv> I guess there's a reason for this
<zyga> iliv: it was used as a field separator earlier
<zyga> iliv: I think it's good to be strict, we can allow it later but in the past there was a good reason to exclude it
<iliv> I see
<iliv> > hmm, maybe it was usr/bin // not sure if you're talking about your experience or my particular case... in my case all binaries are under prime/bin and snapd (or whatever the process is) never could find a daemon binary if appname: ismyapp. it has to be appname: bin/ismyapp.
<zyga> iliv: prime/bin is not in path
<zyga> iliv: if you install your apps so that they are under usr/bin or bin/ then it should work, if not, then you can just specify the path in the command, both should work okay
<iliv> but prime/ is a directory created by snapcraft. it holds bin/ usr/ include/ etc. the autotools (which is my part) installed everything in bin/.
<iliv> it seems like snapcraft is not aware of its own fs layout ?
<iliv> or I am terribly confused about how it all is supposed to work :)
<kyrofa> zyga, iliv indeed, snapcraft adds bin, usr/bin, etc. to the path
<tsimonq2> sergiusens: what unit tests need to be updated? it seems like none of what I've looked at used the contstructors you mentioned
<tsimonq2> sergiusens: (that are breaking)
<kyrofa> iliv, but you still need to declare runnable stuff in `apps`
<tsimonq2> sergiusens: and there's multiple different failures, I don't know which one you are talking about to update
<iliv> kyrofa, which I believe I did. I have apps: myapp: bin/myapp for every binary under prime/bin. yet what you and zyga seem to be saying is that apps: myapp: myapp should work too. if that's case, it doesn't appear to be the case.
<kyrofa> iliv, you're missing a `command` there somewhere
<zyga> iliv: you can think of the root of your snap as a little root filesystem
<kyrofa> iliv, can I see your yaml?
<zyga> iliv: there $SNAP/bin and $SNAP/usr/bin are on path
<iliv> oh sorry
<iliv> here's an example:
<iliv> apps:
<iliv>   clusterdb:
<iliv>        command: bin/clusterdb
<iliv> I have a dozen of these
<szszsz> hi! I would like to access to a device from within snap
<iliv> and strangely none are exposed to a system
<kyrofa> Yeah you should definitely be able to simply use `command: clusterdb` there
<szszsz> I got message from app armor: * use gadget hardware assign to access '/dev/bus/usb/003/046'
<szszsz> Where could I find more info about it?
<kyrofa> iliv, how are you trying to run that app, then?
<kyrofa> i.e. how do you know it's not in PATH?
<iliv> I assume that when an app is exposed I can just run clusterdb on my terminal
<iliv> $ clusterdb
<kyrofa> iliv, no, you need to prefix it with the snap name. <snapname>.<appname>
<iliv> oohhh
<iliv> interesting
<kyrofa> iliv, that prevents multiple snaps from declaring the same command and fighting with each other
<kyrofa> iliv, the only special case there is when appname == snapname, then you can just run <snapname>
<zyga> szszsz: hey
<zyga> szszsz: snappy applications run under confinement and by default they cannot poke at hardware
<zyga> szszsz: snaps can gain more permissions with interfaces
<zyga> szszsz: we have many interfaces for various things but obviously not everything is supported yet
<szszsz> zyga: I would need one for talking to usb devices
<zyga> szszsz: can you please report a bug on launchpad.net/snappy with the description of the problem and all the context (e.g. what kind of device it is)
<zyga> szszsz: I'm sure we can support it
<szszsz> zyga: ok!
<zyga> szszsz: if you know how please tag the issue with snapd-interfaces
<zyga> szszsz: you can run your snap if you install it in devmode
<zyga> szszsz: snap install --devmode your-snap.snap
<zyga> szszsz: that should log about various apparmor denials but should still let your application run
<zyga> szszsz: based on those logs and your bug description we should be able to create an interface for the thing you are trying to access
<didrocks> ogra_: you may have an answer for this one, btw? http://askubuntu.com/questions/792555/how-to-implement-or-call-up-bluetooth-in-snappy-ubuntu-of-beaglebone-black
<szszsz> zyga: I will attach them then
<zyga> szszsz: since snapd is released every week you can use devmode for now but you should be able to use the new interface very soon
<zyga> szszsz: perfect, thank you :-)
<szszsz> zyga: wow, great! :]
<szszsz> zyga: thanks!
<slangasek> zyga: sorry, don't understand what you mean by offloading
<slangasek> zyga: are you asking what you need to do in order to take over the debian/ubuntu uploads, so mvo doesn't have to?
<arcade_droid> How do you do partial updates in a snap? Assume you have a game, one image file in the snap needs to be updated.
<arcade_droid> Because full re-download of a 8GB snap won't please any sane user.
<zyga> slangasek: offloading so he can focus on hacking more than on the release process
<zyga> arcade_droid: we don't have delta updates enabled yet but we are well aware of this
<sergiusens> tsimonq2 the general route to fix tests is to look at the traceback and got to the line it says it failed on that corresponds to the unit test file
<tsimonq2> sergiusens: which is what I've done
<zyga> arcade_droid: snaps should be very natural to do delta downloads and it will be added sometime later as a feature that is transparent to all users
<arcade_droid> zyga, so this is a planned feature of snaps to do partial updates?
<tsimonq2> sergiusens: but I'm not finding the problem
<zyga> arcade_droid: very much so
<sergiusens> tsimonq2 I havne't looked in detail, but since you added a param to the constructors I bet some of these None values are related to that
<tsimonq2> sergiusens: I'll double-check everything, thanks for clarifying
<slangasek> zyga: well, mvo isn't doing the Debian uploads, so no need to offload from him on that.  For Ubuntu uploads, that's not a quick or easy thing to take over if you aren't already a core-dev; but maybe it makes sense for you to take over driving the SRUs / proposed-migration propagation?
<slangasek> zyga: (currently, yakkety hasn't had any version of snapd newer than 2.0.2, because there have been autopkgtest failures that no one has had time to investigate/resolve...)
<zyga> slangasek: anything that helps is useful
<zyga> slangasek: how can I iterate on that? I can run yakkety, run autopkgtests there, how can I upload new versions of snapd to yakkety?
<slangasek> zyga: I believe shepherding the packages through queues is the easy win.  For getting new versions into yakkety, you could give me packages to sponsor uploads of?
<zyga> slangasek: so I prepare the package, ping you and you do the upload?
<kyrofa> tsimonq2, are you running those tests locally?
<slangasek> zyga: yes.  For snapd, I would certainly want your changes to be committed upstream first
<slangasek> zyga: since currently xenial+yakkety are "in sync"
<zyga> slangasek: yep
<zyga> slangasek: I'll see what is blocking current yakkety and I'll work on that next week
<zyga> slangasek: and eventually I could apply to be a core dev
<slangasek> zyga: cool, thanks!
<slangasek> zyga: yes :)
<tsimonq2> kyrofa: yep, same errors
<tsimonq2> kyrofa: I just pushed because I was stuck and needed help
<szszsz> I have one more question, if I may. I have published app but I cannot downloaded it through snap install nitrokey-app --channel beta . How to make it work?
<iliv> kyrofa, I see good to know. I have apparently larger problems as my snap package can't even be installed.
<kyrofa> tsimonq2, you see where you added source_checksum=None here? https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR101
<kyrofa> iliv, huh... what do you mean? What's happening?
<szszsz> I have checked all channels but with no luck. Checked channels in web gui and set all available, but have not helped
<didrocks> szszsz: is it confinment: strict or devmode?
<didrocks> confinement*
<kyrofa> tsimonq2, you switched the order here: https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR296
<kyrofa> So that's failing a lot
<maxiberta> hi, I have an issue with htop snap: it's being denied sending signals by apparmor (it's plugged into system-observe); any way to fix that?
<tsimonq2> kyrofa: heh what? the order matters? that's something I didn't consider for sure
<zyga> szszsz: not sure
<zyga> szszsz: maybe you have to login as yourself first
<kyrofa> tsimonq2, it does it you're not using variable=value
<tsimonq2> kyrofa: thanks, I'll play with it
<kyrofa> tsimonq2, so that's causing failures like "__init__() missing 1 required positional argument: 'source_dir'" for the tar source
<tsimonq2> oh okay
<tsimonq2> kyrofa: sorry for being a n00b :P
<kyrofa> tsimonq2, relax man, before snapcraft I didn't know python at all :)
<kyrofa> tsimonq2, you're in good company!
<tsimonq2> good to know :)
<kyrofa> sergiusens, elopio I need to take an extended lunch today, I may very well not make standup. I'll be working later this afternoon/evening
<tsimonq2> kyrofa: I guess that I'm saying is thanks, and sorry for (in my mind at least) not seeing the obvious
<szszsz> I
<tsimonq2> s/that/what/
<szszsz> I have used devmode for 0.1 and strict for 0.2. I was logged in during upload.
<kyrofa> tsimonq2, I just spent hours on what ended up being a one-liner. We all run into that type of thing! No apology necessary
<szszsz> 0.2 is now under review if I see correctly in web app.
<tsimonq2> alright kyrofa :)
<iliv> kyrofa, see this paste https://dpaste.de/UokM/raw. it includes my snapcraft.yml. So, clearly postgres is being run as root user and I'm wondering if we have any control over which user a service which is part of a snap can be run as?
<szszsz> but what about 0.1 and beta/edge channels? zyga didrocks ^^^
<didrocks> szszsz: did you see my question about confinement?
<kyrofa> iliv, ah!
<szszsz> didrocks: yes, I have responded earlier
<kyrofa> So it installs, but doesn't run :) . Does postgres have a --yes-i-know-what-im-doing flag?
<didrocks> szszsz: sorry, I did miss it :)
<didrocks> so yeah, devmode is private to you AFAIK
<kyrofa> iliv, other daemons are like that as well, php-fpm needs a special flag, apache needs special configs, etc
<didrocks> szszsz: did you use snap login as well?
<kyrofa> iliv, but every one I've done has given me ways around it
<kyrofa> iliv, services are always run as root-- no way around it
<szszsz> didrocks: yes, I have logged in
<didrocks> szszsz: I think you should have access once you are logged in snap (not snapcraft)
<didrocks> interesting, nessita may help you maybe? ^
<sergiusens> kyrofa no worries
<kyrofa> iliv, those daemons have those protections in place for good reasons, but those reasons are not valid within snaps
<szszsz> didrocks: why bother then setting edge/beta channels in app store?
<didrocks> szszsz: you can publish beta version (confined) that everyone can try :)
 * kyrofa -> lunch
 * zyga needs to buy a tshirt after unfortunate accident in the coffee shop, ttyl
<didrocks> szszsz: AFAIK, there will be a way for you soon to share your unconfined version with some people
<szszsz> didrocks: I will check login info once again in both snap and snapcraft
<didrocks> but it's not there yet
<didrocks> yeah, ensure you are logged in in "snap"
<szszsz> didrocks: I am trying too currently :]
<nessita> didrocks, sorry, what's the question (unclear from backlog)?
<szszsz> *to
<didrocks> nessita: szszsz says "I have published app but I cannot downloaded it through snap install nitrokey-app --channel beta . How to make it work"
<didrocks> nessita: "I have used devmode for 0.1 and strict for 0.2. I was logged in during upload."
<didrocks> that's the gist of it
<szszsz> didrocks: nice
<nessita> didrocks, let me check
<didrocks> szszsz: you are in good hands now :)
<szszsz> nessita: here is the url if it helps: https://myapps.developer.ubuntu.com/dev/click-apps/5313/rev/2/
<szszsz> didrocks: thx! :]
<nessita> szszsz, hi! so looking at your package in the store, what I see is: revno 1 (0.1) is published (green box) but revno 2 is not published (thumbs up)
<nessita> szszsz, so you have a few options:
<nessita> 1- to install the revno 1, devmode, you need to pass --devmode to snap install
<nessita> (plus the channel)
<nessita> snap install nitrokey-app --devmode --channel beta
<szszsz> nessita: I have published 0.1 in edge channel, shouldn't that work?
<didrocks> nessita: oh, the client already enforce the --devmode? nice! :)
<nessita> szszsz, if it's a devmode snap, you need to install it with --devmode, because the user needs to be aware some security checks are being bypassed
<nessita> szszsz, your revno 2 is not devmoe (yey!) but it not published, to publish it you need to visit https://myapps.developer.ubuntu.com/dev/click-apps/5313/rev/2/ and click publish at the bottom
<nessita> (we are working to make this screen a bit more user friendly)
<didrocks> nessita: maybe the issue is in the client side return message? (not clear enough it exists, but in devmode)
<didrocks> error: cannot perform the following tasks:
<didrocks> - Download snap "nitrokey-app" from channel "beta" (snap not found)
<didrocks> yeah, it's not really clear
<nessita> didrocks, what version of snapd are you running?
<didrocks> nessita: 2.0.9
<szszsz> nessita: woah, haven't seen that one, just clicked
<nessita> szszsz, so now, since your revno 2 is in stable, you could do: snap find nitrokey-app
<nessita> nessita@miro:~$ snap find nitrokey-app
<nessita> nitrokey-app             0.2                     nitrokey              -      Nitrokey Application
<nessita> (among other results)
<nessita> szszsz, your devmode revision will never appear in searches
<nessita> didrocks, could you ping Chipaca about that? it should work (snap install nitrokey-app --devmode --channel beta)
<szszsz> nessita: thanks, it started working just now
<didrocks> sure
<didrocks> even with 0.2 published now?
<didrocks> (maybe it wasn't published in the beta channel)
<nessita> didrocks, it was, revno 1 was in beta and edge
<didrocks> ok, and 2 isn't? only stable?
<didrocks> as I guess otherwise, it will take rev 2 now
<nessita> didrocks, 2 is in stable, candidate and beta
<didrocks> ah, so can't be reproduced for now
<nessita> didrocks, perhaps with edge:
<nessita> snap install nitrokey-app --devmode --channel edge
<didrocks> yeah
<sergiusens> kyrofa didrocks sans tests, this is good for a review https://github.com/snapcore/snapcraft/pull/620/files
<sergiusens> just sending out now as you are EODing or having a long lunch ;-)
<szszsz> nessita: didrocks rev 2 is all but edge, 0.1 is only edge
<didrocks> sergiusens: sureeeeeeeee, I see your strats :)
<didrocks> sergiusens: do you really want a review now? I was really going to EOD :p
<didrocks> or Monday is ok?
<szszsz> nessita: didrocks well, it is working now, thank you!
<didrocks> nice! :)
<sergiusens> didrocks just an overpass, if not, don't worry, it is what we discussed
<didrocks> sure, can do an overpass
 * sergiusens goes and writes unit tests
<maxiberta> hi all, need some help with apparmor
<maxiberta> apparmor is preventing htop from sending signals to other processes
<didrocks> sergiusens: ok, really did a quick overpass, functionnally-wise, it's great! I didn't spot any issue. Just some comments on some style nitpicking!
<tyhicks> maxiberta: hi - that's by design
<tyhicks> maxiberta: if a process can send another process signals, it can do nasty things like kill another snap's processes
<maxiberta> tyhicks: yep, I get it but... even with system-observe?
<tyhicks> oh
<tyhicks> let me take a look at the system-observe policy
<tyhicks> maxiberta: do you have any apparmor denials in the logs?
<maxiberta> tyhicks: apparmor="DENIED" operation="signal" profile="snap.htop.htop" pid=19011 comm="htop" requested_mask="send" denied_mask="send" signal=term peer="unconfined"
<tyhicks> maxiberta: sending SIGTERM to another process doesn't really fit into system-observe which is defined as, "Can query system status information."
<tyhicks> maxiberta: when you're sending SIGTERM out, you're actively managing the system at that point
<iliv> kyrofa, I see, so overall it's generally safe to run a service as root as long as it is confined. I'm also wondering what happens when we punch holes in the security confinement with plugs. For example, network. I realize this is a very generalized question but how secure is this model? If a ...
<iliv> ... program is running as root and it is confined but we then let it interface (I think would be the word) with unconfined system resources do any of the risks that are typical to a normal system apply to a snap package? At least within the boundaries of the type of plug being used?
<maxiberta> tyhicks: sure, but that's breaking htop's functionality
<tyhicks> maxiberta: perhaps you need a new interface to be defined for what you need
<popey> didrocks: so now I'm getting a dialog in gtetrinet which says "Warning: Theme does not have a name, reverting to default" ð
<ogra_> didrocks, sorry, havent touched beaglebone since we dropped it from our default supported arches
<maxiberta> tyhicks: that'd be good
<popey> didrocks: I suspect it requires some massage to make it look i different directories
<didrocks> popey: you knew I was just typing /quit in my weechat window, didn't you? :p
<popey> hahah
<didrocks> popey: yeah, would be interested
<popey> sorry, see you monday
<didrocks> popey: looking on Monday?
<popey> ya
<didrocks> yeah ;)
<popey> o/
<didrocks> we can have some debug sessions then!
<didrocks> see you guys & popey ;)
<maxiberta> tyhicks: should I report a bug?
<tyhicks> maxiberta: can you file a request at https://bugs.launchpad.net/ubuntu/+source/snapd/+filebug and add the "snapd-interface" tag?
<maxiberta> tyhicks: sure, thanks!
<tyhicks> maxiberta: thank you :)
<timothy> who can change something on http://snapcraft.io/ website?
<tsimonq2> timothy: it's a GitHub repo somewhere
<maxiberta> tyhicks: done, thanks
<tsimonq2> kyrofa: for when you come back, I can fix TypeError: join() argument must be str or bytes, not 'NoneType' by doing a sed of s/source_checksum=None/source_checksum/ but that adds a lot of new errors about missing arguments
<tsimonq2> kyrofa: I'm hesitating to commit and push because maybe it's associated with the lack of "=None"
<tsimonq2> kyrofa: the new result of `./runtests unit`: http://paste.ubuntu.com/18244502/
<tsimonq2> kyrofa: what's also puzzling me is failures like this: https://travis-ci.org/snapcore/snapcraft/jobs/141462851#L2066
<ogra_> nessita, oh, is --channel supposed to work now ? still doesnt for my giter app
<ogra_> *gitter
<ogra_> ogra@styx:~/Devel/packages/snaps/servo$ sudo snap install gitter --devmode --channel edge
<ogra_> error: cannot perform the following tasks:
<ogra_> - Download snap "gitter" from channel "edge" (snap not found)
<ogra_> that is ... https://myapps.developer.ubuntu.com/dev/click-apps/5257
<ogra_> (same error for beta)
<nessita> ogra_, well, in theory the spec requires that snap install uses --edge
<nessita> ogra_, so the specific response should come from Chipaca/pedronis
<ogra_> uh, we dont default to stable ?
<nessita> ogra_, I think we do
<ogra_> nessita, your comment sounded different
<ogra_> "the spec requires that snap install uses --edge"
<ogra_> i thought you meant in general
<nessita> ogra_, ah, I was talking about the format of the command line
<ogra_> ah
<ogra_> well using --edge gets me an error
<nessita> when passing a channel, it should be --channel=name but --name
<nessita> ogra_, rigth, that was in progress last time I asked
<ogra_> the error when using --channel edge indicates it actually looked in the edge channel though
<ogra_> ogra@styx:~/Devel/packages/snaps/servo$ sudo snap install gitter --devmode --channel=edge
<ogra_> error: cannot perform the following tasks:
<ogra_> - Download snap "gitter" from channel "edge" (snap not found)
<timothy> sudo is not necessary if you are in sudo, wheel or adm group :)
<ogra_> timothy, only if you use an U1 login
<ogra_> (which i dont want on this machine)
<timothy> [maybe-OT] snapd package moved to official community repository on archlinux
<ogra_> nice !
<ogra_> totally not OT !
<ogra_> nessita, well, in any case, the gitter snap is in the store in edge and beta ... shouldnt i be able to install it ?
<nessita> ogra_, let me check
<ogra_> https://myapps.developer.ubuntu.com/dev/click-apps/5257/rev/1/
<nessita> ogra_, what exact command are you running?
<ogra_> see above :)
<ogra_> sudo snap install gitter --devmode --channel=edge
<ogra_> i also tried with gitter.ogra
<ogra_> and with --channel=beta
<nessita> ogra_, let me check the fine details
<nessita> ogra_, short answer is yes, you should, now let me debug if this is an store issue or snapd issue
<nessita> ogra_, what version of snapd are you using?
<ogra_> i upgraded it today ... one sec
<ogra_> ah, no, that was snapcraft ... snapd is 2.0.9 still
<nessita> ogra_, is that latest?
<ogra_> seems a newer one is in -proposed, let me grab that one
<ogra_> nessita, ok, fasle alarm ... works with 2.0.10
<ogra_> sorry for the noise
<nessita> ogra_, oh, but that is not released yet?
<ogra_> it is sitting in -proposed ... waiting for th SRU process
<nessita> ah...
<ogra_> i just grabbed it from there
<nessita> ogra_, so well, yeah, latest snappy honors --devmode
<nessita> but pervious don't
<nessita> previous*
<ogra_> yeah
<ogra_> finally i can advertise my snaps :)
<niemeyer> mup: You ok there?
<mup> niemeyer: In-com-pre-hen-si-ble-ness.
<niemeyer> Good
<ogra_> bug #1
<ogra_> bug 12345
<ogra_> niemeyer, no bugs yet ?
<niemeyer> ogra_: Sorry, involved on a snap find-related discussion.. will finish the set up
<ogra_> yeah, no hurry, i thought it was a default feature :)
<niemeyer> bug #1
<niemeyer> Did I do something wrong
<niemeyer> ?
<niemeyer> mup: bug #1
<mup> niemeyer: Bug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <package-qa-testing> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Confirmed for
<mup> ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by
<mup> shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Wine:Unknown> <Ubuntu:Fix Released by sabdfl> <Arch Linux:Confirmed> <Baltix:Confirmed> <Debian:In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1>
<niemeyer> bug #123456
<ogra_> lol, you killed ubot9
<niemeyer> :)
<niemeyer> Hmm.. it should it be overhearing conversations as well about bugs.. #123456
<niemeyer> bug #123456
<niemeyer> Ah, got it..
<niemeyer> bug #123456
<niemeyer> bug #123456
<mup> Bug #123456: podcast crashes amarok <Amarok:Invalid> <xine-lib (Ubuntu):Fix Released> <https://launchpad.net/bugs/123456>
<niemeyer> There you go..
<ogra_> \o/
<niemeyer> Now let's get the new bugs reported here too..
<niemeyer> Done
<niemeyer> Okay, next.. GH issues and PRs
<niemeyer> But must move the server first..
<mup> Bug #1598266 opened: Cannot read/write to usb device [libusb][hidapi] <snapd-interfaces> <Snappy:New> <https://launchpad.net/bugs/1598266>
<sergiusens> mhall119 hey, now I see you :-) Mind trying https://github.com/snapcore/snapcraft/pull/620 with pantheon?
<sergiusens> mhall119 I can help you out running from source if you need to
<saalen> how to define environment variables in the application start wrapper script created by snapcraft?
<mhall119> sergiusens: I'll try, I have no internet access tody though, outside my phone
<jrwren> can I make a snap not depend on ubuntu-core?
<mhall119> sergiusens: I'll try that once my home network is coneccted to the internet again
<niemeyer> mup: Are you still ok?
<mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
<niemeyer> mup is now living its life inside a snap..
<mhall119> that's cool, but it sounds a little sheltered :)
<niemeyer> mhall119: In which sense?
<niemeyer> issue snapd#1124
<mup> PR snapd#1124: integration-tests: add coverage flags to snapd.service ExecStart setting when building from branch <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1124>
<kyrofa> elopio, sergiusens I give you: https://github.com/snapcore/snapcraft/pull/622
<mup> PR snapcraft#622: Hard-link local sources instead of symlinking them <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/622>
<kyrofa> Whoa, thanks mup!
<kyrofa> Haha, niemeyer I should have seen what you just did
<kyrofa> niemeyer, so is # -> LP, <something># -> github?
<kyrofa> Does LP require "bug" and github require "issue" ?
<sergiusens> elopio so, I just found an issue ;-)
<sergiusens> elopio so https://github.com/snapcore/snapcraft/pull/623 will pass unit tests, but there is overmocking in test_commands_register
<mup> PR snapcraft#623: Proper message when registering an already registered snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/623>
<sergiusens> elopio https://github.com/snapcore/snapcraft/blob/23732a5db53b3f1caf14d10845b2cec518530c9e/snapcraft/tests/test_commands_register.py#L52
<kyrofa> sergiusens, any idea why this line https://github.com/snapcore/snapcraft/blob/master/integration_tests/test_store_download.py#L40 is checking to make sure the OS snap is in the project dir instead of parts/<name>/src ?
<kyrofa> sergiusens, does it actually need to be in the project dir?
<sergiusens> kyrofa probably better lived in src
<kyrofa> sergiusens, good deal
<mup> Bug #1598304 opened: systemd services created by snappy breaks etckeeper <Snappy:New> <https://launchpad.net/bugs/1598304>
<sergiusens> kyrofa btw have you checked https://github.com/snapcore/snapcraft/pull/620 again?
<mup> PR snapcraft#620: Alter prefix for pkg-config to get correct values <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/620>
<kyrofa> sergiusens, ah, doing now, sorry
<sergiusens> kyrofa I consider it complete ;-)
<tsimonq2> o/ kyrofa
<kyrofa> Hey there tsimonq2 :)
<tsimonq2> kyrofa: you see the stuff I pinged you about earlier? :)
<kyrofa> tsimonq2, yeah, give me just a minute and I'd be happy to chat :)
<tsimonq2> alright thanks kyrofa :)
<kyrofa> Okay tsimonq2, I'm all yours. Let me re-read what you said
<tsimonq2> \o/
<kyrofa> tsimonq2, I'll just pull your branch and see where it is, okay? That way we don't need to refer to travis
<tsimonq2> alright cool :)
<kyrofa> tsimonq2, alright, first error:
<kyrofa> tsimonq2, snapcraft.tests.test_base_plugin.GetSourceTestCase.test_get_source_with_branch_must_raise_error
<kyrofa> tsimonq2, you can run just that test with: python3 -m unittest snapcraft.tests.test_base_plugin.GetSourceTestCase.test_get_source_with_branch_must_raise_error
<tsimonq2> oh that's convenient
<kyrofa> tsimonq2, indeed, focus on one at a time
<tsimonq2> alright
<kyrofa> This one should be relatively straightforward
<tsimonq2> so it lists 3 things
<tsimonq2> an error and 2 fails
<tsimonq2> the fails are common so I might as well see if I can knock that out, unless you disagree
<niemeyer> kyrofa: They don't require it.. LP will only "overhear" bugs with 5 digits or more
<kyrofa> tsimonq2, indeed, I agree
<niemeyer> kyrofa: So, #123456, but not #123
<mup> Bug #123456: podcast crashes amarok <Amarok:Invalid> <xine-lib (Ubuntu):Fix Released> <https://launchpad.net/bugs/123456>
<kyrofa> niemeyer, ah, okay good to know!
<niemeyer> kyrofa: For this channel, I've limited the GH plugin to require the repository prefix, and default to the snapcore organization
<kyrofa> tsimonq2, note that these are all the same test, just different test data
<tsimonq2> yep I figured that out kyrofa
<kyrofa> niemeyer, how would we do a different org?
<niemeyer> kyrofa: snapcore/snapcraft#123
<mup> PR snapcraft#123: Added an argument to filter examples tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/123>
<kyrofa> niemeyer, just like github org/proj#num
<kyrofa> Ah
<niemeyer> Yeah
<kyrofa> niemeyer, excellent, I've wanted that for a while now thank you!
<tsimonq2> kyrofa: so it looks like the mismatch is that raised.exception isn't equal to the appropriate string
<kyrofa> tsimonq2, indeed, you added some new validation checks there
<kyrofa> tsimonq2, which means the test data also needs to be updated
<kyrofa> tsimonq2, and add some cases to catch your new option
<tsimonq2> oh okay I get it
<tsimonq2> let me play with that in the GetSourceTestCase function
<kyrofa> tsimonq2, yeah do that. Go through the failures one by one, running them individually like I showed you. You should find them all similarly trivial
<tsimonq2> alright
<tsimonq2> kyrofa: so I've had some luck, thank you! :D
<tsimonq2> but
<tsimonq2> it's failing on something that should be trivial to fix
<tsimonq2> AssertionError: "can't specify source-checksum for a bzr source" != "can't specify a source-checksum for a bzr source"
<kyrofa> tsimonq2, one error message has an "a" in it, the other doesn't?
<tsimonq2> yep
<tsimonq2> that's it
<tsimonq2> ahhh
<tsimonq2> figured it out
<tsimonq2> all solved \o/
<tsimonq2> I'll run ./runtests unit to pick out more to solve
<tsimonq2> thanks for getting me started kyrofa
<kyrofa> tsimonq2, no problem! Best of luck :)
<niemeyer> kyrofa: np!
<tsimonq2> that feeling when a one line fix reduces the failing unit tests from 33 to 9! \o/
<niemeyer> and that completes the mup hackery of the day.. probably..
<niemeyer> mup: infer day of the week
<mup> niemeyer: Friday.
<niemeyer> Exactly.. and dinner time too
<niemeyer> mup: infer dinner time
<mup> niemeyer: Basic information: composer Busta Rhymes.
<niemeyer> What? LOL
<niemeyer> mup: infer -all dinner time
<mup> niemeyer: Basic information: composer Busta Rhymes â Recordings: album music act release date, Street Hop Royce da 5â²9â³ Tuesday, October 20, 2009.
<tsimonq2>  
<niemeyer> Okay.. enough playing, sorry. :)
<tsimonq2> kyrofa: you still around? I think the last 9 failing might have a common cause, I pushed the changes I made, mind pointing me in the right direction?
 * tsimonq2 adds unit tests for source-checksum, maybe that's the issue but we'll see
<tsimonq2> nope
<tsimonq2> well I'll play more tomorrow, I'm off for the day, o/
#snappy 2016-07-02
<zc456> Snapcraft doesn't seem to recognize a jar built when using ant. I tested the built jar and it does work. http://i.imgur.com/1T5YUku.png
<zc456> Manfiest file https://github.com/tpaw/snap-repository/blob/master/third-party/micropolis-tpaw/snapcraft.yaml
<teej> Hello.
<teej> I see that snap can be used for all sorts of packages. Does this mean snap has the ability to eventually replace apt/apt-get/aptitude?
<niemeyer> teej: Hey
<niemeyer> teej: This is not a short or medium term goal, at least
<tsimonq2> teej: snaps are NOT meant to replace apt (the project name :P) or any other packaging system
<szszsz> hi! I wanted to establish one thing: should snappy be used with sudo or not?
<szszsz> Some guides uses sudo, official on snapcraft says snap login
<tsimonq2> szszsz: snapcraft no, snappy (which has been replaced with the snap command) most of the time yes
<szszsz> tsimonq2: I meant snap command, which is described on snapcraft main page. I have an impressions there is a difference since commands are not in user path after installing with sudo
<szszsz> or am I wrong?
<szszsz> ok, I am withdrawing this. With sudo I have access to installed command within the path
<szszsz> One more question: is there a possibility that snap could install shortcuts to unity launcher?
<tsimonq2> can you clarify?
<tsimonq2> like, you have the ability to launch it from Unity?
<szszsz> I would like to have it
<szszsz> I have a QT application so running it from terminal does not seem right
<tsimonq2> yeah I think that should already be a thing, I'm not 100% sure, I don't use Unity ;)
<tsimonq2> Alt + F2 ? :)
<szszsz> agreed, that works :]
<szszsz> but it would be better to have nice shortcut with beatiful icon
<szszsz> I have seen a plug named unity, I will check there
<szszsz> Well, I will have to request a new plug for desktop and unity shortcuts if I this right
<juanrubio_at_tiz> quit
<szszsz> https://developer.ubuntu.com/en/snappy/guides/interfaces/
<tsimonq2> szszsz: we have a unity7 pluh
<tsimonq2> *plug
<szszsz> that's right, but I do not know how could I write to shortcuts directory, namely /usr/share/applications/ or ~/.local/share/applications/
<szszsz> As for the latter, I could probably use home plug
<szszsz> I will check it then and return someday in case it would not work
<szszsz> tsimonq2: thanks!
<szszsz> details taken from here: https://help.ubuntu.com/community/UnityLaunchersAndDesktopFiles
<popey> szszsz: yes, we already support .desktop files
<popey> szszsz: just put the icon and desktop file in ~/setup/gui
<popey> sorry, in ./setup/gui - under where the snapcraft yaml is located
<popey> szszsz: e.g. https://github.com/ubuntu/snappy-playpen/tree/master/shotwell
<juanrubio_at_tiz> Hi, I'm trying to create a snap package for my project (https://github.com/tizonia/tizonia-openmax-il), and I'm finding an error when a dependency's setup.py is being run. This dependency (pycryptodome) is expecting a 'build' folder, which does not get created when everything under snapcraft...
<juanrubio_at_tiz> I believe this could be seen as a bug in pycryptodome, and I've raised and issue there (https://github.com/Legrandin/pycryptodome/issues/22)...I'm wondering if there is way to workaround this in my snapcraft.yaml
<iliv> anybody's online? :)
<popey> juanrubio_at_tiz: iliv it's often quiet around here at weekends, sorry
<juanrubio_at_tiz> popey: no worries. I've raised a ticket in launchpad https://bugs.launchpad.net/snapcraft/+bug/1598396
<mup> Bug #1598396: python2 plugin: no 'build' directory found by setup.py under distribution root <Snapcraft:New> <https://launchpad.net/bugs/1598396>
<bull> hey snappers :)
<bull> any luck making snap for this app ?? https://github.com/keshavbhatt/Deskie
<iliv> hey guys
<iliv> I would appreciate it if somebody could look into these questions and answered them on AskUbuntu (so that other people could benefit from seeing your answers):
<iliv> * https://askubuntu.com/questions/794002/user-editable-system-wide-configuration-files-in-snap-packages
<iliv> * https://askubuntu.com/questions/794008/what-is-post-install-equivalent-in-snap-packages
<iliv> * https://askubuntu.com/questions/794010/is-there-a-way-to-control-whether-daemon-should-be-started-on-snap-install-comma
<iliv> there you go
<iliv> 3 questions
<KNRO> Hello, I am trying to make a snap package for my app, but couldn't figure out how to use breeze icon theme
<KNRO> I modified qt5-launch to have export Qt_QPA_PLATFORMTHEME=kde
<MichaelTunnell> Does anyone have a link to the documentation explaining "all-snap" I found the doc for the Transactional A/B which discusses all-snap here https://github.com/snapcore/snapd/blob/master/docs/system-updates.md
<MichaelTunnell> I previously found a github issue on the topic explaining it but that issue has since been deleted so the details are gone
<MichaelTunnell> mostly my question is: does all-snap keep the transactional updates in some way to facilitate the snap rollbacks?
#snappy 2016-07-03
<MichaelTunnell> anyone?
<bull> any luck making snap for this app ?? https://github.com/keshavbhatt/Deskie
<bull> mhall119, any luck making snap for this app ?? https://github.com/keshavbhatt/Deskie  ???
<niemeyer> MichaelTunnell: Not exactly sure of what you mean, but it does keep track records around for exactly what is being done, and also data and old snaps to make the rollback possible
<niemeyer> bull: Someone would have to try.. :)
<bull> niemeyer,  yeah i tried but app wont run after installing it
<niemeyer> bull: Did you try installing with --devmode?
<bull> yeah it failed with unexpected output
<niemeyer> Ok, so it's indeed best for someone that knows more about the details of both the app and snaps to have a look
<bull> niemeyer,  yes
<ogra_> GRR ..
<ogra_> Parts 'copy' and 'sqlite' have the following file paths in common
<ogra_> which have different contents: usr/lib/x86_64-linux-
<ogra_> gnu/libsqlite3.so.0.8.6
<ogra_> yes you silly thing ... that is in fact the reason why i *have* an sqlite part ... i want to replace the existing lib and binary ...
 * ogra_ shakes fist at snapcraft
<niemeyer> ogra_: Just black list with stage: [-filepath]
<ogra_> oh !
<ogra_> niemeyer, thanks a lot !
<niemeyer> ogra_: np
<MichaelTunnell> niemeyer: I pretty much wanted to know if snaps still support incremental updates so that only what is needed is updated rather than the entire snap and if rollbacks are possible still. You answered the rollback thing so great but how about the incremental updates?
<ogra_> hmpf
<ogra_> Jul  3 17:46:41 styx kernel: [265956.819310] SQUASHFS error: xz decompression failed, data probably corrupt
<ogra_> Jul  3 17:46:41 styx kernel: [265956.819315] SQUASHFS error: squashfs_read_data failed to read block 0x1e0ecd6
<ogra_> Jul  3 17:46:41 styx kernel: [265956.825969] SQUASHFS error: xz decompression failed, data probably corrupt
<ogra_> Jul  3 17:46:41 styx kernel: [265956.825974] SQUASHFS error: squashfs_read_data failed to read block 0x1e0ecd6
 * ogra_ tries a reboot 
<niemeyer> @MichaelTunnell: Incremental updates are coming soon as well.. you'll hear about the feature after the term "deltas"
<nothal> niemeyer: No such command!
<pachulo> hi all! Was trying to create a MAME snap using the "make" plugin, but as it seems that there is no "install" target in the MAME Makefile it fails to build because the snapcraft make plugin tries to install it
<pachulo> should an option be created to tell the make snapcraft plugin not to try to execute the "install" target?
<MichaelTunnell> niemeyer: I am making a video explaining snappy and I just wanted to cover that if it is a definite planned feature
<niemeyer> MichaelTunnell: Ah, yeah, definitely coming soon.. content sharing is also landing, btw.. should be available in the next couple of weeks
<niemeyer> That is, one snap being able to explicitly offer files for other snaps to explicitly use
<MichaelTunnell> niemeyer: interesting . . . so similar to shared libraries but shared snaps?
<MichaelTunnell> niemeyer: would it be content/userdata shared between snaps or shared assets?
<niemeyer> MichaelTunnell: Right, will be used to share libraries for sure, but the mechanism is generic for any sort of content
<MichaelTunnell> niemeyer: nice thanks
#snappy 2017-06-26
<waters33637_> how do i change the sshd port on snappy core?
<Vamsi> Hi, is it possible to write snaps in a language other than python? I mean already read a page where the snaps can be written in Go. But is it possible to write in other languages?
<kyrofa> Vamsi, oh certainly-- anything, really!
<kyrofa> Vamsi, snapcraft has a number of plugins included by default, including cmake, autotools, and yes, python, go, and so on
<kyrofa> Vamsi, run snapcraft list-plugins for more info
<Vamsi> kyrofa: Thank you very much.
<kyrofa> Vamsi, even if you want to do something that current plugins don't support, snapcraft supports using plugins in your actual tree as well. And you can always upstream them back to snapcraft, we're nice ;)
<Vamsi> kyrofa: That's awesome. Just another question. Is it possible to work with snapcraft on an IDE for noobs like me who find it easier to write code there? :|
<kyrofa> Vamsi, ugh, I lost my connection, sorry
<kyrofa> Vamsi, not sure if my previous messages got through
<kyrofa> <kyrofa> Vamsi, yes, although snapcraft is a bit of a meta build system, which doesn't make that fit quite perfect
<kyrofa> <kyrofa> i.e. your snap could be made up of multiple parts
<Vamsi> kyrofa: So when you say parts, does it mean that I develop it as a regular app on an IDE and then convert it to a snap?
<renat> Hi guys! It's Renat from Screenly.
<kyrofa> Hey renat, welcome!
<kyrofa> It's been a while!
<renat> Yup=)
<kyrofa> How have you been?
<renat> Fine, thanks=)
<renat> I have a question about timezone control snap=)
<renat> Hm. No. timezone control interface.
<renat> Is it possible to include timezone control interface fix to 2.26.4 release? I investigated the timezone_control.go file on GitHub, but the fix is still not released in 2.26.4=(
<renat> We need that fix desperately=)
<kyrofa> renat, does time-control cover that?
<renat> kyrofa, no, unfortunately.
<kyrofa> renat, we'll need to talk to zyga and/or jdstrand, then
<renat> kyrofa, thanks! I will write them, I think.
<kyrofa> Alright. jdstrand will probably be around in a few hours, too
<koza> ogra_, hey, fyi, fuses blown, can boot core now
<mup> PR snapd#3521 closed: snap-seccomp: make sure snap-seccomp writes the bpf file atomically <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3521>
<ogra_> kyrofa, https://forum.snapcraft.io/t/building-u-boot-gadget-snaps-a-series-of-blog-posts/821
<Ulf> Hey there
<mpt> Where should I report a bug on the results of âsnap findâ?
<mup> PR snapd#3526 opened: hooks: support for refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/3526>
<mup> PR snapd#3527 opened: hooks: support for revert hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/3527>
<xnox> How do i search for packages in the edge channel?
<xnox> e.g. $ snap find --edge hello does not work
<xnox> $ sudo snap find --edge hello
<xnox> error: unknown flag `edge'
<seb128> you don't
<mup> PR snapd#3507 closed: many: backport of seccomp-bpf branch (#3431) to the 2.26 release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3507>
<Chipaca> xnox: find explicitly only searches published, stable snaps
<kyrofa> pstolowski, done reviewing install/remove hooks, asked a few questions
<xnox> seb128, Chipaca: so how does one discover edge channel packages?!
<xnox> why does install accept --channel flag and find does not?
<pstolowski> kyrofa, thanks!
<kyrofa> xnox, by having admin store access and searching
<Chipaca> xnox: non-stable snaps, you learn about them from the developer directly (or word of mouth)
<xnox> o_O
<Chipaca> xnox: or, if you already know about a snap and would like to try its beta (or edge), snap info will tell you
<xnox> i find it weird, that i can call info on something, and install, which find does not find.
<Chipaca> xnox: I'm ok with you finding it weird
<Chipaca> xnox: :-D
<xnox> it feels like not having +r permission on ones home directory
<seb128> xnox, it's not only you don't worry :-)
<Chipaca> xnox: it's more like apt not telling you about things from debian experimental
<seb128> it does
<Chipaca> seb128: not unless you do a lot of work for it to do so
<seb128> if you added the corresponding source
<xnox> Chipaca, they are findable with apt search, but not installed by default with apt install unless e.g. /experimental is given.
<seb128> lot of work?
<Chipaca> when i did it last at least, yes
<xnox> Chipaca, e.g. on ubuntu backports are enabled by default; are searchable; do show up in the results; are not installed by default unless e.g. /xenial-backports is specified.
<xnox> Chipaca, and that seems normal to me. What was your bug with apt?
<seb128> xnox, that seems what one would expect as a behaviour :-)
<Chipaca> xnox: I never said I had a bug with apt?
<xnox> Chipaca, "xnox: it's more like apt not telling you about things from debian experimental" but it does...
<Chipaca> xnox: it doesn't unless you do more work, was more my point
<Chipaca> xnox: in any case I think you understand what I mean and are just being argumentative at this point
<Chipaca> if on the other hand you didn't understand what I meant, I'll try harder
<xnox> commented on https://bugs.launchpad.net/snappy/+bug/1662962 and marked myself as affected.
<mup> Bug #1662962: 'snap find' does not allow channel specification <Snappy:New> <https://launchpad.net/bugs/1662962>
<xnox> Chipaca, on ubuntu, with apt, we have repositories that can be enabled/disabled and can be installable by default, or not.
<Chipaca> xnox: yes, snapd does not support that
<Chipaca> xnox: i'd forgotten about that bug, where the current behaviour is explained or rationalised rather well
<xnox> Chipaca, on ubuntu we enable by default: security, updates, and backports. However, we by default only install from security and updates. backports are visible in ~= info / find, and work with install with extra flags.
<xnox> Very similar to snapd channels, which are possible to use with flags, for channels, for commands info/install, but not find.
<xnox> Chipaca, the last comment says that if there are more people affected the --channels/--beta/et.al. should be supported in the find command.
<xnox> (from mark that is)
<Chipaca> s/should/could/
<Chipaca> xnox: if you can "snap install --edge --devmode foo", would you expect "snap find --edge --devmode" to find foo?
<ogra_> slangasek, i noticed you started building daily ubuntu-core images on cdimage, i'd like to shut down my builds, but can you please fix the naming of the dargonboard ones ? theere are different versions of dragonboards and we only support the 410c, linaro/96boards asked me to make that clear in our images when i started building the ones in http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ ... would be great if the ones on
<ogra_> cdimage could use the same naming scheme
<xnox> Chipaca, yes. Not sure what "--devmode" does. For me there is a package one can install with --edge, and query with info, but not possible to "snap find --edge foo"
<Chipaca> xnox: devmode snaps are not confined
<xnox> because --channel= --beta --edge --candidate --stable flags do not exist on the find subcommand.
<xnox> Chipaca, ok so --devmode does not affect channel selection (e.g. devmode is not a subchannel of edge)
<xnox> so should be irrelevant here.
<Chipaca> xnox: as i see it, it hinges on that if the developer hasn't put it in stable, it means they don't think it's suitable for general use
<xnox> Chipaca, then why is there install --edge and why does info show it by default?
<xnox> Chipaca, imho all command should default to show info from stable channel only.
<xnox> And all commands should be able to show other channels. If there is need to operate on other channels for the `info` and `install` so should also `find`
<Chipaca> xnox: i think the difference is that find is about promoting/suggesting you use stuff, as opposed to info which is about telling you all we know about stuff
<xnox> Chipaca, please tell me this is not an ACL / security feature
<xnox> that one cannot "find" edge channel data....
<Chipaca> xnox: exactly how stupid do you think we are? :-/
<xnox> given lack of --channel= flag on find command, my bar is set low =))))))))))))))))
<Chipaca> xnox: so you disagree with some design decisions, you immediately assume we're incompetent?
<xnox> Chipaca, please note i'm fairly new to using snap on regular basis. I have built a snap, and do use it. But I'm fairly unfamiliar with all the ins and outs.
<xnox> Chipaca, artificially limiting user's ability to view _information_, imho, is censorship =) and nothing else. Especially since viewing the information should be harmless.
<xnox> I would understand ACLs were e.g. publisher alone can find packages, which are authenticated search results, before a package is made public.
<xnox> but not able to find packages, in all channels, is still perplexing to me.
<Chipaca> xnox: snap find --private is the only-find-private-packages bit
<kyrofa> xnox, I think the idea is that there could potentially be all sorts of crap in edge etc. that could be totally useless and not ready for use. Showing such results when searching for a snap to use could be considered noise
<Chipaca> xnox: and the lack of channel flags rationale is, I _think_ (but haven't checked) is from before sections support, so maybe it's time to rehash the discussion
<Chipaca> there _is_ all sorts of crap in edge
<Chipaca> :-)
<xnox> sure, there is crap, i'm not asking for it to be show by default
<kyrofa> Totally useless and not ready for use == my redundancy of the day
<kyrofa> Ah, right, you just want find --channel
<xnox> kyrofa, snap find crap -> should return nothing; snap find --edge crap => should return all the crap =)
<kyrofa> Sure, gotcha. I agree, that would be useful
<xnox> kyrofa, please mark yourself as affected on https://bugs.launchpad.net/snappy/+bug/1662962
<mup> Bug #1662962: 'snap find' does not allow channel specification <Snappy:New> <https://launchpad.net/bugs/1662962>
<kyrofa> I've embarrassingly forgotten the names of my own snaps in non-stable channels. Had to login to the dashboard to jog my memory
<Chipaca> kyrofa: snapcraft list-registered
<Chipaca> :-D
<kyrofa> Chipaca, you know about features in my own project that I didn't know about. This is a bad situation
<kyrofa> But that still seems like a workaround
<Chipaca> dude, i'm not the one that needs convincing
<kyrofa> Haha, I know!
<mup> PR snapd#3528 opened: Use RFC3339 time format for refresh times <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3528>
<mup> Bug #1651597 opened: no bug reporting method <Snappy:Confirmed> <https://launchpad.net/bugs/1651597>
<kyrofa> JamieBennett, https://forum.snapcraft.io/t/dropping-grade-from-the-template-produced-by-snapcraft-init/783 FYI
<Chipaca> Pharaoh_Atem: https://en.wikipedia.org/wiki/Rocca_Calascio
<cjwatson> mpt: https://bugs.launchpad.net/snapstore
<mup> Bug #1651597 changed: no bug reporting method <Snappy:Fix Released> <https://launchpad.net/bugs/1651597>
<mup> Bug #1700560 opened: âsnap findâ returns confusing results <Snappy:New> <Snap Store:New> <https://launchpad.net/bugs/1700560>
<Chipaca> I want to publicly thank kyrofa for offering to work without complaining on all the random snapcraft work we're throwing at him
 * Chipaca waits for kyrofa to follow his "always accept praise" rule
<kyrofa> Chipaca, haha, so far none of the tasks I've agreed to are assigned to me!
 * kyrofa accepts praise
<Chipaca> kyrofa: this can be fixed
<Chipaca> robert_ancell: should i be waiting for another commit on snapd#3528?
<mup> PR snapd#3528: Use RFC3339 time format for refresh times <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3528>
<robert_ancell> Chipaca, Was called into a discussion, still working on it
<Chipaca> robert_ancell: tsk tsk
<mup> PR snapd#3529 opened: interfaces: allow snaps to use the timedatectl utility  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3529>
<slangasek> ogra_: can you file a bug (or do a merge) against ubuntu-cdimage for the dragonboard rename so there's a paper trail?
<ogra_> slangasek, will do
<mup> PR snapd#3530 opened: cmd/snap: include snap type in notes <Created by chipaca> <https://github.com/snapcore/snapd/pull/3530>
<seb128> hum, my test vm crashed while I was installing libreoffice snap
<seb128> I rebooted and now it says "snap libreoffice has changes in progress"
<seb128> what does that mean and how can I get out of it?
<seb128> remove says it's not installed
<seb128> installed gives that message I don't understandf
<pstolowski> seb128, what does 'snap changes' say? try 'snap abort <changeid>; any errors reported by journalctl
<pstolowski> ?
<seb128> pstolowski, seems it's installed now
<seb128> so I guess it resumed installing it in bg
<seb128> and "changes in progress" is a way to say that which was just not undertandable to me
<kyrofa> seb128, welcome to transactional package operations!
<kyrofa> Not the not-understandable part, but the fact that it didn't end up in a weird state. Nice huh?
<seb128> yeah, would be nice if it as telling you what it's doing
<seb128> rather than throwing a weird error that make you want to nuke the install
<seb128> :-)
<seb128> I was close from trashing the vm and redoing a fresh ubuntu install
<seb128> since I had no clue how to get out of the situation
<pstolowski> perhaps the message should give a hint about 'snap changes'
<coreycb> hi all, the keystone snap was blocked on upload to the snap store due to an interface issue which i've since been able to drop. but i think it's still blocked.  can someone take a look?
<coreycb> also the nova snap appears to have the same issue.
<seb128> give an hint about snap changes would be one option
<seb128> another would be to explain what's going on
<seb128> like that it's being installed and that waiting is enough
<neozero> hi. first time snap user on Ubuntu 16.04. '$ sudo snap install wekan' went fine, but '$ wekan.help => cannot mount /snap/wekan/2/$SNAP_DATA/share at /snap/wekan/2/$SNAP_DATA/shared with options bind. errmsg: No such file or directory
<mup> PR snapd#3531 opened: interfaces: updates default, mir, optical-observe, system-observe, screen-inhibit-control and unity7 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3531>
<jdstrand> roadmr: hi! would you mind updating the tools to r887?
<jdstrand> ogra_: fyi, that has your new kernel and two gadgets ^ (prevous revisions had the other one)
<roadmr> jdstrand: sure thing, coming up
<neozero> anything I should be looking at for this simple case of Ubuntu 16.04 $ snap install wekan => $ wekan.help => cannot mount /snap/wekan/2/$SNAP_DATA/share at /snap/wekan/2/$SNAP_DATA/shared with options bind. errmsg: No such file or directory
<jdstrand> roadmr: thanks. I forgot to mention no rush
<roadmr> jdstrand: np, I'll need to hold the merge until tomorrow but should deploy shortly after
<roadmr> (but it's already prepared - just waiting for me to pull the trigger)
<jdstrand> roadmr: cool, thanks
#snappy 2017-06-27
<mup> PR snapd#3532 opened: Support snap title field (localized short name) <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3532>
<zyga> good morning
<mup> PR snapd#3529 closed: interfaces: allow snaps to use the timedatectl utility  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3529>
<mup> PR snapd#3533 opened: tests: extend find-private test to cover more cases <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3533>
<mup> PR snapcraft#1382 opened: rust: Make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>
<mup> PR snapd#3534 opened: tests: shellcheck improvements for tests/main tasks - first set of tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3534>
<ogra_> ppisati, https://bugs.launchpad.net/raspbian/+bug/1646961 ... that affects our raspi2 kernel too, perhaps we could ship the patch ?
<mup> Bug #1646961: brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code <Raspbian:New> <https://launchpad.net/bugs/1646961>
<ppisati> ogra_: i assigned it to me, i'll give it a look ASAP
 * ogra_ hugs ppisati 
<ogra_> mainly cosmetic ... (i dont think it has any technical influence)
<mup> PR snapcraft#1383 opened: autotools: Enable cross-compilation support <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1383>
<mvo> jdstrand: silly question, in artful for seccomp_get_syscall_from_name("socket") on i386 I get -101 which AIUI is a way by libseccomp to say "it's complicated". is there a way to get from there to the real syscall or is that the wrong way to get a systemcall number from a name
<mvo> jdstrand: nevermind, I think i figured it out, reading the libseccomp was instructive enough
<jdstrand> mvo: ah, good. is there a particular problem you are seeing?
<mvo> jdstrand: the problem is in 3535, I see a build failure in artful because in the tests I try to resolve a syscall by name and get a negative number
<mup> PR snapd#3535 opened: snap-seccomp: fix snap-seccomp tests in artful <Created by mvo5> <https://github.com/snapcore/snapd/pull/3535>
<jdstrand> mvo: oh, wow. I think socket will be the only one of these that are weird and I suspect it is related to socketcall
<mup> PR snapcraft#1384 opened: Support yaml merge tags <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1384>
<mvo> jdstrand: exactly, it is socket/socketcall when the bpf is generated
<jdstrand> mvo: ok 'cool'. yeah, that is the only syscall I've seen that is weird like that
<Chipaca> jdstrand: HELLO
<jdstrand> Chipaca: hi!
<Chipaca> jdstrand: :-)
<mup> PR snapcraft#1335 closed: errors: Descriptive error message for bad parts named with uppercase â¦ <Created by EduardoVega> <Closed by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1335>
<mup> PR snapd#3528 closed: Use RFC3339 time format for refresh times <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3528>
<cachio> niemeyer, 2017-06-27 09:59:37 Cannot allocate linode:ubuntu-16.04-64: cannot boot linode:ubuntu-16.04-64 (Spread-60): linode disk /dev/sda not ready to boot. Please contact support.
<cachio> niemeyer, this is happening today in linode
<niemeyer> cachio: Thanks, reported
<cachio> niemeyer, yaw
<mup> PR snapd#3527 closed: hooks: support for revert hook <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/3527>
<Cynerva> what's the best/proper way to unset snap config? i've been telling people to do it by setting to null, e.g. `snap set kube-apiserver runtime-config=null`
<Cynerva> which worked for me before, but i guess someone hit a bug with that
<mup> PR snapd#3523 closed: tests: fix for create-key task to avoid rng-tools service ramains alive <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3523>
<mup> PR snapd#3535 closed: snap-seccomp: fix snap-seccomp tests in artful <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3535>
<mup> Bug #1697880 changed: Add "search" as an alias for "find" in snap command <snapd:Triaged> <https://launchpad.net/bugs/1697880>
#snappy 2017-06-28
<mup> Bug #1686852 changed: Can only run hello snap as root <Snappy:Expired> <https://launchpad.net/bugs/1686852>
<mup> PR snapcraft#1361 closed: pluginhandler: don't clobber path on local import failure <Created by zyga> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1361>
<mup> PR snapd#3536 opened: snap-seccomp: deal with mknod on aarch64 in the seccomp tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3536>
<mup> PR snapd#3537 opened: many: "os" -> "core" snap type <Created by chipaca> <https://github.com/snapcore/snapd/pull/3537>
<cachio> mvo, when you have 1 minute, could you please see PR 3515
<cachio> it is ready
<mup> PR snapd#3515 closed: tests: fix snapd-notify when it takes more time to restart <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3515>
<Chipaca> cachio: do you still not have merge ability?
<cachio> Chipaca, I dont
<Chipaca> cachio: grumble
<mvo> cachio: sure
<mvo> cachio: aha, already merged
<cachio> mvo, chipaca did it, thanks anyway
<Chipaca> cachio: you've been invited to snapd-committers
<cachio> Chipaca, awesome, thanks!!
<mup> PR snapd#3537 closed: many: `os` â¯ `core` snap type <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3537>
<mup> PR snapd#3538 opened: tests: create ramdisk if it's not present <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3538>
<mup> PR snapd#3506 closed: asserts: introduce NewDecoderWithTypeMaxBodySize <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3506>
<Chipaca> pedronis: changeIDMixin, or changeIDmixin?
<pstolowski> cachio, mksnap_fast is the helper I mentioned
<cachio> pstolowski, great, thanks
<cjwatson> I guess somebody will retry the erroring Travis builds once the offending repository stops hash-mismatching?  (https://travis-ci.org/snapcore/snapd/pull_requests)
<pstolowski> cjwatson, we have everything failing like this right now so yeah, i think we will just restart the jobs when we see things are back to normal
<cjwatson> thanks
<mup> PR snapd#3539 opened: tests: fix timeout issue for test refresh core with hanging â¦ <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3539>
<Chipaca> niemeyer: "2017-06-28 12:56:56 Cannot allocate linode:ubuntu-core-16-64: cannot boot linode:ubuntu-core-16-64 (Spread-50): cannot Direct Disk boot a disk with no MBR"
<mup> PR snapcraft#1385 opened: lxd: Don't assume user ID to 1000 for raw.idmap <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1385>
<cachio> niemeyer, we are facing that errror in almost all the execs
<cachio> niemeyer, this is an example https://travis-ci.org/snapcore/snapd/builds/247926959
<cachio> niemeyer, also there are many errors like
<cachio> Discarding linode:ubuntu-16.04-64 (Spread-68), cannot connect: cannot connect to linode:ubuntu-16.04-64 (Spread-68): dial tcp 50.116.8.205:22: i/o timeout
<mup> PR snapcraft#1376 closed: options: fix s390 kernel arch <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1376>
<Cynerva> could i get some eyes on this bug? https://bugs.launchpad.net/snapd/+bug/1699768
<mup> Bug #1699768: "snap set" causes snapd crash <snapd:New> <https://launchpad.net/bugs/1699768>
<Cynerva> tl;dr `snap set` to null causes a snapd panic
<Cynerva> it's blocking us on a feature for canonical distribution of kubernetes
<pstolowski> Cynerva, reproduced here
<Cynerva> pstolowski: thanks, any idea how long it might be before a fix?
<pstolowski> Cynerva, i'm looking at it, but i'm currently at the snappy sprint; but even if I have a fix which hits master in the next few days, it will take 2-3 weeks till it's released
<pstolowski> Cynerva, (new snapd release I mean)
<Cynerva> pstolowski: ack, thanks!
<mup> PR snapd#3540 opened: overlord/state: Abort() only visits each task once <Created by chipaca> <https://github.com/snapcore/snapd/pull/3540>
<Chipaca> mvo: ^
<noise][> in case anyone notices, http://status.snapcraft.io/ is 400'ing, I'm working w/support to get it fixed
<mup> Bug #1701018 opened: Splash screen is not enabled in kernel <Snappy:New> <https://launchpad.net/bugs/1701018>
<pstolowski> Cynerva, would setting the value to "" or some oher meaningless value other than null worked as a workaround before I've proper fix?
<Cynerva> pstolowski: not with how our kubernetes snaps are written today, their configure hooks use `snapctl get -t` which gives different values for null and ""
<Cynerva> pstolowski: but it might make sense for us to update those snaps to accept either
<Cynerva> pstolowski: so yeah, that might be an usable workaround for us :)
<pstolowski> Cynerva, okay, something to consider to unblock you before the fix arrives
<Cynerva> thanks pstolowski
<pstolowski> Cynerva, np. sorry for the trouble
<mup> Bug #1686852 opened: Can only run hello snap as root <Snappy:New> <https://launchpad.net/bugs/1686852>
#snappy 2017-06-29
<mup> Bug #1650671 opened: Content sharing from snap common is broken <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1650671>
<Chipaca> zyga: have you looked at snapd#3499 at all? (is that a "you" pr? or is it one for jamie? or...?)
<mup> PR snapd#3499: Spi patch <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
<zyga> mvo: +1 to merge https://github.com/snapcore/snapd/pull/3464
<mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
<mvo> zyga: did one of the reviewer check each individual snippet that its the same  as in the old big table?
<mvo> zyga: other than that, +1
<zyga> mvo: I cannot say but since jdstrand reviewed it I really trust it is
<zyga> mvo: if you want just go over each patch (they are structured for thaT)
<zyga> mvo: so that you see the same stuff in green and red
<mup> PR snapd#3464 closed: interfaces: put base policy fragments inside each interface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3464>
<ogra_> ppisati, mind taking a look at bug 1701018 ? (your opinion would be helpful there i think)
<mup> Bug #1701018: Splash screen is not enabled in kernel <Snappy:New> <https://launchpad.net/bugs/1701018>
<ppisati> ogra_: yep, as far as i know when you enable the spashscreen you have to select a bitmap
<ogra_> and it defaults to the penguin ...
<ppisati> ogra_: yep
<ogra_> the prob is that they currently use our linux-generic-raspi2 snap ... so they will likely have to rebuild
<ogra_> (which will make their security story a bit awkward)
<ogra_> can you mention that on the bug ?
<ppisati> ogra_: yeah. go ahead
<ogra_> ppisati, i was hoping you can do that (i want a more authoritative person speaking than me :) )
<ppisati> ogra_: oh k, no prob
<ogra_> thanks :)
<mup> PR snapd#3541 opened: snapd: fix for snapctl get panic on null config values <Created by stolowski> <https://github.com/snapcore/snapd/pull/3541>
<ppisati> ogra_: replied, but actually his request make sense - he wants to setup the splash screen from uboot and then make the kernel pick it up without touching, i wonder if someone already did it
<ppisati> ogra_: but they probably did per-build, i doubt there's something generic
<ogra_> yeah
<ogra_> ppisati, what i tried here was to set "stdout=" in u-boot (i.e. drop serial and vga) but that just ends up with the kernel blanking the console (and not showing any further output) instead of leaving it untouched
<ogra_> so i guess you would have to actually turn off the console completely in the kernel and have it not take over hdmi at all
<ogra_> ... pprob is ... they do digital signage ... so they will need the display later from userspace
<ppisati> so they want the splashscreen till userspace picks up, then they'll mess with fb from there
<ppisati> uhm
<ogra_> well, either that or have the kernel show the same splash when it inits the screen
<ogra_> they simply want a splash during the whole boot til userspace ... i guess they dont care how they get there
<ppisati> k
<ppisati> but no, no dynamic splash support in the kernel
<ogra_> yeah ... and plymouth is really not an option for the generic initrds
<ogra_> they might be able to buuld their own ... and end up with a 20MB initrd or so
<ppisati> i wonder if there's a way to embed a bitmap in DT so both uboot and kernel can be teached to use whatever is there
<ogra_> *build
<ppisati> that would generic enough
<ogra_> oh
<ogra_> now thats an idea
<ppisati> but then, we need first to find if they want binary data in DT
<ppisati> and that will probably blow the space reserved for DT at boot
<ppisati> in rpi2 at least
<ogra_> yeah
<ogra_> but thinking about it ... android also manages to have a bootloader splash that stays
<ogra_> until surfaceflinger starts in userspace
<ogra_> though they usually dont have any framebuffer console at all
<ppisati> but they build the kernel fr that device, so they can hardcode the bitmap there
<ppisati> ogra_: have you tried asking this question to the graphics people? perhaps they know a way to skip fb initialization if it's already setup
<ogra_> i'm not sure they build the kernel ... afaik they use our snap and want to get the security benefits from it
<ppisati> ogra_: they can use our src tree, and just apply a single patch (config + bitmap on top of it), and every time we cut a new release, they rebase and rebuild
 * ogra_ finds psplash ... 
<ogra_> i wonder if we could ship that in our initrd ... looks a lot easier than plymouth
<ogra_> http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/
<ogra_> PSplash is a userspace graphical boot splash screen for mainly
<ogra_> embedded Linux devices supporting a 16bpp or 32bpp framebuffer. It has
<ogra_> few dependencies (just libc), supports basic images and text and handles
<ogra_> rotation.
<ppisati> ogra_: but don't they have to add their logo to initrd though?
<ogra_> yeah
<mup> PR snapd#3542 opened: cmd,client,daemon: expose "force devmode" in sysinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/3542>
<ogra_> jdstrand, do we have any interface that allows direct access to /dev/fb0 (i suspect i know the answer, but thought i'd ask anyway) ...
<ogra_> i just makes a psplash snap that runs fine in devmode ...
<mup> Bug #1699504 changed: "network" plug does not allow outbound ping <Snappy:Invalid> <https://launchpad.net/bugs/1699504>
<ogra_> kyrofa, http://paste.ubuntu.com/24980409/
<ogra_> kyrofa, looks like your devices uses at91-sama5d3_xplained.dtb ... which isnt in our kernel
<ogra_> kyrofa, https://goembed.in/2016/03/18/build-and-install-linux-for-arm-cortex-a5-based-embedded-board/ looks like a useful starting page
<kyrofa> ogra_, ah, thank you! How did you find the at91 bit?
<ogra_> google ;)
<ogra_> seraching for "ATSAMA5D36 dtb"
<jdstrand> ogra_: yes, framebuffer
<jdstrand> mvo (cc zyga): I reviewed every line of https://github.com/snapcore/snapd/pull/3464 and I used the debug functionaility to compare outputs before and after
<mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3464>
<matteo> hey guys
<ogra_> jdstrand, bah ... the tool i use uses "dup()" ...
<ogra_> jdstrand, that is why framebuffer doesnt work ... still blocked by seccomp
<ogra_> do you think that could be allowed ?
<ogra_> HAH ...
<ogra_> cheating helps ... if i use docker-support i get access to the dup syscall
<ogra_> :D
<cachio> niemeyer, https://paste.ubuntu.com/24980832/
<niemeyer> cachio: Aw, it removed the disks..
<cachio> yes
<niemeyer> cachio: Can you retry with --debug?
<cachio> niemeyer, it the same with -debug
<cachio> something is hepening before the machine is ready
<cachio> after the step Creating configuration on linode:ubuntu-core-16-64
<niemeyer> cachio: Ah, of course, sorry :(
<niemeyer> cachio: Hmmm
<cachio> it waits until boot
<cachio> and then it is removing disks
<cachio> it is like the image could not be booted
<niemeyer> cachio: Can you rebuild spread locally and disable the disk removal logic?
<niemeyer> cachio: We want to keep around a machine that failed with that error, just once, so we can hand it to support
<cachio> niemeyer, ok sure
<mup> PR snapd#3536 closed: snap-seccomp: deal with mknod on aarch64 in the seccomp tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3536>
<cachio> niemeyer, (Spread-04): 45.33.76.13
<cachio> niemeyer, cannot boot linode:ubuntu-core-16-64 (Spread-04): configID not found
<cachio> niemeyer, (Spread-68): 50.116.8.205
<cachio> this failed
<jdstrand> ogra_: dup, dup2 and dup3 are alreadyin the default seccomp template
<cachio> niemeyer, (Spread-68): 50.116.8.205
<mup> PR snapd#3543 opened: osutil: allow building on ppc64 (not LE) <Created by zyga> <https://github.com/snapcore/snapd/pull/3543>
<cachio> this last one has the disk and config
<tintou> Jun 29 12:03:07 Coco-XPS-13-9360 kernel: [12493.683255] audit: type=1400 audit(1498734187.179:530): apparmor="DENIED" operation="open" profile="snap.test-gst-clutter.test-gst-clutter" name="/sys/devices/pci0000:00/0000:00:02.0/vendor" pid=30120 comm="test-gst-clutte" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<tintou> https://www.irccloud.com/pastebin/5o8o4aC3/gst-error
<kyrofa> tintou, got it, sorry
<kyrofa> Didn't realize I was offline :)
<mup> PR snapcraft#1384 closed: Support yaml merge tags <Created by tim-sueberkrueb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1384>
<mup> PR snapcraft#1378 closed: Integration tests for snap command with target arch <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1378>
 * Chipaca hugs jdstrand
 * jdstrand hugs Chipaca back :)
<mup> PR snapd#3544 opened: tests: make main/help run on opensuse and fedora again <Created by chipaca> <https://github.com/snapcore/snapd/pull/3544>
<Chipaca> fginther: Pharaoh_Atem: ^
<Chipaca> um
<Chipaca> i meant fgimenez, but he's not here
<mup> PR snapd#3532 closed: many: support snap title as localized/title-cased name <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3532>
<stgraber> sergiusens, kyrofa: is https://bugs.launchpad.net/snapcraft/+bug/1590767 somewhere on the roadmap for the next snapcraft?
<mup> Bug #1590767: Support snap installed completion scripts <isv> <lxd> <snapd-interface> <Snapcraft:Triaged> <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1590767>
<stgraber> or is there already some way of passing the completer through to snapd which I'm not aware of?
<sergiusens> stgraber: I've updated the bug status for snapcraft.
<stgraber> sergiusens: great, thanks!
<sergiusens> stgraber: would be nice for the snapd side of the bug to be updated though, your comment gives me confidence it is already available for all snapd installations though
<stgraber> sergiusens: yeah, I remember mvo saying it would be in 2.26 and the release notes for 2.26 seem to confirm it
<stgraber> sergiusens: there may issues though since I doubt anyone actually used it given that snapcraft doesn't support it
<cjwatson> Could somebody please retry https://travis-ci.org/snapcore/snapd/builds/248376205 ?  I don't think the timeout is the fault of my PR.
#snappy 2017-06-30
<fgimenez> zyga: "for i in $(seq 30); do spread -v -debug -reuse -seed=1498731712 external:ubuntu-core-16-arm-32:tests/main/abort external:ubuntu-core-16-arm-32:tests/main/interfaces-home external:ubuntu-core-16-arm-32:tests/main/ubuntu-core-reboot; done"
<kyrofa> niemeyer, I've got a few snapcraft items on the agenda I'd like to discuss at least with you at some point
<niemeyer> kyrofa: Sounds good!
<kyrofa> niemeyer, let me know when you have a gap
<mup> PR snapd#3545 opened: many: support querying and completing assertion type names <Created by chipaca> <https://github.com/snapcore/snapd/pull/3545>
<Chipaca> pedronis: snapd#3540 is almost green
<mup> PR snapd#3540: overlord/state: Abort() only visits each task once <Created by chipaca> <https://github.com/snapcore/snapd/pull/3540>
<cjwatson> Could somebody please retry https://travis-ci.org/snapcore/snapd/builds/248376205 ?  I don't think the timeout is the fault of my PR.
<fgimenez> mvo: http://paste.ubuntu.com/24987938/
<mup> Bug #1701510 opened: Unbind brcmfmac_sdio crashes netplan <Snappy:New> <https://launchpad.net/bugs/1701510>
<mup> PR snapd#3546 opened: tests: fix for rng-tools service not restarting <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3546>
<mup> PR snapd#3543 closed: osutil: allow building on ppc64 (not LE) <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3543>
<ogra_> ppisati, https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/46?u=ogra
<ogra_> ppisati, thats the plan for updating gadgets ... part of it means we need to ship the broadcom firmware with the kernel snap (so bootloader never gets out of sync with the kernel)
<ogra_> i.e. we'll need some changes to the snp build of the raspi2 kernel snap
<ppisati> ogra_: so everything ends up in the kernel snap
<ogra_> well, not uboot, config.txt, cmdline.txt and uboot.env
<ogra_> only the bits that could break the boot
<ogra_> (in case they are bound to the kernel version)
<ppisati> ogra_: ogra_ config.txt and cmdline are part of the broadcm bootloader, IMO they should stay with the bootloader binaries
<ogra_> we cant really overwrite existing ones ... the user might have made adjustments
<ogra_> so only binaries
<ogra_> i.e. start.elf and friends
<ogra_> they also dont get updated every time ... only if there are new upstream versions
<mup> PR snapd#3547 opened: snap-seccomp: skip socket() tests on systems that use socketcall() instead of socket() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3547>
<mup> PR snapd#3548 opened: interfaces: Add /run/uuid/request to openvswitch <Created by coreycb> <https://github.com/snapcore/snapd/pull/3548>
#snappy 2017-07-01
<mup> PR snapcraft#1379 closed: blank version should not be allowed in snapcraft.yaml <Created by roxyd> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1379>
<mup> PR snapcraft#1386 opened: tests: workaround issue that causes failures to download core <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1386>
<mup> PR snapcraft#1387 opened: tests: reenable the cleanbuild integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1387>
<mup> PR snapcraft#1388 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1388>
<bdx> what is the preferred method of getting the host arch from within a plugin context?
<bdx> I'm thinking there has to be a `uname -p` equivalent hanging around here
<popey> ogra_: http://paste.ubuntu.com/24999295/ is the syslog from my nano pi air running your image. I haven't got a serial cable so can't actually use it yet.
#snappy 2017-07-02
<LockeAnarchist> Hello
<LockeAnarchist> I'm having problems trying to run snappy packages on Arch
<LockeAnarchist> I tried Discord and Micro
<LockeAnarchist> They don't run
<LockeAnarchist> Don't know the reason
<devil> ogra_: hi, was following your article on setting up wifi access point with ubuntucore. I have 2 questions for you: during the ap setup wizard you use 192.168.1.1 as IP. Is that the general ip or is that your router ip?
<devil> secondly, at the end you write, onme should connect to connect to the WiFi AP SSID. what tolls does ubuntucore offer to do so
<devil> ...one should connect to...
<devil> ogra_: sorry, forget it, I had a knot in my brain
<ogra_> devil, my LAN is 192.168.2.X ... so thats the ip for the WIFI ... (if you read carefully again, you can see that i initially ssh into 192.168.2.82, whitch is eth0 of the board)
<ogra_> popey, awesome, seems to boot all the way through ... i see no wlan device though :(
<popey> ogra_: http://wiki.friendlyarm.com/nanopi2/download/ links to https://www.mediafire.com/folder/ilkcy37otd7il/S5P4418 which has an s5p4418-ubuntu-core-qte-sd4g-20170613.img.zip which I will try, to see if that has a driver.
<popey> also they have an amusingly named "Ubuntu Mata" directory containing Ubuntu MATE :)
<popey> oh, wrong device
<popey> no image for nano pi air
<diddledan> it looks like gimp isn't relocatable :-(
<diddledan> it fails to start with a window saying it can't copy a standard .gtkrc from it's installation because it builds the path at build time not runtime
<diddledan_> this is the relevant path construct: http://paste.ubuntu.com/25005500/
<diddledan_> also. awesome number batman!
<diddledan_> it's called by this code which I _think_ allows me to perhaps fiddle with the path by setting the environment variable? http://paste.ubuntu.com/25005521/
<diddledan> ok, yes, it looks like this will override it
<diddledan> yey, I dun dit it
<diddledan> it werks
<diddledan> d'oh. can't read png files :-(
<diddledan> or any images
#snappy 2018-06-25
<mup> PR snapd#5385 opened: Update SELinux policy <Created by kevinanderson1> <https://github.com/snapcore/snapd/pull/5385>
<mborzecki> morning
<taaperotassu> Is there any way to see snapcraft stores most downloaded packages? Or see all the packages that are available?
<zyga> Good morning
<mborzecki> zyga: mvo: hey
<mvo> hey mborzecki and zyga !
<mup> PR snapd#5385 closed: Update SELinux policy <Created by kevinanderson1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5385>
<zyga> hey mvo
<mup> PR core18#37 opened: static: add systemd environment generator to ensure PATH contains /snap/bin <Created by mvo5> <https://github.com/snapcore/core18/pull/37>
<zyga> re
<zyga> ok, kids are handled
<zyga> mvo: re, so about those issues you saw last week
<zyga> I'd like to look at the one with layouts later today
<pstolowski> morning
<zyga> I need to work on some leftovers from Friday
<zyga> and I need to plan a rework of security profiles after the call with gustavo
<abeato> mvo, hey, do you have any comments on https://forum.snapcraft.io/t/pulling-network-online-target-as-prerequisite-target-slows-down-starting-services/6063 ? Would be nice to have the opinion of some core team member there :)
<mborzecki> pstolowski: hey
<mvo> zyga: sure
<mvo> abeato: let me look
<mvo> zyga: a quick look at core18#37 would be great, I hope this unblocks some tests
<mup> PR core18#37: static: add systemd environment generator to ensure PATH contains /snap/bin <Created by mvo5> <https://github.com/snapcore/core18/pull/37>
<abeato> mvo, thanks
<mup> PR core18#37 closed: static: add systemd environment generator to ensure PATH contains /snap/bin <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/37>
<mborzecki> abeato: wondering, aside from longer times reported by system-analyze, does this dependency have any negative impact?
<abeato> mborzecki, it does, it implies that starting a service can take 2 minutes more than it should. Think for instance in a system with eth0 and wlan0 configured but SSID not found: you get those additional 2 minutes
<abeato> or eth0 not connected
<mborzecki> abeato: right, but this is just snapd depending on the network (which it could not depend on because the failures are already handled in the code), but this should be fairly transparent for installed snaps and other services, i.e. you don't depend on snapd or network-online -> there's no penalty
<mborzecki> so it's either a service depends on snaps (when it shouldn't) or it's part of graphical target (which iirc depends on mult-user, which in turn snapd is WantedBy)
<abeato> mborzecki, nope, it is that the unit created by snapd when installing the snap includes the network-online.target dependency. The impact is on the service defined by the snap, not in snapd
<mborzecki> abeato: aah ok, missed that! thanks for claryfing
<abeato> np
<mborzecki> mvo: didn't we have some proposals for expressing dependencies on external services/targets?
<mvo> mborzecki: we have a request but no design for this so far :/
<mborzecki> still, we don't have support for Requires at this point
<mvo> yep
<Chipaca> moin moin
<pedronis> mvo: hi, did we add back code to wait for restarts for core/snapd ? we probably need to before 2.34
<mvo> pedronis: no code for this yet
<mvo> pedronis: I will look into it later today
<pedronis> thx
<mup> PR core18#38 opened: hooks: add libpam-systemd <Created by mvo5> <https://github.com/snapcore/core18/pull/38>
<mup> PR core18#38 closed: hooks: add libpam-systemd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/38>
<mvo> sil2100: hey, good morning! I did (as an experiment) mergehttps://github.com/snapcore/core18/commit/a9c4ea6ff0732911a47fa7a1b035eb10c1e68cd4  and https://github.com/snapcore/core18/commit/28b28abd1968b75d3d201d57321a746b6912c7b1 - the background is that "su -l -c env user" on core18 has a PATH without /snap/bin and I suspect its the missing libpam-systemd. if you have more ideas they are very welcome, its not entirely clea
<mvo> r to me if its that or not
<mborzecki> anyoen feels like reviewing #5363 or #5366?
<mup> PR #5363: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
<mup> PR #5366: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
<pedronis> mvo: is the plan to add "netcat" to core18 or not ?
<mvo> pedronis: I pushed a pr to core18 with it, its tiny, I think its worth adding it
<mvo> pedronis: given that its useful in tests and on its own (for admins for debugging)
<mborzecki> thanks for the reviews guys!
<Chipaca> you ask for reviews, you get reviews
<Chipaca> 20 reviews per pr, approximately
<mvo> sil2100: hm, libpam-systemd did not cut it, I will need to dig into this a bit more it seems, very strange
<pedronis> mvo: yes, not against, just confused by the PR that remove tests that needs it
<pedronis> s/remove/disable/
<mvo> pedronis: yeah, my initial thinking was to disable those but then I realized just how many that are and I think now that the better approach is to just add it
<mvo> pedronis: also it was to cut down noise from the tests, I ran the main suite against core18 over the weekend and tried to classify the failures
<pedronis> it's ok
<pedronis> also they are all about network interfaces that are quite fundamental
<pedronis> and they might have classic vs core differences
<pedronis> Chipaca: I added some questions to your snapshotstate PR,  not sure that's a way to unblock that doesn't involve doing the right thing though :/
<pedronis> s/that's/there's/
<Chipaca> pedronis: I just see one about "snapshot" -> "snapshotSetup"
<pedronis> Chipaca: yes
<Chipaca> ah the others are under some of gustavo's hidden ones
<Chipaca> pedronis: I'll look at it later today (i probably meant IsActive instead of IsInstalled there)
<Chipaca> need to do paperwork now
<pedronis> Chipaca: yes, IsInstalled is just needed for the pattern IÂ show
<pedronis> (I think we have one place still in the code base that has a silly one)
<pedronis> Chipaca: anyway IÂ need to finish the improved error stuff before IÂ can help unblock you
<pedronis> Chipaca: sounds like snapshot will 2.35 though :(
<pedronis> *will be
<mvo> pedronis: thank you. I will update the PR once I finished digging into a strange PATH issue on core18
<pedronis> mvo: which reminds me,  not urgent,  there's an extra ":"  in the entry  ': Interface hooks' in the snapd 2.34 roadmap  https://forum.snapcraft.io/t/the-snapd-roadmap/1973
<mvo> pedronis: thank you, nice catch
<abeato> mvo, a possible optimization: https://forum.snapcraft.io/t/are-systemctl-daemon-reload-calls-before-enabling-a-service-needed/6086
<mup> PR snapd#5386 opened: snap: introduce a struct StoreChannel to represent store channels, and helpers to work with it <Created by pedronis> <https://github.com/snapcore/snapd/pull/5386>
<pedronis> Chipaca: ^  what we discussed
<mup> PR snapd#5363 closed: snap: introduce the instance key field <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
 * zyga struggles with apparmor profiles
<mup> PR snapd#5387 opened: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5387>
<mborzecki> another little piece of parallel installs is up for review
<mborzecki> pedronis: ^^
<mup> PR core18#39 opened: hooks: ensure /etc/login.defs PATHs contain /snap/bin <Created by mvo5> <https://github.com/snapcore/core18/pull/39>
 * Son_Goku groans to life
<mborzeck1> wtf, no power, obviously the electricity company allegedly has this info posted 'somewhere', bunch of lunatics
<Chipaca> mborzecki: did you electricity company not pay their bills
<mborzecki> Chipaca: no it's just run by a bunch of a*holes, because it's easier to collect the bills rather than keep the infra in decent shape
<Chipaca> mborzecki: in my current font, * looks just right for use in that word
<mborzecki> Chipaca: what's the font?
<Chipaca> mborzecki: the go one
<Chipaca> https://blog.golang.org/go-fonts
<Chipaca> reminds me of the old solaris console font
<mborzecki> glad i pushed everything minutes before the power was gone
<mup> PR snapd#5329 opened: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>
 * zyga runs another round of layout tests
 * Chipaca ~> lunch
<mvo> a review of core18#39 would be great, this should unblock some more tests
<mup> PR core18#39: hooks: ensure /etc/login.defs PATHs contain /snap/bin <Created by mvo5> <https://github.com/snapcore/core18/pull/39>
<zyga> mvo: done
<niemeyer> Heya
<niemeyer> I've just did an update on Spread to fix the issue reported by Google.. please let me know if you see any hiccups
<niemeyer> I've just done
<mup> PR snapd#5376 closed: tests: skip security-udev-input-subsystem without /dev/input/by-path <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5376>
<Chipaca> niemeyer: how did google report an issue on spread?
<niemeyer> Chipaca: I got an email
<Chipaca> niemeyer: "you're the person responsible for 98% of all api calls"?
<Chipaca> flashbacks of linode
<niemeyer> Chipaca: Yeah, it did bring me memories, but this time it was more like "You are the person responsible for 98% of the API calls that start with a double dash (//)"
<niemeyer> s/dash/slash
<Chipaca> niemeyer: so causing a lot of redirects?
<mborzeck1> let me give you this bag og 500 Internal Server Error
<Chipaca> ah :)
<niemeyer> Or something.. we did get 500s
<niemeyer> They didn't specify what the outcome was on their end, just politely asked whether we could get it fixed
<Chipaca> and you didn't turn around and spam double-slashed endpoints with all the bandwidth you could muster?
<Chipaca> you're too kind
<mup> PR core18#39 closed: hooks: ensure /etc/login.defs PATHs contain /snap/bin <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/39>
<mup> PR snapd#5388 opened: tests: fix tests when no keyboad input detected <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5388>
<mup> PR snapd#5382 closed: tests: add halt-timeout to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5382>
<zyga> cachio: which PR is that?
<mvo> mborzecki: ha! I found *why* su -l is not working anymore in core18: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/984390 - anyway, I will work with foundations now to see if I can get it upstream
<mborzecki> zyga: i see 4.14 kernel in for raspberrypi in yocto
<mup> Bug #984390: $PATH is taken from login.defs not /etc/environment <patch> <shadow (Ubuntu):Triaged by canonical-foundations> <shadow (Ubuntu Precise):Triaged by canonical-foundations> <https://launchpad.net/bugs/984390>
<mborzecki> mvo: thanks, intersting
<zyga> mborzecki: current "production" is 4.9 for older models
<mborzecki> heh 'production' for raspberry pi :P
<mvo> mborzecki: its quite terrible, I debugged fixed this ~2y ago already but it did not land in the distro
 * zyga had a full successful run on his layout patch, whee
<zyga> mborzecki: I mean the one they ship with by default
<mborzecki> wonder what's holding them back aside from gpu
<zyga> probably the question is different
<zyga> no need to go forward so why would they
<mborzecki> (and totally crazy boot process, unless they changed it already)
<zyga> the boot spec is part ot the hardware
<zyga> mvo, niemeyer: one new interesting feature of systemd is the specification for new boot process
<zyga> that's worth reading
<mvo> zyga: do you have a link?
<zyga> yes, one sec
<mborzecki> mvo: https://lwn.net/Articles/758128/
<mvo> mborzecki: ta
<zyga> https://github.com/systemd/systemd/blob/master/doc/BOOT_LOADER_SPECIFICATION.md
<mborzecki> zyga: NoNewPrivileges looks interesting
<zyga> yes but it is unlikely to work soon
<zyga> (as stated in the docs)
<zyga> mborzecki, mvo: I personally really like the idea of that single-efi file that bundles linux, initrd and os-release file
<zyga> that means you can boot a single "linux.efi" file
<zyga> that's self contained
<zyga> that's neat IMO
<mvo> zyga: sounds a bit like a snap
<zyga> mvo: yes, we perhaps could adopt it
<zyga> it would mean we are an easier support target down the line
<zyga> well, at least an idea
<zyga> brb, need to resize my partitions
<mborzecki> heh, the hangouts call pulled 1.2GB of data on my modem
<zyga> revising from break=bottom ;)
<zyga> resizing*
<zyga> ok, quick lunch break
<sitter> when I run snapcraft should it automatically detect common-id's or do I have to manually specify them in my snapcraft.yaml?
<cachio> zyga, sorry for the delay, #5343
<mup> PR #5343: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5343>
<zyga> sitter: I don't know if it is implemented but there are specs for a system where appstream meta-data can be automatically ingested
<zyga> sitter: I don't know if that's implemented yet though, perhaps kyrofa knows
<mup> PR core18#40 opened: hooks: add FIXME for /etc/login.defs changes <Created by mvo5> <https://github.com/snapcore/core18/pull/40>
 * zyga sincerely hopes for the weather to improve and some pressure to increase
<zyga> today feels like mid winter when it's dark, gloomly and wet outside
<zyga> not like first week of summer
<mup> PR core18#40 closed: hooks: add FIXME for /etc/login.defs changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/40>
<sitter> seems https://forum.snapcraft.io/t/adopt-info-from-other-metadata-sources/4370 has the information, assuming that is the latest and greatest way of doing it anyway
 * zyga has IRL interrupt
<mup> PR snapd#5380 closed: tests: blacklist more main tests for core18 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5380>
<pedronis> pstolowski: disconnect branch seems to need now a merge from master (only test failing is spellecheck)
<pstolowski> pedronis: thanks. it still needs some work re undo on disconnects
<mup> PR snapcraft#2168 opened: build_providers: add ssh key managemet support to the qemu build provâ¦ <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2168>
<zyga> jdstrand: good day, are you back by any chance?
<jdstrand> zyga: hi! yes. lots of catching up. what's up?
<zyga> jdstrand: I will have some follow up from layouts but nothing major, just wanted to say hi :)
<mup> PR snapd#5226 closed: data: add systemd user environment generator <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5226>
<mup> PR snapd#5389 opened: snap: account for parallel installs when dealing with broken snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5389>
<zyga> I can imagine you have a lot of catchup to do
<jdstrand> zyga: :)
 * zyga thinks about a 3rd coffee
<zyga> rainly gloomly summer
 * cachio lunch
<mup> PR core18#35 closed: hooks: add netcat package <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/35>
<mup> PR snapd#5390 opened: data: add systemd environment configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/5390>
<ogra_> zyga, i'm a but surprised about that snap version output in the forum, doesnt the snap command itself pull the info our of os-release and uname ? (i thought snap version does not require snapd to run to get at least the needed info from the os)
<zyga> ogra_: no, it's all server side
<ogra_> hmm
<zyga> ogra_: (which makes sense if you think about it being, one day, able to talk to remote servers)
<ogra_> (that makes debugging  a server outage indeed a bit tricky :) )
<ogra_> true ... but perhaps it should then have a --no-remote flag so it can still collect the system info for debugging
<zyga> well, it's not much of use if the server is down
<zyga> and the set of collected things is tricky to compute locally really
<ogra_> haha, systemd is always so helpful with its messages ...
<ogra_> "he start-up result is RESULT"
<ogra_> *the
<ogra_> shouting doesnt help ! ... not even in logs :P
<cwayne> It just wanted to make sure you heard it ogra_
<ogra_> yeah, obviously :)
<ogra_> thats like "command failed with: SUCCESS"
<ogra_> zyga, i bet one of these php thingies he installed is some third party installer or tarball that mangles the install bad enough to break the world
<ogra_> ot that "magento CMS platform" or whatnot
<ogra_> *or
<zyga> yeah, pretty horrible people make php
<zyga> (as in make use of it)
<zyga> also make the thing
<ogra_> WOW ... that log now !
<ogra_> curious that *anything* works on that install
<mvo> hm, hm, can someone help with "error: File must begin with "/": %{_environmnentdir}/990-snapd.conf" - I get this from rpm packaging in https://github.com/snapcore/snapd/pull/5390 but the macro should be defined inhttps://github.com/systemd/systemd/blob/master/src/core/macros.systemd.in
<mup> PR #5390: data: add systemd environment configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/5390>
<Son_Goku> mvo, which target?
<zyga> mvo: I was reviewing
<mvo> Son_Goku: opensuse and fedora
<mvo> Son_Goku: is this stuff just too new? git blame tells me it was added only one month ago?
<mvo> zyga: ups, sorry
<zyga> no worries :)
<Son_Goku> while the functionality existed for a while, the macro didn't exist until systemd 239
<Son_Goku> we just need a compat macro ;)
<mvo> also "_environmnentdir" looks like a typo
<mvo> Son_Goku: aha!
<Son_Goku> and yes, someone screwed up
<mvo> Son_Goku: I will push a fix
<Son_Goku> %{?!_environmentdir: %global _environmentdir %{_prefix}/lib/environment.d}
<mvo> Son_Goku: \o/
<Son_Goku> mvo, zyga: https://github.com/systemd/systemd/pull/9417
<mup> PR systemd/systemd#9417: rpm: Fix typo in %_environmentdir <Created by Conan-Kudo> <https://github.com/systemd/systemd/pull/9417>
<mvo> Son_Goku: heh, was about to do this, thank you!
<Son_Goku> mvo, I would have liked to see you send a PR for rpm things :P
<pedronis> niemeyer: btw, if IÂ remember you said you wanted to chime in on (there is related work going on):Â  https://forum.snapcraft.io/t/url-contact-fields-in-snap-metadata/3067/18
<zyga> Thank you Son_Goku
<zyga> my son has smalled a huge sliding window on his toe
<zyga> some tears and blood later, I am back
<Son_Goku> ...
<cachio> mvo, hey, do you know why the econnreset test blocks the download once it is started?
<cachio> mvo, it is any reason to don't block it before it starts?
<cachio> because I could reproduce the error and found the download finishes after we compare the size of the partial file and before iptables is applied
<cachio> mvo, this is the log https://paste.ubuntu.com/p/2yFqrXT7rd/
<cachio> it has extra debug info
<niemeyer> pedronis: Looking
<niemeyer> pedronis: Provided some feedback there
<niemeyer> zyga: Ouch
<mvo> Son_Goku: hehe, exactly :)
<mvo> cachio: iirc in the old days it would not retry on econnectionrefused
<mvo> cachio: but the retry logic has changed quite a bit so maybe now thats fine?
<Son_Goku> mvo, one day, I'll win you over to the awesome side :)
<cachio> mvo, ok, I'll change the test and see what's the result
<mvo> Son_Goku: :-D
<mvo> cachio: cool, keep me updated
<cachio> mvo, running
<mup> PR core18#36 closed: hooks: set timezone to Etc/UTC <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/36>
<sil2100> mvo: hmm, let me also experiment with that PAT
<sil2100> *PATH missing /snap/bin
<mvo> sil2100: I found the issue
<mvo> sil2100: https://github.com/shadow-maint/shadow/pull/119
<mup> PR shadow-maint/shadow#119: su.c: run pam_getenvlist() after setup_env <Created by mvo5> <https://github.com/shadow-maint/shadow/pull/119>
<mvo> sil2100: this also links to a bug (from 2012 :)
<mvo> sil2100: so we have a workaround for now, I will revert the systemd generator
<mvo> sil2100: and once the fix for su.c is approved I/we can SRU the fix
<mvo> sil2100: and undo the workaround
<sil2100> wow
<sil2100> ;)
 * zyga moves to another room
<mup> PR snapd#5391 opened: tests: simplify econnreset test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5391>
 * cachio afk
<mup> PR snapcraft#2169 opened: Rust plugin improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2169>
<mup> PR snapcraft#2158 closed: rust plugin: fix cargo builds and run tests <Created by tismith> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2158>
<mup> PR snapcraft#2170 opened: Rust plugin env <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2170>
<mup> PR snapcraft#2169 closed: Rust plugin improvements <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2169>
 * zyga has a bad test day
<zyga> or bad network day maybe
<tomreyn> hi there. i just read https://github.com/canonical-websites/snapcraft.io/issues/651 and https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store and am wondinerg whether embedding (privacy impacting) trackers is currently (1) considered acceptable (b) tested for and (c) how it's being handled, if at all.
<tomreyn> from my POV this is a major issue on android, and mostly unhandled / unsolved (or rather accepted) there. so i'm wondering whether what the situation with snaps is.
<tomreyn> s/on android/on the google play store/
 * zyga sees the same error mvo saw
<zyga> that took a while, let's fix it
<mup> PR snapcraft#2170 closed: rust plugin: fix cargo builds and run tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2170>
#snappy 2018-06-26
<mborzecki> morning
<zyga> o/
<mup> PR snapd#5178 closed: interfaces/builtin: initial version of the anbox-support interface <Complex> <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/5178>
<mborzecki> we're at 41 PRs :(
<mup> PR snapd#5253 closed: snap: introduce new fields for parallel snap installation <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5253>
<mborzecki> mvo: shall I land #5384 ?
<mup> PR #5384: tests: update interfaces-timeserver-control to core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5384>
<zyga> re
<zyga> sorry, I was hacking late last night
<zyga> just waking up now
<zyga> looking now
<zyga> merging
<mup> PR snapd#5384 closed: tests: update interfaces-timeserver-control to core18 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5384>
<pstolowski> mornings
<mvo> mborzecki: yeah, if it has the needed +1 please
<mvo> thanks zyga
<mvo> pstolowski: good morning
<mborzecki> pstolowski: hey
<zyga> hey mvo
<zyga> I fixed the layout issue you ran into
<zyga> I will get myself into shape and send a patch
<mvo> zyga: nice
<mvo> zyga: what was it?
<zyga> re
<zyga> it was just this
<zyga> but I want to still tweak this
<zyga> I don't like the fact that it is allowed to fail
<zyga> https://www.irccloud.com/pastebin/xXb1dxKK/
<zyga> I also don't get it why it failed for you in particular
<mvo> zyga: interessting
<zyga> essentially, path ending in / is "bad"
<zyga> let me try to make it okay without this hack
<jamesh> zyga: hi.  do you have any suggestions on how to move forward with this branch? https://github.com/snapcore/snapd/pull/5271
<mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
<zyga> jamesh: hey!
<zyga> jamesh: let me look please, I don't recall
<zyga> hmm
<zyga> it has two +1s
<zyga> I'm a bit sleepy over late hacking but my gut feeling is that I will ask mvo or maybe mborzecki to look at it and then let's land it
<zyga> mvo, mborzecki ^
<mvo> zyga: sure
<mvo> I have a look in a wee bit
<jamesh> zyga: I think the main concerns are about behaviour on OpenSUSE, where the too-old xdg-desktop-portal and partial AppArmor support means it has the potential to reduce security
<zyga> jamesh: on old opensuse there's no strong security
<zyga> and on tumbleweed there's recent everything
<zyga> I think we are fine on this front
<zyga> jamesh: for context, I enabled apparmor on tumbleweed last week
<zyga> but it is not enabled on any any leap release yet
<jamesh> zyga: https://software.opensuse.org/package/xdg-desktop-portal shows too-old xdg-desktop-portal for all OpenSUSE releases
<mup> PR snapd#5392 opened: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5392>
<zyga> jamesh: and we require 0.11?
<jamesh> zyga: 0.11 is the first version with snap support, yes.
<zyga> Mmm
<zyga> Let me ask if 0.11 is coming to TW anytime soon
<mborzecki> zyga: can you take another look at #5311 i've pushed some fixes hopefully it'll be green before cachio wakes up
<mup> PR #5311: tests: start active system units on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5311>
<jamesh> zyga: the issue was that on OpenSUSE, where we had file-level AppArmor confinement but no D-Bus mediation it the old versions exposed everything registered with the document portal
<jamesh> the D-Bus APIs aren't much more or less secure in 0.10 vs 0.11 in this case.
<zyga> mmm
<zyga> well
<zyga> well, at least we would have nicer UX since snaps would be detected
<jamesh> my preferred solution would be to just add "Conflicts: xdg-desktop-portal < 0.11" to the OpenSUSE spec file
<jamesh> so things things work when the new version rolls out, but we don't let people install insecure portals together with snapd
<zyga> jamesh: 0.11 is not submitted to factory yet
<zyga> jamesh: mmm
<zyga> jamesh: but that could mean arbitrary amount of time
<zyga> and also on leap that will be never
<jamesh> or 15.1 maybe
<zyga> perhaps, but I don't know the package update policy
<zyga> jamesh: what should we do if this lands to master with this constraint (on packaging)
<zyga> won't this block spread testing?
<jamesh> zyga: at the moment we don't have any spread tests running against a full portal stack, so it hasn't been a problem yet
<zyga> but won't this block the installation of the package?
<zyga> I mean, if we put a constraint on a package that's not in the archive yet
<zyga> all of suse spread testing will stop
<jamesh> zyga: we never try to install the xdg-desktop-portal package in any of the tests
<zyga> ahh
<zyga> I see what you mean
<zyga> although
<zyga> if the portal package is installed by default anywhere this might be a problem
<jamesh> https://flatpak.org/setup/openSUSE/ seems to indicate it isn't installed by default
<zyga> ok then
<zyga> but let's add this constraint to TW only
<jamesh> (I can't think of a reason for xdg-desktop-portal to be installed currently if flatpak isn't)
<mup> PR snapd#5393 opened: strutil: add PathIterator.Rewind <Created by zyga> <https://github.com/snapcore/snapd/pull/5393>
<mup> PR snapd#5394 opened: strutil: support iteration over almost clean paths <Created by zyga> <https://github.com/snapcore/snapd/pull/5394>
<zyga> mvo: ^ this should fix the issue you ran into
<mup> PR snapd#5395 opened: don't review / don't land: just testing <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
<jamesh> zyga: I imagine we could do some real xdg-desktop-portal spread tests in future, by using a fake version of the org.freedesktop.impl.portal.* D-Bus interfaces to avoid depending on a GUI
<jamesh> zyga: fwiw, it doesn't look like there is any of xdg-desktop-portal or flatpak in SLES, so presumably they are more free to update those packages in point releases
<zyga> jamesh: I don't know much about SLES, I tried to build snappy for SLE 12 but failed on missing build dependencies
<zyga> I need to take the dog out now, it's almost 10:30 !
<mvo> zyga: looking, thanks
<jamesh> zyga: from what I can tell, OpenSUSE Leap is a combination of some packages taken directly from SLES, and some others layered on top.  My point was that it looks like xdg-desktop-portal is one of those packages not from the Enterprise distro, so easier to update
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/5395/files#diff-485a172e36d1bd329b385818efa017b6 :)
<mup> PR #5395: don't review / don't land: just testing <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
<zyga> jamesh: ah, I see
<zyga> jamesh: yes, I hope so, I will ask if anyone is interested in making that upate
<zyga> in the end I can package it too :)
<zyga> pstolowski: that path is a variation of the very first layout issue you found
<pstolowski> zyga: nice
<mvo> zyga: I will run the layout integration test with your PR5294
<Chipaca> mo'in peeps. I'm going to be online but working on paperwork (taking a day off in hr for this crap). Shout if you can save me from the drudgery.
<Chipaca> (boss-man still needs to approve though so it's tentative for now :) )
<mvo> Chipaca: good luck
 * mvo hugs Chipaca 
 * Chipaca hugs mvo
<Chipaca> I thought I had everything but they've added columns Â¯\_(ã)_/Â¯
<Chipaca> anyhoo
<zyga> Chipaca: take care and be careful with typos
<mup> PR snapd#5393 closed: strutil: add PathIterator.Rewind <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5393>
<zyga> mborzecki: I chose not to add a 2nd constructor because we can always do that and YAGNI for now
<mborzecki> zyga: ack
<mup> PR snapd#5394 closed: strutil: support iteration over almost clean paths <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5394>
<mborzecki> pedronis: hi, niemeyer suggested changing StoreName() to InstanceSnap() in #5370, i thought about doing it in a followup PR so as not to pollute this one, but i'll squeeze it in the current one instead just to save on time
<mup> PR #5370: overlord/{config,snap}state: introduce experimental.parallel-instances feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370>
<niemeyer> mborzecki: This one PR is quite short and is where the functions are being introduced.. seems better to just do it there
<niemeyer> mborzecki: Or do you mean everything else "StoreName"?
<pedronis> niemeyer: that my question too?  are we changing   snap.Info.StoreName  to snap.Info.InstanceSnap ? that is a bit strange
<mborzecki> niemeyer: the functions were introduced in #5363, but the diffstat is small 38 lines changed
<mup> PR #5363: snap: introduce the instance key field <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
<niemeyer> pedronis: No, that's strange indeed
<niemeyer> pedronis: "Name" would be the most natural there still
<mborzecki> SnapName() then?
<niemeyer> mborzecki: Or that..
<pedronis> SnapName() is what the assertion uses
<pedronis> so there is precedent
<pedronis> the issue is that we have snapName around the code base quite a lot
<pedronis> those in many cases
<pedronis> instanceName now
<pedronis> but don't think we have done a rename
<niemeyer> It's a different reason, but yeah, sounds okay to avoid "Name" being too obvious for cases we really mean InstanceName
<niemeyer> pedronis: Yeah, we've been doing mainly the method, but left the vars behind
<niemeyer> We can rename to instName or similar shortly.. I think as long as we have a strong convention we can easily fix
<pedronis> yea, we can do a clean up
<pedronis> it's 950 places
<pedronis> but that can wait a bit
<mborzecki> hm that would make a one large diff
<pedronis> yea, I don't think you want to do it now, in that PR
<pedronis> it's not urgent
<pedronis> the methods are a more pressing issue
<mborzecki> so we have StoreName(), InstanceSnap(), Snap() (?), SnapName()
<pedronis> we do hae Snap() methods and they tend to return  a *snap.Info
<pedronis> I'm personally ok with snap.Info.SnapName
<mborzecki> ok, let's do snap.Info.SnapName() then, i'll push it to that PR to avoid another one
<niemeyer> mborzecki: Let's please not do it in that PR
<niemeyer> mborzecki: That PR is reviewed and unrelated
<niemeyer> mborzecki: If you push more changes into it, the changes already reviewed and unrelated are blocked
<mup> PR snapd#5396 opened: many: rename snap.Info.StoreName() to snap.Info.SnapName() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5396>
<mborzecki> niemeyer: pedronis: ^^
<mborzecki> i'll be landing 5370 when it becomes green
<niemeyer> +				RealName: snapInfo.SnapName(),
<niemeyer> Nice
<mborzecki> niemeyer: yeah, it reads nice too
<niemeyer> mborzecki: LGTM with just one detail tehre
<pedronis> mborzecki: lunch here, I can look after
<mborzecki> pedronis: sure, enjoy your lunch!
<mborzecki> niemeyer: thanks, pushed
<mborzecki> heh hit econnreset again
<mborzecki> what if we built in a rate limiter in http download and limit it to say 1MB/s in that particular test?
<mborzecki> there's juju/ratelimit package, which is already available in fedora/debian/ubuntu
<zyga> mborzecki: how would that work?
<mborzecki> zyga: stuff a rate limiting writer in the pipeline between reading from the body and writing to the disk
<zyga> we could do that for an unit test
<zyga> I don't understand how we could do that in a speread test
<mborzecki> zyga: add the writer, into the pipeline if some env flag is set, eg SNAP_DEBUG_HTTP_RATE
<zyga> mmm, yes that could work
<zyga> it might be even more generic
<mborzecki> low tech but well
<zyga> snap set snapd.throttle.downloads=100KB/s
<zyga> ish :)
<pstolowski> could we maybe limit the rate by a QOS rule instead?
<mborzecki> heh, i'd rather do go code  than touch tc :P
<mborzecki> but yeah, that's another option
<mup> PR snapd#5329 closed: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>
<pstolowski> mborzecki: man iptables-extensions - hashlimit looks promising
<pstolowski> mborzecki: i prefer not to modify code for tests (if i've a choice)
<mborzecki> pstolowski: isn't that just for matching?
<pstolowski> mborzecki: yes you're right. yeah, tc might be the way to go
<mborzecki> i can play with this a little
<pstolowski> mborzecki: this article confused be about iptables - https://making.pusher.com/per-ip-rate-limiting-with-iptables/ - it seems he is using iptables + hashlimit to -j DROP packets when reaching limits
<pstolowski> s/be/me
<pstolowski> might not be the best way, but perhaps simple enough for the test
<pstolowski> mborzecki: actually, perhaps we could applay iptables rule right at the start to simply kick in after x MB, instead of injecting it in a racy way
<mborzecki> that could work
<mborzecki> let me check it
<pstolowski> yay, my usb2uart adapters arrived
<pstolowski> going for lunch & to collect them
<zyga> mvo: hey
<zyga> mvo: around?
<mborzecki> btw. fresh debian-9-64, 2018/06/26 10:59:48.646131 store.go:1555: DEBUG: Download succeeded in 6.997s (77MB/s).!!
<pstolowski|lunch> mborzecki: wow!
<mborzecki> subsequent downloads closer to 100MB/s - 99, 96, 95
<mvo> zyga: almost on my way to lunch, what can I do for you?
<mvo> pstolowski|lunch: we could also simply make snapt-test-huge bigger, I can double it
<zyga> mvo: just wanted to ask if we should do one more patch, to translate explicit "core" to "snapd" on API requests, when snapd is the interface host
<zyga> mvo: this would fix tests that do "snap disconnect foo:network core:network"
<mvo> zyga: it sounds sensible, when you say api request you mean web api?
<zyga> mvo: I mean daemon/api.go
<zyga> mvo: though this would really happen in the interface manager
<zyga> mvo: I'm trying to asses what is the next blocker for core18
<zyga> if this is vague I can still hop onto another task that is close to completion and return to core18
<zyga> (later)
<mvo> zyga: can we use a lower layer for the translation than daemon/api.go?
<zyga> yes, I would probably only do this in the interface manager
<zyga> or even perhaps in the repository itself
<zyga> since that makes it immune to state changes
<mvo> zyga: that sounds good, +1 from me
<zyga> ok, super
<mvo> zyga: cool, I get lunch now
<zyga> ok
<zyga> hmm
<zyga> I think we really really really need to update snapd in sid
<mup> PR snapd#5370 closed: overlord/{config,snap}state: introduce experimental.parallel-instances feature flag <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5370>
<mup> PR snapd#4996 closed: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4996>
 * zyga had to clean the kitchen sink, to filter the water, to fill the water tank, to make the coffee 
<zyga> talk about kitchen debt ;)
<zyga> jdstrand: good day
<mborzecki> pstolowski|lunch: heh, no tc for us, i'm policing the ingress taffic, tc can't do that
<mborzecki> pstolowski|lunch: got something ready, will be opening a PR soon(ish)
<mborzecki> pstolowski: i'm actually slowing down all ingress traffic to 512kB/s, this will give us plenty of time to apply the rule in output chain
<mup> PR snapd#5397 opened: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5397>
<pstolowski> mborzecki: nice
<zyga> woah
<zyga> nice work man!
<zyga> let's see how it works :)
<mborzecki> heh, yeah ;) hope it works
<pstolowski> niemeyer: hey, do you agree with my comment re ForbiddenCommandError https://github.com/snapcore/snapd/pull/5326/files/ee3e078f94ba5ee11b5515eddabd40b9d1859c05#diff-82e84d8ad7fc634fbd6d18b5b61c4273 ?
<mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<sergiusens> mvo: can you make `core` a valid base? or is that something Chipaca would normally do?
<mvo> sergiusens: you mean type: base?
<sergiusens> mvo: if I create a snap with `base: core` it is uninstallable
<zyga> woah
<zyga> interesting
<jdstrand> hey zyga :)
<sergiusens> probably because core is mixed thing and not really a base so it would need quirking or some sort of transition
<zyga> jdstrand: hey :)
<zyga> jdstrand: I sent https://github.com/snapcore/snapd/pull/5395 today
<mup> PR #5395: interfaces: generalize writable mimic profile <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
<zyga> I'm actually a little ashamed because I ended up not using the chopTree function in it, we can think about that
<jdstrand> ok
<zyga> or just move the docs over to this PR and drop chopTree
<zyga> some of the way the rules look was made deliberatetely so that they read nice top-to-bottom
<zyga> the code could be slimpler without this
<mup> PR snapd#5383 closed: tests: tweaks for running the main tests on core18 <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5383>
<zyga> I will also send updates to the adb support interface
<zyga> I also recall that we had some issues with /proc/1/ns/mnt
<zyga> and there's one case now that seems to be a good bet of what the issues is, using a vanilla kernel on ubuntu to support new hardware
<zyga> I will give that a try but likely only tomorrow
<zyga> jdstrand: apart from that nothing urgent, I'm trying to wrap up things ahead of a bigger change to the interface manager
<mvo> sergiusens: aha, right - I think we need core16 for that
<mup> PR snapd#5358 closed: tests: add spread test to ensure snapd/core18 are not removable <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5358>
<mvo> sergiusens: let me see if I can create this
<niemeyer> pstolowski: I'm not sure I understand what you mean there
<niemeyer> pstolowski: The ForbiddenCommand type is not being used anywhere other than during instantiation
<niemeyer> pstolowski: So when you say you need the type, where?
<pstolowski> niemeyer: i mean in the error check in api.go: if e, ok := err.(*ctlcmd.ForbiddenCommandError); ok
<niemeyer> pstolowski: Ah, I missed that indeed, sorry
<niemeyer> pstolowski: Yes, +1 on your suggestion
<pstolowski> niemeyer: okay, thanks. in the original PR I (ab)used ForbiddenCommand for that by implementing Error()
<jdstrand> zyga: ok. istr there was an issue I said I was surprised wasn't on your list before I left, and you said you'd add it. I don't recall otoh what that was...
<pstolowski> zyga: can you take 2nd look at https://github.com/snapcore/snapd/pull/5326 when you have moment?
<mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<jdstrand> zyga: 07:37 < jdstrand> zyga: I was surprised to see that the 'profile not found' issue was not on your list. it seems I see at least once a day an issue where someone is hitting it
<zyga> jdstrand: I don't have the hard facts yet, either the reporter I'm talking to will provide them or I can run a mainline kernel on my laptop and compare
<jdstrand> ok, so that was on your list today. great
<zyga> jdstrand: yeah, I recall that, this is why I'm giving you an update, we seem to have more information now
<zyga> it's clearly related to a mainline kernel
<jdstrand> zyga: nice! I'm not even close to caught up on emails yet
<zyga> what is curious is that this hasn't happened in opensuse tumblweed with apparmor that I used for much of my work last week
<zyga> so either opensuse took more patches (which is possible and I think jj mentioned that in the  presentation he gave at a suse conference)
<zyga> or there's more to it :)
<mup> PR snapd#5396 closed: many: rename snap.Info.StoreName() to snap.Info.SnapName() <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5396>
<rbasak> How do I run snapcraft from its source tree? According to HACKING.md calling bin/snapcraft should just work, but I get https://pastebin.ubuntu.com/p/RsKtZ448nk/. Setting PYTHONPATH to the top of the tree doesn't seem to work either. Something to do with looping round through snapcraftctl?
<mborzecki> mvo: zsh in non interactive shells uses /etc/zsh/zshenv
<rbasak> I'm not using virtualenv if that matters.
<mborzeck1> my link has died for a minute there
 * cachio afk
<mvo> mborzecki: thank you
<mvo> mborzecki: there is no .d mechanism, right?
<mborzecki> mvo: not that i'm aware of
<mvo> mborzecki: yeah, thats slightly sad that we can't plug into anything
<zyga> pstolowski: ack
<zyga> (I'll review it next)
<zyga> quick break
<mup> PR snapcraft#2166 closed: project_loader: replace dict keys as well as values <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2166>
<zyga> re
<zyga> mvo: snapd reexec in debian is ok
<zyga> pstolowski: hey, about those serial ports you got
<zyga> how stable are they?
<zyga> and do they have serial numbers
<zyga> I also thought about a case we didn't discuss
<pstolowski> zyga: stable? in what sense? no idea
<zyga> imagine you re-plug a device, snapd understands that it is the same device we had before
<zyga> pstolowski: but linux level things changed about it (e.g. different device path)
<mup> PR snapd#5398 opened: tests: disable auto-refresh test on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5398>
<mup> PR snapd#5399 opened: tests: moving install of dependencies to pkgdb helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5399>
<zyga> oho, storm is coming
<mup> PR snapd#5400 opened: spread.yaml: enable main and regression suite on core18 systems <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5400>
<kyrofa> rbasak, try using a venv
<pstolowski> zyga: yes, a valid scenario. we will find out a change in attributes and recreate the slot + re-estabish connections (if any). that assumes however we have a serial or can construct an equivalent of serial
<pstolowski> zyga: i've just checked 2 adapters, one has serial (and it's not just zeros), the other doesn't
<zyga> ha
<zyga> cool
<zyga> I'm glad you have that
<mup> PR snapd#5401 opened: [RFC] asserts: add (optional) kernel-track to model assertion <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5401>
<mvo> zyga: thanks
 * cachio lunch
<mup> PR snapd#5402 opened: i18n: handle write errors in xgettext-go <Created by mvo5> <https://github.com/snapcore/snapd/pull/5402>
<mup> PR snapd#5403 opened: many: use extra "releases" information on "revision-not-found-error" to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
<mup> PR snapd#5404 opened: i18n: add canary checking to pot file extraction <Created by mvo5> <https://github.com/snapcore/snapd/pull/5404>
<mup> PR snapcraft#2171 opened: {catkin,python} plugin: support cleaning <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2171>
<mup> PR snapd#5405 opened: tests: do not mask errors in interfaces-timezone-control <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5405>
<mup> PR core18#41 opened: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
 * cachio afk
<mup> PR snapcraft#2168 closed: build_providers: add ssh key managemet to the qemu build provider <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2168>
<ogra_> mvo, is it wanted that setting a proxy adds a line without newline at the end to /etc/environment ?
<ogra_> ogra@pi2:~$ cat /etc/environment
<ogra_> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
<ogra_> http_proxy=localhost:8080ogra@pi2:~$
<mvo> ogra_: hm, the missing newline sounds like a bug
<mvo> ogra_: hopefully harmless
<mvo> zyga: fwiw, the layout test with the latest master http://paste.ubuntu.com/p/nTqd6c4Zwc/
<zyga> Is it reproducible?
<mvo> zyga: not sure, probably on core18 but I can run again once the current run is done
<zyga> Ah
<zyga> Wait
<zyga> Is /var/spool in Core18
<zyga> mvo: can you try with https://github.com/snapcore/snapd/pull/5395
<mup> PR #5395: interfaces: generalize writable mimic profile <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
<mvo> zyga: heh, you mean, maybe we don't have it
<mvo> zyga: let me check
<mvo> zyga: http://paste.ubuntu.com/p/6cSTxzWw4Z/
<mvo> zyga: I can try 5395 after the current run
<zyga> OK
<zyga> I left the house now, need to buy some food. I will try after Iâm back
<mvo> zyga: not urgent at all
<zyga> re
<mup> PR snapd#5406 opened: i18n: merge xgettext-canary and xgettext-robustness <Created by mvo5> <https://github.com/snapcore/snapd/pull/5406>
<mup> PR snapd#5406 closed: i18n: merge xgettext-canary and xgettext-robustness <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5406>
<mcphail> ondra: if I use your openhab snap on a pi3, should I also install your pi3-openhab gadget snap? If so, how do I "activate" that? (The documentation on gadget snaps is terribly opaque)
<mup> PR snapd#5407 opened: tests: add fedora to distro_clean_package_cache function <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5407>
<mup> PR snapcraft#2172 opened: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172>
<kyrofa> zyga, I'm having trouble running snaps in lxc on my desktop: cannot remount /tmp/snap.rootfs_nMP7A9/var/lib/snapd/lib/vulkan as read-only: Permission denied
<mup> PR snapcraft#2173 opened: tests: create basic integration test spread infrastructure <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2173>
<kyrofa> niemeyer, eventually as the build VM stuff stabilizes, we'd like to test it in spread. Looks like google supports this (https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances), but it needs to be enabled
<kyrofa> Since it can be done via the API, is that a switch spread can throw for us?
<kyrofa> (perhaps it already is?)
#snappy 2018-06-27
<mborzecki> morning
<mborzecki> i ran #5397 job 7-8 times now, only one econnreset error, but unrelated to the fix we made, the test got 503 when trying to download the snap what looked like some store side hiccup
<mup> PR #5397: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5397>
<mborzecki> i have seen the mounting squashfs error reproduce a couple of times, and at least one other error which i do not recall seeing before in tests/main/validate-container-failures
<mborzecki> i'll be merging the PR when the travis job becomes green again
<mup> PR snapd#5408 opened:  i18n: use xgettext-go --files-from to avoid running into cmdline size limits <Created by mvo5> <https://github.com/snapcore/snapd/pull/5408>
<mup> PR snapd#5407 closed: tests: add fedora to distro_clean_package_cache function <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5407>
<mborzecki> and opensuse downloads flaky too :(
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> I am heading to school for some errands. I will be back in an hour
<pstolowski> mornings
<mborzecki> pstolowski: heya
<pedronis> mvo: hi,   #5403 uses #5386 :)
<mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
<mup> PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <https://github.com/snapcore/snapd/pull/5386>
<mvo> pedronis: *cough* sorry and thank you
<mborzecki> pedronis: hi, could you take a look at https://github.com/snapcore/snapd/pull/5387 ? :)
<mup> PR #5387: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5387>
<mborzecki> this unblocks some unit tests for snapstate
<pedronis> mborzecki: will look in a little bit
<mborzecki> pedronis: thank you
<pedronis> mvo: are you looking at 5403 atm ?   wondering if IÂ should merge or squash merge 5386
<mvo> pedronis: not looking at it right now
<mup> PR snapd#5386 closed: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5386>
<mup> PR snapd#5409 opened: tests: run "arp" tests only if arp is available <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5409>
<pedronis> mvo: IÂ squashed it, and rebased 5403
<zyga> I signed up my son to a new school
<zyga> Heading home soon
<mvo> pedronis: ta
<mup> PR snapd#5397 closed: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5397>
<mup> PR core18#42 opened: hooks: port 008-etc-writable.chroot from core16 <Created by mvo5> <https://github.com/snapcore/core18/pull/42>
<mvo> zyga: http://paste.ubuntu.com/p/q87HDCzFqp/ <- this is a failure I see right now on core18 with the interfaces on core PR. I guess this is what you meant yesterday when you said we also need to translate the API calls?
<pedronis> mborzecki: looks good, left a comment
<mborzecki> pedronis: thanks, looking
<mborzeck1> heh and gnome died again, it's probably somethign with nvidia
<mborzeck1> the host is not responding over the network
<mborzeck1> but the cursor overlay works, pff
<ondra> mcphail install just openhab-ondra, gadget was only in case you need to use some specific usb dongle
<ondra> mcphail if you are not planning to use any usb, then no need for gadget
<ondra> mcphail if you want to use some usb device, share with me pid and. vid of that device I will add it. It exposes serial interface slot so you can connect plug from openhab to it
<mup> PR snapd#5410 opened: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
<Chipaca> moin moin
<pedronis> Chipaca: hi
<Chipaca> pedronis: 'sup
<zyga> mvo: looking
<pedronis> Chipaca: mainly #5403  and reviewing stuff
<mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
<zyga> mvo: yes, exactly that
<pedronis> Chipaca: and IÂ pinged you here:  https://github.com/snapcore/snapd/pull/5386#discussion_r198392974
<mup> PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5386>
<zyga> mvo: I think it's a bit of a weirdness but we should do it
<zyga> mvo: not just because of our tests
<zyga> mvo: but perhaps of scripted interactions in the wild
<zyga> mvo: muscle memory or bash history
<zyga> mvo: I was thinking where to translate that
<zyga> mvo: the repository itself is nice but perhaps too naive
<zyga> mvo: the disconnect will work but I'm not sure about the connection state, as there are other translation points in the interface manager
<zyga> mvo: nothing hard, just something I need to look at
<mvo> zyga: yeah, I agree it should work
<mborzecki> pedronis: regarding https://github.com/snapcore/snapd/pull/5387#discussion_r198401006 i can do the instanceName == info.InstanceName() in MockSnapInstance/mockSnap but i need to set instance key in mocnSnap for mount/file locations to be correct, unless i pull the common part to say mockSnapFiles and duplicate the info parsing bits in MockSnap & MockSnapInstance (which I'd like to avoid)
<mup> PR #5387: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5387>
<mvo> zyga: I guess the question is at what layer to translate
<Chipaca> pedronis: answered your ping there
<zyga> sorry for being late btw, we had to do some paperwork to move our son to a new school
<Chipaca> pedronis: did you answer mvo wrt when architecture would be used, or should i?
<zyga> mvo: I think we should translate in the interface manager
 * Chipaca hugs zyga 
<zyga> mvo: because that captures both connection state and repository connection
<Chipaca> zyga: PAPERWORK IS AWESOME
<zyga> hey Chipaca
<zyga> hahaha
<zyga> Chipaca, the recovering paperwork addict
<mvo> Chipaca: he pointed me to the PR that actually uses this
<Chipaca> mvo: fair
<mvo> Chipaca: so I think its fine
<mvo> zyga: ok
<pedronis> it is used quite a bit
<zyga> mvo: if you want I can look in a sec
<zyga> let me just commit something quickly
<pedronis> Chipaca: anyway your review of #5403 when you can would be appreciated
<mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
<zyga> Chipaca: did you reach the origami phase where instead of filling in the forms you just fold them
<Chipaca> pedronis: yep, on it
<zyga> and daydream
<Chipaca> zyga: so, one change in the hostilization of this process that bit me and delayed me was that they changed from 'list any absences longer than 60 days' to 'list any absences' (ie trips out of the country)
<Chipaca> zyga: the table had three rows
<Chipaca> zyga: so you had to continue it on a separate sheet
<zyga> oooh
<zyga> I would go to jail if they asked me to fill in all the places I've been to correctly
<Chipaca> so I filled one side of the separate sheet with all the info, turned it around to carry on â¦ and there was a hand-drawn comic on it
<Chipaca> so i guess they're getting an original piece of art together with this sumission
<zyga> haha :)
<zyga> fridge magnets help
<Chipaca> (it's all got to be handwritten of course, because this is the nineteenth century)
<Chipaca> anyhoo. I'll put that away for now and review stuff :)
 * Son_Goku groans to life
<zyga> good morning
 * Chipaca passes Son_Goku the mate
 * Son_Goku wobbles
<zyga> Son_Goku: maybe some quick shot of vodka to wake you up ;-)
 * zyga hides
 * Son_Goku runs away
<Son_Goku> ...
 * Son_Goku ambles back
<Son_Goku> zyga, have you made any progress on implementing the base snap creation to Oz?
<zyga> no, I need to schedule that and really work on it soon
<zyga> Son_Goku: I have fedora on w510 now so I can work natively on this
<Son_Goku> :D
<zyga> (and quake, that doesn't help)
<Son_Goku> hah
<zyga> that game really is fun, it plays surprisingly well on the trackpoint
<Son_Goku> well, they _were_ a lot more common when Quake 1 was a fresh game
<zyga> I would like to sync about flock and plan when we should deliver stuff
<Son_Goku> yeah
<zyga> also flock is where, I suspect, we can get most of this ready
<Son_Goku> well, Mohan Boddu is interested in syncing with us on this at Flock
<Son_Goku> most of the releng team will be there at Flock
<Son_Goku> Mohan hit me up this week and was curious about our progress
 * Son_Goku waves to sabdfl_ 
<zyga> that's cool, I think we should not come to flock empty handed
<Son_Goku> it'd be nice to come to Flock with _something_, yeah
<Son_Goku> we already mechanically understand what's needed for a base snap
<Son_Goku> so I don't see a reason why oz cannot make one
<zyga> yeah, I agree
<zyga> I think it's mostly figuring out the architecture of oz and friends to do this
<zyga> do you think we will be able to reuse any of the shell scripts?
<zyga> or will this all involve writing new code
 * Son_Goku wishes GitHub wasn't being unresponsive right now
<Son_Goku> what shell scripts?
<Son_Goku> we don't have any for making fedora base snap
<Son_Goku> there is _a_ python script I wrote to make one
<Son_Goku> but I think the answer is generally going to be no
<zyga> I mean, those scripts
<zyga> I also have some
<zyga> ok
<Son_Goku> we probably are going to need to adapt this to Fedora tooling, which means a kickstart definition for the base snap, and an imagefactory target for it
<pedronis> zyga: IÂ looked a bit at #5369,  it's nice it is short,  it's not super obvious it's correct/maintainable tough, it seems somewhat disperse
<mup> PR #5369: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5369>
<Son_Goku> zyga: https://pagure.io/fedora-kickstarts/tree/master
<Son_Goku> the fedora-docker-* ks files are probably a good starting point
<zyga> pedronis: thank you, do you have any ideas on how to improve it?
<pedronis> zyga: well, tbh, IÂ don't understand even if   snap connect for core interaces works there and how :)
<pedronis> I have a question about that there
<mborzecki> pedronis: pushed a fix
<zyga> pedronis: I think mvo and me discussed that operations against explicitly named core snap don't work yet
<zyga> implicit operations work fine
<pedronis> because of the guessing?
<mup> PR snapd#5411 opened: many: remove core-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5411>
<zyga> yes, the guessing knows about snapd now
<zyga> it has priority if it exists (the snapd snap)
<zyga> for explicit we need to add one more translation point in doConnect and doDisconnect
<pedronis> zyga: anyway it sounds we would need some helpers around manipulating conns
<zyga> mvo: I opened an RFC to drop core-support
<pedronis> so it's clear  snapd cannot get in there
<zyga> pedronis: that's a good idea
<zyga> pedronis: I can propose some and then the translations can happen in a single spot
<zyga> mvo: I don't know if it will pass spread, let's wait and see
<pedronis> mvo: you have quite a few PRs open, anything in particular that I should review or re-review?
<mborzecki> Chipaca: when you're done with the paperwork, can you take another look at #5366 ?
<mup> PR #5366: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
<Chipaca> mborzecki: i'm reviewing 5403 right now, i'll get to that later
<mborzecki> Chipaca: thanks
<mborzecki> hmm got xdg-desktop-portals installed and it's showing popoup when runing unit tests
<mborzecki> haha 'Allow snap "some-snap" to open file "/tmp/check-935424627432528910/7"?'
<Chipaca> pedronis: pausing review of that for a bit, will come back to it later
<Chipaca> pedronis: (commented a bunch meanwhile)
<mborzecki> uhh it's the launcher
<Chipaca> mborzecki: I still think that just dropping "invalid instance key" is not nice
<Chipaca> mborzecki: in that it's gobbledegook
<mborzecki> Chipaca: invalid snap instance name?
<Chipaca> mborzecki: do we call it 'instance' anywhere in user-facing stuff other than this error
<Chipaca> like, does 'snap install --help' explain instances
<mborzecki> Chipaca: well the feature refers to them as instances, snap install uses (or will use) --instance when installing from file, other than that there's no explicit instance
<mborzecki> Chipaca: i can go with 'invalid snap name' or sth along these lines
<Chipaca> mborzecki: concretely: I suggest Â«invalid instance key %q (see 'snap install --help')Â», and adding a small paragraph to the install help that explains  them
<Chipaca> mborzecki: the feature description is not a user-visible document :)
<jack> Hi guys,
<pedronis> Chipaca: but we cannot really add a paragrah yet for something that is an incomplete experimental feature
<pedronis> I suppose mborzecki can add a todo there
<Chipaca> yes :)
<mborzecki> works for me
<Chipaca> a TODO is ok
<Chipaca> I can then hit him over the head with it at a later time
 * Chipaca orders a gross of TODO bludgeons off of amazon
<mborzecki> haha
<mvo> pedronis: thanks, most should be easy(ish), let me look for some harder ones
<Chipaca> mborzecki: when the help is written, we need to line up instance key vs name between error and help to avoid confusion also
<mvo> pedronis: 5392 would be nice
<mvo> zyga: thank you
<pstolowski> zyga: hey, #5326 when you have a moment, please
<mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<sam__> Hi guys, I have a java web application as war file it using tomcat server. Now i want to snap it. please someone guide me.
<zyga> I read it last night but I was too tired
<zyga> I will do it now
<mborzecki> Chipaca: pushed a patch with TODO note
<tomreyn> hi! i recently read https://github.com/canonical-websites/snapcraft.io/issues/651 and https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store and am wondinerg whether embedding (privacy impacting) trackers is currently (1) considered acceptable (b) tested for and (c) how it's being handled, if at all. from my POV this is a major issue on android's primary app ecosystem, and mostly unhandled / unsolved (or rather accepted) there.
<tomreyn> so i'm wondering whether what the situation with snaps is.
<zyga> hey tomreyn
<tomreyn> hello zyga
<zyga> I don't think we have any official policy about trackers in applications yet
<tomreyn> that's... a shame,
<zyga> we don't run applications as a part of the acceptance process, it is fully automated
<zyga> let me look at the policy that we have to be sure
<pedronis> Chipaca: IÂ answered two of your questions, will wait for more feedback
<zyga> tomreyn: I don't think the store has any written policy so far, or at least I cannot find any
<mup> PR snapd#5412 opened: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5412>
<mborzecki> trivial PR ^^
<zyga> tomreyn: I would recommend that you discuss this on the forum as it seems like a goal worth pursuing
<zyga> mborzecki: +1 but use Also
<zyga> so one restore less
<zyga> look at what MockCommand return value MockCmd can do
<mborzecki> interesting, will do
<zyga> tomreyn: discussions on IRC are immediate but actually miss quite a lot of the people that participate in snaps
<zyga> tomreyn: a thread on forum.snapcraft.io, in the store category, is the best way to ensure the key people read tihs
<tomreyn> zyga: thanks for checking. personally i don't think snaps a a goal worth pursuing so i'm not interested in investing time on improving the policies around it. hope you don't mind.
<mborzecki> zyga: pushed
<zyga> tomreyn: not at all, have a nice day :)
<tomreyn> thanks for your time, though.
<tomreyn> zyga: another question, if you have the time: is there a policy which defines which snaps get security support by canonical (in that canonical takes measures to ensure that known security vulnerabilities are overcome in a short amount of time, similar to how the ubuntu security team does it for the supported apt repositories)?
<zyga> yes, there is that
<zyga> may I ask why are you interested having said that snaps are not worth pursuing?
<tomreyn> oh, that's good. ubuntu 18.04 installs gnome-calculator as a snap by default, so i was hoping so.
<zyga> all snaps owned (as snap names) by canonical
<zyga> have secutity support guarantees
<Chipaca> zyga: all snaps with a for-stable-ubuntu branch also
<zyga> Chipaca: thanks, I didn't know that
<Chipaca> snaps installed by default are tracking an ad-hoc branch, not latest/stable, for this purpose
<Chipaca> at least that's my understanding :-) i haven't checked, not having an 18.04 to hand
<Chipaca> but, as I say, curious why tomreyn is simultaneously curious and incurious
<tomreyn> I can be curious about things I don't favor.
<Chipaca> tomreyn: yes :)
<Chipaca> tomreyn: but you said something like it 'not being worth your time', which is rather less than not favouring it
<zyga> tomreyn: snaps and similar efforst are an important part of application distribution, if you look at docker it's been very influential and has changed how many people work, deploy and use software.
<zyga> while you may dislike snaps or anything else, having sane, safe behavior for something used by many people is important to us
<Chipaca> I don't favour systemd, myself, but here we are :)
<zyga> *efforts
<tomreyn> zyga: sure, i'm happy to discuss my discontent with snaps. i like decentralized architectures, the snap store is centralized. i'm an open source enthusiast, snaps opens the door too widely to proprietary software. i also think that at this time, using snaps and debugging issues from a user perspective is badly documented, so it is difficult to know how to recover from issues.
<mcphail> ondra: that's great. thanks! (and thanks for the snap, too)
<zyga> tomreyn: ironically distributing open source software is really hard today
<zyga> much harder than proprietary software
<ogra_> tomreyn, it opens the door the same way for opensource SW
<tomreyn> the way it was introduced in ubuntu was quite intrasparant. the average user does not even know there ar enow two different mechanism to install packages and they would not know where to look for problems.
<zyga> I, as someone working on FOSS for about a decade now, really appreciate that software distribution is breaking away from the initial taxonomy-driven library model
<ogra_> and why would the user need to know that ? she just wants to use some software
<zyga> tomreyn: as with all new software, no matter how many times new things are announced, some poeple will be taken by surprise
<zyga> tomreyn: this is not unique to snaps, it's just how people deal witch change
<tomreyn> ogra_: that's correct, just, traditionally, debian, and also ubuntu, wasn't as embracing to proprietary software.
<ogra_> thats not true ... ubuntus focus was always "the best user experience" ... i.e. "linux for human beings ..."
<zyga> tomreyn: I think ubuntu was always driven by being nice to people and that includes being able to use the software that said people want to use, proprietary or not
 * zyga hugs ogra
<ogra_> we have shipped proprietary nvidia drivers from day one
<zyga> (we are not in the same room btw, :D
<ogra_> heh
<zyga> I'm in a park with my dog, working on a bench
<cjwatson> that's a new value of "one"
<zyga> and ogra is probably 1000km away
<ogra_> not even in the same country :)
<zyga> tomreyn: note that gnome-software has a mode now (not sure if released yet as we tend to see "git master" more often than not) where you can see just FOSS software
<zyga> tomreyn: that includes snaps
<tomreyn> zyga: i agree about the effects of introducing new technology. but don't you think more efforts should have been spent on educating users as to what these changes mean for them, and for how they need to manage their systems?
<zyga> tomreyn: I think that it is impossible to make everyone happe, I can bring some people here who will compain that I'm not addressing the issue they have, add the feature they want instead of documenting something
<zyga> tomreyn: the best way to ensure it is really the best software experience across linux is to help
<ogra_> but do you think someone using gnome-software actually *wants* to "manage their system" ? they just want an easy way to get their software
<zyga> become an advocate
<zyga> document, explain, educate
<zyga> point out issues, help address them
<zyga> help with the design and with bug fixing
<zyga> whatever you feel like doing or feel you are good at
<zyga> we are only a handful of people
<ogra_> if you really needs to be an admin and i.e. "manage your system" you probably dive deeper into the system anyway and will learn abouut snap as you will learn about debs
<zyga> we are not a mega-corp with 100M monthly budget on advertising
<tomreyn> sure, there is only so much time when you have limited resources available. i did not mean to blame you or anyone for not documenting things enough. things could probably have been smoother if there had been more people available to work on it.
<zyga> we cannot do everything ourselves
<zyga> exatly
<zyga> please feel welcome here
<zyga> join us
<zyga> the forum is a fantastic place to contribute
<ogra_> my mother, or sister definitely do not care about the mechanism how their SW is delivered to them as long as the apps start and run flawlessly
<zyga> no coding is needed
<zyga> you can document how snaps work, how they are different, you can make people see this
<zyga> the forum is being used to drive documentation pages
<zyga> (literally, certain posts just show up as documentation on other pages)
<zyga> so anything you contribute has immediate real vlaue
<zyga> *value
<zyga> and it is very good to be sceptical about it
<zyga> you are not the only one
<zyga> seeing how snaps operate, how the policy is made is the best way to keep people working on it as a day job honest
<zyga> so please, stay around, look around and see how you can help - this is how FOSS works
<tomreyn> thanks for the invitation. ;) i'll decline for now (since i'm still thinking that snaps will drive ubuntu in a direction i do not want to support), but maybe my mind will change in the future, you never know. and you placed a good seed there.
<zyga> in the meantime, I need to review a patch from a colleague
<tomreyn> thanks for your time.
<ogra_> cjwatson, did warty not have the drivers on disk (iirc they were shipped but a manual install was needed) ?
<mup> PR snapd#5413 opened: tests: purge packages installed by accounts, calendar, and contacts interface tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5413>
<zyga> tomreyn: one last question
<cjwatson> ICBW but I don't think they worked properly until hoary.  In any case it was a massive controversy when we started considering doing more stuff with them by way of compiz and the like
<zyga> tomreyn: do you have any software you made yourself that you share with others?
<cjwatson> so it's pretty ahistorical to say that Ubuntu has always been all the way over to one end of the spectrum; we've gone back and forth a lot
<ogra_> yeah, i do remember that ... but i thougth we always had restricted on the CD from the start
<ogra_> but i probably mis-remember and t was hoary ...
<ogra_> *it
<tomreyn> zyga: i contribute to an open source game, megaglest. but i didnt write it myself. it's a fork which i help manage / develop.
<cjwatson> ogra_: I *think* that was only since hoary
<ogra_> k
<zyga> tomreyn: are you involved in publishing aspect of that game?
<ogra_> so day "two" :)
<tomreyn> zyga: i have a voice in it. what's your point?
<cjwatson> oh look, I have warty images lying around
<zyga> tomreyn: did you try to ensure that the latest version of your game is available in debian, ubuntu, fedora and opensuse for example
<zyga> or that the bug you fixed is released there
<ogra_> i even have my original warty laptop ... but it is in some box in the basement :)
<cjwatson> they had restricted on the image, but no nvidia
<ogra_> ah
<cjwatson> linux-amd64-generic was in restricted for some reason
<zyga> people see snaps as some uneeded evil often don't have the first hand experience in delivering software across releases of one distribution, let alone across many
<ogra_> heh
<cjwatson> oh, no, nvidia-kernel-common was on the i386 install image
<zyga> I wanted to know if you have experience or stories about that
<cjwatson> but not amd64, presumably for reasons ...
<ogra_> amd64 was still young in 2004 ...
<zyga> pstolowski: so snapctl get as a regular user can read configuration of any snap?
<ogra_> i guess nvidia didnt provide 64bit binaries back then
<cjwatson> yeah, could well be
<cjwatson> the baseline architecture worked well but it was still considered slightly exotic
<ogra_> yep
<pstolowski> zyga: only *own* snap (needs a valid context, so needs to be run by an app itself)
<tomreyn> zyga: yes, it's a hassle if you want to be compatible to all or most linux distros and make installing and upgrading easy. if the software was more widely used i would probably spend time on packaging it using flatpack.
<zyga> tomreyn: maybe it is not widely used becaue it's not widely available due to packaging complexity?
<tomreyn> i don't think that's the case, no.
<tomreyn> Megaglest is in all major distros, and we don't get to see a lot of players. it's an old game with an old graphics engine.
<zyga> pstolowski: how do you define "own" snaps?
<zyga> pstolowski: I mean running "snapctl" outside of snap world
<pstolowski> zyga: by presence of context
<zyga> ah, isee
<pstolowski> zyga: (cookie)
<zyga> and without that?
<zyga> pstolowski: (review sent)
<pstolowski> zyga: without context snapctl get errors out (only -h flag will work)
<zyga> thanks!
<mborzecki> Download (curl) error for 'http://download.opensuse.org/distribution/leap/42.3/repo/oss/suse/x86_64/libcap-devel-2.22-18.16.x86_64.rpm':
<mborzecki> Error code: Curl error 52
<mborzecki> Error message: Empty reply from server
<mborzecki> ehh
<pstolowski> zyga: thanks for the review; okay, i see where your question comes from, i'll add a comment in the code, "as is" it may look scary at first
<zyga> I was thinking if we could grep for something and retry common apt/dnf/zypper/pacman/git operations
<mborzecki> #5412 super simple review, anyone?
<mup> PR #5412: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5412>
<zyga> merge it
<mup> PR snapd#5412 closed: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5412>
<tomreyn> zyga: so, i just reflected a bit more about my disappreciation, and to at least contribute *someething* to your efforts, i tried to condense the aspects i'm most hesitant about when it comes to snaps: privacy concerns: witht he classic apt repos i can tell pretty well that this software has received *some* level of review, and can mostly rely on this to prevent, for example, i install software which analyzes and tracks me / my use of it / the
<tomreyn> computer etc. with snaps, i don't have an easy way to tell where i can rely on things to be 'clean' of such issues and where not. the other aspect is security: there are two sub aspects here: for once, very much as for the privacy concerns i have, i also might install one snap but receive some bundled software i don't want, and i have no easy way to tell whether that's so or not. the other aspect is that while it's great that security updates
<tomreyn> can be shipped so easily - unless i can know what gets regular security updates and what doesn't, i can easily end up with software in a known vulnerable version, but no9t realize it.
<zyga> tomreyn: I am afk for a bit. I will reply when Iâm back
<tomreyn> sure
<ondra> mcphail feel free to ping me if I forget updating it, are you tracking stable or other channel?
<popey> ondra: automate the builds!
<ondra> popey I do consume product of one jenkins, which I do not have control over, so it's hard to automate fully
<ondra> popey I need some job periodically checking if there is new thing on jenkins
<mup> PR snapd#5414 opened: corecfg: added experimental.hotplug feature flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/5414>
<ondra> popey we will eventually get jenkins intergation there, but for that we need hotplug so openhab foundation is happy to adopt snaps, long storey :)
<ondra> mcphail BTW if you are in homekit camp, you might be also interested in homebridge snap
<mup> PR snapd#5415 opened: interfaces: moved normalize method to interfaces/utils and made it public <Created by stolowski> <https://github.com/snapcore/snapd/pull/5415>
<pedronis> mvo:  I did a pass over 5392
<zyga> https://www.irccloud.com/pastebin/BJ7ooq1z/
<zyga> tomreyn: ^
<ogra_> now ... that remonds me that i have to rebuild 4 of my snaps for the libssl CVE ... the store spammed me tonight i should do that :)
<ogra_> *reminds
<mvo> pedronis: thank you!
<mup> PR snapd#5416 opened: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
<mcphail> ondra: cheers. i've just installed the stable channel. i haven't poked it yet. i'm hoping i can replace my openhabianpi installation
<tomreyn> zyga: my response https://paste.ubuntu.com/p/gVWpdPFxrY/
<ogra_> tomreyn, your assumption is wrong, the centralized store does exactly that ... it auto-reviews every upload (and even monitors it during its lifetime)
<ogra_> and thats only possible with such a centalized model
<ogra_> the security model around snaps removes most needs for manual reviews (yet they happen for some special cases like gadget snaps or kernel snaps)
<tomreyn> ogra_: then how did the miner make it in there, and what about user tracking? maybe the automated review process is just not as good as a manual one?
<zyga> tomreyn: in reality, there is no manual review (anywhere) that is detailed, there is only trust and reaction in case of mistakes
<ogra_> it definitely isnt ... but do you think manual reviews in distros are any better ?
<zyga> nobody reads code in detail
<tomreyn> you probably want them both manual and automated, though
<zyga> and really nasty code can be obfuscated
<zyga> tomreyn: snaps make you trust the publisher (a specific entity) rather than the middle man
<ogra_> tomreyn, note that 90% of uploads to distro archives are not regularly reviewed either
<zyga> in both cases (distro and app store) there are ways to catch up with nasty software
<zyga> to block it, patch it out
<ogra_> a deb usually gets an initial review and then the developer uploads on hs own afterwards
<zyga> in reality there is not much difference there
<tomreyn> right, snaps make the user have trust relations to *many* publishers, which is overwhelming
<ogra_> well
<zyga> if you trust mozilla with firefox, use firefox as a snap, or as the tarball from their website, or as the deb in ubuntu
<ogra_> snaps rather make the user trust into the security model
<zyga> tomreyn: yes but that is _reality_
<zyga> tomreyn: in the past nobody really read code
<zyga> it's a myth
<zyga> it was just nicely packed into one big label ($Distro)
<zyga> I think that's not going to change much really
<zyga> what is different is now this is explicit (you know who gives you software)
<zyga> and you can get software from more authors than before (non-free software)
<zyga> and you can have some guarantees about how that software operates (sandbox)
<zyga> in reality there is no better model yet
<ogra_> tomreyn, btw ... thanks to the snap store otifying me i just invested 2x 2min to update 4 snaps (2 server packages, one VPN tool and a desktop app) to get the latest libssl fixes in ... that would have eaten hours of my day if the packages were not snaps
<ogra_> *notifying
<tomreyn> yes, there are clearly benefits in centralization.
<ogra_> also ... the miner is a totally valid thing ...
<ogra_> the fact that the developer did not mention it in the description was not valid though
<tomreyn> so a miner package which would say it is a miner and would just mine for a one hardcoded account would be fine?
<ogra_> i dont see a reason why the package format should deny maintainers to get money for the work they do ... a miner is a possible way to do that ... just not without telling your users about it in advance
<zyga> tomreyn: policy is not decided on IRC
<zyga> it's a process and it is done on the forum
<ogra_> tomreyn, sure, why wouldnt it ...
<zyga> tomreyn: in the end one thing is clear, there's no place for deception in software
<ogra_> tomreyn, its a very valid use-case to have an UbuntuCore image with a preinstalled miner snap to maintain your 10000 node miner farm with one-click
<tomreyn> then you'll need to discuss whether tracking users, probably unknowingly and against their will, is deception.
<ogra_> and in my personal opinion a miner is also a valid thing for a maintainer of opensource software to generate some income ... as long as the user knows in advance what she is getting herself into
<tomreyn> anyways, i do not want to distract you off your work any loinger. thanks for the fruitful (i hope) discussion.
<zyga> tomreyn: would you mind summarizing this conversation on the forum
<zyga> irc is not preserved as much
<ogra_> (beyond that fact that you can deny network access ofr a snap with one click or cmdline command)
<zyga> I'm sure many people will find that useful
<ogra_> yeah, that would be super nice
<tomreyn> zyga: that'd be me contributing to improving snaps, but, at leats so far, i'm not yet convinced that i want to do so. sorry for disappointing...
<zyga> too bad, maybe next time
<tomreyn> (you did bring up a couple things which will make me reconsider a few of my POVs though)
<tomreyn> thanks for that
<zyga> my point about the forum is that then this conversation is not specifically about you getting some answers but the whole community getting information
<zyga> about making sutff better for more than oneself
<mup> PR snapd#5366 closed: snap: helper for validating snap instance names <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
<mup> PR snapd#5387 closed: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5387>
<tomreyn> i will be happy to contribute to projects whose goals i share. ;-) you are welcome to reuse what i posted here and on the pastebin, both by paraphrasing or by quoting me.
<mup> PR core18#42 closed: hooks: port 008-etc-writable.chroot from core16 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/42>
<mup> PR snapd#5417 opened: image: block installation of parallel snap instances <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5417>
<mup> PR snapd#5402 closed: i18n: handle write errors in xgettext-go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5402>
<mup> PR snapd#5418 opened: overlord/ifacestate: get/set connection state only via helpers <Core18> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5418>
<mvo> a second review for 5361 would be great
<zyga> boo
<zyga> mvo: I already did that one
<mup> PR snapd#5390 closed: data: add systemd environment configuration <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5390>
<Chipaca> mborzecki: "ÑÐµÐ°ÑÐµ" is a favourite of mine to check for invalid names
<Chipaca> mborzecki: :-)
<pedronis> mmh, 50 PRs
<Chipaca> pedronis: working on it
 * Chipaca seems nitpicky and slow today, but still
<mborzecki> wow, 49, it was ~45 in the morning
<zyga> mvo: 5411 is green
<mvo> pedronis: my fault - but I have a lot of simple ones
<zyga> it's -377 and some comment changes that made it to +10
<pedronis> ovelord tests have become 30s long mmh
<pstolowski|lunch> pedronis: managers_test is responsible for that
<pedronis> need to dig a bit, seems a bit bad
<pstolowski|lunch> pedronis: (and i might have added to that with the retry-conflicts tests)
<cachio> zyga, hey, when you have a time, could you please take a look to #5343
<mup> PR #5343: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5343>
<zyga> sure
<zyga> cachio: merged
<cachio> thanks
<zyga> I left one comment though
<zyga> maybe you can squeeze that into some other PR
<mup> PR snapd#5343 closed: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5343>
<zyga> mborzecki: review on 5415
<zyga> er
<zyga> that was pstolowski|lunch sorry :)
<zyga> I'm reading your 5417 so I thought about you
<zyga> mvo: funny, same review points :)
<zyga> on 5415
<mvo> zyga: haha
<zyga> er
<zyga> 17
<mvo> pstolowski|lunch: 5415 looks like an easy one, just one suggeston from zyga missing afaict
<mup> PR snapd#5419 opened: [WIP] many: switch to account validation: unproven|verified <Created by pedronis> <https://github.com/snapcore/snapd/pull/5419>
<zyga> mborzecki: can you look at my comment on 5413
<mborzecki> zyga: hmm that's a bit unexpected
<mvo> zyga: I have a conflicting meeting today
<zyga> ack
<niemeyer> mvo, zyga, mborzecki: I won't attend the standup today.. have a conflict over it
<niemeyer> (in principle)
<zyga> ack
 * zyga tries to join
<pstolowski> pedronis: standup or other meeting?
<pedronis> conflict
<zyga> thank you
<pstolowski> zyga, mborzecki arch-linux-64:tests/main/interfaces-content failure https://api.travis-ci.org/v3/job/397340654/log.txt ; is this the same issue you mentioned earlier this week?
<mvo> zyga: did you see my earlier (last night?) paste of the test failure of the layout test on core18?
<mvo> zyga: it is reproducible, it happend on my latest test run as well
<abeato> niemeyer, hi, https://github.com/snapcore/snapd/pull/5309 needs another (hopefully final) round
<mup> PR #5309: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5309>
<niemeyer> abeato: Heya, looking
<abeato> great, thx
<zyga> mvo: I did, thank you
<zyga> mvo: how can I reproduce that, which branch to start with?
<mvo> zyga: please get https://github.com/mvo5/snappy/tree/core18-all-fixes-all-tests and then run "spread -v -debug ubuntu-core-18-64:tests/main/layout
<zyga> pstolowski: hmm, what's the failure there?
<zyga> thanks!
<zyga> pstolowski: I only see the snapd-notify error
<zyga> mvo: running now
<mup> PR snapd#5420 opened: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5420>
<zyga> pstolowski: those sysfs rules are interesting
<zyga> I was not aware about some of them
<pstolowski> zyga: i restarted the job shortly after; here is the error https://pastebin.ubuntu.com/p/RMyqtdzVzq/
<pstolowski> zyga: what sysfs rules?
<mborzecki> zyga: #5420 addresses snap-mgmt thing
<mup> PR #5420: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5420>
<mborzecki> also pushed some fixes for blocking parallel instances when preparing an image PR
<zyga> mvo: reproduced (with my extra branch, investigating)
<kyrofa> sergiusens, slack isn't connecting today, it seems. Are you able to?
<kyrofa> Until it starts working, I'm here if needed
<zyga> mvo: so
<zyga> mvo: I got this error
<zyga> https://www.irccloud.com/pastebin/taNSqyBH/
<zyga> this may not be the same error you got yourself
<zyga> it is also a bug in the test
<zyga> the test encodes assumptions about the base snap
<zyga> mvo: my suggestion is to change the test
 * cachio afk
<zyga> mvo: I will send you a patch shortly
<mvo> zyga: cool
 * zyga has flaky network with 27K photos being backed up today /o\
<mvo> zyga: not sure about the error
<zyga> mvo: the error I got may be different because I merged one of my layout fixes here
<zyga> mvo: this uncovered the assumption about base snap that just don't hold
<kyrofa> Oh, looks like slack is just down in general
<mvo> zyga: aha, ok
<mvo> zyga: I was looking at a different failure
<zyga> mvo: the failure you got is fixed by my PR
<zyga> mvo: so that's expected
<zyga> I just wanted to see if this is correct after
<zyga> vanilla master trips over the bug that this one fixes
<pedronis> pstolowski: we get  5+5 s just from the retries indeed
<pstolowski> pedronis: that's bad.. perhaps instead of settle we could wait the exact number of ensures
<zyga> mvo: hmm, interesting, this is slightly deeper than that
<zyga> mvo: the test is expected to run against the core snap
<zyga> mvo: but because this is a core system it dones't run against the core snap, it runs again core18 because on all-snap systems we don't pivot
<zyga> mvo: which I think is a deeper bug
<zyga> mvo: this means that on core18 sytems _all_ snaps run against core18, not core!
<zyga> which is a critical bug
<zyga> mvo: I switched networks, are you reading this, not sure if irc works now
<pedronis> pstolowski: not sure, anyway it's an area to touch again, at least IÂ see where the time comes from now
<mvo> xnox: hey, I filed bug 1778936 about the need to get a patch from xenial systemd back. I also added a debdiff, anything else I should do to ensure this is part of the next sru?
<mvo> zyga: uh, that sounds nasty
<mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <https://launchpad.net/bugs/1778936>
<zyga> mvo: let me look at that now
<mvo> zyga: I think you are right, I just did "snap run --shell test-snapd-tools.echo" and a cat /etc/os-release and its core18
<mup> PR snapd#5418 closed: overlord/ifacestate: get/set connection state only via helpers <Core18> <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5418>
<xnox> mvo, there is a systemd in-flight in the unapproved.
<xnox> mvo, is this a regression since xenial?
<xnox> mvo, =/ i hope i didn't drop anything else on the floor
<mvo> xnox: its a regression, to be fair we had hoped to get to a clean /etc by core18 but it did not work out ./
<xnox> mvo, horum
<mvo> xnox: I have not noticed any other regression
<xnox> i shall dig into the history of that then quickly
<mvo> xnox: fortunately the patch still applies almost cleanly
<mvo> xnox: it looks like it got dropped when yakkety opened
<mvo> xnox: there is no changelog entry, but with 230-1 it was dropped
<xnox> mvo, ah, which is before i started systemd maintainance. i guess pitti thought it will be all fixed and dropped it post-xenial.
<xnox> mvo, at one point systemd was in-sync in debian and ubuntu
<mvo> xnox: https://launchpad.net/ubuntu/+source/systemd/230-1 is what I was looking at  (diffhttp://launchpadlibrarian.net/261334051/systemd_229-6ubuntu1_230-1.diff.gz )
<xnox> nice
<mvo> xnox: I think he just hated it ;) but thats ok, its really not great that we haven't gotten to the clean etc
<xnox> mvo, do we need to talk about that in brussels?
<mvo> xnox: we need this before brussels
<mvo> xnox: oh, clean etc
<xnox> mvo, cause i think we never got around to finalising what needs to be in-distro / on-core to get this done.
<mvo> xnox: yes please
<xnox> mvo, yeah clean etc.
<mvo> xnox: +100
<mvo> xnox: I think it must be a combined effort of foundations,core,debian but I think the important thing is to start :)
<mvo> xnox: anyway, it won't happen for core18 so we have a bit of time but I will be really sad if we don't have it for core20
<xnox> ack
<mvo> xnox: ta
<mvo> zyga: https://github.com/snapcore/snapd/compare/master...mvo5:core18-use-core?expand=1 <- an integration test for the bug you just found
<kyrofa> sergiusens, snapcraft#2172 is all green
<mup> PR snapcraft#2172: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172>
<mvo> zyga: iirc we do something special on core, did you start looking into it?
<zyga> mvo: yes, I did
<zyga> thanks for the test, it's really simple
<zyga> I mean
<zyga> the bug
<zyga> we just need to talk about it
<mvo> zyga: tell me more :)
<zyga> we have two options
<zyga> option number one is this: detect core18 and treat it as classic (pivot root, etc)
<zyga> a bit hairy but keeps the core status quo
<zyga> option number two: drop all special casing, always pivot
<zyga> I prefer two but it may affect core in some way
<zyga> right now on core we don't do pretty much anything
<zyga> we unshare the mount namespace
<zyga> bind mount tmp and private /dev/pts
<zyga> and that's that
<zyga> so all production hacks are visible at runtime
<zyga> and all the real / is there
<zyga> we talked about this sometime in the past
<zyga> when you first added bases to snap-confine
<mvo> zyga: yeah, I think option (2) is better but more risky
<zyga> I said then that we should unify core and classic to behave like classic (for the purpose of mount ns)
<zyga> but chose not to do this then because we wanted to avoid the risk :)
<zyga> and impact on core itself
<zyga> I think we should do that again
<zyga> but try to fix it at the same time
<zyga> my memory is rusty but I think there's a real issue there
<zyga> that unification doesn't work for a real reason
<zyga> but I forgot that reason
<zyga> I will do a patch that detects booted base != "core" and uses classic semantics
<zyga> because this is a new slate
<zyga> so new issues rather than regressions
<mvo> zyga: +1
<zyga> and because this eventually puts us on a path where core is deprecated and core16 can be the special case (if we end up needing it)
<zyga> ok, I'll get to it now
<mvo> zyga: \o/
<sergiusens> kyrofa: no, slack no work, me fitter, happier, more productive, comfortable
<zyga> mvo: core16 and core will use the same os-releaes file, right?
<mvo> zyga: yes
<mvo> zyga: well, we could decide but that was the plan
<zyga> I think it must
<zyga> I was just checking and thinking aloud :)
<kyrofa> Hahaha
<kyrofa> sergiusens, amen
<pedronis> they need to be ideally identical in bits that snaps can see, or through snap-confine bind mounting stuff (from snapd for example)
<mvo> zyga: yeah, I think pedronis is right, we may need some other way to distinguish
<zyga> pedronis: I agree, it is just that now on core we don't pivot so today on core (bare "core" as boot snap) you see _everything_ that exists on the system, in general, not just what is in the core snap itself.
<zyga> so on a system that moved to core16 we can attempt to keep that
<zyga> but on a core18 system that runs a snap using core16 or core as base we cannot just get that for free, we need to hack things to behave this way
<zyga> some things about product hacks may leak but I don't know if that matters
<zyga> (as in on a real core system you may see stuff that you won't see on core18 with apps running against core16)
<mvo> zyga: lets start with the simple case and just remove the special handling on core18, i.e. on core18 it always behaves like on classic, we always construct the mount namespaces from the snaps
<mvo> zyga: i.e. on anything not old-core
<zyga> mvo: yes, I agree
<zyga> that's what I'm doing now
<mvo> zyga: \o/
<pstolowski> yay, my go-udev patch merged upstream
<zyga> nice :)
<mvo> pstolowski|afk: yay
<mup> PR snapcraft#2171 closed: {catkin,python} plugin: support cleaning <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2171>
<mup> PR snapd#5421 opened: tests: replace MATCH by grep to check users created for ubuntu core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5421>
<sergiusens> kyrofa: 2167 is a little larget than I thought it would be :-P
<kyrofa> sergiusens, ignoring the tests?
<kyrofa> sergiusens, snapcraft#2172 should be all good now
<mup> PR snapcraft#2172: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172>
<mup> PR snapd#5422 opened: devicestate: fix race when refreshing a snap with snapd-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/5422>
<kyrofa> Hey zyga, I'm having trouble running snaps in lxc on my desktop: cannot remount /tmp/snap.rootfs_nMP7A9/var/lib/snapd/lib/vulkan as read-only: Permission denied
<kyrofa> zyga, any ideas?
<zyga> oh, feels like a bug
<zyga> dmesg | grep DENIED
<kyrofa> Run that on the host or the guest?
<zyga> either, it is lxc
<kyrofa> zyga, [61955.378584] audit: type=1400 audit(1530126985.909:482): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-brave-drum_</var/snap/lxd/common/lxd>" name="/tmp/snap.rootfs_o6dcBz/var/lib/snapd/lib/vulkan/" pid=12945 comm="snap-confine" flags="ro, remount"
<kyrofa> zyga, this is a vanilla, confined container
<zyga> one sec
<zyga> hum
<zyga> is this a privileged container?
<zyga> this looks like a bug in lxd to me, why is it running snap-confine under its own profile?
<zyga> hmm
<zyga> stgraber: ^
<kyrofa> No, it's unprivileged. Just `lxc launch ubuntu:xenial -e`
<stgraber> kyrofa: what snap?
<kyrofa> stgraber, any, but that particular test was cla-check
<kyrofa> stgraber, happens when running any app
<kyrofa> stgraber, running on bionic, lxd 3.1 via snap
<stgraber> hmm, can't reproduce this here
<stgraber> running a xenial container on current lxd on bionic, then install hello-world or cla-check inside the container, both work fine
<kyrofa> Could it have something to do with my nvidia card?
<stgraber> getting a clean 18.04 install on a maas node now to see if that behaves differently
<stgraber> kyrofa: could be, yeah
<zyga> nvidia? how?
<stgraber> root@c2:~# hello-world
<stgraber> cannot remount /tmp/snap.rootfs_uuibb2/var/lib/snapd/lib/vulkan as read-only: Permission denied
<stgraber> on a system with an nvidia gpu
<kyrofa> Ah!
<kyrofa> zyga, just saw the word "vulkan" and took a leap
<zyga> yes, that part is related
<kyrofa> That's all I got :P
<zyga> but the question is, why did snap-confine not get an apparmor profile
<zyga> can you do this from inside the container
<zyga> sudo aa-status
<stgraber> kyrofa: anyway, a workaround you can probably use for now is "lxc config set NAME security.nesting true" which will unrestrict some mount operations
<zyga> stgraber: what does that do?
<kyrofa> zyga, sure thing: https://paste.ubuntu.com/p/55BMdHBfxy/
<stgraber> zyga: pretty much allows all mounts everywhere in the container which likely includes remounts.
<zyga> this looks fine
<kyrofa> stgraber, indeed, that seems to let the mount through and the app works
<stgraber> zyga: I suspect the denial is correct in that it's the underlying LXD apparmor profile which refuses the mount, not the snap-confine profile that's loaded on top
<zyga> stgraber: I see
<zyga> so the outer profile needs to allow this as well
<zyga> re
<zyga> I just had a silly incident with one of the random dev boards I had around started serving everyone new IP addresses faster than my router :P
<chiluk> something broke snappy gnome-calculator http://paste.ubuntu.com/p/dFJjCxpXpT/
<chiluk> how is this even possible?
<kyrofa> zyga, stgraber, so how does having an nvidia card result in a mount that is denied, while none of the other mount magic is denied?
<stgraber> kyrofa: probably because only that triggers some snapd hook for vulkan/gl stuff which apparently bind-mounts stuff and then does a remount,ro
<zyga> kyrofa: when you have nvidia we do more things
<stgraber> the remount,ro part is what apparmor denies
<kyrofa> Ah, so the bind mount is okay, it's the remount that's problematic
<stgraber> yep
<zyga> chiluk: are the two snaps connected?
<chiluk> nope ...
<chiluk> but I haven't screwed with any of the snaps.
<stgraber> it's safe for us to allow bind-mounts in general, remounts are more risky
<kyrofa> So what is the fix for this? Does snapd need to be doing something different?
<chiluk> and breaking the calculator is kind of a shit show..
<chiluk> zyga ... I could connect the two.
<zyga> chiluk: can you share "snap changes"
<zyga> kyrofa: the fix must happen in lxd
<chiluk> http://paste.ubuntu.com/p/rJX6bPYjBV/
<chiluk> zyga... I ran snap refresh today in hopes that there was an updated snap..
<kyrofa> zyga, what is the fix? Just allowing remounts. even though they're risky? Or something more specific?
<zyga> chiluk: and snap interfaces | grep gnome-calculator
<zyga> kyrofa: well, to allow this specific operation
<chiluk> zyga http://paste.ubuntu.com/p/gNWj9FDH5g/
<zyga> chiluk: it seems to be connected here
<zyga> gnome-3-26-1604:gnome-3-26-1604            gnome-calculator,gnome-characters,gnome-logs,gnome-system-monitor
<kyrofa> stgraber, can lxd allow snap-confine specifically to remount?
<stgraber> kyrofa: nope
<chiluk> zyga.. I believe you... and it's connected on my desktop as well, but the question still remains how did they get unconnected?
<stgraber> kyrofa: apparmor doesn't let you do per-process and even if it did, there'd be nothing preventing root in the container from calling a random binary snap-confine
<zyga> stgraber: what I don't undertand is how the host of other mounts/remounts we do is ok
<chiluk> I haven't explicitly been doing any snappy things..
<zyga> and this is not?
<zyga> chiluk: can you run: sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt
<zyga> chiluk: and then: cat /proc/self/mountinfo
<stgraber> zyga: I suspect the rest of the things you're doing is just bind-mounts or standard mounts
<zyga> pastebin the result and exit that shell to go back
<zyga> stgraber: interesting, let me check
<stgraber> zyga: I don't see any case where our profile would allow for remounts
<zyga> yes, that's the only place that we remount
<stgraber> I have a change here which allows specifically remount,ro and nothing else, but I'm not sure that this is actually safe, at least I very much doubt that it is for privileged containers
<chiluk> zyga http://paste.ubuntu.com/p/NjGJMYwkTx/
<zyga> stgraber: is this done at apparmor level, why is remounting something read-only not allowed
<stgraber> zyga: because remount is a fs operation, not a mount operation, so if you pass a bind-mount from the host and do remount,ro, now the path on the host is read-only too
<stgraber> zyga: which was a pretty simple DoS attack for privileged containers against their host
<zyga> stgraber: you can pass MS_BIND| MS_REMOUNT to specifically make the bind mount read only, no?
<zyga> and we don't do that!
<stgraber> right, you don't do that :)
<zyga> chiluk: can you finally paste /run/snapd/ns/snap.gnome-calculator.fstab
<zyga> chiluk: this should be enough
<zyga> stgraber: thanks, I will correct this shortly
<zyga> kyrofa: thank you!
<kyrofa> zyga, stgraber, thank you both!
<chiluk> zyga http://paste.ubuntu.com/p/JwbbwbFfcV/
<zyga> kyrofa: can you please drop a topic on the forum with basic info "lxd + nvidia = sad snappy"
<zyga> I will do the rest
<kyrofa> zyga, of course
<stgraber> kyrofa: make sure to mention the security.nesting workaround, that's not great but it works
<zyga> chiluk: can you do "snap list" and share the revision of gnome-calculator and the gnome platform snap
<chiluk> zyga see first pastebin
<zyga> ok, sorry, looking
<zyga> hmm
<chiluk> zyga... It still could be something I did, but that seems unlikely... I feel like other users will probably eventually hit this.
<zyga> let me read the mount table
<zyga> this is what snapd claims it did: /snap/gnome-3-26-1604/64 /snap/gnome-calculator/178/gnome-platform none bind,ro 0 0
<zyga> I'm checking if that's true
<zyga> curiously it doesn't seem to be true
<zyga> did this happen just now?
<chiluk> it's been happening for a few days.. I'm pretty sure it persists over restart.
<chiluk> I guess I could check...
<zyga> can you disconnect and re-connect that interface to see if this fixes it
<zyga> sadly we don't log much when that part fails
<chiluk> you mean run snap connect?
<zyga> yes, please disconnect and re-connect gnome-calculator:gnome-3-26-1604
<chiluk> snap connect gnome-calculator:gnome-3-26-1604
<chiluk> error: snap "core" has no "content" interface slots
<zyga> I think you need to spell both sides of the connection this time
<zyga> sorry
<zyga> it should tab-complete though
<chiluk> snap connect gnome-calculator:gnome-3-26-1604 gnome-3-26-1604
<chiluk> ^^ made it work.
<chiluk> as I expected.
<chiluk> but I don't care about fixing this for me.
<chiluk> I'm a little confused as to why it broke in the first place.
<chiluk> because I can't be the only one.
<zyga> can you jump into the mount ns
<zyga> and collect mountinfo again please
<zyga> same as last time (same commands)
<zyga> I would like to diff the two
<chiluk> http://paste.ubuntu.com/p/3yZmBfBB5C/
<zyga> thank you
<stgraber> zyga, kyrofa: https://github.com/lxc/lxd/pull/4704
<mup> PR lxc/lxd#4704: lxd/apparmor: Allow ro bind-mounts and remounts <Created by stgraber> <https://github.com/lxc/lxd/pull/4704>
<kyrofa> zyga, chiluk, just throwing this out there, but gnome-software has the ability to twiddle those as well, no?
<zyga> sure enough :/
<zyga> https://www.irccloud.com/pastebin/TevxFMh7/
<stgraber> this allows the read-only bind-mounts which you should be using for both priv and unpriv + allows ro remounts for unpriv
<zyga> kyrofa: yes but we _claim_ this is connected, we _claim_ it is mounted (snapd) and it's not
<zyga> so clearly something was broken
<chiluk> right...
<kyrofa> Ah interesting
<chiluk> how'd it get that way though?
<zyga> stgraber: I will fix this in snap-confine, I think it's clearly our mistake because lack of MS_BIND is confusing from an API POV
<zyga> chiluk: that's the question
<zyga> chiluk: if you can reproduce this please tell me, I'd love to know what happened
<zyga> chiluk: do you have any denials in recent history
<chiluk> yeah that's unlikely.
<zyga> sadly, as I said, snapd doesn't log this
<chiluk> zyga.. are you talking app armor?
<kyrofa> stgraber, wait, I thought ro remounts were unsafe since they set the host dir ro as well?
<zyga> chiluk: yes
<zyga> kyrofa: it's subtle
<zyga> kyrofa: we don't want to remount the filesystem
<zyga> kyrofa: we want to remount the bind mounted view
<chiluk> zyga syslog:Jun 27 15:00:44 groovy kernel: [233210.052692] audit: type=1400 audit(1530129644.316:573): apparmor="DENIED" operation="open" profile="snap.gnome-calculator.gnome-calculator" name="/home/dchiluk/Templates/" pid=20481 comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<zyga> guys it's 22:06 and I have snap-confine patches all over my screen, I need to take the dog out, take a shower and not hack much more
<zyga> chiluk: that's not related, so if that is the only denial you had I have no other ideas :/
<kyrofa> zyga, I think I understand what you need to change on the snapd side, I just don't understand that lxd PR, since it covers filesystem remounts, no?
<chiluk> zyga looking
<zyga> kyrofa: I think the lxd PR is a separate topic now, I'm not sure it is strictly speaking mandatory or safe (as stgraber explained earlier)
<zyga> if fixing snap-confine is sufficient to address this we should know soon (it will be in edge in about a day)
<zyga> but first
<zyga> dog/shower/sleep
<stgraber> kyrofa: note that I only allow those for unpriv containers where the kernel will not let them propagate to the host
<zyga> ah
<zyga> that's nice, I didn't know the kernel does that
<zyga> how does it decide?
<stgraber> by looking at the kuid tied to the original mount
<stgraber> if that doesn't match your kuid then you get EPERM
<stgraber> obviously that doesn't work for privileged containers as those run as real root and so you totally do have the right to go and mess with the host mount table
<chiluk> zyga nothing more about calculator or snap that seems relevant in the logs.
<kyrofa> stgraber, ah, interesting, okay
<chiluk> zyga nothing more about calculator or snap that seems relevant in the logs.
<kyrofa> stgraber, thank you for putting that together!
<chiluk> zyga if it's any consolation it looks like this machine was installed with 18.04 pre-release *(probably around beta stage)... maybe that's it.
<zyga> No chiluk, this happened since your last reboot
<zyga> This is purely volatile state
<sergiusens> kyrofa: we need to stop moving back and forth with our comm platform :-P But yeah, the code sans tests is quite large; I am not doing a light review and my state of mind right now also complicates things
<kyrofa> sergiusens, haha, I sent that ages ago! Slack is back up, we can talk there if you like
<kyrofa> Take your time on the review
<sergiusens> well, I would rather discuss here, until I have the urge to paste something :-P
<sergiusens> kyrofa: I setup matrix during the weekend and added elopio as I knew he was on, he told me you are his only other friend there :-P
<kyrofa> Works for me!
<kyrofa> Hahahahahaha
<sergiusens> kyrofa: if you dismiss my review I lose the ability to approve from the same pane :-P
<kyrofa> Oh I didn't actually realize that was a possibility in the first place. How fancy!
<kyrofa> Looking forward to that one landing. Not sure how some of this has been working
<mup> PR snapcraft#2172 closed: many: add shellcheck to static tests <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2172>
<sergiusens> kyrofa: ok, so first pass on #2167 is done
<mup> PR #2167: snapstate, devicestate: do not remove seed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2167>
<sergiusens> kyrofa: what do you think of making the <topic>: in the merge more functional instead of locational? Else you get "many:" for most things and it loses importance.
<kyrofa> sergiusens, yeah I think most of the time they're the same, sans many :P
<kyrofa> I'm good with that, I'll avoid many
<kyrofa> sergiusens, updated snapcraft#2167
<mup> PR snapcraft#2167: many: detect local source changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2167>
#snappy 2018-06-28
<mborzecki> morning
<zyga> Gry
<zyga> Hey
<mborzecki> zyga: hey
<mborzecki> zyga: can you look at #5421 there's something fishy there
<mup> PR #5421: tests: replace MATCH by grep to check users created for ubuntu core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5421>
<zyga> Yeah, in a moment. Barely waking up here
<zyga> We found a curious bug last night
<mborzecki> zyga: what curious bug?
<mborzecki> this one?
<zyga> First coffee
<zyga> I stopped working after 10PM again
<mvo> zyga: good morning!
<mvo> zyga: how can I help :)
<mborzecki> mvo: hey
<zyga> Hey :-)
<mvo> hey mborzecki
<zyga> All good just need to wake fully
<zyga> And we have a small patch to unbreak snappy in lxd
<zyga> I will send it in 20 minutes, just need to clean the kitchen to make the coffee
<mborzecki> coffee, splendid idea
<mvo> 5419 is probably an easy win, has one review already and looks pretty straightforward
<mborzecki> zyga: btw. that's my kde bug that caused no sound in hangouts: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg249018.html
<mvo> pstolowski|afk: good morning! when you have a chance, please check 5415, zyga has one suggestion there about the comment otherwise it is good to go (has two +1 etc)
<zyga> re
<zyga> ok, finally at the keyboard
<zyga> mvo: looking
<zyga> mvo: would you mind reviewing the apparmor change I sent a few days ago?
<zyga> I'll get a 2nd review from jamie
<mvo> zyga: sure, I'm just going over the list sequentially
<zyga> mvo: going back to front helps in making sure we don't starve old PRs
<mvo> 5409 is probably a super simple review btw
<mvo> zyga: yeah, good point
<mup> PR snapd#5404 closed: i18n: add canary checking to pot file extraction <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5404>
<mup> PR snapd#5419 closed: many: switch to account validation: unproven|verified <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5419>
<zyga> pedronis: https://github.com/snapcore/snapd/pull/5419#discussion_r198725202 (when you are around)
<mup> PR #5419: many: switch to account validation: unproven|verified <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5419>
<zyga> mvo: ^
<pedronis> zyga: ?
<pedronis> of course we need to signe the new assertion (which means using the root key, so probably will not happen until the september sprint)
<zyga> perhaps I'm reading the patch wrong
<zyga> when is assembleAccount called?
<pedronis> many places
<pedronis> but yes you are reading the patch wrong
<pedronis> is just changing what the accessors see
<zyga> ah, that's good then
<pedronis> we sign a text, not a struct
<zyga> yeah, I know that,
<zyga> I was worried that this is changing the data to be assembled into the text blob
<pedronis> ?
<pedronis> it changes only what comes out of the new Accessor
<pedronis> Validation
<zyga> ok
<pedronis> as the comment tries to explain is really about preexisting stuff
<pedronis> (until we can rev them)
<mup> PR snapd#5400 closed: spread.yaml: enable main and regression suite on core18 systems <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5400>
<zyga> mborzecki: commented on 5421
<zyga> I'm -1 on that
<mup> PR snapd#5398 closed: tests: disable auto-refresh test on core18 <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5398>
<mup> PR snapd#5322 closed: cmd/snap-confine: include CUDA runtime libraries <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5322>
<mborzecki> zyga: yeah, looks fishy, idk maybe something with the storage again
<mborzecki> zyga: if you look at the pastebin, the output that's logged there even matches
<zyga> mborzecki: yeah
<zyga> it is odd
<zyga> especially that this is a file
<mborzecki> hmm let me restart that travis job a couple of times
<zyga> I'll play with MATCH
<zyga> but first
<zyga> fix the lxd bug
<zyga> then finish coffee because I'm still fuzzy
<zyga> then MATCH
<mborzecki> fuzzy MATCH(ing)
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> hehe
<zyga> I'm very fuzzy matching today
<zyga> on the upside I managed to convince the kids to help a little
<mvo> zyga: help coding? good job man!
<zyga> haha
<zyga> I wish :D
<mvo> zyga: no playing with the MATCH bug please, lets first attack the two core18 issues
<zyga> mvo: that's fair
<zyga> mborzecki: all yours
<zyga> mvo: the lxd issue is tiny so I'll do that first if you don't mind
<zyga> then back to core18
<mvo> zyga: sure, I don't want to boss you around :)
<mvo> zyga: just a little ;)
<mup> PR snapd#5230 closed: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5230>
<mup> PR snapd#5423 opened: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/5423>
<zyga> mborzecki: this is something for you https://forum.snapcraft.io/t/lxd-snaps-nvidia/6134 :)
<zyga> mvo: can we remove 2.33 milestone now
<zyga> I don't know how to now that issues don't show up on github
<mborzecki> zyga: i'll check it before the standup, 18.04 host is good enough?
<zyga> yes
<mborzecki> ok
<zyga> mborzecki: but must use nvidia drivers and you need to perform the test in a container
<zyga> I would recommend that you perform a baseline test first
<zyga> to see the denial
<zyga> and then use patched snap-confine
<mborzecki> now got to find that usb with mu 18.04 install
<mborzecki> yay found it :)
<mborzecki> https://forum.snapcraft.io/t/search-by-common-id/6136 this involves some store work too?
<mvo> zyga: with https://github.com/mvo5/snappy/tree/core18-all-fixes-all-tests we are down to only a few failure: http://paste.ubuntu.com/p/FsTMHB6fFs/ - this is why I'm so keen to fix the snap-disconnect (i.e. route core: to system) and the core mount namespace
<zyga> mvo: I will have the latter done in ~ hour
<zyga> so I think today we may see all green on that PR
<mvo> zyga: the stop mode issue is still a bit mysterious, I think its a race but I don't know how to fix it yet
<mvo> zyga: but yeah, would be awesome to get it to green
<mup> PR snapd#5326 closed: api/snapctl: allow -h and --help for regular users <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<mborzecki> google:ubuntu-core-16-64:tests/main/snapd-notify seems to be failing overly frequently
<mborzecki> this test looks weird, any idea what it's about? all it's doing is systemctl status snapd.service
<Chipaca> moin moin
<Chipaca> hands up if you just messed up the last page of the paperwork and you need to take a break before reprinting it
 * Chipaca finally done except for this bit that's like a checksum of all the above
<Chipaca> then i print that and i'm off to the postoffice and then i'm DONE
 * Chipaca gets back to it
<mborzecki> hm i'll rework tests/main/snapd-notify to use systemctl show properties rather than looking for a debug message
<zyga> mborzecki: my gut feeling is, logging failure
<mborzecki> zyga: yeah, that's why looking at ExecMainStartTimestampMonotonic and ActiveEnterTimestampMonotonic makes more sense as it comes directly form systemd
<mvo> pedronis: re the wait-for-auto-connect review - you ask about s.overlord.Settle() there. what is your suggestions? I was thinking about using s.overlord.SnapManager().Ensure() but that does not mix well with the Settles() we use in the tests elsewhere. what is your suggestion here?
<pedronis> mmh
<pedronis> mvo: my problem is not so muchÂ Settle but the loop etc, why doesn't the old code don't work anymore?
<mvo> pedronis: settle never converges because auto-connect waits for the restart
<mvo> pedronis: so the change is never "done"
<pedronis> ?
<pedronis> let me check
<pedronis> something is different then
<mvo> pedronis: you mean settle should work?
<pedronis> yes
<mvo> pedronis: even if the change does not go into done state?
<mvo> pedronis: aha, ok. sorry, I was not aware of this, let me look
<pedronis> settle doesn't check for done
<pedronis> it checks for ensure scheduling
<mvo> pedronis: don't worry in this case, I can dig into this, I had the wrong assumption
<pedronis> mvo: btw, did we kill this test:  https://github.com/snapcore/snapd/blob/release/2.32/overlord/managers_test.go#L969  ?
<pedronis> we should maybe bring it back
<pedronis> no, still there
<pedronis> wondering what it does right now on master though
 * mvo nods
<mvo> pedronis: aha, so I think the issue is that doAutoConnect returns retry errors. and this means that the taskrunner will schedule runing this task in the future and this is what settle looks at (are there tasks scheduled to run pending). does that make sense?
 * Son_Goku groans to life
<mvo> pedronis: the TestInstallCoreSnapUpdatesBootloaderAndSplitsAcrossRestart works because the configure hook of core waits for a restart
<mvo> pedronis: I can make the test smarter and ensure that the wait happens in the right place (at the auto-connect task)
<Son_Goku> I guess it's more accurate that I was startled awake by thunderstorm...
<pedronis> mvo: no, I'm still not understand, we had tests like that before
<pedronis> mvo: remember the old code in setup-profiles was also like that
<mvo> pedronis: ok, let me dig some more then
<mvo> pedronis: I made the other test more targeted fwiw
<pedronis> mvo: anyway, maybe we are talking past each other, IÂ don't know how you are changing the other test
<mvo> pedronis: I think you are spot on actually. I think the difference is that in the old code we did not restart, we had a check that if the same core is installed as the core that was booted we ignore the restart
<mvo> pedronis: for core18 this is different right now (we can discuss if that is good or bad :)
<mup> PR snapd#5424 opened: tests/main/snapd-notify: use systemd's service properties rater than the journal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5424>
<pedronis> mvo: it's the snapd always restarts stuff?
<mvo> pedronis: its different because right now snapd in seeding mode is not fully installed but after it seeded itself it is fully installed, so it seems to make sense to restart into the fully installed one at this point
<mvo> pedronis: yeah, its the snapd that triggeres the restart
<pedronis> but the other test in managers_test
<mvo> pedronis: the core18 will not trigger a restart as we use the same check if the revision is the same we booted we don't restart
<pedronis> also has a restart
<pedronis> but Settle is enough
<mvo> pedronis: indeed, let me look what is going on there
 * Chipaca returns, triumphant
 * Chipaca looks up the spelling of "pyrrhic"
<mvo> pedronis: still digging but yeah, something is different, its strange the old and the new code use the same retry but in the old one it does converge not in the new
<mvo> pedronis: also strange - in both the new and old world the TestInstallCoreSnapUpdatesBootloaderAndSplitsAcrossRestart test works with settle
<mvo> pedronis: aha! found it - so the difference is that the old code only waited for "core" with setup-profiles. but the new code waits for all snaps that are in auto-connect to restart
<pedronis> mvo: yes, but  they are done in order
<pedronis> I'm still missing something
<pedronis> mvo: the first settle should stop after snapd or core
<pedronis> then you set the system as restarted and continue, no?
<pedronis> what am I missing
<mvo> pedronis: maybe something in the ordering is wrong, let me check
<mvo> pedronis: I see that both snapd and core18 are in doing state for auto-connect - which should not be the case, right?
<pedronis> yes
<pedronis> that seems wrong
<pedronis> something bad with the new snapd code
<mvo> pedronis: thanks, let me re-read the wait code
<mvo> pedronis: yeah, probably a missing WaitAll() in the new code
<pedronis> we should install in order snapd core18  kernel gadget  other snaps
<pedronis> all sequentially
<mvo> pedronis: indeed
<pedronis> mvo: good I insisted because seems there's a real issue
<mvo> pedronis: yes!
<mvo> pedronis: this also explains why the other test is fine
<mvo> pedronis: its probably a bug in the firstboot code only
<mup> PR core18#43 opened: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <https://github.com/snapcore/core18/pull/43>
<mborzecki> #5242 is a trivial review if anyone's interested
<mup> PR #5242: tests: new test for joystick interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5242>
<mborzecki> duh, wrong number
<mborzecki> #5424 is the trivial one
<mup> PR #5424: tests/main/snapd-notify: use systemd's service properties rater than the journal <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5424>
<mvo> pedronis: I pushed an update
<pedronis> ah
<pedronis> mvo: so, good, that was bad
<mvo> pedronis: yes, thanks for the persitance in getting to the bottom of it
<mvo> pedronis: there was also the unit test for the task ordering missing :(
<mup> PR snapd#5415 closed: interfaces: moved normalize method to interfaces/utils and made it public <Reviewed> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5415>
<pedronis> mvo: thx, some more small comments there but looks good overall
 * Chipaca reading https://forum.snapcraft.io/t/5685 very slowly
 * zyga hands Chipaca a copy of for extra fun https://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook-1c.2017.11.22a.pdf
 * Chipaca hands zyga the original documentation for tc
 * Chipaca notes it was only found in russian at first
<zyga> tc?
<Chipaca> zyga: traffic control
<mup> PR snapd#5417 closed: image: block installation of parallel snap instances <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5417>
<mborzecki> anyone willing to take a look at #5389 ?
<mup> PR #5389: snap: account for parallel installs in wrappers, place info and tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5389>
<Chipaca> mborzecki: bring it on
<mborzecki> Chipaca: thanks!
<mborzecki> hmm WatchdogTimestampMonotonic=0 on 14.04 with systemd 204
<mvo> pedronis: thank you!
<mvo> pedronis: I updated the pr again but no rpush with a review, need to have lunch now :)
<pedronis> mborzecki: after #5389 will there be still nore changes in the snap package itself?
<mup> PR #5389: snap: account for parallel installs in wrappers, place info and tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5389>
<pedronis> s/nore/more/
<mborzecki> pedronis: there'll probably be more, the orignal branches introduced some extra helpers and renames, but those can come in later when needed
<mborzecki> zyga: libzypp has download.max_silent_tries to auto retry downloads, i'm checking this now, if it doesn't break things i'll open a PR
<zyga> oooh
<zyga> yes please
<zyga> that's a fantastic feature
<zyga> (no pressure there apt/dnf)
<mup> PR snapd#5414 closed: corecfg: added experimental.hotplug feature flag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5414>
<mup> PR snapd#5425 opened: spread: increase the number of auto retries for package downloads in opensuse <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5425>
<mborzecki> zyga: ^^
<mborzecki> zyga: also if you could take a look at 5424 please
<zyga> done
<mborzecki> the tests are super frustrating today
<mup> PR snapd#5426 opened: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426>
<mborzecki> carved out another piece from parallel installs branch ^^
<zyga> mvo: ha
<zyga> mvo: did you think about this case: core18 system, snapd.snap, core.snap, you run an app that uses core.snap as base; which snap-confine is used? which snapctl is visible?
<zyga> cleaning up snap-confine made me realise this is a bit weird now
<pedronis> snapctl comes from where snap-confine comes
<zyga> mmm, well, it should
<zyga> but those are arranged differently
<zyga> snap-confine is selected by snapd on the outside
<zyga> snapctl is selected by snap-confine
<pedronis> yes
<zyga> and the logic is not the same
<pedronis> how can it be
<pedronis> snapctl is picked relative to snap-confine
<mborzecki> switching to ubuntu to check the lxd thing
<zyga> mmm? there's a bit of code in snap-confine that, if you are not using "core" as a base, does extra bind mounts
<zyga> this handles snap-confine but snapctl is in another place
 * zyga looks at what happens
<zyga> I think it's something to tidy
<pedronis> in that case uses_base_snap is true, no ? you said core18 and snapd present
<zyga> yes but that doesn't handle /usr/bin/snapctl as far as I can see
<zyga> it just does nothing for it
<zyga> there's a chunk of commented-out code there
<pedronis> mmh, IÂ thought snapctl was in /usr/lib/snapd
<pedronis> that is my confusion
<pedronis> we have code for that
<zyga> yeah, it'd be easier
<pedronis> https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L360
<zyga> could we ship a symlink /usr/bin/snapctl -> $libexecdir/snapd/snapctl
<zyga> yeah, I'm looking at the exact same code now
<zyga> anyway, I will add this to the core18 todo list for today
<pedronis> sounds something to discuss with mvo
<zyga> agreed
<mvo> zyga: which snap-cofine/snapctl - the one from core18. I think we want to ensure the tooling is in sync with snapd
<zyga>  yes
<zyga> mvo: let's HO if you want to chat quickly ahead of the standup
<mvo> zyga: sure
<mvo> zyga: I have a PR that moves snapctl into /usr/lib/snapd :)
<zyga> oh, that's great
<zyga> thank you for doing that
<mvo> zyga: one min, just preparing a cup of tea
<zyga> that's going to be a godsend
<zyga> mvo: I had a crazy idea just now
<zyga> snapd.deb that ships just snapd.snap + entrypoint
<mvo> zyga: yeah, its a fun idea to explore
<zyga> mvo: ready when you are
<mborzecki> zyga: lxd from snaps too?
<zyga> yes
<pedronis> mvo: looking at 5392 seems IÂ found an unrelated bug, left a comment there
<mvo> pedronis: thanks, I work on this
<mborzecki> zyga: dog slow container rootfs download, ~300kBps
<mborzecki> zyga: replace snap-confine inside the container right?
<zyga> yes
<zyga> and disable reexec
<zyga> and this will fail but that's fine, it will need an apparmor tweak that we can do as we see the denial
<mborzecki> ok
<mborzecki-ubuntu> btw, current master https://paste.ubuntu.com/p/7crJcmKcH7/
<zyga> I saw that too, I think this is timing/racy test
<mborzecki-ubuntu> zyga: https://paste.ubuntu.com/p/Q855YBK6nm/
<zyga> that's perfect, thanks
<zyga> can you change the apparmor profile for snap-confine
<zyga> I will tell you where
<zyga> hold on
<zyga> on line 269
<zyga> there are a few "remount ro" things
<zyga> change "remount ro bind" there
<zyga> reload and try
<zyga> thank you!
<mborzecki-ubuntu> yup trying it already
<mborzecki-ubuntu> zyga: i've edited snap-confine.real
<zyga> that's good
<mborzecki-ubuntu> zyga: https://paste.ubuntu.com/p/n9536fST8D/ hmm i should probably update lxd profile too
<zyga> no, not the lxd profile
<zyga> mborzecki-ubuntu: what's the profile you have now?
<zyga> as a sanity check
<zyga> copy paste the three lines
<zyga> and have a variant with and without remount
<zyga> in case the pattern requires all flags to be present
<zyga> but hmm
<ogra_> mvo, hmm, does the pi-config stuff of snpd check the existence of values in config.txt at all ?
<ogra_> ogra@pi2:~$ snap set core pi-config.gpu-mem-512=true
<ogra_> ogra@pi2:~$ snap set core pi-config.gpu-mem-512=true
<ogra_> ogra@pi2:~$ snap set core pi-config.gpu-mem-512=true
<ogra_> ogra@pi2:~$ tail -10 /boot/uboot/config.txt
<ogra_> device_tree_address=0x02000000
<ogra_> core_freq=250
<ogra_> dtoverlay=vc4-kms-v3d
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> seems it completly blindly appends lines to it
<zyga> mborzecki-ubuntu: let me know what you get and I'll be right back
<ogra_> (not sure if thats any different in stable, that pi runs edge atm)
<ogra_> uh ... even worse:
<ogra_> ogra@pi2:~$ snap set core pi-config.gpu-mem-512=false
<ogra_> ogra@pi2:~$ tail -10 /boot/uboot/config.txt
<ogra_> core_freq=250
<ogra_> dtoverlay=vc4-kms-v3d
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=true
<ogra_> gpu_mem_512=false
<ogra_> it doesnt toggle the existing value at all but just appends and append for each snap set call
<mborzecki-ubuntu> zyga: hm actually one denial is gone, if you look at the first log, there were to, one seemd like it's inside the container's namespace (?)
<zyga> what's the current denial you see
<mvo> ogra_: uhhh
<ogra_> yeah
<mvo> ogra_: let me check
<mborzecki-ubuntu> zyga: https://paste.ubuntu.com/p/n9536fST8D/ look below '<--- profile replaced --->' line
<zyga> and the app fails to start, correct?
<mborzecki-ubuntu> zyga: yes
<zyga> do you have the vanilla profile somewhere, can you diff before/after
<zyga> (and did you reload the profile (just checking))
<mvo> ogra_: hm,hm,we have tests that should ensure that things are not blindly appended but obviously reality disagrees, lets me find out what is going on
<mborzecki-ubuntu> zyga:  apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<zyga> the file inherit parts are harmless, I think
<zyga> only the last one is the problem
<mborzecki-ubuntu> zyga: http://paste.ubuntu.com/p/KwgWCRgskx/
<mborzecki-ubuntu> zyga: tha's inside the container
<ogra_> mvo, thanks, need a bug ?
<zyga> sorry my input froze
<zyga> mborzecki-ubuntu: the denial now is from lxd indeed
<zyga> that's interesting
<zyga> let me look at the conversation last night
 * ogra_ holds a flame under zyga's input
<mvo> ogra_: this is current edge I assume?
<ogra_> mvo, yeah, i havent tried stable ...
<mvo> ogra_: no worries
<ogra_> (i can if it helps though)
<ogra_> (after a meeting i'm currently in)
<mvo> ogra_: all good, just want to know if I can start with master when trying to reproduce
<ogra_> yeah
<zyga> mborzecki-ubuntu: I think next lxd will fix it
<zyga> https://github.com/lxc/lxd/pull/4704/files
<mup> PR lxc/lxd#4704: lxd/apparmor: Allow ro bind-mounts and remounts <Created by stgraber> <Merged by brauner> <https://github.com/lxc/lxd/pull/4704>
<zyga> mborzecki-ubuntu: can you re-write the profile again, so that snap-confine has just the extra "remount" there
<zyga> reload that profile
<zyga> and ensure this is consistent with the denial you had before
<zyga> and finally add that to the PR 5423
<zyga> that that should be it
<mup> PR #5423: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/5423>
<mborzecki-ubuntu> zyga: wonder if lxd with this patch is in edge already
<zyga> good idea, let's check :)
<zyga> I need to take Bit for a walk
<zyga> it's been too long already
<zyga> mvo: I'll share what I have after I'm back
<mup> PR snapd#5427 opened: configcore: fix incorrect handling of keys with nubmers (like gpu_mem_512) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5427>
<pedronis> away _
<mvo> ogra_: -^
<stgraber> mborzecki-ubuntu: it should be, yes
<mvo> ogra_: it just happens with key that have numbers in them
<stgraber> mborzecki-ubuntu: and I've included it in candidate too
<mvo> ogra_: still a bug of course, thanks for the report
<mborzecki-ubuntu> zyga: lxd (edge)    git-fe39a5a (7606) + snap-confine patch + apparmor profile update works
<mborzecki-ubuntu> stgraber: ^^
<ogra_> mvo, ah ! so i was just lucky to test the right key :)
<mvo> ogra_: precisely
<mvo> ogra_: the fix above should be fine, I look into removing the hand-made thing, I think we have a better library for this
<ogra_> i'll test once it merged
<mvo> ogra_: should be fine, I added a regression test (famous last words)
<ogra_> :)
<zyga> Thank you mborzecki
<mborzecki-ubuntu> zyga: now that MS_BIND is added, apparmor rules for gl{,32} and glvnd need an update too, right?
<zyga> Yes, all three
<niemeyer> mvo: On the go-check tweak, does the + at the end make sense for the case of the diff output?
<mvo> niemeyer: you mean when a struct compare fails? I can look into removing it, I think its redundant and looks a bit out of place
<niemeyer> mvo: I'm trying to understand the consequence, but I can't quite put my finger on it given the examples
<niemeyer> mvo: Line 90 at the very end of the PR diff looks suspect, though.. might be a consequence of it
<mvo> niemeyer: yes, thats a consequence
<niemeyer> mvo: The case demonstrated in the multiline test (TestMultiLineStringEqualFails) is super sweet, btw
<niemeyer> mvo: Okay, this is my last remark then
<niemeyer> LGTM otherwise
<mborzecki-ubuntu> https://paste.ubuntu.com/p/QYwPQhcFfz/ heh each time i run the unit tests a new error comes up
<mvo> niemeyer: thank you! on so many levels :)
<mvo> niemeyer: I will see how I can get rid of the "+" then in the output, iirc this is something that kr/pretty generates
<mvo> pedronis: I replied to your panic question in 5392 - happy to write another PR with a small unit test to be on the safe side
<pedronis> mvo: notice that that code could be used on classic
<pedronis> in that case there's no kernel and potentially no gadget
<mvo> pedronis: then we are missing a test, let me add one
<pedronis> mvo: yes, this is about classic mostly
<niemeyer> mvo: np, and thanks again for the feature. It'll be great to have this!
<mvo> pedronis: iirc we test the classic firstboot in a different place, let me dig into it
<niemeyer> mvo: I don't think the + comes from pretty
<niemeyer> mvo: See the format function
<pedronis> mvo: yes, but this would be a strange tests with a seed.yaml that is empty or has empty snaps  (not sure we have one like that)
<niemeyer> mvo: If it did come from pretty, we'd have the "..." added by the format function
<pedronis> mvo: we have one with no seed.yaml at all IÂ suppose
<mborzecki-ubuntu> zyga: i'll push to your branch
<pedronis> but maybe I'm misremembering
<niemeyer> mvo: But we don't.. it looks like a minor bug on the formatting itself
<mvo> niemeyer: aha, ok
<mvo> niemeyer: thanks again!
<niemeyer> mvo: The + makes sense for the string case (see the multiline example)
<niemeyer> mvo: We might even reuse the quote bool
<niemeyer> mvo: np!
 * niemeyer lunches
<mvo> pedronis: hm, firstboot_test.go has no test for classic. let me find those tests first then I will add it there
<zyga> Thanks mborzecki
<pedronis> mvo: I thought it had a couple
<mborzecki-ubuntu> zyga: and pushed
<mborzecki-ubuntu> zyga: also verified locally
<mvo> pedronis: maybe I'm just too naive, I was looking for MockOnClassic in this file
<pedronis> mvo:  TestPopulateFromSeedOnClassicNoSeedYaml
<mvo> pedronis: aha, there they are. thank you, I will add the test now
<mborzecki-ubuntu> our nvidia spread test caught that too, yay!
<pedronis> mvo: we have ClassicNoSeedYaml, we ClassicEmptySeedYaml I suppose
<pedronis> *we need
<mvo> pedronis: +1
<mup> PR snapd#5428 opened: devicestate: fix panic in firstboot code when no snaps are seeded <Created by mvo5> <https://github.com/snapcore/snapd/pull/5428>
<mup> PR snapd#5429 opened: osutil: import go-udev <Created by stolowski> <https://github.com/snapcore/snapd/pull/5429>
<mvo> niemeyer: you were quite right, a subtle thing in formatMultiLine, update, let me know if its to your liking
<mup> PR snapd#5430 opened: tests: enable new fedora image with test dependencies installed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5430>
<mup> PR snapd#5431 opened: interfaces: move ValidateName helper to utils <Created by stolowski> <https://github.com/snapcore/snapd/pull/5431>
<zyga> jdstrand: hey
<zyga> jdstrand: can you please look at https://github.com/snapcore/snapd/pull/5411
<mup> PR #5411: many: remove core-support interface <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5411>
<zyga> it has two +1s but I didn't merge it because I wanted you to see
<zyga> pstolowski: question
<zyga> why interfaces/utils vs just interfaces/
<zyga> is it an import cycle if we use interfaces?
<zyga> not a strong opinion, just curious
<pstolowski> zyga: yes, i think i replied to that
<pstolowski> zyga: cause interfaces/hotplug/... needs to import interfaces
<zyga> thanks, this makes sense
<popey> jdstrand: heads up, I just moved interfaces and assertions from the github wiki to the forum.
<zyga> popey: interesting, thank you!
<mup> PR snapd#5423 closed: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5423>
<zyga> mvo: comment on 5428
<zyga> mvo: comment on 5427
<mvo> zyga: yay, thank you
<mvo> zyga: will work on it right after dinner
<pstolowski> nooo, our checks don't like formatting of go-udev
 * zyga hugs mvo
<zyga> pstolowski: can we add an exception
<zyga> so that it is not checked
<zyga> alternatively
<pstolowski> zyga: i just did
<zyga> go-fmt and send it upstream :)
<zyga> it's only a patch
<zyga> if they take it, it would be easier
<sergiusens> mvo: did you have any luck with core16?
<sergiusens> mvo: (or maybe zyga), why are xXX revisioned snaps read by root only?
<zyga> sergiusens: hmm, no idea
<sergiusens> in /var/lib/snapd/snaps I mean
<zyga> well
<zyga> right
<sergiusens> can they be made 644?
<zyga> the files are probably made this way
<zyga> I don't think this is deliberate actually
<zyga> Chipaca: ^ do you know why we chmod og-rw locally installed snaps?
<Chipaca> zyga: we don't
<Chipaca> zyga: at least, I don't think we do
<Chipaca> zyga: it's just the defauts for tempfile
<sergiusens> I just think it is on how the copy logic works out, but it is a bit of a pain to inject snaps with this in place
<Chipaca> to be fair, who cares? :-)
<Chipaca> sergiusens: why do you care?
<sergiusens> Chipaca: we inject the local snaps into containers and into build VMs to not download again and to have the same version on the outside and the inside
<Chipaca> sergiusens: ok
<sergiusens> so, yes, we do care
<Chipaca> sergiusens: no, you don't
<Chipaca> sergiusens: or at least, your explanation hasn't explained to me why you do :-)
<sergiusens> speaking of caring, can we make `snap install foo` not fail (with a --wait switch maybe) if there are pending auto refreshes?
<Chipaca> sergiusens: haven't we had this conversation about 'snap watch --last=auto-refresh' ?
<sergiusens> Chipaca: you had, but niemeyer said we should fix that
<Chipaca> that == what?
<Chipaca> not having it fail?
<sergiusens> Chipaca: snap watch --last=auto-refresh
<sergiusens> there's a chance for a race there too, isn't there?
<Chipaca> of course
<sergiusens> between that command returning and calling the new one
<zyga> Chipaca: just an idea "snap install --queue foo"
<zyga> it would wait for all conflicts to resolve and install
<Chipaca> conflicts is about to get a thrashing
<zyga> we could have a concept of idle tasks
<zyga> those are picked up when snapd does nothing
<Chipaca> zyga: stahp
<zyga> just making hand-wavy things
<zyga> can I wave some more
<Chipaca> zyga: stop hand-waving more stuff on when we're trying to simplify it
<zyga> I can also hold my hands above my head like a particular well-known Dilbert boss ;)
<zyga> the idea is really simple ;-)
 * zyga shutups
<sergiusens> Chipaca: and for the permissions thing, I want to avoid this ugly logic https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/lxd/_containerbuild.py#L285
<Chipaca> sergiusens: it finally clicked what you're trying to do
<Chipaca> sergiusens: (why is that doing chown and not chmod?)
<Chipaca> sergiusens: so
<Chipaca> sergiusens: there's no strong reason for them being 0600
<Chipaca> sergiusens: but, we can fix it
<Chipaca> sergiusens: but, fixing it retroactively would be trickier
<sergiusens> Chipaca: I am rewriting that to just do a copy/chmod; but I will not change ownership of files I do not own on my own :-)
<Chipaca> sergiusens: that is, even if the next snapd shipped made local snaps be 0444, you'd still need to handle snaps you can't read
<sergiusens> Chipaca: fix it for the future, build VMs introduced will use this and that is where I care it is ok, by then snapcraft will be fine
<Chipaca> sergiusens: but, feel free to chmod them meanwhile
<Chipaca> no chown, just chmod
<sergiusens> Chipaca: I'll keep the logic, but that sudo request is annoying and would be nice to make it a corner of a corner case
<sergiusens> well, permissions or ownership me no touch
<sergiusens> at the point in that snippet I shared it doesn't really matter as it is operating on the copy
<niemeyer> I also don't get what the problem is
<Chipaca> niemeyer: the problem is that snapcraft runs as the user
<Chipaca> niemeyer: and it tries to copy locally-installed snaps into the vm
<Chipaca> niemeyer: but it can't read them because they're 0600
<Chipaca> sergiusens: may i suggest, meanwhile: sudo cp --no-preserve=mode
<niemeyer> sergiusens: How do you run the vm?
<Chipaca> OTOH maybe snapcraft can talk to lxd and tell it to mount the snaps directory directly
<Chipaca> no copying \o/
<niemeyer> Chipaca: It's qemu, but yes, that's the idea
 * Chipaca decides it's beer o'clock
<Chipaca> brb
<niemeyer> mvo: go-check PR is in
<niemeyer> Thanks again
<pstolowski> zyga: a bunch of formatting/nakered/spelling errors in go-udev. for now i fixed a few locally, added one exception and will propose a fix upstream but don't want to block on that for next few days (thus fixing them locally right now)
<zyga> yeah, that's sensible
<zyga> let's add an exception and fix what we can upstream
<niemeyer> pstolowski: As long as we keep track of the delta, sounds good
<zyga> I'd be surprised if upstream complained about typo fixes and use of go fmt
<pstolowski> yep, the guy has been very friendly so far
<sergiusens> niemeyer: running the VM (for now with sudo), but it is an open still
<niemeyer> sergiusens: Right.. it uses sudo, runs as root.. should be easy to, at least for now, expose the snap directory
<niemeyer> sergiusens: As 9p
<niemeyer> I would rather not change the snap permissions
<niemeyer> As it encourages fiddling with backing data which does not have a well defined API
<Chipaca> niemeyer: fwiw snap permissions are rather accidental right now
<Chipaca> niemeyer: from store, they have 644, whereas local are 0600
<Chipaca> also snapd on master (on my machine right now) refuses to stop (?!?)
<niemeyer> Chipaca: Ah, that sounds buggy indeed
<niemeyer> Chipaca: On both counts :)
<zyga> Chipaca: snapd --stubborn
<Chipaca> systemd ends up kill-9ing it
<zyga> only until snapd controls systemd (evil laughter)
<Chipaca> zyga: I object
<zyga> Chipaca: in soviet russia, snapd ships you ;)
 * zyga really gets back to work
<Chipaca> zyga: you think systemd is hated, imagine if canonical had done it
<zyga> yes
<zyga> lennart would work for us and we would be universally hated (by the people who love to hate)
<zyga> Chipaca: also at that rate systemctl would contain snapd by now
<Chipaca> niemeyer: to be clear: would you be ok with a change that made all snaps be 0444, or would you prefer they all be 0400?
<niemeyer> Chipaca: I don't have a strong opinion there
<niemeyer> Chipaca: Other than we should fix the inconsistency
<Chipaca> niemeyer: as I can't really 'fix' ioutil.TempFile to take a mode, and this is relatively minor (in that if the power goes out and the chmod is lost it's not a huge issue) i'll just add a chmod to the end of install and be done with it
<niemeyer> Chipaca: I guess the argument of hiding them is weak as well.. one might argue about the case of private snaps, but these are mounted with their contents exposed anyway
<niemeyer> Hmm.. although the perms are under the publisher's control
<Chipaca> niemeyer: snap download tho
<niemeyer> Chipaca: In theory that wouldn't give access to private snaps to which one doesn't have access
<Chipaca> niemeyer: so you're concerned that a user that doesn't have root should not necessarily be able to read the files in a private snap
<niemeyer> Chipaca: Yeah, it's something we haven't really accounted much for so far
<Chipaca> mhmm
<niemeyer> Chipaca: The private snap can control its internal perms.. it cannot control whether the snap file itself is made public
<Chipaca> but i agree if that's something we care about, that'd be the reason to make it 0400 instead of 0444
<niemeyer> Chipaca: Makes the case for 0400 a bit more interesting
<Chipaca> or just 0600
<niemeyer> Yeah
 * cachio afk
<Chipaca> ok. 0600 everywhere is a one-line change (two because i'd add a comment). 0444 everywhere is bigger, but i've already got it
<Chipaca> i'll shelve it until tomorrow so you can ponder this in the background
<niemeyer> Chipaca: Thanks!
<Chipaca> np
<Chipaca> if we decide 0600 everywhere is the right thing, sergio is going to be sad
 * Chipaca hugs sergiusens 
<mvo> niemeyer: yay, thank you!
 * Chipaca very EOD
<sergiusens> Chipaca: blimey, well that's that; we can tackle the wait for refresh thing tomorrow ;-)
<mup> PR snapd#5425 closed: spread: increase the number of auto retries for package downloads in opensuse <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5425>
<mup> PR snapd#5409 closed: tests: run "arp" tests only if arp is available <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5409>
<mup> PR snapd#5381 closed: interfaces: make findSnapdPath smarter <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5381>
<jdstrand> popey: thanks! did you do this in coordination with niemeyer? we were talking about it and hadn't done it yet
<jdstrand> zyga: re 5411> ack
<popey> No. It just seemed mad to have it be there.
<popey> The rest API docs should move too as it's the last one left but it's more than 32k in size
<popey> The forum balks at more than 32000 byte docs
<jdstrand> zyga: fyi since mborzecki is away: https://github.com/snapcore/snapd/pull/5423/files#r198954092
<mup> PR #5423: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5423>
<zyga> mmm
<zyga> so the old rules _worked_ with old code outside of lxd
<zyga> inside lxd there was a denial from apparmor profile of the container which disallowed filesystem remounts
<zyga> stgraber changed the profile to allow _mount point_ remount
<zyga> so the new rules also work fine with new code, but now inside and outside of lxd (though you need edge lxd to use it for now)
<jdstrand> zyga: I guess the question is, do these rules only apply for that one line code change, or is there other code that the old rule covered?
<zyga> we have a spread test that checks non-lxd case and it works (it failed before maciej updated the profile)
<zyga> it's the only instance, we checked
<jdstrand> ok, that's fine
<zyga> we don't have a test that checks this inside lxd but this is a separate issue with just running the whole suite in lxd to see what _really _works vs adding special-cases in tests
<zyga> we also ran this in practice on maciej's hardware with bionic host / guest and nvidia drivers and lxd from edge
<jdstrand> zyga: thanks. I commented to myself
<zyga> FYI, I added this as a response to the forum now
<zyga> nice, thank you :)
<jdstrand> (I did in the PR)
<zyga> er, I meant the PR as well
<zyga> not sure why I said about the forum
<jdstrand> heh, it is late there. I meant for you to only see this when you came online tomorrow :)
<zyga> I'm still here, trying to fix some issues in s-c
<mvo> zyga: on the core/core18 thing?
<zyga> yes
<zyga> sorry, interrupts from IRL, daughter being grumpy about housework (literally one plate she used) and chatting with wife about weekend prep
<zyga> mvo: I'm moving out for three weeks to spend the time with my parents (and the kids)
<zyga> so some preparation required
<mvo> zyga: heh, no worries
<mvo> zyga: if you push what you have, maybe I can help?
<zyga> sure
<zyga> mvo: just pushed to branch named after your PR
<zyga> with a WIP/commit on top
<zyga> have a look, not too much really
<zyga> I will try to focus now and finish this
<zyga> but feedback welcome
<mvo> zyga: cool, looking
<mvo> zyga: thanks a bunch!
<jdstrand> popey: ok, thanks! :)
<zyga> trying locally now
<zyga> it failed on some non-core systems, checking what I did again
<zyga> bringing up the VM is veeeery slow
<zyga> more timeouts, sigh
<zyga> I switched to my laptop LTE
<zyga> maybe my home link (different ISP) somehow sucks today
<mvo> zyga: I'm running in parallel
<zyga> it will fail but I want to see exactly how and focus on fixing it
<zyga> did you eyeball the code
<zyga> (please squash the last two WIP patches for better ideas)
<mvo> yeah, looks reasonable
<zyga> and _drat_ I didn't pass keep
<zyga> well
<zyga> ;)
<zyga> mvo: ok, got it to fail now
<zyga> I ran 16.04 classic
<zyga> and it failed with: mount --move /var/lib/snapd /tmp/snapd.quirks_$random: EINVAL
<zyga> hmmm!
<mvo> zyga: I am almost there, I had an earlier failure that core18 did not work
<zyga> I'll gdb to see what happens
<zyga> gdb
<zyga> the one thing I miss in go world
<kyrofa> zyga, you don't need to lie about how much you secretly love C++
<zyga> I don't love C++ actually, I'm a huge fan of C
<zyga> C++ not so much
<zyga> uh, stripped
<roadmr> is niemeyer around?
<roadmr> C is nice, C++ is beyond my powers to grok haha
<zyga> roadmr: I feel exactly the same
<niemeyer> roadmr: He is
<roadmr> niemeyer: +1 for referring to yourself in the third person. Are you OK to transfer travis over to kyrofa ?
<roadmr> zyga: today I found https://www.emojicode.org/
<zyga> mvo: how terrible would it be if snap-confine-debug would be in snapd.snap?
<zyga> 297K
<niemeyer> roadmr: Yeah, major +1 for having a Travis CLI that doesn't involve building the gem from the ground up
<mvo> zyga: for now it should be fine
<roadmr> thanks niemeyer ! the transfer is now complete. Cheers!
<zyga> mvo: I have supper now
<mvo> zyga: ok, lets talk tomorrow
<mvo> zyga: hm, hm, I merged my earlier spread test
<mvo> and running test-snapd-tools.cat /etc/os-release gives me core-18 :(
<mvo> zyga: how is debug mode?
<mvo> zyga: anyway, tomorrow
#snappy 2018-06-29
<mborzecki> morning
<zyga> Hi
<zyga> Mvo: I fixed it
<mvo> zyga: \o/
<mvo> zyga: woha, nice
<mvo> zyga: what was it?
<zyga> Flipped logic
<zyga> Look at the FIX patch
 * mvo looks
<zyga> Core test still need change but runtime is fine
<mvo> zyga: what core test needs a change?
<zyga> Or actually no. It doesnât
<zyga> Ignore me :-)
<zyga> Not enough sleep
<zyga> Donât look at the time stamp
<zyga> I will clean this up and propose to master
<mvo> zyga: uhhh
 * mvo hugs zyga
<mvo> zyga: really not enough sleep
<mvo> zyga: yay, works here, nice job
<zyga> Same here
<zyga> Cool, so one last issue ahead
<zyga> And one that should be way
<zyga> Easier
<zyga> Iâll get some coffee and get right to it
<mborzecki> mvo: hi, can you take a quick look at #5424 ?
<mup> PR #5424: tests/main/snapd-notify: use systemd's service properties rater than the journal <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5424>
<mvo> mborzecki: good morning
<mvo> mborzecki: sure
<mup> PR snapd#5361 closed: snapstate: allow removal of snap.TypeOS when using a model with a base <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5361>
<mup> PR snapd#5424 closed: tests/main/snapd-notify: use systemd's service properties rater than the journal <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5424>
<mborzecki> mvo: yay!
<mvo> mborzecki: thank you, that was failing a lot recently
<pedronis> #5392 needs a 2nd review
<mup> PR #5392: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5392>
<mvo> abeato: hey, good morning! 5309 got a +1 just a tiny tweak to the filename is requested
<abeato> mvo, morning!
<abeato> mvo, yeah saw that, will change it and ping you back :)
<mvo> abeato: great, thank you! I'm keen to land it :)
<mvo> sil2100: hey, good morning. I noticed our /etc/hosts on core18 is empty, do you know where that files comes from nowdays? I wonder if we need to add a static one to our build tooling
<mvo> sil2100: with localhost and the like
<abeato> mvo, 5309 re-pushed
<mvo> looking
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> pstolowski: hey
<zyga> re
<zyga> small horror story
<zyga> what happens after:
<zyga> 1) you talk with your wife about ways of making coffee
<zyga> and about perhaps getting those portable espresso machines
<zyga> 2) you work till 3AM
<zyga> anyone wants to guess? :)
<zyga> the coffee machine breaks :(
<mborzecki> zyga: you go a buy a moka pot? :)
<mup> PR snapd#5420 closed: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5420>
<zyga> what's a moka pot? :)
<zyga> so far I fed the children and tidied the kitchen, now I need to walk the dog
<mborzecki> zyga: https://en.wikipedia.org/wiki/Moka_pot
<zyga> but first, small rebase of that WIP+FIX patches so that I can send it to master
<sil2100> mvo: let me make sure
<mborzecki> any PRs in need of review?
<mvo> mborzecki: the 2.34 ones would be great
<zyga> mvo: ok, I have a nice patch now
<zyga> I force-pushed to my working branch
<zyga> I will now open a master PR
<pedronis> mvo: could you review #5304 ?
<mup> PR #5304: overlord/ifacestate:  simplify checkConnectConflicts and also connect signature <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5304>
<pedronis> heh, sorry
<pedronis> mvo: IÂ meant #5403
<mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
<mvo> pedronis: sure
<mborzecki> zyga: https://paste.ubuntu.com/p/vn9XJVcpKj/
<zyga> mborzecki: is match passing -E?
<zyga> but ... odd
<zyga> do you have a debug shell?
<zyga> if so, type MATCH could be useful
<mborzecki> zyga: yeah, i checked spred source code, it's using ... grep -q -E \"$@\" ..
<mborzecki> zyga: https://github.com/snapcore/spread/blob/master/spread/client.go#L357
<mup> PR snapd#5432 opened: cmd/snap-confine: fix snaps running on core18 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5432>
<zyga> mvo: ^ this is for you
<zyga> mborzecki: magic :)
<mvo> mborzecki: yeah, this is strange, this tests passes most of the time
<mvo> zyga: \o/
<zyga> mvo: I need to take the dog out and look after myself a little
<zyga> I will be back around 10:30 perhaps
<Son_Goku> zyga, do you think we can have a fedora-based snap to demo by Flock?
<zyga> yes
<abeato> mvo, 5309 finished CI fine (thanks for the change in the spread test, I had not noted that one)
<mvo> abeato: ta
<abeato> \o/
<mup> PR snapd#5309 closed: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5309>
<niemeyer> Mornings
<zyga> hey
<mborzecki> niemeyer: hey, you're early, adjusting to new timezones?
<niemeyer> mborzecki: Heya
<niemeyer> mborzecki: Nah, just in the mood for night hacking
<niemeyer> Well.. "hacking".. reviewing right now
<pedronis> mvo: #5392 paniced btw, not sure it's the panic fixed by the other PR
<mup> PR #5392: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5392>
<pedronis> mvo: could be though, maybe they need to be merged
<mvo> pedronis: indeed, I think its the same, I will merge the fix and see if that helps
<mvo> pedronis: but its slightly odd as this panic happens when there are snaps in the seed, I will dig into it
<mvo> pedronis: right after I reviewed your PR
<mup> PR snapd#5388 closed: tests: fix tests when no keyboad input detected <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5388>
<mvo> pedronis: aha, I think I know what is going on, silly me
<pedronis> ah, it was the previous commit
<mvo> pedronis: yeah
<mvo> pedronis: reviewed, looks fine and added some comments but we can land when green I think
<pedronis> mvo: thx, yes, need to tweak a couple of spread tests to get it green
 * Chipaca afk for a while
<popey> cjwatson: when did "Manage this package in the store" link land in the store? I only just noticed it. It's super useful, thank you (if it was you, which I assume it was) that made it happen :)
<popey> s/store/launchpad/
<cjwatson> popey: 2016 :-)  You're welcome
<popey> wow
<Son_Goku> mvo, it's happening! https://pagure.io/flock/issue/87
<mvo> Son_Goku: \o/ woah
<pstolowski> nice!
<Son_Goku> I just filed the proposal since niemeyer gave me the all-clear
<mup> PR snapd#5427 closed: configcore: fix incorrect handling of keys with nubmers (like gpu_mem_512) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5427>
<mvo> mborzecki: 5389 looks good, does this need any further design review or can I just land it?
<mvo> mborzecki: at this stage, what is missing for parallels installs to get them working end-to-end? just curious
<pedronis> mvo: all the interface backends need some work (some a little, some a bit more)
<mborzecki> mvo: i still have changes for snapstate/snapsup, some tests in overlord, small change in daemon and some spread tests, plus changes in store
<mvo> pedronis: aha, thanks
<mborzecki> mvo: oh and some bits in snap-confine too
<mup> PR snapd#5389 closed: snap: account for parallel installs in wrappers, place info and tests <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5389>
<mup> PR snapd#5429 closed: osutil: import go-udev <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5429>
<mborzecki> hit a weird problem, if /etc/dbus-1/system.d does not exist and we dump a file there (creatign the directory first), does dbus daemon need a reload/restart to pick up the new files?
<mvo> mborzecki: I bet it does
<mvo> mborzecki: probably a inotify (or whatever it is nowdays called) restriction
<mborzecki> so #5413 does some distro purge, in arch /etc/dbus-1/system.d is not owned by dbus but rather by individual pacakges
<mup> PR #5413: tests: purge packages installed by accounts, calendar, and contacts interface tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5413>
<mvo> mborzecki: i.e. I assume it sets up a watcher for this dir, but if the dir does not exists it will not setup this watcher
<mborzecki> it's possible that we end up without /etc/dbus-1/system.d at some point
<mborzecki> then when snap is installed, create the dir and dump the *.service file but it's not picked up
<mvo> mborzecki: hm, that seems unfortuante
<mup> PR snapd#5392 closed: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5392>
<mvo> mborzecki: might be worthwhile to fix in the arch dbus package? it seems odd that it would not own the dir
<mborzecki> mvo: i could own /etc/dbus-1/system.d in snapd package, but it's slightly meh, another empty dir
<mvo> mborzecki: especially if the suspicion about the inotify watch is true
<mvo> mborzecki: I don't know the conventions of arch so I might be off but I think the dbus arch package should own the dir
<mvo> mborzecki: or at least co-own it
<mvo> mborzecki: like if dbus is installed it should always be there
<mborzecki> mvo: the 'convention' is no empty dirs shipped by the pacakge, but we're already not doing this
<mborzecki> or doing, i.e. shipping empty dirs :)
<mvo> mborzecki: heh, yeah, I understood (but parsing took a little longer)
<mvo> mborzecki: so that is why dbus does not own the dir? because it would be empty?
<mborzecki> mvo: yes
<mvo> mborzecki: that seems to be slightly silly tbh, it could ship a README in there (again assuming the theory about inotify is correct)
<mborzecki> mvo: it ships /usr/share/dbus-1/system.d, though we don't touch that
<mvo> mborzecki: because dbus is buggy for other packages as well. install foo-that-uses-dbus.d and it won't get picked up until dbus is restarted
<mvo> mborzecki: anyway, just my 2Â¢
<pstolowski> zyga, mborzecki can you take another look at https://github.com/snapcore/snapd/pull/5416 ?
<mup> PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
<pedronis> niemeyer: Q, what kind name we would use for the new single one (the old one cannot be reused because different expectations about Value)  ?
<niemeyer> pedronis: Was hoping we could just preserve what we have
<niemeyer> pedronis: How has the Value changed?
<niemeyer> pedronis: Is it incompatible?
<pedronis> niemeyer: Value is now a mapping of details, before it was just snapName
 * niemeyer looks again
<niemeyer> pedronis: But is it just more than what we had, or incompatible somehow?
<pedronis> it's incompatbile string vs mapping
<niemeyer> pedronis: Ah, the entire "value" was a snap name?
<pedronis> yes
<niemeyer> Ouch
<pedronis> niemeyer: we could use  snap-revision-not-available-as-specified   (to follow your suggested base error message)
<niemeyer> pedronis: "snap-not-available" maybe
<zyga> pstolowski: yes
<pedronis> niemeyer: sounds a bit too much like snap-not-found to me
<niemeyer> Indeed
<niemeyer> hmm
<mvo> zyga: I took the liberty to push a very small spread test to your 5432 fixup pr, thanks again for this
<zyga> sure, thank you
<pedronis> niemeyer: also to explain, IÂ went for two kinds, not just because IÂ needed a kind, but because so a naive client could give a slightly accurate message without parsing value
<niemeyer> pedronis: Ah, indeed.. that will also be solved with the separate kind
<pedronis> I mean "there is nothign for this arch"  vs "there is something but not in this channel"
<niemeyer> pedronis: I see
<niemeyer> pedronis: That's nice indeed
<niemeyer> pedronis: and I guess the "nothing for this arch" is quite useful, even if there's nothing in this channel either
<pedronis> yes
<niemeyer> It's more like "give up, you won't find anything here"
<pedronis> that was the reasoning
<niemeyer> pedronis: +1
<pedronis> I will switch to the shorter kind you proposed tough
<niemeyer> pedronis: Btw, I think we should provide such a message from the server also
<niemeyer> pedronis: In case the client is dumb
<niemeyer> pedronis: Right now I think it's only providing the general "nothing found" one
<pedronis> let me see
<pedronis> niemeyer: no, it gives two different messages if (it has info)
<pedronis> no snap revision for the given channe
<pedronis> l
<pedronis> and
<niemeyer> Or more specifically, "nothing for given constraints".. there's a note about this message being bad in the review, but it would be nice to at least hint at the delta between "nothing for this arch" vs "nothing for this channel", even if we don't go full blown for now
<pedronis> no snap revision for the given architecture
<niemeyer> pedronis: Ah, okay.. I must have missed something then.. it thought it was just returning the rna.Error() message, which is a single one
<pedronis> that's used only as fallback
<pedronis> if some reason or corner case
<niemeyer> Ack
<pedronis> the store doesn't provide the info
<pedronis> niemeyer: code is here:  https://github.com/snapcore/snapd/pull/5403/files#diff-e1016939c627280d9f6c53bdab0530bfR399
<mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
<niemeyer> pedronis: Cool, thanks, looks good.. suggested a minor tweak to the messages
<pedronis> ok, I'll proceed as discussed then
<niemeyer> Thanks
<pedronis> about simplifying thanks, I'll first go over the other feedback, messages and kinds
<pedronis> and then see what iÂ can do
<pedronis> (it's already a bit big and some of that is preexisting)
<niemeyer> mvo: Three PRs from 2.34 to go.. but I'll try to get a couple of hours of sleep before the meeting marathon this morning.. may not be able to review these last ones before my afternoon
<pedronis> heh, s/thanks/things/
<mvo> niemeyer: no worries
<mvo> niemeyer: we can always postpone them or merge them slightly later
<mvo> niemeyer: thanks a lot for your reviews
<niemeyer> np, see you all soon o/
<pedronis> mvo: I'll go over the new feedback for 5403 after lunch
<mvo> pedronis: thank you, also no worries, I plan to do 2.34~pre1 today to see if it builds everywhere and if autopkgtest are fine, we will probably need to do a ~pre2 to deal with that fallout anyway so if a PR is not ready today that is not too terrible
<mvo> pedronis: I also updated 5428, should be an easy review I hope
<pstolowski> zyga: can #5411 land?
<mup> PR #5411: many: remove core-support interface <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5411>
<pedronis> mvo: it's red atm
<zyga> pstolowski: I think so but I wanted jdstrand to see it too
<pstolowski> ack
<mup> PR core#89 opened: hooks: fix 30-fix-timedatectl.chroot to DTRT when running on non-core devices <Created by mvo5> <https://github.com/snapcore/core/pull/89>
<mup> PR core18#44 opened: hooks: fix 030-fix-timedatectl.chroot to DTRT when running on non-core devices <Created by mvo5> <https://github.com/snapcore/core18/pull/44>
<mup> PR snapd#5431 closed: interfaces: move ValidateName helper to utils <Simple> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5431>
<mvo> zyga: we are down to two failing test: ubuntu-core-18-64:tests/main/snap-disconnect (and one race) and tests/main/catalog-update which I am looking into right now
<zyga> that's great, I will give you the patch for disconnect today so that will be just landing and polishing for next week
<zyga> mvo why is catalog-update failing?
<mvo> zyga: no idea, might be a fluke
<zyga> and what happened to systemd and signals? did you find the issue?
<mvo> zyga: checking now
<mvo> zyga: this is the racy one
<zyga> I see that test fail from time to time (~ once a week maybe)
<mvo> zyga: still not sure what is going on there :(
<zyga> aha
<zyga> ok, good news though
<zyga> I think core18 will rock :)
<mvo> zyga: heh, eventually
<mvo> zyga: but yeah, we are on the right path at least
<sil2100> mvo: so I just did a quick check - the /etc/hosts file is still generated by netcfg from what I see, which is a d-i package
<mvo> sil2100: aha, so we probably should include something in our build given that we don't run d-i
<sil2100> mvo: I guess the easiest way would be just to prepare a static one
<sil2100> Let me do that
<mvo> sil2100: \o/ thank you
<mvo> zyga: catalog-refresh looks very much like a bug in get_journalctl_log
<zyga> yeah
<mvo> zyga: when I run journalctl -u snapd.service | MATCh things magically work
<zyga> I think that it is buggy because of buffering
<zyga> we don't see stuff in the "pipe"
<mvo> zyga: I think we need to revert that
<mvo> zyga: it might also the reason why the stop-mode test is failing
<mvo> zyga: I can look after lunch
<zyga> that would be a good thing to see actually
<zyga> yeah
<zyga> ok, thank you
<mvo> zyga: my gut feeling is revert
<zyga> I'm doing reviews, my head is too dizzy still
<mvo> zyga: ok - if you want we can have a quick HO and I can do the disconnect work. I just need some info what you had in mind. but lunch first
<zyga> no, that's fine, I will finish that one :)
<mvo> zyga: I'm super motiviated to get the last bit in
<mvo> zyga: ok
 * mvo hugs zyga
<zyga> yes, mee to :)
<zyga> me too
<zyga> just ... sleepy
 * zyga takes a break from reviews and hacks that bit in
<mup> PR snapd#5433 opened: interfaces/repo: added AllHotplugInterfaces helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433>
<mup> PR core18#45 opened: Provide a static simple /etc/hosts file <Created by sil2100> <https://github.com/snapcore/core18/pull/45>
<zyga> mvo: ok, testing the fix now
<mvo> zyga: woah, thats impressively fast
<mvo> sil2100: \o/
<zyga> mvo: that's a good joke for a 1st patch at 13:12 :)
 * mvo hugs zyga 
<mup> PR core18#45 closed: Provide a static simple /etc/hosts file <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/45>
<mup> PR snapd#5434 opened: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<zyga> mvo: some more tweaks after first round of testing
<zyga> I'll break for 30 minutes now and get back to this before the standup
<zyga> I think it will pass before the standup
<mup> PR snapd#5408 closed:  i18n: use xgettext-go --files-from to avoid running into cmdline size limits <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5408>
<zyga> mvo: I tweaked it now to be even easier, testing now
<zyga> running more tests, it's funny how I ping pong around the cod
<mvo> zyga: :) thanks a lot!
<zyga> I forgot we have resolve disconnect that is full blown and used in daemon/api.go
<zyga> so perhaps the tweaks to other places are actually not needed
<zyga> (more self-contained change)
<pedronis> yes,  the fewer the places the better, the easier is to reason about
<mvo> pedronis: re 5422 - I agree with you, we need at least a proper test and I can give the idea of using the connections a go. I want it in 2.34 but in a way that is not too ugly
<pedronis> mvo: yes, a regression test would  also be good
<zyga> joining
<Chipaca> oops, standup
 * Chipaca runs
<zyga> mvo: it passes now, I will remove my extra patches :)
<zyga> mvo: I pushed two tiny patches to my integration PR
<zyga> mvo: I will amend the latest one to have more tests
<zyga> have a look
<mvo> zyga: nice
<zyga> mvo: question
<zyga> mvo: why is snap-disconnect test _not_ listed for systems: [-ubuntu-core-16-64]
<mvo> zyga: I don't know why its disabled there?
<zyga> my guess was home is not auto connected but that's not relevant there
<zyga> I'll re-enable it
<mvo> zyga: thanks
<mvo> zyga: lets check git blame
<zyga> ha, good idea
<zyga> checking
<zyga> since day 1
<zyga> mvo: and it passes :)
<mvo> zyga: \o/
<zyga> mvo: also pushed
<Chipaca> mborzecki: where is that failure from? the MATCh one
<mvo> Chipaca: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L482 is the relevant code
<Chipaca> yes i've got that
<mvo> Chipaca: aha, you mean from what PR?
<Chipaca> yeah
<mborzecki> Chipaca: i don't remember the actual PR
<Chipaca> basically, two things could be happening that I can think of right now:
<mborzecki> Chipaca: but if you pick one of the failed ones there's a high chance you'll run into it :)
<Chipaca> 1. a non-printable character is in that file, before 'test'
<Chipaca> note the first grep does >> instead of >, so if there was rubbish there it'll still be there
<Chipaca> 2. something wrote to the file between the grep and the MATCH (I don't think so as nothing should be happening concurrently at this point)
<pedronis> Chipaca: one possibility is that the file >>  sometimes doesn't end with newline
<Chipaca> pedronis: right, that's what I mean, there might be a \0 or something in the file, and it gets test:yaddayadda appended
<pedronis> IÂ meant the file >> to
<Chipaca> if there's no reason for the first >> we should change it to a > and be done with it :)
<Chipaca> pedronis: sorry i didn't quite follow you
<Chipaca> pedronis: if you mean the left hand side of the >>, that's a grep so it'll be adding its own newlines
<pedronis> no
<pedronis> IÂ mean the preexisting file ending
<pedronis> maybe we should add a check about that assumption
<pedronis> at least it woudl cleanly
<pedronis> would fail cleanly
<sergiusens> Chipaca: so I've followed the suggestion to mount inside the VM, so carry on with the idea of 400 for snaps
<Chipaca> sergiusens: *smooch*
<mvo> Chipaca: fwiw, golang-1.10 builds fine on xenial in pbuilder, trusty looks a bit more involved, at least the build-depds need to be updated there but probably also not that much work given that we have 1.6 there already
<pedronis> Chipaca: something like  either length is 0  or  tail -c 1 /mnt/system-data/var/lib/extrausers/"$f"| some way to check for a single "\n"
<mvo> Chipaca: I did not really look into trusty though as agreed in the standup :)
<mvo> zyga: I ran snap-disconnect from your PR and it failed :(
<Chipaca> mvo: I'll be giving that a poke on Monday, I reckon
<zyga> mvo: how did it fail, which test did you run exactly?
<mvo> Chipaca: sure thats fine
<mvo> zyga: I used your branch and did: spread -v google:ubuntu-core-18-64:tests/main/snap-disconnect
<mvo> zyga: zyga error: snap "core" has no slot named "home"
<zyga> hmm, I ran exactly that !
<mvo> zyga: but maybe I did smething wrong
 * zyga checks for un-commited stuff :)
<mvo> zyga: and have the wrong branch or whatnot
<mvo> zyga: I'm in a meeting so maybe that
<mvo> zyga: was distracted
<zyga> mvo: I pushed one more patch there
<zyga> maybe that is also needed in practice
<mvo> zyga: ok, let me pull
<mvo> zyga: running it again
<mvo> zyga: I have b4d4df8ff92ddde657cea9f7249b8a69872d69e0 on top currently
<zyga> I think I commited it wrong, it needs to be split into two
<Chipaca> pedronis: so, it's not gibberish at the start of the file
<zyga> I have 71230a6d0e5f11eb6a09aa958b200c00167592b7
<zyga> mvo: top is "    overlord/ifacestate: translate explicit requests for core to snapd"
<zyga> I will split this patch and check what I did
<pedronis> Chipaca: ?
<Chipaca> pedronis: the MATCH thing
<pedronis> yes
<Chipaca> pedronis: I've got a shell in a failed run
<Chipaca> the file is fine afaict
<pedronis> and?
<mup> PR snapd#5435 opened: overlord/snapstate: introduce path to fake backend ops <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5435>
<pedronis> Chipaca: mmh
<pedronis> fine in which sense
<pedronis> test: ...
<pedronis> on its own line?
<Chipaca> yep
<Chipaca> and MATCH passes
<Chipaca> but it failed
<pedronis> mmh
<mborzecki> Chipaca: can you write a short script, source $TESTSLIB/spread-funcs.sh inside and check if that MATCH works in the script?
<pedronis> fun, not
<Chipaca> mborzecki: by a short script you mean one that does the 'for f in â¦' thing?
<zyga> mborzecki: note that spread-funcs is empty outside of a spread run
<zyga> it doesn't "cache" any copy of the functions in the tree
<Chipaca> I'm going to add a 'sync' option in there and run it a few times to see
<mborzecki> zyga: but it's dumped in top level prepare in spread.yaml, won't that be present in when you have debug shell?
<zyga> sync
<zyga> sleep 1
<zyga> sync # to be sure
<zyga> rebot
<zyga> mborzecki: yes, in debug shell that works ok
<Chipaca> zyga: mount / -o remount,sync
<mborzecki> zyga: but MATCH in debug shell comes from the profile which is mangled by spread, i want to check the MATCH that was duped to spread-funcs.sh
<Chipaca> mborzecki: next time it fails i'll look into that
<mborzecki> it's probably ok anyway
<mvo> pedronis: 5403 is green, anything missing there or can I merge it? we can always do a followup
<mvo> pedronis: aha, I think this probably needs a re-review first, right?
<zyga> mborzecki: just source it then :)
<zyga> mborzecki: actually
<zyga> write a script that _sources_ it and _execute_ the script
<mvo> zyga: it woooooooooooooooooooooorked
 * mvo hugs zyga
<zyga> nice :)
<pedronis> mvo: I don't know
<zyga> so that's ... ... that's all that passes now?
<zyga> just reviews and merges and stuff?
<mvo> zyga: please propose your PR and then I can push the big core18-all-tests PR
<zyga> OK
<zyga> on it ;)
<mvo> zyga: \o/
<zyga> :-)
<mvo> sergiusens: let me search for this postpone of refresh command now
<mvo> sergiusens: its "snap set core refresh.hold", let me find a proper example
<sergiusens> mvo: thanks!
<mvo> sergiusens: I'm creating a integration test with a proper example
<zyga> mvo: I'm still reworking it slightly to be less copy-pasty
<mvo> zyga: ok, still in a meeting
<zyga> ok
<mup> PR snapcraft#2174 opened: build_providers: inject snaps when running from a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2174>
<sergiusens> mvo: in case you have moments to spare ^
<mup> PR snapd#5436 opened: tests: add basic integration test for spread hold <Created by mvo5> <https://github.com/snapcore/snapd/pull/5436>
<mvo> sergiusens: the hold example is here -^
<senya> hello! are there examples of complete ruby on rails applications packed with snapcraft?
<senya> specifically: how do I pack an application if it depends on a DB running instance?
<zyga> senya: hey, I don't knof of any but please ask around and also check on the forum
<zyga> senya: note that the database may be (perhaps) a separate snap if that is more convenient
<senya> the whole idea of snap is to be self-sufficient, so I think that if DB is a part of the application then it should be bundled with the application
<zyga> well, it depends on how you look at it
<zyga> you can bundle for a totally self-contained product
<zyga> you can also integrate with an existing database
<zyga> this also makes sense when you think that database may be shared by many systems that have the app snap installed
<zyga> it depends on what you want to achieve
<Chipaca> so... with the changes to prepare.sh, I can no longer get the MATCH thing to fail
<Chipaca> this bothers me intensely
<senya> what I think would be cool to have is a way to package RoR apps with snap, like Redmine, Discourse, etc, so that you can deploy a service with just "snap install redmine" and start using it right away, and then upgrade it with snap when new release is out
<zyga> mvo: still moving stuff around but the resulting logic is much nicer
<zyga> I will push another patch in this branch but open an itegrated PR for master
<mup> PR snapd#5437 opened: tests/lib: sync the file before checking its contents <Created by chipaca> <https://github.com/snapcore/snapd/pull/5437>
<zyga> senya: yeah, I agree
<zyga> senya: I think this is possible
<zyga> senya: and even in a mode where they bundle a simple database
<zyga> (sqlite)
<zyga> senya: but allow a full database to be attached via the configuration system in snaps (snap set)
<Chipaca> senya: doesn't nextcloud use ruby at all?
<Chipaca> afaik it ships with the whole stack in a snap
<Chipaca> (but it might be php, for all i know)
<senya> nextcloud is written on php
<zyga> repyhape
<senya> but if it bundles a DB it could be good as a reference!
<popey> There's not a ton of ruby snaps in the store
<popey> I can't even think of any right now
<Chipaca> zyga: repyhape?
<senya> there was a ruby example somewhere at snapcraft.io I think, but it was for ruby gem, not for a Rails application
<zyga> a frankenstein with php ruby and python
<Chipaca> popey: rubymine?
<popey> thats... java?
<zyga> perl
<Chipaca> popey: psh
<Chipaca> how can they write an ide for a language in anything other than the language
<Chipaca> hard to take 'em seriously
<Chipaca> :)
<popey> turns out you can take one ide, re-skin it for 10 languages and $$$ :D
<popey> (I kid, their IDEs are amazing)
<zyga> $$$ oh wait, it is free ;)
<Chipaca> popey: nothing against $$$ tho
<popey> until it isnt
<Chipaca> I like $$$, myself
<popey> nom nom tasty dolla
<senya> I think I can take https://github.com/nextcloud/nextcloud-snap as a reference and try to adapt the approach for RoR
<Chipaca> just the other day I used some of it to obtain some coffee, and it was good
<senya> oh, the repo even includes some ruby code, interesting
<senya> that what you meant by frankenstein
<Chipaca> zyga: https://twitter.com/perrito666/status/1012730660426059777
<Chipaca> i think I should probably check out
<senya> they are building mysql from the source code https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L255
<senya> but is it possible to use apt to get the mysql package bundled to the snap?
<Chipaca> senya: yes
<senya> I like this idea better
<Chipaca> anyway, EOD, EOW, etc. Will probably pop in later to check on that silly PR, and such, but for now I'm going to go out with the boys before summer ends
<zyga> ends?
<zyga> it just started
<zyga> unless brexit makes UK go directly from one winter to another
<tomwardill> british summer usually starts and ends in the same week
<zyga> hahahaha
<tomwardill> and goes from 'cold and rainy' to 'rainy and a bit warmer'
<zyga> I should invite chipaca over
<zyga> (for winter)
<zyga> mvo: ok, I think I have a nicer version now
<zyga> still missing extra tests for many cases, I will attack those over weekend
<zyga> but now in a much much nicer shape
<zyga> where all remapping is done in a pair of functions
<zyga> incoming and outgoing
<zyga> so we could eventually remap more things if we want to, without ripping the code apart
<zyga> I'm running spread now, will check how the patch looks like
<zyga> one last bastion is daemon/api.go
<zyga> which really duplicates (synchronously) some of the work in other places
<zyga> one thing I can do (and should) is to move the remapping logic to a place where daemon can use it as well
<zyga> let me look
<zyga> I pushed to my branch for reference
<zyga> (force pushed since this is all bunch of WIP's and rebases)
<zyga> it passes, so no regressions
<zyga> that was 16, now trying core 18
<zyga> all green
<zyga> mvo: I will have 3 nice small branches soon, just need to take the dog out
<zyga> one refactor that makes it easy
<zyga> one new helper
<zyga> and the meat (tiny then)
<zyga> but first
<zyga> dog :)
<zyga> mvo: actually, not sure if you are around
<zyga> mvo: I have some ideas how to shrink that to two branches
<zyga> but I should _pack_ first
<zyga> so I will send stuff to look at (next week, please have your weekend)
<zyga> but my time would be better spent on packing everything for the move
<zyga> mvo: if you are around and want to provide quick feedback that is also welcome
<zyga> mvo: because I could change how I refactor that further based on your input
<mvo> zyga: sorry, wasn't around earlier but back now
<zyga> mvo: re
<zyga> mvo: let me show you quickly...
<zyga> mvo: please look at https://github.com/snapcore/snapd/compare/master...zyga:feature/snapd-core-remapping?expand=1
<zyga> I will drop the first change that adds NewConnRefStrings perhaps, I need to do one more pass through this
<zyga> the key thing is the pair of remap functions that define the transformations
<zyga> and their application in several places
<zyga> I plan to refactor this a little bit more to propose the refactoring without the remapping so that remapping is clearly layered on top
<zyga> also some of the comments should just be unified and placed in one spot
<zyga> this looks a bit nicer than earlier attempt that had similar-but-not-quite code all around
<zyga> I still don't like how we need to careful remap in specific places but hopefully those are limited
<zyga> we cannot remap at the api level though because there it would show up in the state
<zyga> so this is a compromise of sorts
<zyga> the key improvement in this iteration is that the functions that remap are well defined and we could possibly do other mappings later easily
<mvo> zyga: ok, thank you! I check it out, just workiing on 2.34 beta right now
<zyga> OK
<mvo> zyga: this looks pretty nice
<mvo> zyga: feel free to propose
<mvo> zyga: that PR
<zyga> I'm 30-40% through packing, I would still like to change one little detail there and add some tests
<kyrofa> Hey zyga, I just got a bug report from a user who's snap suddenly stopped working. Logs are filled with lines like this: https://pastebin.ubuntu.com/p/JsKrXrGx9b/
<zyga> kyrofa: snap version please
<zyga> this means the profile was not loaded so we could not switch to it
<zyga> (and sandy that's not an error message we can easily fix, though I will look into it)
<zyga> a way to fix it would be to call apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap*
<zyga> but I'm wondering why the profiles were lost
<zyga> ideally which distribution and how is it set up (containers?)
<kyrofa> zyga, I asked for `snap version`, but the bug says "Debian 9 (stretch) with all updates applied"
<kyrofa> zyga, excellent on the workaround, shall I suggest it, or do you want more data first?
<zyga> suggest it and ask for uptime, and logs perhaps (system logs)
<kyrofa> Shall I suggest uptime, syslog, and snap changes?
<zyga> oh, snap changes is always useful, yes
<zyga> that sounds like an excellent choice
<kyrofa> Wait, does Debian actually use apparmor?
<kyrofa> I didn't think so
<kyrofa> zyga, here is `snap version`: https://pastebin.ubuntu.com/p/XjfvCT8Br9/
<zyga> yes, it does, though we don't rely on it as much there
<zyga> this all looks good
<zyga> I do wonder what happened
<mvo> zyga: do you think this diff is good enough to cherry pick into the core18-all-tests-all-fixes branch? or will it change again?
<zyga> mvo: it will change a little but it depends on how you plan to use the branch
<zyga> my idea is to decompose it and land bits as they get reviewed
<mvo> zyga: ok
<zyga> so it can stay there because the branch will be rebased and rebased until it shrinks and becomes identical to master
<zyga> you can take it to see how far you get
<zyga> if that helps, sure
<zyga> it might conflict with older patches in that branch so feel free to drop them
<zyga> (they are pretty clearly labeled as affecting ifacestate)
<mvo> zyga: its ok, it can probably wait until monday
<zyga> s/might/will, I'm just polite/ ;)
<mvo> zyga: hm, hm, can't cherry pick apparently
<zyga> oh?
<mvo> zyga: no worries
<mvo> zyga: fixed the conflicts
<kyrofa> jdstrand, the fact that snaps can stat files outside of their confinement but not actually open them is starting to get really annoying :P
<kyrofa> Has there been any progress on fixing apparmor in that regard?
<kyrofa> So many things look for files and open them if they find them. If they find a file they want to open, they rarely write guards around an inability to open them
<kyrofa> I've had to patch certbot already, and now it looks like I need to patch mysql
<jdstrand> kyrofa: not that I'm aware. jjohansen may have additional details ^
<zyga> kyrofa: can layouts help?
<mup> PR snapd#5438 opened: many: run all of main against core18  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5438>
<kyrofa> zyga, maybe, but I haven't played with them
<kyrofa> And only once layouts are generally available everywhere
<zyga> jdstrand: thank you for the review on https://github.com/snapcore/snapd/pull/5395
<mup> PR #5395: interfaces: generalize writable mimic profile <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
<zyga> jdstrand: I replied to some of the comments there
<zyga> not everything because too tired and packing
<mvo> zyga: I pushed the core18-all-tests PR which includes your disconnect fix, fingers crossed
<zyga> ok
<mvo> zyga: I call it a day now, enjoy
<zyga> I wonder if it will pass or if we missed anything
<zyga> night night
<jjohansen> jdstrand: meh, I agree its a pita, but isn't something I can change with in apparmor, it needs to be done in the LSM and vfs
<jjohansen> which is something that some people don't want
<jdstrand> jjohansen: ack. kyrofa, fyi ^
<kyrofa> :'(
<jjohansen> basically hiding them would make applications think they can create, and now we have people trying to create something that doesn't exist
<jdstrand> kyrofa: but, the application is buggy. just cause you can stat() something has little bearing on if you can open() it
<jjohansen> but really does
<jdstrand> kyrofa: I suggest filing an upstream bug
<kyrofa> jjohansen, but at least in that case they'll just get a good old permission denied
<kyrofa> jdstrand, no argument from me, but it's been multiple projects now
<kyrofa> Logging bugs upstream doesn't save me from needing to patch them myself, I'm afraid
<jdstrand> no, it wouldn't
<kyrofa> jdstrand, actually, it seems the issue is in the core snap
<kyrofa> Look at the last line of /snap/core/current/lib/lsb/init-functions
<kyrofa> mysql runs that file, it seems
<kyrofa> [ -e /etc/lsb-base-logging.sh ] is true, but then it can't source it
<kyrofa> So the script exits non-zero, which then brings mysql down with it
<kyrofa> Who is in charge of the core snap, these days?
<kyrofa> I guess I can log a bug over there
<kyrofa> jdstrand, https://bugs.launchpad.net/snapd/+bug/1779416
<mup> Bug #1779416: Scripts in core snap attempt to do things impossible under confinement and die <snapd:New> <https://launchpad.net/bugs/1779416>
<kyrofa> niemeyer, I guess you guys own the core snap these days? ^
<niemeyer> kyrofa: Yeah
<niemeyer> Looking
<niemeyer> kyrofa: Yeah, removing the line sounds fair
<kyrofa> niemeyer, does spread provide a way to determine the OS under test?
<kyrofa> In a task, I mean
<kyrofa> Ooo, $SPREAD_SYSTEM maybe
<niemeyer> kyrofa: Yeah, exactly
<niemeyer> All the "matrix" is exposed as vars
#snappy 2018-06-30
<luk3yx> Will build.snapcraft.io use Ubuntu 18.04 soon?
<Son_Goku> zyga, well, this is a problem: https://bugzilla.redhat.com/show_bug.cgi?id=1596753
<bodqhrohro> Does Snap has a cache everywhere?
<bodqhrohro> I've installed and removed a large (0.5G) snap, but the disk space is still overflowed. Removed all revisions, stopped snap, unmounted it's squashfs partitions, looked for deleted entries in lsof, but nothing helps
<bodqhrohro> So looks like it flooded somewhere else. Not in /snap directory, it has only ~270MB of one revision of core
<bodqhrohro> *anywhere
<popey> bodqhrohro: it's not in /snap, the snaps are in /var/lib/snapd
<bodqhrohro> popey: yes, I found cache here and cleaned manually, thank you. Does snap provide a command like apt's clean/autoclean for this?
<popey> the stuff in /var/lib/snapd is _not_ a cache
<popey> it's the snap itself.
<popey> which gets mounted (it's a loopback squashfs mount) in /snap
<bodqhrohro> Even in /var/lib/snapd/cache? So why there left 4 files if after all I had only one revision of core?
<popey> i meant /var/lib/snapd/snap
<popey> which will likey be consuming some space
<cjwatson> ~/wg 37
<cjwatson> bah, sorry
<mcphail> Can someone point me towards the documentation for architecture-dependent conditionals in a snapcraft.yaml please?
<AuroraAvenue> Hello.
<AuroraAvenue> What command do I use in terminal to open this program up & get it running (as it seemed to install oka) althou there's nothing in the budgie menu.
<AuroraAvenue> https://snapcraft.io/libresprite-simosx
<AuroraAvenue> **What command do I use in terminal to open this program up & get it running (as it seemed to install oka) althou there's nothing in the budgie menu ?
<AuroraAvenue> cjwatson, ping
<AuroraAvenue> elopio, pingu
<AuroraAvenue> diddledan, last time tryin' ping someone this Saturday :(
<AuroraAvenue> moving along ...
#snappy 2019-06-24
<lifeless> question - is the seed directory needed post install? there's 250MB in there that appears to be one-off detritus
<mborzecki> morning
<mborzecki> wow /r/linux is melting down
<zyga> good morning
<zyga> mborzecki: i386?
<mborzecki> zyga: hey, yes
<zyga> https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-with-eoan-ubuntu-19-10/11263/77 is pretty long too
<zyga> fun times
<zyga> how are you?
<zyga> we're driving south from Lux
<zyga> we're aiming for the coast of France
<zyga> we stayed longer with our family in Lux because Gosia was not feeling very well
<zyga> so we are one day behind
<zyga> but now things are looking positive
<zyga> mvo and pedronis are on a sprint this week?
<mborzecki> zyga: kids are on vacations with their grandparents and i caught cold :/ before the weekend i hoped to be able to to 100km+ on bike, but did none of that
<zyga> cold!? how did you do that
<zyga> we're running south, trying to outrun the heat wave
<mborzecki> zyga: heh, to much ice cream and cold drinks :)
<mborzecki> s/to/too/
<zyga> aha, well, the heat can be very hard
<mborzecki> hope i'll be able to land some of the prs
<zyga> mee too
<mborzecki> wanted to do that on tuesday, but builds kept on being red
<zyga> I'm going to review what happened in the last few days
<zyga> and then look at most effective use of the time
<zyga> ooo
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/6922 your comments suggest you did not finish your last pass on this one ?
<zyga> raspi 4
<zyga> https://www.raspberrypi.org/blog/raspberry-pi-4-on-sale-now-from-35/
<zyga> wow
<mborzecki> surprise surprise :)
<zyga> woooow
<zyga> cha ching
<zyga> though I wished for risc v
<jamesh> is there anything more that needs to be done to land https://github.com/snapcore/snapd/pull/6954? (skeleton of desktop session agent)
<zyga> jamesh: hey, I'll review that after 6922
<jamesh> zyga: thanks. https://github.com/snapcore/snapd/pull/6959 is also waiting on a review from you (a helper split out from the icon theme support PR)
<jamesh> the session agent one is probably higher priority
<zyga> I'll focus on helping others in the morning then
<zyga> I've queued all three now
<zyga> small gap in coverage while crossing  countries
<zyga> back now
<pstolowski> morning
<zyga> hello pawel
<mborzecki> pstolowski: hey
<zyga> brb
<zyga> need to stretch my legs
<zyga> jamesh: https://github.com/snapcore/snapd/pull/6959#pullrequestreview-252711139
<zyga> I'll do rest shortly
<zyga> omg it is so hot
<zyga> back
<zyga> looking at 6954 now
<Chipaca> ondra: you around?
<ondra> Chipaca sort of uc20 sprint
<ondra> Chipaca what's up?
<Chipaca> ondra: spidev devices are always spidev< a bunch of numbers> < an actual period > < a bunch of more numbers >?
<Chipaca> like spidev12345.12345 ?
<Chipaca> device nodes*
<ondra> Chipaca so only saw  spidev< a bunch of numbers> < an actual period > < single digit number>
<ondra> Chipaca not sure of num after period can be also multi digit
<Chipaca> ondra: ok
<Chipaca> ondra: i'll comment on your PR
<ondra> Chipaca probably best to ask some real kernel expert :)
<ondra> Chipaca thanks :)
<ondra> Chipaca PR is based on actual hw experience
<Chipaca> ondra: it's about that pesky period
<Chipaca> ondra: which lets any character through right now
<ondra> Chipaca ah, can we lock that? I will double check PR
<zyga> mborzecki: hey
<zyga> mborzecki: I will need to fix 1819875 today
<zyga> mborzecki: wanna talk about it briefly
<zyga> mborzecki: I had some ideas before and those got stuck somehow
<Chipaca> ondra: package main
<Chipaca> import (
<Chipaca> 	"fmt"
<Chipaca> 	"regexp"
<Chipaca> )
<Chipaca> var rx = regexp.MustCompile("^/dev/spidev[0-9]+.[0-9]+$")
<Chipaca> func main() {
<Chipaca> 	for _, s := range []string{
<Chipaca> 		"/dev/spidev1.0",
<Chipaca> 		"/dev/spidev1ð©0",
<zyga> Chipaca: get a pastebin ;)
<Chipaca> 	} {
<Chipaca> 		fmt.Println(s, rx.FindString(s))
<Chipaca> 	}
<Chipaca> }
<Chipaca> ugh
<Chipaca> sorry
<zyga> hey Chipaca :)
<Chipaca> that was meant to be a url
<Chipaca> https://play.golang.org/p/ZzpJfEhHC66
<Chipaca> ^ that one
<Chipaca> zyga: hiya!
<zyga> long time no see, how are you?
<Chipaca> zyga: apparently, bad at copy-and-paste
 * Chipaca unsubscribes from stack overflow
<Chipaca> ondra: in case I bamboozled you too much, here's the url again: https://play.golang.org/p/ZzpJfEhHC66
<zyga> Chipaca: 386 is the number of diffefent of opinions on 32bit libraries today
<Chipaca> ondra: i.e. the current code has a bug, plz fix :-D (note the bug is there already, but, while you're there...)
<Chipaca> zyga: I have Opinions.
<mborzecki> Chipaca: apparently the whole of internet has opinions
<Chipaca> mborzecki: https://picon.ngfiles.com/599000/flash_599131_largest_crop.jpg
<ondra> Chipaca yeah agree, I will update PR
<Chipaca> important to remember that go's regexpses are always unicode-y
<ondra> Chipaca when I use your example I get actually error
<Chipaca> ondra: what error?
<ondra> Chipaca ./prog.go:8:49: unknown escape sequence
<Chipaca> ondra: can you show me the regexp?
<ondra> Chipaca ah wait,  I might need to changes brackets
<ondra> Chipaca OK this one works var rx = regexp.MustCompile(`^/dev/spidev[0-9]+\.[0-9]+$`)
<Chipaca> ondra: by brackets you mean changing "s to `s?
 * pstolowski early lunch
<ondra> Chipaca yeap
<Chipaca> ondra: k
<ondra> Chipaca that fixed it I will update PR
<zyga> looking at https://github.com/snapcore/snapd/pull/6922
<mborzecki> ondra: left some questions under https://github.com/snapcore/snapd/pull/7022
<mborzecki> that mediatek driver looks fishy :/
<mborzecki> ondra: typo in the regex https://github.com/snapcore/snapd/compare/4a8f6caec4705fd950cdd15ded97b7e972f13076..703e8fc307c499659bbd21e36882bee18a39be7d#discussion_r296654422 ?
<Chipaca> #7024 is a nice simple mostly-mechanical PR if you're feeling like it
<ondra> mborzecki what is that diff for? I think you are diffing too many commits, PR is just one small commit
<mborzecki> ondra: wrong link last time, try this one: https://github.com/snapcore/snapd/pull/7023#discussion_r296654422
<pstolowski> mborzecki: 6997 can land
<mborzecki> pstolowski: great, landing now ;)
 * zyga is feeling so so due to driving and working
<Chipaca> zyga: https://www.youtube.com/watch?v=52ogQS6QKxc
<zyga> Chipaca: if that scales to 13" panels I'm happy
<Chipaca> now trying to find dobey's twitter handle to point him at it :)
<zyga> I will be joining shortly
<mborzecki> cachio: standup?
<ogra> zyga, https://i.ebayimg.com/images/g/IwQAAOSwvUlWsxE6/s-l640.jpg scales it to 13"
<ogra> like in https://www.youtube.com/watch?v=rXW32WB3Xm4
<ogra> ppisati, sniff ... found a kernel bug with "sudo modprobe bcm2835-v4l2" ... https://paste.ubuntu.com/p/xB8JcJXGx9/ ... the pi camera works fine when using it via the python lib
<ogra> (just not when trying to get a v4l device for it)
<ppisati> ogra: open an LP bug, how to reproduce it, etc
<ogra> yeah, will do
<ogra> havent tried core18 yet, perhaps 4.15 behaves better (but UC18 is a pain to use for development, missing all ools i like to use)
<ogra> *tools
<ogra> ppisati, https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1834039 is yours
<ppisati> ogra: so, just loading the kmod oops the kernel?
<ackk> jdstrand, hi, around?
<pstolowski> yay, travis finally believed me when i say i signed CLA
<jdstrand> ackk: I am, though I am preparing for/about to attend a meeting, so feel free to ask and I can either answer quickly or circle back
<ackk> jdstrand, just to confirm, with the patched snapd for the system users it should be possible to call setgroups(0, NULL), correct?
<jdstrand> ackk: yes, but your application needs to be modified to do it if it is calling setgroups some other way.
<jdstrand> (eg, patch or LD_PRELOAD)
<jdstrand> snap run --strace ... will show you how it is being called
<jdstrand> ackk: also, fyi, I will be picked up that PR this week. there will be some minor snap.yaml changes but otherwise it will work as you've been testing it
<jdstrand> picking*
<ackk> jdstrand, yes, that's what I have, the preload ends up calling it with 0, NULL
<ackk> jdstrand, awesome, any ETA on when it will be available in a release?
<jdstrand> ackk: considering the focus on uc20 this week and the people who would review it are sprinting this week, there probably isn't going to be much movement for a week or two (I have a lot to do and will do it, but then need reviews, etc)
<ackk> jdstrand, ok, cool
<ackk> thanks
<jdstrand> ackk: I say that cause I don't know the timing of 2.40. I guess it is possible to be in that, but more likely 2.41
<jdstrand> ackk: they want it, so it is possible if I get to everything this week while they are sprinting (my plan), then they'll make it required for 2.40
<jdstrand> we'll see
<ackk> jdstrand, ok, thanks for the info
<marcustomlinson> hey snappy brains. Have you ever thought about the possibility of allowing snaps to perform additional install time operations?
<ogra> ppisati, yep, exactly
<marcustomlinson> I was thinking of the slow first launch situation we face with some snaps. Would be cool (maybe? I think so at least) if we could offload some of that required initial config to the install
<seb128> marcustomlinson, https://docs.snapcraft.io/supported-snap-hooks ?
<ogra> marcustomlinson, the prob here is that many bits that cause slowness are related to putting bits and pieces into SNAP_USER_DATA ... at install time you dont really have that around (apart from the ability to forcefully put pre-cached files into every users home)
<marcustomlinson> ogra: ah
<marcustomlinson> seb128: thanks, that is also useful info
<seb128> np
<zyga> re
<zyga> 39C
<zyga> halp
<ogra> jdstrand, hmm ... so i'm playing with a Pi camera attached via the CSI interface of the Pi, not usb ... using the picamera python lib i can access the camera via /dev/vchiq ... for access to that device node i need to use the opengl interface instead of the camera interface which feels a bit unlogic (but such is the Pi in itself :P ) ...
<niemeyer> mup: Hello.. are you alive and kicking?
<pstolowski> sergiusens: hey, can take a look at https://github.com/snapcore/snapcraft/pull/2609 ?
<mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
<mup> PR snapcraft#2609: schema: allow 'snapd' snap type <Created by stolowski> <https://github.com/snapcore/snapcraft/pull/2609>
<niemeyer> mup: o/
<mup> niemeyer: In-com-pre-hen-si-ble-ness.
<ogra> jdstrand, i wonder if we could have vchiq added to the camera interface too so i could use the camera interface here
<sergiusens> pstolowski: sure. Right after I finish picking up my son from school
<pstolowski> sergiusens: ty!
<mup> PR snapd#6995 closed: gadget: fallback device lookup <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6995>
<mborzecki> yay, mup is back
<niemeyer> Yeah, sorry about that
<niemeyer> I'll patch it so this manual action isn't necessary as soon as I can stop traveling for a few days
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7026
<mup> PR #7026:  cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/7026>
<zyga> mborzecki: draft, I will likely split the patch into several but I _think_ this is mostly it
<mborzecki> niemeyer: thank you!
<mup> PR snapd#7026 opened:  cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/7026>
<mborzecki> zyga: ok, looking
<zyga> thank you
<zyga> I'm in a tunnel, spread running
<zyga> will see
<zyga> mborzecki: it passed locally
<zyga> trying on core16 next
<zyga> as there are usually dragons there
<mup> Bug #1834061 opened: qt apps in hidpi looks tiny <Snappy:New> <https://launchpad.net/bugs/1834061>
<ogra> bah ... kyrofa, sergiusens, did https://github.com/snapcore/snapcraft/pull/2322 not land in a stable snapcraft yet ? or can you not use it with the python plugin ?
<mup> PR snapcraft#2322: project_loader: add build-environment part property <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2322>
<ogra> i'm getting: "Failed to load plugin: properties failed to load for picamera: Additional properties are not allowed ('build-environment' was unexpected)"
<kyrofa> ogra, it landed ages ago, but are you specifying a base?
<ogra> nope, building for core16 so no base
<kyrofa> ogra, try `base: core`
<kyrofa> That will opt into the "new" snapcraft
<kyrofa> But still build for core16
<ogra> ok
<kyrofa> If you're not specifying a base, you're essentially still using snapcraft v2
<ogra> well, lets see what build.s.io thinks now
<ogra> the big sillyness of the week ... all raspberry pi pip modules force-run a test if they are getting built on a pi ... if not they fail ... to override it you need to export "READTHEDOCS=True" ... so intuitive !!!
<jdstrand> ogra: I've taken a note to look at that
<ogra> jdstrand, thanks ... it isnt a blocker or anything ... just feels more natural to use camera for cameras :)
 * jdstrand nods
<ogra> Issues while validating snapcraft.yaml: The 'parts/picamera/build-environment[0]/READTHEDOCS' property does not match the required schema: True is not of type 'string'
<ogra> GRRR !!!
<mborzecki_> zyga: left some comments
<mborzecki_> zyga: best if jdstrand takes a look as well
<zyga> mborzecki_: thank you, looking
<mborzecki> zyga: i noticed that selinux raised something in your PR
 * Chipaca EODs
<cjwatson> ogra: READTHEDOCS: 'True'   if you haven't figured it out already
<sergiusens> kyrofa: do you have time this week to work with cachio on why the catkin-pull tests fail on the gce images?
<cachio> sergiusens, kyrofa do you have logs?
<sergiusens> cachio: here's one failure https://travis-ci.org/snapcore/snapcraft/jobs/548801440
<cachio> sergiusens, the error is related to the repo (Failed to update the package cache)
<sergiusens> kyrofa: I guess a quick trick we can do is just add a PR that prints out apt's configuration
<cachio> sergiusens, kyrofa it would be nice if you add debug: to the test
<cachio> then it will print all the debug info you want to see in case the test fails
<sergiusens> cachio: yes, because `  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY F42ED6FBAB17C654`, but xenial doesn't enforce that by default
<sergiusens> so the theory is that the images were modified to enforce it
<sergiusens> cachio: do you have an example of that? I suppose it does not require calling `spread` with `-debug`
<cachio> just add debug:
<cachio> to the test
<cachio> and then the scirpt you want to run to get debug info in case of failure
<cachio> https://github.com/snapcore/snapd/blob/master/tests/main/appstream-id/task.yaml#L13
<cachio> sergiusens, this is anexample
<cachio> the first I found
<sergiusens> cachio: `debug` is only triggered on errors and before `restore` is run, correct?
<cachio> sergiusens, yes
<sergiusens> cachio: kyrofa if so, then https://github.com/snapcore/snapcraft/pull/2610
<cachio> sergiusens, debug: |
<sergiusens> cachio: even if it is a one liner? I'll fix it regardless in case it becomes a N liner
<cachio> sergiusens, Failed to fetch http://us-east-1.ec2.archive.ubuntu.com/ubuntu/pool/main/a/apt/libapt-pkg5.0_1.2.32_amd64.deb
<cachio> sergiusens, which images are you using?
<sergiusens> cachio: https://github.com/snapcore/snapcraft/blob/master/spread.yaml#L35
<sergiusens> cachio: fortunately, those network errors are transient ones from Travis, we have not reached the spread stage yet
<cachio> sergiusens, yes, reading the https://github.com/snapcore/snapcraft/blob/master/.travis.yml
<cachio> the alternative to skip this errors could be to create a spread tests which runs the unit tests
<cachio> so you just need to install spread and then you run everything in gce
<cachio> and you acn run units tests together with the rest of the spread tests
<sergiusens> oh, it is transient and moving that to spread has been in our thoughts
<cachio> or you can keep it in deferent stages if you want
 * cachio afk
#snappy 2019-06-25
<df00z> Hm, would it be an abuse of snap to try to package up libvirtd + qemu + virt-manager with snappy?  It can register services with systemctl and run as root, right?
<mborzecki> morning
<df00z> morning
<zyga> Good morning
<zyga> I will be around in a hour, need to get breakfast and take the dog out
<mborzecki> zyga: so the dog is travelling with you too? :)
<morphis93417> zyga, mborzecki: do you guys know if `snap save` is intended to show me all snapshots? I can see way more in /var/lib/snapd/snapshots than in `snap save`
<mborzecki> morphis93417: snap saved?
<morphis93417> ah
<morphis93417> the output looks quite similar
<morphis> just run into the issue that our CI system ran out of space because of the automatic snapshot creation on remove
<morphis> 100GB of snapshots ...
<mborzecki> morphis: i think you want snap remove --purge
<mborzecki> morphis: though it's probably for 2.40
<morphis> is there another way to purge or avoid the automatic snapshot?
<mborzecki> morphis: i don't think so, but pstolowski|afk or Chipaca will know more
<morphis> hm, that is unfortunate
<mborzecki> morphis: looked throught the forum, you can set `snap set system snapshots.automatic.retention=no` that should stop snapshots from being created
<morphis> mborzecki: looks like it doesn't for the creation on snap removal
<mborzecki> morphis: https://forum.snapcraft.io/t/snapshots/9468 states 'Disabling automatic snapshots will not affect pre-existing automatically generated snapshots, only those generated by the removal of subsequent snaps.'
<morphis> yeah read that
<mborzecki> morphis: looks like you need to drop the old ones manually, but new ones should not be created
<morphis> mborzecki: yeah, looks like that's it
<df00z> Oh jeeze.   I get to the end of my package compile and it says linker version 2.3.3 isn't compatible with files in this app.
<df00z> I dont want to\cant build this in an ubuntu 16.04 env
<df00z> Not possible to move past that, right?
<mborzecki> df00z: can you use a core18 base instead? that should be like 18.04 env
<df00z> Ugh maybe but probably not.   Building something that needs up to date libs(qemu, libvirt)
<df00z> The whole point of me trying to use this was to avoid managing /usr/local or something awful for a custom build
<jamesh> df00z: it sounds like you've got snapcraft running in legacy mode.  Make sure you've got a "base:" key at the top level, set to "core" or "core18"
<df00z> let me try it
<jamesh> that will switch snapcraft over to building in a VM (for which you'll need to install Multipass) with appropriate libraries to match the base
<df00z> weird I put base: core18, it worked, didnt try to start any kind of VM that I can see
<df00z> I'm on 19.04
<df00z> Unless it only does that with cleanbuild
<zyga> Breakfast time
<zyga> I will be back around 9-10. Once we pack and hit the road again
<df00z> i gotta head to sleep.  i think it worked?  maybe coincidentally because 19.04 isn't using an incompatible linker?
<mborzecki> df00z: afaik it's built in a clean environment, so perhaps you already have multipass, or it just spun up a lxd container
<df00z> long term im probably going to have to build parts for the entire dependency chain...theres gotta be like 50 libs though
<df00z> for now i only built gnutls as a part which ubuntu doesnt have an up to date release that is compatible in it's repo
<zyga> I will be around shortly
<pstolowski> morning
<mborzecki> pstolowski: hey
<pstolowski> morphis: hi, all clarified re automatic snapshots afaict? old ones need to be removed manually with snap forget
<ackk> hi, anyone familiar with non-root users in snap?
<mborzecki> ackk: non root users in snaps with services?
<ackk> mborzecki, I mean the work for being able to use system users in the snap
<mborzecki> ackk: there was a PR from jdstrand but I don't know where it stands at this point
<ackk> mborzecki, right, I'm testing with a snapd built from there
<zyga> re
<zyga> finally all packed and on the road
<ackk> mborzecki, I'm having a weird issue. I pass in the "daemon" user and I have a dir under $SNAP_COMMON that's owned by it (daemon:daemon). If I try to delete it from the app, it gets permission denied. that's understandable if I run it as root, but it happens also if I drop privileges to daemon:daemon
<ackk> mborzecki, so I'm not sure how to handle that
<zyga> it's hard to pack three kids and a dog
<zyga> mborzecki: yeah, so there was a selinux denial
<zyga> mborzecki: question: should a program that is selinux aware actively set the context of a file it creates?
<ackk> zyga, is that like the wolf sheep cabbage problem? :)
<mborzecki> ackk: maybe soemthing inside is now owned by daemon?
<zyga> mborzecki: or should this be done from the policy side?
<zyga> ackk: it's a OMG why did we agree to do this problem :)
<zyga> ackk: driving across europe with our family, including a small baby
<mborzecki> zyga: labels are inherited from parent, unless there's an automatic transition defined
<zyga> mhm
<ackk> mborzecki, not that I can see it, it's all daemon:daemon
<zyga> mborzecki: I didn't look yet but I don't quite get it why the new .info file is any different from the exisiting .fstab or .mnt files
<zyga> mborzecki: so I'll get to selinux shortly, I'll read your review first
<Chipaca> zyga: also to spain?
<zyga> Chipaca: yeah, we are approaching the coast now, south of france
<zyga> from there just a short ride to Palamsos
<zyga> Palamos
<Chipaca> zyga: Palimpsest
<zyga> Chipaca: looking at the car nav, seeing the destination being 4 hours away is surreal
<zyga> Chipaca: normally I would say that is far away
<zyga> Chipaca: but after the last few days that's nearly nothing and 4 hour trip is short and easy in comparison
<Chipaca> zyga: I know that feeling
<Chipaca> I remember getting up one morning, thinking "yeah, this morning we'll go get fuel, that's just â¦ 3 hours south of here, we should make it back in time for tea, easy
<Chipaca> "
<zyga> *fuel*?
<zyga> as in gasoline?
<Chipaca> zyga: yes
<Chipaca> zyga: we were in San Antonio Oeste, and the fuel on the other side of parallel 42 was 50% cheaper
<Chipaca> or maybe more? don't remember exactly. Cheap enough to make it a no-brainer.
<Chipaca> then the next day we did the trip again, this time to see seals and penguins and whales and stuff
<zyga> wow, that's quite the story
<Chipaca> zyga: patagonia resets your near/far scale in less than 24 hours :)
<Chipaca> it's humbling and fantastic and awesome and stuff
<Chipaca> (to be clear: argentine patagonia, which is mostly an arid peneplain of nothing but stout shrubs
<Chipaca> )
<zyga> passing some nuclear plant in france now
<zyga> kids watched chernobyl a little
<zyga> at first they way "is it real"
<zyga> but now they just watch
<Chipaca> zyga: is that the one where radiation sickness is contagious?
<zyga> a-choo
<zyga> lavender fields
<Chipaca> #7028 and #7027 are simple enough and need a second review
<Chipaca> (and if you've looked at the user agent pr you've already looked at these)
<zyga> I'll look
<zyga> ah great
<zyga> that split out is nice and simple
<Chipaca> yeah
<Chipaca> kudos to james
<Chipaca> pstolowski: one for you: https://forum.snapcraft.io/t/does-snap-refresh-trigger-the-disconnect-connect-hooks/11997?u=chipaca
<pstolowski> Chipaca: ok
<ackk> mborzecki, I have a minimal python script+snap which reproduces the issue. it seems it happens if I have subdirs of that dir, also owned by daemon:daemon
<ackk> mborzecki, https://paste.ubuntu.com/p/kw8swvZS2m/
<ackk> mborzecki, both that and with the last commented line in place of the plain os.rmtree fail
<zyga> Chipaca: I left a review on the systemd PR that is more complex than my initial reaction
<zyga> https://github.com/snapcore/snapd/pull/7028#pullrequestreview-253865824
<zyga> IMO it is okay to merge but perhaps it'd be worth to look
<zyga> ok, next one
<zyga> Chipaca: do you know why we do this: https://github.com/snapcore/snapd/pull/7027/files#diff-98811fc63f73eed00da99c36c7326aabR72 ?
<Chipaca> zyga: why would we pass true?
<zyga> I don't understand why we'd pass either
<zyga> do we need those after?
<zyga> why is it relevant to not unset those variables?
<Chipaca> zyga: the API call needs one or the other
<Chipaca> I mean, it takes a boolean
<Chipaca> choose one
<Chipaca> it's a silly thing, just calls Unsetenv on the appropriate environment variables if it's true
<Chipaca> which means you can't grab the sockets again
<zyga> aha
<zyga> and we want to have them again?
<Chipaca> in tests, sure
<Chipaca> outside of tests, no -- but we don't
<zyga> ok
<Chipaca> zyga: otoh if the environ leaks to anything we exec we might want to clear it
<Chipaca> zyga: nothing is breaking today :-)
<zyga> Chipaca: how about this? https://github.com/snapcore/snapd/pull/7027/files#diff-98811fc63f73eed00da99c36c7326aabR56
<zyga> why 111?
<Chipaca> zyga: given that 7028 is green, can we land it without the --no-block in the panic?
<zyga> yep
<zyga> https://github.com/snapcore/snapd/pull/7027#pullrequestreview-253874672 is +1
<zyga> so both can land
<mborzecki> ackk: maybe apparmor blocking this? nothing apparmor related in dmesg?
<Chipaca> zyga: because we want the socket to be 0666
<Chipaca> zyga: without having to chmod it after the fact
<Chipaca> at some point we're going to have to use dynamic loading or something, to keep the snap command in check :-)
<Chipaca> a bit like git foo â git-foo
<Chipaca> especially for the long-running versions of things
<zyga> why?
<zyga> to keep them small?
<Chipaca> zyga: yeah
<Chipaca> zyga: having along-running snap command that has all the libs the snap command itself has seems strange
<zyga> I wish go had a dynamlically linked "libc-of-go"
<zyga> so that hello world was small
<zyga> eh
<ackk> mborzecki, I only get this error: https://paste.ubuntu.com/p/yX5N6xxRrj/
<Chipaca> zyga: that should be doable, but i doubt it'd gain traction with the devs
<zyga> ackk: looks like regular permissions are the problem
<Chipaca> even simple dynamic loading is under-supported
<ackk> zyga, wdym?
<zyga> ackk: you get a denial for cap override
<zyga> er
<zyga> dac override
<ackk> zyga, should I add that plug?
<ackk> seems weird
<mborzecki> ackk: that happens when acting as root on stuff that you wouldn't have access to given its permission bits & owner
<zyga> ackk: I doubt so
<zyga> (I would not add that plug)
<zyga> ackk: what mborzecki said
<ackk> one sec, trying now to remove as daemon user
<zyga> the only reason root can access stuff it normally cannot access is because it has DAC override capability
<zyga> but the profiles take that away
<ackk> zyga, mborzecki I get the same error if I try to remove as daemon user
<ackk> (iow after dropping privileges)
<zyga> feeling a bit sick from looking at the screen
<zyga> mborzecki: you were right
<zyga> buth, only three hours left
<zyga> so close now
<mborzecki> zyga: hm?
<zyga> mborzecki: looking down while moving
<mborzecki> zyga: ah yeah ;)
<mborzecki> so the image tool is using sfdisk now, though the script syntax is kind of ugly
<mborzecki> ackk: apparmor denial this time too?
<ackk> mborzecki, same
<Chipaca> zyga: if it makes you sick, then STOP DOING IT
 * Chipaca whacks zyga over the head with some large mythological fish
<zyga> Chipaca: yeah, I try to look outside the window as much as I can
<zyga> Chipaca: 3 hours 14 minutes left
<Chipaca> popey: you around?
<zyga> we'll break after passing montpellier but now lucy is sleeping so as much as we can push it
<ackk> mborzecki, ah, it only works if the directory containing the one to delete is 0777
<popey> Chipaca: for you, always
<ackk> mborzecki, which poses a problem because I can't really change $SNAP_COMMON to be 777
<Chipaca> popey: Wimpress: any way i should tag https://forum.snapcraft.io/t/getting-taskade-linux-app-featured/12005?u=chipaca so you guys are sure to notice it?
<Chipaca> popey: <3
<popey> i have seen it :)
<Chipaca> popey: right, but if you hadn't?
<Chipaca> (thanks for confirming)
<Chipaca> we don't have an advocacy-requests category :-)
<mborzecki> ackk: it shouldn't happen for test-dir/sub though
<ackk> mborzecki, wdym?
<ackk> mborzecki, if I os.chmod('test-dir', 0o777), then test-dir/sub can be removed, but to remove test-dir I'd need to chmod $SNAP_COMMON
<mborzecki> ackk: i see you're using shutil.rmtree(test_dir), if you do shutil.rmtree(sub_dir) it should work
<popey> i thought we had a snap-advocacy group
<ackk> mborzecki, well, yes and no. in the real case that's a large tree of files/dir, I'd have to recursively chmod everything
<mborzecki> ackk: ah, ok
<popey> oh, we do @advocacy is us
<ackk> mborzecki, also I'd have to remove everything inside the dir manually if I can't remove the whole dir
<Chipaca> popey: so i should just say "yo @advocacy"?
<ackk> mborzecki, in general, that's a problem, if you can create dirs and you can't remove them :)
<popey> Chipaca: ya, i think that would work
<Chipaca> popey: k
<zyga> less than 3 hours left
<zyga> Break time
<Chipaca> zyga: https://www.youtube.com/watch?v=otCpCn0l4Wo
<Chipaca> and it's ubuntu one all over again
 * Chipaca takes a break also
 * Chipaca lied
<Chipaca> now yes, i'm off for a bit
<petan> hello I would like to create a script that will release all stable versions of my software for all platforms (eg. set them to current head / latest build)
<petan> how would I do that?
<petan> if I know specific number I can do something like snapcraft release huggle 2146 stable
<petan> but can I substitute the number 2146 with "whatever is latest"?
<mborzecki> petan: i have a vague recollection of version script that can do that
<mborzecki> petan: this is how snapd does that https://github.com/snapcore/snapd/blob/master/snapcraft.yaml#L11-L12
<mborzecki> fun review if anyone's interested: https://github.com/snapcore/snapd/pull/7030
<mborzecki> zyga: do you want me to look into the selinux denials you got?
<zyga> mborzecki: if you know how to fix that quickly, sure, it will help a lot
<zyga> Break is over, back to work
 * zyga melts in the sun
<mborzecki> pstolowski: what was the problem that triggered https://github.com/snapcore/snapd/pull/7029 ?
<Gargoyle> How come this exists: https://snapcraft.io/sublime-text-bartixxx ? It makes the store confusing.
<zyga> Gargoyle: indeed, I think it should be removed, perhaps popey has an opinion?
<pstolowski> mborzecki: some kind of udev event is too big, i haven't seen this myself, i asked abeato for udevadm monitor output when this happens
<mborzecki> pstolowski: was there a forum topic perhaps?
<pstolowski> mborzecki: no, it was all discussed here and the bug report is the record of it
<pstolowski> mborzecki: fwtw, $ getconf PAGE_SIZE
<pstolowski> 4096
<pstolowski> that's the value we effectively used
<mborzecki> pstolowski: right, but it was increased in the loop with MSG_PEEK until the messag would fit
<pstolowski> mborzecki: but the logic was bogus imho
<pstolowski> mborzecki: mborzecki MSG_PEEK - This flag causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue.  Thus, a subsequent receive call will return the same data.
<abeato> pstolowski, mborzecki I've seen this happening on boot, when a lot of udev events accumulate
<zyga> mborzecki: question
<zyga> mborzecki: should I switch to error handler (as opposed to die)
<zyga> mborzecki: so that I can write tests that don't have to fork to work?
<zyga> mborzecki: gtest is pretty frustrating when you have to test code that die's at all errors
<pstolowski> mborzecki: there is no mention for using it to probe buffer size; to my understanding it simply leaves the data in the queue but still errors out if buffer is too small, no?
<mborzecki> pstolowski: yes, that's the point of MSG_PEEK :)
<abeato> pstolowski, one interesting thing to note is that what systemd does is increasing the socket RECV size to 128MB - in general that is fine as you are only reseving a range virtual addresses in the end. Usually you do not use all
<mborzecki> pstolowski: abeato: fwiw their actual buffer to which they receive stuff is 8k only
<abeato> mborzecki, right, as long as they have buffer space in the kernel side, that's fine - probably there is not a single event thas is 8K
<mborzecki> abeato: yup, so they use super careful 128MB on the kernel side, where events get buffered (althouhg never reach this size), while the usespace reads 8k at a time
<abeato> mborzecki, that seems to be the case, yes
<popey> zyga: sounds like a store question
<jdstrand> ackk: I'm here if you want to talk about the daemon user. note there are a bunch of things at play here for file access: apparmor, seccomp, capabilities, traditional permissions
<ackk> jdstrand, hi, so did you see the discussion from this morning?
<ackk> jdstrand, basically for now I've worked it around by removing everything in the dir manually
<jdstrand> ackk: so, if you create a directory, and chown it to daemon:daemon then the daemon user can use it, etc. *but* it can't delete the directory if the parent dir is say, 755 root:root and root can't delete the dir because it lacks dac_override
<jdstrand> ackk: I intentionally left out dac_override since it grants way too much and the snap can be written to not need it
<ackk> jdstrand, mhm so is there a way to go around it without having to manually clean dirs?
<jdstrand> ackk: you probably want to create the directory 775 root:daemon
<ackk> jdstrand, ah, interesting
<ackk> jdstrand, we have some dirs that are the other way, daemon:root 775
<jdstrand> ackk: that may work too. the files should be 664 as well if you want root to be able to clean them out
<ackk> jdstrand, mhm, the problem is that we're talking about the postgres DATA_DIR, so I only create the root, then postgres (which runs as daemon.daemon) does the rest
<zyga> mborzecki: did you see my question earlier
<zyga> mborzecki: I'm unsure how to test this, I'm eager to proceed with error return and easy tests
<zyga> mborzecki: and die in the caller
<mborzecki> zyga: sounds ok to me
<zyga> k
<jdstrand> ackk: well, set it up however. I'm just saying you'll have the same issues with files if they are daemon:daemon and root tries to delete them because of how apparmor works
<ackk> jdstrand, sigh also even if I set the dir to 775 postgres changes it back to 700 :(
<jdstrand> ackk: ok, you should be able to work through the without patching anything
<jdstrand> ackk: you create $SNAP_DATA/stuff root:daemon 770. then you create $SNAP_DATA/stuff/postgresdb 700 daemon:daemon
<jdstrand> ackk: then postgres, running as 'daemon' can do whatever it wants in $SNAP_DATA/stuff/postgresdb
<jdstrand> ackk: if for some reason you want to clean things out, daemon is able to delete $SNAP_DATA/stuff/postgresdb and below, and root can delete $SNAP_DATA/stuff
<ackk> jdstrand, ah I see
<jdstrand> ackk: with a bit of care, dac_override can pretty much always be avoided and when it is avoided, you know that the code got its priv separation right. in your case, postgres is doing fine and you're just wrapping it so it works, but I recall dhcpd having trouble getting this right in their code
<jdstrand> ackk: where we have a profile for it. the deb packaging set up the dirs wrong assuming dhcpd would just clean things up when it started as root before it dropped
<jdstrand> ackk: but then it didn't do that correctly for several releases (and it was funny cause you could see them trying because the behavior changed with each release), until finally they did
<jdstrand> everything aligned and dac_override wasn't needed any more
<jdstrand> (the same generally goes for dac_read_search)
<jdstrand> ackk: thanks for bringing this up btw. I've added a todo to document this when documenting the feature (it is in the policy, but who reads that? ;)
<ackk> jdstrand, thank you for the help
<jdstrand> ackk: np
<Chipaca> cachio: standup?
<ackk> jdstrand, so it seems the only caveat is that if you create directories that are owned by a non root user directly under SNAP_DATA/SNAP_COMMON/etc you can't ever remove them anymore
<jdstrand> ackk: that is possible, yes, but snap remove always can
<jdstrand> which is why I want to document it
<jdstrand> one could also plugs log-observe, but when people ask for auto-connection, it'll come up and we can direct them ("why does postgres need access to the system logs?")
<ackk> jdstrand, yeah I meant from the point of view of a snap
<ackk> jdstrand, log-observe doesn't make it work though
<ackk> at least, in my test this morning
<ackk> or, uhm
<ackk> maybe I didn't test it right
<ackk> jdstrand, btw, I filed a few bugs related to the confined snap work, any chance they could get fixed soon: https://bugs.launchpad.net/snapd/+bugs?field.tag=maas ?
<jdstrand> the first two are known. I can look at the last two. I have a PR up that I can fold those into
<ackk> jdstrand, awesome, thanks!
<Chipaca> zyga: when you arrive somewhere stable, there are weird things in the forum i'd like you to look at
<zyga> Ok
<Chipaca> zyga: i've flagged you in them so i/you/we don't forget :-)
<zyga> Perfect, thank you
 * pstolowski lunch
<mborzecki> zyga: ok, so figured out some of the tmpfs stuff, i don't think we can plug it nicely now, but otoh it's probably ok to allow s-c readlink there
<mborzecki> zyga: still don't see how the changes trigger this behavior
<Chipaca> cachio: how's validation of 2.39.3 going?
<zyga> mborzecki: right?
<zyga> mborzecki: it's another file
<zyga> mborzecki: we have a few of those already
<zyga> mborzecki: maybe it is because when snap-confine calls snap-update-ns some things magically change?
<zyga> mborzecki: snap-confine no longer writes to that tmpfs, apart from making an empty file
<zyga> mborzecki: once we have snap-bootstrap-ns this can move there (to go)
<mborzecki> zyga: something funny is going on behind the scenes, tmpfs gets a tmpfs_t label, unless there's some transition, what happens is that a bunch of directories is labeled as tmpfs_t and maybe that's a problem
<mborzecki> zyga: take a look at this: https://paste.ubuntu.com/p/Hmkrs3Yhxp/
<mborzecki> zyga: see how /etc and /run are tmpfs_t in mount ns of the snap?
<zyga> mborzecki: what should that directory type be?
<zyga> mborzecki: the hierarchy in /run/snapd/ns is managed by snap-confine
<cachio> Chipaca, I am reviewing the last log for i386
<Chipaca> cachio: cool cool
<cachio> and it should go to candidate
<mborzecki> zyga: etc_t or var_run_t for /run
<mborzecki> etc_t for /etc ofc
<Chipaca> cachio: let me know when/if it's done so I can poke people about it please
<cachio> Chipaca, sure
<cachio> I am trying to reproduce an issue
<mborzecki> zyga: i think it's an artifact of us setting up the mount ns, perhaps we should restore the labels (?) the auto transition doesn't work bc it's named or otherwise
<zyga> mborzecki: so we don't mount a tmpfs ourselves there
<zyga> mborzecki: but we do make a bind mount in /run/snapd/ns
<zyga> mborzecki: and change the propagation mode of that mount
<zyga> mborzecki: once I'm at home I will boot fedora and explore
<zyga> mborzecki: I only have ubuntu on the go
<mborzecki> zyga: we already allow s-u-n to poke tmpfs_t, so I'll push a patch that allows s-c to your branch
<zyga> thanks!
<zyga> I'm adding tests now
<mborzecki> zyga: and we can investigate later, as i suspect it'll take more work
<zyga> yeah, I think so
<Chipaca> popey: do we know any kde devs that hang around the forum? https://forum.snapcraft.io/t/bug-on-web-page-https-forum-snapcraft-io/12013?u=chipaca
<popey> Chipaca:  sitter is on the forum.
<Chipaca> popey: ta
 * Chipaca tagged them in the post
 * Chipaca goes to get a cuppa tea, and maybe some cake
<mborzecki> zyga: this is what ends up with tmpfs_t label https://paste.ubuntu.com/p/fvnh98t27k/
<mborzecki> zyga: oh and pushed a patch to your branch, please fetch before pushing
<zyga> mborzecki: looking
<zyga> mborzecki: sure, no force push!
<ijohnson> hey folks, I'm trying to seed a classic image with a gadget snap and not use a brand store, but on boot/seeding snapd seems to think it needs to get a serial from the public store: https://pastebin.canonical.com/p/fCpRXvDcbV/
<ijohnson> snapd seems to work fine otherwise, I can install snaps and such and even login with `snap login`, but I'm just wondering if there's a way to turn off this behavior where it tries to get a serial
<zyga> ijohnson: I think that is unsupported
<zyga> you must use a vault to use a custom gadget
<zyga> ijohnson: it will go to the store to get a serial
<ijohnson> zyga: hmm that's not great
<zyga> ijohnson: but the public store only gives serials to canonical models
<zyga> ijohnson: it is part of the design, it is unreasonable for one brand to sign serials of another
<ijohnson> zyga: the use case here is building a local gadget snap that exposes slots so that we can use a strictly defined snap with gpio pins and such
<ijohnson> right that's fine I don't want it to get a serial
<Chipaca> ijohnson: everybody gets a serial tho
<zyga> ijohnson: that's a separate concern
<zyga> ijohnson: serial assertion is a part of the flow
<zyga> you will hit other issues this way
<ijohnson> hmm so what would your recommendation be for getting slots and auto-connection rules via a gadget on a classic image that is not connected to a brand store?
<ijohnson> how necessary is it that everyone gets a serial?
<zyga> ijohnson: don't do that?
<zyga> ijohnson: very
<ijohnson> :-(
<zyga> ijohnson: what is the motivation for slots and gadgets on classic?
<zyga> ijohnson: can you tell us more about that
<ogra> i must admit that i have never seen any issues caused by missing serials on my dev images
 * cachio afk
<ijohnson> to use a strictly confined snap that needs to use gpio ports
<zyga> ijohnson: can we make gpio hot-pluggable
<zyga> so that you don't need classic gadgets at all
<ogra> zyga, gpio, i2c, spi all come from the gadget, not core
<zyga> ogra: I know, but now we have a better method for at least some of those
<ijohnson> we convince folks to make their device snaps strict, then we don't provide a way to use those snaps on classic without a gadget
<ogra> if hotplug works for that that would indeed be awesome
<zyga> ogra: the basics work, it is now per-interface to expand them
<Chipaca> mborzecki: 'basename', one word, is already a unix command
<Chipaca> mborzecki: we have things that are bases
<Chipaca> mborzecki: 'base name', therefore, would be the name of the base
<Chipaca> --base-name=core18
<Chipaca> mborzecki: probably not what we want
<ijohnson> zyga: I think hotplug gpio is orthogonal to this
<ijohnson> zyga: my larger concern is about how we can get folks to use these strict device specific snaps without telling they always need to be on core or have a brand store
<zyga> ijohnson: I disagree,
<zyga> ijohnson: classic gadgets are well defined
<mborzecki> Chipaca: right, sounds fishy when you put it like this, Basename like you had it is probably ok then
<zyga> ijohnson: use of gadgets for slots is a special case
<zyga> because we lacked hotplug support
<ijohnson> but gpio ports aren't fundamentally "hotpluggable" so it seems confusing to me
<Chipaca> mborzecki: to be fair I'd already written a comment agreeing with you when it struck me :-)
<mborzecki> Chipaca: hahah ;)
 * zyga just crossed the border
<zyga> finally not roaming anymore :)
<zyga> wooot
<zyga> ijohnson: sorry, lost some messages
<zyga> ijohnson: hotplug is the confusing word
<zyga> ijohnson: the real meaning is dynamically discovered vs statically declared
<zyga> ijohnson: we got away with many slots being statically declared because they were not representing specific hardware but certain concepts
<jdstrand> roadmr: hi! can you pull 20190625-1410UTC ?
<roadmr> jdstrand: hello :) sure
<zyga> ijohnson: GPIO pins are not like that, they are hardware and you can actually discover them (even by reading dbts)
<zyga> ijohnson: so now that snapd has a method of dynamically adding and removing slots that represent hardware
<zyga> ijohnson: we should strive to make more hardware compatible with that system
<ijohnson> zyga: hmm so that all makes sense is the plan to make all device interfaces (i2c, gpio, etc.) dynamically discoverable then?
<zyga> ijohnson: I think so
<zyga> ijohnson: to the extent that is feasable
<zyga> ijohnson: primarily because linux already handles that
<zyga> ijohnson: it handles the custom ways to convey what the hardware is
<zyga> ijohnson: so that userspace doesn't have to worry and do it again
<ijohnson> right that's great but what to do in the meantime until that's done?
<zyga> ijohnson: fix it, walk towards the solution
<ogra> whistle and pretend it is already there ?
<zyga> ijohnson: would be worth checking how hard it is to handle gpio's this way
<ijohnson> ... so on a sacle from my device will start on fire to some failed changes in `snap changes` for the first 2 weeks that a device is running, just how bad of an idea is it to not have a serial
<zyga> ijohnson: pstolowski can offer suggestions I'm sure
<ijohnson> s/sacle/scale/
<zyga> ijohnson: I suspect pretty low, but that will change over time
<zyga> ijohnson: so while it might work now
<zyga> ijohnson: I would not recommend that as a general solution
<ogra> well, currently it is the nly solution to achieve what he wants
<ogra> *only
<ijohnson> okay so that handles my first concern which was connection of slots
<ijohnson> there still remains the question of auto-connection to certain snaps
<zyga> ijohnson: yeah, that will require a gadget
<ijohnson> auto-connection of slots to certain snaps
<zyga> ijohnson: and a brand and a vault
<zyga> ijohnson: I would love if we could host a vault for experimenters
<zyga> ijohnson: with self-provisioning
 * ijohnson thinks that there should be a way for someone building their own image to support this
<zyga> but we're not there yet
<zyga> yeah
<zyga> it's just not done yet
<ogra> does connections: in gadget.yaml not work ?
<ijohnson> ogra that's what I want to do
<zyga> yeah, that should work
<ogra> right
<ijohnson> (and am currently doing in a "sideloaded" gadget)
<zyga> hmmm
<zyga> that may not work
<ogra> i guess you eventually need to use ubuntu-image then
<zyga> but double check the source please
<ijohnson> any pointers to where I should check?
<ogra> to have all the bits and pieces correctly set up
<ogra> abeato, did you have a howto for ubuntu-image for classic images ?
<ijohnson> ogra: I have KyleN's doc
<ogra> that might be derived from his
<zyga> ijohnson: look at snapd's gadget code, grep for "connections" in overlord
<abeato> ogra, yeah, that is the one - there is an older one from Gary too
<ijohnson> zyga: thanks
<zyga> ijohnson: in my argument I was trying to not be against useful features but against making temporary workarounds for missing features, actual features
<zyga> ijohnson: I realize there are holes in our device bring-up story
<ogra> heh
<ogra> canyons ...
<ijohnson> yeah no problem I understand there's missing things
<zyga> I'll break until we arrive
<roadmr> jdstrand: hey so... there's no such tag in the current review-tools repo ;( did you forget to push maybe?
<jdstrand> roadmr: oh, I did. sorry
<roadmr> :)
<jdstrand> roadmr: done
<roadmr> thanks! trying again
<jdstrand> roadmr: I pushed the code days ago and not the tag
<jdstrand> (I created the tag today)
<roadmr> tags are like that :)
<popey> ogra: i was mistaken! Your qemu-virgil snap doesn't work with kvm either!
<popey> https://www.irccloud.com/pastebin/n71Ch7Yu/
<Chipaca> popey: it's all lies! all of it!
<Chipaca> popey: even the turtles!
<ondra> Chipaca ping
<Chipaca> ondra: poit
<ondra> Chipaca just checking if it's known that on core18 bash completion is not working. Did we drop support for bash completion on core18?
<Chipaca> ondra: we did not
<Chipaca> ondra: when you say 'on core18', what do you mean?
<ondra> Chipaca when you boot core18 device and shh into it, there is no bash completion for snap command
<Chipaca> hm
<Chipaca> ah, for snap itself? hm
<Chipaca> ondra: and for snapped apps?
<ondra> Chipaca it's not biggie, yeah for snap itself
<ondra> Chipaca I did not test actual snap apps
<Chipaca> ondra: the 'http' snap is a little snap that has minimal bash completion
<Chipaca> ondra: http --<tab> should give you useful options
<ogra> popey, hmm,  does sudo'ing work ?
<ondra> Chipaca yeah I think it's broken also for snap apps
<popey> no
<popey> I will come back to this another day, don't worry
<Chipaca> ondra: and if you install the 'core' snap, does it fix itself?
<ondra> Chipaca core is also installed there
<Chipaca> ah
<Chipaca> hm
<ondra> Chipaca and does not work without core either
<Chipaca> ondra: I'll make a note, and discuss with m vo next week (or maybe on thursday if it's not crazy hectic)
<Chipaca> as it's not clear to me who's forgotten to do which bit of integration :-)
<ondra> Chipaca sure, it's state for some time, so I can't image it's supper critical
<ogra> popey, works here ...
<Chipaca> ondra: but, quick checks: is /usr/share/bash-completion/bash_completion there in core18?
<ogra> ogra@acheron:~$ qemu-virgil --enable-kvm
<ogra> Gtk-Message: Failed to load module "unity-gtk-module"
<ogra> Gtk-Message: Failed to load module "canberra-gtk-module"
<ogra> Gtk-Message: Failed to load module "canberra-gtk-module"
<ogra> at that point i have a window up probing bios stuff
<ondra> Chipaca it was probably forgotten in core18 rush for the door days
<ondra> Chipaca no but there is /usr/share/bash-completion/completions/
<Chipaca> ondra: yeah those are useless without the main thing
<Chipaca> :-/
<Chipaca> sil2100: OHAI
<Chipaca> sil2100: are bugs in core18 a 'you' thing?
<ogra> sil2100, run !
<ackk> ondra, maybe related to https://github.com/snapcore/core18/issues/89 ?
<Chipaca> heh, indeed, that's not fixed yet is it
<Chipaca> :-(
<Chipaca> ondra: https://bugs.launchpad.net/snappy/+bug/1825254
<popey> ogra: are you in the kvm group?
<Chipaca> ondra: I thought that one was fixed, I should have started there
<ogra> popey, yep and i'm on 16.04
<popey> hm
<ogra> not sure if tat makes a difference
<ogra> *that
<popey> i am not, and if i add myself it doesn't show in groups
<ogra> re-logged in ?
<ogra> shows defiitely in "groups" output for me on 16.04
<popey> no, avoiding re-logging in, but tried starting a new bash and newgrp
<popey> I'll reboot
<ogra> perhaps 18.04 has a new way of managing access to kvm ... not sure
<ogra> (udev-acl or whatnot)
<ogra> in 16.04 the group stuff works if you have qemu-system-common installed (that ships the udev rule enabling the kvm group access to /dev/kvm)
 * ogra reads mail and humps Wimpress' leg !
<ogra> *woof*
 * Chipaca steps away from ogra 
<ogra> lol
<ondra> Chipaca yeah this seems like same bug
<Chipaca> ondra: yeap
 * Chipaca â afk (fetching car from the mechanic)
<ackk> ondra, fwiw it works for me when I also have "core" installed. but my case is a --classic snap, so maybe it's different
<ondra> ackk yeah I'm UC18 system
<popey> ogra: rebooted, still doesn't work on 18.04
<ogra> very weird
 * popey uninstalls things and starts again :)
<ogra> i'm pretty sure my virgil even defaults to usekvm
<popey> \o/ success
<ogra> oh ??
<ogra> how that ?
<zyga> re
<zyga> soooo happy to not be in a car now
<zyga> I'll do my best to get back to speed
<Chipaca> zyga: welcome to the world of people that aren't in cars!
<Chipaca> zyga: i thought i had two forum topics for you but the guy in the first one hasn't responded yet (probably in a different tz), so it's just the one
<Chipaca> zyga: no the other one
<Chipaca> :-p
<zyga> I started looking at the kail linux one now
<Chipaca> zyga: right, guy didn't respond but sure :-)
<Chipaca> zyga: the one linked from there, sil's one, is the one i meant had a bit more info
<Chipaca> zyga: but Â¯\_(ã)_/Â¯
<Chipaca> anyway, i should go see a barber about dinner
<Chipaca> or maybe separately, see a barber, and see about dinner
<zyga> I'm enjoying the non-moving landscape
<zyga> my head is dizzy as if I just got off a carousel
<zyga> Iâll look for some food
<zyga> Then catch up with PRs
<jdstrand> fnordahl: hey, I finally responded to the fuse question. sorry it took so long. It came in before the snapcraft summit then slipped of my radar for a bit
 * Wimpress wipes leg clean
<Wimpress> You're welcome ogra ð
<jdstrand> ogra: fyi, https://github.com/snapcore/snapd/pull/7019/commits/62d5e064fbd3b62445f03b953b37a0518886d5ad
<zyga> Zzzz
<diddledan> popey: to acquire new group assignments without re-logging-in or rebooting there is a command you can run in the terminal `newgrp` which will set that terminal session with the new assignment
<diddledan> you run it e.g. `newgrp kvm`
<diddledan> or just `newgrp` by the looks
<ogra> jdstrand, awesome !
<popey> diddledan: that didnt work, i had to reboot
<popey> ogra: ok, I get qemu launching, but with the various gl options, it segfaults with apparmor failing to get to /home/alan/.cache/mesa_shader_cache/index
<popey> I guess that's a hard-wired path somewhere
<popey> i reckon I can coerce that with MESA_GLSL_CACHE_DIR
 * diddledan wonders what popey is cooking-up with qemu and opengl
<ogra> popey, hmm, with qemu-virgil or with your implementation ?
<popey> currently with mine
<popey> but I ported yours to core18
<ogra> oh, neat
<popey> got it working, had to remove -soundhw ac97 as that was segfaulting
<ogra> yeah, sound is still on my list to look at
<ogra> there is some env var magic to make pulseaudio work
#snappy 2019-06-26
<df00z> Is multipass based on anything, like lxd, or is it it's own thing entirely?
<jamesh> df00z: it is a frontend for various virtualisation systems.  On Linux, it will generally create kvm/qemu VMs
<df00z> On ubuntu for snap?  I dont have qemu or kvm installed
<df00z> it seems to be launching some sort of container though
<jamesh> it launches a VM
<jamesh> kvm is the kernel support for virtualisation
<df00z> oh so it'll integrate with KVM directly, dont need qemu?
<df00z> it seems like a weird black box is all
<jamesh> most KVM based virtualisation systems use qemu
<jamesh> you need more than just a virtual CPU to run a VM
<df00z> when you use base: core18 in a snapcraft yaml file though it uses multipass, i dont have qemu installed
<df00z> i dont know how its launching a vm though i see it is
<df00z> unless they built qemu into the snapcraft snap, very well they could have
<jamesh> there is a copy of qemu in the multipass snap
<df00z> ah-ha, cool.
<df00z> im actually trying to build a snappy for qemu + libvirt, wondering if i am going to have to use classic security
<df00z> confinement
<df00z> that whole steam\wine debacle with ubuntu, couldnt they just release it with snapcraft
<df00z> other distros support multiarch, and snap
<mborzecki> morning
<mborzecki> super simple PR: https://github.com/snapcore/snapd/pull/7034
<mborzecki> got a quick errand to run, bbiab
<jamesh> df00z: there is a kvm interface that should let a strict confined snap use virtualisation.  I don't know whether that will be enough for what you want to do or not though.  Probably the best way forward is to create a strict confinement snap, install in devmode (which turns access denials into warnings) and check the logs
<zyga> Good morning
<mborzecki> re
<mborzecki> zyga: hey, already in spain? is it colder than back here? :)
<fnordahl> jdstrand: no worries, I was aware of the summit and figured you got busy.  Thx for the response, I'll propose a PR for the fstype thing.  I would be interested in a ``fuse-control`` interface, not quite sure where to start though.
<pstolowski> mornings
<zyga> Hey PaweÅ
<mborzecki> pstolowski: heya
<zyga> mborzecki: yeah, it is colder
<zyga> Iâm just taking the dog out, sorry for the late start
<zyga> Last night I slept for 10 hours or more
<zyga> Just felt so tired
<zyga> re
<zyga> finally working
<zyga> I'm using some open wifi I found here, feels dirty
<zyga> like finding a rj45 port in the public bathroom and connecting to it
<mborzecki> zyga: remember about protection
<zyga> brb
<zyga> re
<Chipaca> did I accidentally wake up in a word that is just as strange but more dystopian?
<zyga> Chipaca: what happened?
<Chipaca> zyga: it probably involves purple giraffes
<zyga> whaat?
<mborzecki> zyga: do you know if there are any ubuntu specific apparmor patches for samba too?
<zyga> mborzecki: I don't know, let me look quickly
<zyga> mborzecki: nope
<mborzecki> Chipaca: do the giraffes move their heads to follow the mouse cursor?
<zyga> mborzecki: nothing related to apparmor in any of the patches
<mborzecki> zyga: thanks, idk if you've seen https://forum.snapcraft.io/t/manjaro-apparmor-kernel-patches-create-issues-with-smbd/12024
<zyga> mborzecki: that's what I mentioned yesterday, I was expecting this post to be published
<zyga> mborzecki: what I find possible is that on debian samba is not confined
<mborzecki> zyga: mhm
<zyga> not sure where the profile is coming from on manjaro
<mborzecki> zyga: it's from the aa package, i have it too i believe
<zyga> I don't have those
<mborzecki> zyga: yup, it's there, idk why it jsut called 'smbd' in aa-status output though
<zyga> mborzecki: smbd because that's the executable name
<mborzecki> zyga: i expected /usr/sbin/smbd or usr.sbin.smbd, unless it's magically amtches when a binary smbd is executed from whatver location
<zyga> ah, I understand what you meant now
<zyga> not sure
<mborzecki> 34C in shade :/
 * Chipaca laughs in 17C
<Chipaca> jamesh: thank you for #7036 !
<jamesh> Chipaca: no problem.  It's nice when PRs have more minuses than pluses
<Chipaca> yuss
<mborzecki> need 2nd +1 on this thing to unblock master and jdstrand's PRs: https://github.com/snapcore/snapd/pull/7034
<Chipaca> jamesh: I'm proud to be friends with this guy: https://mobile.twitter.com/perrito666/status/1143659952793370624
<Chipaca> mborzecki: looking
<Chipaca> mborzecki: io_uring sounds nephrological
<mborzecki> Chipaca: > I am going full Marie Kondo on this code.
<mborzecki> Chipaca: well, it's upstream's doing :)
<mborzecki> Chipaca: fwiw there's liburing too
<Chipaca> is it uring-complete
<Chipaca> sorry i had to
<jamesh> Chipaca: but are those 186 lines really necessary?
<Chipaca> jamesh: wc -l /usr/share/common-licenses/* says â¦ maybe
<Chipaca> jamesh: anyway the question should be 'do they bring joy', surely
<Chipaca> or is it spark joy
<pstolowski> mborzecki: 7030 +1 with a suggestion
<zyga> mborzecki: 30C here but the sea makes it nicer
 * zyga reviewed https://github.com/snapcore/snapd/pull/7032/files
 * pstolowski lunch
 * zyga coffee
<zyga> actually getting up to get the coffee now
<mborzecki> zyga: https://forum.snapcraft.io/t/manjaro-apparmor-kernel-patches-create-issues-with-smbd/12024/5 dbus & AA blocking samba?
<Chipaca> jamesh: if you're still around, can you merge master (or rebase, your call) so it doesn't fall over the missing syscalls?
<Chipaca> jamesh: if you're not around I'll merge master myself
<Chipaca> I mean into 7036 fwiw
<zyga> back
<zyga> mborzecki: looking at sfdisk pathces
<zyga> *patches
<jdstrand> fnordahl: I have it on my list to create. at what priority do you need it?
<zyga> jdstrand: hello
<zyga> mborzecki: hot, isn't it?
<fnordahl> jdstrand: that's great!  I suspect the main consumer of the snap will be a charm, so installing it in devmode will be hidden from the end user for now.  It would be great to be able to have a good end user cli experience without --devmode at some point though.
<mborzecki> zyga: it's so hot the dogs don't care when i open a fridge anymore
<zyga> hot dogs? :D
<mborzecki> heh
<jdstrand> mborzecki, zyga: I commented in the manjaro/smbd topic
<zyga> mmm
<zyga> thanks, that is very reasonable advice
<jdstrand> mborzecki: also, https://github.com/snapcore/snapd/pull/7034/files#r297615888
<jdstrand> fnordahl: ok, based on that feedback, it'll stay on the list for 2.41
<jdstrand> zyga, mborzecki: whoops, I fixed a typo just now s/before it can be used in complain mode/before it can be used in enforce mode/
<fnordahl> jdstrand: sweet, do not hesitate to reach out if you need a hand for testing or more information
<jdstrand> man that had a bunch of typos :\
 * jdstrand fixed
<mborzecki> jdstrand_: thanks for the suggestion, https://github.com/snapcore/snapd/pull/7037
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7030#pullrequestreview-254541735
<zyga> more reviews ahead
<jdstrand_> mborzecki: thanks! approved
<mborzecki> jdstrand: fwiw, now we know that the test works :P
<mborzecki> zyga: i'll double check without the `device :` bit, last time i tried it manually sfdisk failed (or segfauled for that matter), but it's quite wonky in general so the reason might have been something else
<mborzecki> zyga: a nice example, a partition like this makes sfdisk segfault: `1 : start=2048, size=2048, type=21686148-6449-6E6F-744E-656564454649, name="BIOS Boot"foobar` xD
<zyga> mborzecki: really? I used it a few times without any issues
<zyga> so... hot...
<mborzecki> zyga: notice how `name="BIOS Boot"foobar` is formatted
<zyga> ah
<zyga> I see
<zyga> well
<zyga> C
<mborzecki> or not C
<zyga> lack of good parser libs
<jdstrand> mborzecki: so, remind me, that list now has the io_uring syscalls, but no released libseccomp has them. why isn't something more needed?
<mborzecki> jdstrand: we just track which syscalls libseccomp (upstream) know of, so that we can interrogate the host lib
<mborzecki> jdstrand: it's part of the shenanigans for snap-seccomp recompiling bpf when a profile or the local libseccomp got changed
<jdstrand> mborzecki: right, versioninfo. but, libseccomp *didn't* change. just syscalls.SeccompSyscalls
<jdstrand> (libseccomp as linked into snap-seccomp that is)
<mborzecki> jdstrand: yup, that's correct
<jdstrand> mborzecki: so we are going to get a recompile, but for no reason afaict. I'm trying to understand/remember what is achieved here
<mborzecki> jdstrand: it's just for the purpose of knowing what syscalls to ask the host lib for, in case that's changed we know that the lib has changed, even though x.y.z version reported by the lib is the same
<mborzecki> jdstrand: as in case of distro patches, bc libseccomp releases are infrequent
<jdstrand> I think I forgot about the mechanism for 'ask the host lib for'
 * jdstrand reads
<mborzecki> jdstrand: oh, and snap-seccomp from core is statically linked iirc, but fedora/arch/suse are not
<jdstrand> mborzecki: ok, duh. I forgot that versionInfo() iterates over the list and tries seccomp.GetSyscallFromName. ok, it all makes perfect sense (again)
<jdstrand> mborzecki: thanks!
<mborzecki> jdstrand: yw
<zyga> jdstrand: hey, could you please look at https://github.com/snapcore/snapd/pull/7026 -- it's a priority for LXD team
<zyga> jdstrand: I'll iterate through existing comments
<mborzecki> zyga: updated the sfdisk PR
<zyga> great, let's see
<jdstrand> zyga: ack
<zyga> looks great, thanks
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/7025#pullrequestreview-254570960
<pstolowski> re
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/7019#pullrequestreview-254577278
<Chipaca> zyga: yeah it's tempting but no
<valentind> Is there a way to enable full confinement on Debian? It says I have only devmode.
<zyga> valentind: hello
<valentind> Hello
<zyga> valentind: not at present, I have this on my scope to fix for the next release
<zyga> I was just reading the freedesktop thread about this btw
<zyga> valentind: where full confinement is not really a thing we can enable,
<zyga> valentind: but we will enable more confinement than we do now
 * jdstrand notes that what zyga has is enabling everthing that is available, but the kernel may not allow full strict mode. not sure what valentind is interested in
<zyga> jdstrand: I bet file rules are what he is after now
<zyga> jdstrand: based on the thread
<jdstrand> (eg, cause the Debian kernel doesn't have af_unix or network compat)
<jdstrand> ah, ok. I didn't read the thread
<valentind> I want to make it fail. For now I can call lzip from the runtime.
<jdstrand> ah right
<zyga> valentind: perhaps in a day or two,
<jdstrand> zyga: I wonder if a temporary thing could be an env var or a snap experimental setting to force it
<zyga> valentind: I need to sort out some things that piled up recently
<zyga> jdstrand: I think we should just do it in edge
<jdstrand> zyga: oh, I thought be 'next release' you meant farther out
<zyga> jdstrand: and add the extra "what it means" command before release
 * jdstrand butts out cause he is clearly confusing things :)
<zyga> jdstrand: ideally 2.40 but perhaps the extra command is 2.41
<zyga> jdstrand: is it so hot for you as well? europe is melting
<zyga> that doesn't help my mind to recover from the 6-day-long road trip
<jdstrand> zyga: it has been very hot and humid. we've gotten some rain this week that kept the temp down a bit a couple of days
<zyga> forecast here is: sunlight and 0 rain for the foreseable future :(
<zyga> and no clouds as well
<jdstrand> yikes
<jdstrand> it is super cloudy atm. seems like it might rain again
<valentind> Found it in the journal: apparmor is enabled but some kernel features are missing: dbus, network
<mborzecki> cachio: standup?
<zyga> valentind: that's caused by the delta between upstream kernel and ubuntu apparmor kernel
<zyga> valentind: it should be all merged in 5.3
<zyga> valentind: but we can do better on older kernels
<valentind> OK. Then I will try to find the patches on the ubuntu kernel and apply them locally to my debian
<zyga> valentind: which kernel do you use now>
<valentind> 5.0
<ogra> i wonder if you could just run the binary deb right away on debian
<zyga> https://www.irccloud.com/pastebin/emj4SlFQ/
<ogra> (saves from patching and recompiling)
<zyga> we have some presets for 5.1 but not for 5.0
<valentind> OK
<valentind> Maybe I should just have a virtual machine with ubuntu.
<zyga> I believe that if you look at the 5.2 tree there is really only one patch that is relevant to snapd
<zyga> the rest are nice but not something we actively test for
<valentind> What is the plan for apparmor configuration for other bases?
<zyga> valentind: we discussed a while ago that perhaps a base should define the base apparmor template but this has not gone anywhere yet
<zyga> valentind: it would need to be handled in snapd explicitly
<valentind> Is there anything I can do to help this?
<zyga> valentind: not much I'm afraid, just upstreaming work on one end and snapd hacking on another end
<zyga> if you want to get involved in snapd hacking we'll gladly welcome you on board
<zyga> but it will be a while before your patches can land into master and make it out to users
<zyga> I will likely change the apparmor usage in snapd well before that
 * zyga switches to PR hacking
<zyga> please ping me about PRs you want to get reviewed but I didn't get to yet
<zyga> I'll continue down the list tomorrow
<zyga> Lunch
<mborzecki> zyga: friendly reminder https://github.com/snapcore/snapd/pull/6922
<zyga> mborzecki: ack
 * zyga -> dog walk
<valentind> Something I did not know about snap are the layout. Nice surprise. Unfortunately, it seems that it does not allow executing from bound paths.
<valentind> It seems that the apparmor snippet generated by bind mounts is missing allowing execution.
<zyga> re
<zyga> valentind: hey, can you provide an example?
<zyga> valentind: it should be working correctly, if not there's a bug
<valentind> Oh wait. My bad.
<valentind> I will try again.
<valentind> No no. It was working fine. I misread the error message.
<valentind> Permission denied was not for the execution.
<valentind> That is good. We can bind /app for compatibility with flatpak.
<zyga> valentind: you should check this out:  ...
<zyga> https://forum.snapcraft.io/t/snapcraft-summit-2019-montreal-a-snapd-perspective/11905
<zyga> search for nix
<valentind> Ok
<zyga> 27C and  *falling*
<zyga> my mind is recovering
<valentind> What are they using as base image for Nix? I suppose ld.so does not come from /nix.
<zyga> it does!
<zyga> it's a snap with pretty much nothing in it, snap download nix-base
<zyga> download and look around
<zyga> it only has /nix so that a layout can put everything there
<valentind> Well, that should break ABI, can Nix run binaries built from other ditributions?
<valentind> nix-base, ok
<zyga> valentind: nix base doesn't ship ld.so
<zyga> valentind: apps ship it
<zyga> valentind: each snap built out of nix contains everything it requires, literally so
<valentind> Yes, I understand.
<valentind> But the path is supposed to be absolute.
<zyga> valentind: it is, download hello-nix and look at what it does
<zyga> note that on nixos some more things happen
<zyga> but in snap world, that's enough
<valentind> I do not find hello-nix
<zyga> oh, sorry,
<zyga> it's not in the store!
<zyga> I only have it because I got it at a snapcraft summit
<zyga> valentind: my point there was:
<zyga> https://www.irccloud.com/pastebin/0hgCLMlj/
<zyga> nix links everything with absolute paths using hashes of the content as directory element
<valentind> So, I could just make applications to provide all the runtime and bind it in the right place.
<zyga> yes
<zyga> if that makes sense that is
<valentind> I still need to make a base with empty directories.
<zyga> what do you need?
<zyga> do you need /app?
<valentind> I need /bin /usr /lib /lib64
<valentind> And /app for the application
<valentind> I will try that.
<zyga> you may need some more for snapd to work
<valentind> Core could also be done like that. Just shipped in the applications.
<zyga> download the nix base snap and  just rename nix to app
<zyga> and see what you need
<valentind> Sure I already have the list of directories I need somewhere to make it work.
<valentind> But those were path were I would bind the Freedesktop SDK.
<valentind> Actually I need only /usr to be bind mounted. The rest should be symlinks.
<zyga> you need to provide some non-symlink directories
<valentind> Sure, those for snap.
<valentind> Well, now it is re-building firefox like that. I will try it when it is built.
#snappy 2019-06-27
<mborzecki> morning
<mborzecki> https://github.com/snapcore/snapd/pull/6992 needs a 2nd review and can land
<zyga> good morning
<zyga> coffee and work
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/6992 just needs a 2nd review and we can land it
<mborzecki> should be easy, just some test cleanup
<pstolowski> morning
<mborzecki> pstolowski: hey
<pstolowski> +1
<mborzecki> yay
<zyga> mborzecki: looking
<zyga> hey pawel :)
<zyga> 9:30
<zyga> better than yesterday
<zyga> 26C and looking great
<mborzecki> zyga: nice
<mborzecki> zyga: sorry to keep poking you :) https://github.com/snapcore/snapd/pull/6922
<zyga> doing now
<mborzecki> anyone managed to order pi4 4GB variant?
<zyga> mborzecki: I was considering
<zyga> but
<zyga> mborzecki: here I can get the es keyboard layout (I wanted the desktop kit)
<zyga> mborzecki: in poland I can get the .pl keyboard layout
<zyga> mborzecki: in both cases I'd have to wait up to a month
<zyga> mborzecki: apart from micro-hdmi (WHY!?!) it is ok
<zyga> mborzecki: I'd prefer to have 3 usb-c instead
<zyga> nobody loves micro hdmi cables
<zyga> mborzecki: reviewing, should be done soon
<mborzecki> zyga: i checked a couple of places but sold out
<zyga> mborzecki: yeah
<zyga> they flew from the shelves
<zyga> just wait, GBP/PLN is favourable :)
<mborzecki> zyga: maybe availability was like amd's vega cards ;)
<zyga> mborzecki: at this price point they will fly off any store
<zyga> mborzecki: I read a funny tweet yesterday, cannot remember it exactly but it roughly read "how many people will buy it just to put it on the shelf next to older pi's, also unused'
<pstolowski> heh, was considering it a few days ago (botland.com.pl). out of stock already
<zyga> pstolowski: preorder, they are the only official reseller
<zyga> pstolowski: others buy from them
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6922#pullrequestreview-255050272
<zyga> mborzecki: I'll task switch to work on the feedback from both you and jstrand
<zyga> I think this will land today
<mborzecki> zyga: ok, great
<mborzecki> zyga: i think i'll leave a todo about preserving file permissions, osutil.CopyFile can do that but in a funny way by calling cp, and while it's ok for a scenario when you build an image, it feels fragile when you update :/
<zyga> mborzecki: I think it's not needed now but it'd be worth making this explicit (as in, this is not supported and is documented as such)
<mborzecki> zyga: mhm, sounds fair
<zyga> mborzecki, pstolowski: desktop set or just bare pi4? (hard questions)
<mborzecki> zyga: i'll try getting the regular one, the keyboard/mouse look like toys tbh
<zyga> yeah but OMG shiny :)
<pstolowski> zyga: bare
<mborzecki> zyga: and the desktop set is what $100+? :P
<zyga> it's not much, case + psu
<zyga> + cables you'd otherwise how to source separately (2$ a piece)
<zyga> + keyboard / mouse (with only one usb port)
<Chipaca> xnox: 00-ê±É´á´á´á´-á´á´É´ê°ÉªÉ¢.Êá´á´Ê
<valentind> zyga, It is not straight forward to bind mount /usr from the snap application. Snapd bind mounts several things within /usr, but it does it before the layout binding. So those paths disappear. I would need to make a script to generate all the paths to mount in order not to mount over those paths.
<zyga> valentind: yeah, mounting all of usr is tricky :/
<zyga> valentind: can you help me understand why you'd need that?
<zyga> valentind: I assumed that the freedesktop runtime would be much like flatpak runtime model
<zyga> valentind: with / being a full read only image (mostly)
<zyga> valentind: and /app being the application image
<zyga> valentind: with extra places for writable data
<valentind> Yes.
<zyga> valentind: in this model, can you not keep the runtime as the base snap, with /usr and all the other suspects as-is
<valentind> Well, if we cannot run commands from /usr/bin it is annoying.
<zyga> valentind: perhaps that's what we should fix, we could change snapd to generate different apparmor template for if the base snap is the freedesktop runtime
<valentind> I could also just mount /usr/bin from the app with the files copied from the runtime.
<valentind> zyga, Yes, this is what I would like.
<valentind> But I do not know how much time it would take to get there.
<zyga> valentind: perhaps not that much, can you tell me if what you are missing is simply
<zyga> (in apparmor terms)
<valentind> I do not mind providing a apparmor template for freedesktop sdk, this is fine.
<zyga>  /usr/bin/** ixr,
<zyga> perhaps coupled with something similar for /usr/lib
<valentind> This would be enough I think.
<zyga> I think we can do that then, is there a thread I can reference in the pull request?
<valentind> I think we need run only for ld.so, and it is already there.
<zyga> valentind: can you make that modification locally?
<valentind> Libraries do not need execution otherwise. Just that the dynamic loader can be executed.
<valentind> Sure, I can do that.
<zyga> valentind: you can install a snap, edit /var/lib/snapd/apparmor/profiles/snap.$SNAP_NAME.$APP_NAME, reload that using apparmor_parser -r /path/to/profile and see if that fixes it
<zyga> valentind: once you have the set of changes I can make a quick PR
<zyga> thank you!
<valentind> Ah libexec as well
<zyga> I'm sure there's a small list you can find by iterating
<xnox> Chipaca:  ship it!
<xnox> Chipaca:  i should totally do that somewhere sometime, as the defualt filename.
<valentind> zyga, yes that works. I will check a bit more to see what makes sense to add.
<zyga> thanks!
<Chipaca> xnox: that's the output of 'unifonter -k k 00-snapd-config.yaml' fwiw
<zyga> brb, short walk to the library
<zyga> (free wifi, ac and super quiet)
<zyga> re
<zyga> I forgot how nice this place was
<valentind> zyga, I have found few other places than /usr/bin/ and /usr/libexec/ where there are binaries. But I think I will change freedesktop sdk to move them to libexec. Not sure why they are there.
<zyga> valentind: what kind of executables were those?
<valentind> It is in the library directory.
<valentind> They look like libexec things.
<zyga> valentind: in /usr/lib?
<zyga> valentind: I think it's okay to add to the template instead of changing the base snap too much
<valentind> OK, then.
<valentind> So yes, {,/usr}/bin/* {,/usr}/libexec/** and {,/usr}/lib/**. Should I make a mr? Or will you take care of that?
<zyga> valentind: I can do that
<zyga> valentind: I have some ideas where that should be
<valentind> OK Great.
<Chipaca> could I have a second review of a very very simple but important pr, #7040 ?
<Chipaca> https://github.com/snapcore/snapd/pull/7040/files
<mborzecki> Chipaca: do you know if we're doing another . release?
<zyga> mborzecki: can you do another pass over infofile subset of https://github.com/snapcore/snapd/pull/7026/files
<zyga> mborzecki: I will address the remaining comments now
<mborzecki> zyga: sure
<zyga> I need to take a break, the library is closing soon
<zyga> see you soon
<wieczorek1990> Can I get any love in the reviews? https://snapcraft.io/gitl
<mborzecki> zyga: added some comments about new info scanner
<zyga> Thanks
<zyga> Resuming work now
<wieczorek1990> How often are review-tools updated?
<zyga> wieczorek1990: on demand, I think
<mborzecki> wieczorek1990: jdstrand likely knows best
<zyga> brb for lunch
<zyga> wieczorek1990: or roadmr also knows AFAIK
<wieczorek1990> mborzecki: jdstrand told me to wait :)
<jdstrand> wieczorek1990: the review-tools are updated. roadmr is getting them to production as we speak. it should be soon
<wieczorek1990> cool
<zyga> mborzecki: trying to join standup
<jdstrand> wieczorek1990: it seems likes you may have auto-uploads setup for gitl? if so, you may want to pause them for the next day or so until they start passing automated review
<wieczorek1990> just let me find that option :)
<wieczorek1990> jdstrand: removed from the build list
<jdstrand> wieczorek1990: I'll ping you when the tools are in proc then
<wieczorek1990> jdstrand: thanks
<dot-tobias> Ping kyrofa / sergiusens: https://forum.snapcraft.io/t/cmake-part-with-build-snaps-gets-mangled-include-parameters/ â any quick hint what's going wrong here?
<ogra> dot-tobias, what did you break again ?
<ogra> :)
<dot-tobias> ogra: Just one of my user-errors again, I hope ð
<dot-tobias> Holding It Wrongâ¢
<ogra> must be the heat
<dot-tobias> most definitely
<jdstrand> wieczorek1990: ah, the update is in prod now and gitl passes automated reviews :) (see r141). all the other revisions are now being scanned and passing (up to r147 now)
<zyga> jdstrand: hello, I sent several updates to https://github.com/snapcore/snapd/pull/7026 -- could you do another pass please
<zyga> jdstrand: I'm still doing a few changes to the comments as you suggested but the "essence" of the changes are good now IMO
<jdstrand> zyga: ok
 * zyga moved closer to home 
<jdstrand> Saviq: is is possible to adjust the mirror when using snapcraft with multipass? (maybe that is a question for sergiusens... hi to both of you!)
<jdstrand> I'd like to use something other than archive.ubuntu.com
<Saviq> jdstrand: not easily with snapcraft, no - it doesn't give you a way to modify the cloud-init
<Saviq> today, only option would be to `snapcraft pull` a part, then get into the instance and switch the mirror
<Saviq> long-term, we're working on configurable cloud-init defaults in Multipass, which could help with this (although snapcraft provides a cloud-init, I wonder if we should mess with itâ¦)
<Saviq> jdstrand: one way or another, yes I'd say it's a sergiusens question :)
<Saviq> b/c I'd rather see snapcraft allowing you to specify a mirror rather than you hacking the instances under its feet :)
<Saviq> there's also an option of a snapcraft pluginâ¦
<Saviq> but you'd need to modify each snapcraft.yaml to make it use the plugni
<Saviq> so yeah, I really think this kind of thing would be a snapcraft one :)
<ogra> jdstrand, you can easily do that by adding an extra part to your snapcraft.yaml that calls add-apt-repository ... i.e. pilibs here adds a PPA (but any proper deb archive should actually work here), pistream (the part afterwards) then uses a package from there (libraspberrypi-bin) https://github.com/ogra1/picamera-streaming-demo/blob/master/snap/snapcraft.yaml#L37
<ogra> that way should work in any build env (multipass, launchpad buildd etc)
<ackk> hi, is it possible for a snap to know if it's installed with --devmode?
<Chipaca> ackk: what for?
<ackk> Chipaca, basically conditional logic in hooks as you can do stuff like chown if in devmode
<ogra> given that devmode isnt something you should/would use permanently you should really not do any permanent hacks in your hooks for it
<Chipaca> ackk: if you really really need to do this, try snap list $SNAP_INSTANCE_NAME
<Chipaca> ackk: if you can do that, you're in devmode*
<Chipaca> * or you have snapd-control
<ackk> Chipaca, ah, interesting trick :)
<ackk> Chipaca, thanks
<Chipaca> actually it works also if you have snapd-control :)
<Chipaca> because you can't run snap :)
<ackk> heh, cool
 * zyga -> nap
<zyga> zzzz
<wieczorek1990> https://www.irccloud.com/pastebin/3kyusPpM/
<wieczorek1990> So, I've been trying to enable aliases in gitl run using snap, and I'm kind of blocked. Getting this error:
<wieczorek1990> error: could not lock file /home/luke/.gitconfig: Permission denied
<wieczorek1990> Thought there won't be errors after adding the personal-files interface
<wieczorek1990> Here's my snapcraft.yaml: https://github.com/wieczorek1990/gitl/blob/master/snap/snapcraft.yaml
<wieczorek1990> Here's the function in git causing problems: https://github.com/git/git/blob/ab15ad1a3b4b04a29415aef8c9afa2f64fc194a2/lockfile.c#L73
<wieczorek1990> Any hints?
<wieczorek1990> Other thing is that normal aliases don't work, they exit with a message like this:
<wieczorek1990> expansion of alias 's' failed: 'status' is not a git command
<wieczorek1990> but they work if written as "s = !git status", strange
<ogra> did you actually connect the interface ? it surely doesnt automatically connect
<wieczorek1990> it's there when I run `snap connections gitl`
<ogra> and connected ?
<ogra> (did you explicitly run snap connect for it after install)
<wieczorek1990> No, I ran install from the store
<ogra> yeah, that wont connec it
<ogra> you need to explicitly run snap connect <snapname>:<plug>
<ogra> (i never used personal-files so i dont know where to you need to connect)
<wieczorek1990> connecting did not change a thing
<wieczorek1990> Did not expect so much work for deploying app with snap :)
<ogra> well, the good thing about snap packaging is that once you figured it out you usually do not need to touch it again
<zyga> store is somewhat red
<zyga> https://www.irccloud.com/pastebin/YI8ilsRW/
<zyga> noise][: ^ https://status.snapcraft.io/ is green, should I see anything ?
<noise][> nothing alerting but let me take a look
<zyga> it's not all the stuff I do but I've restarted tests over small one-off failures a few times
<Paddy_NI> Will the "Gnome Software" ever be gaining support for displaying markdown read from a snap apps description properly?
<noise][> zyga: we are seeing some elevated err rates, coinciding with a deploy, investigating and will update status page in a minute
<Paddy_NI> Ascii cast and video support would also be awesome
<zyga> as always, thank you for keeping the store running :)
<noise][> zyga: all fixed now, was 1 bad unit in a pool, monitoring caught it but as a low-prio so nobody had looked at it right away
<noise][> we will fix that as well :)
<zyga> noise][: super, thank you
<jdstrand> Saviq: ack, thanks
<jdstrand> ogra: thanks. the thing is I want to change the mirror (not a ppa) only for local builds, not LP builds
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/7026 is green
<zyga> I have some more tests piled up but I'll wait for your review first
<zyga> jdstrand: the only significant change I'd like to introduce is to allow to define a memory cap so that unbound input cannot happen
<jdstrand> zyga: is that in a subsequent PR or this one?
<zyga> jdstrand: perhaps subsequent since this is green now
<zyga> jdstrand: or either if you'd like to see that earlier
<zyga> jdstrand: I'm mainly trying to be practical and land it soon
<jdstrand> zyga: I'd prefer to review 7026 if you're done with it. I think that improvement could come in a subsequent PR (we do control the file after all, so I consider this landable without it (sans my 2nd review))
<zyga> jdstrand: +1
<zyga> jdstrand: I'm happy with that
<jdstrand> zyga: put another way, I didn't want to review it and then have you add more :)
<zyga> sure
<jdstrand> if we could avoid it (can't always)
<jdstrand> ok, so I'll take a look at it after a couple things. might be tomorrow morning
<zyga> thank you, I'm heading to bed anywa
<zyga> I'll work with maciej to get it re-reviewed
<zyga> hopefully it could land tomorrow
<jdstrand> zyga: good night! :)
<zyga> good night :)
#snappy 2019-06-28
<wieczorek1990> Updated my plugs
<wieczorek1990> https://forum.snapcraft.io/t/please-allow-use-of-personal-files-for-gitl-was-classic-confinement-for-gitl/9420/30
<df00z> Is there a reason snapcraft seems to pass "-prefix=" with the autotools plugin?
<df00z> it seems to hork up a lot of builds
<df00z> unless /usr is specified
<hunterk> I'm trying to add a scriptlet to symlink a library in my snap, but it doesn't seem to be doing anything. That is, I don't see any trace of it in the build log on snapcraft: https://github.com/libretro/retroarch-snap/blob/master/snapcraft.yaml#L20
<hunterk> can anyone tell me if I formatted that properly in the yaml?
<df00z> sorry, i am not quite there yet, havent done scripts
<mborzecki> morning
<mborzecki> duh, clearlinux is weird, it says it supports cloud-init, but makes no use of it when i attach a disk with vfat labeled ucidata
<mborzecki> turns out they have their own implementation https://github.com/clearlinux/micro-config-drive/ that takes config-2 openstack style disks only :/
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> Good morning
<mborzecki> zyga: hey hey
<zyga> mborzecki: can you re-review https://github.com/snapcore/snapd/pull/7026
<zyga> mborzecki: I have some more patches but per agreement with jdstrand those will go to another PR
<zyga> mborzecki: those add a few more unit tests and allow the memory buffer to be capped
<zyga> mborzecki: with those test coverage for the new code is 100%
<mborzecki> zyga: ok, looking
<zyga> thanks!
<zyga> pstolowski: how are you? :)
<zyga> weekend coming up, weather is slightly saner (at least in poland, here's it is going to be much hotter)
<pstolowski> zyga: hey! i'm good, and weather is sane, yes
<zyga> today is going to be blazing hot, cannot wait till 10:00 when the library opens
<ackk> hi, to confirm, the "refresh" hook is called both on first install and every time a snap is updated right?
 * zyga breakfast
<zyga> pstolowski: ^
<pstolowski> ackk: no. there is no "refresh" hook, there are "pre-refresh" and "post-refresh" hooks, they are only run if snap is already installed and is refreshed, not on initial install. see https://docs.snapcraft.io/supported-snap-hooks
<ackk> pstolowski, ah, thanks
<ackk> pstolowski, shouldn't post-refresh run when you first install the snap?
<ackk> ah, it doesn't seem so :/
<zyga> ackk: no, it runs after refresh, which is not the initial install
<pstolowski> ackk: the idea with pre- and post- is to allow snap to do something with "old" snap resources before switching to new snap, and then afterwards in the new snap
<ackk> This hook is executed for the newly installed snap,
<ackk> pstolowski, so doc is wrong I think ^
<pstolowski> ackk: are you sure you didn't have old revision around? i checked the code before actually looking up the doc
<ackk> pstolowski, if I do have an old revision, it is run
<zyga> ackk: are you trying or installing?
<zyga> there's a bug with snap try in this case
<ackk> pstolowski, I'm saying what I see matches what you said (only run on refresh, not on new install), but the doc says otherwise
<ackk> zyga, try
<zyga> in try case it's broken because it's all one virtual revision
<pstolowski> ah, snap try
<ackk> zyga, so, if I want a script to be run on new install and on subsequent refresh, I can use install + post-refresh right? and symlink one to the other
<zyga> ackk: or configure
<ackk> zyga, yeah that's what i have at the moment but I wanted to move away from that as it might break things if you run snap set
<zyga> ok
<ackk> also, it would run more times that it needs
<ackk> zyga,  is symlinking allowed?
<zyga> I suspect so but I don't believe we test for it
<ackk> I'll try
<pstolowski> zyga: thanks for pointing out 'snap try', i wouldn't realize this could be a factor
<zyga> pstolowski: we should warn if refresh hooks are present in snap try
<zyga> it probably would be easy now
<pstolowski> indeed
<ackk> zyga, you mean post-refresh is broken if you use snap try?
<ackk> why is it one virtual revision? if you upgrade via snap try you get x2,x3...
<zyga> ackk: if you snap try snapd will think that you already have the hook
<zyga> ackk: because it's one actual directory it is always looking at
<zyga> ackk: I suggest that you snap pack and actually install to test this code
<zyga> snap try cannot be used for that reliably
<ackk> zyga, ok, thanks
<ackk> zyga, I'm mostly using snap try because the squashfuse bug makes it really slow to use maas in a snap
<zyga> bug?
<zyga> you can compress with gz
<ackk> it uses 100% cpu
<zyga> it will be fast
<zyga> it's not a bug, it's just expensive compression :)
<ackk> zyga, uhm, squashfuse constantly using 100%cpu sounds like a bug
<zyga> ah
<zyga> sorry, I misread
<zyga> squashfuse
<zyga> it's not a bug, squashfuse is just really this slow
<ackk> zyga, https://bugs.launchpad.net/snapd/+bug/1817276
<zyga> lots of overhead for access
<ackk> zyga, it only happens inside containers
<ackk> zyga, it makes it moslty unusable
<zyga> because we only use squashfuse inside containers
<zyga> fuse is just slwo
<zyga> *slow
<zyga> we'd need a new kernel implementation that is not fuse to be any faster
<zyga> perhaps something could be improved in the current one but in general fuse is just really slow
<Chipaca> good morning and greetings from The Sprint
<pstolowski> hey Chipaca
<Chipaca> zyga: what's the status of #6891?
<Chipaca> pstolowski: 'sup :-)
<pstolowski> Chipaca: how is the sprint?
<zyga> Chipaca: hey, looking
<Chipaca> pstolowski: I'm exhausted and I've only been here 24 hours
<Chipaca> pstolowski: how mvo, pedronis and niemeyer cope with it I don't know
<zyga> Chipaca: the status is that there's one undesired consequence of the fix that is present on core16 only, it needs to be debugged but debugging is painful (slow) because of core nature
<zyga> Chipaca: I will task switch to it as soon as https://github.com/snapcore/snapd/pull/7026 is merged
<zyga> Chipaca: the error is that on core16, the new test measures duplicated /snap/name/revision entries
<zyga> probably a consequence of something else propagating
<zyga> but I don't understand it yet
<zyga> Chipaca: how is the sprint so far?
<ackk> zyga, fwiw it seems a bit weird that snapd only prints "Running <hooname> hook if present" only when the hook actually exists. I mean why the "if present"?
<ackk> zyga, FTR symlinking doesn't work :(
<zyga> ackk: bug, it used to always do that
<zyga> pstolowski: ^
<zyga> the message is out of date
<pstolowski> right, we now optimize hooks out, message needs updating
<ackk> ah actually my symlink test wasn't accurate, need to test again
<ackk> oh actually it seems symlinks get converted, nice
 * ackk stares at squashfuse running at 100% since 5m
<Chipaca> zyga, mborzecki, either of you feel like taking a look at os-release for clearlinux? wrt https://forum.snapcraft.io/t/snapd-on-clearlinux/12048?u=chipaca
<mborzecki> Chipaca: tried booting clear linux image in the morning, was a funny experience
<Chipaca> mborzecki: glad you're having fun
<Chipaca> :-Ã¾
<Chipaca> mborzecki: anything and everything clearlinux, I blame xnox for it
<mborzecki> hm maybe i should at least paste os-release in that topic
<Chipaca> mborzecki: zyga has a zoo
<Chipaca> mborzecki: https://github.com/zyga/os-release-zoo
<Chipaca> zyga: archived? :-(
<zyga> Chipaca: I have a clearlinux VM
<zyga> Chipaca: tried building snapd there
<zyga> Chipaca: moved to gitlab.com/zygoon/os-release-zoo
<zyga> since I was curious of how the grass looks like there
<Chipaca> it looks clear, duh
<ogra> and ?
<ogra> was it greener ?
<zyga> ogra: it was very fast indeed
<zyga> I was surprised to see a brand new package manager
<zyga> not related to anything else
<zyga> and a matching package format aswell
<wieczorek1990> Can I get some love here: https://forum.snapcraft.io/t/please-allow-use-of-personal-files-for-gitl-was-classic-confinement-for-gitl/9420/32?u=wieczorek1990
<xnox> zyga:  i love your zoo
<zyga> xnox: pleasure, contributions welcome
<zyga> I should be more active about adding stuff I have access to there
<ogra> ppisati, where did System.map-*, abi-* and config-* go ?
<ogra> wget -O- -q http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-4.4.0-154-generic_4.4.0-154.181_armhf.deb | dpkg -c - | grep boot
<ogra> drwxr-xr-x root/root         0 2019-06-25 11:19 ./boot/
<ogra> -rw------- root/root   7310208 2019-06-25 11:19 ./boot/vmlinuz-4.4.0-154-generic
<ogra> seems they are not in the deb anymore
<ppisati> ogra: :O
<ppisati> ogra: check the linux-modules-* package
<ogra> ah, there are config-* and System.map-* .... but abi-* is still missing ... did we drop that ?
<zyga> mborzecki: could you have another look at https://github.com/snapcore/snapd/pull/7026 please
<zyga> mborzecki: if you are interested, on top I have one patch https://github.com/zyga/snapd/commit/eacf3860affb61f2ad6f8cd40bf5e6e56bb7bf91 that I decided to postpone until after this lands
 * cachio afk
<mborzecki> zyga: nice, though jdstrand was ok with getline() :)
<zyga> yeah but then I played and fed /dev/empty into it
<zyga> this used all ram
<zyga> so ...
<zyga> here it is :)
<zyga> I'll propose it as soon as this lands
<mborzecki> haha
<zyga> also need to propose a patch to get easy way to run lcov
<zyga> but first, small break
<zyga> then back to https://github.com/snapcore/snapd/pull/6891
<mborzecki> zyga: oh, looks like glib is using lcov too
<mborzecki> zyga: i'd check of clang/llvm has something
<zyga> honestly anything that works is ok
<mborzecki> zyga: hahha, given that it's C land, you can put the bar too high :)
<mborzecki> so dropping snap.ReadGadgetInfo() saves ~20k on snap binary, worth it?
<zyga> mborzecki: yeah
<zyga> trying to join...
<jdstrand> zyga (cc mborzecki): wow, you added a lot of code to get rid of the variable list. I feel bad cause of all the code you wrote, but jeez, why can't we just do a simple loop and search like I originally suggested?
<jdstrand> I mean, this is setuid code, parsing teensy files that we control
 * setuid looks around
<jdstrand> lets regulate the input and be very strict (skipping if malformed/whatever) and keep the code simple without state
<jdstrand> mborzecki: am I wrong in my assessment?
<zyga> jdstrand: yeah but also made it much simpler (O(N) instead of O(N*N)) and much more testable
<zyga> jdstrand: this will also allow me to replace the os-release parser with the same tested code
<zyga> jdstrand: more is not necessarily worse (especially that the public code surface is smaller and even easier to use)
<jdstrand> zyga: I think you mean s/simpler/faster/
<zyga> no, it is simpler to reason IMO
<zyga> the logic in each function is more straightforward than before
<jdstrand> I'm trying to reason about it while reviewing it and found that not to be the case
<zyga> where it was all in one more complex function
<zyga> the private function does a pass over the file
<zyga> the public function calls the private function with a helper callback that extracts the single key we are looking for
<zyga> everything else is tests
<zyga> jdstrand: the structs avoid very long argument lists
<jdstrand> I understand the one loop pass. I know why you are doing it. I'm saying it feels like a lot more than is required to extract a key/value pair from a file
<jdstrand> zyga: I am not saying I don't understand the code. I am saying it seems like more than is needed. I'd like mborzecki's input as well
<Chipaca> what key/value pair from what file?
<zyga> ack, though I'd rather not rewrite it again :)
<Chipaca> :)
<zyga> Chipaca: key=value from a file we write
<zyga> Chipaca: but also keeping it open to drop the custom code for /etc/os-release parser and use this one instead
<jdstrand> zyga: I know, which is why I said I feel bad...
<jdstrand> Chipaca: https://github.com/snapcore/snapd/pull/7026
<zyga> jdstrand: can you clarify if you feel bad because of how the code looks like or because of the initial suggestion, sorry I didn't get that
<mborzecki> jdstrand: agree that it's bit more more than needed, but afaiu the idea is to reuse this elsewhere
<Chipaca> oh in C
<mborzecki> Chipaca: bleh C :/
<jdstrand> zyga: I feel bad for you writing a lot of code that I really want to NAK. I'm trying to figure out if I am beign reasonable
<Chipaca> and in part of a 800-line PR
<zyga> ack, I see
<Chipaca> that touches 23 files in 34 commits
<zyga> Chipaca: most of that is noise, the main part is just tests and a single .c file
 * Chipaca steps slowly away from that
<zyga> Chipaca: I can move 90% of the files changed to another PR that can land without any impact
<zyga> jdstrand: on top of that I also wrote a patch to use fixed size buffer
<zyga> jdstrand: but I didn't include it in this PR as we discussed
<jdstrand> zyga: again, I didn't care about fgets vs getline. I was just adding to the sidebar commentary
<zyga> ack
 * jdstrand takes a deep breath and tries to reread this in different orders to somehow rationalize is is worth it
<zyga> jdstrand: please make a decision, I will close and re-do this if necessary
<jdstrand> uhh... of course?
<jdstrand> though, if I'm being honest, if I do decide to let it through, I'm going to ask for Michael or Samuele to ack the added complexity
<Chipaca> zyga: I'd say that anything that touched C should be very far away from anything that is noise
<zyga> Chipaca: read the PR
<Chipaca> zyga: I'm feeling particularly ornery today though
<zyga> Chipaca: it's not noise per se, just trivial required changes to complete the feature
<zyga> Chipaca: it's noise for the point of view of the discussion
<zyga> *from
<zyga> removal of .info files
<zyga> spread test + data files
<niemeyer> zyga: I've got a bug on a connected content interface
 * jdstrand notes he is only talking about sc_infofile_get_key()
<jdstrand> and down
<niemeyer> zyga: Hello btw :)
<zyga> niemeyer: hey!
<zyga> niemeyer: can you tell me more please
<niemeyer> zyga: I've been speaking to people all week live here and suddenly I forgot you were not one of those :p
<mborzecki> jdstrand: wondering, as a middle ground, we could live without scanner state & callback thing, plus enforce <key>=<value>\n format, but keep the error codes, then https://github.com/snapcore/snapd/pull/7026/files#diff-5dd49f9aa50cb48081dd1039d91e4e9aR243 becomes where value is extracted, wdyt?
<zyga> I hope it's one of the known ones, but we'll see
<niemeyer> zyga: The scenario is quite specific, so might be related
<niemeyer> zyga: I had a local snap unsigned that I developed myself
<zyga> niemeyer: there's a fix that is close to landing that happened to resolve a number of bugs at once
<niemeyer> zyga: And then I refreshed into a proper snap from the store
 * zyga listens
<niemeyer> zyga: Which had a new connection that did not exist in my local snap
<niemeyer> zyga: The connection was established (and is), but the actual content doesn't show up in the content directory
<zyga> niemeyer: ok, some questions: is this snap using the desktop interfaces by any chance?
<niemeyer> zyga: This is the gnome platform interface
<niemeyer> zyga: http://paste.ubuntu.com/p/qDX9jnn9qr/
<zyga> niemeyer: if you nsenter -m/run/snapd/ns/$SNAP_NAME.mnt - do you see the directory you were expecting?
<jdstrand> mborzecki: I liked how the tests read (ie, the error codes) and found that a nice improvement. it is when I started looking at all the structs, caller_state, function pointers, etc that I was like "this is going to take me all day to prove to myself that it is bulletproof)
<jdstrand> s/)/"
<zyga> jdstrand: I'm happy you like the error handling, I think it is a good pattern to follow, even if the outcome is die() simply because of how testable that mode is, and that error forwarding also calls die if nobody is to pick up the error on the caller side.
<niemeyer> zyga: Where do I run thta?
<jdstrand> mborzecki: not that it would take all day, but having that feeling isn't great when you are looking at setuid file parsing
<zyga> niemeyer: open a terminal, sudo nsenter -m/run/snapd/ns/foo.mnt # replace foo with the name of the snap
<zyga> niemeyer: normally on  your host
<niemeyer> zyga: No
<niemeyer> zyga: It's empty
<zyga> niemeyer: ok, can you look at /run/snapd/ns/snap.$SNAP_NAME.fstab and see if we claim we made the connection there?
<zyga> niemeyer: (do you see the mount point represented in that file)
<niemeyer> zyga: Wait, but something doesn't add up
<zyga> oh?
<niemeyer> zyga: I may be running the command incorrectly
<zyga> niemeyer: nsenter drops you into a shell inside the namespace
<niemeyer> zyga: I don't have permission to run nsenter as a user on that ns
<zyga> niemeyer: you have to sudo nsenter from the host
<niemeyer> zyga: and runnign as root doesn't make sense
<niemeyer> zyga: Doesn't that mean I'd get into a different namespace than my user would see normally?
<zyga> niemeyer: it's just a debug tool, it is okay to run it as root
<zyga> niemeyer: yes, but that's what I'm trying to debug at this moment
<zyga> niemeyer: I strongly believe you are seeing a bug that is fixed by https://github.com/snapcore/snapd/pull/6891
<niemeyer> zyga: Sure, but root never run the snap command
<zyga> niemeyer: sure but this is not the snap command, we are inspecting intermediate state
<jdstrand> mborzecki: I'm also worried about future maintenance
<zyga> niemeyer: if you see the mount point and stuff connected properly in this mount namespace this is the same bug
<zyga> niemeyer: that is all I'm trying to establish now
<jdstrand> mborzecki: I would be ok with a middle ground. do you think I am being unreasonable?
<jdstrand> mborzecki: (in my gut reaction)
<niemeyer> zyga: Okay, I must be forgetting about some detail related to namespaces.. the namespace needs to be user-specific, and this file path doesn't look user specific
<niemeyer> Ah, no, it's not user specific
<zyga> niemeyer: that's correct, this is the non-user-specific namespace; the bug is that because of sharing settings some changes don't propagate to the per-user namespaces
<niemeyer> That's what I'm forgetting
<niemeyer> Ack
<zyga> niemeyer: the PR changes the settings to properly propagate into per-user mount namespaces
<niemeyer> zyga: So yeah, the content is really missing
<zyga> niemeyer: we're hoping it will be in 2.40
<niemeyer> zyga: Okay, cool
<niemeyer> zyga: Thanks!
<niemeyer> zyga: How's spain?
<zyga> niemeyer: honestly, I'm just a piece of luggage here; I'm working all the time anyway. The kids seem to like it though, recalling memories and seeing friends
<mborzecki> jdstrand: zyga: probably buggy middle ground? https://paste.ubuntu.com/p/nMVvYKpyQ2/
<niemeyer> zyga: Hope you can enjoy the evenings with them a bit at least
<zyga> mborzecki: that would work but remember that the reason the callback exist is so that the os-release parser can extract ID and other fields that we need to look at without changing this function again
<zyga> niemeyer: yeah, though evenings are the best moments to work for now, I take mid-day slow (I recall why siesta existed) and try to compensate in the evening
<zyga> niemeyer: looking forward to a slower weekend though :)
<jdstrand> mborzecki: that is like all that I was expecting from this PR
<zyga> niemeyer: https://twitter.com/zygoon/status/1144347521613017106
<jdstrand> mborzecki: that verified with tests/etc is inline with what I would prefer. the fact that you loop through the whole file on each run is no big deal now (there is only one thing in the .info file) and isn't a big deal for os-release since it is small as well and one would want to extract like only a key or two anyway
<mborzecki> zyga: jdstrand: ok, so perhaps we could work with that for now and then look at os-release once the fix lands?
<zyga> jdstrand: does that mean that the door for the future where this code can be brought back is open or that you'd rather use the simpler implementation and just loop over input several times?
<kenvandine> jdstrand: is this still blocked?  https://github.com/snapcore/snapd/pull/5644
<jdstrand> mborzecki: a future optimization for that could be read it into memory and pass that stream into sc_infofile_get_key(). then everything stays clean. if we were talking about large files, that would be different and we'd need to consider something smarter
<zyga> jdstrand: note, I wrote that version once, it was also nacked
<zyga> jdstrand: one that read everything into memory and scanned that
<jdstrand> mborzecki: but that isn't the case (we can even comment "To keep this simple, ..."
<zyga> jdstrand: I have a feeling this is the 4th attempt at this key=value thing for snap-confine
<jdstrand> zyga: I did say 'future' there
<jdstrand> mborzecki, zyga: this PR seems like is is not focused, so yes, I like mborzecki's approach. do something simple and verifiable to fix the 'base changes' bug. then iterate to read os-release. we can land that sooner than later. for os-release, we can argue about the merits of efficiency vs simplicity/etc with all the right people looking at it
<jdstrand> kenvandine: yes
<jdstrand> kenvandine: it needs me to grandfather hundreds of snaps. it is still on for this cycle
<kenvandine> jdstrand: ok, thanks
<niemeyer> zyga: Nice!
<niemeyer> zyga: How do I get the namespace to work again?
<jdstrand> zyga: re open door> part of why we have peer reviews for this code is multiple viewpoints. I am always going to want simplicity in code for auditability, reliability and provability. if this was not setuid, it would be different. there is no obvious need (to me) for the optimizing, even when considering os-release. Michael and Samuele can overule that after hearing all sides
<zyga> niemeyer: you'd have to discard it, I'm afraid
<niemeyer> zyga: Already did
<niemeyer> zyga: New namespace has the same issue
<zyga> niemeyer: if it doesn't work now it may be some other issue
<zyga> niemeyer: can you run this from the terminal with SNAP_CONFINE_DEBUG=yes
<zyga> after discarding it
<jdstrand> zyga: I'm concerned about-- what happens if the user is able to trick snap-confine into reading a file the user controls, and there is a bug
<zyga> jdstrand: I share those concerns, I think we are on the same page here. I specifically made sure this robust (even to the point of fixed memory sizes in the follow-up)
<jdstrand> zyga: I'm not saying the code has a bug. I'm just saying it takes a lot of mental thought to verify it is all ok and that thought will need to be expended every time this part of the code is touched when it lanes
<jdstrand> lands*
<niemeyer> zyga: https://pastebin.canonical.com/p/dC2YbSXMsr/
 * zyga fetches token
<jdstrand> zyga: I know you're being careful! :) you have great checks; it is just so much more than seems required I balked at it
<zyga> jdstrand: ack
<jdstrand> zyga: perhaps save it off for now, take the middle ground approach for now and revisit when everyone is back in town?
<zyga> jdstrand: yeah, I think that's the only way forward
 * jdstrand notes he is off Tue-Fri next week
<zyga> niemeyer: is this after you have discarded? I'm surprised to see "keep" changes there
<zyga> (keep indicates that an existing entry is reused)
<niemeyer> zyga: Yep
<niemeyer> zyga: I assume that to discard I need to umount and rm
<zyga> niemeyer: how did you discard if I may ask?
<niemeyer> zyga: Am I missing something?
<zyga> not quite, you must run the discard tool, it also removes the .fstab files
<zyga> (those in /run/snapd/ns)
<niemeyer> Aha
<zyga> I mean, you must umount and rm stuff in /run/snapd/ns that matches the snap name)
<niemeyer> There's nothing there
<niemeyer> Uh, no, I'm lying
<zyga> nothing in /run/snapd/ns/snap.*.fstab
<niemeyer> zyga: Yeah, that fixed it
<niemeyer> zyga: The rm of the fstab, that is
<zyga> good, I'll look at fixing the propagation ASAP
<niemeyer> kenvandine: Works, will be playing with it on the flight back home
<niemeyer> zyga: Thank you!
<kenvandine> niemeyer: awesome
<jdstrand> zyga, mborzecki: ok, summarized my thoughts and irc outcome here: https://github.com/snapcore/snapd/pull/7026#pullrequestreview-255757563
<zyga> jdstrand: I'm almost done, one sec
<zyga> I'll push the simplified version
<zyga> jdstrand: pushed
<jdstrand> zyga: I'm sorry for the extra work. we all want the same thing ultimately even if we have different opinions on how to get there. thanks for being patient (with all of the reviewers)
<zyga>  jdstrand in the extra test, you mean one that has a trailing newline?
<zyga> jdstrand: because malformed input test 3 already does that without the newline
 * zyga adds the extra test just in case 
<jdstrand> zyga: yes
<zyga> added now
<jdstrand> zyga: ie, the file we read in has
<jdstrand> foo=
<jdstrand> bar=baz
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/7026/commits/701b333abbdec24af7eea53f8a1479bb43ff3dc1 is this what you expected?
<jdstrand> and foo is assigned the empty string
<jdstrand> (or if you don't want to support empty strings, a test that it isn't allowed)
<zyga> I want to support empty values
<zyga> I think it is useful
<jdstrand> zyga: I do too. then, 'yes' that is what I had in mind, but it isn't malformed
<zyga> yeah, I think those are "tricky" but not clearly malformed :)
<zyga> I'll rename those
<jdstrand> char empty_value_ok = "key=\n";
<jdstrand> ?
<jdstrand> but choose whatever you want
<zyga> pushed
<zyga> I think this matches the discussion and can be approved now
 * zyga needs to take the dog out
<ogra> ogra@pi3:~$ grep PRETTY /etc/os-release
<ogra> PRETTY_NAME="Ubuntu Core 16"
<ogra> ogra@pi3:~$ snap debug sandbox-features|grep confinement
<ogra> confinement-options:  classic devmode strict
<ogra> why does that list classic on an UbuntuCore system ?
<zyga> ogra: bug, should be fixed
<ogra> k
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7045
<zyga> just want to formally ack it, it's just a simple make fmt
<zyga> ogra: https://github.com/snapcore/snapd/pull/7048
<ogra> zyga, ah, nice !
<zyga> jdstrand: not binding in any way: https://github.com/snapcore/snapd/pull/7049
<zyga> I don't know if it passes tests yet
<zyga> just wanted to open it to see what happens and see what you think
<jdstrand> zyga: approved both
<zyga> Oh, great, thank you :-)
<hunterk> I'm trying to run a script as part of the snapification to symlink some libs that aren't being found. I'm doing it with override-prime, but that doesn't seem to be doing anything
<hunterk> that is, i see no override message in the snapcraft build log and no symlinks
<hunterk> is there some other, better way of doing this?
#snappy 2019-06-29
<df00z>  keep running into walls.   In the YAML file can you somehow use snap's environment variables?   Like configflags:                         - --sysconfdir=SNAP_DATA
<df00z> trying to avoid something hacky like override-prime scripts to copy files around
<hunterk> df00z: yeah, that's what I'm trying to do. hacky script to symlink some libs
<df00z> Can you skip a step?  like i want to re-prime
<df00z> snapcraft clean --skip prime or something
<df00z> er --step
<df00z> hunterk: override-stage works
<df00z> override-prime is ignored
<df00z> it looks
<hunterk> df00z: oh nice. I'll switch to that. thanks!
<ardaguclu> Client: HexChat 2.14.1 â¢ OS: Ubuntu "bionic" 18.04 â¢ CPU: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz (1,36GHz) â¢ Memory: Physical: 15,2 GiB Total (13,5 GiB Free) Swap: 2,0 GiB Total (2,0 GiB Free) â¢ Storage: 92,6 GB / 1,5 TB (1,4 TB Free) â¢ VGA: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller @ Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller â¢ Uptime: 1h 55m 3s
<df00z> Do snapcraft install hooks run "in the bubble" ?  It's not finding some files in /etc that are clearly in the prime directory if I shell into the multipass environment.
#snappy 2019-06-30
<ardaguclu> Hello, I have some questions about snapd project structure. Where is the most appropriate place for this?, should I ask via forum or here?. Thanks
#snappy 2020-06-22
<mborzecki> morning
<mborzecki> quick errand, brb
<zyga> Good morning
<zyga> Letâs catch up on email
<zyga> And administrative tasks
<zyga> https://github.com/snapcore/snapd/pull/8881 needs a 2nd review
<mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<mborzecki> re
<zyga> hey :)
<pstolowski> morning
<mborzecki> zyga: hey, how are you feeling?
<mborzecki> pstolowski: hey
<zyga> hey pawel!
<zyga> mborzecki: without pain killers, pretty bad
<zyga> with them, passable
<zyga> two weeks of bed now
<zyga> but hey, special bed desk arrives today
<zyga> so no more cramped legs :)
<mup> PR snapd#8895 closed: tests: mock servicestate in api tests to avoid systemctl checks  (6/8) <Services âï¸> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8895>
<pedronis> hello
<mborzecki> pedronis: hey
<mborzecki> do we have a helper that checks wheher snapd reexec'ed?
<mborzecki> zyga: ^^
<zyga> mborzecki: I think we have some logic like that in cmd/* somewhere
<mborzecki> i see there's some code in snapdtool, but it derives the location of the internal tooling
<zyga> but there was some change recently
<mborzecki> zyga: i was hoping for something like `IsReexeced() (boot, error)` ;)
<zyga> right :)
<zyga> don't we have a env variable for thaT?
<pedronis> zyga: is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652 fixed released now?
<mup> Bug #1871652: snap run hangs on system-key mismatch due to reexec and shutdown <champagne> <snapd:Fix Committed by zyga> <snapd (Ubuntu):Confirmed for zyga> <https://launchpad.net/bugs/1871652>
<zyga> pedronis: I think so
<zyga> 2.44.3 was released as .5 IIRC
<mup> Bug #1870201 changed: lxd-support interface doesn't appear to get properly connected/ready <snapd:Triaged> <https://launchpad.net/bugs/1870201>
<mup> Bug #1871827 changed: git ubuntu submit fails on focal <snap> <submit> <usd-importer:New> <https://launchpad.net/bugs/1871827>
<mup> Bug #1882957 changed: Snapd `internal error: connection "[slot] [plug]" not found in state` <snapd:Triaged> <https://launchpad.net/bugs/1882957>
<mborzecki> zyga: hmm, we don't?
<mborzecki> zyga: looks like we're jut passing os.Environ() to exec
<pedronis> mborzecki: snapdtool is just what was in cmd  and cmdutil move to one place, didn't change or add much
<pedronis> *moved
<mborzecki> pedronis: zyga: in the context of #8861, i'm not sure we should be writing out the conf fies to /usr/share/dbus-1 unless snapd is reexeced
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<zyga> I agree
<mborzecki> hence the question whether there's any helpers that can tell us that
<zyga> it's not our place to write probably
<mborzecki> mhm, leaving a comment there for jamesh
<jamesh> mborzecki: if there are better places to do this stuff, I'm open to changing it.  But at the moment, that's where similar work is being done.
<pedronis> pstolowski: you are still working on #8891, right?
<mup> PR #8891: o/servicestate: add updateSnapstateServices helper (5/8) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8891>
<pstolowski> pedronis: yes, i'd like to play a bit and refactor this helper
<pedronis> ok
<pedronis> jamesh: hi, Jamie asked a question for you here: https://bugs.launchpad.net/snapd/+bug/1881232
<mup> Bug #1881232: AppArmor blocks ibus input when IBUS_USE_PORTAL=1 <snapd:Confirmed for pedronis> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1881232>
<mborzecki> jamesh: do you recall those other bits that write out system locations were? iirc there's some code for snapd on core and core->snapd remodels doing that
<mborzecki> maybe we should wrap those locations with an if{} too
<jamesh> mborzecki: it's writing out D-Bus activation files for "snap userd"
<jamesh> pedronis: looking
<pedronis> thx
<mborzecki> jamesh: thanks i will take a look, but it soulds like we could address this in a follow up
<zyga> brb
<zyga> re
<jamesh> pedronis: responded to the bug report.  Looks reasonable to add to the desktop interface (no need for desktop-legacy)
<mup> PR snapd#8898 opened:  snapdtool: helper to check whether the current binary is reexeced from a snap <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8898>
<mborzecki> jamesh: pedronis: ^^
<mborzecki> pedronis: i've tentatively put the helper in snapdtool
<pedronis> it's the right place
<mup> PR snapd#8899 opened: tests: add servicestate.Control tests (7/9) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8899>
<zyga> thunderstorms!
<mborzecki> zyga: yay, like there weren't enough for the last few days
<zyga> haha, right? :D
<zyga> tropical banana republic of polandia
<mborzecki> hahah
<zyga> I need to reboot to fix my system
<zyga> really heavy rain now
 * zyga small break for tea
<zyga> and larger break for lunch too
<mup> PR snapd#8900 opened: tests: extra worker for google-nested backend to avoid timeout error on uc20 <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8900>
<mborzecki> cmatsuoka: hi, i looked a bit why the cla check came up with your @gmail.com email address
<cmatsuoka> mborzecki: yeah, I found the merge node there
<mborzecki> cmatsuoka: it's probably the merge that happens automatically when the branch is not on top of current master
<cmatsuoka> mborzecki: but this is something that started happening on friday, I wonder if github changed something there
<cmatsuoka> mborzecki: I worked around it by changing my primary email address in github
<mborzecki> cmatsuoka: hm i could tweak the call to git shortlog -s -e --no-merges, though i'm thinking that there could be a merge that ahs some actual code changes due to conflicts
<cmatsuoka> mborzecki: the primary address change shouldn't be a problem (and now it will allow me to accept modiciation suggestions in reviews)
<cmatsuoka> it's interesting however that it never happened before, even in the same PR, and now it happens in all of them
<mborzecki> cmatsuoka: it's becase we landed some tweaks to cla_check
<mborzecki> cmatsuoka: https://github.com/snapcore/snapd/pull/8455 landed on friday
<mup> PR #8455: tests/lib/cla_check: expect explicit commit range <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
<cmatsuoka> mborzecki: mm ok, well, it's not causing problems for me anymore but if someone else complains we already know what's causing it and a potential workaround
<mborzecki> cmatsuoka: btw. thhere's a way to select differnt email address on per organization basis, but afaict it only affects notifiactions :/
<zyga> re
<cmatsuoka> mborzecki: ah interesting, I didn't find that settings on gh
<mborzecki> cmatsuoka: it's in notifications -> custom routing, but apparently does not affect commits
<cmatsuoka> ah, under notifications, ok, I didn't look there
<mborzecki> cmatsuoka: perhaps you can add your other email address to lp too
<mborzecki> (it's probably more convenient)
<cmatsuoka> yep, it's already on LP but it seems that I didn't sign the CLA using it
<mborzecki> cachio:  when did that problem on centos start appearing?
<cachio> last week
<cachio> mborzecki, I thought that was going to be fixed with the last update but didn't happen
<cachio> mborzecki, we use a base image which is provided by centos cloud project
<cachio> last week I updated the image manually
<cachio> I can do it again
<cachio> and it will start failing on snapd tests so then we can fix snapd tests
<cachio> mborzecki, what do you suggest?
<mborzecki> cachio: you can try updating, maybe ausearch will be consistent, but it may as well be a bug in the tool itself
<cachio> mborzecki, ok
<cachio> I'll manually update again
<cachio> mborzecki, thanks
<mborzecki> cachio: it used to show 'no matches' but i don't understand why it's not doing tghat anymore, do you have more of the log, or just the tiny snippet?
<cachio> mborzecki, just that
<jdstrand> pedronis: I'm happy to take bug #1881232 off your hands
<mup> Bug #1881232: AppArmor blocks ibus input when IBUS_USE_PORTAL=1 <snapd:Confirmed for pedronis> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1881232>
<pedronis> jdstrand: thanks
 * jdstrand assigns himself
<mborzecki> zyga: do you recall whether https://github.com/systemd/systemd/issues/12401 was introduced in 242?
<zyga> looking
<mborzecki> zyga: the linger workaround
<zyga> ah
<zyga> hmm hmm hmm
<zyga> numbers
<zyga> I don't recall for sure, let me look if I left a comment
<mborzecki> zyga: there's a comment indicating when the fix was done
<zyga> so you are asking about when the bug was introduced?
<zyga> IIRC it was always broken before that :)
<mborzecki> zyga: well, it must have worked before, otherwise they would not keep recommenting loginctl enable-linger in rhbz for rhel8
<mborzecki> hm must/should
<zyga> it may have been fixed in distros
<cachio> mborzecki, centos 8 updated
<zyga> but if you look, the required line to logind conf was only added in 243
<zyga> it probably worked with some distro config before that but master was broken
<mborzecki> zyga: do you recall which distros were broken?
<zyga> all that we tested
<zyga> I don't recall this being okay before 243 on any distro
<zyga> but I may be wrong
<mup> PR core18#152 closed: Make .disk/info visible on the root partition <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/152>
<mborzecki> zyga: hmm so the effect was that the director would not be created?
<mborzecki> zyga: i mean /var/lib/systemd/linger ?
<zyga> linger wouldn't do anything because logind could not create it
<zyga> logind itself worked okay
<zyga> just this part was impacted
<mborzecki> zyga: tried centos-8 and fedora-31/32, loginctl enable-linger seems to work fine, /var/lib/systemd/linger is already there even before i run the command, and then it creates the right file underneath
<zyga> how about centos-7?
<mborzecki> zyga: we don't do user sessions there anyway
<zyga> ah
<zyga> right
<mborzecki> zyga: i'll try wrapping that workaround with if ! test -d /var/lib/systemd/linger and see what happens
<zyga> sure
 * zyga will resume work later, need a break for painkillers to work again
<mborzecki> zyga: cachio: i've tried a couple of workaroudns for linger, but i need to run some errands now, opened #8901 to see if this one is sufficient
<mup> PR #8901:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>
<cachio> mborzecki, thanks
<zyga> ok
<cachio> I'll take a look
<mborzecki> and wth tests.session is formatted with tabs
<mborzecki> i don't think any other scripts use tabs
<mup> PR snapd#8901 opened:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>
<mborzecki> anyways, bbl
<mup> Issue pc-amd64-gadget#49 opened: Please provide dual-signed shim for UC20 1.0 <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/issues/49>
 * cachio lunch
<jdstrand> pedronis: hey, you assigned bug #1884444 to me, but it is working as expected. what did you want me to do with it?
<mup> Bug #1884444: SECURITY ISSUE: Snaps unconfined on CentOS and Fedora <snapd:New for jdstrand> <https://launchpad.net/bugs/1884444>
<pedronis> jdstrand: answer with the official stance on that
<ijohnson> tianon: do you know if this is the right docker repo to file an issue for the registry against ?
<ijohnson> https://github.com/docker/distribution/issues/3185
<tianon> ijohnson: for the registry in general, yes, but the specific issue you've filed is an issue with the registry image, which would be https://github.com/docker/distribution-library-image -- see also https://github.com/docker/distribution-library-image/issues/106 and https://github.com/docker/distribution-library-image/issues/107 (https://github.com/docker/distribution-library-image/pull/92)
<mup> PR docker/distribution-library-image#92: Fix security issues: bump alpine to 3.11, remove apache2-utils <Created by andriisoldatenko> <Merged by dmcgowan> <https://github.com/docker/distribution-library-image/pull/92>
<ijohnson> thanks tianon, I think I will close my issue and comment on the existing issues that if htpasswd is meant to not be in the image anymore, they need to adjust the docs too
<jdstrand> roadmr: hey, can you sync 20200622-2009UTC ?
<roadmr> jdstrand: certainly!
<jdstrand> msalvatore: ^ that has the cvescan override
<jdstrand> roadmr: thanks!
<msalvatore> jdstrand: thanks :)
<ijohnson> cachio: in order to run nested tests via qemu, I need to increase the amount of memory allocated to spread systems otherwise the nested QEMU allocation fails due to not being able to allocate all the memory for the nextedVM
<ijohnson> cachio: , is `memory: 4G` ok, or should I use `memory: 3G`?
<ijohnson> cachio: the other thing I could do is define a qemu-nested which uses `memory: 4G` and leave qemu at `memory: 2G`
<cachio> ijohnson, hi
<cachio> you are talking about memory of the host vm right?
<ijohnson> cachio: yes
<cachio> not the nested vm
<ijohnson> cachio: yes I want to increase the memory of the host VM in the qemu backend
<cachio> well, I think 4gb
<cachio> and then 2 for the host
<cachio> for the nested
<cachio> if you run nested suite of snapd then the default size for the nested is PARAM_MEM="-m 4096"
<cachio> and the host has 8gb
<cachio> so, you will need to update nested.sh to upate that
<ijohnson> cachio: ah I forgot actually that I had already decreased the nested VM memory in my local git tree to 2G, you're right it's 4G, so it would need to be at least 5G in the host
<cachio> ijohnson, yes
<cachio> 5GB should work
<cachio> or more
<ijohnson> cachio: since the current default is 2G, I think increasing to 5G is a bit much and may be unexpected to folks trying to run qemu spread tests locally as they will run out of memory very easily with even 3 spread workers, so I think I will just define a new qemu-nested backend which uses 8G
<cachio> ijohnson, yes
<cachio> it is easier
<cachio> ijohnson, if you need any help I am going to buy some stuff, please leave a note I'll read it once I am back
<ijohnson> cachio: I will open the PR for you to look at, but I will be EOD within the hour, but please take a look tomorrow
<ijohnson> cachio: it's not urgent so it can wait til tomorrow
<cachio> ijohnson, sure, I'll take a look once I'm back
<ijohnson> thanks
<cachio> np
 * cachio afk
<mup> PR snapcraft#3184 opened: build providers: check revision before switching <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3184>
<mup> PR snapd#8902 opened: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>
#snappy 2020-06-23
<mup> PR snapd#8903 opened: tests: new core config helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8903>
<mborzecki> morning
<mborzecki> mvo: hey
<mborzecki> quick errand, brb
<mvo> mborzecki: good morning
<zyga> Good morning
<zyga> I will start at 9
<zyga> Good to see you mvo!
<mvo> zyga: good morning. even better to see you :)
<mvo> zyga: hope you are well (enough)!
<mborzecki> re
<mborzecki> zyga: hey
<zyga> Iâm going to be soon. Just had my morning painkillers
<zyga> But even without them I think there is an improvement
<mborzecki> zyga: something is off in centos 8 with the change from #8901
<mup> PR #8901:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>
<mvo> zyga: nice!
<zyga> mborzecki: Iâll look in 20 minutes
<mborzecki> zyga: thanks
<mup> PR snapd#8904 opened: snapstate: use testutil.HostScaledTimeout() in snapstate tests <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8904>
<zyga> re
<zyga> in makeshift floor office
<zyga> I'm on bug shift today
<pstolowski> morning
<mborzecki> pstolowski: heya
 * zyga looks at the PRs 
<mborzecki> funny when syncing homes with a loptop through unison it takes significantly longer because of a bunch of 1gb files in snapd source tree that were left behind after i last played with uc20 imare prepare code for the spread tests
<zyga> mborzecki: can you push the syntax fixes to https://github.com/snapcore/snapd/pull/8901/files please
<mup> PR #8901:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901>
<zyga> heh
<zyga> :)
<mborzecki> haha
<mborzecki> ok
<zyga> commented in the RP
<zyga> PR
<mborzecki> zyga: ah, w8, the code that retries linger is further down
<zyga> where?
<zyga> I don't see any
<mborzecki> zyga: line 161/169
<zyga> hmm
<mborzecki> zyga: w8, 143/151
<zyga> ah I understand now
<mborzecki> zyga: enabling twice should be harmless, right? it jus drops a file under /var/lib/ssytemd/linger
<zyga> IIRC it does more than that
<zyga> but it enabling twice should be harmless if it works right
<zyga> I wonder what happens if we try and fail
<zyga> fix the system
<zyga> and try again
<zyga> enabling linger does start all the user services
<mborzecki> zyga: maybe we should disable/stop user@<uid>.service?
<mborzecki> zyga: in the branch when enable fails
<zyga> not sure, we'd have to look at logind to see what it does and where the current failure is placed in the sequence of calls
<mup> PR snapd#8898 closed:  snapdtool: helper to check whether the current binary is reexeced from a snap <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8898>
<mup> PR snapd#8900 closed: tests: extra worker for google-nested backend to avoid timeout error on uc20 <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8900>
<zyga> ok, my plan for today is to work some more on the udev mystery
<zyga> and then do bug triage
<zyga> and some iteration on branches
 * mborzecki wonders how to split a 2k 'WIP' commit nicely into smaller patches
<Cruft> Why is there an autostart service running without snaps that require auto starting applications?
<zyga> Cruft: the auto-start service runs once on session startup, in case there are things to do IIRC
<Cruft> but through systemd and or X-gnome-autostart or whatever it is now "hidden" from freedesktop spec, wouldn't you not only be able to enable or disable the permission to do so individually but also know if that service should even run?
<zyga> can you be more specific please, I'm not sure I understand what you meant
<Cruft> its to help snapd make sure the snap program(s) that have autostart functionality are run on startup correct?
<zyga> yes
<Cruft> Wouldn't you already know upon installation and or boot that that was the case?
<zyga> as those programs cannot use the normal method for starting
<zyga> I'm sorry, know what?
<zyga> that some programs auto-start?
<Cruft> That they would otherwise autostart
<Cruft> They are mounted on install right?
<zyga> are you saying that the programs should notify the user somehow that they auto-start?
 * zyga is confused as to what the exact problem is, sorry 
<zyga> yes, they are mounted
<Cruft> No. I'm saying that the auto start service should not be run unless an auto start application exists
<zyga> I see what you mean now
<zyga> it's much easier this way
<Cruft> Also that in the event that auto start applications exist, that it can be explicitly turned off if not already possible, therefor not running after
<zyga> we'd have to enable or disable this
<zyga> are you saying that you'd like to control this per app?
<Cruft> both
<Cruft> but A makes B easier
<zyga> I think they are unrelated, A is a service that you can disable per user or globally
<Cruft> I can control microphone permissions but not autostart? Eh.
<zyga> B is new (per user) state that needs UI and APIs to drive
<zyga> autostart is not an interface
<zyga> I see what you mean but it's not done this way technically
<Cruft> Is it just using freedesktop conventions to determine this?
<Cruft> Within the snap(s)
<zyga> somewhat, but it's more complex to prevent confinement escape
<mborzecki> Cruft: kind of, the app cannot drop a random file under $HOME/.config/autostart, iirc the service looks inside ~/snap/<name>/ instead
<Cruft> right so its using the same xdg / .config i guess per user autostart as a determination within the snap tree?
<zyga> yes
<zyga> there's also some extra layer
<zyga> that matches the desktop file
<zyga> again, to prevent confinement esape
<zyga> we cannot just use the desktop file that was created by the app
<Cruft> I'm more thinking in terms of deciding to run at all
<zyga> eventually there will be a portal
<zyga> and the UI will be nice
<zyga> this makes it work with existing programs
<zyga> without new APIs
<mborzecki> Cruft: maybe it's somthing to consider, but the whole selecting which app runs by tweaking gnome session is a pita since the old days
<Cruft> You must understand though that people who have no autostart snaps are now having their boot further slowed by a service to autostart snaps
<zyga> is it this slow?
<Cruft> Its not fast, it was slower than alot when I measured. That is how I found the service.
<Cruft> I have many snaps but none autostart
<mborzecki> Cruft: hmm the sevice actually globs inside ~/snap/*/current/.config/autostart
<zyga> Cruft: unfortunately there's no easy way to make it conditional
<Cruft> right so you would know at install time
<zyga> Cruft: as snapd does not mediate the act of opting into or out of autostart
<Cruft> to run the service in userspace
<zyga> no, we don't know at install time
<zyga> we only look in that auto-start service
<zyga> and if the file is there and matches something in the snap definition
<zyga> we start the snap app
<zyga> we don't have an event when a running app enables auto-start
<Cruft> So you have no first mount etc hook
<Cruft> for current or whatever
<zyga> this is not related to mounting
<zyga> I don't think you understand how this works
<zyga> when a running app decides to enable auto-start
<zyga> it drops a file into an xdg location
<zyga> we only re-map $HOME so it's not the real location
<zyga> that's all
<zyga> when a session starts, the auto-start service scans the per-snap $HOME of each snap
<zyga> and looks for the xdg auto-start information
<zyga> and then acts on it
<zyga> that's it
<zyga> there's no more logic
<Cruft> So rather than scanning post mount it scans every time you boot
<zyga> it's not post mount because this is dynamic
<zyga> and it's not every time you boot
<zyga> it's in the user session
<zyga> there's no way to statically say you want to auto start an app via xdg
<Cruft> So then why isn't the service disabled if no new snaps have been installed
<zyga> you must create a desktop file in a specific location in the home directory
<zyga> because it's not something we considered important, when there's nothing to do it's doing nothing pretty quickly
<zyga> and making it better is really hard
<zyga> and again
<zyga> you misunderstand how it works when you talk about installed snaps, you can have one snap and it can opt in and out of autostart
<zyga> so it's not about that
<mborzecki> Cruft: w8, maybe i'm confused, which service are we discussing here? /etc/xdg/autostart/snap-userd-autostart.desktop ?
<Cruft> I believe that was the one
<Cruft> Let me check
<Cruft> yes
<mborzecki> Cruft: ok, so this one starts when your graphics session is coming up, scans ~/snap/*/current/.config/autostart for relevant desktop files, starts any snaps that want autostat and exits, if there are no desktop files dropped by the snaps, then it exits
<ogra> Cruft, if it would scan post mount (i.e. before even GDM starts) it would have to scan *all* users homes instead of the home of the specific user that just logged in ... that would surely be a lot slower than running at session start
<ogra> snaps are mouned by systemd during boot ... way before you reach any session you could access
<ogra> *mounted
<Cruft> Oh believe me, I saw.
<mborzecki> Cruft: so you're saying the autostart service is running still after your session is fully up, or does it run slow during startup?
<Cruft> Both
<Cruft> and that it shouldn't be in either case.
<ogra> sounds like these are simply bugs ...
<mborzecki> Cruft: can you do `ps -ef |grep userd` ?
<Cruft> It could literally check during updates at the same time
 * zyga is confused about updates
<Cruft> yes, there is a line with the pid, time, etc
<mborzecki> Cruft: can you paste it?
<Cruft> no, i'm not on that computer on this machine
<Cruft> i can retype it i guess
<mborzecki> Cruft: you can skip the pid, i'm interested in the command `snap userd ..`
 * ogra could imagine that using a db instead of walking ~/snap/*/.config might speed up things quite a bit, but that would also mean completely moving away from freedesktop standards
<Cruft> you could shard them out in sqlite if you use that
<Cruft> as they currently stand
<zyga> none of that matters if apps don't use that
<zyga> so we support what apps do
<Cruft> I'm not sure what you're asking me to type mborzecki
<mborzecki> Cruft: `ps -ef|grep userd`, there should be a command in the last column that starts with `snap userd..`, please paste/type that in the channel
<ogra> he wants the most right entry of the ps output ð
<Cruft> snap userd
<zyga> that's the other userd
<zyga> not the auto-start thing
<mborzecki> Cruft: that's the user session helper that exposes dbus api for snaps to request xdg-open, manage xdg-settings and some other thing i don't recall now, incoming requests are sanitized
<ogra> ... and that specific one is rather unlikely to have any impact on session startup time ...
<mborzecki> Cruft: so you're saying that one starts slow?
<ogra> (as it starts async and nothing but snaps depend on it)
<Cruft> Yes
<Cruft> I can see that. I didn't realize this was go
<Cruft> welp, looks like i need to Delve into it
<mborzecki> Cruft: `snap userd` is actually started via dbus activation
<mborzecki> Cruft: i don't think it shows up as a systemd --user service
<Cruft> ah
<Cruft> ok yeh I see the two dbus unconfined services for snapd userd
<mborzecki> Cruft: yes, io.snapcraft.Settings and Launcher
<zyga> mvo: o/
<zyga> mvo: 2.45 is not released, right?
<zyga> I mean, I see it in groovy
<zyga> but focal has 2.44
<mvo> zyga: I asked sil2100 to look at the 2.45.1 SRU, he said he will get to it today :)
<mvo> zyga: but yeah, it's waiting in the unapproved queue
<zyga> sure I just wanted to know
<zyga> mvo: one more thing
<zyga> mvo: the core snap is at 2.45 while snapd is at 2.45.1
<zyga> is that expected?
<mvo> zyga: maybe because of phasing, let me double check
<mvo> zyga: hm, that sounds like we need to ask cachio what is going on there
<zyga> okay
<zyga> thanks, I just wanted to understand where we are to update bugs that are fix commited
<mup> Bug #1878374 changed: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374>
<zyga> mvo: do you expect 2.45.1? I would like to update the launchpad milestones
<zyga> oh. we have one :D
<zyga> ok
<mup> Bug #1878374 opened: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374>
<mup> Bug #1878374 changed: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374>
<zyga> I updated all the milestones that were open
<zyga> mvo: is the next release going to be 2.45.2 or 2.46?
<zyga> brb
<mvo> zyga: there will be a 2.45.2 most likely we have some requests for this
<zyga> I see
<mup> PR snapd#8905 opened: bootloader: introduce managed bootloader, implement for grub <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8905>
<mborzecki> pedronis: trivial piece ^^
<pedronis> mborzecki: thanks, will try to look at it soon
<mvo> degville: silly question, what should I use to add comments to a discourse page, i.e. something like "// XXX: needs update for the new fields" or similar?
<degville> mvo: html comments work
<degville> ie. <!-- comment -->
<mvo> degville: is that what is what we use elsewhere too? if so, I will use it
<mvo> degville: is the preview confused? in the preview the comment is displayed as is
<degville> mvo: well, we use it on the docs pages because the html comments aren't visible in the final output. For general Discourse comments, though, it doesn't really matter - I don't think syntax highlighting works.
<degville> mvo: it shouldn't be visible in the preview?
<mvo> degville: hm, maybe I do something wrong, let me try again
<degville> mvo: At least, I've just tried it and it's hidden for me.
<mvo> degville: yeah, silly me, works
<mvo> degville: thank you
<degville> it's not very pretty.
<mup> PR snapd#8906 opened: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
<mup> PR snapd#8907 opened: asserts: implement Database.FindSequence <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8907>
<mup> PR snapcraft#3184 closed: build providers: check revision before switching <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3184>
<zyga> mvo: is https://github.com/snapcore/snapd/pull/8436 something you wanted to cherry pick into 2.45.2?
<mup> PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8436>
<zyga> I'm asking if I should target the bug report accordingly
<zyga> I set the bug to target 2.46, if you want it in 2.45.2 just ping me and I'll adjust things
<mvo> zyga: iirc it was not super urgent but I can double check
<zyga> sure
<zyga> 2.46 is fine
<zyga> I'm only asking because it was squash merged
<zyga> sil2100: are we using classic eth0 or the new "stable" names on core images?
<zyga> sil2100: the context is a bug where pi4 has different behavior than prior images
<pedronis> ijohnson: I re-reviewed #8683
<mup> PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
<mup> PR snapd#8908 opened: overlord/snapstate: graceful handling of denied "managed" refresh schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8908>
<mborzecki> pedronis: ^^
<pedronis> mborzecki: reviewed
<mborzecki> pedronis: thanks
<zyga> pedronis: there's a request to extend the valid language for app commands to include the = sign, so that prog --opt=value would be allowed without wrappers
<zyga> pedronis: currently the allowed app expression is:
<zyga> var appContentWhitelist = regexp.MustCompile(`^[A-Za-z0-9/. _#:$-]*$`)
<pedronis> zyga: it's related to snapcraft dropping wrappers support for core20
<zyga> looking at this I think that adding = is probably okay
<zyga> but I wanted to ask you for advice
<zyga> indeed, it's mentioned in the bug report
<pedronis> well, we need to think this through
<zyga> sure, I've left it as whishlist
<pedronis> zyga: feel free to assign to it to me
<zyga> ok
<pedronis> doesn't mean we'll get to it quickly, but it's blocked on me either way
<zyga> sure
<zyga> sil2100: do you know where to track bugs about raspberry pi kernel?
<zyga> (on core)
<ijohnson> Thanks pedronis
<sil2100> zyga: hm, I guess I'd have to check with the ethernet device names, can't say from the top of my head
<zyga> sil2100: the bug claims that pi4 uses eth0
<zyga> sil2100: but earlier devices us en!@!#@!@#!
<sil2100> zyga: as for the pi kernel bugs, I guess they're handled as any others - so fill in a bug for linux-raspi on LP :)
<mup> PR snapd#8909 opened: interfaces/apparmor: allow snap-specific /run/lock <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8909>
<zyga> thanks, that's what I needed
<zyga> sil2100: hmm, no such project
<zyga> oh well
<zyga> standup time
<sil2100> zyga: hah, it's not a project, it's a package: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/
<ogra> zyga, linux-raspi for focal ... linux-raspi2 for anything before (see https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1881623 that was triaged by juerg (our pi kernel maintainer)
<mup> Bug #1881623: USB support missing in initrd makes booting core with writable on USB impossible <linux-raspi (Ubuntu):New> <linux-raspi2 (Ubuntu):Confirmed> <linux-raspi2 (Ubuntu Xenial):New> <linux-raspi2 (Ubuntu Bionic):New> <linux-raspi (Ubuntu Focal):New> <https://launchpad.net/bugs/1881623>
<zyga> ogra: ah, a source package
<zyga> ogra: got that, thanks!
<ogra> yep
 * zyga breaks for lunch
<mup> PR snapd#8904 closed: snapstate: use testutil.HostScaledTimeout() in snapstate tests <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8904>
<zyga> re
<mup> PR snapcraft#3179 closed: Maven plugin: improve error message when target libs are not found <bug> <Created by edumucelli> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3179>
<pstolowski> i managed to reproduce https://bugs.launchpad.net/snapd/+bug/1882957 with my spread test. funny thing is it happend after fleshing things out in the test and re-arranging some ops
<mup> Bug #1882957: Snapd `internal error: connection "[slot] [plug]" not found in state` <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1882957>
<cachio> mvo, hey
<cachio> mvo, the snap ubuntu-clock-app isnot in the repo anymore, so the test for unity fails
<cachio> do you know any other snap that could be used instead
<cachio> ?
<mup> PR snapd#8910 opened: usersession: support additional zoom URL schemes <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8910>
<mborzecki> hm gadget Update/Backup/Rollback could use a little refactor
<mborzecki> anyways, errands, bbl
<mvo> cachio: uh, a good question
 * cachio lunch
<abeato> zyga, hey, I have seen a problem with layouts, in a qemu environment where I installed NM, it looks like the layout is not really happening, I cannot see the files inside the snap. If I look at the mount namesapce, I see:https://paste.ubuntu.com/p/sDCdbm9Jqz/
<zyga> hey!
<abeato> hi :)
<zyga> ah , //deleted
<abeato> yeah...
<zyga> I'm doing bug triage now, can you please show me some more context
<abeato> I am installing on qemu, while running spread tests
<abeato> I have a snap version with core18, and I install on top a core20 version of the snap
<abeato> the first does not use layouts, the second does
<abeato> if I reinstall the snap, things look good and there is no //deleted string
<zyga> what are the layout definitions
<zyga> actually, I think it's best if you report a bug
<zyga> with all the details
<zyga> I'll try to look at it in the evening
<zyga> I have a few more bugs to go through today
<abeato> zyga, sure will do - I wanted to double check if this was a known issue before
<zyga> it may be known behavior
<zyga> depending on the paths used
<zyga> the //deleted thing is really interesting part of linux
<zyga> I didn't know about it before I started working on snapd
<abeato> seems like some timing problem, some times happens, some times it does not
<zyga> abeato: I think it's not timing as snapd is freezing the world for mount changes
<zyga> probably sequence
<zyga> I'll gladly analyze it in detail and explain what's going on
<ijohnson> cachio: for https://github.com/snapcore/snapd/pull/8902#issuecomment-648236050 how did you reproduce this ?
<mup> PR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>
<abeato> zyga, https://bugs.launchpad.net/snapd/+bug/1884806
<mup> Bug #1884806: layouts are not honored some times <snapd:New> <https://launchpad.net/bugs/1884806>
<zyga> abeato: thank you!
<abeato> np
<zyga> abeato: btw, what is /usr/var?
<abeato> zyga, a folder with some config files for NM
<zyga> I mean, I don't have /usr/var on my classic system
<zyga> it's a weird location
<zyga> is that hardcoded in n-m?
<abeato> zyga, it is the default in nm, unless you change it with config options - which we do in the deb
<abeato> for the snap anyway we override it
<zyga> I see
<zyga> ok
<zyga> I'll look more closely
<zyga> can you do one quick test perhaps
<abeato> sure
<zyga> refresh the exact same revision twice
<zyga> just install --local perhaps
<zyga> and see if that has the same effect
<abeato> hm I did not know that one
<abeato> zyga, not sure what is that? 'snap install --local' does not exist
<abeato> zyga, refreshing the same revision actually works
<abeato> zyga, also disabling then enabling the snap
<zyga> ah, sorry
<zyga> not local
<zyga> I meant --dangerous :)
<zyga> and just install the .snap file
<zyga> instaling the same snap file twice tests if layout system can re-construct a no-update update
<abeato> zyga, yeah, that works
<zyga> abeato: thanks for checking, that's useful to know
<zyga> abeato: perhaps there's an issue with core18 -> core20 transition
<zyga> I'll debug this
<abeato> great
<mup> PR snapd#8911 opened: asserts,seed: split handling of essential/not essential model snaps <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8911>
<pedronis> ijohnson: this ^ tries to address some of your concerns about the seed code
<ijohnson> thanks I will take a look
<mvo> pedronis: I updated 8889 a bit
<pedronis> mvo: thx, adding it back to my queue
<mup> PR snapcraft#3185 opened: cli: allow promoting from edge without --yes <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3185>
<zyga> mvo: I'll take a break now, see you tomorrow
<zyga> after Thursday typing won't be such a chore
<cachio> ijohnson, sorry
<cachio> spread -debug google-nested:ubuntu-16.04-64:/tests/nested/core/image-build
<ijohnson> cachio: I am running `spread --debug -v google-nested:...:tests/nested/` now, and have not seen any failures yet
<cachio> spread -debug google-nested:ubuntu-16.04-64:tests/nested/core/image-build
<ijohnson> haha literally as I just sent that it failed on a tet
<ijohnson> let me look
<cachio> core-18 workerd perfect here
<cachio> ijohnson, also failed with timeout uc20
<ijohnson> cachio: yes I just saw the uc20 failure here, I will investigate
<ijohnson> actually I need to break for lunch, but will investigate more afterwards
<cachio> ijohnson, something that I forgot SPREAD_USE_CLOUD_INIT=false
<cachio> you need to use that to force the use of the assertion disk
<cachio> otherwise by default it will use cloud_init
<ijohnson> cachio: let's chat a bit later after I'm back from lunch
<cachio> ijohnson|lunch, sure
<cachio> mvo, should we run the unity test in nightly in case there is not any unity snap available?
<ijohnson|lunch> cachio: I didn't reproduce that error with my current patchset, let me push it up before my next meeting
<ijohnson|lunch> cachio: I will attach the log from my run in the PR
<cachio> sure
<cachio> I'll make another tun
<cachio> run
<ijohnson> cachio: please pull from the branch, but here's the output from my most recent run https://github.com/snapcore/snapd/pull/8902#issuecomment-648321737
<mup> PR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>
<mvo> cachio: I think we can stop testing unity if we don't have any snaps. let's remove it
<cachio> mvo, sure, thanks
<mvo> yw
<ijohnson> cachio: I didn't try with preparing all of these without cloud-init yet I just want to make sure that the PR is good when using cloud-init for the users, a followup will use the assertions disk
<ijohnson> cachio: in other words the spread run I linked to in the PR comment doesn't have SPREAD_USE_CLOUD_INIT=false defined
<ijohnson> cachio: so if you could test just normally that would be great to see
<cachio> ijohnson, ok
<ijohnson> thanks
<cachio> let me try
<ijohnson> I will look more after my meeting now
<cachio> ijohnson, in core16 workerd with SPREAD_USE_CLOUD_INIT=false and without
<cachio> so the fix works
<cachio> let me check uc20
<ijohnson> cachio: yes let me look at why the uc20 ones failed
<mup> PR snapcraft#3186 opened: Riscv64 support <Created by xnox> <https://github.com/snapcore/snapcraft/pull/3186>
<ijohnson> cachio: for me, only tests/nested/core20/basic and 64:tests/nested/manual/core20-early-config failed
<cachio> ijohnson, yes, this is something different
<cachio> I need to take a look tomorrow to that one
<cachio> ijohnson, so, on uc20 the user assertion creates the user but then I see https://paste.ubuntu.com/p/zgDk4hWFqb/
<cachio> error: too early for operation, device not yet seeded or device model not acknowledged
<cachio> ijohnson, I am running again
<ijohnson> cachio: ah interesting
<ijohnson> cachio: I hit your bug with the /dev/mapper/loop2p1 issue, it's a race condition but I can fix it easily, I will push something up
<roadmr> jdstrand: heads up, xnox is about to send your way a bug about making review-tools happy with a new architecture
<cachio> perhaps we'll need to wait until seeding is copmleted, right?
<ijohnson> cachio: perhaps
<ijohnson> cachio: for uc20 probably yes, but the /dev/mapper issue is not related to seeding
<ijohnson> (but I know how to fix it
<ijohnson> )
<jdstrand> roadmr: that will be interesting to fix, as I likely will need core20 but focal has bugs in various places
<roadmr> the fun
<ijohnson> cachio: did you ever figure out the deal with uc20 nested VMs rebooting constantly ?
<cachio> ijohnson, well, it used to reboot 1 once by using -smp 1
<ijohnson> cachio: in the log I'm looking at the nested VM got rebooted at least 10 times before the spread timeout got hit, looks like less than a minute after it booted it got rebooted
<cachio> ijohnson, I saw different bug reports similar
<cachio> but not sure the reason
<cachio> ijohnson, reboots in install mode?
<cachio> run mode?
<ijohnson> cachio: in run mode
<ijohnson> cachio: although actually maybe install mode too, don't remember
<ijohnson> let me show you the log
<cachio> it is the same I see
<cachio> here in the last log
<ijohnson> cachio: this is the serial boot log from the nested VM: https://pastebin.ubuntu.com/p/b9PHpFkFKm/
<ijohnson> yeah it was rebooted 6 times I guess, all the unintended reboots were in run mode
<cachio> ijohnson, well this is not normal
<cachio> at least should reboot 1 extra time
<cachio> but not more
<ijohnson> haha yeah I would agree it is not normal for a VM to get randomly rebooted 6 times at random points in the boot sequence
<cachio> perhaps it is related to the usr assertion
<cachio> hehehe
<ijohnson> cachio: could be, this run was with SPREAD_USE_CLOUD_INIT=false just to see what happens with the assertions on all the systems
<cachio> I triggered new executions with and without user assertion to see if that could be the reason
<ijohnson> it eventually made it to a successful boot and is running normally now, but it did not import the assertion on uc20
<cachio> last run I did worked, it took 15 minutes to prepare the nested vm and connecto shrough ssh
<ijohnson> cachio: it is very slow
<cachio> ijohnson, yes
<mup> PR snapcraft#3176 closed: tools: fix environment-setup to work on aarch64 <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3176>
<cachio> perhaps there were some reboots
<cachio> ijohnson, this is the last run https://paste.ubuntu.com/p/83MKxjngDv/
<ijohnson> cachio: I think as long as this branch is working with the default  SPREAD_USE_CLOUD_INIT=true the way the tests run now, we should push forward with this branch and I can propose follow-ups to fix using assertions
<cachio> ijohnson, sure
<ijohnson> cachio: so it seems it is randomly failing with uc20 then
<cachio> ijohnson, yes
<cachio> this is related to some errors we have seen with kvm and gce
<ijohnson> cachio: ok I just pushed up a fix for the loop device not available problem you saw, it should eliminate the race condition, I think we should probably merge this then and continue with a followup PR
<cachio> if you run without kvm then never reboots
<ijohnson> cachio: what do you think ?
<cachio> ijohnson, it is ok
<cachio> it is working pretty well now
<cachio> just that problem but shouldn't affect the current nightly executions
<ijohnson> cachio: what do you mean about not rebooting without kvm ?
<ijohnson> cachio: you only see these random reboots with kvm enabled ?
<cachio> we use qemu with kvm aceleration
<ijohnson> i.e. -machine ubuntu-q35,accel=kvm ?
<cachio> if I run without kvm acceleration those random reboots never happen
<cachio> ijohnson, right
<ijohnson> ah very interesting
<cachio> the problem is that if we don't use kvm then the execution is very slow
<ijohnson> right
<cachio> and something interesting is that if we dont use ovmf the reboots don't happen
<ijohnson> cachio: where did you report this bug again? I remember reading through your LP bug you filed but I don't remember where now
<cachio> so it is a combination between could + ovmf + kvm
<cachio> ijohnson, a time agou I created the bug in launchpad
<cachio> in kvm project
<ijohnson> do you have the link ?
<cachio> ijohnson, let me check
<cachio> ijohnson, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1872803
<mup> Bug #1872803: VM reboots using qemu and kvm with ovmf <qemu (Ubuntu):Expired> <https://launchpad.net/bugs/1872803>
<cachio> ijohnson, this issue should address that https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1882774
<mup> Bug #1882774: issues with secondary VMX execution controls <sts> <verification-done> <verification-done-focal> <Ubuntu Cloud Archive:New> <qemu (Ubuntu):Fix Released> <qemu (Ubuntu Focal):Fix Committed> <https://launchpad.net/bugs/1882774>
<ijohnson> thanks cachio, very interesting
<mup> Bug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>
<mup> Bug #1874156 opened: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>
<mup> Bug #1413410 changed: Unable to match embedded NULLs in unix bind rule for abstract sockets <aa-kernel> <aa-parser> <AppArmor:Fix Released by jjohansen> <AppArmor 2.9:In Progress> <Snappy:Invalid> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1413410>
<mup> Bug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156>
<ijohnson> cachio: interesting, another nested uc20 w/ assertions enabled failed due to all the random reboots, but it never got through to run mode: https://pastebin.ubuntu.com/p/4ggsB5mbhY/
<cachio> ijohnson, let me try with the qemu from proposed
<cachio> that could contains a fix
<mup> PR snapcraft#3185 closed: cli: allow promoting from edge without --yes <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3185>
<ddstreet> hi all, anyone know if snaps are building and/or providing dbgsyms yet? or is that still a future item?
<ijohnson> hi ddstreet what's been recently implemented is support for gdbserver, where a gdbserver will be run from inside a snap's confinement such that you can then connect from outside snap confinement to that gdbserver to debug the snap
<ijohnson> ddstreet: that will allow you to have dbgsysm exist on the host outside of the snap and debug the snap
<ijohnson> there's a forum post about this here: https://forum.snapcraft.io/t/new-experimental-snap-run-experimental-gdbserver-option/18227
<ddstreet> ijohnson thanks! and are snaps now built with dbgsyms included?
<ijohnson> ddstreet: that is up to each snap, most are not built with dbgsyms afaik
<ddstreet> hmm ok, so do you know if at least canonical-provided snaps include dbgsyms?  e.g. chromium?
<ddstreet> or any documented way to tell if a snap includes dbgsym?
<mup> PR snapd#8912 opened: tests: update unity app on nightly test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8912>
<ijohnson> ddstreet: there is no documented way to tell if a snap includes dbgsym outside of just looking at it
<ijohnson> ddstreet: why do you ask ?
<ddstreet> more recently there's an email to ubuntu-devel-discuss asking how to debug chromium, and it was pointed out it's a snap now, which led to discussion about not being able to debug snaps
<ddstreet> but more in general, i'm part of canonical sustaining engineering, and it's something that we are going to face at some point in the very near future
<ijohnson> ddstreet: right so today you have both snap run --gdb chromium, which will run gdb inside snap confinement, but then you can't load debug symbols without modifying the snap to include those
<ijohnson> ddstreet: that is helped by gdbserver, but where we still fall short is that we don't have equivalent debug symbol snaps that could be uploaded alongside the actual running snap
<ijohnson> ddstreet: not sure if that's currently on the roadmap, but I know that's been discussed to have a new snap type just for debug symbols to be produced at the same time
<jdstrand> roadmr: hey, in case you didn't see in the bug comment from 30 seconds ago, 20200623-2050UTC has the riscv64 update
<roadmr> jdstrand: oh I didn't :)
<jdstrand> roadmr: if you can pull whenever it makes sense for you, that would be great
<roadmr> I'll queue it up!
<jdstrand> thanks :)
 * roadmr checks time
<jdstrand> xnox: fyi (and thanks again)
<roadmr> just enough time to land/QA today so maybe it can be deployed tomorrow
<jdstrand> xnox: ^
<roadmr> I'm off tomorrow but the awesome team might deploy
<jdstrand> cool
<mup> PR snapcraft#3173 closed: cli: use snap pack instead of mksquashfs <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3173>
#snappy 2020-06-24
<mup> PR snapd#8902 closed: tests: fix assertion disk handling for nested UC systems <Squash-merge> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8902>
<mborzecki> morning
<zyga> Good morning
<zyga> Iâll start at 9
<zyga> Just checking mail in the morning
<mborzecki> zyga: hey
<zyga> My keyboard is already in Warsaw
<zyga> Maybe it will be delivered a day earlier
<zyga> Oh 2.45 has regressed Snapcraft and Ubuntu image
<mborzecki> zyga: hmm? bugs?
<mborzecki> zyga: do you know what broke?
<zyga> re
<zyga> I will look now
<zyga> I just got mail that autopkgtest regressed
<zyga> hmmm
<zyga> the log is rather useless
<zyga> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/snapcraft/20200624_005739_df199@/log.gz
<zyga> it says
<zyga> deb2snap             FAIL non-zero exit status 1
<pstolowski> morning
<zyga> earlier there's this warning
<zyga> [1mWarning:[0m /snap/bin was not found in your $PATH. If you've not restarted your
<zyga> hey pawel
<zyga> (along with ansi escapes, yuck)
<zyga> maybe something did regress on path?
<zyga> let's look at the other regressions
<zyga> there's a rather silly regression in snapd
<zyga> + snap install --edge test-snapd-hello-multi-arch
<zyga> error: snap "test-snapd-hello-multi-arch" is not available on edge for this architecture (i386) but exists on other architectures (amd64).
<mvo> zyga: wuut? how can that happen
<zyga> good morning mvo!
<zyga> I was about to ask that :)
<mvo> zyga: oh, is that on 20.04 where i386 got removed?
<mvo> zyga: good morning :)
<zyga> no, this is on 19.10
<zyga> https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#snapd
<zyga> maybe something go removed wrongly
<zyga> oh oh
<zyga> OH
<zyga> my keyboard is coming now
<mborzecki> haha
<zyga> mvo: this snap is multi-arch in the sense that it contains i386 binary inside amd64 contianer
<zyga> *container
<zyga> so it should work on 20.04+
<zyga> there's only one revision
<zyga> so whatever broke didn't involve the snap changing
<mvo> zyga: woah
<mvo> zyga: very strange
<zyga> mvo: does snapcraft error make any sense to you
<zyga> I'm trying to make some sense out of the log
<mvo> zyga: you mean [1mWarning:[0m /snap/bin was not found in your $PATH. If you've not restarted your ?
<zyga> that seems like a warning that's earlier up the log
<zyga> the log ends with:
<zyga> deb2snap             FAIL non-zero exit status 1
<zyga> what is deb2snap?!
<zyga> the whole part reads:
<zyga> https://www.irccloud.com/pastebin/UmCedmeB/
<mvo> zyga: it's some sort of helper iirc to transition debs to snaps, iirc it started with chromium
<zyga> maybe version changed :D
 * zyga checks
<mvo> zyga: I bet
<zyga> lol
<zyga> 4
<zyga> yes
<mvo> zyga: the test failure does not make much sense - also autopkgtest
<mvo> zyga: ha!
<mvo> fun
<zyga> current version is 4.05
<zyga> 4.0.5
<zyga> so where is the test that needs fixing
 * zyga looks
<mvo> zyga: this is a silly test then - will you tell sergiusens about "autopkgtest [00:57:26]: test deb2snap: [-----------------------" failing because the version number changes :) ?
<zyga> sure :)
<pedronis> mvo: it seems we broke the snap-auto-mount test on master for core20
<mborzecki> pedronis: do you have logs?
<mborzecki> pedronis: nvm, it failed in my pr too
<pedronis> mborzecki: yes, as I said seems to be really broken, failing consistently
<mborzecki> was this modified recently?
<mborzecki> i did some changes to coldplug auto-import, but it was back in may iirc
<mborzecki> and debugging is broken too, there's no /var/log/syslog :/
<pedronis> mborzecki: not sure, but maybe some of the test assertions were changed
<pedronis> for other tests
<mvo> yeah, wonder why it's happening now. maybe something else changed too?
<mvo> new udev or systemd in core20 maybe?
<zyga> new systemd!
<mup> PR snapd#8913 opened: tests/core/snap-auto-mount: fix debug section <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8913>
<mborzecki> let's see if there's any useful output
 * mvo is in a meeting but will follow from the sidelines
<pedronis> #8889 needs a 2nd review
<mup> PR #8889: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8889>
<mborzecki> heh, the test runs succesfuly in isolation
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/8910
<mup> PR #8910: usersession: support additional zoom URL schemes <Bug> <Needs security review> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8910>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8889#pullrequestreview-436420132
<mup> PR #8889: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8889>
<mborzecki> zyga: lucky us that zoom has no more url schemas ;P
<zyga> mborzecki: yet :D
<zyga> keyboard is here
<zyga> brb
<mborzecki> zyga: maybe you could reference https://github.com/snapcore/snapd/pull/8761#pullrequestreview-425508154 for the msteams://
<mup> PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8761>
<zyga> mborzecki: sure, I was looking for it
<zyga> need a moment to adjust
<zyga> so weird
<zyga> so weird and comfortable
<zyga> getting used to the layout will take a momentt
<zyga> there are four layers to lean
<zyga> learn
<mborzecki> zyga: it's 2 separate pieces right?
<zyga> yes
<mborzecki> wireless in between or wired?
<zyga> wired with a detachable cord
<mborzecki> zyga: and keyboard -> pc wired too?
<zyga> RJ11 phone connector
<zyga> yes
<zyga> it has a custom app
<zyga> FOSS, they provide a appimage
<zyga> an
<mborzecki> we need a snap then :)
<mborzecki> but wow, rj11, haven't seen those in a while
<zyga> it's actually practical
<zyga> not custom
<zyga> not USB
<zyga> mouse layer!
<zyga> ok, somewhat adjusted now
<zyga> apart from annoyance when my muscle memory doesn't match
<zyga> there is no strain now
<mvo> zyga: thank you, lookin gnow
<zyga> sure
<zyga> feel free to push this to me
<mup> PR snapd#8702 closed: overlord/configstate: add system.kernel.printk.console-loglevel option <Created by EthanHsieh> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8702>
<mup> PR snapd#8914 opened: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8914>
<zyga> mborzecki: I've added the reference to msteams pull request now
<mborzecki> zyga:  thanks!
 * zyga small break to move around a little
<zyga> I need to focus on https://github.com/snapcore/snapd/pull/8881 now
<mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<zyga> why do my PRs get 50+ comments ;-)
<mborzecki> pedronis: zyga: got some debug logs in snap-auto-mount PR https://github.com/snapcore/snapd/pull/8913/checks?check_run_id=802673638
<mup> PR #8913: tests/core/snap-auto-mount: fix debug section <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8913>
<mborzecki> meh: 2020-06-24T09:38:28.0114940Z + is_core_nested_system
<mborzecki> 2020-06-24T09:38:28.0115148Z /home/gopath/src/github.com/snapcore/snapd/tests/lib/nested.sh: line 158: NESTED_TYPE: unbound variable
<zyga> looking
<zyga> ah
<zyga> good old shell
<mborzecki> duh, how come some of the code runs under -u and other parts do not
<zyga> -u?
<mborzecki> set -u
<zyga> ah
<mborzecki> hm spread does not set -u for the test scripts, so how did it end up being set there?
<zyga> IIRC there was something similar
<zyga> when we learned that set -e is easily lost
<zyga> with stuff as simple as ( )
<mborzecki> zyga: there was some subshell weirdness combined with () and {}
<mborzecki> 2020-06-24T09:38:27.4134740Z Jun 24 09:38:27 ubuntu snapd[2470]: daemon.go:313: DEBUG: pid=2735;uid=0;socket=/run/snapd.socket; POST /v2/assertions 10.868987ms 200
<mborzecki> 2020-06-24T09:38:27.4135673Z Jun 24 09:38:27 ubuntu snapd[2470]: daemon.go:313: DEBUG: pid=2735;uid=0;socket=/run/snapd.socket; POST /v2/users 446.144Âµs 200
<mborzecki> so importing assertions was succesful?
<zyga> mborzecki: don't you love our state-sharing shell functions
<pedronis> mborzecki: some our .sh set set -u
<zyga> that's why I don't want to see more shared state shell code
<mborzecki> pedronis: oh, right sourcing those can mutate the state :/
<pedronis> isn't this prepare.sh anyway?
<pedronis> it has a set -eux
<zyga> only executed programs are possible to reason about
<mborzecki> pedronis: the unbound error popped up in debug section
<mvo> zyga: I replied to #8889
<mup> PR #8889: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8889>
<mborzecki> pedronis: iirc those were separate shell instances
<zyga> thanks mvo
<mvo> thank you!
<pedronis> mborzecki: not sure, the log is a bit confusing
 * pstolowski lunch & errand
<ijohnson> morning folks
<ijohnson> sorry mborzecki
<ijohnson> that NESTED_TYPE was my fault :-(
<zyga> mvo: replied
<zyga> good morning ijohnson!
<mborzecki> ijohnson: no worries and good morning
<clmsy> hi, quick question, there are some packages that their snaps dont exist, such as dracut, clevis etc (things i need to implement full disk encryption on ubuntu core 16 based image).  I decided to do stage-packages into the gadget snap and when the machine boots i could reorg files under /etc /usr/lib /usr/bin etc but i ofc forgot for a moment that its read-only for security
<clmsy> am i completely bound to the fact that i need these packages as snaps so they can be used by the system, i cant just prime them into the gadget than try to move them under main paths like /usr/..
<ijohnson> clmsy: iiuc trying to use dracut on an ubuntu-core system will not work, as the initramfs is in the kernel snap and that is read-only
<ijohnson> clmsy: yes you cannot add things to the root filesystem that is not already in the base snap (which for ubuntu core 16 is the core snap)
<ijohnson> clmsy: that being said some directories are writable and can be modified
<ijohnson> clmsy: see writable-paths man page on ubuntu
<zyga> clmsy: squashfs is pretty much read only and it is unrelated to security
<mborzecki> was dracut even used for uc16?
<ijohnson> mborzecki: I don't think so
 * zyga small break
<clmsy> does this mean guys that i am bound to wait for ubuntu core 20 for full disk encryption that i just cannot implement it for 16
<ijohnson> clmsy: it is implementable for uc16, we have had commercial customers for whom Canonical Field Engineering team implemented full disk encryption, but I don't recall more details than that
<zyga> clmsy: on which architecture?
<ijohnson> clmsy: if you are interested in talking to our Field engineering team, I would refer you to ogra
<clmsy> we are using this https://fit-iot.com/web/products/fitlet2/
<clmsy> intel atom 64bit
<zyga> if it has TPM I would really go after core20
<clmsy> it has tpm yes
<zyga> it's probably easier than retrofitting this into uc16
<clmsy> i should also email ogra maybe to take his opinion
<zyga> it's a lot of work
<ijohnson> clmsy: does it have tpm 2.0 ?
<zyga> really nice box btw!
<ijohnson> clmsy: also yes what zyga said, we designed uc20 with full disk encryption in mind so that it's easier than it used to be for ubuntu core 16 and 18 to implement full disk encryption
<ijohnson> clmsy: also if ogra isn't around, you could also reach out to lool
<zyga> and uc20 based system can install and use core16 and core18 apps
<zyga> so you don't lose anything
<zyga> anyway brb
<clmsy> i really appreciate your feedback guys, i ve been fiddling and fighting to make it work for the last week
<clmsy> is there a generic email addr for field engineering team at canonical i can send an email to
<mborzecki> clmsy: if you have the box around, you can try uc20 beta (just saying)
<ijohnson> clmsy: yes, let me get email that for you, one minute
<ijohnson> clmsy: also it seems that device has tpm 2.0 through the intel firmware
<ijohnson> so it should just work with uc20 beta: https://docs.ubuntu.com/core/en/releases/uc20
<clmsy> i actually implemented uc20 beta
<clmsy> having an issue there
<clmsy> i used the baseline from snapcore
<clmsy> in the gadget.yaml file under the repo snapcore
<clmsy> a volume is defined as ubuntu-boot, but when i bot it says no such device etc
<clmsy> ill try keep working on it
<clmsy> let me get an email addr i would really like that
<clmsy> ^_^
<ijohnson> clmsy: the ubuntu-boot missing on first boot is expected, it should continue to boot past that though
<ijohnson> clmsy: do you have uefi enabled on the device ? it seems relatively new so I assume so
<clmsy> uefi is enabled, secure boot is also enabled, it does continue to recovery boot but than you know what happens, the-tool service fails with exit code (1) and says the following: model does not specify all the requestted essential snaps: [base kernel snapd]
<clmsy> and the model actually does specify all of them
<clmsy> i actually send an email to a canonical contact of ours
<clmsy> Ondrej Kubik
<clmsy> with all the details and screenshots, and even our model json file
<clmsy> he is the only contact i know
<ijohnson> clmsy: can you show your model assertion snaps header ? (and sorry I'm still waiting trying to figure out an email to give you)
<ijohnson> i.e. the bit that has `snaps: [...]`
<clmsy> yes 1 sec
<clmsy> this is the snaps map: https://pastebin.com/Z49qbDVr
<clmsy> on top of the model base is core20 and grade is secured
<ijohnson> clmsy: ah you are hitting this bug: https://bugs.launchpad.net/snapd/+bug/1883973
<mup> Bug #1883973: cannot boot uc20 model with multiple base snaps <snapd:Fix Committed by pedronis> <https://launchpad.net/bugs/1883973>
<ijohnson> clmsy: unfortunately the fix that bug has not yet been released, but you can kinda fix it locally until it gets released to the pc-kernel
<ijohnson> clmsy: also I would suggest using latest/beta for all your snaps for now, rather than latest/stable, as right now all the stable snaps for uc20 are not quite stable, I mean they should be good, but we are much more actively testing the beta snaps right now rather than the stable ones
<clmsy> oooh that seems to be the bug yes
<clmsy> thank you for letting me know! i really appreciate it... i was trying a lot of different things to see if i can do a workaround
<clmsy> im glad this irc channel exists ^_^
<ijohnson> clmsy: give me a minute to get you a script that you can use to fix the kernel snap
<ijohnson> clmsy: ok so download this script from this gist: https://gist.github.com/bboozzoo/010ed5e94ee0f695d1aeece43513a018
<mup> PR snapd#8889 closed: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8889>
<ijohnson> then use this script to rebuild the kernel snap (which uses that script): https://pastebin.ubuntu.com/p/J7TXCMrdYZ/
<ijohnson> clmsy: ^
<clmsy> thank you very much for the help!!!!
<ijohnson> clmsy: also to contact field engineering please reach out to sales@canonical.com and you can mention that you were referred there by snapd developers on #snappy IRC channel
<clmsy> perfect!! most helpful
<clmsy> i'll get to working on this issue
<ijohnson> yes please reach out again if you are having more trouble with uc20, we are happy to help and welcome any feedback/bugs you have about it :-)
<clmsy> <3
<zyga> re
<zyga> back to fixes
<mborzecki> Eighth_Doctor: hey, i see you've started pushing out updates, thank you!
<Eighth_Doctor> ðï¸
<mup> PR snapd#8915 opened: gadget: do only one mount point lookup in mounted fs updater <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8915>
<mborzecki> ijohnson: pushed a fix for NESTED_TYPE to #8913
<mup> PR #8913: tests/core/snap-auto-mount: fix debug section <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8913>
<ijohnson> thanks mborzecki, approved
 * zyga is slow today, sorry, learning curve 
<mborzecki> hm maybe snap-auto-mount is racy, but afaict (pedronis please correct me), by the time the POST /api/v2/assert request returns all processing is done
<mborzecki> or it's another another udev settle/async thing that pops up randomly
<pedronis> mborzecki: yes, should be done
<NerdSnapper> o/ need help with youtube-dl snap, seems to be an outdated version not working anymore. can i manually update the binary in the snap packet?
<mup> PR snapd#8901 closed:  tests/lib/tools: apply linger workaround when needed  <Precious Logs> <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8901>
<mup> PR snapd#8908 closed: overlord/snapstate: graceful handling of denied "managed" refresh schedule <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8908>
<NerdSnapper> sorry if this is the wrong place to get help with a outdated snap package... where can I talk to?
<mborzecki> NerdSnapper: https://github.com/joedborg/youtube-dl is listed in contact-url, i suggest you try opening an issue there
<mup> PR snapcraft#3187 opened: cli: use maxval of UnknownLength for pack progress <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3187>
<mup> PR snapd#8887 closed: bootloader: pull recovery grub config from internal assets <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8887>
<cjp256> I  created a content snap mirroring gnome 3.x platform ones.  it's supposed to share "$SNAP" or "/", like the gnome snap, but when it surfaces inside of the snap, I get the content's snap revision number as the first level directory?  Is that supposed to happen?
<cjp256> (e.g. x4)
<zyga> cjp256: hi, can you show me the plug and slot definition please
<cjp256> https://www.irccloud.com/pastebin/5fABgBQw/
<cjp256> zyga: ^^ thanks for looking :D
<zyga> looking
<zyga> note that in all the cases, / maps to $SNAP, right
<cjp256> I would expect so?  the gnome-platform uses "/"
<zyga> sure, just stating that so it's not unclear
<NerdSnapper> mborzecki: if a snap package (e.g. youtube-dl) is outdated, who provides an update for snap? the original software seems to be actual and working fine, only the snap version is old...?
<mborzecki> NerdSnapper: whoever published the snap
<zyga> cjp256: I think I know what's going on
<zyga> cjp256: in a call, I'll get back to you
<cjp256> zyga: k thanks
<zyga> so, the content interface has two modes of operation
<zyga> 1:1 and 1:n
<NerdSnapper> mborzecki: OK I try to find out...
<mborzecki> NerdSnapper: if you run `snap info <name>` it lists a contact-url for the snap publisher
<zyga> the former uses the target directory and replaces it with the connected content; the latter uses the target directory to enunerate the connected slots
<zyga> the latter mode uses the directory name of the source - if you share the whole snap you will get the revision number
<zyga> if you want to use the 1:1 mode instead please drop the "source" component from the syntax
<cjp256> oh
<zyga> i think this is documented
<zyga> let me know if this aspect is unclear please
<zyga> sergiusens: hi
<NerdSnapper> mborzecki: great thank you, you helped me understand it, that was the contact-url you mentoined... ;)
<zyga> sergiusens: we got a SRU regression on a test that checks snapcraft version to be 3.*
<mup> PR snapd#8891 closed: o/servicestate: add updateSnapstateServices helper (5/9) <Needs Samuele review> <Services âï¸> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8891>
<NerdSnapper> mborzecki: I see I am not the only one with this issue :)  with youtube-dl
<joedborg> NerdSnapper: hi there, i've just checked the snap.  due to a merge conflict from upstream, the automatic builds had stopped and gone unnoticed.  it's now back up and there'll be a new build very soon.
<NerdSnapper> joedborg: thumbs-up great! thank you very much
<cjp256> zyga: makes perfect sense as you explain it.  and it works now! I don't think that's an obvious in the documentation, and it feels like an error case maybe worthy of a snap warning? I'm not sure how the consumer snap would account for a unknown revision tag unless wildcarding?  Docs say source is `presents one or more sub-directories` which is true, but doesn't elaborate on this case as to a potential difference in
<cjp256> behavior for a single shared directory.  Thanks for helping me out!
<sergiusens> zyga: hi, Snapcraft is on version 4 now
<sergiusens> but I guess you know that
<sergiusens> SRU regression where?
<mup> PR snapd#8916 opened: tests: adding ubuntu-20.04 to google-sru backend <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8916>
<zyga> sergiusens: Iâm afk for a moment but I will share the SRU link when I am back
<zyga> By
<NerdSnapper> o/ wishing you all a nice evening...
<jdstrand> ogra: hi! I still have a bbb kicking but lately I've been seeing: snapd[1122]: taskrunner.go:271: [change 1688 "Request device serial" task]
<jdstrand> failed: cannot deliver device serial request: Cannot process serial request for device with brand
<jdstrand> "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" and model "bbb"
<jdstrand> ogra: have you seen this?
<mborzecki> errands, bbl
<ijohnson> jdstrand: that's expected unless you have `serial-authority: [generic]` in your model assertion
<ogra> jdstrand, well, this device doesnt use a canonical model
<ijohnson> jdstrand: or unless you have a brand store for your bbb :-)
<ogra> being core16 i dont think there are ways to make it obtain one
<ogra> (one = serial)
<ogra> core20 allows the new "generic" serial
<ijohnson> ogra: you could try rebuilding that image with a model that uses serial-authority
<ogra> probably time that i dust off my bbb and create a core20 img
<ijohnson> ogra: also serial-authority: [generic] is allowed on any uc model, not just uc20
<ogra> oh, i didnt know that !
<ijohnson> yes it's a generic feature of model assertions now
<jdstrand> ijohnson: ok, well, this is a new, somewhat noisy message
<ogra> i'll play with it ..
<ijohnson> the appliance images which are all uc18 use this
<ijohnson> jdstrand: it shouldn't be new though ...
<jdstrand> newish? I feel like I've only started seeing it in my logs. maybe the message changed and my filter isn't catching it...
<ogra> well, i think snapd used to be quiet about it ... apart from an error in snap changes
<jdstrand> ok, yes, the message changed
<jdstrand> it used to say: cannot deliver device serial request: Cannot process serial request for device with brand "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP", store can sign serial only for brand "canonical"
 * jdstrand updates logcheck
<pedronis> maybe the store error status changed a bit and the effect is different
<pedronis> I would need to check
<pedronis> if the http status code is the same the behavior shouldn't be much different
<ijohnson> cachio: can you explain the purpose or intent of this line in prepare.sh: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L288
<ijohnson> cachio: I keep seeing google-nested:...:tests/nested/classic/ fail to prepare from this line
<ijohnson> and it's unclear to me why we need that line, since we install the core snap below, why does it matter that we didn't have the core snap before we go to install it?
<pedronis> ijohnson: I think mvo added that because we had this images that sometimes have core and sometimes don't
<pedronis> and if core is there you get race errors
<ijohnson> pedronis: no that line is much older
<ijohnson> https://github.com/snapcore/snapd/commit/f45e33a299ebfa08f8bdf53c924d5ece1d46f046
<cachio> ijohnson, it is because we need to make sure that the env is clean
<ijohnson> or rather https://github.com/snapcore/snapd/commit/4ba6181f9b4ea724752f48114a4a263897d4197a actually
<pedronis> ijohnson: ah, it's prepare classic, not core
<ijohnson> cachio: so why don't we instead try to just purge snapd from the system instead of just failing the test if the core snap is there?
<ijohnson> I don't know why the core snap is there but it feels like every run I will get the core snap there
<cachio> ijohnson, so, you face that issue when reuse your system right?
<cachio> or when using a clean env?
<ijohnson> cachio: yes it happens when the system is reused afaict
<ijohnson> err rather after the system was used for a test, restore runs, then the next test prepare runs and fails like this because the core snap is there
<cachio> ijohnson, in this case we need to make something to clean up better when we restore
<cachio> because the idea is to make sure the env is clean
<ijohnson> cachio: ok, I will try something locally to see if it fixes the problem in restore and propose today
<cachio> ijohnson, perhaps just removing snapd is enough
<cachio> remove --purge
<ijohnson> cachio: that is what I was going to try
<cachio> ijohnson, nice, thakns!!
<cachio> ijohnson, just ping me, I'll review it
<cachio> after lunch
<ijohnson> cachio: sounds good
 * cachio lunch
<mborzecki> heh 2020-06-24T13:49:05.9507944Z 2020-06-24 13:49:05 Cannot allocate google:ubuntu-14.04-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: 500 Internal Server Error
<ijohnson> amazing
<zyga> google ran out of ram
<mup> PR snapcraft#3187 closed: cli: use maxval of UnknownLength for pack progress <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3187>
<mup> PR snapd#8916 closed: tests: adding ubuntu-20.04 to google-sru backend <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8916>
<mup> PR snapd#8913 closed: tests/core/snap-auto-mount: try to make the test more robust <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8913>
 * zyga takes a break,
<zyga> tomorrow will be a more productive day
<mup> PR snapd#8835 closed: POC:  skip binary to skip tests in an easy way <Proof of concept> <Skip spread> <â Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8835>
 * cachio -> kinesiologist
<ogra> Lukewh, did our metrics stop working or did my zoom-client snap simply hit a threshold ? the numbers havent changed i a week now
<ogra> *in a week
<mup> PR snapd#8917 opened: osutil/disks: add mock disk and tests for happy path of mock disks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8917>
<mup> PR snapcraft#3188 opened: snap: allow for different compressions for pack <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3188>
<mup> PR snapd#8918 opened: many: make nested spread tests more reliable <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8918>
<mup> PR snapd#8919 opened: gadget/install,secboot: test if the tpm can be provisioned <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8919>
<mup> PR snapcraft#3118 closed: plugins: add support for local v2 plugins (core20) <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3118>
<mup> PR snapd#8920 opened: interfaces: update cups-control and add cups for providing snaps <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
<secretfader> Is there a currently recommended method for self-hosting a snap store?
<secretfader> (I tried searching the forum, but only came back with posts that seem outdated.)
<oerheks> one can publish private snaps on snapcraft.io
<oerheks> but your own  or 'offline' snapstore, no.
<oerheks> one can download snaps and store them, ofcourse
<oerheks> (correct me if i am wrong)
<secretfader> oerheks: Thanks for the insight. That's what I understand as well, but hoped I was wrong. (I'd like to investigate p2p distribution methods, in addition to official server/client techniques.)
#snappy 2020-06-25
<stgraber> secretfader: a combination of private snaps on the public store + https://docs.ubuntu.com/snap-store-proxy/en/ for onsite delivery may be able to do what you want
<oerheks> oh nice
<mborzecki> morning
<mup> PR snapd#8915 closed: gadget: do only one mount point lookup in mounted fs updater <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8915>
<mup> PR snapd#8921 opened: gadget: fix typo in mounted filesystem updater <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8921>
<mup> PR snapd#8921 closed: gadget: fix typo in mounted filesystem updater <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8921>
<mborzecki> yay
<mborzecki> mvo: hey
<mvo> mborzecki: good morning
<mup> PR snapd#8911 closed: asserts,seed: split handling of essential/not essential model snaps <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8911>
<mvo> zyga: can I help with 8881 ? looks super close, just reading the reamaining comments
<zyga> Good morning. Let me try finishing it. I think today will be smoother than yesterday
<mborzecki> zyga: heya
<zyga> Hey :-)
<mvo> ok
<pstolowski> morning
<mborzecki> pstolowski:  hey
<mborzecki> anyone investigated the random failure in unit tests related to GPG?
<zyga> not yet
<zyga> settling in for work
<pedronis> mborzecki: not yet
<pedronis> mborzecki: can you explain why you think chasing the dm hiearchy is simpler? it sounds like more code, am I wrong?
<mborzecki> pedronis: yes, it may be a bit more code, but upside is the information is coming directly from device hierarchy rather than from a specially formatted name
<mborzecki> pedronis: otoh the name format will remain stable throughout the release as udev/systemd versions are frozen effectively
<pedronis> mborzecki: less code is more compelling at this point to me, also because is not clear that slaves couldn't have many entries?
<mborzecki> pedronis: it should be one for simple lvm/luks, i can find out about other scenarios
<pedronis> mborzecki: it's ok, just pointing out that the error cases will also grow
<mborzecki> pedronis: anyways, not a strong opinion, thought it may be worth considering given how easy it is to chase down the device with shell
<mup> PR snapd#8922 opened: tests: fix incorrect check in smoke/remove test <Simple ð> <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8922>
<mborzecki> it's supper annyoing how google meet is hiding the bootom bar with the (un)mute/hangup buttons each time the window goes out of focus
<mborzecki> obviously accompanied by an animation of the bar rolling up and down
<zyga> heh, yes
<mup> PR snapd#8922 closed: tests: fix incorrect check in smoke/remove test <Simple ð> <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8922>
<zyga> pedronis: left a small question on the assertion sequence PR: https://github.com/snapcore/snapd/pull/8906/files#r445405988
<mup> PR #8906: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
<pedronis> zyga: I tried to answer
<zyga> thanks, that makes sense
<mborzecki> meh another random test failure https://paste.ubuntu.com/p/Y5G6hx4QG7/
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8881/files#r445419656 it's missing a } in the template list
<mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<zyga> oh,
<zyga> looking
<mborzecki> zyga: `AddParametricSnippet([]{"/dev/", "rw," <<<hgere>>>, "sda1")`
<mborzecki> zyga: and probably []string too
<zyga> ah
<zyga> I se
<zyga> fixed
<mborzecki> zyga: thx :)
<zyga> I fixed string as well, just didn't push again
<mvo> zyga: what's the state of 7700 ?
<mvo> zyga: should this be reviewed by pedronis ?
<zyga> looking
<zyga> yes, it needs review to establish direction
<mvo> zyga: preping for vMontreal I was wondering if we can try a push for refresh awareness again :)
<mvo> zyga: cool, I add the tag
<zyga> thanks
<mvo> zyga: do you have an order in which these should be reviewed?
<mvo> zyga: is 7700 the first one we should look at?
<zyga> mvo: no, there are two PRs now, that are critical
<zyga> this and ...
<zyga> https://github.com/snapcore/snapd/pull/8573
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<zyga> though that one was already reviewed and I need to expand it a littie
<zyga> *little
<zyga> mvo: it was reviewed already :)
<mvo> zyga: ok, let's try to move this a bit forward before vMontreal
<zyga> apart from that there is https://github.com/snapcore/snapd/pull/8829
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<zyga> that needs a 2nd review and I think is ready to land
<mvo> zyga: I do the second review
<mvo> zyga: after my current meeting
<zyga> and after 8829 lands I can shring https://github.com/snapcore/snapd/pull/7825 once again, it will be closer to something that is reviewable then
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> thank you!
<zyga> mvo: then there is https://github.com/snapcore/snapd/pull/8863
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<zyga> which is the lsat of the group I have now
<zyga> it needs two reviews and I also think it is ready
<zyga> those two should shrink the main backend PR by quite a bit, perhaps enough for it to be mostly just tests
<zyga> there's one more PR that can be broken out but I'm blocked by those two helpers landing first
<zyga> man github is slow on large pages :/
<zyga> I mean, my laptop is slow
<zyga> I want to be healthy again and use my normal work stuff
<zyga> hrm
<zyga> go language server is swapping on my system
<zyga> disabled go support in code, it's useless at this stage
<zyga> mvo: I think https://github.com/snapcore/snapd/pull/8881 is ready now
<mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<zyga> mvo: I'm open to changing the API again to make it even harder to use incorrectly but I don't consider it blocked anymore
 * zyga small break to change the workspace
<mup> PR snapd#8905 closed: bootloader: introduce managed bootloader, implement for grub <Simple ð> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8905>
<mborzecki> finally landed, took a bunch of restarts
<mborzecki> now which part should i open next
<jamesh> mvo: for what it is worth, I think some of the font cache differences come from all the static versions of fc-cache versions being linked against xenial's freetype
<mvo> jamesh: thanks, that is good to know, so if we fix that and build with the right freetype it should be better?
<jamesh> hopefully.  I think this is the cause of color emoji compatibility at least
<jamesh> mvo: I think the private fontconfig cache is probably the best bet going forward though
<mvo> jamesh: yeah, I would *love* to remove this from snapd and move it into the snaps
<zyga> ls
<zyga> ps
<zyga> id
<zyga> o/
<mvo> bash: o/: No such file or directory
<zyga> trying to work from the office
<zyga> will see how it goes
<zyga> maybe an hour or two a day
<seb128> jamesh, mvo, should bug #1858636 be assigned to someone from the snapd team again in regard of the recent findings? ijohnson was assigned but unassigned himself
<mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Invalid> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1858636>
<mup> PR snapd#8923 opened: wrappers: helper for enabling services (8/9) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8923>
<mup> PR snapd#8924 opened: gadget, bootloader: preserve managed boot assets during gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8924>
<zyga> mborzecki: hi
<zyga> question about managed boot assets PR
<mborzecki> zyga: hm?
<zyga> should BootAssets return nil if IsCurrentlyManaged returns false?
<zyga> I know the usage below is correct
<zyga> just asking conceptually
<mborzecki> zyga: no, i'm not sure it's needed, i actually thought about making it part of the Bootloader interface even
<mborzecki> zyga: iow, it answers the question as to where inside the tree can the bootloader assets be located, IsCurrentlyManaged() indicates whether those are really managed
<pstolowski> zyga: updated #8914 per your suggestions, thanks
<mup> PR #8914: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8914>
<zyga> pstolowski: looking
 * pstolowski lunch
<zyga> pstolowski: one more question there
<zyga> in the beginning of the diff
<zyga> is there any risk that "old" stores more than the undesired flag?
<zyga> perhaps we should do something like task.Set("old-conn", ConnectionState{Undesired: old.Undesired})
<zyga> (I forgot the type names so forgive me for making the name up
<zyga> pstolowski: not sure if you see what I'm worried about
 * zyga breaks to wait for meds to help 
<zyga> please review https://github.com/snapcore/snapd/pull/8881
<mup> PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<mborzecki> it'd be nic to have auto cancel of runs when a PR gets updated
<mborzecki> s/nic/nice/
<mup> PR snapd#8925 opened: bootloader: allow managed bootloader to update its boot config <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8925>
<pstolowski> re
 * zyga feels better
<pstolowski> zyga: great to hear that!
<zyga> temporary but yeah
<pstolowski> ijohnson: hey, can you take a look at #8899 (i think you assigned it to yourself anyway)?
<mup> PR #8899: tests: add servicestate.Control tests (7/9) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8899>
<ijohnson> Hey pstolowski yes it's in my queue, I started yesterday but got distracted; should finish this morning
<pstolowski> ijohnson: sure, thanks
<zyga> ijohnson: about ram, try the code snap and open snapd there
<zyga> install the go extension it recommends
<zyga> and observe ram usage
<zyga> the official go language server immediately eats 4+GB
<zyga> after indexing snapd
<ijohnson> zyga: I did, I filed an issue about strict and classic snaps being confused about each other, so I don't use the code snap any more :-/
<zyga> I had to close the editor to join the hangout
<ijohnson> cause the code snap can't use the go snap
<zyga> I see
<zyga> I think it's pretty nice overall (code itself)
<ijohnson> but I do remember trying the language server and it has some weirdness I don't remember so I turned it off
<ijohnson> but I'm quite happy with vs code, I would love to use the snap when we can fix that bug
<zyga> yeah but the features are really great
<ijohnson> have you used the remote sharing feature yet?
<zyga> no?
<pedronis> pstolowski: I don't think I need to review that tests PR
<ijohnson> it's quite nice actually, we used it a bit at the virtual snapcraft summit
<ijohnson> ah live share is the name of it
<ijohnson> https://code.visualstudio.com/blogs/2017/11/15/live-share
<zyga> is it like something that atom had a while ago
<pstolowski> pedronis: ok, i thought so, thanks
<zyga> where >1 people can code in one workspace
<zyga> really nice
<zyga> we should try that
<ijohnson> zyga: yeah sounds like it, I've never used atom though
<zyga> maybe next week?
<ijohnson> yeah we could try doing some kind of pair coding session I know we talked about trying that out all the way back in paris iirc haha
<zyga> yeah
<roadmr> we'll always have paris ð
 * zyga makes coffee
<mup> PR snapd#8881 closed: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8881>
<mborzecki> when snap run runs a hook (as root ofc), should we really try to create /roon/snap/<name>/<rev> ?
<mborzecki> we don't expect hooks to try to manipulate home
<pstolowski> mborzecki: probably not. this happens in snap-run?
<mborzecki> pstolowski: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1884929
<mup> Bug #1884929: snap creates (or tries to create) a direcotry in /root/snap/ <amd64> <apport-bug> <focal> <package-from-proposed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1884929>
<mborzecki> it's running a configure hook
<mborzecki> hmm, there's a bunch of things that happen but maybe shouldn't be when we run --hook, it's creating $HOME/snap, migrating Xauthority and activating a document portal
<pedronis> mborzecki: it probably makes sense to do only a subset of that for hooks
<pstolowski> mborzecki: not sure about $HOME/snap (maybe it should be crated), it's also related to what is exposed via SNAP_* env vars
<mborzecki> pstolowski: still the hook runs as root, not sure why there would bea need to store anything inside /root instead of /var/snap/
<pstolowski> mborzecki: they shouldn't, worried about silly hooks though
<mup> PR snapd#8926 opened: Add microstack-support interface <Created by dshcherb> <https://github.com/snapcore/snapd/pull/8926>
<pstolowski> oh, i think undo of snap connect has yet another bug /o\, it doesn't restore security profiles. it's only a problem with undo of individual snap connect, and not when run as part of a install/refresh change
<pstolowski> i wonder how/when did this sneak it. probably at the time undo handlers were re-arranged
<mup> PR snapd#8927 opened: tests: avoid exit 1 when nested type var is not defined <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8927>
 * cachio lunch
<pedronis> ijohnson: I think we should try to land #8683 with the current approach, https://github.com/snapcore/snapd/pull/8683#discussion_r445635143
<mup> PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
<ijohnson> pedronis: ok, I have not yet had a chance to explore mborzecki's recommendation but it seems that it would be more code
<pedronis> ijohnson: I mean, if we are really paranoid about udev then we shouldn't use udevadm at all, but I don't think we are there yet
<ijohnson> sure, I mean the udev that's there right now seems to be good enough, so I'm fine to keep using it until we have reason to want to rip it out
<pedronis> yes
<zyga> mvo: thank you for merging 8881
<zyga> mvo: I will open some follow-ups for it
<mvo> zyga: sounds good
<pedronis> pstolowski: I reviewed #8914, lgtm
<mup> PR #8914: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8914>
<pstolowski> pedronis: ty
<pedronis> pstolowski: you said there's more to fix though?
<pstolowski> pedronis: yes, i'm afraid so, but it can be a followup. we're missing m.setupSecurityProfiles on undo
<pedronis> pstolowski: only if it's not an auto-connect one?
<pedronis> I mean only if we did setup profiles
<pedronis> right?
<pstolowski> pedronis: doConnect sets up security profiles (unless delayed-setup-profiles is set). but undo doesn't do this at all. this affects manual 'snap connect ..' if you have a hook that fails after connect
<pedronis> pstolowski: I mean it matters only if !delayedSetupProfiles or what should happen in that case?
<pstolowski> pedronis: we should do repo.Disconnect and then m.setupSnapSecurity like we do on connect,
<pedronis> only if !delayedSetupProfiles ?
<pstolowski> pedronis: yes
<pedronis> ok, thx
<pstolowski> pedronis: for delayedSP==true it's a different case (refresh, instal) where everything is undone and initial setup-profiles should do the right thing
<pstolowski> pedronis: btw, with a disconnect hook that fails it is impossible (not really a surprise) to uninstall affected snap
<pstolowski> a flag for such cases would be handy
<pstolowski> it could set IgnoreError=true on all hooks
<zyga> pstolowski: snap remove --force
<zyga> ?
<pstolowski> yep
<zyga> mvo: any chance for a review of https://github.com/snapcore/snapd/pull/8829
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<zyga> mborzecki: not sure if you have time today but a look at https://github.com/snapcore/snapd/pull/8863 would be great
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<zyga> with those two I can make progress on r-a-a
<mvo> zyga: having fun with freetype now, but let me try
<zyga> mvo: it's not much code, just a pair of functions
<ijohnson> zyga: I will try to review that in my PM if mvo does not finish
<zyga> thank you so much!
<ijohnson> zyga: I've been waiting for nested spread runs to finish, so it's easy for me to do reviews while waiting for results :-)
<zyga> :)
<ijohnson> cachio: so I finally got around to try and reproduce your uc20-recovery test and it finished fine for me, I ran it with `spread --debug -v google:ubuntu-core-20-64:tests/core/uc20-recovery`, is that the right test you said was failing ?
<pedronis> cmatsuoka: I looked at #8824
<mup> PR #8824: many: move encryption and installer from snap-boostrap to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
<cmatsuoka> pedronis: thanks, I'll check
<mup> PR snapd#8914 closed: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8914>
<ish> Is there a way for a user to alter the layout after installing a snap? For example, the app I'm snapping produces datafiles as output.  Our classic install dumps this data /var/log/<app_name>..  Could they redirect it there if they choose to? By default it happily logs to a confined space I've mapped with a layout.
<zyga> ish: users cannot alter the layout
<ish> Ok.  Thats what I thought.  Was hoping for some command that I couldn't find to "connect" directories together.
<mvo> zyga: fwiw, I pushed https://github.com/snapcore/fc-cache-static-builder/pull/2 - will have dinner now so let's hope ijohnson  can review, otherwise I do it in my morning
<mup> PR fc-cache-static-builder#2: build freetype from the security pocket too <Created by mvo5> <https://github.com/snapcore/fc-cache-static-builder/pull/2>
<zyga> mvo: ack
<zyga> uh, 5% battery left
<zyga> brb
<zyga> plugged in
<zyga> hmm
<zyga> Variable NESTED_TYPE not defined. Exiting...
<zyga> on tests/main/lxd-no-fuse on 18.04
<zyga> ah
 * zyga fixed the problem
<cachio> zyga, there is a PR for that
<zyga> yeah, I know, different problem
<cachio> zyga, nice
<zyga> it was just a message that confused me
<zyga> cachio: updated https://github.com/snapcore/snapd/pull/8728
<mup> PR #8728: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8728>
<cachio> ijohnson, yes
<cachio> ijohnson, but it is not failing in google
<ijohnson> cachio: do you think I should just run that test in a loop ?
<cachio> it fails with edge image
<cachio> using external backedn
<ijohnson> cachio: ah right now you said it was with external
<ijohnson> cachio: ok, can you remind me which external image I need to use?
 * zyga returns to bed
<cachio> ijohnson, yes, 1 sec
<zyga> (it was great to work from office again today)
<ijohnson> zyga: glad to hear you are feeling better today :-)
<cachio> zyga, happy to hear that
<zyga> little by little :)
<cachio> ijohnson, https://storage.googleapis.com/spread-snapd-tests/images/pc-amd64-20-edge-snapd_edge/pc.img.xz
<cachio> ijohnson, I am testing now the beta image
<ijohnson> cachio: thanks, so I just run that via qemu on my local machine, then how do I point spread to use that as the external image ?
<ijohnson> err external backend
<ijohnson> do I need to change some IP address or set some env var ?
<cachio> ijohnson, then you do
<cachio> export SPREAD_EXTERNAL_ADDRESS=localhost:8022
<cachio> ./tests/lib/external/prepare-ssh.sh localhost 8022 sergio-j-cazzolato
<cachio> with you lp id
<cachio> ijohnson, and  spread -debug external:ubuntu-core-20-64:tests/core/uc20-recovery
<cachio> that should be enough
<ijohnson> cachio: ack will give it a try
<cachio> ijohnson|lunch, tx
<mup> PR snapd#8824 closed: many: move encryption and installer from snap-boostrap to gadget <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
<sdhd-sascha> hey, zyga, not sure you are there... but is the merge of master ok. (just for speed...) Or should i look for an error? I'm just past the age of 40' ;-) ... maybe i'm different, ...
<sdhd-sascha> i didnt like to make error... but i can't denied it...
<ijohnson> sdhd-sascha: hi, which PR are you referring to? it's almost always ok to merge master into your branch
<sdhd-sascha> hey, ijohnson ... i love, to rename "master" to something... ;-) I'm not bad at you ;-) All okay...
<ijohnson> sdhd-sascha: ah are you asking about if github.com/snapcore/snapd will rename it's "main" branch from master to something else ?
<sdhd-sascha> it's sun down here...
<sdhd-sascha> very nice...
<sdhd-sascha> i listen some techonicic sound
<sdhd-sascha> i'm good, and fine...
<sdhd-sascha> maybe, i look for my wife, what she do...
<sdhd-sascha> Hey, ijohnson, Is not an PR. Or, did you need an Graph Algo, for GO ?
<sdhd-sascha> At all ;) I hate programmer who analye text, and do the same reverse...
<ijohnson> sdhd-sascha: sorry I don't quite follow your question? is there something you need help with ?
<sdhd-sascha> ijohnson: no, no, but i give you great respect, for your development in this divicult times...
<ijohnson> thanks
<sdhd-sascha> :-)
<sdhd-sascha> ijohnson: i think think you have more knowleghe, then i.... but is it okay, to say, no?
<ijohnson> sdhd-sascha: no worries
<ijohnson> cachio: yeah so I can reproduce the issue you were seeing, I think I understand the problem
<sdhd-sascha> hey, you. ijohnson and cachio ;-) thank you
<sdhd-sascha> can i send, what i want before:
<sdhd-sascha> hey, zyga.. don't matter i respect you all. i know, that you all maybe know more formulas and grammer then i... but i stil believe, that i can scane a graph in a way, wich should to follow a goal
<ijohnson> cachio: the issue is that with the google backend, when we boot uc20, it has that special tweak service unit to copy files into place, but we don't have such a thing for the external backend, and by default recover mode does not copy all the user data from the run mode ubuntu-data to the ephemeral ubuntu-data in recover mode
<ijohnson> cachio: I need to look but I think I can propose a fix for this
<sdhd-sascha> hmm
<sdhd-sascha> ijohnson: today, i'm in flaw with my wife (lucky, that she sleep... but i love her... damn....)... okay, where should i start? I still have PR to ubuntu-image. But not the access to google...
<sdhd-sascha> cachio: you, have my respect. Because you, like you said... Love Graph's ...
<sdhd-sascha> hey, i need to go
<sdhd-sascha> is it okay, for you?
<sdhd-sascha> https://www.irccloud.com/pastebin/2OcYYwcr/
<cachio> sdhd-sascha, sure, thanks
<cachio> ijohnson, ood news
<sdhd-sascha> ?
<cachio> ijohnson, which is the problem?
<ijohnson> cachio: the issue is that in google with uc20, /home/gopath is copied by the special snapd snap we use in the image, the snapd snap in the external backend image you showed me does not have that special snapd
<cachio> ijohnson, ah, right
<cachio> well snapd snap in external is not modified like we do in google
<ijohnson> cachio: I'm looking at ways we could abuse the system to make it copy this data from the host ubuntu-data to tmpfs
<ijohnson> cachio: exactly
<sdhd-sascha> heym cachio yi want o talk to o  you... but my moude didnt. You are a badhttps://www.irccloud.com/?/pastebins
<sdhd-sascha> he is bad
<sdhd-sascha> sorry, he was nice to me.... but  hd was hard to me...
<cachio> sdhd-sascha, sorry, do you need any help?
<sdhd-sascha> No, why should i ly?
<ijohnson> cachio: is there an env var for what user spread is running as on the target system, should I just use $USER ?
<cachio> SPREAD_BACKEND external
<sdhd-sascha> cachio: did you know the-mentor9011 big bugs. )seven centimer) are found here... I don't know whagt todo.. (IF TH4Y TO NOTHING, ok .. but else... then i love family.. _ OR?
<cachio> ijohnson, we use that
<ijohnson> thanks cachio
<sdhd-sascha> :-)
<sdhd-sascha> ijohnson: it's okay ;-9 since brexit i want another way ;-)
<mup> PR snapcraft#3188 closed: snap: allow for different compressions for pack <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3188>
<mup> PR snapcraft#3189 opened: Snap compression <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3189>
<ijohnson> cachio: have you ever seen a failure like this:
<ijohnson> https://www.irccloud.com/pastebin/pL4KWHcb/
<ijohnson> the external VM was alive and working fine, I could ssh to it, so I'm not sure what the issue is with that
<ijohnson> cachio: I'll retry it again, but if I could get past that I have fixed the test I think, at least I resolved the issue with not copying the gopath to recover mode
<cachio> ijohnson, no, first time+
<ijohnson> cachio: ack I will try again with -vv maybe I can see where it got stuck
<mup> PR snapcraft#3189 closed: Snap compression <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3189>
 * cachio afk
#snappy 2020-06-26
<mup> PR snapd#8927 closed: tests: avoid exit 1 when nested type var is not defined <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8927>
<mup> PR snapd#8748 closed: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 <Created by jhenstridge> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8748>
<jamesh> ijohnson: thanks!
<ijohnson> jamesh: np
<mborzecki> morning
<zyga> Hey
<zyga> Iâll start at nine
<mborzecki> zyga: heya, last day of 'school'
<zyga> Yes. Kids are very happy
<zyga> Too bad the circumstances are not better
<mvo> hey zyga and mborzecki
<zyga> Hey
<zyga> The
<seb128> hey mvo, thx for the fontconfig and freetype fix ... do you have any hint on the easiest way to test the change?
<zyga> Took meds now
<zyga> Will be able to work in 30
<mvo> seb128: I can build a custom snapd snap for trying it out, will take some minutes
<seb128> mvo, that would be nice if you could, I'm happy to give it a try today
<mvo> seb128: sure, building now and once done will ping you
<seb128> thx
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> pstolowski: heya
<mborzecki> need coffee
 * zyga starts with reviews
<zyga> mborzecki: btw, for evening reading: https://lwn.net/Articles/824380/
<zyga> oh and https://github.com/snapcore/snapd/pull/8728 is a low hanging fruit
<mup> PR #8728: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8728>
<mborzecki> zyga: oh, nice
<mup> PR snapd#8928 opened: tests: add spread test for disconnect undo caused by failing disconnect hook <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8928>
<pstolowski> zyga: ^ something easy for a warmup ;)
<jamesh> zyga: if you've got time, could you give this a review? https://github.com/snapcore/snapd/pull/8861
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<zyga> jamesh: I'll do my best to help
<jamesh> zyga: thanks.  You gave it a once over earlier, and now I just need a second sign off
<zyga> jamesh: ah, I really like how github shows what I reviewed
<zyga> and shows only changes
<pstolowski> zyga: nb, snap remove --force needs ack from Samuele
<zyga> sure
<zyga> I was thinking if it makes sense to fail on interface hooks when removing a snap
<pstolowski> zyga: indeed
<mvo> seb128: sorry, took a while, had some unclean checkout and a bug in the cleanup: https://people.canonical.com/~mvo/tmp/snapd_2.45.1+git1648.gf492c71_amd64.snap is the test snaps
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8925#pullrequestreview-438094666
<mup> PR #8925: bootloader: allow managed bootloader to update its boot config <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8925>
<zyga> brb
<mborzecki> zyga: thx
<mborzecki> mvo: can you cherry pick https://github.com/snapcore/snapd/commit/3192141bc8481f58639e71a099b17a608366b7a0#diff-ccde24f4fb0b0adce138f9b26cea79ed to 2.45 in case we do another point release?
<mvo> mborzecki: sure thing
<mborzecki> mvo: thanks
<mvo> mborzecki: thanks, done
<mborzecki> yay
<mvo> mborzecki: nice one!
<zyga> mborzecki: what does NoSlashBoot do?
<mborzecki> zyga:  haha, so it means you're lookin at the root of the boot fs
<zyga> hmm?
<mborzecki> zyga: instead of the actual rootfs where you'd normally find /boot/..
<zyga> so /foo/bar/froz becomes just /?
<mborzecki> iow no /boot
 * zyga looks at the source
<mborzecki> zyga: not necessarily, we ahve /boot/grub/.. which is a bind mount of /EFI/ubuntu from system-boot iirc
<seb128> mvo, thx, I will give a try a bit later and let you know if it improves things
<mvo> seb128: thanks
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8924#pullrequestreview-438131587
<mup> PR #8924: gadget, bootloader: preserve managed boot assets during gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8924>
<zyga> more reviews
<zyga> thank you for looking at the tracking PR
<zyga> I will iterate on it soon
<mborzecki> zyga: thanks for the reviews too
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8923#pullrequestreview-438156283
<mup> PR #8923: wrappers: helper for enabling services (8/9) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8923>
<zyga> jdstrand: is https://github.com/snapcore/snapd/pull/8920 something that I should review now or is it better to wait for the final form?
<mup> PR #8920: interfaces: update cups-control and add cups for providing snaps <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
<zyga> jdstrand: also note that opening a draft vs a blocked PR is probably more idiomatic for GH
<pstolowski> zyga: thanks!
<mup> PR snapd#8929 opened: [RFC] many: add new "daemon-startup: inhibit" option <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8929>
<zyga> mvo: ^ quick comment
<mvo> zyga: thanks, interessting idea
<zyga> mvo: it doesn't have to be complex
<zyga> perhaps just
<zyga> startup-presets: default: app-name: disabled
<zyga> if you catch my "language"
<zyga> default would be the only supported value now
<zyga> presets are somewhat different, as they come from the distro
<zyga> but we could convey the same idea
<zyga> e.g. apache is not started automatically
<zyga> but the server preset makes that so
<zyga> while desktop does not
<zyga> (just a made up example)
<zyga> perhaps an app could even have a snapctl level influence over the preset to use
<zyga> anyway, just an idea
<zyga> https://www.freedesktop.org/software/systemd/man/systemd.preset.html has some docs about tihs
<zyga> *this
<pstolowski> #8928 needs 2nd review and is a low hanging ð
<mup> PR #8928: tests: add spread test for disconnect undo caused by failing disconnect hook <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8928>
<zyga> pstolowski: I see what you did there :D
<mup> PR snapd#8930 opened: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
<pstolowski> :)
<mvo> zyga: yeah, the idea of having hooks that would enable/disable under certain conditions is part of the idea for this
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8918#pullrequestreview-438161318
<mup> PR #8918: many: make nested spread tests more reliable <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8918>
<zyga> review days are good
<zyga> ok, only dbus to review
<zyga> and then back to iteration
<zyga> or maybe small lunch break and then iteratoin
<zyga> *iteration
<mup> PR snapd#8931 opened: tests/main/install-fontconfig-cache-gen: enhance test by verifying, add fonts to test <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8931>
<zyga> jamesh: https://github.com/snapcore/snapd/pull/8861#pullrequestreview-438214407
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<zyga> cc mvo ^
<zyga> not +1, not sure what to do about this
<zyga> I think we need to revisit our reexecution strategy with regards to how it should be structured internally
<zyga> what's okay and not and if we need any belts and suspenders to make it sane over time
<zyga> 9% of battery, time for a trip downstairs for the charger
<zyga> oh boy
<jdstrand> zyga: probably best to wait for cups-control. I wasn't expected it to be blocked for so long but I got pulled away. if you're looking to review things, I suggest https://github.com/snapcore/snapd/pull/8699 and https://github.com/snapcore/snapd/pull/8301
<mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs Samuele review> <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
<mup> PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>
<jdstrand> expecting*
<zyga> jdstrand: ack, thanks!
<jdstrand> but I am getting back to cups-control today (want to right a spread test)
<zyga> I'll do both, just need to charge
<jdstrand> thanks!
<zyga> in the office
<zyga> stairs feel wobbly
<zyga> https://github.com/snapcore/snapd/pull/8728 needs a 2nd review\
<mup> PR #8728: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8728>
 * zyga takes a break to rest
<mup> PR snapd#8932 opened: Update security profiles after disconnecting plug-slot in connect undâ¦ <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8932>
<mup> PR snapd#8933 opened: tests/core/uc20-recovery: apply hack to get gopath in recover mode w/ external backend <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8933>
<mborzecki> cachio: downloaded the image, trying now
<cachio> mborzecki, tx
<zyga> I will resume work in 30 minutes
<zyga> the schedule for painkillers is somewhat annoying
<zyga> btw, typing on the faceless keyboard is really much easier than I anticipated; I think the only thing I stil struggle with are arrow keys
<mborzecki> cachio: in what scenarios does the test fail?
<cachio> so
<cachio> just need to run the test like this
<cachio> first prepare ssh
<cachio> ./tests/lib/external/prepare-ssh.sh localhost 8022 sergio-j-cazzolato
<cachio> with your lp id
<cachio> export SPREAD_EXTERNAL_ADDRESS=localhost:8022
<cachio> and run spread -debug external:ubuntu-core-20-64:tests/core/snap-set-core-config
<cachio> mborzecki, to start the vm I do
<cachio> sudo qemu-system-x86_64 -smp 2 -m 2048 -snapshot -net nic,model=virtio -net user,hostfwd=tcp::8022-:22 -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive  file=~/workspace/validator/images/output/pc-amd64-20-edge/pc.img,cache=none,format=raw,id=disk1,if=none -device virtio-blk-pci,drive=disk1,bootindex=1 -machine accel=kvm
<mborzecki> cachio: hmm, i've built a pc20 image and the test would fail there too from what i can see
<mborzecki> wonder why it does not fail when we run it on gce
<cachio> mborzecki, that's my concern
<cachio> not sure where the difference is
<mup> PR snapd#8728 closed: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8728>
<cachio> I didn't see any special config for console conf in the code
<ijohnson> cachio: what's the test that doesn't work ?
<ijohnson> sorry I had to drop from SU before you could share details
<cachio> ijohnson, snap-set-core-config
<ijohnson> I'm all setup to run external spread tests easily now though :-)
<ijohnson> cachio: ack I will give it a try right now
<ijohnson> cachio: same pc.img.xz as yesterday ?
<cachio> yes
<ijohnson> cachio: much like the other test, if this is being run with an external backend, it functions differently
<ijohnson> cachio: the issue is that this test tries to re-enable console-conf after disabling it, but that only works if console-conf was never run manually by the user
<mborzecki> heh, 2nd thunderstorm today
<ijohnson> cachio: in our case, we manually run console-conf in order to be able to create the test / ubuntu users
<mborzecki> hah
<ijohnson> cachio: which means that snapd does the right thing and when we unset the system config, snapd doesn't undo console-conf disabling itself
<ijohnson> cachio: the test needs to be adjust to special case external backend, I will prep a PR for oyu
<mborzecki> ijohnson: thanks for investigating!
<cachio> ijohnson, thanks
<cachio> ijohnson, everything is realted to all the magic we did to prepare snapd to be executed on google
<mup> PR snapd#8934 opened: overlord: mock timings.DurationThreshold in TestNewWithGoodState <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8934>
 * zyga finally had lunch and meds and can get back to work :)
<ijohnson> cachio: yes essentially all these bugs are related to the magic we do for snapd + UC on google
<zyga> ijohnson: o/
<ijohnson> hey zyga
<zyga> ah, you're around - great
<zyga> I'll push tweaks to comments in 8829 in a moment, wanted to ask if you could look at my explanations there
<zyga> I'll let you know when they are up
<ijohnson> zyga: yes I'll take a look just let me know when they're up
<zyga> thank you
 * cachio lunch
<zyga> ijohnson: pushed https://github.com/snapcore/snapd/pull/8829
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<zyga> it's broken down in commits so you can see it more easily
<zyga> https://github.com/snapcore/snapd/pull/8829/commits/6430d396deb9ad5daaced3b119b9bb1d64b413a9
<zyga> https://github.com/snapcore/snapd/pull/8829/commits/d20c0bfb6d48ce1cd650229c8d8b718ae9fe8640
<zyga> https://github.com/snapcore/snapd/pull/8829/commits/89d8a1a34426dfc94adc33147c186a2a9caa5f0a
<zyga> https://github.com/snapcore/snapd/pull/8829/commits/105748396066ddd45c455b177f6accad5e670871
<zyga> that's all
<zyga> if you have cycles today I'd love a review of the counterpart https://github.com/snapcore/snapd/pull/8863
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<ijohnson> zyga: thanks, one small comment then LGTM
<ijohnson> zyga: I'll take a look at the other one today too
<ijohnson> xnox: what is the canonical way to know if console-conf ran? I thought it was the presence of the /var/lib/console-conf/complete file, but it doesn't appear that file is ever written by console-conf itself ? that file simply seems to be used to _disable_ console-conf, not to tell whether console-conf ran or not
<zyga> ijohnson: applied now
<xnox> ijohnson: pass. I am not sure if it is possible to tell if it ran, or did anything, or if it's state was cleared, or like who/what created the managed user....
<ijohnson> xnox: I'm wondering about for our tests in snapd about disable console-conf
<ijohnson> xnox: we can hack some things into place, but our test was checking for that file, but it seems that file is not actually created when we expected it to be
<pstolowski> ijohnson: hey, would you take a look at #8928? it's test only PR
<mup> PR #8928: tests: add spread test for disconnect undo caused by failing disconnect hook <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8928>
<ijohnson> xnox: if there's not an "official way" that's fine I can replace it with a working hack to see that the test is checking the right thing
<ijohnson> pstolowski: sure, will be my afternoon though at this point
<pstolowski> thanks!
<xnox> ijohnson: maybe something is buggy? It should be leaving that stamp file at the end... When ran successfully. At least that's what I thought.
<mvo> seb128: did my updated snapd snap help with the fc-cache issue? no rush, just curious if I can update anything in the PR
<ijohnson> xnox: it doesn't leave a stamp file on uc20 or uc18 afaict
<ijohnson> xnox: shall I file a bug ?
<ijohnson> zyga: thanks for adding that Error(), I'll keep an eye on the PR and merge it for you tonight
<seb128> mvo, ah, sorry, I meant to comment, I just tested half an hour ago, I wiped the cache, installed your snap and the font was correctly listed in the newly generated cache, so seems to work from that testing
<zyga> thanks
<mvo> seb128: \o/ yay
<zyga> once it lands I need to merge it back into to big helper
<seb128> mvo, thanks for the quick fix :)
<mvo> seb128: my pleasure, thanks for all your help with this! (and to jamesh)
<ijohnson> mvo: regarding that bug, how will the spread tests get the fix for that? do we build the fc-cache helpers in the snapd deb the way we do for the snapd snap? just wondering how we could properly fix my spread test showing that it works
<seb128> mvo, I've added a comment on the bug and the pr now
<ijohnson> cachio: do you have time today to verify #8933 ?
<mup> PR #8933: tests/core/uc20-recovery: apply hack to get gopath in recover mode w/ external backend <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8933>
<mvo> ijohnson: I think we just merge the fix into edge, rebuild the snap and then re-run your test (that now no longer needed to rebuild the snapd snap). it's not as nice as you test but we can always revert again if needed
<mvo> ijohnson: sorry, it's very low-tech, a real friday evening suggestion :)
<ijohnson> mvo: so the test will use the snapd snap ?
<ijohnson> mvo: that's fine, just wondering since it's a little annoying in the test to have to revert from the snapd snap to the deb, certainly doable though I think
<mvo> ijohnson: yeah, once fc-cache-builder is in git and the snapd snap is rebuild we should have the right version
<ijohnson> mvo: ah actually all the font tests are run on classic, so it's not a problem, the magic spread restore should take care of it
<ijohnson> nvm me, thanks mvo
<mvo> ijohnson: aha, ok
<mvo> ijohnson: sorry, I think I was not even grasping the depth of the question :)
<mvo> ijohnson: but happy to help!
<ijohnson> mvo: haha no worries it's probably EOW time for you anyways :-)
<mvo> ijohnson: it is - plus it's hot here :)
<ijohnson> yah I hear that
 * mvo is good at making excuses
 * mvo will just write one or two more mails and then call it a day
<ijohnson> xnox: seems that /run/console-conf/login-details* is the best indicator if console-conf ran successfully / normally on the system
<xnox> ijohnson: but that could also be generated if the system got provisioned elsehow too I think
<ijohnson> xnox: I don't see it, I tried both with cloud-init and with system user assertions and don't see that dir
<xnox> Interesting.
<ijohnson> xnox: maybe I checked in bad ways
<xnox> And after reboot it's still there?
<ijohnson> xnox: but I can make my test pass now, so that's all that's important :-)
<ijohnson> xnox: afaict yes
<xnox> Cool. Roll with it.
<xnox> Next time I touch consoleconf I will try to understand how it works.
<ijohnson> haha sounds good
<cachio> ijohnson, sure
<cachio> ijohnson, https://paste.ubuntu.com/p/RvVKN4978X/
<cachio> https://paste.ubuntu.com/p/JfCz4D3Rfz/
<ijohnson> cachio: very interesting, was this when the system was in recover mode or run mode ?
<cachio> https://paste.ubuntu.com/p/hsNtwZNYsw/
<cachio> no space error
<ijohnson> cachio: ah I see that is in recover mode
<ijohnson> cachio: also re: the snap-set-core-config, the test exposed a real bug, so I will need to fix that bug before we can fix the test
<cachio> ijohnson, hehe
<cachio> good news in that case
<ijohnson> cachio: yeah :-)
<ijohnson> cachio: also for your uc20-recovery is that snapd panic reproducible for you ?
<ijohnson> or did it just happen once, as I don't see that with my VM
<cachio> yes
<cachio> the once I sent before?
<ijohnson> cachio: the one from https://paste.ubuntu.com/p/hsNtwZNYsw/
<ijohnson> cachio: what arguments are you running the external VM with ?
<cachio> yes
<cachio> I have a debug session opened
<ijohnson> cachio: I use this:
<ijohnson> https://www.irccloud.com/pastebin/DDPDyNii/
<ijohnson> maybe I need to provide less RAM to the VM
<cachio> ijohnson, I use https://paste.ubuntu.com/p/mCyynrpCpQ/
<cachio> 2048
<cachio> big diff
<ijohnson> cachio: ack I'll try with 2048 to see if I can reproduce it
<ijohnson> cause yeah we might have run out of space, but we shouldn't panic in that case I'm pretty sure
<cachio> I'll try with 3gb
<mup> PR snapd#8829 closed: sandbox/cgroup: add tracking helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8829>
<cachio> ijohnson, with 3GB didn't work
<cachio> trying with 4GB now
<cachio> got stuck after reboot
<ijohnson> cachio: you mean with 3 GB it didn't panic but it did get stuck after reboot?
<cachio> dont know because after 20 minutes I killed spread
<cachio> https://paste.ubuntu.com/p/JC4kDVGCWV/
<cachio> ijohnson, this is the output
<ijohnson> ah cachio that seems to be the bug that I thought I fixed by deleting the ~/.ssh/rc file
<ijohnson> cachio: interesting, I need to step out for a while now, but I will try again to see if I can reproduce that issue
 * ijohnson -> afk for bit
<cachio> ijohnson, np, see you then
<cachio> ijohnson, with 4GB workerd well
<cachio> ijohnson, https://paste.ubuntu.com/p/PDt2jk3W2f/
<cachio> the problem is that in the lab devices we don't have 4gb
<mup> PR snapcraft#3190 opened: extensions: export content snap egl vendor dir <maintenance> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3190>
<ijohnson> cachio: yes I will see what to do about using 2G, also won't this test be run on devices like rpi that might only have 1G of RAM?
<cachio> ijohnson, yes
<cachio> it runs in pi3 with 1 or 2 gb
<cachio> and pi4 with 4/8gb
<cachio> which is fine
<mup> PR snapcraft#3174 closed: link_or_copy: do not try to create hardlinks to symlinks <bug> <Created by hpoul> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3174>
<mup> PR snapcraft#3190 closed: extensions: export content snap egl vendor dir <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3190>
<mup> PR snapcraft#3191 opened: plugins: introduce v1.FlutterPlugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3191>
#snappy 2020-06-28
<mup> PR snapd#8935 opened: spread.yaml: allow amazon-linux-2-64 qemu with ec2-user/ec2-user <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8935>
