#snappy 2015-04-27
<D_Cent> tyhicks: hi! i just solved my name_to_handle_at problem - i re-compiled the libusb4java shared object on my other raspberry pi with raspbian and put this version into my project and it seems to work correctly now :)
<FourDollars> Hi, what is the difference between ubuntu-15.04-snappy-amd64+generic.img.xz and ubuntu-15.04-snappy-amd64-generic.img.xz?
<JamesTait> Good morning all; happy Monday, and happy Tell a Story Day! :-D
<ruenoak> FourDollars: I think one is Stable and one is Edge a rolling dev version, just a guess though, but the download img's are named the same
<hawkowl> hmm okay i am having some trouble with my Python app
<hawkowl> there's no $TEMP or $TMP passed through, it seems, so it tries the system default places, which doesn't work
<mvo> hey jdstrand, so you mentioned earlier that you see a upgrade hang on bbb?
<jdstrand> mvo: hi!
<jdstrand> mvo: I did see a significant delay, yes. I'm not sure if it was related to https://bugs.launchpad.net/snappy-ubuntu/+bug/1447652 or not
<mvo> jdstrand: I think its because there is a thing called SyncBootloader files that will always cp /boot/a -> /boot/b which is now very slow because we use sync and also not needed because ubuntu-device-flash already did that
<jdstrand> mvo: oh, interesting
<mvo> jdstrand: so its a separate bug, but if you don't mind, please file it because I think we need to kill that function
<mvo> jdstrand: if you ctrl-z and ps afx you probably see a "cp -a" there
<mvo> cp -a /boot/a /boot/b
<mvo> to be precise
<jdstrand> mvo: https://bugs.launchpad.net/snappy-ubuntu/+bug/1449032
<mvo> thanks jdstrand
<jdstrand> np
<mvo> jdstrand: I'm doing a stop-watch test right now and its already copying for >4min :(
<jdstrand> yeah
<tyhicks> D_Cent: great to hear that you're unblocked and I'm glad that we don't need to allow name_to_handle_at
<tyhicks> D_Cent: thanks for the update :)
<leandrosansilva> Hello to all. I am doing some research for a new product where I work and ubuntu snappy came up as a possible base for it. I am looking for a operating system which allows me to perform "atomic updates", avoiding the possibility of breaking my system in case of an update failure. Do you think ubuntu snappy may me suitable for such task?
#snappy 2015-04-28
<wxl> stupid question of the week: how does one use a bluetooth for input on snappy for things (pi2 fwiw)
<dholbach> good morning
<dholbach> can somebody take a look at https://bugs.launchpad.net/developer-ubuntu-com/+bug/1447733?
<dholbach> is snappy-ubuntu the project to be used?
<dholbach> sergiusens, https://bugs.launchpad.net/snappy-ubuntu/+bug/1447733 - is this a known bug?
<dpm> hi lool, and here's one for you - it seems the package name of one of the Rpi2 bits needs renaming? https://bugs.launchpad.net/developer-ubuntu-com/+bug/1449417
<dholbach> lool, I just fixed the developer site part of it
<lool> dholbach, dpm: indeed; recent change to udf; there's another one we need to update for: command requires one more argument (15.04 or rolling)
<dpm> lool, I think I added that to the bug description. Could you confirm that is the case to make sure we're not missing anything else?
<lool> (the first error I'm getting is: "the required argument `Release` was not provided")
<lool> dpm: yeah; I'd like to check the prefix thing with beuno here
<dpm> lool, but with dholbach's fixes to https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2 you shouldn't get the  "the required argument `Release` was not provided" error anymore, should you?
<lool> dpm: oh I got the previous version of the page just minutes ago
<lool> I guess caching and all
<dholbach> yep
<lool> yeah new version looks good
<dpm> yeah, the page has now ' udf core 15.04 ...'
<dholbach> hey slangasek, your name is on the list for uos track lead - but there's a question mark behind your name... do you have more information?
<JamesTait> Good morning all; happy Cubicle Day! :-D
<lool> ppisati: heya
<ppisati> lool: yo
<lool> ppisati: I've used https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-3.19.1-7-generic-bcm2709_3.19.1-7.7_armhf.deb to build my rpi2 device tarball; it seems your device tarball works better (shows more memory)
<lool> ppisati: would you know what might explain this?
 * lool checks if PPA has newer version
<ppisati> lool: yep,. i pushed a new one
<ppisati> lool: uhmm... the only thing that come to my mind are the arguments passed on the cmdline (or embedded during kernel compilation)
<ppisati> lool: you mean, you see more memory
<ppisati> lool: moving from 3.18 to 3.19?
<lool> ppisati: hmm some user reported on the mailing-list seeing 128M, but now seeing 1G with your kernel (the thread you replied to)
<ppisati> lool: yep, what was previous? 3.18? 3.19.X?
<lool> ppisati: https://lists.ubuntu.com/archives/snappy-devel/2015-April/000548.html
<ppisati> lool: did he use uboot or direct booting?
<ppisati> lool: he didn't give that ifno
<lool> he said he used udf
<ppisati> lool: ok, so my kernel gives him more memory, but what was the previous one?
<lool> ppisati: one of mine, but I dont think which exact version
<lool> but the initial message is recent: https://lists.ubuntu.com/archives/snappy-devel/2015-April/000501.html
<lool> 5 days ago, I was already on your 3.19 kernels
<lool> ppisati: actually I can reproduce here
<lool> 3.19.1-4-generic-bcm2709 is the uname
<lool> Linux localhost.localdomain 3.19.1-4-generic-bcm2709 #4-Ubuntu SMP PREEMPT Fri Mar 27 19:49:10 UTC 2015 armv7l armv7l armv7l GNU/Linux
<lool> that's old (march 27)
<lool> console=tty0 console=ttyAMA0 root=/dev/disk/by-label/system-a init=/lib/systemd/systemd ro panic=-1 fixrtc rootfstype=ext4 init=/lib/systemd/systemd ro
<lool> ppisati: I'll just pull your latest kernel now, but I'd be interested in what might have changed between this march 27th 3.19 and the latest that would explain the memory difference
<lool> dpm, dholbach: Ok, got to the bottom of the OEM namespacing changes from last week
<lool> the bottom line is: it's a bug, this could work, but we changed this while implementing "snappy switch" just before release, and now it's set in stone in the 15.04 release
<lool> so I'll reupload a pi2-unofficial or something like that
<dholbach> ok cool
<dholbach> lool, in a mail from Thursday somebody said about the raspi2 image "> Raspberry Pi - dang, that image is mostly 3.9Gb of uncompressed 0âs"
<dholbach> I'm not sure what to reply
<lool> dholbach: that's true; it's because I lazily rsync it over
<lool> but I think I could gzip --rsyncable it
<dholbach> yoohoo!
<dholbach> can we do something about http://pastebin.ubuntu.com/10923388/?
<lool> dholbach: no idea
<dholbach> sergiusens, ^ do you maybe know?
<lool> dholbach: image gziped BTW
<dholbach> lool, do we need to update the docs?
<lool> dholbach: I'm updating my README but I have to retest all the bits; it will take a while (also interrupted by various things  :-)
<dholbach> lool, cool, let me know
<beuno> jdstrand, store has t447
<beuno> r447 even
<shawn_freenode> ls
<lool> Password:
<lool> ppisati: Linux localhost.localdomain 3.19.1-8-generic-bcm2709 #8-Ubuntu SMP PREEMPT Mon Apr 13 19:16:38 UTC 2015 armv7l armv7l armv7l GNU/Linux
<lool> ppisati: still 128M though
<lool> same cmdline
<lool> ppisati: am I supposed to include some gpu mem cmdline option?
<jdstrand> beuno: nice, thanks!
<lool> [    2.623474] Kernel panic - not syncing: Could not decompress initial ramdisk image.
<lool> sigh
<ppisati> lool: nope, the embedded PPA is the correct one
<ppisati> lool: my board is disconnected now, didn't you say that you had all the memory?
<lool> ppisati: I think it's one of the other boot files that you kept and I didn't
<lool> fixup.dat or another one
<lool> I'm still researching
<lool> I've excluded vmlinuz and cmdline
<wxl> anyone here using snappy on a pi2?
<jdstrand> tyhicks: hey, how familiar are you with "send_destination" in dbus bus policy (ie, /etc/dbus-1/system.d/*.conf
<tyhicks> jdstrand: I'm not familiar with it off the top of my head
<jdstrand> ok, thanks
<tyhicks> jdstrand: I'll bet it is the equivalent to peer=(name=foo) in an AppArmor D-Bus rule
<jdstrand> tyhicks: that is what I was trying to figure out
<jdstrand> I think that is correct
<jdstrand> basically, it's the bus name
<jdstrand> (in dbus parlance)
<jdstrand> so, not the interface name or the object path
<tyhicks> right
<jdstrand> ok, I just filed a bug against snappy, but I think it is invalid
 * jdstrand is checking
<jdstrand> tyhicks: fyi, that is exactly the case
<tyhicks> nice
#snappy 2015-04-29
<dholbach> good morning
<leandrosansilva> Hello to all. Is there any generic installer for ubuntu snappy? I found some kvm appliances and images for r-pi and bbb, but  no "iso" image
<dholbach> you can find all the available images on http://developer.ubuntu.com/snappy/start
<dholbach> but I guess that's already where you found the other images
<leandrosansilva> dholbach: What I need is install snappy in a physical machine (atom processor)
<dholbach> I don't know if we have instructions for that
<dholbach> you can either wait for somebody else to answer the question, or you could mail snappy-devel@lists.ubuntu.com
<leandrosansilva> oh, thank you
<dholbach> no worries :)
<tbr> leandrosansilva: I'd highly suspect that just DD'ing the KVM image to a drive/usb-stick would work
<tbr> I'm a bit unclear about how the snappy hardware adaptation is done. As ubuntu obviously runs on physical machines, etc.
<leandrosansilva> tbr: thank you, I`m going to try this approach
<willcooke> hey sergiusens, I saw on the snappy ML that you guys are working on an installer this cycle.  Do you need any desktop-style requirements from us?
<willcooke> o/ seb128
<seb128> hey
<dholbach> willcooke, sergiusens and co is at a sprint right now, so I'm not quite sure how much they pay attention to IRC
<dholbach> if nobody responds, maybe send a mail to snappy-devel@lists.u.c?
<willcooke> ah, thx dholbach - I'll follow up on the ML
<dholbach> rock and roll
<willcooke> I'm going to do that now, otherwise I will forget...
<dholbach> :)
<willcooke> This marks an important stage in my life:
<willcooke> The second time ever that I've learnt something good from a mailing list.
<sergiusens> willcooke: yes we are; we only brainstormed until now, we would need to put our notes out in the wild and I guess you can work it from there; we are going to focus on the core side of it and leave it to olli's team to work on personal (UI)
<sergiusens> willcooke: but in a nutshell, it's run live with an option to install
<willcooke> sergiusens, sounds great - thank you!
<willcooke> seb128, I wonder if we can wrap ubiquity around it?  Get that Ubiquity port to Mir everyone wants too?
<willcooke> sergiusens, do you know if there will be a UOS session on in?
<sergiusens> willcooke: I'll be spending time off next week and I think uos is next week, but maybe we can add one
<willcooke> sergiusens, no worries, I'll keep an eye on the schedule.  If not, if you could ping me when the docs are available and we can pick it up from there.
<seb128> willcooke, I'm unsure ubiquity is a fit, it's based on the debian installer and quite much on debs systems
<seb128> willcooke, what we need there is closer from e.g usb-creator
<willcooke> seb128, NEW INSTALLER! \o/
<seb128> something that dump an image on a disk
<seb128> haha
<willcooke> I'm going to write it in bash script
<seb128> though part of ubiquity would make sense to reuse maybe, like partitionner
<seb128> :-)
<sergiusens> we talked about it, it's a simpler problem to solve that ubiquity
<willcooke> oh, yeah - partitioning will be interesting
<seb128> at the same time, does partitionning is a feature we want to support?
<seb128> or is snappy just a "take over the disk" type of system?
<willcooke> hrm - good call, probably dont need to worry about it too much at this stage
<sergiusens> those question are in our notes, but feel free to ramble on, you might end up with good ideas
<sergiusens> :-)
<mvo> sergiusens: https://bugs.launchpad.net/snappy-ubuntu/+bug/1449904
<JamesTait> Good morning all; happy World Wish Day! :-D
<sennn> what is snappy?
<zer0x> i have a problem installing remotely a .snap
<zer0x> WARNING, trying automatic key setup, if it fails use --pub-key [path-to-key] or input your password on every request.
<zer0x> Failed to setup keys: no pub ssh key found, run ssh-keygen first
<zer0x> and then it ask me for 3 times the password:ubuntu
<zer0x> but it give me error: issues while running ssh command: Usage:snappy [-h] [-v]
<zer0x>              {info,versions,search,update-versions,update,rollback,install,uninstall,tags,config,build,booted,chroot,framework,fake-version,nap}
<zer0x>              ...
<zer0x> snappy: error: unrecognized arguments: --allow-unauthenticated
<zer0x> then I try to use eclipse to copy paste my .snap and then to install it locally
<zer0x> and i get the error: Package architectures "all" not compatible with system architecture "armhf"
<zer0x> (I forget to mention I use beaglebone black)
<leandrosansilva> Hello to all. How can I generate a ubuntu snappy image? I mean, how is the kvm image available for download generated? I`d like to do the same process but internally in the company I work. The basic idea is creating a snappy image with a few more things installed, as I could not find a way to install things on it except for snappy.
<leandrosansilva> I`ve been researching about system-image-cli command
<Odd_Bloke> Where is cloud-init able to write to on boot?  Would it be able to write in to a temporary directory?
<mwenning> Hi snappy guys, has anyone modified the snappy image so that it can be netbooted?
<dholbach> mwenning, many folks working on snappy are at a sprint now - if nobody answers, you could try to write a mail to snappy-devel@lists.ubuntu.com
<mwenning> dholbach, in Malta?
<dholbach> yep
<mwenning> dholbach, that's where I am ;-) , I'll ask around
<mwenning> thx
<dholbach> haha
<dholbach> great
<dholbach> find sergiusens or mvo or asac or lool
<dholbach> I'm sure they're going to have answers for you
<tbr> hmmmmm, so the current snappy amd64 generic image doesn't have capability to boot on a EFI system out of the box?
<dholbach> tbr, many folks working on snappy are at a sprint now - if nobody answers, you could try to write a mail to snappy-devel@lists.ubuntu.com
<tbr> dholbach: yeah, no need to repeat yourself. no I'm not at the sprint myself. yes, if nobody answers I'll email the list, like I did before.
<dholbach> tbr, sorry about that
<dholbach> I couldn't quite remember who I replied to in this channel
<tbr> though it's faster to just install a virtual ubuntu server image on uefi and copy over whatever will be missing
<dholbach> I just realised that many are interested in snappy after the release
<tbr> dholbach: someone else, but it scrolled through my view just minutes ago
<dholbach> and that some might be disappointed if they come here and don't get their questions answered
<dholbach> yeah, I didn't check when you actually joined
<tbr> dholbach: I was disappointed by the lack of help /before/ the release. ;-)
<dholbach> some folks were sprinting there as well ;-)
<dholbach> all right... I call it a day - have a good one yourself!
<tbr> yeah, I know. the usual "ZOMG release day comethfast!" frenzy
<dholbach> exactly :)
<dholbach> see you around!
#snappy 2015-04-30
<dholbach> good morning
<tbr> good moaning
<tbr> if anyone by chance knows how to build a snappy image from scratch, I'd be interested to hear. It looks like I'll need to dig into that to get it working for most of my use cases.
<dholbach> sergiusens, lool: if you're close to mvo, can you please nudge him to get back to me? thanks
<JamesTait> Good morning all; happy Poem in Your Pocket Day! :-D
<sergiusens> apw: http://paste.ubuntu.com/10950695/
<lool> dholbach: sorry, should have kept the .img file too; should I readd it along the .gz?
<dholbach> lool, I updated the docs to link to the img.gz - not sure about keeping the .img file?
<lool> dholbach: ok
<mwenning> asac
#snappy 2015-05-01
<JamesTait> Good morning all; happy Friday, and happy Batman Day! :-D
#snappy 2015-05-02
<citroniks> hi to all
<citroniks> in pi2 snappy not updating please help me in advance thanks
<devil> citroniks: what did you try to make it update?
<citroniks>  "sudo snappy update ubuntu-core "
<devil> citroniks: what does 'sudo
<devil> snappy versions -a' tell you
<devil> and you should use my nickname so I get notified, I do not stare at this channel
<citroniks> devil, ok ok in pi snappy has gui
<devil> citroniks: what are you trying to say?
<citroniks> devil, in raspberry pi 2 snappy os im getting only terminal i want to graphical user  interface
<devil> citroniks: snappy has no gui
<devil> what are you trying to do with snappy?
<citroniks> devil, run some qt application now only installed snappy os in pi
<citroniks> devil, im new to snappy os
<devil> citroniks: what does 'sudo
<devil> snappy versions -a' tell you
<citroniks> it showing error "server certificate verification failed "
<devil> hm, no idea, I have not used snappy lately, but never had such a problem
<devil> this channel is pretty dead on weekends, so you might have more luck on monday
<citroniks> devil, thank you so much  have a good weekend
#snappy 2016-05-02
<zyga> good morning
<morphis> zyga: ping
<zyga> morphis: hey, good morning
<morphis> zyga: morning!
<morphis> zyga: wondering if you tested the bluez interface changes at runtime as I am getting invalid apparmor profiles with those changes
<zyga> morphis: hmm, no I did not
<morphis> doesn't seem to like peer=(label=snap.bluez.{bluez,obex}),
<zyga> morphis: can you pastebin what you're getting?
<zyga> hmmm
<zyga> I see, thanks, jdstrand suggested those nad I assumed it would be digested
<morphis> zyga: https://paste.ubuntu.com/16186420/
<zyga> ok, let me look
 * zyga curses at 2fa
<zyga> why does it need to auth me for a f.... pastebin
<zyga> Plain form not available for deep linking.
<zyga> morphis: odd, for me it complains at line 241
<zyga> AppArmor parser error for test.aa in test.aa at line 241: syntax error, unexpected TOK_ID, expecting TOK_CONDID or TOK_END_OF_RULE
<zyga> and that is:   # for 'udevadm trigger --verbose --dry-run --tag-match=snappy-assign'$
<zyga> ??
<zyga> I think line numbers are broken
<zyga> it really complains about   signal peer=snap.@{SNAP_NAME}.*,$
 * zyga experiments
<zyga> morphis: it's clear that something is quite not right
<zyga> morphis: can we wait till jdstrand or tyler shows up?
<morphis> sure
<morphis> zyga: reworking the network-manager interface now
<slvn> hello ! got some issue with my snap. Running "snap-review mysnap" says "checksums do not match.". I can't upload it to the store because of that. I have tested the "opencv" example and it worked.
<slvn> I have also tested the command lines "snapcraft snap <DIR>" or "mksquashfs <dir> ..". But it failed also the checksum test.
<zyga> slvn: we know that, at least on pi2, mksquashfs is not really deterministic
<zyga> maybe it affects other arches
<zyga> slvn: for now I'd report a bug and try to investigate
<slvn> zyga, could you (quickly) double-check with the SDL2 package that it also fail on your side ? I am on amd64, and build for amd64
<zyga> slvn: I'm somewhat busy but if you run it 100 times and collect the distribution of the hashes that would make a fantastic bug report
<zyga> slvn: note, run mksquashfs only
<slvn> ok why not ...
<slvn> how can I get the hash ? checksun mysnap.snap ?
<zyga> slvn: sha512sum
 * zyga explores how to refactor snapenv
<slvn> and you say, I only need to re-do "snapcraft snap" ?
<zyga> I'd just re-do the squashfs command but snapcraft snap is close enough
<slvn> zyga, I get something like : http://paste.ubuntu.com/16186526/
<zyga> hmm
<zyga> perhaps snapcraft snap is not enough
<zyga> as in, it does changes to snap/ files
<zyga> kyrofa, sergiusens: ^^
<slvn> zyga, something like "mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs" ??
<zyga> yes
<slvn> same randomness ..
<zyga> slvn: report that as a bug on squashfstools please
<zyga> definitely worth investigating
<slvn> ok
<zyga> slvn: can you also check if it is the same if you use something to turn of paralell compression?
<slvn> zyga, I was about to test that. But I haven't find the option
<slvn> op yes -processors
<slvn> I try
<zyga> slvn: -processors 1
<slvn> also failing :/
<slvn> I will do the bug report !
<morphis> zyga: I will most likely write the snap label replacement code you wrote for the plug side also for the slot side
<zyga> sure
<zyga> morphis: if you figure out why apparmor doesn't accept the file you sent me feel free to fix the shared function too
<zyga> morphis: and note that for me it also failed on line mid-file
<zyga> morphis: on all-up-to-date xenial
<morphis> ok
<morphis> zyga: https://github.com/ubuntu-core/snappy/pull/1036#discussion_r60144002 is what I am currently looking into
<morphis> but trying first to rework the rules a bit
<zyga> morphis: keep this in mind: https://github.com/ubuntu-core/snappy/pull/1036#issuecomment-215841904
<zyga> morphis: the 'works on the desktop' aspect
<morphis> zyga: so how can I test that?
<zyga> morphis: snap nmcli separately perhaps?
<morphis> and how do I say that the ubuntu-core snap provides the interface?
<zyga> morphis: you want to look at snap/implicit.go
<morphis> ok
<zyga> morphis: but you'll have to bite the bullet and make it dependant on being on the desktop (say dpkg/info exists)
<morphis> hm
<zyga> but don't worry
<zyga> there's similar code in ubuntu-core-launcher
<pedronis> zyga: we really need to talk (with mvo etc)Â about what's the official way to detect desktop vs not
<pedronis> we need an official helper somewhere for that
<morphis> zyga: my only fear is this will bringup another lengthy discussion
<morphis> so I would like to do that after the first PR
<morphis> or let you guys do it properly
<zyga> morphis: no worries, I'll help you out
<morphis> zyga: sure but I want to get a first version merged soon, this is already pending for too long
<morphis> zyga: also I am getting
<morphis> peer=(label=snap.network-manager.networkmanager),
<morphis> in the plug apparmor file
<morphis> with your method from utils.go, shouldn't that be snap.network-manager.nmcli?
<zyga> hmm
<zyga> yes, let's see what I did there
<zyga> is networkmanager an app name?
<slvn> zyga, I haven't reported the bug yet because my testcase was passing the checksum test :)... so I found out something: adding a line "stage-packages: [ .. ]" solve the issue ...
<zyga> slvn: curious
<slvn> yep, I add a stage-package line in my "real" package, and it worked also. I will report that ...
<morphis> zyga: it is
<zyga> morphis: so that is correct, the plug can talk to the slot
<morphis> ok
<morphis> zyga: however I am wondering if its ok to include the client app name in the permanent slot apparmor policy, propably not
<zyga> hmm, why?
<zyga> client app name in permanent slot?
<zyga> isn't that what per-connection snippet should do
<morphis> zyga: https://paste.ubuntu.com/16186665/
<zyga> morphis: is nmcli connected to nm?
<zyga> morphis: it seems to be the same as bluez and bluetoothctl
<morphis> yes
<morphis> zyga: see https://github.com/ubuntu-core/snappy/pull/1036#discussion_r60144002
<morphis> that is what I had before
<morphis> but jdstrand said we should use proper snap.* names too
<morphis> for bluez we didn't do that
<zyga> wasn't that what my earlier patch (now broken apparently) did?
<morphis> https://github.com/ubuntu-core/snappy/blob/master/interfaces/builtin/bluez.go#L74
<zyga> ah, I see
<zyga> I'm somewhat confused though
<zyga> do we need this on both slot and plug ends?
<zyga> if the slot side permission didn't exist
<zyga> would the plug-side connection permission suffice?
<morphis> zyga: not sure too
<morphis> playing a bit with more generic rules right now
<slvn> https://bugs.launchpad.net/snapcraft/+bug/1577333
<ubottu> Launchpad bug 1577333 in Snapcraft "snap-review failed with "checksums do not match"" [Undecided,New]
<morphis> zyga: ok, I have a simpler version working now which pretty much looks the same as the bluez one
<ogra_> mvo, looks like your latest u-d-f is broken, mind rolling it back (or do we need to update the gadgets ? ... looks more like squashfs-tools to me though)
<zyga> ogra_: see the bug reported by slvn above
<zyga> it seems that mksquashfs is the new willy wonka
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash is the last working one btw
 * ogra_ has backups ;)
<zyga> the last one standing ;)
<ogra_> :)
<morphis> zyga: https://github.com/ubuntu-core/snappy/pull/1036#issuecomment-216181284
<zyga> morphis: thanks
<morphis> zyga: can you give this a last review round?
<morphis> niemeyer, jdstrand: ^^
<zyga> morphis: in a sec
<morphis> zyga: btw. should I have AutoConnect() { return true }?
<zyga> morphis: that won't do much on non-desktop
<zyga> auto-connect only connects to stuff on the OS snap
<zyga> (today0
<morphis> so you be false?
<zyga> yeah, leave it as false and add a note
<morphis> ok
<morphis> zyga: btw. if you want to test the bluez snap we have prebuilt ones at https://code.launchpad.net/~snappy-hwe-team/+snap/bluez
<zyga> morphis: oh, that's useful, thank you
<zyga> morphis: I'll get to testing this shortly, I'm mid-way in another branch
<morphis> sure, take your time :-)
<zzarr> hello! is there a snappy image for dragonboard 410c yet?
<ogra_> zzarr, build one yourself ...
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash should be the last working ubuntu-device-flash
<zzarr> nice, thanks ogra_
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/README has the runes you need
<zzarr> thanks ogra_
<ogra_> (do not use the mvo u-d-f, it is currently broken)
<zzarr> mvo?
<ogra_> the one mentioned in the readme
<zzarr> okey
<mvo> ogra_: almost ready again
<ogra_> good :)
<zzarr> I use the one you have ogra_
<ogra_> yeah, thats fine then
<zzarr> it's done (it was quick)
<zzarr> 100/100 internet connection ssd and a quad core i7... I don't ever have to wait :)
<mvo> zzarr, ogra_: new u-d-f is up
<zzarr> nice
<zzarr> mvo, what are the benefits with it?
<zzarr> (over ogra_'s binary?)
<mvo> zzarr: I don't know what ogra_ binary is doing, sorry so I can't answer
<zzarr> okey, no problem, maybe ogra_ can tell
<zzarr> thanks for helping me, both of you mvo and ogra_ :D
<zyga> morphis: I'm adding some inline comments to n-m
<morphis> zyga: aye
<zyga> morphis: quick side question: what's the dichotomy of apparmor doing some checks and dbus.xml doing what looks like the same checks again
<morphis> zyga: a more fundamental question we could solve with snappy but for now we want to stick to what upstream does + apparmor on top
<zyga> morphis: I see, thanks
<ogra_> mvo: my binary is simply the one from brefore it broke :)
<ogra_> *before
<mvo> ogra_: heh, clever!
<kyrofa> Good morning
<zyga> jdstrand: around?
<jdstrand> zyga: hey, I am now
<zyga> jdstrand: hey! :)
<zyga> jdstrand: I hope you had a good weekend
<zyga> jdstrand: we found some issues with apparmor and the {app1,app2} label syntax
<jdstrand> yes, thank you
<jdstrand> zyga: you too
<zyga> jdstrand: check the backlog with morphis above for details
<zyga> jdstrand: other than that there are some commends on the network-manager interface
<zyga> jdstrand: and otherwise we're looking good :)
<morphis> zyga: looking at them now ..
<jdstrand> zyga: can I see the generated policy?
<zyga> s/commends/comments/
<zyga> jdstrand: one sec
<zyga> jdstrand: https://paste.ubuntu.com/16186420/
<zyga> that's the same pastebin as above
<zyga> I tried it and I also had an error mid-file about signal and a glob there
<zyga> not sure what to make of it
<jdstrand> zyga: use peer=(label="snap.bluez.{bluez,obex}")
<jdstrand> zyga: ie, put it in quotes
<zyga> ah, so just " "
<zyga> morphis: ^^ :)
<jdstrand> yeah
<zyga> thanks! :D
<zyga> jdstrand: did you try to compile it?
<jdstrand> and you can do that for "snap.bluez.*"
<zyga> I also got an error with signal mid way
<jdstrand> zyga: yes
<zyga> ah ok
<jdstrand> and "snap.bluez.app1"
<jdstrand> zyga: as for signal, no issues here. are you compiling on an old kernel?
<zyga> jdstrand: on 4.4.0-21
<jdstrand> it works fine here
<zyga> if no issues let's disergard that, I'll re-check after this is patched
<zyga> disregard*
 * zyga cannot type 
<morphis> jdstrand: when you have some time, could you look at the reworked apparmor policy of the network-manager inteface?
<morphis> jdstrand: tried to keep the same things as we already have in the bluez interface definition
<jdstrand> yes
<morphis> thanks
<jdstrand> morphis: as for question or client name in permanent slot, no, we should not do that. We could/should do that in connected slot though
<morphis> jdstrand: ok
<jdstrand> s/or client/on client/
<kyrofa> zyga, `snapcraft snap` on its own will regenerate the meta/ directory. If you want to essentually only have it call mksquashfs you need to use `snapcraft snap <dir>`
<zyga> kyrofa: ah, thanks
<kyrofa> zyga, it does that so it picks up on YAML changes like changing the snap name, etc.
<urm8> hello!
<urm8> Hi people
<urm8> where do I get newest info about Snappy, including forum discussions on building and stuff like that?
<zyga> urm8: hey, right here is one spot, I know that many people also use ask ubuntu
<zyga> urm8: I'd recommend snappy-app-devel maliling list as well
<urm8> that mailing list looks like the one.
<urm8> Thanks
<zyga> urm8: there's also snappy-devel as well
<urm8> I wanted to pack OpenFoam, but the learning curve to deb packing seem though, so I thought maybe giving the Snappy way a try!
<urm8> brb
<kgunn> zyga: thot you'd be off today, but hey...after some discussion late friday with jdstrand, i think i really am stuck
<kgunn> i've got nil nil returning for everything but aa/seccomp on perm slot
<zyga> kgunn: hey? why is that?
<kgunn> but when i try to install my snap, it complains about dbus?
<kgunn> and i don't even have dbus or any need for it
<zyga> can you be more specific please?
<kgunn> yep one sec
<ogra_> asac, http://people.canonical.com/~ogra/snappy/all-snaps/canonical-pi2_3.3_all.snap in case you want to help testing :)
<kgunn> zyga: will get back to you in a minute with some pastebins...first have to clean up an experiment i ran late friday
<zyga> kgunn: ok, I'm in a metting now, happy to work with you after
<urm8> Hi people, is there a begginer guide to snappy too?
<sborovkov> Hello, which interface should I use to allow shared memory access? (peration="mknod" profile="snap.screenly-client.viewer" name="/dev/shm/WK2SharedMemory.907069164" pid=1006 comm="ld-linux-armhf." requested_mask="c" denied_mask="c" fsuid=0 ouid=0)
<zyga> sborovkov: ask jdstrand, perhaps none, in that case please file a bug on snappy (on launchpad)
<sborovkov> zyga: ok, got it
<sborovkov> jdstrand: Hello, is there an interface to allow shared memory access?
<zyga> sborovkov: to be clear, there's no specific interface, apps should have *some* shm access today
<zyga> perhaps the some value needs tweaking
<jdstrand> sborovkov: looking at your denial you need to adjust your app to use /{dev,run}/shm/snap/@{SNAP_NAME}/@{SNAP_REVISION}/
<jdstrand> tbh, I never understood why that directory had revision in the path
<jdstrand> I mean I sorta understood, but for what people use it for, it isn't needed imho
<zyga> jdstrand: the revision part is problematic, I think
<zyga> jdstrand: snaps hardly know that (they do but not really easy)
<jdstrand> I'm totally fine to remove it
<sborovkov> jdstrand: ok, understood, now just gotta find where it's used in webkit's code.
<zyga> jdstrand: if it's not a security issue I'd drop revision for sure
<jdstrand> zyga: SNAP_REVISION is in the env
<zyga> jdstrand: yes, I know but hardly anyone patches code to use it
<jdstrand> sborovkov: you might be interested in this historical bug: bug #1197060
<ubottu> bug 1197060 in apparmor-easyprof-ubuntu (Ubuntu) "SDK webview applications should use an app-specific path for shared memory files" [Undecided,Fix released] https://launchpad.net/bugs/1197060
<sborovkov> jdstrand: Hmm, looks like this was resolved by using 0xide whatever that is. We are using our own build of webkit unfortunately for now so that won't help I guess. I don't understand if with new security I could still use apparmor to tweak this for my app somehow? Or should I just go the route of tweaking paths it accesses
<ogra_> uh, webkit ... why do you get yourself into such a security nightmare ? :)
<sborovkov> ogra_: We had that part written long time ago to display web pages in QML. It also allows nice things like stopping animations, and some other low level stuff which is nice for performance on RPI. Now Qt moved to web engine but I have no idea if anyone even tried porting it to RPI
<ogra_> well, oxide definitely runs on armhf devices ... and is well integrated with qml
<ogra_> (and fully security maintained in ubuntu)
<sborovkov> ogra_: I will look at it, I was not aware about it before even. We are moving from raspbian to snappy currently. And have a beta soon, just need to port everything to new security (well once /dev/vchiq can be accessed with it). But need to get out beta for now :-)
<jdstrand> sborovkov: is there a bug on /dev/vchiq? if not, can you file it describing what the device is and why you need it? please add the 'snapd-interface' bug tag
<kgunn> zyga: hmmm....ok i made some progress, interesting stumbling block, i'd mod'd your refresh-bits to build off my fork of ubuntu-core/snappy (kgunnfront/snappy)...that seemed to be an issue
<kgunn> at any rate.. i can install mir-snap now
<kgunn> https://pastebin.canonical.com/155618/
<kgunn> jdstrand: ^ i've not been so excited in quite a while ;)
<jdstrand> slvn: is your issue one of bug #1576763 or bug #1555305 ?
<ubottu> bug 1576763 in click-reviewers-tools (Ubuntu) "pi2 images generate different checksums on repeated runs" [Undecided,New] https://launchpad.net/bugs/1576763
<ubottu> bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] https://launchpad.net/bugs/1555305
<zyga> kgunn: hmm
<zyga> kgunn: you cannot change the package name
<zyga> kgunn: you have to move your fork of snappy into $GOROOT/src/github.com/ubuntu-core/snappy
<zyga> kgunn: otherwise it will never ever do anything
<sborovkov> jdstrand: there is one, it has high priority now
<jdstrand> slvn: if so, please comment in those bugs with any relevant info. otherwise, please file a new bug and let me know the bug number
<kgunn> zyga: yep...i just copied over my mod'd files to ubuntu-core dir and it worked
<kgunn> zyga: tools are getting too smart these days :)
<jdstrand> sborovkov: what is the bug number?
<zyga> kgunn: glad to hear you are progressing :)
<sborovkov> jdstrand: https://bugs.launchpad.net/snappy/+bug/1533265
<ubottu> Launchpad bug 1533265 in Snappy "/dev/vchiq is inaccessible for unprivileged user" [High,Confirmed]
<jdstrand> kgunn: woohoo! :)
<kgunn> i know minor victory
<ogra_> jdstrand: we need the re-defined kernel snaps for thsi bug i fear
<ogra_> *this
<zyga> ogra_: why?
<ogra_> because we cant ship any udev roles today
<ogra_> *rules
<zyga> ogra_: you can, via interfaces :)
<zyga> ogra_: interfaces create udev rules
<jdstrand> it is more than just udev
<ogra_> inside the kernel snap ?
<ogra_> where would they end up ?
<zyga> ogra_: inside /lib/udev/rules.d
<ogra_> there is no bind mounting or anything for the location they would need
<jdstrand> zyga: those rules don't do DAC permissions
<ogra_> zyga: that would just be ignored at snap install time
<jdstrand> zyga: the interface udev rules are only for tagging
<zyga> ogra_: oh, I didn't knowthat
<jdstrand> I suspect this is a device that won't be covered by the existing implementation
<jdstrand> I asked for more information in the bug
<zyga> jdstrand: hmmm, it depends on what we need to do
<zyga> jdstrand: how is this different from /dev/ic2-1
<zyga> jdstrand: (which worked okay)
<ogra_> zyga: like you cant ship the kernel config in /boot/config-$uname today ...
<zyga> (roughly 2/3 months ago)
<jdstrand> but I suspect /dev/vchiq is something like all the android specific devices on Touch and simply needs to be granted to all apps somehow. we'll see
<zyga> jdstrand: AFAIR /dev/vchiq is pi specific but perhaps I just know wrong
<ogra_> jdstrand: it is a rpi only device afaik
<jdstrand> zyga: if you read the bug, the bug says a) they used hw-assign (it is gone) and b) after using hw-assign, the perms are 600
<zyga> ogra_: I used interfaces to "hw-assign" /dev/i2c-1 to my snap
<jdstrand> 'a' would need to be solved with interfaces. 'b' cannot currently
<ogra_> zyga: and thats fine
<sborovkov> jdstrand: I am not sure what it does exactly, but it's needed for h/w decoding on RPI
<zyga> jdstrand: that's my earlier bug, remember when I said non-background apps should have a chmodded /dev/*
<zyga> jdstrand: it works if you are a service
<zyga> jdstrand: (you run as root, the tagging does the rest)
 * ogra_ still thinks that needs solving on a kernel level first
<jdstrand> we can't just chmod stuff
<zyga> jdstrand: I argued that we should chmod the device to 666 if it's tagged
<zyga> (in the cgroup)
<jdstrand> I know you did
<jdstrand> that isn't the right solution
<jdstrand> it is too simple
<ogra_> why not use udev-acl here ?
<ogra_> and ship a udev rule for ti
<zyga> jdstrand: too simple and thus too open or what?
<jdstrand> it might be ok for this device, but it might not be for another device
<ogra_> *it
<zyga> jdstrand: if there's no tagging there's no cgroup, no chmod
<zyga> jdstrand: if there's tagging it is precisely because we want to allow access to the device
<jdstrand> I know, but just because it is tagged doesn't mean non-root should have access
<jdstrand> maybe it should. maybe it shouldn't
<zyga> jdstrand: plus remember that we can always apparmor-away all bits we don't want
<zyga> jdstrand: I remember the discussion, I know it's still an open question
<zyga> jdstrand: but it somewhat feels like policykit discussion we had with gustavo a while aog
<zyga> ago*
<zyga> jdstrand: when it's granted, it should be just allowed
<zyga> jdstrand: still, that's my 0.02
<jdstrand> and I maintain my objection to the simplistic approach
<jdstrand> we captured this in that doc a while ago. we can pick it up at another time
<zyga> jdstrand: given that if we say you cannot open without root, anyone can just ship a service that exposes it
<zyga> jdstrand: so I'd say it's not security but obfuscation at some level
<zyga> jdstrand: sounds good
<jdstrand> only if you assign it to the root service
<zyga> jdstrand: you assign it to a snap, what the snap author does is not something we control
<jdstrand> there's a lot of things to consider
<zyga> jdstrand: if it is assigned to a non-root cli tool then it's still under our control via the cgroup
<jdstrand> I understand what you are saying
<jdstrand> but the security policy is something that uses DAC as well as our sandbox
<zyga> sorry, I'm not trying to convince you, I'm just arguing because I think there's no extra security in this mode and I'm hoping you will show me I'm wrong :)
<jdstrand> we need to be extremely careful
<zyga> agreed
<jdstrand> especially when moving forward with multi-user, Ubuntu Personal and if we ever do opt-in per-app UIDs
<jdstrand> there is a lot to consider
<jdstrand> anyway, I can't consider all of this right this second-- I have meetings to attend to and PRs to review
<jdstrand> :)
<zyga> sure, no worries
<sborovkov> Alright guys, I am gonna come back in few days and ask you again about this. If there is no solution in sight I can use custom kernel snap/whatever I guess - though it would be very nice if it's possible to upgrade in the future to stock ones without reflashing SD cards
<dragly> Has there been any updates on accessing OpenGL in snaps? Last week I forgot to issue a bug report after I last talked on this channel about the trouble I had with Snapcraft+Qt+OpenGL on Nvidia hardware.
<dragly> I tried the ubuntu-clock-app example now, and I still get the "Unrecognized OpenGL version" error when running it after installation. Should I file a bug report or is this already fixed in a newer version of snapcraft? I'm using 2.8.4.
<zyga> dragly: there were no changes on the desktop that are released yet, we are working on the first SRU now
<zyga> dragly: though I'm not sure if that particular bug is fixed there already (it might be)
<dragly> anything in "proposed", or do I need to clone the repo to see if it has been fixed?
<kgunn> here's a bug link to track that
<kgunn> https://bugs.launchpad.net/snappy/+bug/1574851
<ubottu> Launchpad bug 1574851 in Snappy "libgl not found on nvidia machines (so far)" [Critical,Triaged]
<sergiusens> jdstrand hello! Can I inject raw apparmor to test something out somehow? hint, relate to /dev/shm
<zyga> sergiusens: maybe
<zyga> sergiusens: I can help you out
<zyga> sergiusens: do the connection and all the other stuff you want
<zyga> sergiusens: then edit /var/lib/snapd/apparmor/profiles/*
<sergiusens> zyga k, thanks
<zyga> sergiusens: then run apparmor_parser -r /path/to/that/file
<zyga> sergiusens: that should do the trick
<zyga> sergiusens: just keep in mind that various operations will erase that change
<sergiusens> zyga do I need to run anything after editing?
<kgunn> ok, i'm stuck with https://pastebin.canonical.com/155621/
<zyga> sergiusens: apparmor_parser -r
<zyga> sergiusens: on the file
<zyga> sergiusens: to actually load it
<kgunn> basically says it can't find mir-server when it's clearly part of the smae
<kgunn> *snap
<sergiusens> zyga says already loaded, how do I unload?
<kgunn> and this used to "just work"
<zyga> sergiusens: -r reloads it
<zyga> technically -r is replace
<zyga> so just -r :)
<dragly> kgunn: Thanks! I'll subscribe to the bug.
<kgunn> sergiusens: mvo i feel like this might be more in your wheelhouse, my mir-server.snap used to work & unchanged, i add mir i/f to builtin, mir snap installs...i see mir-server:mir in plug list
<kgunn> but then it fails with https://pastebin.canonical.com/155621/
<kgunn> saying it can't find mir-server which i can very well navigate to the current snap and see it there
<kgunn> did some pathing assumptions possibly change?
<asac> ogra_: whats that image?
<morphis> jdstrand: what about leaving the discussion to make that network-manager interface working on desktop up to another PR?
<ogra_> asac, THATS A GADGET WITH WROKING SERIAL
<asac> ogra_: ah... well, i cant use udf still :/
<ogra_> EEEK
<asac> need full blown images
<asac> hehe
 * ogra_ whacks his caps key
<jdstrand> morphis: I'm fine with that so long as there is a note in the PR about it (or even in the policy)
 * jdstrand was just going be what niemeyer asked for
<jdstrand> s/be/by/
<kgunn> so, using $SNAP_APP_PATH in my files, is that correct? or did it change to something like $SNAP
<morphis> jdstrand: yeah, commented for him on the PR about that
<jdstrand> kgunn: those changed
<morphis> niemeyer: would that be ok for you?
<jdstrand> kgunn: SNAP is install, SNAP_DATA is /var, SNAP_USER_DATA is /home
<kgunn> jdstrand: thanks
<jdstrand> kgunn: I often find myself using 'hello-world.env|grep SNAP' :)
<kgunn> jdstrand: i presume that's on a wiki somewhere and i just got lulled into previous glory/success :)
<sergiusens> kgunn its just $SNAP
<kgunn> thanks guys
<jdstrand> kgunn: I'm not sure of that. the docs are in the process of being updated. dpm may have more details
<dpm> jdstrand, kgunn, I'm missing some context on what you're trying to do, but that might help in the meantime: http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data/762405#762405
<kgunn> dpm: thanks...was just sharing i was lost :)
<kgunn> i was still using snap_app_path
<kgunn> didn't realize it changed
<jdstrand> dpm: we were talking about the status of the docs wrt 16 changes (of which env vars is one part)
<asac> kgunn: hello-world.env is your friend :)
<asac> oh that was already suggested
<asac> hehe
<kgunn> asac: that's ok, it helps me to be told more than once :-P
<asac> lol
<qengho> kgunn: I wish the Lint tool warned about using deprecated environment variables.
<asac> kgunn: also hello-world.sh is neat... you end up in a shell inside the app sandbox, so you get a live feel what it means to live in a box :)
 * asac hopes kgunn learned at least something on top now :)
<mvo> kgunn: sorry, was in a meeting. I think the error you see is fixed in master but not yet in the distro, we want to sru this RSN but it is not done yet
<didrocks1> ogra_: stupid questions, but where are the fresh vm images for ubuntu core series 16?
<sergiusens> jdstrand hey, I wrote an email to the list, mostly intended for you; maybe I am just too ignorant on many things I mention but wanted to get the ball rolling
<sergiusens> kgunn I've been adding an app to my apps called "shell" with the same plugs as the ones I want to test
<didrocks1> mvo: hey, do we have any equivalent of snappy list -u/-v ?
<mvo> didrocks1: not yet, but please file a bug and we prioritize it
<didrocks> mvo: ok, I think it's the same for rollback and such, isn't it? (I remember there was a set-versions or whatsoever)
<mvo> didrocks: yes
<didrocks> ricmm: that's going to make our script about rollback for FTF harder ^ :p
<didrocks> mvo: bug #1577439 and bug #1577441 (trying to point the next important show we have in it, but I know the timeline is short)
<ubottu> bug 1577439 in Snappy "No more -u/-v options for "list"" [Undecided,New] https://launchpad.net/bugs/1577439
<ubottu> bug 1577441 in Snappy "No way to rollback a snap since the move to snap command" [Undecided,New] https://launchpad.net/bugs/1577441
<slvn> jdstrand, the two bugs are https://bugs.launchpad.net/snapcraft/+bug/1575582 and https://bugs.launchpad.net/snapcraft/+bug/1577333
<ubottu> Launchpad bug 1575582 in Snapcraft "Snap package, using SDL2, needs access to libGL.so and DRI dependencies" [Undecided,New]
<ubottu> Launchpad bug 1577333 in Snapcraft "snap-review failed with "checksums do not match"" [Undecided,New]
<ogra_> didrocks, onyl kvm currently (with the normal amd64 image) for vbox you would have to convert yourself ...
<didrocks> ogra_: do you have any link?
<didrocks> I looked on cdimage, but only find the preinstalled file system
<didrocks> no .img
<ogra_> didrocks, nothing beyond mvo's all-snaps dir, we still have no official 16.04 snappy alpha yet
<didrocks> ogra_: ok, that confirms it! Thanks :)
<zyga> re
 * zyga pushed a nice refactor branch https://github.com/ubuntu-core/snappy/pull/1114
<zyga> morphis: I'm done with my current track, I can now look at dbus and quoting what's required
<zyga> morphis: anything else I can help you with?
<kyrofa> tyhicks, jdstrand https://code.launchpad.net/~kyrofa/ubuntu-core-launcher/create_user_common_data/+merge/293555 is ready for a look when you're able
<zyga> kyrofa: some of the error messages confuse allocating memory for filesystem operation failures
<zyga> confuse as in the error message might be confusing
<kyrofa> zyga, well remember it results in perror
<zyga> +	char *common_user_data = calloc(common_user_length, 1);
<zyga> +	if (common_user_data == NULL) {
<zyga> +		die("failed to create user common data directory");
<zyga> + }
<zyga> that's clearly confusing IMHO
<zyga> that's failed to allocate memory, not create anything
<kyrofa> zyga, the error message will actually say "failed to create user common data directory: out of memory" (or something similar)
<zyga> hmmm
<zyga> I see
<kyrofa> zyga, I didn't want the message to say "unable to allocate memory: out of memory" :P
<ogra_> needs to be prefixed with "success:"
<kyrofa> Hahaha
 * ogra_ sighs ... so it seems jdstrand made the german news with the ubuntu-core-launcher fix ...
<ogra_> top story at heise.de today ... "another insecurity in snap packages"
<jdstrand> the joys of open source :)
<ogra_> i wish i knew why they dislike us so much recently ...
<jdstrand> hopefully they reported that it was discovered internally and fixed within a day of discovery
<ogra_> nope
<ogra_> wow, google translate makes it nearly unreadable ...
<ogra_> https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=http%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FErnste-Sicherheitsluecke-in-Ubuntus-neuem-Paketformat-Snap-geschlossen-3195532.html&edit-text=
<jdstrand> heh
<jdstrand> it was fairly even until the end. then there was an axe to gring
<jdstrand> grind
<ogra_> Upon connection of mount points a clerical error resulted in the source code means that the launcher was placed with a correspondingly adapted package name to execute arbitrary code
<ogra_> rrright
<jdstrand> well, I said even, not accurate :)
<ogra_> heh
<jdstrand> they were pretty close
<ogra_> yeah, the german sentence is fine there ...
<sergiusens> jdstrand ok so I created #1577514
 * sergiusens should probably reply to the ML as well
<sergiusens> jdstrand ok just to add to the bucket list I've expanded https://bugs.launchpad.net/snappy/+bugs?field.tag=snapd-interface by 4
 * zyga soft-EODs
<jdstrand> sergiusens: thanks
<jdstrand> sergiusens: two of those are already fixed in trunk
<sergiusens> jdstrand sounds good; just wanted to be torough
<jdstrand> np
<kgunn> jdstrand: curious one, so i'm getting this denial https://pastebin.canonical.com/155642/ but i have "/run/udev/data/* r," in my slotAA
<sergiusens> kgunn you might be hit by that snapd bug where you need to remove a snap before installing it again
<kgunn> sergiusens: i am uninstalling my snap in between
<kgunn> snap remove mir-server
<kgunn> i installed with --devmode and it actually launched
<kgunn> so now just trying to go through the aa/seccomp dance
<palerider> well, this looks popular...
<sergiusens> kgunn I don't know how to answer your problem except rinse and repeat
<kgunn> right, sergiusens, i just thot that specifically having   "/run/udev/data/* r," in my slotAA would have taken care of the denials that appeared...
<kgunn> also i had that in my aa from the beginning
<kgunn> so wasn't like i added it
<kgunn> to suppress those
<jdstrand> kgunn: that should be allowed by that rule. perhaps the slot didn't connect (ie, the policy isn't in the profile in /var/lib/snapd/apparmor/profiles/...)
<kgunn> jdstrand: so i just grepped it
<kgunn> /var/lib/snapd/apparmor/profiles/snap.mir-server.mir-server:246:  #   /run/udev/data/* r,
<kgunn> i presume the # is not a good sign
<jdstrand> kgunn: no. there is a comment about it in the default policy. looks like your slot side didn't connect
<jdstrand> for your slot side udev apparmor rule
<jdstrand> (ie, don't be confused be the comment-- your rules 'simply' didn't connect
<jdstrand> )
<kgunn> jdstrand: so what should i look at now?
<jdstrand> kgunn: is the slot side configured to auto-connect?
<jdstrand> I thihnk the bluez interface was set to autoconnect
<jdstrand> let me look
<kgunn> jdstrand: no i'm not autoconnect
<jdstrand> otherwise, you could snap remove mit and then install
<kgunn> (i think)
<jdstrand> no, bluez isn't
<kgunn> jdstrand: but, just thinking about it... should mir be autoconnect?
<jdstrand> well, I'm not sure what the design is supposed to be here
<jdstrand> I mean, to me it would make sense that the permanent slot policy would autoconnect
<jdstrand> since it is, well, permanent
<jdstrand> kgunn: are you still using the trick I gave about putting it in the slot connection portion of the code or is it actually in the slot permanent part?
<jdstrand> kgunn: regardless, to unblock yourself, you can look at built/opengl.go and set autoConnect: true in your NewMirInterface() which would hopefully unblock you until zyga is back
<kgunn> jdstrand: right, so i'm actually permanent slot atm
<jdstrand> kgunn: ok, that's good (in that that is what it should be)
<kgunn> exactly
<jdstrand> try playing with autoConnect or moving it to connected slot and doing a manual connect to unblock yourself for the time being
<kgunn> ok np
<jdstrand> but we need zyga again
<kgunn> i mean i can run it with --devmode, so i'm really just wanting to work through doing it the "right way"
<kgunn> thanks again :)
 * jdstrand nods
<jdstrand> np
<example6> Hello everyone. I'm trying to make a _very_ basic snap consisting of nothing but a few shell scripts. I'm using just the 'copy' plugin to put everything in place, but it doesn't seem to be creating a .snap file OR moving any of the relevant files into snap/
#snappy 2016-05-03
<example6> Well, I learned that I need to do 'snapcraft assemble' to build the actual .snap, but when I do filesets to copy my binaries from stage/ to snap/ I keep getting an "Operation not Permitted"
<qengho> example6: You only need "snapcraft" unless you want the process to end prematurely at some stage.
<qengho> example6: I bet "strace -e trace=file -f snapcraft" will show you what you're doing wrong.
<qengho> example6: And/or, "snapcraft --debug"
<example6> --debug doesn't seem to be available for me, but the trace showed me that it had been looking for my files in parts/test/install which they never were copied to. I have successfully made a snap now which is pretty much all I need. Thanks @qengho
<example6> So in my snapcraft.yaml I specified daemon: simple and a command: property hoping that this would be registered as a snappy service and start automatically, but that seems not to be happening. Am I missing something big here?
<zyga> kgunn: re
<svij> hello!
<svij> I've snapped a cli-tool
<svij> how can I open the man pages of a snap?
<zyga> svij: there's a bug open on this, currently man pages are not supported
<zyga> svij: it's also non-obvious how it should behave
<svij> zyga: alright
<zyga> svij: e.g. what should be the man page name? $snap.$app
<zyga> svij: original?
<zyga> svij: should non-command man pages be alloweD?
<zyga> svij: etc, ideas welcome, we honestly don't know yet
<svij> zyga: that what I wondered too
<ysionneau> hi
<ysionneau> if I declare a plug in my snapcraft.yaml which I use directly in the same snap : after installation is the plug supposed to be printed by "snap interfaces" command?
<ysionneau> (because right now it's not :o)
<cjwatson> zyga: man pages> I would say that the name should not be mangled; instead, rely on man-db's existing support for inferring MANPATH based on PATH
<cjwatson> stuff other than section 1/8 is indeed trickier
<zyga> ysionneau: what interface is the plug?
<zyga> cjwatson: hmm, how does that work?
<zyga> cjwatson: $PATH/../man/ or something?
<cjwatson> zyga: basically
<zyga> cjwatson: interesting, thanks for this idea!
<cjwatson> zyga: also $element/../share/man
<zyga> ysionneau: can you please share your snapcraft.yaml
<ysionneau> zyga: sure! thanks a bunch :) http://pastebin.com/ZK8nRftb
<slvn> Hey ! I have some issue with the ubuntu "myapps" : "Core" vs "Personnal". I have .click packages for ubuntu phones, and I am also publishing some snap package. seems click and snap got merged ...
<slvn> I mean, the same webpage display release of click and snap, is this normal ?
<zyga> ysionneau: looking
<zyga> ysionneau: old security is gone
<zyga> ysionneau: the plug is parsed and thein ignored
<zyga> ysionneau: you cannot run unconfined with old securiry anymore
<davmor2> JamesTait: ^ slvn you might be able to answer
<slvn> somehow, based on the naming, .snap package are added under on the same package of my .clik packages
<pmp> is there a way to have snapcraft syntax check my .yamls?
<slvn> It actually makes sense! don't know wheter this is wanted or not
<JamesTait> I'm not aware of any merge... it wouldn't really make sense, with the package file formats being different (.deb for clicks, squashfs for snaps).
<slvn> also, my click package are targetted to ubuntu phones (ARM), wherease the .snap are Amd64
<JamesTait> Sounds like a bug to me.
<slvn> JamesTait, then my account is a little screwed-up now ..
<slvn> JamesTait, do you have some kind of admin account to see what's going on ?
<slvn> I confirm that on my dev page, I see under "Overview" both revision of click and snap
<JamesTait> Hmm... I see snaps under my Ubuntu Core tab and clicks under my Ubuntu Personal tab, but there's also a snap package that was shared with me on the Ubuntu Personal tab. So something's not right.
<slvn> JamesTait, it's based on the naming, my apps that have the same name are merged when published for the first time
<JamesTait> slvn, can you point me to an example package?
<JamesTait> I have limited access, so won't be able to fix anything, but might be able to shed light on it for those who do.
<slvn> JamesTait, https://myapps.developer.ubuntu.com/dev/click-apps/773/
<slvn> a mahjong game
<slvn> snap is not published, click is published months ago
<slvn> both are merge ..
<slvn> 'd
<JamesTait> slvn, looking into it for you.
<slvn> thanks ...
<JamesTait> slvn, OK, there's another user seeing the same thing, so it's not just a problem with your account.
<slvn> JamesTait, ok ...
<JamesTait> slvn, we're looking into the root cause - could you file a bug for it in the meantime? https://bugs.launchpad.net/software-center-agent/+filebug
<slvn> JamesTait, here it is: https://bugs.launchpad.net/software-center-agent/+bug/1577717
<ubottu> Launchpad bug 1577717 in Software Center Agent "Published snap package appears under the list of click packages" [Undecided,New]
<JamesTait> Thanks, slvn, we're on it.
<slvn> ok great !
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/1117
<ysionneau> zyga: how do we run unconfined now?
<ogra_> --devmode
<zyga> ysionneau: http://www.zygoon.pl/2016/04/snap-install-devmode.html
<ysionneau> zyga : ah thanks!
<jdstrand> zyga: ack but it will be a little while
 * jdstrand -> long meeting
<zyga> jdstrand: sure
<noizer> Hi guys
<noizer> I have a problem with an library that i want to use.
<noizer> The library does only support Soft float on my raspberry pi 3
<noizer> Is there any possibility to change snappy from Hard float to Soft Float?
<zyga> noizer: snappy doesn't care about binaries you run
<zyga> noizer: does that library run without snappy?
<noizer> zyga: No I tried to install it on a raspberry pi with ubuntu mate. But there I had a problem with hard floating :s
<zyga> noizer: can you be more specific?
<noizer> zyga:  i'm not familiar with hard and soft floating
<zyga> noizer: can you pastebin anything?
<noizer> zyga: Do you know Nuance the tts egine. They support only there library on ARM processors with soft floating
<zyga> noizer: nope
<ogra_> i doubt it will work
<kyrofa> Good morning
<ogra_> you might be able to ship a complete armel chroot inside your snap ... perhaps ...
<zyga> softfloat means that floating point is emulated, so it should work anywhere (slowly)
<ogra_> (but you would need to use a dristro that even provides armel ... armel is dead in ubuntu since 9.04 or so)
<zyga> though if you want to link to it with a armhf gcc you won't have luck
<ogra_> zyga, you cant exec armel binaries on armhf systems
<zyga> noizer: ask Nuance to rebuild
<zyga> ogra_: are you sure? why not?
<ogra_> yes i'm sure
<zyga> ogra_: curious, why is that?
<ogra_> you can multiarch ...
<zyga> ah
<ogra_> but that means *all* libs
<zyga> well, that's okay I was just curious
<zyga> right that's exactly what I expected
<zyga> it's just a different abi
<ogra_> and it means you cant use ubuntu
<zyga> right, so you *can* execute but you need to bag all the bit you need
<zyga> the cpu won't care
<ogra_> cpu and kernel wont care (if it is a hardfloat capable cpu) ...
<zyga> right
<ogra_> but you need to ship a full chroot inside your snap
<zyga> noizer: long story short I'd recommend really asking those folks for a build
<ogra_> (and all this is 100% theoretical ... i dont think anyone ever actually tesetd this)
<zyga> yep
<noizer> zyga: We asked for it but it will cost us 250 000 euro for a rebuild with all the features we want
<zyga> noizer: for an armhf rebuild?
<zyga> wow they are picky :)
<noizer> zyga: yes
<ogra_> wow ... thats like ... a lot of money for 5min of work
<zyga> noizer: unless they hand coded that with assembly that's typically "make" on an ubuntu install :/
<ogra_> yeah
 * zyga smeslls marketing BS (not noizer's in any way) 
<zyga> noizer: quick idea
<noizer> zyga I don't know how they builded it but yeah it is very expensive to rebuild
<zyga> noizer: get a raspberry pi 1 image, put it on your pi2's home directory
<zyga> and chroot
<zyga> if that works we can snap it
<zyga> noizer: that's total BS they just want money :)
<ogra_> yeah, it is definitely just "rebuild with ubuntu toolchain"
<ogra_> i.e pull your source tree onto an ubuntu armhf and build it ...
<zyga> ogra_: we even have nice cross toolchains packaged
<zyga> so they don't even need a board
<ogra_> yeah
<ogra_> well
<ogra_> depends on the depends ;)
 * zyga will start charging $0.25M for his python rebuilds now ;)
<zyga> ogra_: yeah true
<ogra_> (you really wouldnt want to cross build a gui app that uses a lot of libs ... )
<ogra_> wxgtk ;)
<noizer> zyga how does it works then with the image of rpi 1
<zyga> noizer: pi1 is using an older cpu
<zyga> noizer: e.g. a raspian image is compiled for armel
<noizer> zyga ok then put it on my rpi3 and compile and install it on that image?
<zyga> noizer: compile everything on your pi1
<zyga> noizer: make sure it works there
<zyga> noizer: then grab the whole sd card and tarball it
<zyga> noizer: then put that tarball on a pi3
<zyga> noizer: unpack it, you may need to tweak some things (bind mount /proc etc)
<zyga> noizer: then chroot
<zyga> noizer: check that it still works
<zyga> noizer: if you get that far we should be able to snap it
 * zyga looks forward to "enterprise" software
<ogra_> if the above doesnt work you should always be able to use a real container
<ogra_> lxc or docker ...
<noizer> So what will docker do then?
<zyga> noizer: don't worry about docker
<zyga> noizer: try what I said
<noizer> ps Is there not a way to make snappy Soft floating?
<noizer> zyga Ok how will it works then with my other software because my software needs to connect with the libaray.
<ogra_> you would have to ship it as softfloat too ... likely in the snap snap
<ogra_> *same snap
<ogra_> (geez ... /me curses freud)
<noizer> Damn thats very hard then :s
<ogra_> (in a year from now the above sentence will be "snap snap, snap snap snap, snap !" .... )
<zyga> noizer: why is that hard?
<zyga> noizer: it's not pretty, essentially shiping a foreign distro in a snap
<zyga> noizer: but since the CPU itself allows this it would not be much different from running raspbian natively
<zyga> noizer: I guess it depends on what you want? prove that it's possible for a demo? use it "in production"
<ogra_> yeah, not m,uch different from running i386 chroots on amd64
<zyga> yeah
 * zyga curses timezones 
<zyga> is UOS starting in two hours from now?
<kyrofa> zyga, indeed
<zyga> thanks kyrofa
<kyrofa> zyga, plenary opening in two hours, sessions start in three
<kyrofa> Hey ogra_ I've been investigating the ROS failure on xenial-- the one that was due to locale settings. On Ubuntu Core, at least the image I have, LANG=C.UTF-8. However, on Xenial LANG=en_US.UTF-8. ROS runs fine with C.UTF-8 but errors out with en_US.UTF-8 (like this: http://pastebin.ubuntu.com/16200846/ )
<kyrofa> ogra_, is that just a difference between ubuntu core and the desktop?
<noizer> zyga Ok I will try it tomorrow because then I got my rpi1 with me
<zyga> noizer: good luck
<noizer> zyga If i have some troubles can you help me out then?
<ogra_> kyrofa, we ship no locales at all on the image ...
<zyga> noizer: i'll be attending UOS  but I can try
<noizer> UOS? what does that mean?
<ogra_> noizer, ubuntu online summit
<zyga> heh
<kyrofa> noizer, http://summit.ubuntu.com/
<zyga> I just tried to install a snap
<zyga> sudo snap -i ...
<ogra_> usually the place weher we do planning for the next release ...
<zyga> old habits die hard
<ogra_> fix that 1
<ogra_> !
<ogra_> (by adding -i  ;) )
<zyga> ogra_: maybe I'll implement -i as a hidden command
<zyga> also printing "we feel your pain" ;-)
<ogra_> yeah :)
<kyrofa> ogra_, that explains the C then, I suppose. Right?
<ogra_> right, we ship whatever libc includes by default ... which is C and C.UTF-8
<ogra_> there is no additional locale handling in the rootfs ... you have to do that inside the snap itself if needed
<kyrofa> ogra_, right, I have the opposite problem-- the locale on the xenial desktop is busting me. So I guess I should just set C.UTF-8 in my snap, huh?
<ogra_> (we also dont ship keymaps or fonts that support UTF8 )
<kyrofa> I don't know why it's not working though, which is frustrating
<ogra_> kyrofa, yeah
<kyrofa> Stupid boost and its cryptic errors
<sergiusens> morning
<kyrofa> Morning sergiusens :)
 * zyga triaged https://bugs.launchpad.net/snappy/+bug/1577472
<ubottu> Launchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete]
<zyga> ogra_: btw, do you perhaps know what compells gnome-terminal (or shell running inside it) to interpret, e.g. alt+l as Å (on my locale)
<zyga> ogra_: I'm asking because it seems to stop as soon as I run a snap
<zyga> (not all snaps, but hello world seems to be affected)
<ogra_> hopefully all snaps :)
<zyga> not all snaps :)
<ogra_> oh ?
<zyga> ogra_: build this https://bugs.launchpad.net/snappy/+bug/1577472
<ubottu> Launchpad bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Incomplete]
<zyga> ogra_: (snapcraft.yaml inline)
<zyga> ogra_: that snap still works!
<zyga> as in I get Å
<ogra_> we explicitly do not chip any locale support, keymaps or console fonts
<ogra_> (that would likely easily triple the size of the rootfs )
<zyga> ogra_: but how does it work, gnome-terminal is from the classic ubuntu side
<zyga> ogra_: so it has the fonts
<zyga> ogra_: I don't know how input handling works
<ogra_> but not the locale info
<zyga> but I suspect it's also on the teminal side
<zyga> locale, right I get how locale works
<ogra_> we only support C.UTF-8
<zyga> but it doesn't affect keyboard input
<ogra_> it affects the representation of the key code
<zyga> hmm? how does that work? I suspect that the shell puts the tty into raw mode
<zyga> but what happens next?
<zyga> and how is that affected by snappy
<zyga> (I'm trying to understand why it doesn't work in hello-world but works in the small example I made)
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml
<ogra_> have a look at that
<zyga> I see locales there
<ogra_> if you want your snap to have support for more than C.UTF-8, you have to ship this set of packages
<zyga> I don't think that answers my question
<zyga> I'm specifically asking about how input handling works
<zyga> and why one snap behaves differently than another one
<zyga> the snap I made has busybox-static
<ogra_> a keycode is sent ... it gets processed and a char is printed :P
<zyga> hmmm
<zyga> right
<zyga> I see
<zyga> processed, that's where locales go in
<ogra_> if your font doesnt have the char, it cant be printed (and you get little squares)
<zyga> I guess that busybox just accepts and echoes everything that's not a special control character clearly
<zyga> and bash is is doing it "properly" and hence I get nothing
<zyga> (properly == through locale)
<ogra_> right
<zyga> thanks!
<zyga> that makes sense
<zyga> I forgot about raw mode
<zyga> console echo can be deceiving :)
<ogra_> if you ship locales and console-setup-linux you should be able to get around that
<zyga> nah, I was just curious how it works
<zyga> I don't really need it for anything now
<zyga> I'd love if someone made locale that's tiny
<ogra_> lol
<zyga> and is not shipping translation
<zyga> translations*
<zyga> tiny as in ~50Kb max
<ogra_> locale and tiny dont really fit into the same sentence
<zyga> what's in locale anyway?
<zyga> what's the big part?
<zyga> (is it just glibc doing crazy correct huge thing or is it an intrinsict problem of locale data)
<ogra_> (i mean, the locale itself perhaps ... but you need all tghe surroundings like termcap/curses ... fonts etc etc )
<zyga> fonts = not really
<zyga> (not on classic)
<zyga> not in webapps
<zyga> termcap = not in webapps
<ogra_> just ship the locales package
<zyga> and outside, man just ship one for xterm and ignore the rest :P we have two termcap packages, one normal and one kitchen-sink one
<zyga> I see a billion charmaps
<zyga> perhaps 90% of them are useless today
<zyga> or 100%-1
<zyga> man what a load of garbage :)
<zyga> and the actual locale definitions should be easily under 50KB compiled
<zyga> even the charmaps are tiny
<zyga> (obsolete but small)
<zyga> though locales get some processing
<zyga> (which is also super slow) on install time
<zyga> do you know what that does?
<ogra_> it creates the binaries
<ogra_> from the locale definitions
<zyga> does that have to run at install time?
<ogra_> (simply calls locale-gen i think)
<zyga> can we compile all locales on snap build time?
 * zyga reading the script now
<ogra_> if you want to use the locales, they have to be up to date against whats on the system, yes
<zyga> just shell, no perl :)
<zyga> against what's on the system? what does that mean?
<zyga> are they self contained or not?
<ogra_> if they were self contained you would have to generate them at install time ;)
<zyga> so what do they need from the system on install time?
 * zyga reads the script
<ogra_> have a look under /usr/share/locale
<zyga> I see just .mo files
<zyga> anything I'm missing
<zyga> mo files are built at compile time
<zyga> I don't suspect locale-gen needs gettext to run
<ogra_> and locales are built from the mo files
<zyga> !?
<zyga> but they contain keymaps
<zyga> how is that related to translations
<ogra_> LC_MESSAGES is part of your locale
<zyga> keymaps and charmaps
<zyga> yes but the question is: why do we need to generate anything on install time
<ogra_> to be in sync with the binaries on the system
<zyga> I don't understand, in sync with what
<ogra_> (better ask infinity for details)
<ogra_> buit afaik there is no way to ship "small" locales pre-created
<zyga> if I update, say, the translation catalogue for something, do I need to rebuild locale data?
<ogra_> yes
<zyga> do you know why?
<ogra_> out prob is really that we do not enforce C.UTF-8 ebverywhere yet
<zyga> that's not a solution to apps wanting to have locale support really
<ogra_> you dont really want country specifric locales, but you want full UTF-8 support
<ogra_> which a LOCALE=C default doesnt give you
<zyga> I'm trying to understand how locale works today
<zyga> I know that
<zyga> I disagree about country specific locale, it depends on an app
<ogra_> but half of snappy uses C ... the other half uses C.UTF-8
<zyga> hmm? do we set locale to C anywhere explicitly?
<ogra_> we're not consistent yet ... i.e. the launcher needs to enforce C.UTF-8
<zyga> I'm still puzzled by what you said earlier:
<ogra_> no
<ogra_> C is the fallback
<mvo> zyga: we even have a bug about the Å issue: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576411
<ubottu> Launchpad bug 1576411 in snapd (Ubuntu) "UTF-8 is not very well supported inside snaps" [High,Triaged]
<zyga> zyga	if I update, say, the translation catalogue for something, do I need to rebuild locale data?
<ogra_> if nothing is set
<zyga> ogra_	yes
<ogra_> mvo, yeah, i just commented on that :)
<zyga> right, I saw that bug
<ogra_> zyga, the issue is that we need to eliminate the places where C is still used
<mvo> aha, nice
<mvo> sorry,I looked at this yesterday haven't seen all the followups :)
<zyga> ogra_: I still want to understand locale better
<ogra_> zyga, infinity is your man :)
<zyga> thanks!
 * zyga thinks this is a nice moment to take a lunch break
<sergiusens> kyrofa I have one for you https://bugs.launchpad.net/snapcraft/+bug/1577750
<ubottu> Launchpad bug 1577750 in Snapcraft "Search for libraries for 16.10 cause a build failure" [Critical,In progress]
<sergiusens> kyrofa better yet https://github.com/ubuntu-core/snapcraft/pull/496
<kyrofa> sergiusens, ah!
<sergiusens> kyrofa yeah, ah describes it perfectly ;-)
<kyrofa> sergiusens, I may have updated my comment as you were replying. But shouldn't the exclusion list be for the target rather than the host?
<kgunn> zyga: hey, so from y'day discussing with jamie, looks like my interface is not "connecting" .... i added autoconnect true, but didn't seem to help
<kgunn> thots?
<zyga> kgunn: that's expected, the problem here is that auto-connect is only affecting the OS snap
<niemeyer> dholbach: ping
<zyga> kgunn: see http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html (the 2nd to last header)
<zyga> kgunn: it will not connect anything to a slot on the mir snap, we need to discss how this should work before we enable it
<kgunn> zyga: @will connect anything...you mean that expresses a mir plug in their yaml right? i would've thought that would be the prevention, e.g. manual review for anyone wanting the mir-server slot
<zyga> kgunn: connect will connect anything compatible
<zyga> kgunn: that's still a TBD, how we want this to work, it's related to assertions as well
<zyga> kgunn: I think you should focus on getting the interface to work for mir proper and for mir client apps and we'll iterate on connection policy
<kgunn> zyga: ok, i'll migrate to a connected slot today.... that should keep me busy :)
<kgunn> i need to clean up client yaml too
<zyga> kgunn: cool, ask me anything if you are blocked
<zyga> dholbach: do you want me to prepare anything about interfaces?
<zyga> dholbach: or should I just join various sessions and answer questions/talk
<sergiusens> kyrofa yes, but we need to implement the `release` tag in snapcraft.yaml to know what we are targetting ;-)
<kyrofa> sergiusens, okay, same page then
<kyrofa> sergiusens, so for now we're assuming the same release as host?
<sergiusens> kyrofa yeah :-) I want to play ball as if yakkety did not exist yet though
<sergiusens> kyrofa yup
<sergiusens> kyrofa and cleanbuild always assumes xenial
<kyrofa> sergiusens, +1
<sergiusens> kyrofa we are xenial centric for now; I don't think we want to start supporting building from yakkety just yet
<kyrofa> sergiusens, I agree, seems like a safe assumption
<kyrofa> sergiusens, problems occur when targeting a release older than host. libc symbols and whatnot
<sergiusens> ogra_ you are missing on the "other" network. Are you off today?
<ogra_> sergiusens, brunching :)
<sergiusens> ogra_ and you have a game to watch today I guess ;-)
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/1118 (for later)
<ogra_> sergiusens, bayern atletico ? yeah, i watched the first one ... wasnt that exciting though
<dholbach> zyga, feel free to join any of them - for the interfaces session, I guess niemeyer and you can start talking about interfaces generally and then we can move on to questions, workflow, etc.
<kyrofa> sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/497
<zyga> great, that's a plan then
<niemeyer> dholbach: Heya
<dholbach> hey niemeyer
<niemeyer> dholbach: Can we move the two core sessions we have at 15UTC to 17UTC?
<dholbach> http://summit.ubuntu.com/uos-1605/2016-05-03/ is the schedule for today :)=
<dholbach> :-)
<niemeyer> dholbach: I think the 17UTC slot is open on that track on both days
<dholbach> hohum
<dholbach> we announced the schedule already, so some might have planned their days according to this
<dholbach> 17 UTC today is the lunch slot
<dholbach> and the 15 UTC session today is about python3
<dholbach> so led by somebody in the foundations team
<ysionneau> zyga: read_paths / write_paths still exists ?
<zyga> ysionneau: no it does not
<zyga> ysionneau: that was a part of old-security
<ysionneau> what is the modern way?
<zyga> ysionneau: to come up with a new interface
<zyga> ysionneau: what do you need access to?
<dholbach> niemeyer, ^ did you see my reply?
<niemeyer> dholbach: Okay, sounds good, thanks
<ysionneau> ok maybe let me copy paste all the warnings I get (in --devmode) zyga
<dholbach> niemeyer, cool
<zyga> ysionneau: please do!
<ysionneau> zyga: http://paste.ubuntu.com/16201687/
<zyga> ysionneau: ah, /dev/shm, we're looking into making that easier
<zyga> ysionneau: currently you can access /dev/shm but just in weird locations
<ysionneau> yeah I've seen the mailing list posts
<sergiusens> kyrofa https://github.com/ubuntu-core/snapcraft/pull/498
<sergiusens> kyrofa about locale, I have ideas :-)
<kyrofa> sergiusens, good deal. Should we hold off on that catkin PR, then?
 * zyga tunes into UOS
<sergiusens> kyrofa just until standup which is when UOS ends :-)
<kyrofa> sergiusens, sounds good
<pmp> is there somewhere an snapcraft.yaml-example (up-to-date) which shows how to request a syscall permission?!
<sergiusens> pmp that is not possible anymore, now it is required to do it through interfaces (no surprises for end users). Talk to zyga or jdstrand (or attend the UOS session about it today!)
<zyga> pmp: o/
<sergiusens> personally I am hit by it a bit too as I can't easily get things out of the way
<dholbach> UOS sessions today: http://summit.ubuntu.com/uos-1605/2016-05-03/
<zyga> pmp: which system call are you missing?
<pmp> send - for a test I removed all plugs-sections of my apps - now added network
<zyga> pmp: send for a test? can you elaborate on that?
<pmp> the missing syscall was 'test' (289 on arm)
<pmp> not test - 'send'
<pmp> plugging my app to network fixed
<zyga> pmp: ah, cool :)
<zyga> pmp: so you don't need any interfaces beyond network?
<pmp> zyga: not for the moment
<zyga> pmp: cheers, good luck :)
<kyrofa> sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/450 has been rebased
<pmp> zyga: well, I just got another syscall missing 241, which is sched_setaffinity
<sergiusens> pmp you can start out by logging a bug and tagging it like https://bugs.launchpad.net/snappy/+bugs?field.tag=snapd-interface
<pmp> sergiusens: where (in snappy) is the mapping done between syscalls and interfaces?
<sergiusens> pmp in https://github.com/ubuntu-core/snappy
<sergiusens> exact location I would need to check for
<sergiusens> oh, top level interfaces in there
<noizer> zyga short question what OS should i run on the rpi1 for the soft-float problem
<zyga> noizer: rasbian should be easiest to work with
<zyga> noizer: the default pi os
<noizer> ok will it be automatically soft float?
<noizer> because i dont know mutch of floating etc
<noizer> may it be the latest rasbian?
<zyga> noizer: all of pi1 is like that
<zyga> noizer: yes, any version will work
<noizer> zyga ok
<noizer> maybe for good understanding
<noizer> zyga i just need to build an application for the soft floating
<noizer> on rpi1
<zyga> noizer: https://wiki.debian.org/ArmHardFloatPort (for some back-story)
<noizer> what should i do then?
<zyga> noizer: install rasbian, build your app there
<zyga> noizer: test your app
<zyga> noizer: look at the list I gave eaarlier, ask questions if you get stuck
<noizer> zyga: then i need to chroot and build it in a snap?
<zyga> noizer: then you need to take that whole rasbian install and stick it in your home directory on a pi3 system runnning ubuntu 16 series
<zyga> noizer: then we can see if it works there if you chroor inside
<zyga> noizer: we can look at snapping that, if it works, at the very end
<noizer> Ok
<noizer> hopefully will it work
<zyga> (or pi2, I don't know if pi3 works yet)
<zyga> ogra_: does pi3 work btw?
<zyga> with the pi2 image
<noizer> I can start first with the pi2
<ogra_> zyga, yes ... though i'd suggest to build your own image using the pi3 gadget
<zyga> ogra_: ah, nice, let me try that
<ogra_> i will roll back the pi2 one to pi2 only very soon
<zyga> I recall mvo did some changes to gadget support
<zyga> wonder if that affects ip3
<ogra_> which would leave you with an unbootable image
<noizer> ogra_: oooh ok
<zyga> pi3
<ogra_> the pi2 and 3 gadgets are identical ... apart from uboot.bin
<ogra_> so as long as the pi2 one works, the pi3 one will too
<pmp> ogra_: well the pi2 still behaves "not as before" - terminal via uart still doesn't work and the red-led is behaving strangly
<ogra_> pmp, yes, on my TODO
<pmp> but it works
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/canonical-pi2_3.3_all.snap
<pmp> I mean snap is working nicely - ideal for my tests
<ogra_> feel free to help testing this ;)
<ysionneau> it seems interfaces like network and network-bind are "builtin" in github/ubuntu-core/snappy . But I have other interfaces when I do "snap interfaces", I guess those are defined by ubuntu-core? Where is ubuntu-core code repo?
<zyga> ysionneau: all of those are coming from snappy
<ogra_> (thats my pending upload for the gadget snap that should restore the old UART behaviour
<zyga> ysionneau: I can show you where it is in the code if you want
<ogra_> )
<zyga> ysionneau: the core snap could, but is not currently, defining any interfaces
<zyga> ysionneau: in the snappy source tree look at snap/implicit.go
<zyga> ysionneau: all of the interfaces are defined in interfaces/builtin/
<ysionneau> so far I looked at https://github.com/ubuntu-core/snappy/tree/5324816c114757ed1b8641a63a84d6bd3a6edb66/interfaces/builtin
<ysionneau> ok lemme have a look at implicit.go :)
<ysionneau> thx
<zyga> ysionneau: there's also my post that describes a bit about how interfaces look like: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html
<ysionneau> ah I see.
<ysionneau> zyga: oh, I didn't see this one, did you post it on the ML?
<pmp> ogra_: I'd love to get more insights, but it is hard to find the bits and pieces - how to build a u-d-f for example, how to make a gadget-snap for rpi? Is there something available which might help?
<zyga> ysionneau: actually no
<zyga> ysionneau: I have a biiig one after this, just need a moment to finish some last bits
<ogra_> pmp, not really ... we are working on a porting guide soon
<ysionneau> awesome!
<ysionneau> something that snappy really lack right now is documentation, and it's really cool to see that it is coming up those days :)
<ogra_> (the prob is that it will be completely re-defined what a gadget snap is ... so we have to wait til that definition stands)
<zyga> ogra_: I suspect we'll need to decide on gadget/assertions transition next week
<ogra_> yes
<ogra_> thats my expectation
<ogra_> (that we come out of the week and know how kernel and gadget will look like)
<pmp> l
<pmp> is there a possibility to create an interface on my system, which actually provides more syscalls or other protected things via a snap?
<zyga> pmp: yes but you will have to contribute that interface to snappy to actually be able to distribute your snap in any way
<zyga> pmp: you cannot do that with a 3rd party snap
<zyga> pmp: all interfaces are defined in snappy source code
<zyga> pmp: and this is the basis of security of the whole architecture (along with reviews in the store when restricted interfaces are used)
<pmp> zyga: how will this work with a branded store? Where we will most likely need customized interfaces.
<zyga> pmp: that's an excellent question for the sprint
<zyga> pmp: wrote it down now
<pmp> zyga: thank you
<zyga> pmp: I think it would be good to know some extra details, can you share more with me in private?
<pmp> zyga: no problem, via mail it will be easier
<zyga> pmp: do you know how to contact me?
<pmp> zyga: I have your address
<zyga> jdstrand: add https://bugs.launchpad.net/snappy/+bug/1577471 to your TODO (To read) list please
<ubottu> Launchpad bug 1577471 in Snappy "Snap applications cannot access the user's normal XDG directories" [Undecided,Confirmed]
<jdstrand> zyga: yes, though we discussed that before-- niemeyer asserted that snaps should access ~/snap/name/version and not all those. that said, I'll read and comment in the bug a bit later
<jdstrand> zyga: so it is that, pr 1117 and 1118 that you need?
<zyga> jdstrand: yes though the purpose of the home interface is to let them access other files
<zyga> jdstrand: anyway, thanks :)
<jdstrand> other non-hidden files
<jdstrand> but sure, we can discuss in the bug
<jdstrand> I mean we can do whatever, I just want to make sure we are doing what we agreed to
<zyga> jdstrand: I reviewed the seccomp argument filtering branch btw
<zyga> jdstrand: I was wondering if we should do that in u-c-l, it feels like apparmor_parser like problem where we don't have to parse text in a setuid executable
<roadmr> hey folks, what's a good place to document my snap? i.e. people install it, then how do they learn more about how it works? is there a discoverable place for a README or something?
<jdstrand> zyga: it has to parse it, it sets up the seccomp sandbox
<zyga> roadmr: not at the moment, is that a desktop snap, a cli snap, a service?
<zyga> jdstrand: no, it has to setup the sandbox, doesn't mean that has to parse text :)
<roadmr> zyga: it installs a ssh server listening on port 8022 (see, I'd like to at least document the port)
<zyga> jdstrand: we could parse it into a binary format that is far easier to load
<jdstrand> zyga: how else is it going to setup the seccomp sandbox?
<zyga> roadmr: we don't have anything that would support that today
<zyga> jdstrand: the same way, just read the description from the binary file
<roadmr> zyga: so I'd say it's a service. I can always put a "ssh to port 8022 and poke around" in the description :)
<jdstrand> zyga: then we are parsing binary in a setuid executable
<roadmr> zyga: ok, gotcha... I'll find a workaround :) thanks!
<zyga> jdstrand: yes, that's far easier to validate
<zyga> jdstrand: load a header, load a bunch of structures, look at the data for sanity checking
<jdstrand> zyga: the kernel doesn't have an interface like apparmor for loading a binary blob
<zyga> jdstrand: yes but that can all be local to u-c-l
<zyga> jdstrand: the binary interface
<jdstrand> ehh
<jdstrand> I think there are bigger fish to fry
<zyga> jdstrand: e,g, we could even exec the parser and read from it, after dropping root
<zyga> jdstrand: sure, I just wanted to point that out
 * jdstrand notes that the parsing is happening after dropping root
<zyga> jdstrand: it feels like something that will grow and get more complicated
<zyga> oh
<zyga> I didn't notice that! sorry for that then
<jdstrand> granted, it isn't permanently dropped due to nnp (which is unfortunate, but the state of things atm
<jdstrand> )
<zyga> nnp?
<jdstrand> NO_NEW_PRIVS
<jdstrand> there is a comment in the code if you want to know more about it
<zyga> I see
<zyga> thanks
<jdstrand> but, seccomp is quite limited-- there isn't terribly much more we can do
<roadmr> can I build my snap for e.g. arm or arm64 on an x86_64 host?
<zyga> jdstrand: is the reason we're adding seccomp argument filtering because how apparmor and seccomp differ as to when they are inspected?
<zyga> roadmr: use launchpad
<zyga> roadmr: otherwise probably not
<roadmr> zyga: oh yay! I'll look into it. Not a big deal, really, it's a toy snap
<jdstrand> zyga: we are adding it for things like setpriority
<zyga> apparmor cannot inspect the arguments but seccomp can, right/
<jdstrand> zyga: with setpriority there are values that are ok (eg, >0) but other values that are not
<roadmr> zyga: thanks for your help, I know you're busy, much appreciated :)
 * roadmr goes for nooms
<jdstrand> zyga: apparmor doesn't do syscall filtering or inspection at this time
<jdstrand> apparmor uses the LSM
<zyga> jdstrand: right, thanks for hand holding me with all my questions :-)
<jdstrand> and the LSM hooks, which don't support syscall filtering (that is what seccomp is for). apparmor may, one day, allow setting a seccomp filter as part of its policy syntax (and therefore all the seccomp stuff could be removed from the launcher), but that is all future work (unprioritized)
<gblanchard4> How do I set the logging level when using the snapcraft commands?
<sergiusens> elopio what's our status on adt for the "other" arches?
<elopio> sergiusens: IS doesn't want to give us the access to the regions with other arches. We'll have to try again to use jenkaas, which is probably not ready for all the features we need.
<elopio> my hope is that they'll give us access while jenkaas is ready for us. Waiting for reply...
<sergiusens> elopio right, but all our tests error out in the archive's adt run, so wondering if there is an easy fix there
<elopio> sergiusens: without access to the same machine adt is running, I can only guess at fixes. Which means we'll know if they worked only when you put the new version in proposed.
<elopio> pitti: is there a way I can get the same armhf container autopkgtests are using?
<sergiusens> elopio fair answer :-)
<sergiusens> elopio as a follow up, that was about pivoting on arches, we should also add adt for yakkety if possible in our tests
<elopio> sergiusens: that one is easy, I added it to my TODO. Do you want it run in every PR?
<sergiusens> elopio yes please, we need to ensure we keep compatibility both ways (ensure APIs we choose work on both)
<sergiusens> elopio if possible enable that ASAP :-) Already going down the third dput that fails on infra ;-)
<elopio> sergiusens: on it...
<pitti> elopio: sure, just use adt-build-{lxc,lxd}, those are exactly what production uses
<pitti> oh, almost
<pitti> we apply this --setup-command on every test:
<pitti> ed -i "s/ports.ubuntu.com/ftpmaster.internal/; s/ubuntu-ports/ubuntu/" /etc/apt/sources.list `ls /etc/apt/sources.list.d/*.list 2>/dev/null || true`; ln -s /dev/null /etc/systemd/system/bluetooth.service
<pitti> elopio: sorry, of course you don't need the apt source mangling to ftpmaster.internal, that only works in the DC
<pitti> elopio: but you might want the ln -s /dev/null /etc/systemd/system/bluetooth.service, some tests fail otherwise
<pitti> (apt-get install bluez fails in a container)
<elopio> pitti: thanks, OD!I'll try soon.
<elopio> ignore the OD, it's hard to type these days.
<sergiusens> pitti do you know if python apt is broken in the archives? I am seeing lots of this in adt now http://paste.ubuntu.com/16204372/
<sergiusens> well maybe not python apt could be something else
<pitti> sergiusens: eek; haven't seen this yet, but this actually looks like apt itself (libapt)
<sergiusens> pitti so the path forward is I should wait for a tentative fix there and then click on "rerun"?
<pitti> sergiusens: where did you see this?
<sergiusens> pitti https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapcraft/20160503_064449@/log.gz
<sergiusens> pitti we use python apt where what fails are seen (only on y)
<pitti> sergiusens: oh, this isn't new -- http://autopkgtest.ubuntu.com/packages/s/snapcraft/yakkety/amd64/ history reaches back to all of yakkety indeed
<sergiusens> pitti I haven't seen this on xenial though (which gets adt runs on every code drop)
<sergiusens> in the process of adding yakkety now
<pitti> right, xenial seems fine
<sergiusens> but I have no idea what is going on given the archive is rather new I think infra problems but I may be totally off track
<Paddy_NI> Is there a way of browsing the currently available snaps?
<sergiusens> mvo can I ask you being the apt expert?
<sergiusens> mvo maybe I can expand that to "software package" delivery expert ;-)
<elopio> sergiusens: kyrofa: after Sergio's suggestion, this one is ready to go: https://github.com/ubuntu-core/snapcraft/pull/481
<sergiusens> elopio I am afraid of running any of this in yakkety now given the above breakage :-P
<sborovkov> Hello. Implementation question, may be someone did this before. So snap has access to /dev/shm/snap/snap-name/snap-revision. How do I make shm_open use that location? I see that that shm_open takes name that starts with `/` and it should be single `/` according to docs.
<elopio> sergiusens: well, this now seems stable enough. I can work on the yakkety run and I'm almost confident this one won't suddenly break :)
<elopio> so, feel free to leave it in the queue.
<sergiusens> elopio just want to get the apt issue solve first
<zyga> sborovkov: excellent question, let me look
<zyga> sborovkov: ah, sorry  shm_open is  not the same as /dev/shm
<sborovkov> zyga: is not it used for creating shared memory anyways
<zyga> sborovkov: AFAIR the memory allocated with dev_shm is not visiable in the filesystem
<sergiusens> zyga the man page seems to illustrate it otherwise
<zyga> sborovkov: for /dev/shm/stuff, I'm not sure but AFAIR it is just a tmpfs so you can just open files there
 * zyga reads
<sergiusens> shm_open(const char *name, ...) where name is of the form of a path
<zyga> sergiusens: yes, but I'm not sure that is an actual file, I'm almost sure it's not, though I could be wrong
<sergiusens> zyga maybe correct, but I guess if you use shm_open you avoid this apparmor problem
<sborovkov> sergiusens: how do you avoid this problem?
<zyga> sergiusens: right, this is a different system call
<sergiusens> zyga I am just going by the chromium source I read earlier where they don't use shm_open and create a file in /dev/shm instead due to the fact the shm_open is sort of limited on OS X
<zyga> sergiusens: though AFAIR shm_open is terrible and discouraged
<zyga> sergiusens: as there'es no good value for name
<sborovkov> argh, webkit's using it. Oh well.
<sergiusens> sborovkov you should be able to just open("/run/shm/$SNAP/$REVISION")
<zyga> sergiusens: right, because then the name is at least somewhat meaningful and you can control permissions to the file and what not, I'm not sure how it works on osx (/dev/shm)
<sergiusens> sborovkov but yeah, you'd need to patch webkit; is it of the form "org.chromium.Chromium.XXX"?
<sergiusens> that's my current blocker issue today fwiw
<zyga> sborovkov: if it's easy to patch, do it
<sborovkov> sergiusens: sorry, what do you mean about the form "..."?
<zyga> sborovkov: we're definitely going to change what is allowed (to make it more liberal) though jdstrand knows the details
<sergiusens> zyga it really isn't which is why I wanted my proposal to mount in a new namespace to fly :-)
<zyga> sergiusens: I think that's a sensible idea
<sergiusens> zyga jdstrand and about pulseaudio, if hardlinking is supported, I'd just hard link into that path created by the launcher ;-)
<zyga> sergiusens: a fork bomb snap would still work so I would not worry much about how shm quotas should work now
<zyga> sergiusens: I'm not familiar with pulseaudio issues
<sergiusens> but if pulseaudio requires accessing shared memory, I'd say the architecture for pulseaudio is somewhat broken as well ;-)
<zyga> sergiusens: why?
<zyga> sergiusens: it use buffers to share between clients
<sergiusens> zyga look at my email exchange with jamie ;-)
<zyga> sergiusens: where is the excchange?
<sergiusens> zyga yeah, but I could write to other locations and inject into other apps, right?
<sergiusens> zyga mailing list of course, don't you read email anymore? ;-)
<zyga> sergiusens: nah, I'm just not fully up to my inbox zero goal :)
<sborovkov> zyga: sergiusens: so hm can you recommend what calls I should use to replace shm_open with. What's the recommended way (did not deal with lol level IPC for a long time)
<zyga> sergiusens: I moved 500 emails out of the way today
<zyga> sborovkov: one sec
<sergiusens> sborovkov I cannot recommend anything, I am blocked ;-)
<zyga> so I just checked
<sborovkov> zyga: Hmm. From stackoverflow: It just happens that GLIBC places all shared memory objects in /dev/shm or /var/run/shm by prepending the path to the object name and calling open() on the resulting name. That won't create subdirectories though I guess.
<zyga> yeah
<zyga> I just made a demo snap
<zyga> one sec let me publish this
<zyga> I may have a nice solution
<zyga> for all apps
<zyga> give me 10 more minutes, ok
<zyga> s/nice/hackybutworking/
<sborovkov> zyga: sure, thanks for assistance :-)
<jdstrand> sergiusens, zyga and sborovkov: the detail zyga is referring to for making it more liberal is to drop SNAP_REVISION and just use /run/shm/$SNAP/...
<jdstrand> as for dealing with chromium-- still thinking that through
<jdstrand> sergiusens: note, your proposal is not to mount in a new namespace. it is to bind mount (there is a big technological difference)
<sergiusens> jdstrand you are most likely right :-)
<sborovkov> zyga: alright, I gotta go now, I will ask you tomorrow about your solution then
<zyga> almost done :)
<zyga> ha
<zyga> works
<zyga> now for the grand finale
<zyga> let it work with any precompiled app :)
 * zyga loves C
<Chipaca> hiya
<zyga> jdstrand: quick question
<jdstrand> shoot
<zyga> jdstrand: I made shm_open work magically
<zyga> jdstrand: as a LD_PRELOAD or link-time .o
<zyga> jdstrand: but it seems that apps cannot actually create /dev/shm/$SNAP_NAME/$SNAP_REVISION today :)
<zyga> jdstrand: it feels like the launcher should do that
<jdstrand> no
<zyga> jdstrand: do you agree?
<jdstrand> let me double check
<zyga> thank you
<zyga> sergiusens: ^^ if this is fixed I can give you a part that fixes anything
<zyga> sergiusens: using shm_open
<jdstrand> but I think that is right (like with ~/snap/name/version, it was the launcher's job to do that
<jdstrand> but, we can fix that
<zyga> jdstrand: rigth, that's my feeling
<sergiusens> zyga it doesn't use shm_open (chromium, I told you exactly the opposite)
<zyga> sergiusens: oh, I'm sorry what does it use then?
<sergiusens> zyga open
<zyga> sergiusens: ah, directly?!
<zyga> boo :)
<zyga> well, better than nothing :)
<zyga> I'll share my stuff after this session
<jdstrand> zyga: so, I'm ok with having these rules:
<jdstrand> /{dev,run}/shm/snap/@{SNAP_NAME}/ rw,
<jdstrand> /{dev,run}/shm/snap/@{SNAP_NAME}/** mrwlkix,
<jdstrand> zyga: but something will still need to create /{dev,run}/shm/snap
<jdstrand> we could do:
<jdstrand> /{dev,run}/shm/snap/@{SNAP_NAME}/ r,
<jdstrand> and have the launcher create /{dev,run}/shm/snap/@{SNAP_NAME}
<zyga> jdstrand: /dev/shm/snap/$SNAP_NAME or /dev/shm/$SNAP_NAME
<zyga> +1
<zyga> jdstrand: I'll work on this
<jdstrand> zyga: ok
<zyga> jdstrand: how soon can we release a launcher that does /snapname/snaprevision
<zyga> jdstrand: this would work with new snaps (using my trick) without a release of snappy proper
<sergiusens> zyga jdstrand https://chromium.googlesource.com/chromium/src.git/+/master/base/files/file_util_posix.cc#157  and https://chromium.googlesource.com/chromium/src.git/+/master/base/files/file_util_posix.cc#144
<sergiusens> zyga so mkstemp
<zyga> sergiusens: glibc has a way to customize shm_open
<zyga> sergiusens: so too bad it's not used here
<zyga> sergiusens: this will have to be patched :/
<zyga> anyway, one problem at a time
<zyga> sergiusens: thanks for sharing this
<sergiusens> zyga it is not that simple though
<jdstrand> zyga: if we are going to sru that, I'd like to have the seccomp arg filtering as part of that sru to cut down on sru red-tape
<sergiusens> zyga as this code base is spread out in many projects and many projects use their own variant build/fork
<zyga> jdstrand: we should get the blank-ish check though
<zyga> as more and more things will be released
<zyga> jdstrand: but for now I agree
<jdstrand> tyhicks: do you have a feeling for when the seccomp arg filtering will be reviewed?
<jdstrand> zyga: yes (and I requested that for the launcher)
<jdstrand> well, I asked that someone else ask for it
<jdstrand> I think that happened
<tyhicks> jdstrand: hopefully by the end of this week
<tyhicks> jdstrand: is that soon enough?
<jdstrand> tyhicks: cool, thanks
<zyga> jdstrand: maj 03 20:34:13 zyga-thinkpad-w510 kernel: audit: type=1400 audit(1462300453.710:78): apparmor="DENIED" operation="mknod" profile="snap.shm-open-demo.demo-builtin" name="/dev/shm/shm-open-demo/100001/demo" pid=8044 comm="demo-builtin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
<zyga> jdstrand: should this be denied today?
<zyga> ah, I see /dev/shm/snap/
<zyga> sorry for bugging you :)
<zyga> https://github.com/zyga/snappy-runtime-helper/blob/master/snappy.c
<zyga> jdstrand: ^ I'll hack u-c-l and snappy to do what you suggested earlier
<jdstrand> zyga: /dev/shm/shm-open-demo/100001/demo should be denied today. I forgot /dev/shm/*snap*/
<zyga> yep, I noticed that :)
<jdstrand> ah, yes you did :)
<zyga> jdstrand: I patched it to have /snap/ there too
<zyga> jdstrand: one thing I realized is that the launcher doesn't know $SNAP_NAME or $SNAP_REVISION today
<zyga> jdstrand: (it might just use getenv but feels wrong, I'd really just want to know $SNAP_NAME and act on that
<zyga> jdstrand: (to mkdir bits)
<zyga> jdstrand: ah, it seems it does use environment variables, so I guess that's not an issue
<zyga> though that feels wrong :)
<sergiusens> zyga create a part, put it on the wiki
<zyga> sergiusens: good idea
<qengho> Computer: "cannot get discharge macaroon from store"    Me: "Oh, right. Of course"
 * zyga still doesn't know what discarge there means
<qengho> My new band name is DISCHARGE MACAROÃN.
<mvo> qengho: could you please check if there was maybe a typo in the username/password?
<mvo> qengho: and yeah, the error message needs some love
<ogra_> Just rename it to 'boom!'... Has about the same amount of info, but is funnier
<gblanchard4_> Can you expose multiple commands in the snapcraft.yaml?
<sergiusens> yes gblanchard4_
<qengho> Sure. New sections.
<sergiusens> it is a a dict
<qengho> I was making a snap in one place. I disconnected. Resumed at home. Now, running the snap says "Bad system call
<qengho> ". I can't think of any other change than the network in use.
<qengho> I know that sounds crazy.
<qengho> That is, I moved my laptop from one place to another. Same machine. The "wget" run in my snap package fails now with "Bad system call".
<qengho> I haven't updated snap deb in the last week or so.
<qengho> Could it be some problem with the seccomp filter not being fully un-installed or something, between "snap remove/install" runs?
<zyga> qengho: probably one of the bugs in 2.0.2
<zyga> qengho: I hope we release 2.0.3 soon (today?)
<zyga> qengho: also there's a known bug in 2.0.2 when you install a snap a few times (during development)
<qengho> zyga: I think I've been careful to remove first. I think that avoids it.
<gblanchard4> qengho: Thanks, I will give it a try!
<zyga> yes
<qengho> Next question: Can I find out what syscall failed?
<Kamilion> qengho: sysdig can probably drill down to answer that for you.
<sergiusens> qengho dmesg | grep <snap>
<sergiusens> qengho scmp_sys_resolver against sig
<Kamilion> you'd need dkms and root access to the machine for sysdig; however. csysdig is the curses frontend, switch to the system call view.
<qengho> sergiusens: I only see apparmor lines, no seccomp.
<Kamilion> then drill down to failed system calls and look which processes are unhappy
<sergiusens> qengho are you maybe looking at old logs then?
<qengho> fresh out of "dmesg"
<sergiusens> or you may have been hit by kernel rate limiting
<qengho> Eh, no.
<sergiusens> qengho ph plain "Bad system call", maybe binary from a different arch?
<sergiusens> s/from/for/
<jdstrand> sergiusens, qengho: note bug #1567597. if you are using --devmode there is no logging of seccomp violations
<ubottu> bug 1567597 in Snappy "implement 'complain mode' in seccomp for developer mode with snaps" [Medium,Confirmed] https://launchpad.net/bugs/1567597
<qengho> sergiusens: I built it here, no special flags or compiler.
<qengho> jdstrand: Not using devmode.
<jdstrand> ok
<zyga> hmm
<zyga> jdstrand: is there a way to get a core file from a crashing app?
<zyga> using pulse in snappy (even with --devmode) crashes all the stuff I try
<qengho> I think I can make it go somewhere with proc core pattern.
<sergiusens> zyga ulimit -c unlimited
<zyga> (pulseaudio)
<zyga> thanks!
<zyga> I got a game working
<qengho> Oh.
<zyga> though without sound for now :)
<zyga> got it :-)
<qengho> I swear, this started its "Bad system call" when I moved locations.
<qengho> I'm renaming package to see what happens.
<zyga> hmm
<zyga> #0  __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:60
<zyga> #1  0x00007fc06ed8d4ce in __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:1987
<qengho> zyga: Athlon?
<zyga> no :)
<zyga> core i7
<zyga> same binary works outside
<zyga> (this is scummvm)
<Kamilion> ah, I was wondering. Interesting.
<zyga> I suspect a null pointer somewhere
<jdstrand> zyga: I don't know. I do know mvo had gdb, etc working in snaps at one point
<zyga> I'll build scummvm from source with debug
<zyga> jdstrand: hmm, you just gave me an idea :)
<zyga> actually
<zyga> my idea is to go to sleep for a change
<yofel> so, I started looking at https://developer.ubuntu.com/en/snappy/build-apps/get-started/, but apt tells me "E: Unable to locate package snappy-tools" - what am I looking for instead?
<josharenson> Is there an https server available as a snap?
<jdstrand> zyga: I like that idea :)
<zyga> (and here I am, replying to email)
<almejo_> Hi every one. I need help packaging an app. My app is packaged and installed. But the app does not start. It onlly throws "XmbTextListToTextProperty result code -2" in the console. Is a python qml app.
<nealmcb> I want to put snappy ubuntu core on my raspberry pi 2.  but at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ I see instructions for 15.04.  Should I ignore that and use e.g. http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz ?
<almejo_> I forgot to tell exactly the problem. The app does not appears. I have no gui :(
<qengho> nealmcb: I don't think there are any good rpi images right now.
<nealmcb> qengho: i.e. 15.04 is the latest good one?  Or even it isn't good?
<nealmcb> and what is the story for the raspberry pi 3?
<qengho> nealmcb: 16.04 could be good, theoretically, but I don't think any current image is. Just a fluke today.
<nealmcb> what sort of fluke today?
<josharenson> nealmcb: I installed snappy (as opposed to 16.04 server) on my pi2 last night just fine
<josharenson> nealmcb: ah qengho makes an interesting point
<nealmcb> josharenson: which image?  The one I pointed to?
<Kamilion> nealmcb: I think flexiondotorg was working on various pi images, but I don't think there's any ubuntu-core images that I'm aware of for xenial at the moment.
<jdstrand> kgunn: I read your bug report for slot connect. are you at least able to manually connect the permanent slot side?
<josharenson> nealmcb: No its a 15.04 image
<Kamilion> I know snapd has one available
<josharenson> nealmcb: ubuntu-15.04-snappy-armhf-raspi2.img.xz
<jdstrand> kgunn: or is it basically not being added until a connection with a client?
<Kamilion> (for xenial)
<zyga> Kamilion: xenial core images are not finished yet
<zyga> Kamilion: I think we will offer developer preview images soon but I think this will only take shape next week
<ogra_> There are experimental ones for all arches but you will have to wipe them soon
<Kamilion> so then what's ubuntu-core 16.04+20160419.20-55 ?
<Kamilion> ah, okay
<zyga> Kamilion: where did you get it from?
<Kamilion> thanks, ogra_
<ogra_> so it isn't rally worth releasing them until they are upgradeabl
<ogra_> e
<Kamilion> zyga: snapd?
<zyga> Kamilion: that's the core snap
<zyga> Kamilion: that's not the whole image, the whole image has a kernel and a gadget
<Kamilion> ah
<zyga> Kamilion: we're still working on those parts
<Kamilion> gotcha
<zyga> Kamilion: on 16.04 you are using the kernel from the classic ubuntu
<Kamilion> yes, I am
<ogra_> http://people.canonical.com/~mvo/all-snaps/
<zyga> Kamilion: on a board like the raspberry pi 2 you would need a complete snap-based image and those will be available in a few weeks from now
<Kamilion> and only the pi2 and 3's CPU will be supported, ARM7 yadda yadda
<zyga> right now we only have previews that may need to be re-flashed entirely sometimes
<ogra_> there are the experimental ones... But you will have to re-flash...
<Kamilion> no pi1, that's for rasbian to deal with, basically. (as far as I can tell)
<ogra_> pi3 will get a community supported image, like the bbb
<Kamilion> are the images going to be available before the first point release of xenial in juneish?
<ogra_> pi2 will be officially supporte
<Kamilion> oh, I've got a BBB, I should give that a shot.
<zyga> Kamilion: juneish?
<ogra_> around 16.04.1
<zyga> Kamilion: anyway, I think we will have images "in a few weeks"
<ogra_> I guess
<zyga> so weeks, not months
<zyga> 16.04.1 is released after 16.10
<ogra_> well, 8weeks are two months :)
<Kamilion> last I heard from #ubuntu-release during the 20th to 25th when I was paying attention, the first point release was supposed to be june
<zyga> ogra_: hush ;)
<ogra_> zyga huh?
<zyga> ogra_: still I hope this will be less than two months :)
<zyga> ogra_: just kidding, sorry
<ogra_> .1 will definitelyvrelease before 16.10
<qengho> July, I think.
<ogra_> unless the release schedule got totally changed
<zyga> Kamilion: perhaps I remember incorrectly but 14.04.1 was done after 14.10
<ogra_> yeah
<zyga> anyway, sorry, I may be wrong here
<ogra_> should be in july
<ogra_> and I guess stablebsnapoy will be broad the same time
<Kamilion> zyga: yes, that was the case, 14.xx's point releases were far between
<zyga> (and it containled LTS enablement packages)
<ogra_> stable snappy
<Kamilion> I think 16.04 is getting more rapid updates
<zyga> ah, I wasn't aware of that
<zyga> thanks!
<Kamilion> or at least an early point release to deal with some post-release problems
<ogra_> .1 is always early
<Kamilion> like the llvm-3.8 issues
<ogra_> usually hew comez with .2
<ogra_> hwe
<ogra_> god !!!!
<ogra_> the auto correction is killing me
<nealmcb>  
<Kamilion> wow, fun, ZNC with a bunch of clients, just like me. heh.
<nealmcb> Great - thanks folks!
<kgunn> jdstrand: well, i just cleaned up my client project...and was working on pushing aroud the i/f to be "connected" slot vs permanent
<zyga> kgunn: how do you setup your VM, perhaps I can reproduce your setup and aid you somehow?
<kgunn> zyga: https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<edsiper> ogra_, what's the procedure to flash de Dragonboard ?
<kgunn> thanks for attempting, and let me know if you have questions
<zyga> kgunn: huh, that's nothing special?
<zyga> kgunn: does qemu work?
<zyga> kgunn: I should be able to run this with regular devtools setup with a simple tweak
<kgunn> yeah, i hadn't tried with any other vm's...so it might be fine
<ogra_> edsiper: just uncompress and dd to an sd card ... flick the SD switch on the bottom of the board and you should be good to go
<zyga> kgunn: which vm software are you using there libvirt uses kvm inside?
<zyga> kgunn: anyway, I'll check that tomorrow, I suspect this can be x10 easier and faster with devtools-based setup and ephemeral VMs it is using
<kgunn> zyga: info says hypervisor:kvm emulator:/usr/bin/kvm-spice
<zyga> that's great then
<edsiper> ogra_, is this one functional ? http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz
<zyga> will work just as well with qemu :-)
<edsiper> great
<zyga> kgunn: I'll ping you tomorrow, for now I have to look after my kids
<ogra_> should  be, yes ... you will need to create a wlan0 file etc
<kgunn> o/ enjoy zyga
<ogra_> (to get ssh access)
<qengho> before: https://pastebin.canonical.com/155727/     after: https://pastebin.canonical.com/155726/
 * zyga has a real backtrace 
<zyga> https://paste.gnome.org/pp7ej1hyn
<zyga> sergiusens: do you have any hints on stage-packages and -dbg packages for symbols
<zyga> sergiusens: should I build libsdl myself and just overwrite the bits in snap/ manually for hacking (like I did with scummvm executable)
<zyga> sergiusens: or is the a better magic way to get non-stripped libraries
<gblanchard4> Are underscores and periods not allowed in the YAML? i.e. in the apps section
<zyga> gblanchard4: they are not allowed
<zyga> gblanchard4: juse use dashes, most apps don't use dots and we use them internally so they are reserved
<gblanchard4> zyga: Okay, thanks for the information. I was trying to figure out why my yaml failed validation.
<zyga> gblanchard4: snapcraft should also check that, I think
<gblanchard4> zyga: I am trying to port some python based bioinformatics software to alleviate dependency hell. I was trying to make it as seamless as possible. Most of the scripts use the underscore convention i.e. print_config.py
<zyga> gblanchard4: remember how snap apps are exposed
<zyga> gblanchard4: in general each app is named: $snap.$app (e.g. biosoftware.something)
<zyga> gblanchard4: when you have many scripts you can improve their names based on this knowledge
<zyga> gblanchard4: you can run print_config.py from a command called print-config
<zyga> gblanchard4: the command name is not the same as the file / command it runs
<gblanchard4> zyga: Thats a great point!
<zyga> gblanchard4: also note that if the app name is the same as snap name we don't do foo.foo, the resulting executable is just "foo"
<zyga> gblanchard4: so if there's any "main" program in your snap that would be the way to expose it
<gblanchard4> zyga: Ha, I learned that the hard way by accident. It's really a collection of python scripts, no "main".
<zyga> gblanchard4: are they CLI tools?
<gblanchard4> zyga: yes
<gblanchard4> zyga: I use a lot of python based CLI tools. The are currently all in separate virtualenvs, but many rely on more than just python (usually some R packages too). I think snaps are a great idea to help me keep everything separate.
<zyga> https://paste.gnome.org/piq8y6ony
<zyga> definitely pulseaudio related
<zyga> the crash is in #2  0x00007f0a75f17fe6 in PULSE_SetCaption (this=0x22b3460, str=0x0) at ./src/audio/pulse/SDL_pulseaudio.c:394
<qengho> Oh man, no "source:" for merely downloading a file? Ugh.
<zyga> the root cause is null pointer coming from         SDL_WM_GetCaption(&title, NULL);
<zyga> which smells X related
<zyga> ha
<zyga> found the root cause :)
<zyga> heh /proc related (obviously)
<zyga> and also a bug in sdl1.2
<zyga> just last build before EOD
<zyga> woot
<zyga> I have a working snap for flight of the amazon queen
<zyga> sergiusens: I fixed a bug in sdl that probably (99%) affects each SDL game
<zyga> resulting in a crash
<ZenHarbinger> I have a question about running a Java Swing application deployed via snap: https://askubuntu.com/questions/764496/developing-a-snap-package-for-a-project-using-java-swing
<ZenHarbinger> namely, it doesn't run
<zyga> ZenHarbinger: hey, I replied to your question
<zyga> ZenHarbinger: can you pastebin snap interfaces please
<ZenHarbinger> you mean the output?
<ZenHarbinger> from snap interfaces?
<qengho> Yes.
<ZenHarbinger> I listed it at the link:
<zyga> ah, I see now
<zyga> can you look at syslog and pastebin the DENIED lines
<zyga> I suspect this is getpeername or something like that I fixed this for 2.0.3 already
<zyga> but let's see
<qengho> "snap justlikeapportcollect
<zyga> ZenHarbinger: just pastebin the whole syslog if you don't know what to look for
<ZenHarbinger> http://pastebin.com/incCe8d0
<ZenHarbinger> sorry, had to run it
<zyga> ZenHarbinger: https://bugs.launchpad.net/snappy/+bug/1574526
<ubottu> Launchpad bug 1574526 in Snappy "x11 plug doesn't allow getsockname, breaks xeyes" [High,Fix committed]
<zyga> this is already fixed
<ZenHarbinger> awesome, so just wait? ok.
<qengho> (Note, not "Fix released")
<zyga> mvo will release 2.0.3
<zyga> then you will need to reinstall (or disconnect and reconnect x11) the snap
<zyga> and it should work
<ZenHarbinger> Great! Thanks guys!
<zyga> :-)
<zyga> ZenHarbinger: (please update the question on ask ubuntu if you can)
<zyga> sergiusens: https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/1577986
<ubottu> Launchpad bug 1577986 in libsdl1.2 (Ubuntu) "SDL 1.2 crashes on snappy, breaks scummvm" [Undecided,New]
<qengho> zyga: Do we have a list of "tentpole" apps that we expect to be able to snap as a prerequisite for declaring v2 released?
<zyga> qengho: v2 of what?
<zyga> qengho: snapd 2.0.2 was released on the 21st or something close to that
<qengho> Well, whatever we release as snappy. Not "2", but "come, all, snappy is ready for you". The number is not important.
<zyga> qengho: ah, I see
<zyga> qengho: sprint topic
<qengho> Ah.
<zyga> qengho: I don't have any lists yet though I actually proposed we run with one :)
<qengho> Agreed.
<zyga> qengho: for desktop apps and some unspefied use cases for devices
<qengho> If you want one that's ambitious and not quite crazy, I will upload my "Kodi" snap branch.
<qengho> zyga: Go offline already! :)
<zyga> qengho: desktop will see ongoing progress, I'd say that the idea is we will release new interfaces (and updated interfaces) each fortnight to remove blockers from snapping some high-profle apps
<zyga> qengho: but also remember that some desktop things are very hard because everything is closely coupled
<qengho> Don't I know it.
<zyga> qengho: so I don't know if we'll succeed quickly
<zyga> (with kodi :)
<zyga> anyway, afk :)
<zyga> good night
<qengho> Good night.
<zyga> (I said that three times already)
#snappy 2016-05-04
<josharenson> I have a python script that is a wrapper for my build process. I'm currently using cmake as my plugin and my CMakeLists.txt just calls execute_process on the python script. This is stupid. Should I just make the plugin python and name my script setup.py even though its not really a python module?
<josharenson> I guess I could use make too...
<josharenson> ^^ that actually worked pretty well
<qengho> josharenson: Are you distributing some python, or something made with python?
<josharenson> qengho: something made with python
<qengho> I'd "build-packages" python, instead of "plugin: python". I think so. Not sure.
<josharenson> qengho: Yeah I added python as a build-package and made this http://pastebin.ubuntu.com/16209847/ my makefile
<josharenson> seems reasonable
<qengho> Cool!
<josharenson> qengho: yeah, thanks
<qengho> You probably get a smaller package than with plugin-python.
<ZenHarbinger> BTW, I did update the answer on askubuntu. that is all. 'nite!
<sergiusens> elopio the last one https://github.com/ubuntu-core/snapcraft/pull/499
 * sergiusens goes to bed
<elopio> good night.
<swami> hi
<swami> can someone help answer this question, posted in the dev mailing list? https://lists.ubuntu.com/archives/snappy-devel/2016-May/001802.html
<example6> Hi guys. I'm trying to build a snap that just runs a shell script that runs a pre-built executable made for a specific system. Right now I'm just using the 'make' plugin to copy my files and wrapper into place, and I've added daemon: simple and my wrapper as a run command but it doesn't seem to be starting when I install or reboot. Any advice on making this happen?
<example6> I can't seem to find any documentation on it
<zyga> good morning
<slvn> hello!
<slvn> no bug report for today :)
<slvn> just a question, I was wondering the signication, when publishing a snap, of "series : 15.04/rolling core, 16, rolling core" ?
<zyga> slvn: well, it where is your snap going to work?
<zyga> slvn: you should go with 16
<zyga> slvn: that's "stable", that s what people will get
<slvn> zyga, ok, it makes sense, that's what I chose
<slvn> zyga, btw, I published a basic snap app, using SDL2, with SDL2 log debug enabled. may be useful for testing...
<zyga> slvn: what is the name of the snap?
<slvn> zyga, tic-tac-toe . At first, this is a mobile game, but it runs also on desktop.
<slvn> (it's more like a testing sample for me, than a real app)
<noizer> zyga: Hi I installed my rpi1 and looked if it is soft floating but it is hard floating how can that be?
<zyga> it cannot
<zyga> how did you check that?
<noizer> they told me to look in the /lib dir
<noizer> and there you can see arm-linux-gnueabihf
<noizer> zyga or is there a way too see it better?
<zyga> no, you seem to be right, one set
<zyga> though not all is lost
<zyga> you should be able to run an armel chroot now, let me show you how to make one
<noizer> ok
<zyga> noizer: trying now
<noizer> zyga Ok :p
<zyga> geez pi1 is slow like hell
<zyga> it's happening, just ... ... ... slowly
<noizer> zyga I know thats not realy fun
<zyga> (in other news debootstrap is written in perl, perl is slow)
<noizer> Maybe a other question about it. When I'm developing further on this application can i compile it then on the rpi3 or rpi2?
<zyga> as long as you are in the armel chroot, yes
<noizer> awesome :D
<noizer> then it will be faster to compile on the armel chroot :D
<zyga> noizer: anyway, you can give this a try, sudo debootstrap --arch=armel sid armel
<zyga> noizer: this will create the directory "armel" with a debian chroot
<noizer> debootstrap command not found :s
<noizer> zyga how long does it take for debootstrap?
<zyga> noizer: on pi1 ~ hour
<zyga> on pc ~ minute
<noizer> does we need to make it on rpi1?
<zyga> yes
<noizer> pfff hate that
<zyga> it's possible to do on pc but stage 1/2 stuff is more complicated and you need to finish a lot of the slow part on the real hw anyway
<noizer> zyga ok np i'll wait
<noizer> zyga and  still busy with you?
<mvo> ogra_: hm, what is up with livecd-rootfs in ppa:snappy-dev/image - can those changes get merged to trunk?
<ogra_> mvo, sure ... thats effectively only the addition of uboot-tools to all arches (everything else was reverted again ...
<ogra_> note that we still dont have an x86 uboot gadget, so we still dont know if uboot on x86 will work with the changes we did
<mvo> ogra_: ok
<mvo> ogra_: I have a trivial change for the new kernel spec :)
<mvo> ogra_: I commited to trunk already and merged your stuff and uploaded, I was just surprised at first
<ogra_> mvo, well, we dont use trunk in xenial ...
<ogra_> (and i have set yakkety builds to manual, dailies come from xenial currently)
<ogra_> (for cdimage that is)
<mvo> ogra_: we use the ppa version in the xenial ppa, that is what you are saying, right?
<ogra_> mvo, or if we delete that we use the xenial version from the xenial archive :)
<ogra_> xenial images use the xenial livecd-rootfs ... we'd have to SRU the changes like with any other package
<ogra_> thats what i mean ...
<mvo> ogra_: *cough*
<ogra_> *grin*
<noizer> zyga: its done ove rhere
<zyga> noizer: cool, chroot away
<noizer> zyga ps how can i see its succesfully done?
<zyga> noizer: if id crashed you'd know
<noizer> because i got some warnings
<zyga> like?
<noizer> W:Failure while installing base packages
<noizer> ...
<zyga> anything more?
<noizer> wait I will send you a picture
<zyga> I recommend ssh, you can copy paste stuff
<zyga> but a photo works too
<noizer> haha i didn't use this time ssh
<ogra_> and for taking the photo, we recommend using an ubuntu phone
<ogra_> :)
<noizer> hehehe I want the new ubuntu phone
<zyga> you can then scp the photo off the phone :)
<noizer> do you got an ubuntu phone?
 * ogra_ has three ... and just ordered the MX5pro last week
<ogra_> (but i used to work on the phone team before snappy :) )
<noizer> http://imgur.com/Inp1Qm7
<noizer> ogra_: ooh is it good the new ubuntu phone?
<ogra_> can you push the bootstrap.log file somewhere ?
<ogra_> noizer, i can tell you once i have it in my hands :)
<noizer> ogra_: oooh ok xD
<noizer> ps i try to push it
 * ogra_ hopes it arrives before the sprint ... but my hopes are low
<zyga> brb
<ogra_> wait, are you trying to bootstrap armel on an armhf machine ?
<noizer> http://pastebin.com/h0nBVQc8
<noizer> on the raspberry pi 1
<ogra_> cannot copy extracted data for './usr/share/man/man1/req.1ssl.gz' to '/usr/share/man/man1/req.1ssl.gz.dpkg-new': failed to write (No space left on device)
<ogra_> there is your issue
<noizer> omg
<noizer> thats 8gb of space and not enough omg
<noizer> or does i need to expand it maybe
<ogra_> check with "df -h"
<noizer> ogra_:  dammed only 4gb
<noizer> how can i expand it easily?
<ogra_> is that a snappy install ? +
<noizer> raspbian
<ogra_> ah
<ogra_> no idea then ... i'D try with gparted
<ogra_> (on the PC )
<noizer> yea thats the way I always do it
<zyga> noizer: there's something in raspi-config AFAIR
<zyga> yep
<zyga> sudo raspi-config
<zyga> pick the expand filesystem option from the menu
<noizer> debootstrap is started again
<kyrofa> Good morning
<sergiusens> good morning everyone!
<sergiusens> mvo so follow up from my apt issues, this fixes it https://github.com/ubuntu-core/snapcraft/pull/499
<zyga> jdstrand: hey
<kyrofa> sergiusens, meet in 30?
<noizer> zyga can you tell me the following steps (raspi is still busy but i can prepare myself then)
<zyga> noise][: bind mount /proc and /sys into the chroot, chroot inside, try to build your app
<noizer> zyga chroot /path/to/dir
<noizer> is it that you mean
<noizer> of coure after bind mount ...
<sergiusens> kyrofa maybe 45?
<kyrofa> sergiusens, sounds good
<zyga> noise][: chroot armel; if you followed the command I used earlire
<noizer> Ok
<noizer> hopefully is he almost done he is now reloving dependencies of base packages :s
<ogra_> re loving :)
<ogra_> love it back !
<noizer> ogra_: hahahah xD sorry resolving :p:p
<ogra_> :)
<zyga> that reolves the situation
<noizer> how is the ubuntu summit?
<zyga> good
<zyga> I always like the fact that UOS is recorded
<zyga> UDS was fun but if you weren't there, you lost 90% of it
<zyga> UOS is more egalitarian
<noizer> heheheh xD
<jdstrand> zyga: hi! :)
<zyga> hey, good morning :)
<jdstrand> good afternoon :)
<zyga> jdstrand: I have an intereting bug, I have no idea what the cause is: https://bugs.launchpad.net/snappy/+bug/1578091
<ubottu> Launchpad bug 1578091 in Snappy "Unable to read /proc/$$/cmdline, even with devmode" [Undecided,New]
<zyga> jdstrand: this breaks sdl (which I already fixed) but I wonder why this happens
<jdstrand> let me check something
<jdstrand> zyga: to be clear, the profile is otherwise in complain mode, it is loaded in the kernel and you are seeing an apparmor denial?
<zyga> yes
<zyga> no
<zyga> not apparmor denial
<zyga> I jus get EPERM
<zyga> just run hello world and cat it
<zyga> that's why I don't get it:)
<jdstrand> what are the permissions on the file?
<zyga> maybe /proc mount point something
<zyga> r-r-r-
<zyga> they are not the problem
<zyga> no idea :)
<jdstrand> zyga: can you access the file outside of confinement?
<zyga> yes
<jdstrand> ok, we have an explicit denial for that
<jdstrand> deny @{PROC}/@{pid}/cmdline
<jdstrand> I will need to talk to tyhicks or jjohansen on what complain mode is supposed to do wrt explicit denies
<jdstrand> they'll be online a bit later
<jdstrand> zyga: does the app work ok without it?
 * jdstrand would think it is a bug in complain mode that it is enforcing an explicit deny
<jjohansen> jdstrand: explicit denies override complain mode. Basically complain mode only applies to that which there isn't a rule for.
<jdstrand> ok, I see
<jdstrand> jjohansen: good morning-- I wasn't expecting you here now :)
<zyga> no, it crashes
<dholbach> sergiusens, kyrofa: will you be able to run the "how to snap your software" session later on yourself?
<zyga> jdstrand: btw, why is this deny working even in complain mode
<dholbach> it looks like I'm double-booked and would need to go to the CoC review session as well
<jjohansen> zyga: because complain mode only applies to denials that are caused by missing rules, not for rules that already exist
<zyga> ah, I see, thank you
<sergiusens> dholbach we need a secretary
<sergiusens> :-P
<sergiusens> dholbach if you cannot I guess we have no choice, right? :-)
<dholbach> sergiusens, theoretically it should just be a matter of setting up a hangout-on-air in your canonical account (if you have more than 10 participants) and adding the youtube link to summit
<dholbach> sergiusens, if all else fails, I'd need to follow up with the CC on the CoC over email later on
<jdstrand> zyga: ok, so if we have crashes then we should remove the explicit deny. I'll update the bug and assign to me.
<zyga> jdstrand: thank you
<zyga> jdstrand: if it is on the snappy side I can quickly remove that denial
<zyga> jdstrand: I didn't look yet
<jdstrand> zyga: I'd prefer the PR came from me (it is on the snappy side) since I want to update the comment, reference a bug, etc. I have a couple other things I want to adjust in the policy too. I can get to it today
<zyga> sure, thank you :)
<jdstrand> np
 * zyga goes to send the fix to SDL upstream
<dholbach> sergiusens, kyrofa, hum... same for the "snapcraft roadmap" session :-/
<kyrofa> dholbach, understood. sergiusens do you have experience setting up the hangout-on-air?
<kyrofa> dholbach, does that require a G+ account associated with the Canonical email?
<sborovkov> zyga: Hello, did you succeed yesterday with your solution for shared memory?
<dholbach> kyrofa, it can be your personal account as well if you don't plan to have more than 10 attendees
<zyga> sborovkov: yes but it is so hacky that we'll work on a better solution that doesn't require code modification
<zyga> sborovkov: as right now the "solution" requires snappy changes, ubuntu-core-launcher changes and a small helper library (I've published it at. ... )
<zyga> sborovkov: I'll open a bug and collect all the details there
<sborovkov> zyga: Oh. That's a lot of things. Is the proper solution going to be any time soon?
<zyga> sborovkov: https://github.com/zyga/snappy-runtime-helper (though it's not useful really)
<zyga> sborovkov: at around sru-2
<zyga> sborovkov: ~2 weeks
<zyga> +/- a week
<sborovkov> zyga: got it
<dholbach> kyrofa, looking for the link to the docs right now
<zyga> sborovkov: I hope to have it merged before
<zyga> sborovkov: this is the release time
<dholbach> kyrofa, sergiusens: https://wiki.ubuntu.com/UDS/Sessions :)
<zyga> sborovkov: you can look at what my hack does above
<kyrofa> dholbach, alright I can do it in that case (I already had a personal G+ before Canonical, and google doesn't let you merge them or anything)
<zyga> sborovkov: but you will still need to change ubuntu-core-launcher to mkdir a directory for you
<zyga> sborovkov: so that's a bit not optimal
<sborovkov> zyga: understood
<dholbach> kyrofa, sergiusens: you might have to change to the classic interface of Google+
<dholbach> kyrofa, sergiusens: thanks guys - I'm sorry, but I just got dragged into the other meetings
<kyrofa> dholbach, hey, you're an important guy!
<dholbach> kyrofa, you too! :-)
<sborovkov> zyga: can you post me the issue url when you create it, so I can keep track of this
<kyrofa> dholbach, and no problem :)
<zyga> sborovkov: gladly, I was actually getting started on this
<sborovkov> thanks
<kyrofa> dholbach, should I just give you the URL so you can update summit, then?
<dholbach> kyrofa, you should be able to put it into "edit hangout details" on the session page in summit
<dholbach> but I can do it for you too
<dholbach> what's the link?
<kyrofa> dholbach, all I see is "skip this session," so I must not have that capability
<kyrofa> dholbach, can you give it to me?
<dholbach> oh ok
<dholbach> I set your attendance to required and thought that would do it
<dholbach> just give me the link and I'll add it for you
<dholbach> not sure what the issue is :-/
<jdstrand> zyga: did you do the snappy side of SNAP_REVISION for shm? I'm in that file now and can do it as part of my PR if you haven't
<zyga> jdstrand: one sec
<zyga> jdstrand: I'm filing the bug now
<zyga> jdstrand: we need to fix it buy you can reference a (good) bug :)
<zyga> jdstrand, sborovkov: https://bugs.launchpad.net/snappy/+bug/1578217
<ubottu> Launchpad bug 1578217 in Snappy "No way to use shm_open(3)" [Undecided,New]
<dholbach> kyrofa, do you have the youtube link?
<kyrofa> dholbach, event page: https://plus.google.com/events/cosa4a1b1rr2vv0kfiei60jq424
<jdstrand> zyga: ok, I'll do the policy part of that
<kyrofa> Oh youtube: http://youtu.be/ME_pLU9GMfo
<zyga> jdstrand: great, thank you
<dholbach> kyrofa, http://summit.ubuntu.com/uos-1605/meeting/22683/the-snapcraft-roadmap/ is updated O:-)
 * zyga does a strong coffee in anticipation of UOS
<dholbach> kyrofa, teamwork âµ
<kyrofa> dholbach, thank you! I'll ping you again for the next one :)
<zyga> jdstrand: we should think about support for refreshing rules across sru updates
 * dholbach hugs kyrofa :-)
<dholbach> thanks!
<zyga> jdstrand: my code that originally did this was rejected and we need a nice and elegant solution
<zyga> jdstrand: (for stuff that changes in template.go)
<jdstrand> yes
 * kyrofa hugs dholbach back :)
<sergiusens> kyrofa you got it, right? sorry was distracted!
<kyrofa> sergiusens, no problem, yeah all set
<sergiusens> kyrofa sort of
<sergiusens> kyrofa forgot to check my hair
<sergiusens> kyrofa where is the link to join?
<kyrofa> sergiusens, hahaha, I just did the same
<elopio> good morning.
<jdstrand> zyga: well, that shm bug is asking for more than what I thought it was. I was just going to chop off SNAP_REVISION
<jdstrand> zyga: please see my comment
<zyga> checking
<jdstrand> I imagine that pulseaudio will create the files underneath the bind mount and the client would never see them
<zyga> jdstrand: hmm, you are right
<jdstrand> zyga: we could instead allow creating files in the directory under an app-specific name
<zyga> jdstrand: I'll test this with near-real changes, what I did was to mkdir the missing directories manually and to *not* adjust the policy but to use my hacky preload library (linked from the bug)
<jdstrand> eg, /dev/shm/<snapname>.*
<zyga> jdstrand: I'm not sure if it is the pulse client or server making those files in /dev/shm (in general) though, if it is the client and it shares the path via X11 ipc then we're in trouble
<jdstrand> I have no idea
<zyga> but without the bind mount it would mean that we need something like my preload helper to make this work which seems wrong
<zyga> but I'll develop this further before we commit
<jdstrand> I think we are introuble either way
<zyga> yes, I fear you might be right
<jdstrand> cause if the server creates it, it is under the mount and if the client creates it, it is in /dev/shm/snap/... (and the server won't know about it)
<jdstrand> zyga: did you see my comment? we could allow app-specific names in the top level
<zyga> jdstrand: we could ask someone that knows pulseaudio (or check ourselves); the problem is that we should not make this pulse specific :/
<zyga> app-specific names won't work, many apps use a random ID
<jdstrand> zyga: no, pulseaudio is but one example I know of
<jdstrand> zyga: this is getting into an area where apps are going to need to work with the system. ie, they can't read arbitrary stuff our of /etc either
<jdstrand> or write all over $HOME
<zyga> jdstrand: yes, we should just estimate what is the better approach
<zyga> jdstrand: let me do some more experiments
<zyga> jdstrand: I'll check iff the bind mount would work
<jdstrand> traditional apps are always going to butt up against the sandbox in some ways
<zyga> jdstrand: with pulse
<zyga> jdstrand: and if the top-level one would work as you suggested
<jdstrand> ok
<zyga> jdstrand: thanks for the insight, I totally didn't think about this
<jdstrand> zyga: note the top-level one is obviously so we don't use a bind mount
<zyga> right
<jdstrand> ok, I'll leave this bit alone for now
<zyga> sborovkov: what was the app you were interested in? webkit?
<sborovkov> zyga: yes
<zyga> sborovkov: thanks
<jdstrand> chromium also suffers from this
<jdstrand> zyga: note, on touch we allowed .org.chromium.Chromium.*. we could do the same for webkit and then also allow /dev/shm/snap.$SNAP.*
<zyga> do you know if chromium was patched?
<jdstrand> zyga: as a stop-gap until we get fuller apparmor mediation of shm
<zyga> if it was then we can allow anything sane, if it *wasn't* patched then I'm interested in the technical bits that made it work
<jdstrand> zyga: on Touch we provide oxide. our oxide was not patched to an app-specific patch (though it could/should have been)
<jdstrand> zyga: the technical bits was that we allowed the path it (ie upstream) wanted
<zyga> mmm
<jdstrand> ie, we punted on Touch until we had fuller apparmor mediation of shm
<zyga> I see
<zyga> OK
<jdstrand> so we have a choice to do the same here or to force devs to adjust their apps
<jdstrand> assuming your bind mount investigation doesn't pan out
<zyga> btw, the pulse exercise, I suspect that the snapped pulseaudio and deb-based pulseaudio would work makes the exercise more interesting
<zyga> right?
<jdstrand> snapped pulseaudio could not work I don't think cause its files would be in its snap-specific area that is not shared by the client's snap-specific area
<jdstrand> unless we did some brittle heroics
<jdstrand> I can't quite see how those heroics would work
<ssweeny> is there a way to stop/start/restart a service within a snap?
<sborovkov> ssweeny: systemctl?
<jdstrand> maybe if there was a 'pulseaudio' dir in /dev/shm, then pulseaudio has a bind mount for it, so its writes to /dev/shm/pulseaudio... but that is really /dev/shm/pulasudio/pulseaudio.... then all the apps bind mount with passthrough /dev/shm/pulseaudio/... I'm not sure. this is getting weird
<jdstrand> sborovkov: that won't work. apps can't use systemctl
<jdstrand> ssweeny: you are free to stop and start daemons within your snap via signals, scripts, etc, but not systemctl
<ssweeny> hmm
<jdstrand> ssweeny: I suggest writing out a pidfile to $SNAP_DATA and then sending HUP or similar
<zyga> ssweeny: proper API for service management is coming in a few weeks
<ssweeny> ah, I see
<zyga> ssweeny: we removed the older API because it had the wrong abstractions
<zyga> ssweeny: more news after the sprint next week
<jdstrand> zyga: are you talking about the snapd API for 'snappy service' that was removed?
<zyga> yes
<ssweeny> jdstrand, zyga, ok I can work around until the API is updated
<ssweeny> thanks!
<jdstrand> zyga: note, 'snappy service' couldn't be used by snaps to manipulate there snaps either
<zyga> jdstrand: that's true, unless they had snapd-control
<jdstrand> I can see that a properly designed API could be used
<jdstrand> but snapd-control gives away way too much currently
<ssweeny> my use case is that I have a runtime test fixture that stops the currently-running service and starts its own copy then when the test finishes it restarts the installed service
<jdstrand> snapd could be designed to allow safe APIs though
<zyga> jdstrand: yes, that's a good point
<ssweeny> it'd be useful to expose that in a snap for developers but not critical
<zyga> jdstrand: could use the peer info to allow self-managemnet
<jdstrand> yes
<jdstrand> but probably would need a safe socket and an unsafe socket and then have two different interfaces, one that anyone can use and one not
<davidcalle> jamiebennett: thanks for the reports on the snapcraft doc, will be imported asap
<jamiebennett> davidcalle, thanks. Not sure how much has already been fixed with didrocks update so will stop filing bugs until the new pages are live
<davidcalle> dholbach: ^
<davidcalle> dholbach: I'll do it after the scopes UOS session
<dholbach> jamiebennett, which update? or which pages was this about?
<davidcalle> dholbach: snapcraft intro tutorial
<dholbach> ah ok
<dholbach> davidcalle, I'm happy to help - just let me know
<davidcalle> dholbach: thanks, no worries
<qengho> Is that "ubuntu-device-flash" that ogra_ or mvo use to make images any different than the one in the repo? Obvious answer is yes, but not sure why.
<ogra_> It moved forward since relase
<jamiebennett> dholbach, talking to didrocks he has already made some changes to the documentation, pending review and upload by the community team. Do you have these changes?
<qengho> ogra_: And that's not in yakkety or a PPA?
<ogra_> nope
<zyga> qengho: it is also a fork with different features
<qengho> Where's the source?
<zyga> qengho: we hope to merge it during the y cycle
<dholbach> jamiebennett, no - did they land in snapcraft trunk or is this another page which just lives in the CMS?
<zyga> qengho: probably in mvo's fork
<ogra_> will be SRUed to xenial once the gadget and kernel formats are final
<zyga> (branch on LP)
<qengho> Suppose I want a binary for armhf. What branch?
<jamiebennett> didrocks, ^^^ who has your doc changes?
<jamiebennett> didrocks, Or did I misunderstand?
<zyga> I don't really know
<mvo> qengho: lp:~snappy-dev/goget-ubuntu-touch/all-snaps
<mvo> qengho: let me know, if its too tricky to build I can do an arm version
<dholbach> jamiebennett, a couple of things changed in snapcraft and snappy and we're going to pull in these changes, no problem
<qengho> mvo: thanks.
<dholbach> jamiebennett, but if there's anything else we can help with, we're happy to help obviously
<jamiebennett> dholbach, Thanks. The docs in github are easier to change, the CMS changes we will need your help with.
<dholbach> jamiebennett, some of the snappy/snapcraft people already have access to it, but sure, happy to help :)
<jamiebennett> dholbach, Ah, OK
<noizer> zyga debootstrap installed
<sergiusens> jamiebennett can I get removed from owning doc changes? didrocks and asac have the same item; I am glad to help or even draft it though
<noizer> zyga it was proc and sys that i needed to mount?
<zyga> yes
<zyga> mount --bind /proc /path/to/armel/proc
<jamiebennett> sergiusens, sure, we can move that to didrocks with asac and you contributing
<noizer> zyga same thing for sys?
 * zyga -> session
<zyga> yes
<noizer> Ok xD
<noizer> brb
<didrocks> jamiebennett: dholbach: we were talking about the get starting
<didrocks> not the upstream doc itself
<didrocks> getting started*
<dholbach> ah cool
<dholbach> let's chat about this later on
<jamiebennett> OK
<dholbach> or... we're in the snappy docs: next steps session right now
<dholbach> http://summit.ubuntu.com/uos-1605/meeting/22673/snappy-docs-next-steps/ (or ping us for joining the hangout)
<didrocks> dholbach: in meetings right now though :(
 * dholbach hugs didrocks 
<dholbach> didrocks, let's chat after UOS then :)
 * didrocks hugs dholbach
<didrocks> yeah
<dholbach> great - it's been a while :)
<dduffey> lool, trying to build your quagga snap, looks like the custom plugin is not executing from the src directory ... I suspect an environmental variable change potentially?
<lool> dduffey: I'm trying to build an upstream snap right now
<lool> dduffey: (I had most of the reply written down, but wanted to go back with the start of an upstream snap)
<dduffey> lool, sweet
<lool> dduffey: not sure which custom plugin you mean?
<dduffey> lool there were a few other things (patch failure, some yaml changes, etc.) ... but got stuck on when it runs the quagga build
<dduffey> x-custom in:
<dduffey> http://bazaar.launchpad.net/~lool/+junk/quagga-snap/view/head:/snapcraft.yaml
<dduffey> when it runs dpkg-buildpackage, it looks like it is not running it from parts/quagga/src
<dduffey> and I'm doing this from 16.04
<lool> dduffey: Oh right, I think I was unpacking the package myself into the source tree; didn't want to check this in though
<dduffey> lool I see that in the README, so I think I did the same ... i.e. parts/quagga/src has content (including debian/changelog), but the build fails saying it cannot find debian/changelog
<lool> dduffey: afraid it escapes my mind; would you mind switching to the upstream snap instead?
<dduffey> lool, yeah, where is it?
<lool> dduffey: WIP  :-)
<lool> I've started it with this email, almost have something building
<dduffey> lool, ah, okay, I'll back off then :)
<ysionneau> hmm which ubuntu package contains the "snappy" tool?
<ysionneau> (to do "snappy build" to builda gadget snap)
<sergiusens> ysionneau snapcraft build <dir>
<ysionneau> sergiusens: if my gadget snap only has meta/snap.yaml, I can do snapcraft snap . ?
<ysionneau> it seems to work and produces a squashfs
<sergiusens> ysionneau correct; all gadgets can be built with snapcraft now
<ysionneau> cool
<ysionneau> for the kernel snap, it seems the 'kernel-device-tree', 'kernel-image-path' are not accepted anymore :o
<ysionneau> correct ?
<dholbach> kyrofa, let me know if you want me to add the youtube link for you :-)
<sergiusens> ysionneau kernel-image-path is implied from target
<sergiusens> ysionneau so yeah, that is gone
<sergiusens> ysionneau the kernel-device-tree is missing an s
<kyrofa> dholbach, yes please: https://plus.google.com/events/ck0qgm3n2q9tg977qlafvs217vo and http://youtu.be/qvlJlgVMML4
<sergiusens> ysionneau `snapcraft help kernel` should be correct
<dholbach> kyrofa, updated! :-)
<dholbach> thanks!
<jdstrand> zyga, niemeyer: fyi, bug #1578287
<ubottu> bug 1578287 in Snappy "inconsistency between 'snap interfaces' and 'snap connect/disconnect'" [Undecided,New] https://launchpad.net/bugs/1578287
<zyga> jdstrand: ack, I'll read it after the session
<lool> dduffey: https://github.com/lool/quagga-snap
<lool> dduffey: it's cargo-culted from the other one and was only build tested
<ysionneau> sergiusens: ah thanks for the help !
<ysionneau> (indeed trees is more correct)
<niemeyer> jdstrand: Commented on the issue
<niemeyer> zyga: ^
<jdstrand> niemeyer: thanks
<jdstrand> fwiw, I agree that snap interfaces slots then plugs order should not change
 * zyga nods
<zyga> I was thinking about it as well
<zyga> I'd like to let people make it work in any order but fist ensure that we validate plug/slot uniqueness correctly
<zyga> I also wonder how thish should look like on the REST API
<zyga> I'd rather have the rest API precise unless we pass a flag that says otherwise
<zyga> but perhaps that's not required
<zyga> just worth thinking about the api apart from the UX
<sergiusens> elopio is the testing infra broken?
<zyga> sergiusens: some stuff were broken in the morning
<zyga> sergiusens: both on IP connectivity and on what the stuff actually did
<sergiusens> zyga ah, it failed immediately so that might be it
<example6> Hi guys. Still struggling with this one problem of getting my snap to run automatically after install / reboot. Is there anything I should be putting in my Makefile to make this happen?
<example6> in my apps: in snapcraft.yaml I just have one app that runs my wrapper as a daemon
<example6> but it doesn't seem like the wrapper is being run at all
<dpm> dholbach, so tomorrow I'll be back home for the snaps on desktop demo, so I should be able to run my main desktop and not have to worry about x86
<dholbach> cool
<dholbach> let's chat beforehand
<dpm> sounds like a plan
<zyga> example6: you want to use daemon: ... entry
<zyga> example6: look at snapcraft examples
<zyga> example6: there are existing things doing that
<example6> zyga: that's what I did. I have daemon: simple along with my command: in my basic app. I can't seem to find any log of it failing however
<example6> the command: just runs the wrapper script
<zyga> example6: check if the systemd unit was generated in /etc/systemd/system/
<zyga> example6: use systemctl to see if it was started
<zyga> example6: use journalctl to see the logs
<zyga> example6: try to install a snapcraft example and see it run
<zyga> example6: and then iterate on it to look more like your snap
<example6> alright, thank you zyga
<zyga> example6: in the end it might fail because of confinement, try installing the snap with --devmode
<example6> Good to know, thank you
 * zyga -> EOD
<blackout24> Hi, is there something like a sources.list file for snappy? How does it select the channel and the server to find the snaps from the store?
<blackout24> Or is all of that hardcoded into the snap binary?
<kgunn> blackout24: try snap --help
<kgunn> snap list will show you what snaps are on the device
<kgunn> unfortunately, as least that i know, no good way to see what's in the snap
<kgunn> snap find will list the entire store if given on arg
<kgunn> and for install, you can give a channel, but if you don't it'll use the device default (however the image is stitched i suppose)
<blackout24> Ahh you misundertood me. I  mean if there is some file that specifies the server where snaps are fetched from.
<pedronis> blackout24: the channel is selected per snap when one installs/refreshes (--channel argument)
<pedronis> blackout24: there is nothing like sources.list, there will be ways to do offline installs but still secured by assertions etc, that's an area that will evolve over time
<blackout24> thanks
#snappy 2016-05-05
<example6> My snap is unable to create files inside its directory in /apps despite its directory having access to anyone. Is there some sort of method I should be following to give it its own directory in a more writable space?
<example6> I changed ownership of it to root, that didn't seem to help. It seems to be root who's running my program
<example6> Would this be something to do with apparmor?
<jdstrand> example6: /apps is readonly. you have to use the writable directory in /var. Since you said /apps, I'm going to assume you are on 15.04, therefore the writable directory is in /var/lib/apps. you can look at $SNAP_APP_DATA_PATH in your environment to see the precise directory to use
<jdstrand> example6: if you are actually on 16.04, the readonly directory is in /snap and the writable in /var/snap and you use $SNAP_DATA in your environment
 * jdstrand was just passing through
<jdstrand> hope that helps! :)
<example6> jdstrand: that helps a ton! Thank you! Do you have any advice on copying my program to /var/lib/apps after installation? it's basically a script that runs a program that creates a few files in the same directory
<example6> I noticed some of the demos (which don't properly start as services most likely since I am indeed on 15.04) had things like var, lib, bin, etc in side their snap/ directory
<jdstrand> example6: you got me before I walked away :) I did something similar in my ufw snap (snappy install ufw.jdstrand). basically, you copy what you need over into /var/lib/apps from /apps. this can be done be a wrapper script that after the copy, runs the real script
<jdstrand> s/be a/by a/
<jdstrand> example6: though it might be easier to adjust that program to take an optional argument to output to $SNAP_APP_DATA_PATH
<jdstrand> --outdir=$SNAP_APP_DATA_PATH (or similar)
<jdstrand> ok, really gotta run, good luck! :)
<example6> thank you!
<liuxg> I just tried snappy app calculator on Ubuntu 16.04.  However, I cannot find the app in the ubuntu store app. what is the problem for it? https://developer.ubuntu.com/en/desktop/get-started/
<swami> can someone help me with a question on device tree/dtb/fdt on rpi2?
<liuxg> I have tried to develop a snappy app for my desktop. every time, when the app is installed, a new version is installed. when I remove it, it only removes the recent one. now the directory is full of different version of the snap app. how can I remove the previous versions of the app. it occupies a lot of space.
<shuduo> kgunn: hi, i'm following the guide https://goo.gl/4nmG93 to build mir demo. but snapcraft-mir-client building output error like "[Errno 2] No such file or directory: '/home/shuduo/work/snappy/mir-
<shuduo> demo/snapcraft-mir-client/parts/environment/build/snappy-qt5.conf'
<liuxg> how to delete a snap on ubuntu 16.04?
<liuxg> I have tried to use "sudo snapp remove app_name". however, it does not remove the previous versions of the snap apps installed on the system.
<zyga> sergiusens: I would love to have easy access to all debugging symbols
<zyga> quick break while pulseaudio is building
<blackout24> Trying to gain some knowledge on the different commands (snap and snappy). When I download an Snappy Ubuntu Core image and run it in KVM it has the snappy command, which seems to handle more than just the packaging (configures the bootloader). "snappy" has an update command, but on 16.04 there is only the "snap" command and it doesn't look like there is "snap update".
<blackout24> What are the roles of these two applications?
<zyga> blackout24: snappy is the old command that is removed in 16 and 16.04
<blackout24> ahh thanks
<zyga> blackout24: snap is the replacement that uses the REST api (snappy had everything linked in)
<zyga> blackout24: update is now called refresh
<blackout24> When 16.04 downloads a new ubuntu-core snap will it mess with the bootloader? Because 16.04 isn't a snappy system.
<zyga> blackout24: no
<zyga> blackout24: snappy differentiates between core and classic systems
<blackout24> I have ported snappy to Arch Linux and everything works, but when it downloads the ubuntu-core image when I try to install the calculator-app it complains that it can't determine the bootloader. How can I tell snap that I'm on a classic system and it should only install it as a framework.
<zyga> blackout24: ah, in that case you need to patch the source a little, in the past (2.0.2 release) we checked for dpkg status file, now there's a method (I need to check which) that checks this
<zyga> blackout24: I think it should be easy to tweak that to understand arch as well
<zyga> blackout24: I can help you out in a moment, just need a second to test something I'm hacking on now
<zyga> blackout24: look at release/ look for onClassic
<zyga> blackout24: I'm sure we will gladly take patches to detect arch there
<blackout24> Right now I just pull the 2.0.2 snapd deb file from archive.ubuntu.com and "ar p *.deb data.tar.xz | tar -Jxf -C targetdir" the whole thing in a PKGBUILD. I could also let it build the latest Go sources from github and only extract the systemd unit files from snapd deb.
<zyga> blackout24: no that won't work, you really need to rebuild it with a patch
<zyga> it behaves differently on classic and on all-snap system
<blackout24> ok
<zyga> blackout24: and get master
<zyga> blackout24: (no point in using 2.0.2) we SRU regularly so working on latest version is the best way
 * zyga back to hacking
<blackout24> Great thanks. I also wanted to see if I can tweak snapcraft to use pyalpm to check if the build-tools and dependencys are installed on an Arch system.
<zyga> blackout24: for that look at sergiusens
<zyga> blackout24: I can help you out with snappy
<zyga> jdstrand: hey, I have some good and some bad news
<jdstrand> zyga: hey
<jdstrand> and here I was trying to sneak in early to get some stuff done...
<zyga> hehe
<zyga> jdstrand: I got pulseaudio on classic to work
<zyga> jdstrand: but this doesn't solve the bigger shm_open problem
<jdstrand> what did you do to get pulseaudio on classic to work?
<zyga> jdstrand: http://paste.ubuntu.com/16236835/
<zyga> surprisingly little
<zyga> no other changes required
<jdstrand> ok, yeah
<jdstrand> that is what I figured it would look like
<zyga> jdstrand: connect is in the base profile I think, I can remove it
<zyga> jdstrand: now what is interesting is how pulseaudio would work as a snap itself
<zyga> e.g. would it still be +owner /run/user/*/pulse/native rw,
<jdstrand> right
<zyga> (i doubt that)
<jdstrand> this is where I was talking about the dichotomy of classic vs core
<zyga> still, I think this is better than nothing, I'll iterate to reject pulseaudio slots for now
<jdstrand> and the policy being different
<zyga> and propose this, it unlocks a lot of nice apps today
<zyga> and we can add slot support later
<jdstrand> zyga: this is exactly the policy I was thinking should be in either unity7 or unity7-(pulse?)audio, etc
<zyga> I think it's fine to have a pulseaudio interface
<zyga> as a dedicated thing
<jdstrand> I think it is completely fine to have a pulseaudio interface
<jdstrand> for snaps
<jdstrand> for snapped pulseaudio
<zyga> we just need to think if the actual interface is portable, I think the only issues is /run/user socket
<jdstrand> I'm very less sure about this
<jdstrand> there's other stuff
<zyga> if the socket was provided to the client as an attribute
<zyga> yes?
<jdstrand> there is a dbus socket iirc, something else
<jdstrand> I can't recall everything. some are safe some are not
<zyga> I'd start with one that just hands access to this socket
<zyga> not to dbus (this app doesn't need dbus, it does sound like 90% of apps do)
<zyga> I bet pulse has a rich interface but we don't have to support all the bells and whistles (e.g. one that would make the sound indaicator work)
<zyga> indicator*
<jdstrand> so this gets back to: are they separate interfaces (pulse for classic and pulse for core) or is it one named interface (pulseaudio) that will output different security policy if on a classic system vs core system
<zyga> I think that different policy is okayt
<zyga> different behavior is less okay (not okay)
<jdstrand> I don't think we know that this will be for 90% of the apps
<zyga> and this if we take a common subset and enforce that, a single interface is okay
<zyga> jdstrand: 90% of apps just play sound
<zyga> 10% also capture sound
<zyga> 0.1 need to manage pulseaudio internals
<zyga> ballpark numbers but that's realistic IMHO
<jdstrand> did you know that 85% of statistics are made up on the spot?
<zyga> exactly
<jdstrand> :P
<zyga> and mine fits
<jdstrand> does it?
<jdstrand> :)
<zyga> look at it from another point of view, all apps on all mobile devices can play sound when they run
<zyga> supporting that today is very easy and I think that's what we should do
<zyga> supporting more is an open question that we don't have to solve now
<jdstrand> we can take an opinionated view that to play sound you must use what is in the interface
<jdstrand> but every time we take an opinionated view on classic, there is pressure to just allow it
<zyga> I see what you mean, I think we will need to experiment some more
<zyga> perhaps the real issue is the interface name
<jdstrand> zyga: we have an audio policy on Touch that does that safely
<zyga> perhaps we should require that the plugs have an attribute "basic"
<zyga> or something like that that lets us do more later
<zyga> is touch also using pulseaudio?
<jdstrand> yes
<zyga> does it differ because of no X, I know pulse uses X for some IPC
<jdstrand> we call the policy group 'audio', but that is pulseaudio
<jdstrand> I don't know anything about that
<zyga> where can I look at the policy?
<jdstrand> perhaps that is one of the different optional IPC mechanisms (like the dbus one)
<jdstrand> zyga: http://bazaar.launchpad.net/~ubuntu-security/apparmor-easyprof-ubuntu/1.3-stable-phone-overlay/view/head:/data/policygroups/ubuntu/1.0/audio
<zyga> thanks!
<niemeyer> zyga: How does the pulse audio files look like under shm?
<jdstrand> zyga: so, I don't particularly care if we use one interface name with two different policy or two interfaces names. I only care that the policy is appropriate on the target system. that said, once we make the decision, that's it, which is why I'm being cautious
<jdstrand> and I don't have actual stats that the cli and dbus-socket (as opposed to native) aren't legitimately used on classic. on Touch we said "sorry, use 'native'". on classic, I worry someone is going to say "you need to make super important app FOO work and it needs 'cli'"
<jdstrand> but again, if we export two different policies depending on the running system, fine
<jdstrand> it is just we don't have that device introspection in the interface code today
<jdstrand> though, one could argue that we are breaking our contract if when using 'pulseaudio' on classic you also get 'cli' where on core you don't
<sergiusens> blackout24 so you want to use pyalm as build-packages/stage-packages? Look at snapcraft.internal.repo to start out
<jdstrand> perhaps an attribute could help there... but I'm not sure what that would look like
<zyga> niemeyer: pulse-shm-$random-number
<sergiusens> good morning
<jdstrand> niemeyer: it would be much nicer for a pulse snap to use pulse-shm-snap.foo.$random-number (or similar)
<jdstrand> then we can have /dev/shm/pulse-shm-snap.@{SNAP}.* rwk,
<niemeyer> jdstrand: How's that better than /dev/shm/${SNAP}.*?
<jdstrand> that would work too
<jdstrand> I think that falls into (or similar)
<zyga> niemeyer: I think the question we should be asking is if we should expect to patch applications in any way or not
<zyga> niemeyer: if the answer is yes then we can have a nice policy and sensible values everywhere
<zyga> niemeyer: if the answer is no, it's complicated
<jdstrand> I betting the client doesn't need patching
<jdstrand> I'm
<jdstrand> because it is a random number
<niemeyer> jdstrand: Hm?
<jdstrand> it is probably talking on the native interface and the server says-- here, use this thing (whether by fd or something else)
<zyga> jdstrand: the server probably passes the filename via the socket
<jdstrand> and so the client doesn't care what the file name is. I'm am guessing that is how it works
<zyga> jdstrand: though pulse is complex, I bet there are many options thre
<jdstrand> zyga: yes, that is what I'm saying
<jdstrand> so in theory, the pulse snap could be patched
<zyga> jdstrand: I was just highlighing the filename vs fd
<zyga> jdstrand: the other thing to note is the socket itself
<zyga> as in where it is
<jdstrand> we could even SRU a patch so that classic does the same thing
<jdstrand> perhaps the SRU would look at the security label of the connecting application and only do it for clients whose label starts with 'snap.'
<jdstrand> anyhoo
<zyga> jdstrand: can apparmor/seccomp do something about connections over unix sockets?
<zyga> jdstrand: e.g. constrain connect
<jdstrand> zyga: the socket itself is going to need to be known by the clients
<jdstrand> yes
<davidcalle> sergiusens: kyrofa: developer.ubuntu.com is now syncing snapcraft docs with github every 2h \o/
<jdstrand> we have unix mediation
<jdstrand> though not for file backed sockets
<jdstrand> this is a named socket so we only have file rules
<zyga> ah
<zyga> I see
<sergiusens> davidcalle \o/
<jdstrand> (we'll get full unix mediation semantics for named sockets with future work)
 * sergiusens checks
<zyga> jdstrand: I was thinking about patching pulse server but then there are other apps, I don't know how the socket is located today, is that hardcoded somewhere or is that passed by IPC we don't see
<zyga> jdstrand: but perhaps that is not needed
<jdstrand> zyga: I think this is like mir-- there is a known location and that's ok
<zyga> jdstrand: on classic the /run/users socket is okay
<zyga> jdstrand: on snappy we could just make a different policy
<zyga> jdstrand: on classic pulse runs as the user
<jdstrand> on core I think we're going to need to let the permanent connected slot to need to use a well-known path
<zyga> jdstrand: so that's another complication
<jdstrand> that was a poorly contructed sentence
<zyga> jdstrand: at the end of the story we should check if a snap like paplay can work on classic and core
<jdstrand> zyga: on Personal, it will run as the user too
<zyga> jdstrand: but perhaps not on core
<zyga> jdstrand: it couldn't today, right?
<niemeyer> I'm honestly a bit lost on the conversation by now
<zyga> jdstrand: service == root
<jdstrand> zyga: Personal is going to need a lot of work. that would be of session services
<zyga> niemeyer: sorry, we're brainstorming what possiblities exist and what implications they might have now, this is specific to pulse, not to shm_open
<zyga> is there anyone working on pulseaudio snap for core today?
<niemeyer> zyga: Understood, but I'm kind of missing the high-level conversation we should have
<jdstrand> niemeyer: for the record, I'm completely fine with /dev/shm/${SNAP}.* as that keeps things isolated. if we feel this is a good thing generally, I can propse a change
<niemeyer> zyga: What are the constraints for that design
<jdstrand> niemeyer: that may not help pulse and chromium, but it provides a general 'do this and it will work' mechanism
<zyga> I agree with jdstrand's opinion on this
<zyga> we can always poke holes with specific interfaces, shouldn't stop us from sane defaults
<zyga> not thet the very subtle path that jdstrand proposed does not have subdirectories under /dev/shm as that would not work
<jdstrand> zyga: re who is working on it> no, but it is on the list from phonedations, after bluez, nm, location-service and ofono/modemmanager
<zyga> undrstood
<jdstrand> according to I believe, morphis
<zyga> niemeyer: quick question, would you be okay with a pulseaudio interface that works on classic only (like x11,unity7) and allows just plugs (no slots)?
<niemeyer> jdstrand: So what is pulse audio trying to do that this would not work?
<jdstrand> zyga: I could allow creation of both a snap-specific file patch and a snap-specific directory in /dev/shm so people are free to use that general mechanism without issues
<zyga> jdstrand: except that shm_open rejects subdirectories
<zyga> jdstrand: we could allow it but it would  be non-trivial to use
<jdstrand> niemeyer: pulseaudio server today does not conform to /dev/shm/${SNAP}.*
<jdstrand> niemeyer: it could be made to do so both in a snap and in SRU
<niemeyer> jdstrand: Ah, ok.. my underslying question was actually: do we know of cases that want to share those files?
<jdstrand> zyga: right, which is why we allow *both*. one that is file for shm_open and one that is directory for people that use open()
<zyga> jdstrand: that would work
<jdstrand> but both are app-specific
<niemeyer> jdstrand: app-specific or snap-specific?
<zyga> 2016 and mksquashfs freezes my desktop session because scheduling sucks :/
<jdstrand> niemeyer: honestly, I do not. I was assuming they were client specific (not even session specific) since I see a bunch of them in my session
<ogra_> Stop using that hardware from 2004
<jdstrand> zyga: hrmm-- I see similar things :\
<ogra_> :)
<jdstrand> ogra_: I have an xps 13!
<jdstrand> not the newest one, but still :)
<ogra_> The 2004 model ?
<sergiusens> davidcalle looks good, I have a request already though ;-) Can we enhance the code snippets with pygments?
<jdstrand> haha
 * ogra_ grins
<jdstrand> no :)
<jdstrand> 2014 iirc
<ogra_> yeah, same device here...
<davidcalle> sergiusens: only if markdown has a way to specify language for code snippets
<niemeyer> zyga: What did you find out with pulseaudio?
<ogra_> do we use xz for squashfs compression ?
<niemeyer> zyga: When you allow it to use shm, but not other processes to see those files, what happened?
<davidcalle> sergiusens: (or we come up with a custom tag, that works too)
<jdstrand> niemeyer, zyga: ok, so, do we agree that I should modify the default policy to allow /dev/shm/${SNAP}.* for files and directories just because that is the correct way to handle shm_open() and open(), regardless of pulse, chromium, etc?
<zyga> niemeyer: that pulseaudio on classic can be accomodated with a very simple interface, it needs to access a shared socket (per user) and files named /dev/shm/pulse-shm-*
<zyga> jdstrand: +1
<zyga> jdstrand: pulse would work with a simple interface as described
<niemeyer> jdstrand, zyga: Let's consider that for a little while before acting, please
<zyga> jdstrand: chromium, I need to analyze still
<zyga> standup!
<jdstrand> niemeyer: all that is doing is saying: "the path we said you could use before (/dev/shm/snap/$SNAP/**) we undesrtand to be broken. here is something that will work for you. Next up, design pulseaudio interface (that may or may not comply with that)"
<sergiusens> davidcalle the github extension of markdown does fwiw (and we are using it or were)
<jdstrand> zyga: for pulse, if we are saying "native socket only for both core and classic" and we generate policy for /dev/shm/pulse-shm-* on classic and (perhaps) /dev/shm/$SNAP... on core, then I'm ok with one interface: pulseaudio
<jdstrand> zyga: if we are going to entertain the dbus or cli pulse sockets, those need to be different interfaces/attributes
<jdstrand> that way the default is always the native socket, but (if we decide to support it), you can request cli or dbus-socket
<jdstrand> zyga: oh, and the native socket for the slot is at a well-known path
<jdstrand> though, I think I prefer /dev/shm/snap.$SNAP... to /dev/shm/$SNAP... for namespacing
<jdstrand> we could argue that point in the PR
<kyrofa> Good morning
<kyrofa> davidcalle, awesome!!
<davidcalle> sergiusens, ok
<jdstrand> zyga: in this manner, the contract is always the same for the native socket. we just may (or may not) use a different shm path
<sergiusens> davidcalle hey, I love the fact that they are being updated though!!! \o/
<zyga> jdstrand: hmmm, I'm not sure I understand that correctly, would you mind expresisng that as a plug-side aa policy pseudo code?
<zyga> jdstrand: I agree on /dev/shm/snap.$SNAP
<zyga> jdstrand: $SNAP_NAME to be precise
<jdstrand> zyga: if we say that the 'pulseaudio' interface uses 'native' socket by default, plug side for classic is what you pasted. plug side for core may drop /dev/shm/pulse-... and rely on only the general /dev/shm/snap.$SNAP (I say may cause let's see how things go with that snap). then, if at some future date someone wants the 'cli' or 'dbus-socket' pulseaudio sockets, we introduce an attribute or pulseaudio-{cli,dbus-socket} interfaces
<zyga> jdstrand: I agree with that
<jdstrand> zyga: in this manner, the default pulseaudio interface contract is consistent between classic and snap
<jdstrand> which was my biggest concern
<zyga> jdstrand: yes, that's very important
<kgunn> shuduo: ah...thanks for the catch, i forgot to bzr add that file....added now, should work
<zyga> jdstrand: and later on we can do pulseaudo-control interface or use attributes, depending on how things look like precisely
<jdstrand> so if we're pressured to allow cli or whatever, we have a way forward that doesn't break apps (new interface or attribute)
<jdstrand> exactly
<jdstrand> ok, cool
<jdstrand> I think we are in agreement on pulseaudio. I'd like to get to agreement on the paths in /dev/shm for the non-pulseaudio general case too though
<jdstrand> since they are known to be broken
<jdstrand> then we can look at chromium
<jdstrand> oh
<zyga> jdstrand: I think /dev/shm/snap.$SNAP_NAME.*
<zyga> jdstrand: snap. as that makes it obvious what the culprit is
<zyga> jdstrand: no .app as shm is an IPC mechanism and shold work within one snap directly
<zyga> jdstrand: and .* to allow those random names
<zyga> (to be precise . to termiante $SNAP_NAME * for the random stuff)
<jdstrand> zyga: we talked a long time ago about the 'home-hidden' interface but I think that morphed into (the idea to have) an interface that allows requesting access to file/directory (eg, ~/.mozilla). that could be used for chromium
<jdstrand> zyga: snap.> yes and makes sure a crafted snap name doesn't try to use a well-known path in /dev/shm
<zyga> jdstrand: and we could also marry this with a patch to glibc
<jdstrand> zyga: the whole time I was thinking snap.$SNAP_NAME.* since I figured apps within a snap might want to use shm however they want
<zyga> jdstrand: to make shm_open() use $SNAP_NAME prefix transparently if SNAP_NAME is defined
<zyga> jdstrand: _or_ let people use something like my runtime helper
<jdstrand> that is a possibility
<zyga> jdstrand: LD_PRELOAD or linked in
<jdstrand> or they patch the code
<jdstrand> yes, there are options for people
<zyga> my helper is actually a nice bit that you can link in or preload and it just works :)
<jdstrand> yeha
<jdstrand> yeah
<jdstrand> I guess that would be part of snapcraft?
<jdstrand> you say, "I want snappy compliant paths in /dev/shm' in snapcraft.yaml and you get that?
<jdstrand> that doesn't help static code, but that's ok. it is handy regardless
<zyga> jdstrand: we can make that happen by magic with snapcraft
<zyga> jdstrand: just stick it in
<zyga> jdstrand: oooor
<zyga> jdstrand: actually I have a interesting/cool idea
<zyga> jdstrand: what if we had a magic LD_PRELOAD managed by the core snap itself
<zyga> jdstrand: where we ship very conservative and non-invasive things like that
<zyga> jdstrand: so when policy changes, it still works
<jdstrand> that is an interesting idea. my conservatism says we may want to offer an opt-out though
<zyga> sure
<zyga> out is okay
<zyga> jdstrand: offtopic, are you going to the sprint?
<jdstrand> zyga: what did you think about the comment on the 'path interface' bit for chromium (which uses open()). is that 'path interface' still a thing? (I thought it was needed for things like ~/.mozilla, etc)
<jdstrand> zyga: no. tyhicks will be there. I will be on irc though in my normal timezone
<zyga> the path interface is an interesting idea, it's certainly a sprint topic, I was thinking about it from a different POV, .e.g. where you as a user can create a slice of $HOME, create a new slot, and connect it to some slots (typed home-slice perhaps)
<zyga> jdstrand: how that might work for non-home directories, I don't know
<jdstrand> zyga: so the spec for that interface is only for non-home?
<jdstrand> err
<jdstrand> only for home?
<zyga> there's no spec yet, this was just some speculation
<jdstrand> ok
<zyga> jdstrand: I'd like to have one
<zyga> jdstrand: it's a simple idea and would let us see how hooks work (it would have to be hook based)
<jdstrand> yeah. my understanding is that it is a requirement
<zyga> jdstrand: ok, let's wrap up shm_open and pulseaudio as agreed
<zyga> jdstrand: I'll work on pulse now
<zyga> jdstrand: I have a lovely snap that just work with this interface, I'd love to put it in the store
<jdstrand> zyga: I can work on the generalized shm
<zyga> jdstrand: brilliant, thank you
<jdstrand> zyga: so, I have two simple PRs from yesterday but the intergration tests failed. I don't see how my code could have done that (especially the PR for doc changes :), but I can't see the integration test results to know what is happening
<zyga> jdstrand: integration tests are broken now I think
<zyga> fgimenez: ^^ are they?
<zyga> jdstrand: if you connect to the VPN you can see the results
<zyga> jdstrand: let's merge the doc changes after they get the second review
<zyga> jdstrand: as for the other PR, I didn't review any yet
<jdstrand> ack, thanks
<jdstrand> zyga: for me at least, this pulseaudio discussion was really good. it solidifies concepts like interfaces contracts, classic vs core vs personal, how attributes might play a part, etc
<jdstrand> which will inform future interface discussions
<jdstrand> yes, FileNotFoundError in the jenkins output. seem broken
<blackout24> zyga, I changed the release.go code: https://github.com/timjp87/snappy/blob/master/release/release.go#L73
<blackout24> Unfortunately I still get "Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)"
<zyga> blackout24: you also need to patch ubuntu-core-launcher
<blackout24> ahhh
<zyga> blackout24: though wait, where do you see that error?
<zyga> blackout24: on snapd start up? snap install? when?
<blackout24> snapd install
<blackout24> I try to install the calculator
<blackout24> and it first fetches ubuntu-core
<blackout24> I cleaned my previous installation, which just used the precompiled 2.0.2 binaries from xenial and modified my PKGBUILD so that it pulls the source from github and applies the patch before building snap and snapd.
<blackout24> I also rebooted to make sure
<zyga> blackout24: and the error showed up when?
<zyga> blackout24: note that snapd also has a few systemd units you need
<zyga> blackout24: you may want to look at those
<zyga> blackout24: but I don't know arch really so I cannot help there
<kgunn> shuduo: so it worked ok for you now?
<zyga> sergiusens: could snapcraft be very conservative about .debs it downloads so snapcraft clean; snapcraft can reuse them, I still have to do snapcraft clean all the time and downloading debs over and over is the last big slowdown
<niemeyer> blackout24: Please note we'd be happy to take those patches in
<niemeyer> blackout24: Assuming you can make it all actually work
<blackout24> Thanks. Yes I installed the systemd units from the github.com repo into /usr/lib/systemd/system. Arch has everything in /usr instead of installing stuff to /lib.
<blackout24> They are the same that are listed as contents of the snapd package in 16.04
<zyga> blackout24: you will also need apparmor and seccomp
<zyga> blackout24: and ubuntu-core-launcher actually working
<shuduo> kgunn: i'm verifying on another laptop. will let me you later. maybe after 30 minutes. thanks. :)
<blackout24> That's what I wanted to find out if apparmor is a hard dependency
<kgunn> nw, thanks for trying
<zyga> blackout24: yes
<zyga> blackout24: and seccomp as well
<zyga> but that's hard not to have :)
<zyga> blackout24: if you build ubuntu-core-launcher you're 90% closer to running snapd
<blackout24> zyga: There is an alternative kernel available with the apparmor patches. It's not maintained but should be possible to revive.
<zyga> blackout24: you may also need kernel patches but I'll delegate that to some other folks
<kgunn> zyga: you seem busy, but had a chance to try my fork and get the plug to connect?
<sergiusens> zyga do snapcraft clean --step build
<zyga> sergiusens: <3 thank you
<zyga> kgunn: not yet, I'll do it today as I'm not going to be involved in UOS as much
<kgunn> nw
<blackout24> Right now I only have the userland apparmor libraries installed. They are available through the AUR.
<sergiusens> zyga also, you can most likely get away by using build packages instead of stage-packages in most cases
<niemeyer> jdstrand: How fast can we ship a new glibc for 16.04?
<sergiusens> blackout24 the ubuntu security team has some easy instructions to get different kernel versions patched
<zyga> kgunn: how does mir use shared memory?
<sergiusens> blackout24 maybe this can kickstart your work https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels
<sergiusens> zyga heh, the shm question is being raised a lot now. I am happy to see this being brought up :-)
<zyga> snappy will comb software into looking nice and uniform
 * zyga does a poor man's job of snap try
<blackout24> sergiusens, thanks
<zyga> and ... wow, speedup :)
<jdstrand> niemeyer: the new glibc for shm_open?
<niemeyer> jdstrand: Yeah
<zyga> niemeyer: to make shm_open() understand $SNAP_NAME and use it as prefix?
<jdstrand> well, the hardest part would be convincing infinity, but I'm kinda liking zyga's LD_PRELOAD idea since that would work on any glibc system (eg, non-Ubuntu systems)
<zyga> jdstrand: I'll refresh my preload library to do that
<zyga> jdstrand: we can experiment with it while convincing infinity :)
<jdstrand> zyga: well, but again, if we use your LD_PRELOAD library be default idea, there is no need to convince infinity. snappy can maintain those changes outside of SRUs and those changes propagate to other distros
<jdstrand> s/be/by/
<zyga> hmmm
<zyga> not needing it would feel nicer but I agree that it is a simplification
<jdstrand> I can promise you upstream glibc won't take it, so then we have a permanent delta that we ask all other distros to incorporate
<zyga> iff it is added by default by snapcraft
<zyga> jdstrand: why won't they take it?
<jdstrand> snapcraft or your snapd idea of by default
<zyga> ah, right
<camako> zyga, @how mir uses shared memory : It uses it for Mesa s/w clients. Mir client requests it, server allocates it, client renders to it, gives it back to the server, and server posts it on the display
<jdstrand> have you worked with upstream glibc?
<jdstrand> :)
<zyga> jdstrand: no :)
<jdstrand> go ahead, float this by infinity right now in #ubuntu-devel :)
<zyga> camako: I'd like to know how it allocates shared memory and shares is across processes
<zyga> jdstrand: isn't that guy who used to be grumpy off glibc maintenance now :)
<jdstrand> but really, again, regardless of upstream, having this (and perhaps other things) in control of snapd/snapcraft might be better
<zyga> jdstrand: yes, I agree on that
<jdstrand> zyga: yes... :)
<zyga> jdstrand: looking at how shm_open works, it's actually a bit sucky :/ it's easy to hack and change the directory, harder to convince glibc to just take a non-directory prefix...
<zyga> gimme a sec
 * sergiusens starts monitoring #ubuntu-devel with a bucket full of popcorn
<fgimenez> zyga, integration tests infra seem to be fine now
<zyga> fgimenez: thank you
<camako> zyga, it allocates using
<camako>     auto raw_fd = open("/dev/shm", O_TMPFILE | O_RDWR | O_EXCL | O_CLOEXEC, S_IRWXU);
<camako> it maps using mmap
<camako> zyga, it requires a kernel that supports O_TMPFILE
<zyga> camako: thank you
<camako> yw
<zyga> jdstrand: ^^
<kgunn> camako: is same for android bins ?
<zyga> jdstrand: that looks like not something glibc can "cure"
<kgunn> vs mesa
<camako> kgunn, not today but it could be
<zyga> kgunn: who's doing the allocation? mir-server or mir-client?
<camako> used for android in the future as well
<camako> zyga, mir server does the allocation
<zyga> camako: ahhh, even more interesting
<fgimenez> zyga, np :)
<camako> zyga, though also in the future we could use client allocated buffers as well... not today tho
<zyga> camako: how does it share this with the client?
<kgunn> camako: isn't server alloc'd buffs part of our security story tho
<camako> through an IPC mechanism that dups the fd
<camako> zyga ^
<zyga> camako: so the client side just gets the fd and mmaps it
<camako> kgunn, yeah there may be issues... that's why it's not done yet
<zyga> camako: no need for an open on the client side?
<camako> zyga, correct
<zyga> thanks
<zyga> that's good and bad
<zyga> the O_TMPFILE is something hard for us to support
<zyga> I need to read how it works
<camako> zyga, there is nothing magical about it, just that it was introduced in kernel > 3.18
<camako> zyga, we also have an alternate path for lesser kernels that uses " raw_fd = mkostemp(template_filename, O_CLOEXEC);"
<jdstrand> zyga: fyi, there is a list of required kernel patches that ogasawara and others are putting together for snappy kernels
<zyga> jdstrand, camako: it's not really as much as an old kernel, we just want to ensure snaps cannot create arbitrary names in /dev/shm
<camako> zyga, but that leaves a temp file that we have to unlink. O_TMPFILE doesnt create anything in the filesystem
<zyga> we'd prefer if they can be prefixed
<zyga> oh
<zyga> so there's no file at all? a
<zyga> so that might just work (tm)
<camako> zyga, correct
<zyga> thanks!
<zyga> that's much easier to support :)
<jdstrand> well
<jdstrand> there is probably an LSM hook for it
<jdstrand> and that is probably going to be mediated as a file
<jdstrand> I would ask ty hicks about that, but he is currently working on an emergency
<jdstrand> maybe there isn't a hook (idk)
<jdstrand> it's easy to see though
<jdstrand> if you have a new kernel just try the code and see if it gets blocked
<zyga> jdstrand: if we cannot confine it, is that a problem?
<zyga> jdstrand: remember that we still confine the socket that is used to transport the fd
<swami> can someone help on dtb/fdt/device tree issue on rpi2 with custom u-boot?
<jdstrand> zyga: if there is no denial and no path then there should be no attack vector since another application shouldn't be able to get at the fd. this would also need ty hicks input
<zyga> kgunn: I'll look at mir next, wrapping up this work
<kgunn> sure
<swami> during u-boot, after loading uboot.env, I m getting this error: "libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting!"
<swami> but the printenv show fdt addr and file etc., any pointers, anyone please?
<kgunn> just from another thread and discussion, and sorry if i missed this if already said, but is there a thought to make interfaces have versions?
<kgunn> or should that be frozen per series at least?
<kgunn> zyga: niemeyer ^
<zyga> kgunn: interface is like a binary protocol
<zyga> kgunn: if you change it in an incompatible way
<zyga> kgunn: it should be a new interface
<kgunn> ok
<kgunn> pmcgowan: ^
<zyga> kgunn: what is the current trend? is it constantly a new wire protocol?
<pmcgowan> kgunn, so yes ;)
<zyga> kgunn: another option would be to constrain the interface to a library and have the "mir client" share a .so for the other snap to open
<zyga> kgunn: then the wire is irrelevant-ish
<kgunn> zyga: i was wondering only in the context of sdk/uitk actually (brainstorming if interfaces would be used there)
<pmcgowan> kgunn, I think the big difference vs what we do today is we cannot have one snap provide multiple interfaces
<pmcgowan> whereas today one pile of bits is many frameworks
<kgunn> right
<pmcgowan> which is the potential issue depending on your viewpoint
<zyga> kgunn: definitely, the only question is how, not if
<kgunn> ;)
<niemeyer> kgunn, zyga: Using a library just moves the same problem elsewhere
<niemeyer> You now have a library ABI and the interface must change if that ABI breaks
<zyga> niemeyer: yes that is true, just the question of which problem is easier to solve
<niemeyer> zyga: Different answers for different developers
<niemeyer> pmcgowan: Why can we not have one snap providing multiple interfaces?
<pmcgowan> niemeyer, can we?
<zyga> yes :)
<niemeyer> pmcgowan: Yeah, multiple plugs, multiple slots
<pmcgowan> ah then great
<kgunn> so you can effectively version (meta-like)
<niemeyer> pmcgowan: With the same interface or different interfaces
<niemeyer> kgunn: We have unity7 today already
<niemeyer> kgunn: We just don't have a field named "version" in the interface, and I don't think we should do that
<kgunn> sure
<niemeyer> We should try really hard not to break these interfaces, as it means we're breaking real software out there every time we do it
<pmcgowan> indeed
<niemeyer> When we do require the breakage, we need a new interface
<niemeyer> A new interface is simply a new name from the user perspective, with a new definition from snapd's perspective
<kgunn> right, it's just a reality with SDK...it will need to evolve/grow over time
<niemeyer> kgunn: Of course, it's a matter of how long we stick to an interface, not whether we should break it or no
<niemeyer> kgunn: Good software tends to be engineered so that its public runtime APIs do not break often
<niemeyer> kgunn: The longer they last, the longer software remains working, the better for everybody
<kgunn> niemeyer: sure, and i think pmcgowan's team doesn't change a crazy amount...but just needs a way to manage the breaks
<kgunn> and seems like that's a decent answer
<pmcgowan> kgunn, niemeyer what we do a lot of is add new APIs without breaking old ones
<niemeyer> I'm not judging anyone.. this is a statement of desire :)
<pmcgowan> so that sounds like multiple interfaces
<niemeyer> pmcgowan: Depends..
<kgunn> pmcgowan: and even if you do break...you could run through a series with interface-old and interface-new, then drop -old in the next series
<niemeyer> pmcgowan: Sometimes it's possible to introduce new features without breaking old logic and in a way that is introspectable
<pmcgowan> true
<shuduo> kgunn: mir-demo works great now. thanks.
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/1133
<zyga> jdstrand: also https://myapps.developer.ubuntu.com/dev/click-apps/4989/rev/1/ ;)
<zyga> jdstrand: if you want to try this out
<jdstrand> ack
<zzarr> hello!
<zzarr> I'm new to snappy
<zzarr> how does it work?
<zzarr> I have a dragonboard 410c which I have booted snappy from a sdcard on
<zzarr> I wish to install it to the emmc on the dragonboard, but I don't know how
<zyga> re, sorry, system crashed hard when I unpluged an USB device :/
<zyga> jdstrand: I read your comment and I fully agree
<zyga> jdstrand: thanks for teaching me more about apparmor details through the various comments :)
<zyga> jdstrand: do you think SRU-ing pulseaudio is something we should get started with now (to restrict recording)
<zyga> jdstrand: so that it can be ready when the next snappy SRU is out
<jdstrand> zyga: I do, yes
<jdstrand> zyga: that way they can just use pulseaudio playback and enjoy
<tyhicks> zyga: did you get all of your answers regarding O_TMPFILE?
<zyga> tyhicks: no, sorry, I got disconnected
<tyhicks> zyga: what did you want to know about it?
<zyga> tyhicks: hi btw :-)
<tyhicks> zyga: hi :)
<zyga> tyhicks: I think I just need to check now, I wasn't sure how O_TMPFILE worked, I heard that it doesn't even create an entry in the filesystem, just returns an fd
<tyhicks> zyga: that's correct
<zyga> tyhicks: does that mean the path argument is totally ignored?
<tyhicks> zyga: from userspace's perspective, yes
<tyhicks> zyga: the kernel uses the path to determine which filesystem's tmpfile() implementation should be used
<zyga> tyhicks: from the kernel? will you get an apparmor deny if the process cannot write to /dev/shm
<zyga> ah
 * zyga intends to experiment with mir next so he'll find out for sure :)
<jdstrand> tyhicks: I wasn't sure apparmor would still mediate it as a path and if it didn't, is it possible for another process to get access to that fd?
<jdstrand> tyhicks: sounds like zyga will blackbox the first question though :)
<zyga> hehe
<tyhicks> jdstrand: other processes can't get to that fd (unless the owning process passes the fd to another process)
<tyhicks> I'll take a quick look to see if AA is going to mediate it
<tyhicks> zyga: my biggest concerns about its usage are that it is only available in relatively new kernels and that not all filesystems support it
<zyga> tyhicks: that's upstream problem to solve (mir) but from what I read above there is a fallback to another mechanism as well
<tyhicks> zyga: aha! I was thinking that you were investigating its use in the launcher or something else internal to ubuntu core
<jdstrand> tyhicks: right, that was my understanding (barring a kernel vulnerability of course)
<tyhicks> jdstrand: the owning process can do some trickery in /proc/self/fd/ to link the fd back into the filesystem but AA mediation definitely comes into play at that time
<jdstrand> tyhicks: so, if the server opened it and passed it to the client, are you saying the client can't pass it again? I thought it could (but that would trigger remediation)
<jdstrand> revalidation*
<tyhicks> jdstrand: I didn't intend to say that
<jdstrand> (and this is just for clarification-- whether it can't pass or can pass with revalidation is fine from an isolation perspective)
<tyhicks> jdstrand: it is just a regular fd and it can be passed around like any other fd
<jdstrand> ok
<jdstrand> the point is, if I have an fd, nothing can access it unless I give it to them
<tyhicks> correct
<jdstrand> cool, that is what I thought be wanted to be doubly sure :)
<plars> elopio: fgimenez: Hi! I have the snap I build with your upstream tests pretty much up and running under checkbox now, but I hit a kernel bug yesterday on one of the tests, have you seen this? http://paste.ubuntu.com/16227643/
<zyga> ok, let's look at mir now
<tyhicks> zyga, jdstrand: I just did a quick test and you do need appropriate permissions in the directory that you pass to open() when using O_TMPFILE
<zyga> tyhicks: which level of permissions?
<zyga> tyhicks: apparmor or filesystem
<tyhicks> zyga: regular fileystem level permissions and apparmor
<tyhicks> zyga: they're both checked
<zyga> tyhicks: hmm, that's a bit annoying then, you need write permission for /dev/shm (apparmor) then?
<tyhicks> zyga: yep
<zyga> tyhicks: that's interesting/annoying then:) so mir slot will need "/dev/shm w,"
<zyga> right?
<tyhicks> zyga: that's correct if they're passing O_WRONLY to open()
<tyhicks> zyga: if they're passing O_RDWR, then "/dev/shm rw," will be needed
<zyga> tyhicks: I believe the actual call is...
<fgimenez> hey plars, nope, never saw that before
<plars> fgimenez: maybe a fluke, but I wanted to capture what I could
<zyga> tyhicks: camako:     auto raw_fd = open("/dev/shm", O_TMPFILE | O_RDWR | O_EXCL | O_CLOEXEC, S_IRWXU);
<zyga> so /dev/shm rw,
<fgimenez> plars, yes, that concrete test is passing in the cloud instances with that same kernel snap version http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/2309/consoleFull
<tyhicks> zyga: actually, looking at the kernel code, only write perms are checked even if O_RDWR is specified
<tyhicks> that's kind of odd
<zyga> tyhicks: in which way?
<tyhicks> zyga: just that they're only checking for write perms in do_tmpfile()
<zyga> ah
<zyga> I though you meant the userspace code
<tyhicks> zyga: anyways, be sure to double check my work and leave those rules out of the interface initially to see if it gets a denial
<zyga> tyhicks: yep, that's sensible
<zyga> tyhicks: which work do you refer to?
<zyga> I only read your seccomp argument filtering patches
<tyhicks> zyga: I was talking about my investigation into how O_TMPFILE is mediated
<zyga> ah
<tyhicks> zyga: double check it by leaving the rule out initially and see if you get a denial that looks like this:
<zyga> sorry, I'm not parsing stuff correctly today :)
<tyhicks> apparmor="DENIED" operation="open" profile="test" name="/tmp/#23739838" pid=12721 comm="test" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
<zyga> yep
<zyga> I'll do that
<zyga> just setting up the environment now
<tyhicks> zyga: note the name="/tmp/#23739838" part
<tyhicks> zyga: I pass "/tmp" to open()
<zyga> that #123 is not a real name right?
<tyhicks> right
<zyga> is that userspace or kernel making that
<tyhicks> kernel
<zyga> ok
<tyhicks> ok, I need to tend to something else
<tyhicks> let me know if you hit any issues
<zyga> thanks for your help!
<zyga> kgunn: ok, focusing on mir now
<zyga> kgunn: is your pull request up to date?
<kgunn> zyga: only have a fork, didn't do a pull request...but yes, it was sort of "best state"
<zyga> kgunn: thanks, I'll take it :)
<kgunn> i played around with moving from perma slot to connected slot...but still had no joy
<zyga> kgunn: I think you shared the mir snap but do you have the link handy anywhere?
<kgunn> i was trying to connect manually like snap connect mir-server:mir ubuntu-core:mir...
<kgunn> zyga: https://code.launchpad.net/~mir-team/+junk/mir-server-snap
<kgunn> and a wiki for all the other stuff
<kgunn> https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<blackout24> If I use the current Arch Linux Kernel 4.5.1 as a template is it enough to just just flip some Kconfig switches to get apparmor and seccomp? The wiki here https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels mostly seems to be for old kernels. This would make packaging a custom kernel a lot easier.
<blackout24> I have the apparmor parser and libs and libseccomp packaged as well as ubuntu-core-launcher.
<blackout24> Only the kernel should be missing.
<zyga> blackout24: try it
<jdstrand> zyga: fyi, https://github.com/ubuntu-core/snappy/pull/1135
<zyga> mmm
<zyga> just a sanity check, w there lets the snap mkdir /dev/shm/snap.foo.$anything//
<zyga> ?
<jdstrand> yep
<jdstrand> I tested it
<zyga> fantastic, thank you
<jdstrand> http://paste.ubuntu.com/16242478/
<jdstrand> (that is within hello-world.sh)
<zyga> hello world is a very useful tool :)
<jdstrand> it is :)
<zyga> I'll upload busybox snap ot the store
<zyga> it's nice too and sometimes more powerful
<kyrofa> blackout24, yeah it really depends on the current kernel config. The 96boards kernel only needed squashfs enabled: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/
<kyrofa> zyga, where are we on some sort of hw-assign functionality with interfaces?
<zyga> kyrofa: it's there but nothing is using it
<zyga> kyrofa: an interface can hand out snippets of udev rules
<zyga> kyrofa: note that hw-assign is not coming back
<zyga> kyrofa: the assignable thing thould be a slot and a proper interface
<zyga> kyrofa: what do you need to support?
<kyrofa> zyga, right
<kyrofa> zyga, the realsense camera
<zyga> kyrofa: how is that exposed by the kernel?
<zyga> kyrofa: note that it smells very much like something that won't happen before we have hooks
<zyga> kyrofa: e.g. run hook to find realsense cameras
<kyrofa> zyga, uvcvideo
<zyga> kyrofa: you can prototype with an interface that tags a specific device along with an apparmor rule that lets it through
<zyga> kyrofa: how does the app find it?
<zyga> kyrofa: is it hard-coded/
<zyga> kyrofa: are you going to the sprint next week?
<zyga> kyrofa: we could hack this together quickly
<kyrofa> Yeah I am-- that'd be fun!
<kyrofa> zyga, no, not hard-coded... it uses the kernel module somehow. Not too familiar with the lib, but I'll do some research
<zyga> kyrofa: a strace of what it does is a good first step
<blackout24> Setting CONFIG_AUDIT and enabling Apparmor Kconfigs worked. apparmor status gives me: "apparmor module is loaded." seccomp support was enabled anyway. Still getting "Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)", though. Might have to do some print debugging to see if it sets the OnClassic variable correctly.
<blackout24> ubuntu-core-launcher is installed, too. Compiled it natively against libseccomp and libapparmor, which both also compiled natively and packaged.
<blackout24> I also added also the extra files that are present in the ubuntu packages that go to /etc etc.
<ali1234> kyrofa: was it you doing the "how to snap" demo yesterday?
<kyrofa> ali1234, I was one of them, yes
<ali1234> the main one? the qt application?
<kyrofa> ali1234, yeah, the qt app. The bearded one :)
<ali1234> answered many of my questions, thanks
<kyrofa> ali1234, I'm happy to hear that!
<ali1234> had to drop out after your bit and missed the others
<ali1234> when is a good time to ask some follow up questions?
<kyrofa> ali1234, now is fine
<ali1234> hmm okay... so regarding install rules etc
<ali1234> what does the layout inside the snap look like, to the application that is running?
<ali1234> like if my file needs /etc/foo.conf, where does that go inside the snap? or how do i adjust the paths in my code?
<ali1234> or say, /usr/share/myapp/somedatafile
<kyrofa> ali1234, the layout of the snap doesn't look any different to an app in the snap than it does to you outside the snap
<kyrofa> ali1234, i.e. /etc/foo.conf will try to reach out to /etc/foo.conf rather than the one in the snap
<kyrofa> ali1234, for that particular example, your app should use the $SNAP environment variable to make sure it's grabbing stuff within the snap
<ali1234> so... how do i access datafiles that are staged and end up in the snap?
<kyrofa> ali1234, do you remember when I installed the snap and a script was generated by snappy and placed in /snap/bin/ ?
<kyrofa> ali1234, that script defines several environment variables that can be used by the application within the snap
<kyrofa> $SNAP is one of them, which points back to the snap itself
<ali1234> and if upstream doesn't use it, then i have to patch it?
<kyrofa> ali1234, well, that depends
<kyrofa> ali1234, to give you an example from my experience, I was snapping software from upstream which by default uses /etc/my-configuration-file.conf
<kyrofa> ali1234, however, that piece of software also had a command-line option for specifying the location of that file
<ali1234> ah.. so then the wrapper can handle it
<kyrofa> ali1234, so all I had to do when snapping it was specify that flag in the `apps` section of my snapcraft.yaml
<kyrofa> Right
<ali1234> neat
<kyrofa> ali1234, but if your upstream doesn't have that type of functionality, things get more difficult
<ali1234> okay next question. you talked about wiki parts... how can i see a list of them all and what they do?
<kyrofa> ali1234, in that case you either maintain a fork that uses $SNAP and friends, or perhaps try to contribute such a flag upstream
<kyrofa> Ah, easy!
<kyrofa> I shared this link during the talk: https://wiki.ubuntu.com/Snappy/Parts
<kyrofa> You can see how each one is a little snapcraft snippet
<ali1234> yeah.
<ali1234> there's fewer than i expected :)
<kyrofa> ali1234, add some! ;)
<ali1234> a gstreamer one would be nice
<ali1234> ...but
<ali1234> what i really need is the broadcom videocore libraries
<ali1234> that will probably be harder... they normally live in /opt/vc
<kyrofa> Yeah I'm afraid I have no experience with those
<ali1234> i don't think they are even packaged in a deb anywhere
<kyrofa> blackout24, I get that error on a livecd session... you're not doing that by any chance?
<ali1234> kyrofa: okay another question. i noticed you can specify build dependencies inside parts and also outside parts... why is that?
<ali1234> presumably it also works for stage packages?
<kyrofa> ali1234, honestly I'm not quite sure-- there's really no difference
<kyrofa> ali1234, no, stage packages are different
<kyrofa> ali1234, build-packages aren't really part-specific, since they get installed on the host system
<ali1234> hmm
<kyrofa> ali1234, whereas stage-packages become associated with the part in question
<ali1234> i thought it would build everything in a chroot or something
<kyrofa> ali1234, no, unless you use cleanbuild which does it in an lxc
<ali1234> ah okay. so i should probably do that to make sure i didn''t forget about any build deps which i already had installed and forgot to add to the yaml?
<kyrofa> ali1234, indeed, it would certainly catch those
<blackout24> kyrofa, no I ported snapd to Arch Linux. The OnClassic boolean is correctly set to true in release/release.go. I patched it to detect Arch and it works when I fmt.Println() it.
<kyrofa> blackout24, haha, sweet
<blackout24> I'm using systemd-boot as bootloader, but I thought that with OnClassic as true it would just skip the bootloader check
<qengho> "redhat", huh.
<ali1234> kyrofa: http://paste.ubuntu.com/16220152/ is what i got before i ran into the lack of vc libs, is there anything obviously wrong with that so far?
<sergiusens> jdstrand hey, one thing I see about chrome is that it deletes the shm file "code-oss 8001 sergiusens   28u      REG               0,21  4198400      46 /dev/shm/.org.chromium.Chromium.XElnLe (deleted)"
<kyrofa> ali1234, no that looks pretty good actually
<kyrofa> ali1234, however, once you get this working as you expect note that you might very well be able to do away with those stage packages
<kyrofa> ali1234, do you remember when I was talking about the automatic library crawling?
<ali1234> yes, didn't know about that (i wrote this a couple of weeks ago)
<kyrofa> ali1234, ah, okay. So that _should_ mean you don't need library-only stage packages
<kyrofa> ali1234, but it's still fairly new
<ali1234> gstreamer does dynamic load plugins at run time...
<ali1234> and the camsrc part is actually a gstreamer plugin
<kyrofa> ali1234, ah, you may need them then
<kyrofa> Good catch
<kyrofa> You were listening!
<ali1234> as well as the good/bad/ugly
<ali1234> okay i think that's all my questions, thanks
<ali1234> just need to solve this videocore stuff and i think i can handle the rest
<kyrofa> ali1234, you know where we are if you have more questions!
<pedronis> blackout24: no, there's a buglet such that we don't skip some bootloader manipulation on classic
<jdstrand> sergiusens: yeah, I was aware of that
<jdstrand> well, I remember that when looking at Touch
<blackout24> pedronis, so the problem most likely is that there is no systemd-boot support?
<pedronis> there isn't indeed
<pedronis> just grub/uboot
<pedronis> anyway those bootloader manip on classic
<blackout24> I will see if I can work on that.
<pedronis> shoudl go away
<pedronis> in the next weeks
<sergiusens> jdstrand oh shucks, I was wondering if that would lax the security requirements for it a bit :-)
<jdstrand> sergiusens: well, it isn't so much about well-behaved code like chromium, it is about ill-behaved code that could take advantage of the shared access
<qengho> "well behaved"
<jdstrand> heh
<jdstrand> well-intentioned?
<qengho> +1
<sergiusens> jdstrand so I know where to patch chromium; the problem is having it make its way to all the forks
<jdstrand> right, I undertand the problem
<jdstrand> understand
<jdstrand> sergiusens: but that path does not fit with snaps-- it assumes a differently designed system
<example6> Greetings everyone. I'm having trouble with my web server snap starting. When it starts it checks if a specified port is already in-use, and if it is, it quits and tries again. Currently I am able to run it perfectly fine on its own, but when run as a snappy service, it keeps failing, no matter what the port is.
<jdstrand> sergiusens: I'm not saying we won't get something working for this case, just that it isn't obvious
<sergiusens> jdstrand yeah, I understand the issue being on both sides
<example6> I suspect this could be due to systemd trying it again immediately but I could be wrong
<example6> It could also be some strange apparmor permission thing preventing it from taking up a port
<example6> I don't really know where to go from here, so any help would be greatly appreciated.
<jdstrand> sergiusens: note that with the recent shm PR, you can create a file in /dev/shm rather than having to worry about a directory, etc
<sergiusens> example6 have you plugged network-bind?
<example6> sergiusens, I haven't, I'll try that!
<jdstrand> sergiusens: so the path is /dev/shm/snap.$SNAP_NAME.whatever_you_want
<sergiusens> jdstrand yup saw the PR
<jdstrand> that shoudl at least make the patch simpler
<qengho> example6: And "dmesg" might be helpful next time.
<jdstrand> but, still working through it. maybe we'll introduce another interface, not sure. I'm actually tasked with something else atm and will be circling back to these things, perhaps late next week
<example6> qengho, I did check dmesg but didn't see anything related
<plars> elopio: ok, that test that hits a kernel bug for me, but seems to work for you - I can make it work, but only if I run it by hand from *outside* the snap. When I try to run it from within the snap, I hit the problem. Maybe there's some permission/isolation issue here? (I did install with --devmode)
<example6> Is there any way to plug network-bind from package.yaml inside the actual snap? I haven't been able to get snapcraft.yaml to properly initialize the snap as a service
<example6> So i've just been using snappy build .
<zyga> example6: package.yaml?
<zyga> example6: are you using 16.04 or 15.04?
<example6> 15.04
<zyga> example6: there are no interfaces in 15.04
<kyrofa> example6, you should be able to make this work from Snapcraft. Can you pastebin the YAML you're trying to use?
<zyga> kyrofa: ^^ 15.04
<kyrofa> zyga, yeah I know. Should still be able to get a service running in 15.04 :)
<zyga> yep though not with plugs and slots :)
<kyrofa> Right
<zyga> blackout24: I think that what you are doing is extremely cool and useful!
<example6> I'd prefer not to have to udpate ubuntu-core at this point since some other things are depending on this format but from what it sounds like I might not have a choice...
<zyga> come to the dark side, we have cookies and plugs and interfaces
<kyrofa> example6, you don't need to. We're happy to help you with 15.04 stuff, assuming what you're trying to do is possible of course
<kyrofa> example6, did you refer to examples when building your snapcraft.yaml? Maybe this one: https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/shout/snapcraft.yaml ?
<blackout24> zyga, thanks. It's also seems like a good way to sharpen my Go skills. I like Go very much.
<example6> Yes I did, but I need this to run as a service, and daemon: service wasn't having it start at all
<kyrofa> example6, can you pastebin your YAML? Happy to help
<example6> Sure, one sec
<kyrofa> example6, you're probably suffering from the fact that most of our public-facing documentation is on Snappy 16, not 15.04
<kyrofa> example6, so you need to make sure you're referring to examples compatible with 15.04
<example6> The snapcraft.yaml is _very_ simple, I'm just using the Makefile to copy some scripts and premade executables into place and then a wrapper to start them: http://pastebin.com/ppgSnSSz
<example6> But this was pulled from 16.04 documentation I think, and I didn't find anything about using snapcraft that would work with our system
<kyrofa> example6, indeed, that's a Snapcraft 2.x-compatible YAML
<kyrofa> example6, try this:
<example6> I see now that the example you linked is different
<kyrofa> example6, http://pastebin.ubuntu.com/16244497/
<kyrofa> example6, indeed, notice that they're examples from Snapcraft 1.x rather than master
<example6> kyrofa: so that did indeed properly start it as a service. However, it's still failing to bind to any specific port
<example6> I did add plugs: [network, network-bind] to the service
<example6> But since it's 15.04 it doesn't support plugs apparently
<kyrofa> Right, in 15.04 they're caps
<kyrofa> example6, so try caps: [network-service]
<kyrofa> example6, another example (with caps): https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/tomcat-maven-webapp/snapcraft.yaml
<example6> kyrofa, even with the caps it doesn't want to bind to 8080
<kyrofa> example6, what is the error? Care to pastebin your syslog?
<example6> Could this have any relation to my wrapper script copying the executables to /var/lib/apps/.... on the first run?
<example6> Sure
<example6> http://pastebin.com/XL7J02E5
<kyrofa> example6, huh. Have you verified that the specific port ISN'T in use?
<example6> Well, I've changed the port to any number of other arbitrary values
<example6> It just fails with the same message for the different port
<sergiusens> zyga you should check for NULL as well https://github.com/zyga/snappy-runtime-helper/blob/master/snappy.c#L27
<kyrofa> example6, yeah I don't see any snappy-related issues there...
<kyrofa> Those messages are coming from the service itself
<kyrofa> And I don't see any denials or anything
<sergiusens> dholbach https://github.com/seehuhn/moon-buggy/pull/2 or use my branch for better moon-buggy satisfaction :-0
<dholbach> very nice! :)
<example6> Hmm, okay. Thank you for all the help kyrofa.
<sergiusens> dholbach 92kb and saves scores :-)
<sergiusens> works in cleanbuild too ;-)
<dholbach> nice
<dholbach> very nice! :-)
<example6> Is it possible to add a service start/stop delay in snapcraft.yaml or should I just put a sleep in my wrappers?
<example6> In 15.04 to be exact
<example6> I'm having a problem now that my application is looking for a .hidden type folder in /root/ (*since it seems to be run by root) but AppArmor is denying this operation. Is there any cap I can reference to allow this?
<zyga> sergiusens: thanks! good point
<jdstrand> davidcalle: hey, I'm looking at https://developer.ubuntu.com/en/snappy/guides/ and the links under 'Snappy Internals' are all 404s
<example6> Hmm. well I solved the permission problem but it still doesn't want to bind to port 8080.
<example6> If my script is running from /var/lib/apps, does it get denied network access?
<example6> it doesn't say so in syslog
<scherrey> Does snappy use systemd?
<oparoz> scherrey, yes
#snappy 2016-05-06
<zyga> o/
<commander_> hi snappers
<commander_> i need help
<commander_> am trying to pack my qt app for snap store
<commander_> anyone here ??
<commander_> my app is precompiled with qmake can i snap it ??
<commander_> who is on ??
<commander_> i need help
<didrocks> hey commander_! I don't think we have a qmake plugin, but kyrofa and sergiusens would be able to help you in a few hours (they are US-based)
<didrocks> ah, snap
<wsnipex> hi. I'm working on packaging kodi as snap package and have problems getting opengl to work
<wsnipex> it trying to load the intel driver i965_dri.so, but claims the file doesn't exist, while it IS in the snap at the correct location
<wsnipex> here is the console output with LIBGL_DEBUG=verbose: http://paste.ubuntu.com/16252748/
<wsnipex> any pointers would be much appreciated
<zyga> wsnipex: hey
<zyga> wsnipex: looking at your output the thing that jumps at me is this:
<zyga> libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
<zyga> libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
<wsnipex> yeah, the lib is there though
<zyga> note that snaps do not chroot, so your search path has to understand $SNAP
<zyga> also note (play with hello-world.sh) that snap apps don't see your normal /
<zyga> as they get the ubuntu-core snap bind-mounted in various places
<zyga> so you don't see your normal /usr
<zyga> you see the very same ubuntu-core snap /usr
<zyga> the same on desktop and "devices"
<zyga> wsnipex: does this make sense? do you see what I mean?
<wsnipex> thats what I thought. How can I modify the command wrapper that sets LD_LIBRARY_PATH? its always overwritten
<zyga> wsnipex: you can just add one more wrapper
<zyga> wsnipex: we also have SNAP_LIBRARY_PATH but we don't use it for intal AFAIR, it is used for nvidia
<wsnipex> I'm completely new to snaps, so pleae bear with me
<zyga> no worries, we all are :)
 * zyga should publish the next article about snap runtime environment and confinement details
<wsnipex> so, how/where do I add another wrapper?
<zyga> wsnipex: add a new app, say 'sh' and run shell there
<zyga> in that shell experiment with various LD_LIBRARY_PATH values
<zyga> once you know what you want
<wsnipex> albeit I can do it in our own wrapper script, I'd like to change as little in kodi as possible
<zyga> add a new file in the build tree, make sure it gets copied with snapcraft.yaml (using the copy plugin)
<zyga> and change the command of the app you were running originally to run the wrapper
<wsnipex> ah, I see, thanks
<zyga> wsnipex: but first experiment with just a shell, look at how the environment looks like there
<wsnipex> so currently there is no way to directly influence the default wrapper
<zyga> there are two "wrappers"
<zyga> the one in /snap/bin/ made by snappy on install
<zyga> you cannot influence that one
<wsnipex> heh, yes. I mean command-kodi.wrapper
<zyga> and one by snapcraft (command-foo.*)
<zyga> you can freely change that one though that's something snapcraft makes
<zyga> it's just part of snapcraft implementation detail
<wsnipex> I tried that, but my changes were overwritten on snapcraft snap
<zyga> yes, I know, the solution is to add your own wrapper :)
<zyga> run it as the 3rd wrapper
<zyga> sorry, we'll get it more streamlined over time
<zyga> just didn't have the time for 16.04 :)
<wsnipex> no worries
<wsnipex> also the plugins could be more flexible, specially autotools and cmake ;)
<zyga> those are extensible
<zyga> you can have your own local plugins in your tree
<zyga> and snapcraft picks them up
<zyga> it's all python so it is pretty flexible
<wsnipex> yeah, I saw that, just didn't have time to look further into it
<wsnipex> zyga, http://paste.ubuntu.com/16254300/
<zyga> libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
<zyga> same search path?
<wsnipex> I've exported and printed LD_LIBRARY_PATH
<wsnipex> first line, 1st entry
<zyga> I saw that but look at the "search paths" part being indifferent
<zyga> maybe something different
<wsnipex> -rw-r--r-- 5 root root 6561728 Apr 14 21:08 /snap/kodi/100001/usr/lib/x86_64-linux-gnu/dri/i965_dri.so
<zyga> EGL specific probably
<zyga> nothing is looking at that directory
<wsnipex> yeah, it seems to ignore the ld_library_path
<zyga> there's no chroot /usr/lib/x86_64-linux-gnu/dri is _not_ the same as $SNAP/usr/lib/x86_64-linux-gnu/dri
<wsnipex> sure, I get that
<zyga> sorry, this is new ground to me
<zyga> I wish I knew where this is hardcoded
<wsnipex> might have to take this up with intel mesa devs
<zyga> strace it, grep for PATH in sources, look at gdb, poke around
<wsnipex> will do
<wsnipex> and thanks for your help!
<zyga> good luck, ping me back when you get it running
<zyga> I think this should be handled better by the opengl interface
<zyga> just not sure how exactly just yet
<wsnipex> yeah, probably dlopen is not the optimal way
<commander_> hi
<commander_> i snapped a package but didn't got .snap file after successful compilation
<commander_> am using ubuntu 14.04
<commander_> anyone to help here ??
<wsnipex> zyga, got a step further: LIBGL_DRIVERS_PATH: /snap/kodi/100001/usr/lib/x86_64-linux-gnu/dri
<zyga> cooool
<wsnipex> looking at the mesa code brought up this var
<zyga> I'll write this down, perhaps something we should set in snapcraft/snappy by default
<commander_> i snapped a package but didn't got .snap file after successful compilation'
<commander_> guys
<commander_> help me please
<zyga> wsnipex: does it load now?
<wsnipex> so, I now briefly see kodi starting... before it cores :)
<zyga> commander_: please share the log/output in a pastebin
<zyga> wsnipex: strace/gdb helps
<commander_> okay zyga
<zyga> wsnipex: add gdb,strace as parts to your snap
<zyga> (and busybox)
<zyga> shell inside and poke around
<zyga> use: ulimit -c unlimited
<zyga> and cd $HOME to make the core there
<zyga> you can inspect that core later
<zyga> I went through this experience yesterday
<zyga> what helped a lot was fetching specifc libraries with apt-get source
<zyga> and building them with DEB_BUILD_OPTIONS=nostrip
<zyga> so that I would have symbols for gdb
<zyga> this helped me zero on the issue
<zyga> if you want I can also show you a trick that will let you skip snapcract snap part
<zyga> and just work live
<wsnipex> its still something with gfx
<zyga> with a "writable" snap
<zyga> wsnipex: after you install your snap the first time, unmount it (assuming there are no services runing)
<commander_> zyga, http://pastebin.com/cEyUbB5R
<wsnipex> that'd be cool
<zyga> and sudo mount --bind /path/to/your/build/tree/snap /snap/$SNAP_NAME/10000* (the largest revision)
<zyga> then you can run your snap and you can compile/edit/change stuff
<zyga> a bit hacky but nice before we finish $ snap try
<commander_> i got no .snap file
<zyga> commander_: is this with snapcraft on ubuntu 16.04?
<commander_> its on 14.04
<zyga> commander_: can you do snapcraft clean; snapcraft | pastebinit
<commander_> okay wait
<zyga> commander_: show that output to kyrofa or sergiusens though we're a bit busy with sprint prep (me included) so no promises
<commander_> zyga, i cleaned and run snapcraft
 * zyga has to dig out some ram from his 2nd PC, brb
<commander_> okay
<wsnipex> nice trick :)
<commander_> zyga, it is downloading everything again
<commander_> i mean libraries and other stuffs
<commander_> please look and my yaml file once plz
<commander_> zyga,  here it is http://pastebin.com/kbpyv3Y1
<popey> zyga: do we support it on 14.04?
<zyga> popey: no
<commander_> kyrofa,  here is my yaml http://pastebin.com/kbpyv3Y1
<commander_> popey,
<popey> zyga: so.. the fact that commander_ is on 14.04....
<commander_> am keshav bhatt @keshavmail68 from twitter
<zyga> commander_: you need to use 16.04
<commander_> i also unable to upgrade to 16.04 from ubuntu 14.04
<zyga> sergiusens: it would be nice if we could SRU snapcraft to 14.04 that says "use xenial" if it sees plugs/slots
<commander_> popey, i logged in to my dev account on developer portal and it said its disabled , whats the matter ???
<zyga> or something similar to version snapcraft support properly
<popey> commander_: I don't know.
<commander_> zyga, what about my yaml file bro is it  okay ???
<commander_> popey, i mean why will they disable my account for no reason ??
<zyga> commander_: on xenial it might build, the icon is no longer something you set in the yaml, put it in setup/gui
<proteusguy> does snappy use systemd?
<zyga> proteusguy: yes
<proteusguy> zyga, thanx. I don't suppose there's any simple way to eliminate systemd from snappy and use something else?
<commander_> zyga,  i also noticed a bug in snapcraft
<zyga> proteusguy: i don't know, you'd have to explore, I doubt that would be accepted upstream though
<zyga> proteusguy: systemd is used for a number of things
<commander_> zyga, it is unable to build example from launchpad , if it will try do download untrusted packages , i mean if gpg signature is missing for a package it will simply skip download with some apt-get errors .
<zyga> proteusguy: look at the source, there's a lot of things happening there with various places
<zyga> commander_: sorry I cannot help you with 14.04 and snapcraft issues
<commander_> okay i will install ubuntu 16.04 tonight
<commander_> i will talk to you later okay :) thanks for your time bro
<commander_> zyga, bro snap file appeared this time
<commander_> haha
<commander_> its working now
<commander_> thanks
<proteusguy> zyga, that's what I figured. thanx for your reply.
<commander_> it saying snapping \
<commander_> my 2mb app is now 80mb wts that ???
<commander_> is it okay ??
<Chipaca> commander_, what libraries does it use?
<commander_> qt libs
<Chipaca> commander_, only 80mb? quite good
<commander_> its a qt app uses qml and c++
<Chipaca> :-)
<commander_> what ! :D
<Chipaca> commander_, so the 80mb is all of qt and c++ libs
<davmor2> commander_: that's about right then, look at the clock and calculator apps and see how big they are :)
<commander_> and whats the issue with debian packaging it make only a 2mb package
<commander_> haha
<commander_> guys here is my app www.ktechpit.com/ubuntu/ktechpit-com-released-ubuntu-play-store-ubuntu-14-04/
<commander_> if you wana check it out you can download a trial version .
<wsnipex> before I forget:  it might be nice to document how to use snap behind a proxy somewhere, took me a bit to find that overriding systemd config with Environment=http_proxy
<commander_> bye guys i will join later
<zyga> wsnipex: there's an open bug about proxy support
<zyga> wsnipex: we'll have to look at how that should work properly
<wsnipex> well, go supports the http_proxy env var ootb
<wsnipex> but systemd doesn't allow reading those
<zyga> yes but it's tricky because this is the daemon that has to know this :)
<zyga> exactly
<wsnipex> so you have to set it in the systemd.service
<wsnipex> the real issue with systemd is: you cannot have real variables in the systemd environmet
<wsnipex> so you can't do: Environment=http_proxy=$http_proxy
<wsnipex> which is a real pita
<zyga> well that cannot obviously work
<zyga> the reality is that proxy support is more complex than a single global settinhg
<wsnipex> it could, if it was set in /etc/environment and systemd would read that
<zyga> real proxies often require more elaborate setup, if we're fixing proxy we should really make it work
<zyga> not just more work
<wsnipex> best option might be to have snap read it and pass it on to the deamon, if thats possible
<zyga> what if each user has different proxy?
<wsnipex> if snap reads the users env, that'd be no issue
<zyga> what if both users want a different proxy?
<wsnipex> not snapd
<zyga> one snapd services many users
<zyga> anyway all I'm saying is that there's a bug and this is not a trivial thing to solve
<wsnipex> yes, have snap (not snapd) read it
<zyga> brb
<Chipaca> wsnipex, whats the problem with proxies? without making me read all the backlog :-)
<Chipaca> wsnipex, do you have a particular issue that needs addressing?
<Chipaca> or is it a more generic "we should support this" thig
<Chipaca> thing
<wsnipex> snap won't use a system configured proxy
<wsnipex> unless you override the snapd systemd service
<Chipaca> wsnipex, i ask you again, are you having a problem you need solving, or is it an on-principle issue?
<wsnipex> I solved it for me, so the latter
<Chipaca> wsnipex, how did you solve it? editing the .service file?
<wsnipex> I created /etc/systemd/system/snapd.service.d/proxy.conf
<wsnipex> [Service]
<wsnipex> Environment=http_proxy=....
<Chipaca> wsnipex, question for you: would doing, instead, `EnvironmentFile=/etc/environment` solve it for you?
<wsnipex> a little cleaner then editing the actual service file
<wsnipex> that might actually work, let me try
<Chipaca> ah, yes, copying to /etc/ is what i meant by editing (on a snappy core it's your only option)
<Chipaca> wsnipex, followup question is whether instead of that, PassEnvironment=<space-separated list of proxy env vars> works for you
<Chipaca> then we can talk about which approach is best of these two, if they both work
<wsnipex> yes, works
<wsnipex> could be a decent solution
<Chipaca> ogra_, on snappy core is /etc/environment writable?
<wsnipex> but it won't work for users having different proxies
<ogra_> Chipaca, i dont think so ...
<ogra_> (and we should find some other mechanism ... if you need global vars)
<Chipaca> wsnipex, i hear you. Not sure there's much we can do for users with different proxies at this point.
<Chipaca> I mean, passing the info from the user to the server is incredibly tricky
<Chipaca> and most of the time is going to be the wrong thing to do anyway
<wsnipex> PassEnvironment doesn't work
<Chipaca> noted
<Chipaca> ta
<ogra_> per user stuff should come from /etc/profile.d
<wsnipex> didn't even know this
<wsnipex> where should PassEnvironment take the env from?
<Chipaca> wsnipex, systemd
<Chipaca> wsnipex, it's "pass these env vars from systemd to the child"
<Chipaca> ogra_, isn't /etc/profile.d (ba)shist?
<Chipaca> ogra_, ie not something like /etc/environ
<ogra_> well, pam parses it iirc
<ogra_> so it is "loginish" :)
<ogra_> it is where per-user stuff should go :)
<Chipaca> ogra_, /etc/profile.d is parsed by pam? things like /etc/profile.d/bash_completion.sh ?
<Chipaca> that sounds wrong
<ogra_> well, by shell logins
<wsnipex> its parsed by the shell
<wsnipex> uh, maybe pam_env reads them
<ogra_> no, i think that reads ~/.pam_environment only
<ogra_> thats probably the best place to use then :)
<kyrofa> Good morning
<wsnipex> how can I get around: Mount snap "kodi" (cannot find mounted snap "kodi" at revision 100001)
<wsnipex> can I force install somehow?
<ogra_> how did you build it ?
<ogra_> snapcraft ?
<wsnipex> yes, but I had it installed before already
<wsnipex> then following zyga's advice to debug it, umounted it manually
<wsnipex> now I cannot get it to install anymore
<ogra_> hmm, zyga might know a way out then :)
<ogra_> since he got you into this
<wsnipex> where does snapd store its state?
<wsnipex> it clearly thinks its already installed, so if I could purge this somehow..
<kyrofa> wsnipex, may I suggest the reset-state script in https://github.com/zyga/devtools/ ?
<wsnipex> kyrofa, thanks!
<wsnipex> worked
<kyrofa> wsnipex, hopefully once the next release makes it through the SRU process that won't be necessary anymore
<wsnipex> nice
<oparoz> Hey guys, can we use ZFS snapshots in Ubuntu Core to keep track of changes when doing updates/rollbacks?
<ogra_> no
<oparoz> ;(
<oparoz> Why ogra_ ? ZFS isn't available?
<ogra_> Perhaps in the future....
<kyrofa> ogra_, will ZFS be supported at all now that it's in xenial?
<ogra_> right
<kyrofa> Ah
<ogra_> kyrofa, I still don't see it as a good default for embedded.... Beyond that we would indeed need to have support for that in all usespace tools
<ogra_> *user
<ogra_> (and it is only available on 64 bit arches afaik)
<kyrofa> ogra_, ah, right, now I remember a conversation you had with someone else about this a few weeks back
<oparoz> Ah yeah, I kind of forgot the memory requirements...
<oparoz> ARC is super hungry
<ogra_> I think it is a good idea to support it long term... Optionally
<ogra_> but definitely out of scope for the first image
<oparoz> Thanks ogra_
<wsnipex> hmm, how can I disable binary stipping in snapcraft?
<sergiusens> didrocks if commander comes back, tell him to watch the UOS workshop session  :-)
<kyrofa> wsnipex, what bad stuff is happening?
<sergiusens> wsnipex we don't do binary stripping just yet
<sergiusens> we will, we don't :-)
<wsnipex> right, I simply misinterpreted the snap output. Once I disabled stripping in the applikation build, its ok
<wsnipex> now I at least get a gdb trace of my crash: http://paste.ubuntu.com/16258222/
<kyrofa> wsnipex, indeed, as sergiusens mentioned, we will eventually strip (which is why it's named "strip"), so you didn't really misinterpret :)
<wsnipex> is snap restricting access to set locale?
<kyrofa> wsnipex, ah, I know that error!
<kyrofa> wsnipex, are you running this in Ubuntu Core or the desktop?
<wsnipex> desktop
<kyrofa> wsnipex, I'm far from a locale expert so I don't actually know the problem, but one of my snaps had that problem as well and I ended up setting LC_ALL=C.UTF-8 in its wrapper to get around it. I couldn't use anything but C or C.UTF-8. I haven't investigated enough to know who to blame for it though-- the project I was snapping, or something to do with snappy
<kyrofa> wsnipex, sergiusens might have some suggestions, though
<kyrofa> wsnipex, note that ubuntu core _only_ has C and C.UTF-8 locales
<wsnipex> I'm assuming its snappy, since this code is perfectly fine outside of it
<kyrofa> wsnipex, any denials in the syslog?
<wsnipex> I'm running in devmode
<kyrofa> wsnipex, ah, then no :P
<kyrofa> wsnipex, yeah wait for sergiusens. ogra_ might have some suggestions as well
<wsnipex> otherwise it'd hang up way before that ;)
<wsnipex> I'll try setting the locale in the meantime
<didrocks> sergiusens: will do! :)
<wsnipex> oh wow, setting the locale to LC_ALL=C.UTF-8 works :)
<wsnipex> kodi now starts :D
<wsnipex> thanks kyrofa
<kyrofa> wsnipex, sure thing. Sorry for a workaround instead of a solution there-- I want one as well
<wsnipex> yeah, this needs fixing of course, but its great to have it working for now
<wsnipex> I still have a long road with app-armor...
<vila> sergiusens, kyrofa: coverage fixed in the macaroons branch (using ~130 recorded responses), hope that address your concerns
<jdstrand> elopio: hey-- I have a few ideas for integration tests and wanted to pass them along so they could end up on someone's queue somewhere? should I CC others?
<jdstrand> s/somewhere?/somewhere./
<plars> fgimenez: elopio: Hi, I have some more info about that issue I was seeing
<plars> fgimenez: elopio: on that test that hits a kernel bug for me, but seems to work for you - I can make it work, but only if I run it by hand from *outside* the snap. When I try to run it from the snappy-tests snap that I built, I hit the problem. Maybe there's some permission/isolation issue here? (I did install with --devmode)
<fgimenez> plars, elopio mmm not sure, you only hit the problem with one of the tests?
<plars> fgimenez: so far, just that one. I haven't tried going further yet
<fgimenez> plars, that tests exercises the home interface by creating and installing test snap with that plug defined, maybe when you try to install that snap from another one without the plug it might cause problems
<plars> fgimenez:  --devmode doesn't help me here?
<fgimenez> plars, not sure, can you try the networkInterfaceSuite?
<plars> fgimenez: some of them seemed to work, but then I got a bug here:
<plars> sudo snap disconnect network-consumer:network ubuntu-core:network
<plars> [82096.043981] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
<plars> so as soon as it tried to disconnect it
<fgimenez> plars, that's from the snappy-test snap, right?
<plars> fgimenez: yes
<plars> fgimenez: can I just connect somehow to everything once the snap is installed? or do I need to go rebuild with more plugs defined in my snapcraft yaml?
<fgimenez> plars, maybe you can regenerate snappy-test defining all the plugs used by snaps created in the tests (currently home and network)
<fgimenez> plars, yes, once it's generated afaik you cannot connect to additional slots
<plars> fgimenez: I actually already have home defined - is that all the first one should have needed?
<plars> -                    snappy-tests:home
<fgimenez> plars, yes, the home-consumer snap only needs the home plug to be available, but i'm not sure of the behaviour calling it from another snap
<plars> but I also see this in snap interfaces output:
<plars> :home                -
<ogra_> i think you need to manually connect the interfaces
<fgimenez> plars, if you have it already defined and it is failing then that's not the solution of course
<fgimenez> plars, yes, home doesn't autoconnect
<plars> ogra_: fgimenez: so something like: sudo snap connect snappy-tests:home ubuntu-core:home
<ogra_> yeah
<fgimenez> plars, ogra_ yes, that should do, you can check snap interfaces after
<plars> let me retry homeInterfaceSuite.TestPlugDisconnectionDisablesCreate with that set up
<plars> nope, still hit but on disconnect :(
<plars> sudo snap disconnect home-consumer:home ubuntu-core:home
<plars> [  657.125253] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
 * ogra_ guesses you are better off asking zyga or jdstrand here
<fgimenez> plars, maybe zyga can help here ^
<fgimenez> ogra_, yep :)
<jdstrand> plars: can you paste the full trace?
<plars> jdstrand: the original one was here: http://paste.ubuntu.com/16227643/
<plars> jdstrand: but that looks slightly different from what I got now
<plars> https://www.irccloud.com/pastebin/isX3KDXU/
<jdstrand> plars: can you file a bug? jjohansen1, you may want to look at that ^
<jdstrand> plars: in your bug report, can you tar up everything in /var/lib/snapd/apparmor/profiles and /var/cache/apparmor ?
<plars> jdstrand: I'll have to reboot/retry - it's in a snapshotted qemu session right now, and it hangs when I hit this so hopefully there will be something useful there. Where's the best place to file this?
<ogra_> interesting that systemctl doesnt complain about the autopilot stuff ... iirc we dont ship that anymore
<jdstrand> plars: oh, and home-consumer_1.0_all.snap. if that has sensitive stuff in it, feel free to strip out the sensitive stuff (only need the yaml)
<plars> jdstrand: that's all from the snappy integration tests
<jdstrand> plars: https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug
<fgimenez> jdstrand, home-consumer comes from here https://github.com/ubuntu-core/snappy/tree/master/integration-tests/data/snaps/home-consumer
 * jdstrand hopes that /var/lib/snapd/apparmor/profiles has the snap.home-consumer.reader and .writer policy
<plars> jdstrand: you want me to run this like I did before, or after connecting to ubuntu-core:home slot manually?
<jdstrand> whatever gets the kernel bug
<oparoz_> Does security-override works to give access to /proc ?
<plars> jdstrand: they both do :)
<plars> I'll do both
<plars> !
<plars> it's working now - every single time I've run it so far I hit that kernel bug, and now it works
<plars> I wonder if running it as a snapshot made a difference
<jdstrand> plars: its possible sometimes the bug is a crasher and sometimes not. it is clear there shouldn't be a bug and the bug if it doesn't crash now may cause instability and other problems
<plars> ok, I got it to reproduce this time
<plars> by running the whole suite
<plars> jdstrand: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135
<ubottu> Launchpad bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,New]
<plars> jjohansen1: also ^ https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135
<jdstrand> plars: awesome, thanks!
<jdstrand> plars: I left a couple of questions for you in the bug
<jdstrand> (fyi)
<ssweeny> jdstrand, any chance of a review for https://github.com/ubuntu-core/snappy/pull/1118 today? I'm going on holiday next week and I'd like to have this resolved if we can
<jdstrand> ssweeny: I might be able to. I'm working on something else but I think I can get it done before eod. note, the snappy guys are sprinting next week and seem to be traveling today, so not sure how all that will impact your plans
<ssweeny> jdstrand, fair enough
<blackout24> I have snappy working on Arch Linux now. Kind of. The problem was that after implementing another check to see if snappy is used on a classic system it tries to do some bootloader stuff upon installing ubuntu-core. Since I didn't use grub it always just exited at that point. For simplicity I just installed grub without actually using it. Now it downloads and installs all the snaps.
<blackout24> apparmor_status even shows that there are some profiles loaded now.
<blackout24> Only problem is that a) for some reason /snap/bin isn't in my PATH despite installing apps-bin-path.sh in my profile.d and b) when I try to run ubuntu-calculator-app.calculator it wants root, while on a 16.04 test machine it doesn't. It also fails with "aa_change_onexec failed with -1. errmsg: No such file or directory"
<blackout24> Adding support for systemd-boot is a little tricky since it's so minimalistic that it doesn't have an env file for variables. You'd probably have to implement a lot of string manipulation magic to essentially emulate that. Also the actual boot entry is a *.conf file in /boot/loader/entries. It can be named however you want. There is no sdboot.cfg for this or something.
<blackout24> Ahh I see on 16.04 /usr/bin/ubuntu-core-launcher has different permissions
<ssweeny> jdstrand, thanks for the review! I'm looking at adding the label=###PLUG_SECURITY_TAGS### string and it needs a new helper function. My question is what should that string look like at the end. The function for slots includes all the bound apps but that doesn't seem right to me for this
<jdstrand> ssweeny: the plugs side gets all the connected slots. the slots side (what you are looking to add) are all the connected plugs
<ssweeny> jdstrand, ok, so it would still be something like "snap.name.app" or "snap.name.{app1..appn}" or "snap.name.*"?
<jdstrand> the actual format of that string should be like what ###SLOT_SECURITY_TAGS### is. if one snap/app, then no alternation, if all apps within a snap, then a glob (.*) and it multiple snaps, alternations with globs as needed
<jdstrand> yes
<jdstrand> but in this case you might end up with {snap.name1.{app1..appn},snap.name2.*,snap.name3.app}
<jdstrand> does that make sense?
<jdstrand> it is because multiple snaps can plug into a slot. the other way there was only the one slot provider
<ssweeny> ah
<ssweeny> ok
<plars> jdstrand: I'm not sure I understand your comment - I'm not trying to simply install that snap, I'm trying to run one of the integration tests in snappy, which I've packaged in another snap. The integration test does install that home-consumer snap as part of it, but that's just one piece of what it's doing. And it doesn't seem to be the installation of the
<plars> snap that's causing the problem
<jdstrand> I was trying to get at a simple reproducer. perhaps it would help if jjohansen1 was involved
<jjohansen1> blackout24: what is logged in dmesg?
<jjohansen1> what kernel, and which apparmor patchset (if any)?
<plars> jdstrand: I'll see if I can come up with something simpler
<jjohansen1> a dump of apparmor/features would be good too
<ssweeny> jdstrand, from what I can tell the ConnectedSlotSnippet only gets a reference to one plug, so I guess there will be multiple snippets, one for each attached plug?
<jjohansen1> jdstrand: uhm which of the 3 issues did you want me to jump in on?
<ssweeny> jdstrand, so each snippet will only have one snap with 1..n possible apps
<blackout24> jjohansen1, I just rebuilt the stock ARCH kernel with CONFIG_AUDIT and and apparmor Kconfig flags. The version is 4.5.1 so it should be the latest upstream apparmor.
<blackout24> I also packaged the latest upstream libapparmor and libseccomp
<jjohansen1> blackout24: okay, I think there is a bug fix for change_profile that is needed for that kernel
 * jjohansen1 goes digging
<jdstrand> ssweeny: I'm not sure. I'm not sure this subtlety was considered
<ssweeny> interesting
<ssweeny> I can't see any difference in the way the snippets go into the FS
<jdstrand> ssweeny: if it helps, you could treat it like ###SLOT_SECURITY_TAGS### for now and then ask the question in the PR for zyga to pick up when he is back online
<ssweeny> they're all just appended to the slot profile
<ssweeny> jdstrand, I'll give that a go
<jdstrand> and I'll jump in and help guide that discussion
<blackout24> I stepped through ubuntu-core-launcher and it fails in line number  562 where it uses aa_profile as parameter, which is taken from the second parameter when the app is launched through the helper script. The Apparmor profiles all seem to be in place.
<jdstrand> blackout24: that suggests the profile isn't loaded
<blackout24> Yes because  "aa_change_onexec failed with -1. errmsg: No such file or directory", but the profile should be there if it wants to load it.
<jdstrand> blackout24: that error is somewhat misleading. it isn't able to change_onexec because the profile isn't loaded into the kernel. the launcher doesn't load the profile into the kernel, snap install does
<jdstrand> blackout24: what is the output of apparmor_parser -QTK /var/lib/snapd/apparmor/profiles/snap.your.profile?
<ssweeny> jdstrand, ok, the line I end up with is peer=(label="snap.location-service.{example-client,example-service,location-service-cli}") and apparmor doesn't like that: 5Z ERROR cannot setup apparmor for snap "location-service": cannot load apparmor profile "snap.location-service.location-service": cannot load apparmor profile: exit status 1
<ssweeny>                                                                apparmor_parser output:
<ssweeny>                                                                AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.location-service.location-service in /var/lib/snapd/apparmor/profiles/snap.location-service.location-service at line 309: dbus rule contains message conditionals and service conditionals
<jjohansen1> blackout24: hrmmm, I didn't find what I was looking for yet. It could have been a userspace error, I will keep looking
<jdstrand> ssweeny: can you paste the full rule?
<blackout24> jdstrand, this command just returns without printing anything. apparmor_status says module is loaded and 1 profiles are loaded.
<blackout24> snap.notes.notes is in enforce mode, but I try to run the calculator app at the moment. notes doesn't work, yet either.
<jdstrand> blackout24: ok so the userspace is ok. what is the output of apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.profile? (that shoudl be run as root)
<jdstrand> ssweeny: you can paste the whole profile if you want
<blackout24> Also returns without printing anything
<blackout24> But apparmor status now says that 2 profiles are loaded
<jdstrand> blackout24: and aa-status shows that 'snap.your.profile' is loaded in the kernel?
<blackout24> And lists the calc app profile which I used for your command
<ssweeny> jdstrand, nevermind, I had the replacement string in one too many places. It seems to work now
<blackout24> 2 profiles are loaded. 2 profiles are in enforce mode. <lists the notes profile and calculator profile now>
<jdstrand> blackout24: I suspect the launcher will get farther along now
<jdstrand> blackout24: assuming what you are trying to launch corresponds to one of those two profiles
<jdstrand> :)
<jdstrand> ssweeny: ack
<blackout24> Yes. Now it fails with execv failed: No such file or directory. Will have to strace or ltrace that.
<jdstrand> blackout24: ok-- note there is a problem with snapd not loading the profile into the kernel during snap install that you'll have to debug
<jdstrand> blackout24: look at interfaces/apparmor/apparmor.go for details on what it is doing
<jjohansen1> blackout24: that could be a different bug where apparmor is returning -ENOENT when the target profile is not found (I have patch in the upstream queue for that)
<jjohansen1> blackout24: what is the message from apparmor in dmesg?
<blackout24> jjohansen1, http://pastebin.com/8Y1diFRJ
<jdstrand> blackout24: are you using an upstream kernel or one with newer apparmor patches?
<jjohansen1> upstream
<blackout24> 4.5.1 without any patches. I rebuilt it from the official PKGBUILD on ARCH and just changed 4 Kconfig switches
<jjohansen1> blackout24: thts it? It is missing at least one message
<jdstrand> blackout24: I very much doubt you are going to have success with a pure upstream kernel at this time
<jjohansen1> there should be something from change_profile or exec
<jdstrand> beyond apparmor
<jdstrand> well, maybe with 4.5.1 it is primarily apparmor
<blackout24> Packaging a new kernel with a handful of extra patches would not be a problem. I would adopt linux-apparmor in the Arch User Repo which is currently unmaintained and ship the extra patch to also make snappy run
<jdstrand> but assuming you can get it to work, you won't have dbus, ptrace, signal and unix mediation
<jdstrand> I see
<jdstrand> well, there are patches for 4.4 (Ubuntu has 4.4), I don't know the status of the 4.5 patchset
<jdstrand> and we're working to get these bits upstream
<jdstrand> but that'll take a while
<blackout24> I could easily just set the package version to 4.4.0 and download the 4.4.0 kernel sources and apply the patchset.
<jdstrand> I'll let jjohansen1 comment on how to get the patches. they are in a git tree somewhere
<blackout24> The kernel doesn't have to be as recent as the official ARCH kernel, which will remain untouched on the system anyway.
<jjohansen1> blackout24: for the apparmor bits git://kernel.ubuntu.com/~jj/linux-apparmor-backports
<jjohansen1> you are looking for the v4.X-aa3.5-beta1 branches
<blackout24> jjohansen1, thanks
<ssweeny> jdstrand, I believe I've addressed all of your comments
<blackout24> jjohansen1, it doesn't let me clone it for some reason. fatal: remote error: access denied or repository not exported: ~jj/linux-apparmor-backports
<jjohansen1> blackout24: oops I stuck a ~ in there, thats only for the http version of the url
<jjohansen1> git://kernel.ubuntu.com/jj/jj/linux-apparmor-backports
<jjohansen1> urgg
<blackout24> thanks
<jjohansen1> lets try again
<jjohansen1> git://kernel.ubuntu.com/jj/linux-apparmor-backports
<blackout24> jjohansen1, something is still not working fatal: remote error: access denied or repository not exported: /jj/jj/linux-apparmor-backports
<jjohansen1> blackout24: see that last url, I managed to double up the jj/ in the one you just tried
<jjohansen1> the weekend can't come soon enough
<blackout24> haha yeah I know that feeling
<blackout24> cloning...
<qengho> ubuntu-device-flash says "expected a gadget snaps: snap not found". Specified "canonical-pi2". What gives?
#snappy 2016-05-07
<wsnipex> hi
<wsnipex> how does one specify apparmor/seccomp policies after old-security was removed in snap?
<wsnipex> sergiusens, ping
<blackout24> jjohansen1, I made a package from your git branch. However I still get an execv error after loading the aa profile into the kernel. I stepped through ubuntu-core-launcher with gdb and it loads all the seccomp rules and aa profiles and after around 16000 steps fails in main at:
<blackout24> 585		execv(binary, (char *const *)&argv[NR_ARGS]);
<blackout24> (gdb) print binary: $6 = 0x7ffdcb8d9508 "/snap/ubuntu-calculator-app/5/command-calculator.wrapper"
<jjohansen1> blackout24: any messages in dmesg?
<blackout24> I don't understand why I get "execv failed: No such file or directory", when this file is present in that location
<blackout24> jjohansen1, http://pastebin.com/raw/4PH7aRxH That must have been from when I apparmor_parser -r'ed the profile
<blackout24> before that it wasn't loaded according to apparmor_status
<blackout24> now I have
<blackout24> 1 profiles are loaded. 1 profiles are in enforce mode. snap.ubuntu-calculator-app.calculator
<jjohansen1> blackout24: can you paste the output of
<jjohansen1>   sudo cat /sys/kernel/security/apparmor/profiles
<blackout24> snap.ubuntu-calculator-app.calculator (enforce)
<blackout24> that's the whole output
<blackout24> I don't think that it's a problem with the apparmor side, since it fails at the excecv part in main.c in ubuntu-core-launcher, which seems to be past the whole profile loading stuff from stepping through it
<jjohansen1> so what I am seeing from the log is snappy is doing the change_onexec to snap.ubuntu-calculator-app.calculator before the profile is loaded
<blackout24> ahh ok
<jjohansen1> notice the DENIED entry comes before the STATUS profile_load
<jjohansen1> change_onexec is returning -2
<jjohansen1> which is enoent
<blackout24> I used the v4.5-aa3.5-beta1 branch from your git tree. Just cloned it and compiled it.
<jjohansen1> so that may be why you are seeing an enoent
<jjohansen1> blackout24: right, this isn't a kernel problem
<jjohansen1> I have no idea why that change_onexec is coming before the profile is loaded
<jjohansen1> but the kernel won't find the profile is it isn't loaded
<blackout24> There was a problem with security/apparmor/include/domain.h I had to change line 18 into #include "label.h" (was #include "include/lable.h"), but the lable.h is in the same dir.
<blackout24> Otherwise the kernel wouldn't compile
<jjohansen1> blackout24: doh, we do have a patch for that, I must have dropped it from the branch
<jjohansen1> I'll make sure to get that cherry-picked
<blackout24> jjohansen1, I think I managed to get a little bit further with getting snappy to run on Arch. Maybe. ubuntu-core-launcher has its own profile which I installed to /etc/apparmor.d/usr.bin.ubuntu-core-launcher. However these profiles don't seem to get automatically pickedup so I parsed it manually.
<blackout24> Now trying to run the calculator app gives me:
<blackout24> /usr/bin/ubuntu-core-launcher: error while loading shared libraries: libapparmor.so.1: cannot open shared object file: Permission denied
<blackout24> ubuntu-core-launcher is setuid root on my system just like on 16.04
<blackout24> That's the dmesg: http://pastebin.com/raw/jyxDs6Ra
<blackout24> brb
<blackout24> Mhh one of the biggest problems when trying to get snappy to work on Arch Linux is that apparmor restrictions don't seem to work on symlinks. Ubuntu and Debian still have the libs scattered around /lib /lib64 /usr/lib etc. On Arch and Fedora the first two are just symlinks to /usr/lib and everything is installed there.
<blackout24> The usr.bin.ubuntu-core-launcher profile in /etc/apparmor.d for example restricts the access to /lib/@{multiarch}/libapparmor.so* to mr. I deleted the @{multiarch} part since /lib/apparmor.so* and /usr/lib/libapparmor.so* are still the same thing on Arch. I reparsed the profile, but still got access denied for this shared object. Only writing /usr/lib/libapparmor.so* in the profile worked.
<zzarr> hello!
<zzarr> is it possible to make a snap package that uses the gpu?
#snappy 2016-05-08
 * ogra_ is off to the airport
#snappy 2017-05-01
<chatter29> hey guys
<sborovkov> Hi, is 2.24 in stable now?
<Son_Goku> sborovkov: should be
<sborovkov> Son_Goku: nope :-(
<Son_Goku> it was supposed to go out last Monday on Ubuntu
<Son_Goku> it's certainly out on Fedora
<sborovkov> not on armhf at least
<sborovkov> snap info co
<sborovkov> installed:   16-2 (1580) 69MB -
<sborovkov> refreshed:   2017-03-29 14:05:52 +0000 UTC
<sborovkov> channels:
<sborovkov>   stable:    16-2 (1580) 69MB -
<sborovkov> snap --version
<sborovkov> snap    2.23.6
<mup> PR snapd#3257 closed: tests: specify the auto-refreshable snap being tested <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3257>
<zyga> good morning
 * zyga is doing house cleaning tasks
<zyga> sborovkov, Son_Goku due to travel/holidays it will probably happen early this week but I don't know
<zyga> AFAIK only jamie bennett can promote to stable
<niemeyer> Mornings
<niemeyer> Sprint kicking off here
<Son_Goku> moo
 * Son_Goku is cleaning up for travel
<Son_Goku> le sigh
<Son_Goku> the spring/summer months are always full of travel
<moti> Hello guys
<moti> I ran ubuntu core 16.04 on my PI3.
<moti> controllingthe Pi with laptop(over ssh), and want to know how can i use gui apps like "ubuntu-calculator-app"
<moti> i can find this app in luncher of the ubuntu on the laptop
<moti> but there is no any gui in ubuntu core!
<moti> http://paste.ubuntu.com/24492481
<moti> the calculator has installed but i dont know how to use it.
<Blu2> from the dscription: "Ubuntu Core is a tiny, transactional version of Ubuntu for IoT devices and large container deployments"
<Blu2> https://www.ubuntu.com/core
<moti> you mean there is no chance to run gui apps?
<Son_Goku> well, there's Mir support, but beyond that?
 * Son_Goku shrugs
<Blu2> The calculator would require a display server and wm, I guess
<Son_Goku> you'd need to configure a Unity 8 session
<Son_Goku> as far as I know, Unity 8 is the only thing that currently works on Snappy Ubuntu
<moti> but the "unity" or "x11" are not availablein the iterfaces list of snappy on raspberry
<Son_Goku> unity is for unity7
<moti> while it is available on x64 pc
<Son_Goku> the unity interface isn't available on Ubuntu Core on x86 either
<Son_Goku> only on Ubuntu Classic
<moti> yea, i just checked!!!!(but how the gui snaps work)
<moti> anyway, how can i configure the the unity 8 ?
 * Son_Goku shrugs
<Son_Goku> I think you'd have to install the unity 8 session snap
<moti> OK, got it
<moti> but as final question, it has any stable version instead of edge?
<moti> @Son_Goku, thank you for helping
<nothal> moti: No such command!
<moti> xxx ^_^
<Son_Goku> moti: no
<Son_Goku> there likely will never be :(
<moti> Yea, i read on web
<moti> Its 6 pm here and i got tired, going for a movie, good bye guys.
<jdstrand> Trevinho: hi! thanks for the updates to the preload plugin. not sure if you saw, but I filed https://github.com/sergiusens/snapcraft-preload/issues/13
<zyga_> hey
<Pharaoh_Atem> zyga_: https://paste.fedoraproject.org/paste/NmsFYMd2WEStihK1ATvizV5M1UNdIGYhyRLivL9gydE=
<Pharaoh_Atem> shellcheck fails the scripts in snapd 2.25 :/
<ogra_> Pharaoh_Atem, was that script recently added ?
<ogra_> (the test script)
<mup> PR snapd#3255 closed: tests: set ownership of $PROJECT_PATH for the external backend <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3255>
#snappy 2017-05-02
<anuragh>  #blackarch
<zyga_> good morning
<zyga_> Pharaoh_Atem: looking :/
<mup> PR snapd#3248 closed: tests: fail early in the spread suite if trying to run it inside a container <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3248>
<zyga_> aha, not great
<zyga_> Pharaoh_Atem: I'll fix that in a sec, thanks for reporting
<pstolowski> hey zyga_ !
<zyga_> pstolowski: hello
<zyga_> Pharaoh_Atem: offtipic, can I propose rawhide packaging for inclusion into packaging/
<zyga_> Pharaoh_Atem: it will be useful for CI soon
<morphis> zyga: we can't yet
<zyga> morphis: because of patches/
<morphis> zyga: we still miss changes to get snap-confine building
<zyga> morphis: we can add the actual patches too you know
<morphis> zyga: but I have things locally and will submit PRs soon
<zyga> aha ok
 * zyga pushed the fix for shellcheck
<zyga> now where's my github token :/
<morphis> unless we have initial CI I would like to held the .spec file back
<morphis> as only then it has value inside the tree
<morphis> zyga: but if you have a good idea of how we can solve the problem http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/0001-cmd-use-libtool-for-the-internal-library.patch solves, that would be awesome :-)
<zyga_> Pharaoh_Atem: https://github.com/snapcore/snapd/pull/3258
<mup> PR snapd#3258: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <https://github.com/snapcore/snapd/pull/3258>
<mup> PR snapd#3258 opened: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <https://github.com/snapcore/snapd/pull/3258>
<zyga_> pstolowski: this needs a 2nd trivial review https://github.com/snapcore/snapd/pull/3234
<mup> PR snapd#3234: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <https://github.com/snapcore/snapd/pull/3234>
<pstolowski> ok
<zyga> morphis, Pharaoh_Atem: is that shellcheck fix something you can easily carry in the tree?
<zyga> (as a pathc)
<zyga> patch
<morphis> zyga: I think Pharaoh_Atem is fine as long as we have a PR or the PR merged upstream
<mup> PR snapd#3230 closed: tests: extend network-control spread test to cope with network namespaces <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3230>
<morphis> zyga: do you have a raspbian system at hand?
<Chipaca> morphisâ out of curiosity, for what?
<morphis> Chipaca: snapd packages :-)
<zyga> morphis: yes
<zyga> well
<zyga> on a pi1
<zyga> but I can (probably) move that to a pi2/3 easily
<morphis> zyga: hm, would be nice to see the error message on the pi1
<zyga> error message about?
<morphis> zyga: that we don't have a suitable core snap for the pi1
<morphis> I guess it will try to load the armhf one but not sure
<mup> PR snapd#3234 closed: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3234>
<zyga> morphis: I think it will just fail, let me try
<zyga> pstolowski: thanks!
<morphis> zyga: yeah
<zyga> pi1 is so slow...
<morphis> :-)
<Chipaca> zygaâ remember snap 1 on the bbb?
<Chipaca> or weren't you around for that
<Chipaca> snappy*
<zyga> Chipaca: snap 1 as in 15.04 snapd?
<Chipaca> snappy --help
<pstolowski> zyga, yw
<Chipaca> <30 seconds waiting>
<zyga> Chipaca: I recall it was slow :D
<zyga> was that in python or all go already?
<Chipaca> snappy was python
<zyga> heh
<zyga> nice :D
<Chipaca> and the slow was the main driver for the move to go
 * zyga would love to see python code of snappy
<Chipaca> zygaâ no, no you wouldn't
<Chipaca> but it's in git :-)
<Chipaca> zygaâ this was pre-overlord, so the fs was the transaction layer
<zyga> was is terrible?
<zyga> aaaaha :D
<zyga> remember the 16.04 push to make the insanity go away?
<zyga> morphis: let me update first, I'll install snapd shortly
<morphis> zyga: let me upload the repo first
<zyga> morphis: which repo is that?
<morphis> zyga: deb https://mm.gravedo.de/raspbian/ jessie main
<zyga_> morphis: fyi, raspbian already has snapd
<zyga_>         500 http://archive.raspbian.org/raspbian stretch/main armhf Packages
<morphis> zyga: stretch does, yes
<zyga_> 2.21-2
<morphis> zyga: that is currently in rc
<morphis> so everyone out there is still using raspbian based on debian 8
<morphis> which doesn't have it
<morphis> and a stable raspbian based on debian 9 is still months away
<morphis> zyga: what you officially get from the pi foundation is jessie: https://www.raspberrypi.org/downloads/raspbian/
<morphis> zyga: are you running stretch then on your pi?
<zyga_> morphis: yes
<zyga_> morphis: well, not stretch, but raspbian + jessie/wheezy/stretch raspbian archives
<morphis> sounds hacky :-)
<morphis> zyga: however, if you add the repository you should get snapd 2.24
<pstolowski> zyga, have you seen the failures in master? https://forum.snapcraft.io/t/tests-broken-in-master/457
<zyga_> pstolowski: no, looking now
<zyga_> pstolowski: can you please edit your post to use formatting
<morphis> zyga_: once I did some more testing I will make a post in the forum to call for wider testing
<zyga_> morphis: ^ did you see that failure? update test hangs on debian
<morphis> zyga_: which failure?
<morphis> pstolowski: you have a link to the test run on in travis?
<pstolowski> zyga, done; i thought I did by using ` , but apparently it's not enough
<pstolowski> zyga, https://travis-ci.org/snapcore/snapd/builds/227867834?utm_source=email&utm_medium=notification
<zyga_> pstolowski: I think you need ```
<pstolowski> i'm not sure it's from the same travis run, but failed the same I think
<zyga_> pstolowski: so...
<zyga_> pstolowski: I think we rejected one fix that may be the cause here
<pstolowski> it got stuck on Run configure hook of "core" snap if present
<morphis> zyga, pstolowski: so this is running 2.21 and installing the core snap from stable
<morphis> zyga, pstolowski: sounds very muhc like https://bugs.launchpad.net/snappy/+bug/1674193
<mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:Fix Committed by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<pstolowski> morphis, indeed it's an upgrade from old version. but I wonder why it's failing now, i don't think it's a new test?
<morphis> pstolowski: did we release a new core snap to stable recently?
<pstolowski> or rather, any new conditions
<pstolowski> dunno
<morphis> zyga_: any idea?
<zyga_> morphis: yes
 * zyga_ looks for the PR
<zyga_> https://github.com/snapcore/snapd/pull/3145
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3145>
<morphis> zyga_, pstolowski: ok, can reproduce the same problem on my debian install
<zyga_> look at https://github.com/snapcore/snapd/pull/3145/commits/71ce65eb95b3210515a8c81f4737e5c3d9bd18fb
<zyga_> so we rejected that PR
<zyga_> let me try to recall the rationale
<zyga_> https://github.com/snapcore/snapd/pull/3145#discussion_r110766622
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3145>
<pstolowski> zyga, looking at your last comment, you had a simpler variant merged?
<zyga_> so the question is, why did the slot not auto-connect after restarting into new snapd?
<morphis> zyga: with a core snap from edge the problem doesn't exist
<morphis> a $ snap install core fails and a $ snap install --edge core works
<zyga_> morphis: how about edge?
<zyga_> er
<zyga_> beta
<morphis> zyga: what do we have currentl in stable?
<zyga_> morphis: no idea
<zyga_> morphis: the version field is useless
<morphis> wonderful ..
<zyga_> ogra_: hey
<ogra_> zyga_, yo
<zyga_> ogra_: is the snapcrat feature that would let us give real and sensible verison available now
<pstolowski> shall we take this conversation to https://forum.snapcraft.io/t/tests-broken-in-master/457?
<zyga_> ogra_: so that "snap info core" shows the snapd version there?
<ogra_> zyga_, not sure if it landed with the last drop
<morphis> zyga_: beta works too
<ogra_> zyga_, if it did i have to do a few changes first ... the bug wasnt closed but perhaps thats just an oversight from sergio
<zyga_> ogra_: aha, thanks
<zyga_> morphis: ok, then when 2.25 is released this should be fixed
<morphis> zyga: right
<morphis> however that wont help us to get CI back working on master
<morphis> zyga_: unless we do a $ snap install --beta core for debian during the test run
<zyga_> morphis: I think that's a reasonable compromise for now
<morphis> let me do a PR
<zyga_> is federico working today? I'd like to know his opinion
<zyga_> morphis: please do, thanks!
<zyga_> pstolowski: yeah, let's summarize on the forum
<zyga_> we can paste this converstation
<morphis> zyga_, pstolowski: https://github.com/snapcore/snapd/pull/3259
<mup> PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259>
<morphis> pstolowski: can you summarize the discussion in the forum?
<mup> PR snapd#3259 opened: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259>
<pstolowski> morphis, will do
<zyga_> morphis: hmm
<zyga_> morphis: so one question
<zyga_> morphis: after 2.25 is out it won't change anything in debian
<zyga_> morphis: because debian is frozen, right?
<zyga_> morphis: so I'm trying to understand one thing there
<zyga_> morphis: the test installs some debs
<zyga_> morphis: are they not the same as snapd in edge?
<zyga_> morphis: (except for the name of the plug?)
<zyga_> morphis: what I'm trying to say is that perhaps, if we get this rigth, the change is not needed, no need to special-case debian
<zyga_> morphis: I think some code may be missing from master
<zyga_> morphis: master contains code that renames core-support to core-support-plug
<zyga_> morphis: so it should work
<morphis> why?
<morphis> better asked, why -plug as suffix?
<pstolowski> morphis, zyga_ summarized the discussion in the forum, let me know if i missed anything
<zyga_> morphis: to keep plug and slot names distinct
<morphis> zyga_: isn't is already imminent for a plug that it is a plug?
<Son_Goku> ogra_: in re yesterday's question about test script, I don't know
<Son_Goku> maybe?
<Son_Goku> the shellcheck thing has always been there, though
<Son_Goku> it passed in 2.24
<Son_Goku> zyga_, morphis: https://paste.fedoraproject.org/paste/NmsFYMd2WEStihK1ATvizV5M1UNdIGYhyRLivL9gydE=
<Son_Goku> shellcheck test fails on 2.25
<ogra_> Son_Goku, to late ... fix is alÃ¶ready pending
<ogra_> :)
<Son_Goku> ogra_: is there an active PR?
<ogra_> (zyga works in his sleep :P )
<ogra_> https://github.com/snapcore/snapd/pull/3258
<mup> PR snapd#3258: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <https://github.com/snapcore/snapd/pull/3258>
<Son_Goku> excellent :D
<Son_Goku> well... not so excellent
<Son_Goku> what the hell happened to spread/travis?
<Son_Goku> oh, welp
<morphis> Son_Goku: from what I experienced so far there are differences between shellcheck on Ubuntu and others
<ogra_> also the version plays a role
<Son_Goku> yeah, shellcheck runs are disabled on F24 and older
<ogra_> the 14.04 shellcheck is pretyt crappy ... not sure what versioon that was thopugh
<Son_Goku> because shellcheck < 0.4.4 doesn't actually support -x
<ogra_> my trees all install a 16.04 chroot when doing shellcheck
<Son_Goku> Fedora 24 and EPEL 7 have shellcheck 0.3.x, which can't actually run the tests :/
<ogra_> is pedronis around today ?
<ogra_> manually upgrading a pi3 gets me "[/] Setup snap "core" (1829) security profiles (phase 2)" ... forever .... shell prompt never returns
<ogra_> (pretty much like described in one of the forum threads)
<Son_Goku> wut
<Son_Goku> this PR somehow breaks Fedora builds
<zyga_> Son_Goku: fixed
<zyga_> Son_Goku: sorry, the patch had a broken file inside by accident
<Son_Goku> take 4
<Son_Goku> good, gobuild is fixed
<Son_Goku> now we're at C build
<Son_Goku> shellcheck passed... good
<zyga_> Son_Goku: yeah, sorry about the earlier patch
 * zyga_ feels like he has cold :/
<ogra_> zyga_, dude ... i tend to test stuff before commenting ... shellcheck didnt disagree ;)
<ogra_> but leave it ugly if you feel like ;)
<zyga_> ogra_: I think it may be different version then, I did fix all the things shellcheck reported
<zyga_> ogra_: I tested on F26
<ogra_> ah
<zyga_> I wanted to have a patch that would be clean for fedora packaging
<ogra_> well, newer ubuntu versions might spill a warning there
<zyga_> btw, I think shellcheck would disagree about $FOO/"whatever" but I may be worng
<zyga_> warning?
<ogra_> yeah
<zyga_> about extra quoting?
<Son_Goku> zyga_: I think shellcheck would be fine with "$FOO/whatever", though
<ogra_> about possible interpretation as: "$TMP/$(basename "     $0     ")"
<Son_Goku> well, for inner quotes, shouldn't you use a different quote for the inner one?
<ogra_> anyway, if it doesnt complain now, leave it
<Son_Goku> like single quotes for inner and double for outer
<ogra_> technically just quoting $0 is enough
<zyga_> Son_Goku: no, that's actually correct
<zyga_> Son_Goku: $() gives new quoting context
<Son_Goku> zyga_: ah
<Son_Goku> shell is confusing :)
<zyga_> Son_Goku: "$(echo "This is $(echo "ok")")"
<zyga_> yes
<Son_Goku> well, I'm about ready to commit my 2.25 package
<zyga_> +1
<Son_Goku> unless there's any other patches I need besides PR3222 and PR3258 (though I don't need the latter)
<zyga_> Son_Goku: not sure, I don't know of any
<Son_Goku> well, I guess that's what testing updates is for :)
<Son_Goku> I've also created a snap-mgmt script that will be run on %preun on final removal
<Son_Goku> based on the snapd.postrm script
<Son_Goku> so that will need specific testing
<Son_Goku> zyga_, morphis: building: https://koji.fedoraproject.org/koji/taskinfo?taskID=19367859
<morphis> Son_Goku: awesome!
<zyga_> Son_Goku: thank you
<Son_Goku> building on all Fedora branches now
<Son_Goku> zyga_: there are some advantages to building for an upstream distro that moves fast :)
<Son_Goku> I hate armv7hl builds :(
<Son_Goku> they need to fully move over to the VMs on aarch64 hosts
<Son_Goku> those are so much faster...
<zyga_> Chipaca: hey
<Chipaca> zyga_â hi
<zyga_> Chipaca: can you please review https://github.com/snapcore/snapd/pull/3259
<mup> PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259>
<zyga_> Chipaca: master is currently broken because of htis
<zyga_> Chipaca: howerver plase note what I said above:
<zyga_> Chipaca: actually let me add that to the forum
<Chipaca> zyga_â you said a lot of things above. Which is the note?
<zyga_> https://forum.snapcraft.io/t/tests-broken-in-master/457/6
<zyga_> I want to fix master but I'm not sure this is the actual fix
<zyga_> and that we're not missing anything
<Son_Goku> zyga_, morphis: https://bodhi.fedoraproject.org/updates/FEDORA-2017-866e9643a8 (F24), https://bodhi.fedoraproject.org/updates/FEDORA-2017-2e4459fa03 (F25), https://bodhi.fedoraproject.org/updates/FEDORA-2017-74f7c7df46 (F26)
<Son_Goku> morphis, zyga_: please specifically test final removal of snapd *after* upgrading or installing v2.25
<Son_Goku> source script: https://src.fedoraproject.org/cgit/rpms/snapd.git/tree/snap-mgmt.sh
<Son_Goku> install step: https://src.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n434
<Son_Goku> scriptlet execution: https://src.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n568
<zyga_> Son_Goku: ack, will do
<morphis> Son_Goku: will do!
<Son_Goku> this is specifically for solving https://bugzilla.redhat.com/show_bug.cgi?id=1444422, so that's what this aims to fix
 * Son_Goku hopes the patch load doesn't get any bigger on snapd...
<Son_Goku> I'm sort of cheating by using PR diffs, but the number of patches being applied to snapd is quite high now :(
<Chipaca> fwiw i think we agreed that we should let you remove core if it was the last snap left, but it wasn't prioritised
<zyga_> Chipaca: yes, I think we agreed
<Chipaca> (but my memory is bad so don't trust me alone on this)
<zyga_> Chipaca: I think it should be easy, right?
<zyga_> Chipaca: no other snap installs in progress
<zyga_> Chipaca: and no other snaps
<Chipaca> zyga_â i think it wasn't super easy because of how isolated the bit that checks for core was, but i could be misremembering
<Chipaca> in any case, it still isn't prioritised :-)
<zyga_> Chipaca: we could catch the context at the time the op is made
<zyga_> and pass a flag like "ok-to-remove-core'
<Chipaca> zyga_â that sounds like the wrong way to do it
 * Son_Goku grumbles about crappy hotel Wi-Fi
<Chipaca> lunch!
<pstolowski> good idea
<ogra_> zyga_, https://bugs.launchpad.net/snapd/+bug/1687608 ... you asked about more info about this in https://forum.snapcraft.io/t/device-gets-bricked-after-trying-to-upgrade-core-snap/453 .... i can reproduce it fine here if you want me to collect data
<mup> Bug #1687608: running "snap refresh core" on an UbuntuCore device locks you out until reboot <snapd:New> <https://launchpad.net/bugs/1687608>
<zyga_> re
<zyga_> ogra_: looking
<morphis> zyga_: you had time to give snapd on raspbian a try?
<zyga_> ogra_: aha, can you tell me what is in snap changes?
<zyga_> morphis: no, I left the apt-get update && apt-get dist-upgrade -y running in the background
<zyga_> let's see
<ogra_> zyga_, http://paste.ubuntu.com/24498251/
<Son_Goku> morphis, zyga_: could one of you guys create a topic on the forums announcing the snapd 2.25 testing for Fedora once it syncs out to updates-testing?
<ogra_> zyga_, note that my SD is worn out, thus change 13 failed (but rolled byck fine) ... change 14 is the actual one showing the issue
<ogra_> *back
<zyga_> interesting
<zyga_> I wonder why change 13 failed
<zyga_> how is your SD a factor?
<ogra_> zyga_, because uboot.env was trashed (Sd worn out)
<zyga_> aah
<zyga_> 2017-05-02T09:40:50Z ERROR cannot finish core installation, there was a rollback across reboot
<morphis> Son_Goku: sure
<ogra_> right, ignore that one
<ogra_> it rolled back fine
<zyga_> ogra_: ok so after rollback what did you do?
<ogra_> zyga_, snap refresh core
<zyga_> 2017-05-02T10:04:41Z INFO Waiting for restart...
<zyga_> I'm trying to grok the log there
<zyga_> it was waiting for restart over and over
<ogra_> which also works fine but does never finish the "Setup snap "core" (1829) security profiles (phase 2)" bit
<zyga_> yeah
<zyga_> I think we have a bug there
<zyga_> let me look
<ogra_> yes, we do
<ogra_> it used to give me the console back before ... now it doesnt anymore
<zyga_> weird
<zyga_> so
<zyga_> we log that message when snapd itself saves in the state that it is waiting to restart
<ogra_> yeah, the message was there before ... but didnt spin forever
<zyga_> and that is not even saved in the state
<zyga_> it's just saved in memory
<zyga_> so we really need to restart
<zyga_> (though I suspect that it may be broken if we restart snapd rather then the machine)
<ogra_> the security profiles thing is saved in memory ?
<zyga_> ogra_: no
<zyga_> the "restarting" flag
<ogra_> the restarting flag isnt the issue
<zyga_> the task just does nothing until that flag is cleaned
<zyga_> so what is?
<ogra_> the issue is "Setup snap "core" (1829) security profiles (phase 2)" never finishing
<ogra_> or at least never returning the console access
<zyga_> ogra_: ...
<zyga_> ogra_: did you look at the code?
<ogra_> no
<zyga_> ogra_: the restaring flag guards that code from running
<zyga_> ogra_: that's why I mentioned it
<ogra_> well, the code obviously runs :)
<zyga_> ogra_: yes and bails out instantly because of that
<ogra_> http://paste.ubuntu.com/24498125/ shows even the spinner rotating between line 60 and 78
<zyga_> yeah, the spinner is client side query
<zyga_> so...
<ogra_> ah, so you mean the reboot flag kicks in to early ?
<zyga_> no, I don't think it does
 * zyga_ thinks
<zyga_> so
<zyga_> it's just this
<zyga_> we set the flag
<zyga_> and ask the system to reboot
<ogra_> right
<zyga_> but the reboot is not instant, it will be a while before it happens
<ogra_> which obviously works as expected
<zyga_> then lots of time passes
<zyga_> and then we reboot
<zyga_> and then it works OK
<zyga_> but the UX is not making it clear what is going on
<ogra_> that message has been there before since day one ... but it always left me interacting with the tty ... now it doesnt anymore and the spinner goes on
<zyga_> ogra_: you can ctrl-c and exit
<zyga_> ogra_: but I suspect shutdown may set nologin
<ogra_> before the spinner stopped at some point
<ogra_> no, ctrl-c is ignored
<zyga_> ogra_: yes but there was a bug there (hence phase 2)
<zyga_> morphis: no luck with your repo
<zyga_> morphis: apt-get doesn't like it
<ogra_> i think before it acvtually printed the "[/] Setup snap "core" (1829) security profiles (phase 2)" ... finished it and only then the reboot message showed up
<ogra_> at least thats what i remember
<ogra_> now both are there at the same time and the "[/] Setup snap "core" (1829) security profiles (phase 2)" seems to hold the console access
<morphis> zyga_: what does apt-get say?
<morphis> it will most likely complain because if the unknown key
<zyga_> E: Failed to fetch https://mm.gravedo.de/raspbian/dists/jessie/InRelease
<ogra_> raspbian !?
<morphis> zyga_: that file exists, can you give me the full output?
<morphis> ogra_: yeah
<zyga_> morphis: there's nothing else reall
<ogra_> can that even run our armhf binaries  ?
<zyga_> let me pastebin
<zyga_> http://pastebin.ubuntu.com/24498297/
<ogra_> (given it is a re-compile of the whole archive for v6)
<morphis> ogra_: these packages are rebuild for raspbian
<ogra_> ah, k
<morphis> zyga_: there we go: E: The method driver /usr/lib/apt/methods/https could not be found.
<morphis> zyga_: and it gives you the solution in the next line
<ogra_> apt-transport-https isnt a default in raspbian
<ogra_> ?
 * ogra_ would expect it to be seeded in all deb based distros nowadays ...
<zyga_> oh
<zyga_> sorry
<morphis> ogra_: me too
<ogra_>  01 16:56:05 localhost.localdomain /usr/lib/snapd/snapd[897]: helpers.go:173: cannot connect plug "core-support" from snap "core", no such plug
<ogra_> May 01 16:56:05 localhost.localdomain /usr/lib/snapd/snapd[897]: helpers.go:173: cannot connect plug "network-bind" from snap "core", no such plug
<ogra_> hmm
<ogra_> i thought we fixed that one
<niemeyer> Good days
<niemeyer> The forum is going down and back up for a quick configuration change
 * ogra_ wonders if his drafted answer will survive that :)
<niemeyer> ogra_: Yes, it saves while typing
<ogra_> ah, cool then
<niemeyer> It's back up already
<zyga_> morphis: installing
<ogra_> niemeyer, and worked fine :)
<zyga_> morphis: installed :)
<zyga_> morphis: trying to install stuff
<morphis> zyga_: good
<zyga_> morphis: well, it downloads core now
<morphis> zyga_: hm
<zyga_> morphis: which is terrbile, we should print architecture that snapd knows about in "snap version"
<ogra_> zyga_, UH OH ! so hitting ctrl-c like 5 times actually gets me the console back .... it seems just inconsistent in accepting ctrl-c after all!
<ogra_> still though ... i did never need to actually hit ctrl-c at all before
<morphis> zyga_: which architecture does the kernel report?
<morphis> niemeyer: you have a minute to snapshot Spread-08 as a new fedora-25-64 image?
<zyga_> morphis: it runs the configure hook now
<zyga_> morphis: armv6l
<zyga_> morphis: core has installed!
<niemeyer> morphis: Yeah
<niemeyer> morphis: Is it ready?
<Chipaca> zyga_â snapd prints its architecture on startup (not sure of the context)
<zyga_> Chipaca: thanks, so snapd on arm6l thinks it is arctually armhf
<zyga_> so it all misbehaves
<Chipaca> well, we don't support arm6l inside snapd so Â¯\_(ã)_/Â¯
<morphis> niemeyer: it is, down to 1022M, the minimal size we can get to
<Chipaca> are we doing a standup today?
<ogra_> well, and we dont really have any v6 in the archive ... so your build-deps will be armhf, your libc will be at build time etc etc
<niemeyer> morphis: Okay, working on it
<morphis> Chipaca, zyga_: we shouldn't then download the armhf snap on arm6l
<morphis> niemeyer: thanks!
<ogra_> Chipaca, good question ... who is around ? you, zyga_, me and pstolowski ?
<Chipaca> yeah
<pstolowski> o/
<ogra_> we could meet asnd rant about the guys in montreal ;)
<Chipaca> and people not reviewing branches, also
<zyga_> morphis: runtime.GOARCH is "arm"
<ogra_> yeah
<zyga_> Chipaca: I'm in the room now
<zyga_> Chipaca: let's hang out for 5 min
<morphis> zyga_: I see, that actually is our problem then ..
<morphis> zyga_: what does /proc/cpuinfo give you on the pi1?
<zyga_> morphis: http://paste.debian.net/930351/
<morphis> zyga: uname -m reports arm6l?
<zyga_> yes
<morphis> good
<ralsina> Morning folks! I don't have access to my canonical account anymore since I don't work there anymore, but I can't use my preferred namespace "ralsina" for my new personal account. Is there any way to get it back?
<niemeyer> morphis: All done.. please remember to test the update task in the spread-images project so we're able to update it easily in the future
<morphis> niemeyer: thanks!
<zyga_> morphis: suggestion to use uname data to konw the real architecture
<ogra_> zyga_, note that an armhf kernel could drive a v6 userspace though
<ogra_> (technically ... not sure that is done anywhere)
<zyga_> ogra_: yeah perhaps, for now let's just close one big gap though
<ogra_> yeah, unlikely that you hit that in the real-world
<ogra_> hmm, well ... except probably in a raspbian chroot running on top of a debian installation ...
<ogra_> (for testing or building or some such)
<mup> PR snapd#3260 opened: WIP: Implement --user instance for snapd <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
<morphis> niemeyer, zyga_: time to review https://github.com/snapcore/snapd/pull/3222 again?
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<mup> PR snapd#3261 opened: snap-confine: init the ENTRY variable, coverity is unhappy otherwise <Created by mvo5> <https://github.com/snapcore/snapd/pull/3261>
<elopio> Facu: our fake servers in snapcraft turned into an ugly beast. We need at least an url router. Would it make sense to use flask? or maybe there's something lighter.
<Facu> elopio, can't you route urls using something static? like apache?
<dragly> I have an app that crashes with a segfault when run in a snap sandbox. Is there any way I can run gdb to debug this?
<elopio> Facu: wouldn't it be worst to add apache as a dependency than flask? I want something like this, but it's not in xenial :( https://github.com/pretenders/pretenders
<Facu> elopio, understand; to just re-route probably flask is even too big, maybe a smaller web framework would also do the job, like pyramid; but if you already are proficient with flask, go for it
<pachulo> stupid question: what is the wdl-nextcloud snap for?
<ogra_> pachulo, perhaps kyrofa knows ... i'd just go with the nextcloud snap from nextcloud
<ogra_> pachulo, i thinnk wdl means "western digital" and is tied to the netxcloud box
<pachulo> ah, ok, that makes sense! Thanks ogra_ !
<elopio> Facu: I'll take a look at pyramid. Thanks.
<daker> hi, does anyone know the state of mir-kiosk stuff(gui apps on ubuntu-core), is it still developed/maintained?
<kyrofa> pachulo, ogra_: no idea. It doesn't seem to be available in the stable channel-- how did you find it? Last I heard the upstream nextcloud snap was still shipped on the nextcloud box
<ogra_> kyrofa, snap find nextcloud on a pi3 shows it to me
<kyrofa> ogra_, ah, so armhf then
<ogra_> yeah
<kyrofa> That always gets me :P
<ogra_> stop using dead arches, arm is the future!
<ogra_> ;)
<kyrofa> ogra_ does all his development work on a pinebook
<ogra_> haha, not really :)
<roadmr> jdstrand: hello! r875 of the tools is now in production
<jdstrand> roadmr: that was fast. thanks! :)
<jdstrand> roadmr: fyi, the review-tools fork of crt and its edge snap is not bad
<jdstrand> roadmr: I'm not ready to say 'integrate this into the snapcraft.io store in lieu of crt', but I wouldn't mind feed back from people playing with it
<jdstrand> feedback even
<roadmr> nice!
<zyga_> jdstrand: hey
<zyga_> jdstrand: I'm working with a user that has xenial with 4.4 kernel and hits an apparmor denial for snap-confine
<zyga_> jdstrand: I'm quite puzzled by what's going on
<jdstrand> what is the denial?
<zyga_> https://github.com/lxc/lxd/issues/3267
<zyga_> jdstrand: a downgrade to 2.24 helps
<zyga_> until a reboot
<zyga_> when it is broken again
<olive> Hi!
<zyga_> I did a diff of snap-confine in 2.24 and I don't see anything relevant
<zyga_> olive: hey!
<zyga_> jdstrand: olive here is affected by this issue
<zyga_> jdstrand: my quick idea is that snapd 2.24 doens't use snap-confine from core yet, i'm checking that now
<zyga_> jdstrand: the actual denial though is very odd; IMO it is allowed by the profile
<zyga_> [11120.777073] audit: type=1400 audit(1493729112.057:3410): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/var/lib/lxd/" pid=31726 comm="snap-confine" srcname="/var/snap/lxd/common/lxd/" flags="rw, rbind"
<zyga_> this is one denial
<zyga_> (actually this one feels wrong, I saw a different one earlier)
<zyga_> and this one is also something unexpected
<zyga_> olive: is there anything in /var/lib/snapd/mount/snap.lxd.fstab
<jdstrand> zyga_: there is no rule for that in 2.25
<jdstrand> mount options=(rw rbind nodev nosuid noexec) /var/lib/snapd/hostfs/var/lib/lxd/ -> /var/lib/lxd/,
<zyga_> jdstrand: right, I saw a different denial earlier that matched this rule you just pasted
<jdstrand> the srcname in the denial is /var/snap/lxd/common/lxd/
<zyga_> (saw == on irc)
<olive> zyga_: not better after reboot
<zyga_> olive: ok, thank you for checking
<olive> snapd 2.25
<zyga_> jdstrand: so olive here is on 2.25 with no snap-confine installed (I was worried because there was a .dpkg-bak file in /etc/apparmor.d/)
<olive> /var/lib/snapd/mount/snap.lxd.fstab: No such file or directory
 * zyga_ is puzzled
<zyga_> ok
<zyga_> olive: can you do this please:
<zyga_> export SNAP_CONFINE_DEBUG=yes
<zyga_> and then start lxd if you can
<zyga_> though
<zyga_> you can run anything else
<zyga_> even hello-world snap
<zyga_> as the denial should be generic
<olive> http://paste.ubuntu.com/24499042/
<jdstrand> zyga_: it seems snap-confine is doing something wrong. why is it trying to use /var/snap/lxd/common/lxd/ as the srcname instead of /var/lib/snapd/hostfs/var/lib/lxd?
<zyga_> jdstrand: no idea yet
<zyga_> jdstrand: but very fishy
<zyga_> olive: great, can you couple that with 'dmesg | grep DENIED'
<zyga_> olive: get the last lines
<zyga_> olive: it should be just one, paste it here directlyu
<jdstrand> /var/snap/lxd/common/lxd/ is for the lxd snap. /var/lib/snapd/hostfs/var/lib/lxd is the core snap. it seems to be picking the wrong thing
<olive> [  384.578585] audit: type=1400 audit(1493738612.509:148): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/var/lib/lxd/" pid=7625 comm="snap-confine" srcname="/var/snap/lxd/common/lxd/" flags="rw, rbind"
<olive> [  384.690504] audit: type=1400 audit(1493738612.621:149): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/var/lib/lxd/" pid=7631 comm="snap-confine" srcname="/var/snap/lxd/common/lxd/" flags="rw, rbind"
<zyga_> jdstrand: note that snap-confine debug log doens't mention anything related to lxd common at all
 * zyga_ looks at the source
<jdstrand> olive: does /var/lib/snapd/hostfs/var/lib/lxd exist? is it a symlink?
<zyga_> jdstrand: that mount has hard-coded arguments, I doubt we're doing anything worng
<zyga_> jdstrand: note, hostfs is just inside snaps
<zyga_> olive: can you please `ls -ld /var/lib/lxd`
<zyga_> jdstrand: a symlink the is likely the cause
<roadmr> jdstrand: sorry was otp! oh so review-tools? you say it's a fork? where does that live?
<olive> ls: cannot access '/var/lib/snapd/hostfs/var/lib/lxd': No such file or directory
<olive> # ls -ld /var/lib/lxd
<olive> lrwxrwxrwx 1 root root 25 Feb  1 22:45 /var/lib/lxd -> /var/snap/lxd/common/lxd/
<zyga_> aha
<zyga_> olive: perfect
<zyga_> olive: so two questions
<zyga_> olive: did you do that manually?
<olive> no.
<jdstrand> zyga_: 'hostfs is just inside snaps'. huh? it has to exist at whatever point snap-confine is running to mount it. I guess you mean within its mount namespace
<zyga_> olive: and did it really work before?
<olive> yes :)
<jdstrand> roadmr: https://launchpad.net/review-tools
<ogra_> hahaha
<zyga_> jdstrand: yes, I mean that the hostfs directory as you specified it is always empty from a typical unconfined shell
 * ogra_ looks forward to jdstrand's answer in https://forum.snapcraft.io/t/startx-as-a-regular-user/460
<zyga_> olive: so that symlink won't work unfortunately, let me think about it for a sec
<ogra_> (i think the user asked here before and was toold "no Xorg on UbuntuCore" ... but seems he tried anyway (or it is another person)
<zyga_> olive: is that directory empty?
<zyga_> olive: I mean /var/lib/lxd
<olive> yes, just this symlink
<olive> oh.wait.
<zyga_> olive: right, but if you follow the symlink, is /var/snap/lxd/common/lxd empty?
<olive> when I cd /var/lib/lxd and ls... it is not empty. o_O
<zyga_> stgraber: ^^ is that symlink anything you are familiar with? (symlink from /var/lib/lxd -> /var/snap/lxd/common/lxd)
<zyga_> olive: ok, as a quick work-around do this:
<olive> ok sorry, I'm tired, of course, it is a symlink... :(
<stgraber> zyga_: nope
<stgraber> zyga_: not something we do or would ever recommend someone do
<olive> zyga_: http://paste.ubuntu.com/24499072/
<stgraber> zyga_: folks should just "export LXD_DIR=/var/lib/snap/common/lxd/" if they want tools outside of the snap talking to the snap LXD
<jdstrand> it isn't something that would be allowed by the profile anyway
<zyga_> olive: can you try stgraber's advice, remove that symlink please
<olive> I promise you that I have not tweaked myself. I only followed the stgrabber article;)
<jdstrand> ie, the snap couldn't create that symlink
<zyga_> jdstrand: I'll patch snap-confine to be smarter
<zyga_> jdstrand: it should not belly-up fail on that
<zyga_> I wonder if we could kill the LXD quirk now
<jdstrand> the lxd snap would have to (ab)use its lxd-support interface to load and/or change to a profile that allowed that write and perform the symlink
<stgraber> jdstrand: the lxd snap never uses /var/lib/lxd
<jdstrand> stgraber: right, not saying you are doing that. saying you'd know if you did cause you'd have to go through hoops
<olive> I remove the /var/lib/lxd link ?
<stgraber> olive: yeah
<zyga_> olive: yes, please
<jdstrand> olive: curious, did you ever try to run lxd inside of a container launched from the lxd snap?
<stgraber> jdstrand: I'm pretty sure this bind-mount was added for the juju, conjure-up or similar snaps that wanted to talk to the host LXD
<zyga_> stgraber: ah, perhaps that is it
<olive> ok now snapd is running    Active: active (running) since Tue 2017-05-02 17:35:10 CEST; 5s ago
<olive> jdstrand: I don't think so
 * jdstrand is wondering if a container was given write access to the host's filesystem and then did that
<jdstrand> olive: did you use juju or conjure-up like stgraber said?
<zyga_> jdstrand: note that 2.25 has reassociate fix, maybe what is going on is that snap-confine breaks out of the container?
<zyga_> jdstrand: though I bet lxd uses process namespace
<zyga_> jdstrand: so probably not that
<olive> never tried juju in the server.
<olive> in this* server
<jdstrand> zyga_: it might be the reassociate stuff
<olive> conjure-up either
<jdstrand> I think making snapd more robust in the face of this is a fine fix, but the root cause needs to be found
 * jdstrand notes he also uses the lxd snap, is on 17.04 with snapd 2.25 and does not have this issue
<morphis> zyga_: thanks for the comment, completely forgot to mention that
<olive> thank you everybody. specially zyga_ and stgraber :)
<olive> and jdstrand
<olive> (and sabdfl)
<zyga_> jdstrand: trying to reason about this, I don't think is could be the reassociate fix, after all, it should not change anything in this case;
<zyga_> olive: you are welcome!
<zyga_> stgraber: all lxd containers use the PID namespace, right?
<zyga_> jdstrand: and in the pastebin from SNAP_CONFINE_DEBUG log above we see: DEBUG: re-associating is not required
<jdstrand> something created that symlink
<jdstrand> the only thing I can think of is a container that had /var(/...) mounted inside
<jdstrand> and then it did it
<jdstrand> or as stgraber said, some tool trying to be smart and getting something wrong (but those tools weren't run)
<dragly> Found a way to get gdb running. Is there any reason why QFontDatabase::findFont should segfault when calling into libQt5XcbQpa?
<dragly> For instance a plug that should give access to fonts?
<ogra_> shouldnt the desktop-qt part provide that ?
<zyga_> jdstrand: I think that we don't bind mount all of /var, right?
<zyga_> jdstrand: so that cannot be done from inside a snap
<zyga_> dragly: no, sorry :/
<zyga_> dragly: there are no fonts in the core snap
<ogra_> why would there
<zyga_> dragly: and host fonts are not accessible
<ogra_> the snapcraft desktop parts install fonts inside the snap
<ogra_> that should just work, provded you used the right part in your snapcraft.yaml
<zyga_> ogra_: we wanted to offer sharing of classic fonts
<zyga_> ogra_: e.g. run your favourite editor with locally-installed font
<ogra_> zyga_, right, i'm talking about today
 * zyga_ nods
<ogra_> there definitely no reason for the above error if you include the right bits
<ogra_> dragly, https://github.com/ubuntu/snappy-playpen/blob/master/qcomicbook/snapcraft.yaml as an example
<ogra_> (see the "after: [desktop-qt5]" there)
<jdstrand> zyga_: lxd is in a position to do its own reassociate. not saying it does, it just can. I'm grasping at how it could have happened
<zyga_> jdstrand: aha, that's true
<zyga_> jdstrand: still I don't think it is reassociate that was re-enabled that is at fault here
<dragly> ogra_: thanks. I'm using a custom Qt install, but it might help to install the default Qt packages and use those to have all the necessary pieces set up and ready. I'll look up what after does.
<mup> PR snapd#3262 opened: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <https://github.com/snapcore/snapd/pull/3262>
<zyga_> morphis: hey
<morphis> zyga_: hey!
<zyga_> morphis: do you have a working qmeu image I can use for debian?
<zyga_> morphis: I'm still debugging https://github.com/snapcore/snapd/pull/3259
<mup> PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259>
<zyga_> morphis: I think there's a deeper problem there
<zyga_> morphis: I can work on linode but I'd prefer a local image
<morphis> zyga_: was looking into that too but it looks to me like those failing bits are not coming from the debian part ..
<jdstrand> zyga_: I suspect we need to keep an eye on this. there is no reproducer and other lxd snap users are not complaining. if/when they do, we can request a reproducer/etc
<morphis> zyga_: but let me check if I have my dirty script to create a debian qemu image still, didn't had time to clean them up yet
<zyga_> morphis: much appreciated!
<morphis> zyga_: take http://saimei.ftp.acc.umu.se/cdimage/openstack/testing/debian-testing-openstack-amd64.qcow2 and use https://gist.github.com/morphis/1e181e60b3803f8a72952c580fad9a21
<morphis> zyga_: $ ./adt-buildvm-ubuntu-cloud -r sid --image=$PWD/debian-testing-openstack-amd64.qcow2 --verbose
<morphis> zyga_: save the gist as adt-buildvm-ubuntu-cloud
<zyga_> thanks
<morphis> zyga_: the script is a hacked variant of the ubuntu variant
<morphis> but should give you an image with debian:debian to login
<zyga_> morphis: I have it, thank you!
<morphis> zyga_: however it looks more like the tests are a bit racy
<morphis> linode:ubuntu-16.04-32:tests/main/interfaces-openvswitch is the one which fails now
<dragly> I am getting a "No such file or directory: [...]/parts/qml/install/etc/xdg/qtchooser/snappy-qt5.conf" when using desktop-qt5
<zyga_> morphis: gee, that iso image clones forever
<zyga_> wgets
<zyga_> I get modem speeds on it
<morphis> zyga: https://cdimage.debian.org/cdimage/openstack/
<morphis> try a different mirror thne
<zyga_> thnx
<diddledan> is there a way of telling `snapcraft cleanbuild` to use a different release of ubuntu for a local build? I think I need to use a more-recent version than 16.04 for some of my build dependencies to be satisfied
<diddledan> specifically I need a more recent vala than 0.34.0: checking whether /usr/bin/valac is at least version 0.34.0... no
<qengho> diddledan: No. Instead, make "vala" a separate part. Compile your compiler.
<morphis> zyga_: you found anything?
<morphis> zyga_: looks like all tests for https://github.com/snapcore/snapd/pull/3259 passed now
<mup> PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259>
<zyga> morphis: still downloading the image, currently at 25%
<morphis> zyga_: even on another mirror?
<zyga> yes, maybe something elsewhere on the network
<zyga> morphis: mvo just said he's looking too
<morphis> zyga: ok
<zyga_> jdstrand: is my explanation in https://github.com/snapcore/snapd/pull/3252 sufficient?
<mup> PR snapd#3252: tests,cmd/snap-confine: port older snapd-discard-ns tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3252>
<cratliff> I'm going through the running nodejs as a service demo and am running into this issue.  https://github.com/canonical-websites/tutorials.ubuntu.com/issues/70  does anyone have a workaround other than to run services in devmode?  I'm wanting to convert some code that's using systemd to snaps and it doesn't seem like it will work right now.
<zyga_> cratliff: can you just build it entirely, not with snap try
<zyga_> cratliff: whatever the issue it will likely function correctly then
<zyga_> cratliff: I suspect you are on encrypted home folder or something else
<zyga_> cratliff: can you tell me where the [...] part that you removed in the issue was pointing to?
<zyga_> it finally downloaded
 * zyga_ debugs debian
<cratliff> Sorry, I'm not aware of removing anything, I'm not sure what you are referring to.  I've not attempted to build it without try yet, let me see.
<zyga_> aha
<zyga_> cratliff: sorry, I assumed you were reported of the issue there
<zyga_> cratliff: just build the snap and install it
<zyga_> cratliff: as for snap-try, there are still some issues
<mup> PR snapcraft#1294 opened: plugin: Add plugin for meson build system <Created by JulianLiu> <https://github.com/snapcore/snapcraft/pull/1294>
<zyga_> I think I just figured out a simple way to handle it actually
<cratliff> I installed the server with --dangerous, not --devmode.  It is working, since I used dangerous it should show that it is running without issue contained, right?
<zyga_> cratliff: not sure really, does snap list say it is devmode?
<cratliff> no, it does not.
<zyga_> cratliff: great, then you are good :)
<cratliff> cool, thanks for the help.
<zyga_> cratliff: good luck
<zyga_> finally
<zyga_> geez
<zyga_> forever
<mup> PR snapd#3263 opened: snap: make `snap prepare-image --extra-snaps` derive side info <Created by mvo5> <https://github.com/snapcore/snapd/pull/3263>
<zyga_> and it doesn't boot :/
<zyga_> I think I will resort to regular debian image to deubg this
<mup> PR snapd#3241 closed: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3241>
<zyga_> ok, so it gets to login prompt
<zyga_> but debian/debian doesn't work
 * zyga_ looks at the script again
<diddledan> how do I tell snapcraft to keep the lxc container using cleanbuild when the build fails so that I can try to figure out why I'm getting a permission denied error when running an autotools build when it tries to execute ./configure
<diddledan> ignore that, I'm gonna do it a different way - run an lxc container manually and call snapcraft directly within that without using cleanbuild
<diddledan> ok, so it only dies in cleanbuild :-/
#snappy 2017-05-03
<mup> PR snapcraft#1295 opened: Record build packages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1295>
<zyga> good morning
 * zyga has reproduced the issue affecting debian
<zyga> locally
<zyga> (finally)
<zyga> morphis: thanks for your help, I'll either contribute a debian-creation script to autopkgtest or vendorize it to build spread images in my repository
<morphis> zyga: np, which issue did you reproduce exactly?
<morphis> the hanging configure hook?
<zyga> morphis: yes
<zyga> morphis: essentially I only got the image created late last night and I left it at the spread -debug prompt
<morphis> zyga: that one happens on a regular debian installation with snapd installed from the archive
<zyga> yes, I'm replying on the forum
<morphis> zyga: this really much looks like we miss something in 2.24 which was fixed in 2.23.6
<zyga> morphis: hmm
<morphis> zyga: interesting, however we broke distros like debian with this which would validate a hotfix for 2.24 and again proves that we always have to release snapd and a core snap in sync
<zyga> morphis: wait
<zyga> morphis: I'm 100% sure mvo merged all of 2.23.x into 2.24
<zyga> morphis: what this 2.24 sems to be lacking is a timeout on the hook
<zyga> morphis: or a way to let it fail
<zyga> morphis: this VM is up for 10 hours now
<morphis> and the hook is still running?
<zyga> morphis: and the hook is up for 10 yours still
<zyga> morphis: yep
<zyga> morphis: let's check the 2.24 tree to be sure we're not missing anything
<morphis> ok
<zyga> spineau: good morning :)
<zyga> morphis: I found one small bug btw
<spineau> zyga: morning zyga
<zyga> in spread setup
<zyga> morphis: PR coming up in a sec, just describing it
<zyga> morphis: https://github.com/snapcore/snapd/pull/3264
<mup> PR snapd#3264: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264>
<zyga> morphis: and https://github.com/snapcore/snapd/pull/3265
<mup> PR snapd#3265: spread: add spread target qemu:debian-9-64 <Created by zyga> <https://github.com/snapcore/snapd/pull/3265>
<zyga> morphis: now to investigate 2.24
<mup> PR snapd#3264 opened: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264>
<mup> PR snapd#3265 opened: spread: add spread target qemu:debian-9-64 <Created by zyga> <https://github.com/snapcore/snapd/pull/3265>
<zyga> morphis: signed off is a personal preference, I just think it is important as a declaration of intent, there is no formal requirement to use it
<morphis> zyga: yeah it is, but what are you signing off?
<morphis> for the kernel its clear but for other projects its not unless explicitly stated somewhere
<zyga> morphis: oh, right, I do use the same semantics
<zyga> morphis: I think there is no other well-known semantics for that line
<morphis> it normally refers to https://developercertificate.org/
<zyga> yep, (though I think I read that elsewhere, I wasn't aware of this domain before)
<morphis> zyga: I think the linux foundation has its own copy of this
<morphis> just wasn't sure what this means in the context of snapd as we have the CLA too
<zyga> morphis: I think it formally does nothing but I really wish we had it over the CLA :)
<zyga> morphis: so 2.24 should have a timeout
<zyga> morphis: so checking WTF
<morphis> zyga: however, should we go in the meantime with https://github.com/snapcore/snapd/pull/3259 to get all other PRs unblocked?
<mup> PR snapd#3259: tests/upgrade: force install core snap from beta for debian <Created by morphis> <https://github.com/snapcore/snapd/pull/3259>
<zyga> morphis: yes
<zyga> I'll merge it now
<morphis> ok
<morphis> thanks
<mup> PR snapd#3259 closed: tests/upgrade: force install core snap from beta for debian <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3259>
<zyga> ok, let's merge master into some PRs and get some breakfast :)
<morphis> :-)
<zyga> ok, done
<zyga> morphis: thank you, sorry for taking so long to merge this :)
<zyga> morphis: I'll open a new thread to investigate the hook timeout issue
<morphis> zyga: why not reusing the one we already have?
<zyga> https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464
<zyga> morphis: separate topic
<zyga> morphis: I linked them though
<zyga> hmmm
<zyga> so I removed overlord/hookstate/Context.timeout (field in the struct) and no test captured that, looking deeper
<zyga> ok, breaking this to really eat something...
<dragly> Sorry for the basic question, but I am a bit confused after the folder structure changed:
<dragly> If I have "snapcraft.yaml" in a folder named "snap", should "setup/gui/app.desktop" be inside "snap" as well?
<dragly> I moved most files into the "snap" folder after snapcraft told me "plugins" should reside there.
<mwhudson> hi so https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1657254
<mup> Bug #1657254: console-conf - unable to connect over proxy <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1657254>
<mwhudson> so the ui side is pretty easy
<mwhudson> but once the user has provided a proxy, the thing to do is stick it in /etc/environment and systemctl restart snapd?
<zyga> mwhudson: probably,yes
<Chipaca> zygaâ o/
<Chipaca> zygaâ you're feeling like finishing a review today? :-D
<Chipaca> zygaâ snapd#3264 is gtg once green, but random tests are failing in debian?
<mup> PR snapd#3264: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264>
<zyga> Chipaca: hey
<zyga> Chipaca: wrt 3264 yes, I'll merge master to fix it but spread is already overloaded
<zyga> Chipaca: yes, I do feel like code reviews but I want to get to the bottom of hook timeout not working first
<zyga> Chipaca: how are you doing? :)
<Chipaca> jdstrandâ snapd#2969 has conflicts
<mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<Chipaca> zygaâ doing alright i think
<Chipaca> finally got an appointment with physio wrt my back (nhs physio takes ages)
<Chipaca> so hopefully i'll have that fixed and be able to get back to running soonish :-)
<zyga> Chipaca: I hope you will
<Chipaca> zygaâ what was the cause (and fix) for âhsearch_r failed for |S_IFREG: No such processâ?
<zyga> Chipaca: snap-confine from distro used when profile was made by snapd from core snap
<zyga> Chipaca: where are you seeing tihs
 * mwhudson reads the code systemd uses to process EnvironmentFile= directives...
 * Chipaca hugs mwhudson 
<Chipaca> why would you do this to yourself
<mwhudson> the documentation is lacking
<Chipaca> zygaâ running snapd from master
<Chipaca> zygaâ on my dev laptop
<zyga> Chipaca: hmm hmm
<zyga> Chipaca: self built deb?
<zyga> Chipaca: build&install snap-confine
<Chipaca> zygaâ no deb
<zyga> Chipaca: it'll help
<zyga> Chipaca: tip: make hack
<Chipaca> ah
<zyga> (in cmd/)
<Chipaca> zygaâ you've probably got the autoconf invocation in your bash history; care to share?
<zyga> Chipaca: ./autogen.sh
<zyga> Chipaca: make hack :)
<zyga> Chipaca: that's all you need
<Chipaca> that had a lot more options before
<Chipaca> :-)
<Chipaca> whoo. i like
 * Chipaca runs it again without -n
<zyga> :D
<mup> PR core-build#9 opened: Add writable boot for android-boot "bootloader" <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/9>
<Chipaca> zygaâ that sorted it, thanks!
<mup> PR snapd#3258 closed: cmd/snap-confine/tests: fix shellcheck on recently added files <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3258>
<zyga> Chipaca: I found something fishy in 2.24
<zyga> Chipaca: can you look at (in master) overlord/hookmgr/context.go
<Chipaca> zygaâ you want chips with that?
<zyga> Chipaca: ha, I wish :D
<zyga> Chipaca: the Context.timeout field is unused
<Chipaca> zygaâ in master it's overlord/hookstate/context.go
<zyga> Chipaca: but Context.Timeout uses Context.setup.Timeout
<zyga> ah, right
<zyga> so I know we have a test that checks hook timeouts
<zyga> but I also see this reliably not time out in spread :/
<zyga> the code there looks sane. I'll try to add debugging to see what really happens
<Chipaca> the tests set Timeout on the setup also
<Chipaca> zygaâ i reckon that timeout in the context is a leftover bugish
<zyga> yep
<Chipaca> zygaâ do you have a snap that should time out and doesn't? for testing here
<zyga> ok, I'll start with 2.24 and focus on the test that checks it really works
<zyga> Chipaca: yes, upgrade/basic as of 07182f7b1b7f7679f9e32f1511cc1669179c90f8
<zyga> Chipaca: but only on debian
<zyga> Chipaca: where we don't have apparmor
<zyga> Chipaca: if you look at 2eda8023ca28060e5a027822969399bfe89ee508 instead you can run this reliably in qemu
<zyga> Chipaca: though you need a qemu image
<zyga> Chipaca: (or via linode)
<Chipaca> zygaâ what hook isn't timing out?
<Chipaca> config? iface?
<Chipaca> device?
<zyga> Chipaca: the way I understand it, the upgrade/basic test installs 2.24 and upgrades to master
<zyga> Chipaca: so if 2.24 already had timeouts (and I think it does based on what I read) it should not hang with the hook there forever
<Chipaca> ifacestate does not set a timeout
<Chipaca> neither does devicestate
<Chipaca> only config does
<Chipaca> and it sets it to 5 minutes, overridable by SNAPD_CONFIGURE_HOOK_TIMEOUT environ
<Chipaca> prepare.sh sets SNAPD_CONFIGURE_HOOK_TIMEOUT to 30s
<Chipaca> for snapd
<zyga> Chipaca: configure on core
<zyga> Chipaca: and there is a timeout set, it's 5 minutes
<zyga> Chipaca: it hangs because seccomp is enabled and core-support is disconnected
<zyga> Chipaca: so seccomp kills part of snapctl
<zyga> Chipaca: that's all expected
<zyga> Chipaca: what is wrong is the timeout
<zyga> Chipaca: task logs does not show we even try to kill it
<Chipaca> hmm
<Chipaca> zygaâ does it not timeout, or does the killemall or something after it hang?
<zyga_> Chipaca: re, switched to mobile
<zyga_> Chipaca: I'm uploading a debian spread image in case you want to try
<Chipaca> zygaâ dunno if you saw my q about killemAll
<zyga_> Chipaca: no, sorry
<zyga_> Chipaca: lost in irc transition
<Chipaca> <Chipaca> zygaâ does it not timeout, or does the killemall or something after it hang?
<zyga_> Chipaca: it does not, it just keeps waiting for it to run
<zyga_> Chipaca: and according to my reading of the code, if it were timing it out the task log would say so
<zyga_> Chipaca: look at...
<zyga_> https://forum.snapcraft.io/t/tests-broken-in-master/457/10
<zyga_> the tail of that
<zyga_> Chipaca: the qemu image will be uploaded in 9 minutes
<Chipaca> i think it's all Son_Goku's fault
 * Chipaca hides
<zyga_> Chipaca: https://www.dropbox.com/sh/7k7qdo82vjjscy7/AADu7UsMsYXd5NYExOysgSx9a?dl=0
<zyga> Chipaca: you can get that image there
<Chipaca> zygaâ question: why not compressed?
<zyga> Chipaca: qcow2
<Chipaca> i mean, i don't mind, my connection is fast enough :-)
<zyga> Chipaca: it is compressed :)
<Chipaca> but your upload is slow
<zyga> Chipaca: I was just _uploading_ that :)
<zyga> Chipaca: yeah, I was sending it over 3G
<zyga> Chipaca: landline is sllooooow 0.1MB/s
<Chipaca> zygaâ qcow2 isn't compressed by default, and if it is it's readonly
<zyga> Chipaca: over 3G I had 0.3MB/s outdoors and (I noticed by accident) 2.5MB/s while standing on the staircase inside the house
<zyga> Chipaca: aha, do you think I can make it smaller then?
<Chipaca> zygaâ resonant cavities ftw
<zyga> yeah but I was surprised :)
<Chipaca> agreed, it'd be surprising to me too :-)
<Chipaca> a happy surprise
<Chipaca> knowing the mechanism does not make it any less fortunate
<Son_Goku> ?
<zyga> Son_Goku: I think chipaca was joking
<Chipaca> Son_Gokuâ niemeyer isn't around to blame for everything, so it's your turn
<zyga> we're trying to figure out what's going on wiht an apparently non-functional timeout on configure hooj
<zyga> hook
<Chipaca> zygaâ bzip2 of the img would've saved 26%
<Chipaca> debian-9-64.img:  1.351:1,  5.920 bits/byte, 26.00% saved, 789250048 in, 584078746 out.
<Chipaca> anyway
<Chipaca> what was i doing?
<Chipaca> coffee.
<Chipaca> zygaâ how do you log in to the image you sent me?
<Chipaca> ah
<Chipaca> debian/debian
<Chipaca> :-)
<zyga> Chipaca: I added a readme file now
<zyga> I'll re-compress it, drat :)
<zyga> though I'll check xz
<zyga> xz
<Chipaca> zygaâ is xz threaded now?
<Chipaca> actually, never mind. I was going to coffee.
<zyga> haha, enjoy :)
<zyga> I have no idea
<zyga> the compressor seems not to be
<zyga> I commented on https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464
<zyga> Chipaca: downto 474MB
<zyga> Chipaca: so I made this https://spread.zygoon.pl/
<Chipaca> zygaâ configure: error: xfs/xqm.h unavailable
<Chipaca> morphisâ ^
<Chipaca> looks like build deps are wrong on debian
<morphis> Chipaca: where do you get that?
<zyga> Chipaca: hmm, odd, you may need xfsprogs-dev for this
<morphis> zyga, Chipaca: we have xfslibs-dev in debian/control
<Chipaca> morphisâ i get this on debian after doing `sudo apt build-dep snapd` and then running autogen.sh from cmd/
<zyga> Chipaca: this gets you deps for what is in the distro
<Chipaca> and that has not brought in xfslibs-dev
<zyga> Chipaca: not for what you have in the tree
<morphis> Chipaca: ah, on debian we have snapd 2.21 only
<Chipaca> ah
<Chipaca> i should've done build-dep ./
<morphis> yeah
<Chipaca> yeah that brings it in
<Chipaca> sorry for the noise then :-)
<morphis> np :-)
<Chipaca> zygaâ and 'make hack' falls over because no apparmor_parser
<Chipaca> boo, etc
<morphis> Chipaca: did you configure with --disable-apparmor?
<Chipaca> morphis: I ./autogen.sh --disable-apparmor
<Chipaca> morphis: but I don't see that passing the option on to configure
<Chipaca> morphis: but it does have debian-specific opts iin there
<Chipaca> morphis: what should i do?
<morphis> debian-specific opts in the configure script?
<Chipaca> no, in autogen.sh
<Chipaca> --libexecdir=/usr/lib/snapd
<morphis> AFAIK autogen.sh checks for /etc/os-release and configures accordingly
<Chipaca> morphis: yes, but all it does for debian is the above, no --disable-apparmor
<morphis> Chipaca: but for `make hack` it looks like the easiest way is to disable the apparmor profile installation manually in Makefile.am
<Chipaca> and even with disable-apparmor, "make hack" tries to use apparmor_parser
<Chipaca> yeap
<morphis> yeah seems to be a short coming of the Makefile.am implementation
<morphis> Chipaca: looks like we need a if WITH_APPARMOR in there
<Chipaca> also, would be extra neat if 'make hack' dtrt wrt the go binaries as well
<morphis> Chipaca: yes
 * zyga breaks for lunch
<Chipaca> zyga: I think I set things up to reproduce the thing, but it didn't work (or rather, it worked). After lunch can you walk me through this?
<zyga> re
<zyga> Chipaca: yes
<zyga> Chipaca: gladly!
<Chipaca> zyga: so, how do i repro? :-)
<morphis> zyga: do we want to keep our sync meeting today or do we want to drop it with Alex and Jamie both being out?
<zyga> morphis: let's drop it
<morphis> zyga: ok
<zyga> morphis: fyi, I'd like to collect more images on http://spread.zygoon.pl/
<morphis> zyga: done
<zyga> morphis: thanks
<morphis> zyga: I can contribute a fedora-25-64 image
<zyga> morphis: I can also start auto-building all the images and keeping them the web
<zyga> morphis: great!
<zyga> morphis: ideally you'd share something I can wget
<zyga> Chipaca: ok, let's try this together
<zyga> Chipaca: give me a sec for the current run to complete
<Chipaca> zyga: i'm on detached head 2eda8023c
<morphis> zyga: let me compress and upload
<zyga> morphis: great
<zyga> morphis: perhaps you can upload to dropbox?
<Chipaca> zyga: built snap-confine, -exec, and d, running d with SNAP_REEXEC=0 et al
<morphis> don't really use dropbox
<zyga> morphis: ok
<morphis> zyga: but will upload to my server
<zyga> Chipaca: so, I didn't get that far, so far I can run it if I run the upgrade/basic test on debian-9-64
<zyga> Chipaca: this starts with 2.24
<zyga> Chipaca: and updates to master
<zyga> (though the update fails)
<zyga> Chipaca: give me a few more minutes for the current run to fail
<zyga> Chipaca: so I think that what we need to try instead, if you want interactive session, is to get 2.24
<zyga> Chipaca: add some debugging if you like
<zyga> Chipaca: build the deb and install it on debian-9
<zyga> Chipaca: and then snap install core
<zyga> Chipaca: (stable)
<zyga> Chipaca: and see what happens
<zyga> Chipaca: it should break because of seccomp
<zyga> Chipaca: but then we should time out the hook after 5 minutes
<zyga> Chipaca: do you agree?
<Chipaca> zyga: I'll try
<zyga> Chipaca: ok I will too
<jdstrand> Chipaca: re snapd#2969> ack, thanks. fixed
<mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<Chipaca> zyga: you should review stuff ^ :-)
<mup> PR snapd#3252 closed: tests,cmd/snap-confine: port older snapd-discard-ns tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3252>
<zyga> Chipaca: aha, I guess so
 * zyga opens a new ta
<zyga> *tab
<zyga> ah, it is this branch
 * zyga read it already
<dragly> ogra_: I tried the after: [desktop-qt5] step you recommended. Are there any requirements for it to work? Currently, it fails on a clean build with an error "No such file or directory: [...]/mypart/install/bin", where mypart is a completely different part in snapcraft.yml.
<dragly> However, if I remove it, build again, then add it, and build once more, it works.
<dragly> Seems like it depends on other parts to create an install dir for some reason.
<morphis> zyga: uploading ..
<dragly> Checked the backgrace, and it happens in _file_collides.
<dragly> backtrace*
<dragly> Must be that _file_collides assumes other parts actually install something.
<zyga> gah, my network, what is going on :/
<Chipaca> niemeyer: if you drop by, you requested changes on snapd#3026, zyga did as requested (on 14/03, ie 50 days ago), branch LGTM, is it OK to merge as is?
<mup> PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026>
<niemeyer> Chipaca: Heya
<niemeyer> Chipaca: That's not true.. I've looked at this PR last week and it wasn't fixed
<Chipaca> niemeyer: git disagrees, but maybe he forgot to push
<niemeyer> Chipaca: Happy to have a look again when we have a break here
<Chipaca> or maybe i'm misreading what github says
<Chipaca> anyway, yeah, take a gander
<niemeyer> Chipaca: One of us is misreading.. I see "cmd/snap-confine: simplifiy error handling from argument parser" few days ago
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> niemeyer: yeah, github just said "added commits on 14 mar" here
<Chipaca> had to look into commits to see that detail
<morphis> zyga: https://mm.gravedo.de/files/fedora-25-64.img.xz
<morphis> Son_Goku: any time to check https://bugzilla.redhat.com/show_bug.cgi?id=1444819 again?
<zyga> Chipaca: standp?
<zyga> morphis: thanks!
<zyga> morphis: thanks, I have it now
<mup> PR snapd#3266 opened: interfaces: allow plugging DBus clients to introspect the slot service  <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3266>
<Chipaca> hmmm
<Chipaca> zyga: with qemu-img we can create a local qcow2 image that used an http image as the backing file; this'd probably be faster than downloading the images
<Chipaca> zyga: (but you'd have to de-xz the .img for that)
<Chipaca> zyga: if you have ssh access to spread.zygoon.pl and can xunz -k, i can test this
<zyga> Chipaca: yes, sure
<zyga> Chipaca: it's my server
<Chipaca> zyga: there exist servers that only give you ftp access, to this day /o\
<zyga> Chipaca: decompressing
<zyga> Chipaca: FYI, my test is now doing this: [/] Run configure hook of "core" snap if present
<Chipaca> zyga: yeah, here as well (taking way too long at it)
<zyga> Chipaca: done
<zyga> Chipaca: how do you make those magic qemu images?
<zyga> Chipaca: and does qemu cache anything?
<ogra_> if you use http you can easily decompress during download on the fly btw ...
<ogra_> URL=http://cdimage.ubuntu.com/ubuntu-base/xenial/daily/current/xenial-base-amd64.tar.gz
<ogra_> CHROOT=xenial-test-chroot
<ogra_> wget -q -O - $URL | zcat - | sudo tar x -C $CHROOT
<Chipaca> zyga: qemu-img create -f qcow2 -b https://spread.zygoon.pl/debian-9-64.img debian-9-64.img
<ogra_> that wont use any disk space and decompress during download
<ogra_> (works fine with xzcat too)
<Chipaca> ogra_: my point is we don't use _most_of the image, so we can avoid downloading it
<zyga> ogra_: ooh
<zyga> nice
<ogra_> ah,. completely, yeah
<zyga> let's try that
<ogra_>  wget -q -O - $URL | html2text | grep .... <- easy way to grep through website content ;)
<zyga> ogra_: .xz doesnt work
<zyga> but plain does :)
<zyga> it boots
<cpaelzer> ogra_: worth a try for sure but is that fetching it in streaming still or will it use http range requests to read partially?
<zyga> pretty neat!!!
<ogra_> cpaelzer, i think wget just streams ...
<cpaelzer> ogra_: in the use as qcow backing file I meant
<ogra_> directly to stdout at lest ... so it depends whet the next command in the pipe does
<Chipaca> cpaelzer: the qemu-img approach does range requests afaik fwiw
<ogra_> cpaelzer, well, i never used it in that context ...
<cpaelzer> ok that I expected, be careful then
 * ogra_ uses it mostly to stream tarballs to disk to avoid debootstrap
<zyga> Chipaca: ok, the test just failed for me!
<cpaelzer> I'd assume something in the order of a few hundreds individual requests might take as long as the full image :-)
<zyga> Chipaca: no mention of restarts!
<Chipaca> yeah it never moves on from the hook
<Chipaca> and yes it's snapd 2.24
<Chipaca> from core 1689
<mup> PR snapcraft#1292 closed: tests: fix the recording tests to work in multiple architectures <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1292>
<Chipaca> wait no that core version is wrong (wrong terminal :-) )
<Chipaca> but how do i then have snapd 2.24
<Chipaca> with no core
<Chipaca> ooooohhhhh
<Chipaca> also: whaaaa
<Chipaca> this is a nice bug
<Chipaca> zyga: snapd restarted into the new snapd, but if it fails afterwards it does not restart back into old when rolling back
<Chipaca> jdstrand: any reason not to land snapd#2969?
<mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<mpontillo> So I have a snap with stage-packages including python2.7, and upstream code looking for 'python' on the path. Looks like it only installs the 'python2.7' binary. Anyone know the best way to just make a symlink from usr/bin/python2.7 -> usr/bin/python?
<zyga> Chipaca: what? :D
<Chipaca> zyga: you run that test with -debug, yes?
<zyga> Chipaca: wait, let me grok this
<zyga> Chipaca: but don't we disable reexec for that test?
<zyga> yes
<Chipaca> zyga: so when it fails you get a shell
<zyga> I have the shell stull open
<Chipaca> zyga: in that shell, do 'snap version'
<zyga> it says 2.24
<Chipaca> zyga: and snap is 2.21-something, yes?
<zyga> yes
<zyga> (ah, so we *do* reexec)
<Chipaca> zyga: ok, so 'snap abort 1'
 * zyga was confused by this then
<zyga> done
<zyga> 2.21
<zyga> now I get 2.21
<zyga> of snap
<zyga> but not snapd
<Chipaca> zyga: for snapd as well?
<zyga> aaaaah
<Chipaca> right
<zyga> so snapd keeps being there
<Chipaca> zyga: now a 'systemctl restart snapd' gets you back the snapd 2.21
<zyga> yes
<Chipaca> zyga: unless the tests are doing something weird to get that snapd version
<Chipaca> (which could be!)
<zyga> no, they don't
<zyga> they just install it from the packge
<Chipaca> so, yeah
<zyga> so are we seeing two bugs now?
<Chipaca> something is awry
<zyga> fist of all, when it was stuck
<zyga> it was already 2.24?
<Chipaca> zyga: it's bugs all the way down
<zyga> or was it sitll 2.21+b2
<Chipaca> zyga: 'snap change 1' will tell you that
<zyga> 2017-05-03T15:22:34+02:00 INFO Requested daemon restart.
<zyga> so 2.24 from the core snap
<zyga> so, that version definitely has hook bug
<zyga> I ran 2.24 directly on ubuntu and tried to get the spread test tha checks this to fail
<zyga> and it didn't though
<zyga> perhaps it's a combination of some factors that makes it hang
<Chipaca> zyga: what's probably happening
<Chipaca> and I'm guessing here
<Chipaca> is that 2.21 did not set the timeout
<Chipaca> and 2.24 gets it from state
<Chipaca> ... where it was put by 2.21
<Chipaca> so the fix is: when you don't want a timeout, put a _negative_ duration as the timeout
<zyga> oooh
<zyga> definitely!
<Chipaca> in the check to timeout, check for negative instead of > 0
<Chipaca> == 0 --> default timeout for the task (backwards compat etc)
<Chipaca> < 0 --> no timeout
<zyga> aha
<Chipaca> > 0 --> go on holidays
<Chipaca> \o/
<zyga> well, we need some form of tri-state for sure
<zyga> thank you for solving that one!
<zyga> I didn't think about pre 2.24 making the state
<Chipaca> we need patches working again
<zyga> so...
<Chipaca> is what we need
<zyga> yes :/
<zyga> can we do a patch that fixes it?
<zyga> sets a timeout on confiugre hook if missing
<zyga> it's not the end of the world if we cannot undo it
<zyga> wtyt?
<zyga> wdyt?
<Chipaca> i think the rule is no patches until we fix them
<mpontillo> Figured it out. Added python-minimal to stage-packages.
<zyga> Chipaca: can we fix it anywhere eles?
<zyga> Chipaca: I mean we did certainly a lot of patch-like things lately
<zyga> e.g. all the fixes for plug renames
<zyga> those are exactly patches but not called that
<zyga>  :D
<Chipaca> zyga: we can do one of those patch-like things, because it's backwards-compatible
<zyga> gee, let me lock the state, change it and unlock here
<Chipaca> that is, if the state has a timeout, the old snap just won't load it
<Chipaca> so yes we can and should do that
<Chipaca> zyga: and yes, snapd being at the wrong version after that abort is another bug
<zyga> Chipaca: great find, thank you!
<jdstrand> Chipaca: from my perspective, no, but I was hoping morphis would glance at it since I touched a bunch of interfaces his team implemented
<zyga> I was staring at it for so long without realizing it
<Chipaca> morphis: can you look at snapd#2969 ?
<mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<zyga> morphis: I'll merge it when you give it +1
<zyga> Chipaca: I'll start with the patch for the hook timeout
<Chipaca> morphis: no pressure :-p
<Chipaca> zyga: ok
<zyga> Chipaca: as for reexec back
<zyga> Chipaca: do you mean that we need to figure out that something failed and we need to shutdown snapd?
<zyga> Chipaca: when undoing one of the tasks?
 * zyga has built all the spread images for ubuntu now
<zyga> it was faster to spawn a VM, build them and reattach a disk than to upload from home
<Chipaca> zyga: i'm saying, doLinkSnap has maybeRestart(); there needs to be a maybeRestart on the undo path
<zyga> aha, that does make sense!
<Chipaca> and there is one in undoUnlinkCurrentSnap
<zyga> well
<zyga> I'm happy that it turned out to be double-plus-good :)
<zyga> not a wasted day and no bugs found
<Chipaca> so we need a test for this to figure out why it's not working :-)
<morphis> Chipaca, jdstrand: didn't I comment already? thought I did as I was looking at that PR
<Chipaca> (an integrationy test, not a unit test which it does have i believe)
<zyga> Chipaca: aha
<morphis> Chipaca, jdstrand: however I would prefer to get that into edge soon so our CI can execute against it
<morphis> then we will see if anything for those interfaces is broken the best way
<Chipaca> morphis: was that a "yes +1 land it plz"?
 * zyga reads the hook manager code closely
<morphis> Chipaca: yes
<morphis> let me add a comment
<Chipaca> boom, merged
<mup> PR snapd#2969 closed: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2969>
<Chipaca> 33 PRs. Bring it on!
<Chipaca> zyga: how's the tab completion review coming along?
<zyga> Chipaca: hmm, I could switch to it now
<zyga> or look at the hook manager
<zyga> hmm
<zyga> pick :)
<Chipaca> zyga: serialise things dude :-)
<zyga> Chipaca: ok, let me look for 10 minutes
<zyga> with hot context
<Chipaca> ah, pavel is away today
<Chipaca> niemeyer: snapd#3119 is blocked waiting for a review from you, also (and it's old!)
<mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
 * zyga got small electric shock
<zyga> darn uk adapters :/
<niemeyer> Chipaca: Thanks, I think there are several things in the queue which need love
<Chipaca> niemeyer: need love from reviewers, or from writers?
<niemeyer> I was hoping to have more time here, but turns out we're running from meeting to meeting as usual
<niemeyer> Chipaca: I suspect both, but I need to go back to our review board
<niemeyer> Which is out of date
<Chipaca> :-) ok
<Chipaca> niemeyer: i was just going through https://github.com/snapcore/snapd/pulls and poking people
<Chipaca> not being particularly methodic as i was trying to repro the 2.21/2.24 debian issue above
<niemeyer> Chipaca: Thanks for pushing the reviews forward!
<Chipaca> niemeyer: shut up and get reviewing!
<Chipaca> :-D
<Chipaca> how's the sprint btw
<niemeyer> More long plenaries than smaller decision meetings.. we need some more of the latter before the week is over
<niemeyer> On the bright side we got the +1 to move on with our development Sprint.. I need to push its organization forward
<Chipaca> niemeyer: delegate (not that i'm offering)
<Chipaca> niemeyer: you've got way too much on your plate
<niemeyer> Chipaca: Curiosity, I'm actually pretty hungry right now :P
<niemeyer> Curiously
<zyga> Chipaca: can you pull master into 3150 please?
<zyga> Chipaca: or just let me...
<Chipaca> zyga: snapd#3150?
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<zyga> Chipaca: yes
<zyga> if you cna please do :)
<Chipaca> sure, give me a mo
 * zyga fetches --all
<zyga> thnx
<Chipaca> zyga: any reason for the merge?
<Chipaca> i ask because it'll trigger a retest, and i've been triggering a lot of those :-)
<mup> PR snapcraft#1242 closed: kernel_plugin: use CROSS_COMPILE to override the default toolchain <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1242>
<zyga> Chipaca: just to have a chance to pass all tests
 * zyga read the text above as GROSS_COMPILE
<Chipaca> zyga: merged and pushed
<zyga> Chipaca: thank you
<mup> PR snapd#3265 closed: spread: add spread target qemu:debian-9-64 <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3265>
<mup> PR snapcraft#1204 closed: target-arch: decouple target arch from deb, and use a separate field â¦ <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1204>
<Son_Goku> morphis: I'll try to squeeze some time to check it today (at Red Hat Summit atm)
<Chipaca> zyga: can you answer jdstrand on snapd#3253?
<mup> PR snapd#3253: cmd/snap-confine/spread-tests: discard useless --version test <Created by zyga> <https://github.com/snapcore/snapd/pull/3253>
<zyga> Chipaca: looking
<zyga> Chipaca: done
<Chipaca> zyga: 'ppreciated
<kyrofa> Hey ogra_, I thought the rpi3 had spi enabled (we talked about this before)?
<kyrofa> ogra_, https://askubuntu.com/questions/911510/ubuntu-core-on-raspberry-pi-3-spi-driver-isnt-available
<kyrofa> ogra_, any idea on that one?
<morphis> Pharaoh_Atem: sounds good
<Chipaca> zyga: snapd#3150 is now green again :-)
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<zyga> Chipaca: let there be merge!
 * zyga does one _last_ read
 * Chipaca lifts his finger from the big green button
 * zyga notices lots of nice documentation!
<zyga> Chipaca: do we need a GPL header in the new shell script?
 * zyga will add comments from now
<Chipaca> zyga: ... maybe?
<Chipaca> zyga: i mean, yeah, we do :-/
<zyga> Chipaca: wait with the push as I also added small nitpick and we'll save one test slot
<Chipaca> why do some spread runs take nearly an hour (coming dangerously close to being killed)
<Chipaca> and, killed :-(
<zyga> Chipaca: what is bounced?
<zyga> Chipaca: allocation contention?
<zyga> we need to figoure out queing
 * zyga fetches coffee and gets right back up here
<Chipaca> zyga: bounced are things that the snap requests be tab completed, but that end up needing completing "outside" the snap
<Chipaca> zyga: variable names, shell aliases, shell functions, that sort of thing
<Chipaca> they're bounced from the completion mechanism inside, back to the outside to be completed there
<zyga> aha
<zyga> Chipaca: what is <( ... ) ?
<zyga> apart from chicken head?
<Chipaca> zyga: <(o_o<)
<Chipaca> zyga: it's called process substitution
<nacc> is that ascii-kirby?
<Chipaca> zyga: man bash, look for that
<zyga> thanks!
<Chipaca> zyga: but basically you write foo <(bar), the shell runs bar, sends its output to a_file, and runs foo a_file
<zyga> aha
<zyga> right, I just read that
<zyga> man,
<Chipaca> whether a_file is an actual file or something more magic is system-dependent
<zyga> shell
<zyga> shell is insane :)
<Chipaca> zyga: no, man bash, man shell is something else
<zyga> ;-)
<Chipaca> and then there's <( á )>
<mup> PR snapcraft#1296 opened: rust snaps can now use source-subdir without failing on pull <Created by roxyd> <https://github.com/snapcore/snapcraft/pull/1296>
<Chipaca> anyhow, EODish from me
<zyga> Chipaca: that's the chicken looking for food
<Chipaca> i'll be back to tend to these two spread runs but other than that, i'm out
<Chipaca> zyga: á( á )á
<zyga> d-d-dancing!
<zyga> jdstrand: question about https://github.com/snapcore/snapd/pull/3266
<zyga> jdstrand: would it make sense to allow introspection on any object?
<zyga> jdstrand: or is that leaking stuff?
<jdstrand> zyga: fyi, I don't know if you want to merge from trunk. https://github.com/snapcore/snapd/pull/3254 seems to keep taking too long
<zyga> I cannot remember if we can read properties this way, I think not though)
<zyga> jdstrand: it should be fine, just needs to be re-triggered when spread is idle
<jdstrand> zyga: it would leak stuff in my opinion. we should only allow introspecting the things that the interface allows access to. I don't think it should be part of default policy
<zyga> jdstrand: reading the diff now, I have more questions, what does it mean that path is not object specific for unconfined?
<jdstrand> look at the commented out rule and the description
<jdstrand> I discussed it
 * zyga reads the rest
<jdstrand> path=/ peer=(label=unconfined)
<zyga> jdstrand: I still don't get one thing: what is being leaked exactly?
<jdstrand> zyga: ok, well, I may have stepped on your toes cause I restarted the travis-ci tests
<zyga> jdstrand: hahe, no worries :) it will be OK
<mup> PR snapd#3253 closed: cmd/snap-confine/spread-tests: discard useless --version test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3253>
<mup> PR snapd#3266: interfaces: allow plugging DBus clients to introspect the slot service  <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3266>
<mup> PR snapd#3254: tests: re-enable and moderninze /media sharing test <Created by zyga> <https://github.com/snapcore/snapd/pull/3254>
<jdstrand> zyga: imagine a system with ofono, avahi-observe and fwupd all as debs
<zyga> ok
<jdstrand> zyga: allowing path=/ peer=(label=unconfined) means you can introspect all three
<zyga> ok
<jdstrand> there is nothing in the rule making it service-specific
<zyga> but is the introspection data sensitive?
<jdstrand> /org/freedesktop/systemd1 <-- that is service specific
<zyga> AFAIR it is just XML that describes what the API is
<jdstrand> zyga: it's a leak. is it a huge major world-ending leak? no
<zyga> well, hardly a leak, it just lets you know something is there in the first place, is that right?
<jdstrand> zyga: but for example in the network-manager api you can enumerate things just by looking at the introspected data
 * zyga tries to understand what is being exposed exactly, not how serious that is
<zyga> aha!
 * zyga looks at dbus specs
<zyga> I wrote some dbus code earlier and I did implement introspection support
<zyga> maybe I'm missing something
<zyga> I just want to be sure I understand what is going on
<jdstrand> zyga: it depends on the api too. yes, it lets you enumerate services that are installed (avahi, ofono, fwupd, others, ...) but the api can put info in there. eg, org.foo is fine by itself. you hot plug baz and bar and the foo service updates the api to have org.foo.bar and org.foo.baz
<jdstrand> nm does this sort of thing
<jdstrand> but, it is messy
<jdstrand> we have some leaky things already, sure, but we are going to be trying to fix those leaks, so I strongly prefer to not add new ones
<jdstrand> zyga: really what is going on is that I am only adding new accessing and not taking anything away
<jdstrand> accesses*
<jdstrand> and only adding ones that don't leak
<jdstrand> if there is some super-critical use case for opening up more, we can perhaps reconsider
<zyga> aha
<zyga> jdstrand: you are correct
<zyga> jdstrand: https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
<jdstrand> but sborokov mentioned a bug with pydbus and org.freedesktop.login1, and I'm fixing that and being safely proactive with everything else
<zyga> jdstrand: the smoking-gun there is the full dump of what is there
<zyga> jdstrand: object paths and what not
<zyga> jdstrand: thanks for explaining that
<jdstrand> np
<zyga> jdstrand: btw, do you think we should open bugs on the projects that use / as the object path?
<jdstrand> zyga: I thought about that. if it is a new service, yes. these ancient services we unfortuately can't cause clients would break
<zyga> jdstrand: ah, right
<zyga> well boo
<zyga> :/
<jdstrand> yeah
<jdstrand> good news is lennart is doing the right thing today (he (presumably) wrote the avahi dbus api, but the systemd object paths are clean)
<zyga> jdstrand: I kind of wish someone made a dbus proxy with turing-complete processing built in
<zyga> jdstrand: that would be secure to run in a separate tight sandbox (old-style seccomp)
 * zyga EODs
 * zyga updates https://spread.zygoon.pl/images/
<mup> PR snapd#3267 opened: cmd: make rst2man optional <Created by morphis> <https://github.com/snapcore/snapd/pull/3267>
<mup> PR snapd#3268 opened: Browser support sys devices <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3268>
<mup> PR snapd#3261 closed: snap-confine: init the ENTRY variable, coverity is unhappy otherwise <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3261>
<mup> PR snapd#2976 opened: support users and groups with seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2976>
<mup> PR snapd#2976 closed: support users and groups with seccomp <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2976>
<fede2> I'm getting a coredump on a snap for a python (pyqt5) application called URH (universal radio hacker)
<fede2> This is the snapcraft file https://github.com/fede2cr/snapcraft-sandbox/blob/master/limesdr-urh/snapcraft.yaml
<fede2> And I'm actually getting the same error as in this post https://askubuntu.com/questions/783758/pyqt-snap-builds-successful-fails-to-run
<fede2> I'm running on a freshly installed Ubuntu 16.04 with unity.
<fede2> Any suggestions?
#snappy 2017-05-04
<mup> PR snapcraft#1276 closed: sources: validate unknown source-type in yaml <Created by EduardoVega> <Closed by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1276>
<mup> Bug #1688103 opened: Classic confinement should allow preservation of $HOME <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1688103>
<mup> PR snapcraft#1297 opened: sources: validate unknown source-type in yaml <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1297>
<mup> PR snapcraft#1298 opened: Reroll of proposed JHBuild plugin <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1298>
<pstolowski> morning
<zyga> good morning!
 * zyga will be back soon, just overslept;
 * Chipaca looks around for a zyga
<mup> PR snapcraft#1299 opened: asset-tracking: save the dependencies of build packages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1299>
<Son_Goku> niemeyer: yo
<mup> PR snapd#3266 closed: interfaces: allow plugging DBus clients to introspect the slot service  <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3266>
<Chipaca> zyga: un zyga!
<Chipaca> zyga: hello, you
<zyga> Chipaca: hey, I was sleeping :/
<Chipaca> zyga: excellent
 * zyga feels dizzy today, perhaps it is a sign to take a day off
<Chipaca> zyga: if you're not feeling well, get out of here
<Chipaca> zyga: don't want to get internet cooties
<zyga> Chipaca: I just flet sleepy
<zyga> I'll file half a day off and take it slow
<Chipaca> zyga: how many hours did you sleep?
<zyga> not sure, I just got back here
<Chipaca> zyga: (if you're late from sleeping too much because the other days you were working late instead of sleeping, i don't think you should file half a day)
<zyga> no, last night my daughter decided to stuff instead of behaving like a normal child, she was up way past 1AM
<Chipaca> daughters gonna daught
<zyga> haha
<zyga> nice :)
<Chipaca> zyga: i've addressed your concerns in etelpmoc i think
<Chipaca> zyga: fwiw ${!x} is variable indirection
<Chipaca> i.e. if $x is foo, ${!x} is $foo
<zyga> indirection? so like ${${x}} ?
<zyga> a
<zyga> ah
<zyga> wow
<zyga> I didn't know that
 * zyga does that in make but not in bash
 * zyga hugs make
<Chipaca> zyga: i suspect https://travis-ci.org/snapcore/snapd/builds/228530132?utm_source=github_status&utm_medium=notification is the hook timeout thing
<zyga> Chipaca: looking
<zyga> Chipaca: though it should no longer time out AFAIK
<zyga> ha
 * zyga looks at details
<zyga> ah, yes
<zyga> perhaps master is not merged into this yet?
<Chipaca> zyga: that's correct, this is merging release/2.25 back into master
<Chipaca> all it is is the changelogs
<Chipaca> as such, I'm merging them even though travis is grumpy
<Chipaca> zyga: ok?
<Chipaca> agj! i can't
<Chipaca> well... not on the website anyway
<Chipaca> :-)
<zyga> Chipaca: I think we can merge master into that branch
<zyga> Chipaca: then it will merge
<zyga> Chipaca: it's silly but should work
 * zyga tries
<Chipaca> zyga: i can do this
<Chipaca> already have the branch
<zyga> ok
<zyga> Chipaca: question about the oldish PRs
<zyga> Chipaca: I feel we should fork and close the old PRs where we cannot push into them directly
<zyga> Chipaca: and take them over
<Chipaca> there, merged master
<zyga> Chipaca: thanks!
<Chipaca> zyga: which ones can't we push into directly?
<Chipaca> zyga: (yes, fork and close those, but which?)
<zyga> Chipaca: those that do not belong to team members, e.g. https://github.com/snapcore/snapd/pull/2869
<mup> PR snapd#2869: interfaces/builtin: add online-accounts-service interface <Created by mardy> <https://github.com/snapcore/snapd/pull/2869>
<Chipaca> zyga: that one says i can push to it
<zyga> Chipaca: oh? maybe bad example
 * zyga looks
<zyga> yes
<Chipaca> they would've had to manually untick the "let team members push" for it to be the case
<zyga> ah, that's good then
<zyga> maybe it's a new thing; I didn't see this before on those branches
<zyga> or maybe they ticked that back in between :)
<Chipaca> zyga: what do you want to do with snapd#3264?
<mup> PR snapd#3264: tests: remove quoting from [[ ]] when globs <Created by zyga> <https://github.com/snapcore/snapd/pull/3264>
<zyga> Chipaca: yeah, I'll look
<zyga> Chipaca: I think you are right
<zyga> Chipaca: and it might explain why it worked before
<zyga> Chipaca: the test was buggy twice
<Chipaca> zyga: morphis replied there
<zyga> Chipaca: so it worked
<zyga> Chipaca: oh, looking
<Chipaca> hehe
<zyga> haha
<zyga> nice
<zyga> morphis: thanks; I'll correct that
<zyga> done
<Chipaca> I'm still disappointed [[ doesn't properly ligature into ã
<zyga> oh
<zyga> it does :)
<zyga> btw, I have to show this to you
<zyga> if you like things like that
<zyga> https://github.com/tonsky/FiraCode
<Chipaca> there's a emacs mode that does that sort of thing when writing haskell
<zyga> if you work in atom
<zyga> it works in any language
<zyga> and I must say it does look very pretty and readable
<zyga> I use it
<Chipaca> i tried atom, but no
<Chipaca> muscle memory is a good thing to have, and it's wasted in atom
<zyga> you can use any editor that can grok font features like that
<Chipaca> (also, if i use emacs instead of atom, i can finally point at it and laugh about memory usage!)
<zyga> it's juts that only atom did (for the set that I tried)
<zyga> terminal is too dumb
<zyga> and I bet emacs (which I dind't try, or I'd be still trying to close it ;-) can too
<zyga> hahaha
<zyga> well
<zyga> I hate atom for constantly using 5-15% CPU
<zyga> for whatever
<zyga> and using 1.5GB of ram
<Chipaca> closing emacs is really hard: File -> Quit
<Chipaca> :-P
<Chipaca> (but, yeah, muscle memory)
<zyga> oh, it seems to work in kde kosole
<zyga> I know ^C^X
<zyga> or something like that
<zyga> ^X^C
<Chipaca> half of the time if i have to think of it i don't get it
<Chipaca> like, the combo for making a paragraph of text justified to a certain width
<zyga> I ran vim to try
<zyga> vim prints :quit instructions if you do :)
<zyga> I know how to use emacs but I just prefer vim
<Chipaca> :-)
<zyga> yeah
<zyga> I know how to do that in vim but I cannot remember, I have to just do it by trying
<Chipaca> yeap. And that's great :-)
<Chipaca> so why waste it
<Chipaca> anyway. lunch.
<zyga> ok, we have 30 branches
<zyga> I'm taking oldest one
<zyga> ok, let's skip that one
<zyga> I'll take 2nd oldest (mine)
 * didrocks is really happy about Visual Studio Code for any Go development. Doesn't use (from my testing) as much memory or CPU that atom, more feature, and font ligature with Fira Code as mentioned ;)
<Chipaca> didrocks: when it's in a snap i'll try it :-)
<mup> PR snapd#3270 opened: adjust Nice and oom_score levels for snapd <Created by ogra1> <https://github.com/snapcore/snapd/pull/3270>
<zyga> Chipaca: there's a snap
<zyga> Chipaca: sergio uses it
<zyga> didrocks: I love visual studio code btw
<zyga> didrocks: I really wish some of the new editors could be used on windows with ubuntu for windows
<zyga> (but if you do your files are wasted, poor implementation from microsoft)
<didrocks> zyga: yeah, I don't personnally have that issues, but indeed, this is one I imagine
<zyga> didrocks: well, on real ubuntu I just use vim :)
 * didrocks would miss sourcegraph on pure vim
 * ogra_ is always annoyed ending up with all the ":wq"'s in non vim edited files :P
<zyga> didrocks: what is sourcegraph?
<zyga> hehe
<mup> PR snapd#3271 opened: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
<morphis> zyga: ^^
<zyga> morphis: +1
<zyga> morphis: could we reuse the /etc/alternatives test
<zyga> morphis: and use environment trick to multiply it?
<zyga> morphis: I think it largely does this already
<morphis> zyga: sure
<zyga> morphis: can you please?
<zyga> morphis: (feel free to rename it to something appropriate)
<zyga> morphis: and this is very nice, it should fix docker on openssl!
<zyga> er
<zyga> opensuse :D
<zyga> openthis openthat
<morphis> docker and lxd :-)
<morphis> zyga: there is something still wrong in the test, however enough for a first review :-)
<didrocks> zyga: https://sourcegraph.com/, you can look up for references, how certain APIs are used in the wild (on github in particular), have the documentation and referenced linked to any usage, even in a PR on GH
<didrocks> doesn't work in all languages, but quite awesome in Go :)
<zyga> didrocks: interesting
<zyga> Chipaca: question, I need to teach interfaces about "snap try"
<zyga> Chipaca: we have snap.ConfinementType
<zyga> Chipaca: but that doesn't feel quite right
<Chipaca> zyga: tell me more -- why does snap try affect interfaces?
<zyga> Chipaca: because in try mode on encrypted $HOME we need special internal snippet
<zyga> Chipaca: I see that we also have interfaces.ConfinementOptions
<zyga> Chipaca: and that feels good, it's a struct with booleans
<Chipaca> try is not a confinement type
<zyga> Chipaca: it's not a type
<Chipaca> if you need it exposed, doing it via ConfinementOptions feels better, yes
<zyga> Chipaca: (not ConfinementType, ConfinementOptions)
<zyga> yeah
<Chipaca> zyga: yeah, was responding to your "we have snap.ConfinementType"
<zyga> I'll do that
<zyga> right
<zyga> IRC :)
<zyga> thanks!
<zyga> I didn't remember we have COptions
<zyga> crypted home is funky
<zyga> Chipaca: it's funny that all the work that went into update-ns can be reused from snapd now
<zyga> Chipaca: (as in looking for mounted cyptfs in /home)
<Chipaca> zyga: hilarious
<zyga> Chipaca: well, unexpected benefit of writing it in go
<Chipaca> :-)
<Chipaca> i think i need a nap
 * Chipaca grumpy
<zyga> Chipaca: do! I feel better after!
<zyga> Chipaca: siesta :)
<zyga> Chipaca: still here?
 * zyga traces the code from daemon to see what's happening
<Chipaca> zyga: yes
<zyga> Chipaca: I'm trying to grok if snap.Info is sufficient to know where snap try is coming from (where's the directory)
 * zyga would like to have a nice "snap list --internal" or something that showes all the data without any transformation but with mimimal pretty printing
<Chipaca> zyga: just hit the rest api :-)
<Chipaca> http snapd:///v2/snaps/thesnap
<zyga> ah
 * zyga tries
<zyga> hmm
<Chipaca> zyga: the "trymode" in the rest api is gotten from snapstate
<zyga> seems not :/
<zyga> I need the actual directory
<Chipaca> ah! you need the actual directory?
<zyga> yep
<zyga> I might infer that from bind mount data
<zyga> but scary
 * zyga looks at state
<niemeyer> Son_Goku: Heya
<niemeyer> Hi all
<ogra_> yo
<zyga> Chipaca: ah, we dont store that at all!
<zyga> Chipaca: it's thrown out after the change is done
<zyga> hey niemeyer
<Chipaca> zyga: it's SnapPath in the SnapSetup
<zyga> Chipaca: yes but that's in a change
<zyga> Chipaca: not in the state :/
<zyga> Chipaca: (snap state)
<Son_Goku> niemeyer: hey, so the snappy sprint date sounds good to me
<Son_Goku> but I need to first see if I can get the vacation block ;)
<niemeyer> Son_Goku: Sounds good, fingers crossed
<Chipaca> zyga: sounds like maybe we should store it in there if it's needed
<morphis> zyga: any idea why I get: [  306.778066] audit: type=1400 audit(1493902786.616:133): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/lock/" pid=8144 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<morphis> zyga: that is with my PR and latest snap-confine from master
<zyga> morphis: can you join our standup maybe?
<morphis> zyga: in another meeting right now
<mup> PR snapd#3249 closed: releasing package snapd version 2.25 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3249>
<morphis> zyga: anything important or you just want to talk about the error above?
<zyga> morphis: no, just wanted to have you in our standup
<morphis> zyga: ah :-)
<morphis> zyga: then feel free to put me on the attendees list
<morphis> if we're over here soon I will join
<zyga> ok
<zyga> I cannot do that thou
<ogra_> morphis, i think zyga meant "join it on a regular base" ... is the meeting you have right noow reguar at this time ?
<morphis> ogra_: just every thursday, ever other day is fine
<ogra_> ah, cool
<zyga> fgimenez: so the logs there have little information, perhaps the test needs to be tweaked to connect plugs/start docker some way?
 * zyga is unsure
<fgimenez> zyga: not sure, running in qemu right now, will let you know how it goes
<fgimenez> zyga: looks like a timing issue, from the debug console after the error "docker info" works just fine http://paste.ubuntu.com/24511102/
<zyga> yeah, it looks ok
<zyga> I wonder if this is intentional: Debug Mode (server): true
<mpt> <https://snapcraft.io/> is full of references to meta/snap.yaml. Is that (a) an old name for snapcraft.yaml, (b) a replacement for snapcraft.yaml, or (c) something else entirely?
<davidcalle> mpt, c
<zyga> mpt: c, it's a file read by snapd
<zyga> mpt: it's a file that describes a built snap
<mpt> aha
<mpt> davidcalle, zyga: Thanks. So does snapcraft (for example) produce the meta/snap.yaml as part of its output?
<pachulo> kyleN: are you around?
<pachulo> sorr, i meant kyrofa
<davidcalle> mpt, it's part of the produced snap
<zyga> mpt: yes
<zyga> mpt: it should be in prime/
<mpt> zyga, so meta/ is old-and-busted, and prime/ is new-hotness?
<zyga> mpt: no
<zyga> mpt: after you build something with snapcraft you should be able to see the unpacked snap in prime
<zyga> mpt: including snap.yaml in prime/meta/snap.yaml
<zyga> mpt: sorry, I didn't mean to imply that it is in a wrong place
<mpt> zyga, ok, so if snapcraft isnât involved then thereâs no prime/ directory?
<morphis> zyga: I am struggeling a bit to work with a self-build snap-confine, what is the best way to test one? just running $ make hack?
<zyga> mpt: yes
<zyga> mpt: prime is just a way that snapcraft implements its internal things
<zyga> mpt: snapd only looks at the build artefacts that are placed into the squashfs
<zyga> morphis: yes
<zyga> morphis: make hack works wonders :)
 * zyga uses it all the time
<zyga> morphis: note that you need to bind mount it to core too
<zyga> morphis: or use the version that ties this into the reexec flag
<zyga> morphis: or snapd will still load snap-confine from core
<mpt> zyga, understood, thank you. (Asking these questions because I have the job of reviewing+tweaking the snapcraft.io front page.)
<zyga> mpt: great, I'm glad to help
<zyga> jdstrand: hey, do you remember by any chance how 14.04 style encrypted home directory looked like
<zyga> jdstrand: what kind of filesystem was thta?
 * zyga looks for 14.04 iso
<morphis> zyga: something like `SNAP_REEXEC=0 snap run --shell hello-world` shoudl work?
<zyga> morphis: perhaps, just check if SNAP_REEXEC is the right variable
<zyga> morphis: or just to be sure
<zyga> morphis: bind mount snap-confine from distro over that in core
<zyga> morphis: then it always works
<morphis> zyga: if I add printf statements in snap-confine, should I see the output?
<mup> PR snapd#3272 opened: add interfaces-shutdown-introspection spread test <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3272>
<zyga> morphis: yes
<zyga> btw I was looking at systemd apis
<zyga> I may start using them to log errors
<zyga> they are really lovely!
<jdstrand> zyga: like on all releases, it is a stacked filesystem
<zyga> jdstrand: right but I recall it was different in 14.04
<zyga> I checked how it looks like in 16.04
<jdstrand> zyga: you mean the apparmor paths?
<zyga> jdstrand: no, I mean how it is reapresented
<zyga> jdstrand: I want to look through the mount tables to check if there's an encrypted home in use
<jdstrand> zyga: what you are describing I don't know what you are talking about. I know this:
<jdstrand>   # encrypted ~/.Private and old-style encrypted $HOME
<jdstrand>   owner @{HOME}/.Private/** mrixwlk,
<jdstrand>   # new-style encrypted $HOME
<jdstrand>   owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk,
<zyga> jdstrand: I know that too :)
<zyga> jdstrand: on 16.04 there's en "ecryptfs" mounted
<zyga> jdstrand: what is used on 14.04?
 * zyga checks anywy
<zyga> jdstrand: no worries, I'll find out soon enough :)
<jdstrand> zyga: so if it is other than that, 'no, I don't remember' (I never knew ;)
<jdstrand> zyga: you might ask Tyler (he is sprinting) if you can't get to the bottom of it
<zyga> nah I will know in 15 minutes
<zyga> just installing 14.04
<zyga> Chipaca: question/suggestion, I think we ought to track "snap-try" origin in state
<zyga> Chipaca: now where is the question? in side-info? feels icky
<jdstrand> morphis: to answer your question, your denial for 'c' on '/run/snapd/lock/' is because in whatever mount namespace snap-confine is currently running in, that dir doesn't exist
<morphis> jdstrand: hm
<zyga> morphis: ah, you may need to do one more thing
<zyga> morphis: you may need to bind mount the apparmor profile
<morphis> jdstrand: I got that with a simple $ snap run --shell
<zyga> morphis: from the distro onto the core snap
<morphis> zyga: bind mount?
<zyga> morphis: then restart snapd
<jdstrand> morphis: what distro?
<morphis> jdstrand: Ubuntu 16.04 but with a self-build snap-confine
 * jdstrand wonders why people are bind mounting apparmor profiles...
<zyga> morphis: mount --bind /etc/apparmor.d/usr.lib.snapd.snap-confine.real /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine.real
<jdstrand> ah
<zyga> jdstrand: deelopment
<zyga> ;)
<jdstrand> yes
<zyga> :D
<morphis> zyga: why is that needed at all?
<Chipaca> zyga: (thinking)
<morphis> if I set SNAP_REEXEC=0
<zyga> morphis: because snapd creates a new profile at runtime
<zyga> morphis: any SNAP_REEXEC is probably not working :)
<zyga> (just guessing)
<zyga> I bet it's not working and then you get the wrong snap-confine and the wrong profle
<morphis> zyga: when I call $ snap run --shell .. how is snapd then involved?
<zyga> if it did work you would not need to bind mount anything
<zyga> morphis: snapd compiles the apparmor profile of snap-confine from core on startup
<zyga> morphis: maaaagic ;)
<zyga> morphis: look at /etc/apparmor.d
<morphis> zyga: hm, I have snapd already running, calling `make hack` and then immediately `snap run --shell` afterwards
<zyga> morphis: do the bind mount
<zyga> morphis: reload snapd
<zyga> morphis: it'll work
<zyga> or check what really controls reexec
<jdstrand> morphis: to be more clear. if there is a bug in reexec, then snapd is loading the profile from /snap/core/current/etc/apparmor.d/... and not one that you may have loaded
<zyga> morphis: AFAIR there's a patch that fixes some of that (maybe reexec is unconditional)
<jdstrand> morphis: so if you bind mount over the one in /snap/core, you trick snapd to load your profile
<morphis> jdstrand, zyga: I still don't get how snapd is involved when I run $ snap run --shell
<zyga> morphis: it isnt
<zyga> morphis: but ... if snap run doesn't grok reexec feature
<zyga> morphis: and for whatever reason goes to "reexec" (not really) by running snap-confine from the core snap
<morphis> from what I read in the code it shouldn't with SNAP_REEXEC=0
<zyga> morphis: then the apparmor profile for snap-confine in the core snap applies
<zyga> morphis: well, debug away :)
<zyga> morphis: note: snap also reexecs
<zyga> morphis: so your snap reexes into core "snap" then runs snap-confine from either core or distro
<jdstrand> morphis: like zyga says, it doesn't. but, if you restart snapd for some reason and this reexec logic isn't right, then the profile in /snap/core gets loading into the kernel
<morphis> ok, I see
<zyga> morphis: and to finish that sentence, snapd on startup generates and loads the apparmor profile for snap-confine based on what is stored in the core snap
<zyga> morphis: (for the snap-confine from /snap/core/123/usr/lib/snaps/snap-confine)
<jdstrand> morphis: you should be able to apparmor_parser -r /path/to/the/profile/you/want/loaded and *not* restart snapd and have it work too
<zyga> morphis: each copy of snap-confine has a distinct profile
 * jdstrand is assuming there is a bug in reexec, as zyga guessed
<morphis> zyga, jdstrand: ok leaving the profile beside, I've added a few printf statements to my self-build snap-confine binary and then don't show up when I run snap run, bind mounts in place etc.
<zyga> morphis: does it show when you run it manually?
<zyga> morphis: did you forget to make hack again?
<zyga> morphis: note that after you bind mount I think make hack does weired stuff
<zyga> morphis: not sure
<zyga> weird*
<zyga> morphis: also journal has useful hints on reexec
<morphis> zyga: no I didn't, also verified with strace, however let me play a bit more
<pcercuei> hi
<pcercuei> I'm trying to package an app that requires a specific udev rule
<pcercuei> is there support for that?
<zyga> pcercuei: can you tell me more about the rule
<zyga> pcercuei: it is possible but it requires an interface
<zyga> pcercuei: that is merged in upstream snapd
<pcercuei> SUBSYSTEM=="usb", PROGRAM=="/bin/sh -c '/usr/bin/iio_info -s | grep %s{idVendor}:%s{idProduct}'", RESULT!="", TAG+="uaccess"
<pcercuei> that's my rule right now. "iio_info -s" scans the compatible USB devices, the udev rule gives users access to those
<pcercuei> the 'iio_info' tool would be inside my snap
<zyga> pcercuei: hmm, that would not work then
<zyga> (we don't have support for running helper progams from snaps)
<pcercuei> I can change the rule for a standard idVendor/idProduct check without calling an external program
<zyga> but we may have something else...
<zyga> pcercuei: so
<zyga> pcercuei: do you have your own gadget snap?
<zyga> pcercuei: we have the iio interface
<zyga> pcercuei: your gadget can describe such devices
<zyga> pcercuei: and then your app can have a plug to consume it
<pcercuei> it's a bit more complicated than that
<zyga> pcercuei: note that I have no idea what iio is in practice, I read the kernel docs about that a while ago but I never tried using anything like that
<pcercuei> IIO is a kernel framework, so I assume the 'iio' interface of snaps grant access to /dev/iio:deviceX and /sys/bus/iio/*
<pcercuei> however here, I'm doing IIO over USB
<pcercuei> with a server that uses FunctionFS on the USB device, and acts as a RPC more or less
<pcercuei> the client is libiio, which uses libusb to communicate with the server
<pcercuei> So the 'raw-usb' plug works fine in my snap, as long as the udev rule is installed
<zyga> it adds access to /sys/bus/iio/devices/$specific_device/
<zyga> pcercuei: the problem is that we don't have any hotplug capability in snapd yet
<zyga> pcercuei: and thus any such iio slot must be declared statically by the gadget snap
<zyga> pcercuei: the rest should work OK
<morphis> zyga, jdstrand: ok got it working now, not sure what my problem was before
<morphis> zyga, jdstrand: thanks anyway!
<pcercuei> I don't really care about hotplug - but when my snap starts, it should be able to see an already-plugged compatible device
<pcercuei> otherwise that means I have to ask my users to install a .deb so that the udev rule is installed, which defeats the purpose of having a one-file package
<zyga> pcercuei: not that your app, to get that permission needs an interface connection
<zyga> pcercuei: something on the system must show that there's a "iio" slot available
<zyga> pcercuei: and your app (and the snap containing it) must declare an "iio" plug
<zyga> pcercuei: and something must make the connection between the two
<zyga> pcercuei: only then can your app actually use that device
<zyga> pcercuei: and note that this only works in a core system with just snaps (no debs) so that you can use a gadget snap
<zyga> pcercuei: does that make sense to you?
<pcercuei> not really
<zyga> pcercuei: ok, let's start from one basic thing
<pcercuei> what on the system would say that there's a 'iio-usb' slot available?
<zyga> pcercuei: snaps get permissions only when an interface is connected
<zyga> pcercuei: (we'll get to that)
<zyga> pcercuei: a connection is made between a plug (consumer) and a slot (provider) that are compatible
<zyga> pcercuei: any snap can declare a iio plug
<zyga> pcercuei: but iio slots can only come from gadget or core snaps
<pcercuei> Yes; in my case, I plug to the 'usb-raw' slot
<zyga> pcercuei: becase there is no hot-plug detection the core snap does not declare any iio slots
<zyga> pcercuei: that leaves us with the gadget snap
<zyga> pcercuei: I'm unsure I understand how usb-raw and iio interplay here
<pcercuei> forget about IIO
<pcercuei> I'm just trying to communicate with a USB device; the data I transfer is related to IIO, but that's not relevant here
<zyga> pcercuei: so when you use usb-raw what denials are you getting?
<pcercuei> The problem I have, is that while I plug to 'usb-raw', I still can't communicate with the USB device, because it belongs to the 'root' user and isn't accessible by other users of the system, unless a udev rule is here to say so
<zyga> aha
<pcercuei> if I run my snap app with sudo, the USB device is properly detected
<zyga> so the app itself runs as an ordidinary user?
<zyga> ok
<zyga> I get it now
<zyga> this is a different issue, sorry for the confusin
<zyga> confusion*, one sec
<pcercuei> no problem :)
<Chipaca> zyga: wrt trymode, i think it's right that it goes in SnapState's Sequence
<Chipaca> zyga: what's more, i think trymode as a flag on SnapState itself is wrong
<zyga> Chipaca: yep, I agree
<Chipaca> zyga: (it's wrong, and results in buggy output in "snap list --all" when you have a snap installed and then do 'snap try' of the same snap
<Chipaca> )
<zyga> pcercuei: https://forum.snapcraft.io/t/snappy-and-users-and-groups/331
<zyga> pcercuei: have a look at this thread please
<zyga> pcercuei: it describes where we are with that
<pcercuei> thanks
 * zyga is starving but will be back soon
<zyga> pcercuei: 2. supporting device access via ACLs for granting access of devices to (non-root) users. https://launchpad.net/bugs/1646144
<mup> Bug #1646144: ACLs to devices need to be supported in core  <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Fix Committed by ogra> <ubuntu-core-meta (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1646144>
<ogra_> thats fixed in edge
<zyga> ogra_: that's just a sliver of the problem
<zyga> ogra_: the whole thing is not implemented
<ogra_> yeah
<pcercuei> ah, that's unfortunate
<ogra_> well, using a gadget and adding the rule there would work though ...
<ogra_> as well as adding the rule manually to an image
<ogra_> (its just linux after all ... )
<kuhlmant> I have submitted for a name in the Ubuntu Store, 'mojo' to be used for a snap. This was a couple of days ago and I'm wondering what the process is and the expected processing time?
<zyga> ogra_: not sure, can a gadget add arbitrary udev rules?
<zyga> ogra_: the problem is that the user running this isn't root
<ogra_> well, the rule is run by udev
<zyga> ogra_: which rule? can a gadget add arbitrary unconfined rules?
<ogra_> and i think you are able to ship anything in system-data/etc/
<ogra_> iirc ubuntu-image has code to copy all such stuff
<morphis> zyga: updated https://github.com/snapcore/snapd/pull/3271 and combined both test cases
<mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
<Chipaca> kuhlmant: i think you need to start a forum thread about it
<pcercuei> ogra_: gadget snaps look like something to generate OS images
<kuhlmant> Chipaca: I guess I can do that, I didn't think there as much to discuss so haven't. If starting a forum thread is the standard process though I will. What is next typically?
<pcercuei> ogra_: my snap would run on Ubuntu, Debian, Fedora etc.
<ogra_> pcercuei, yes, indeed they are ... zyga mentioning the gadget above made me think you were on UbuntuCore, sorry
<pcercuei> ok
<ogra_> (i could have asked :P )
<ogra_> though i couldnt imagine an UbuntuCore multi-user system ... that could have told me what you want :)
<morphis> zyga: you remember when you looked into https://bugs.launchpad.net/snappy/+bug/1644573 which parts of the go std library were trying to use IPv6?
<mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573>
<station> can ubuntu core be instaled as an Gateway/Router/Server or is it a bad idea, is there a tut
<station> +firewall
<mup> PR snapd#3273 opened: tests: wait for the docker socket to be listening <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3273>
<Chipaca> station: yes it can (dell is shipping such a thing for example)
<station> well I cnow but is there a DIY Tut?
<station> if I set to grab a firewal Docker Image and sow on, would't that either take for ages or function like crap at the moment
<station> or can I plunge myself into the unknown and be a happy Firewall/ Gateway /Router/Server user in like 5h
<Chipaca> station: I don't think there's a tutorial aimed at that specifically
<Chipaca> station: but if what you're looking for is to create a one-off thing, as opposed to a product, it's merely a question of installing the right snaps
<ogra_> there should be a ufw snap
<ogra_> and there is a wifi-ap snap
<ogra_> so a firewall and an AP are definitely possible
 * ogra_ wouldnt put docker in the loop ... thats just useless overhead
<kyrofa> Hey pachulo, did you need me?
<mup> Bug #1688103 changed: Classic confinement should allow preservation of $HOME <Snapcraft:Invalid> <Snappy:Invalid> <https://launchpad.net/bugs/1688103>
<mup> PR snapd#3264 closed: tests: remove quoting from [[ ]] when globs <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3264>
<mup> PR snapd#3267 closed: cmd: make rst2man optional <Created by morphis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3267>
<mup> PR snapd#3254 closed: tests: re-enable and moderninze /media sharing test <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3254>
<Chipaca> zyga: super easy review: snapd#3270
<mup> PR snapd#3270: adjust Nice and oom_score levels for snapd <Created by ogra1> <https://github.com/snapcore/snapd/pull/3270>
<Chipaca> pstolowski: zyga: and please finish your reviews of my completion branches...
<pstolowski> Chipaca, will do tomorrow first thing in the morning, sorry about that
<Chipaca> morphis: thanks!
<mup> PR snapd#3270 closed: adjust Nice and oom_score levels for snapd <Created by ogra1> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3270>
<morphis> Chipaca: np
<mup> PR snapd#3240 closed: snap: add `snap refresh --time` option <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3240>
 * ogra_ hugs Chipaca 
<diddledan> what should I put in the CLA form for "Canonical Project Manager or contact" so that my snapcraft submission can be accepted?
 * zyga will soon return to code reviews
<Chipaca> diddledan: what options are there?
<diddledan> it's a blank text field
<diddledan> but it won't accept a blank entry
<Chipaca> diddledan: ah. Jamie Bennet
<diddledan> ok I took that. agreement now signed \o/
<diddledan> s/I/it/
<Chipaca> :-)
<jdstrand> zyga: hew, fyi, be87d017 broke 'make check' on (at least) xenial and earlier because it doesn't support -x
<jdstrand> zyga: 'make check' for snap-confine when shellcheck is installed that is
<jdstrand> hey*
<jdstrand> zyga: and uninstalling shellcheck makes 'make check' fail
<jdstrand> zyga: ugh, all the annotations need a newer shellcheck
<jdstrand> well, maybe not all, but a bunch
<jdstrand> workaround seems to be to install shellcheck from zesty
<jdstrand> zyga: does this ^ mean 'make check' isn't run during the LP builds? that would be unfortunate
<jdstrand> zyga: it seems the fix would be to check if '-x' is supported and if not, skip the syntax check
<jdstrand> zyga: or checking 'shellcheck --version'
<jdstrand> zyga: or shipping shellcheck in the sources so it is always the same
<jdstrand> anyway, I'm not blocked
<zyga> re
<zyga> jdstrand: ay, I know about shellckeck, unfortunate :/
<zyga> jdstrand: you can make it pass by re-running autogen.sh
<zyga> jdstrand: shellcheck is written in haskell so insane to ship
<zyga> jdstrand: I thought about it and my secret desire is to have a shellcheck backport as everything else is hard (including shellcheck as a snap)
<zyga> jdstrand: or alternatively do a non-backport update of shellcheck
<zyga> jdstrand: but that's something foundations would have to comment on
<zyga> slangasek: hey
<jdstrand> interesting
<zyga> slangasek: quick question; what is easier, backport newer shellcheck to xenial or use shellcheck as a snap while building snapd?
<zyga> slangasek: interestingly we could move the package from xenial to, say, zesty, and then do xenial backports
<jdstrand> afaik the former since the latter isn't supported (declaring Build-Deps on snaps)
<zyga> slangasek: then zesty shellcheck is good
<jdstrand> you also can't do LP builds for the archive against -backports
<zyga> jdstrand: aww :/
<jdstrand> archive builds*
<zyga> jdstrand: right
<zyga> jdstrand: well
<zyga> jdstrand: I think it's semi-ok
<zyga> jdstrand: what need to change
<zyga> jdstrand: is that >16.04 builds should pull in shellcheck
<jdstrand> sru 0.4.4 to xenial would be fine
<zyga> jdstrand: then we'll know during daily CI via adt
<zyga> jdstrand: yeah? I'll check if it builds quickly
<jdstrand> but, really, as you say, just skipping the shellcheck where the version is known not to work is fine
<jdstrand> it is just we don't want to disable all of 'make check' to avoid the shellcheck issue
 * zyga has a love hate relationship with shellcheck, it's amazing and haskel is interesting but man, haskel toolchain stuff is terribly annoying to work with
<zyga> jdstrand: oh, I think it's not that, we just skip shellcheck
<zyga> jdstrand: we still run other checks
<zyga> jdstrand: (for sure)
<zyga> one thing we should do soon is to enable hard error checking on valgrind
<jdstrand> imho, it is fine to not run check-syntax-sh on 16, since we are getting all the benefits from the versions of Ubuntu with the used shellcheck
<zyga> but some of that is hard as there's plenty of false positives because we fork/exec and use glib for testing
<zyga> yes, I agree
<jdstrand> it's kind of funny to implement a tool in a rather niche language to syntax check a ubiquitous language
 * jdstrand didn't realize it was haskell
<zyga> jdstrand: yeah, I read the implementation, it is really beautiful
<zyga> jdstrand: hey
<zyga> jdstrand: can you have a look at https://github.com/snapcore/snapd/pull/2837/files
<mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
<zyga> jdstrand: not a detailed review
<zyga> jdstrand: I'm still working on extra tests
<zyga> jdstrand: just tell me if that fits your idea
<jdstrand> zyga: there was another conversation on that somewhere...
<jdstrand> zyga: I'm not imagining that am I?
<jdstrand> zyga: oh, heh, nm
<mup> PR snapd#3273 closed: tests: wait for the docker socket to be listening <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3273>
<jdstrand> the conversation was in that PR-- I was thinking this was a brand new PR :)
<zyga> jdstrand: :D
<zyga> jdstrand: it's my oldest PR ever
<zyga> jdstrand: there's one obvious nastiness there
<zyga> jdstrand: _any_ ecryptfs gives _any_ try mode snaps the extra snippet
<zyga> jdstrand: but we can remove that nastiness soon, chipaca said we should rework the state a little to store trymode flag in a per-revision thing
<zyga> jdstrand: and then we can also store the path
<zyga> jdstrand: (currently snapd just doesn't know)
<jdstrand> I'm actually already commenting on that
<zyga> thank you!
<zyga> jdstrand: thanks!
<jdstrand> np
<slangasek> zyga: you can't build-depend on snaps at all currently
<Chipaca> ogra_: you around?
<mup> PR snapd#3268 closed: interfaces/browser-support: deny read on squashfs backing files and LVM vg names <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3268>
<Son_Goku> niemeyer: so I've made the vacation request
<Son_Goku> fingers crossed!
#snappy 2017-05-05
<zyga> Chipaca: good morning
<Chipaca> zyga: morning
<zyga> Chipaca: I'm seeing this error all the time:
<zyga> src/github.com/snapcore/snapd/vendor/golang.org/x/crypto/ssh/test/test_unix_test.go:25:2: cannot find package "golang.org/x/crypto/ssh/testdata" in any of:
<zyga> does it ring any bells? anything changed in how we vendor stuff?
<Chipaca> zyga: i have never seen it before
<morphis> zyga: I've seen this once in a fedora build where we missed to copy testdata into place
<morphis> but actually that was for one of our packages not the ssh one
<zyga> Chipaca: ok, separate topic, I asked mvo how we might go ahead with storing more data into sequence but he didn't reply; I was thinking about storing a 2nd sequence like object
<zyga> hey morphis :)
<morphis> zyga: hey!
<zyga> Chipaca: so that we can get away without patching anything in the state
<zyga> Chipaca: so sequence-ex could store more stuff (flags, path, side info)
<zyga> Chipaca: wdyt?
<Chipaca> zyga: type SuperInfo struct { *SideInfo }
<morphis> zyga: do you have time for another review on https://github.com/snapcore/snapd/pull/3222 ?
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<zyga> morphis: yes, I'll focus on reviews today (again)
<zyga> morphis: I was off yesterday (despite being here a little)
<zyga> Chipaca: super info I like
<Chipaca> zyga: and make Sequence be []SuperInfo (or []*SuperInfo)
<zyga> Chipaca: hmm
<zyga> Chipaca: though
<zyga> maybe not sure, we risk clashing fields
<zyga> Chipaca: why not just sequence-ex with dedicated fields?
<zyga> (we can clean up when patches are live)
<Chipaca> zyga: because then you have to keep to slices in sync?
<zyga> yes
<Chipaca> zyga: and decide how to handle drift
<zyga> I planned to already
<zyga> hmm
<zyga> in case of rollbacks?
<morphis> zyga: thanks
<zyga> well, this is already equally hard, there is no required data currently, we'd have to add the data only to the new sequence
<zyga> and this is only for snap try, it is still broken today in master (from this pov) so it'd not be a regression
<Chipaca> zyga: i mean, what's the advantage of having a second sequence instead of adding to the existing?
<Chipaca> zyga: you're seeing something there that I am not
<zyga> Chipaca: the advantage is that the second sequence would not embed a go type so it cannot clash on field names there;
<Chipaca> zyga: we could even add SnapPath to SideInfo
<Chipaca> ogra_: ping?
<zyga> Chipaca: hmm hmm
<zyga> Chipaca: the problem is that we may need more than just snap path
<zyga> Chipaca: what I think we need to capture in this particular case is the fact that it was on encrypted directory
<zyga> Chipaca: more so than the fact than the actual path (which I would capture anyway)
<Chipaca> zyga: it being on an encrypted directory is something that should be detected at runtime, fwiw
<zyga> Chipaca: no, because it may not even be mounted :/
<Chipaca> ok, wait
<Chipaca> if it's not mounted, why do you need to know if it's encrypted?
<zyga> Chipaca: have a look at the discussion here https://github.com/snapcore/snapd/pull/2837#discussion_r114855843
<mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
<zyga> Chipaca: because it was encrypted when the user is logged in
<zyga> Chipaca: then she logs out
<zyga> Chipaca: and snapd restarts
<zyga> Chipaca: and needs to write the apparmor policy
<zyga> Chipaca: :/
<Chipaca> zyga: brb
<zyga> no worries, I wanted to let you know about this to get you thinking
<zyga> I'll try to fix it today but I want to agree on direction
 * zyga -> breakfast
<Chipaca> zyga: if the directory of a snap try goes away, the snap is removed
<Chipaca> zyga: several rough edges here though
<Chipaca> zyga: one is: if you snap install foo, and then snap try ./foo, you end up with a foo from the store and a foo from try. We don't handle this case well today at all (the whole snap is in "try mode")
<Chipaca> zyga: and the question is, if the directory goes away in this case, what should happen? should it fall back to the non-try one?
<Chipaca> i'd suggest we solve this by not allowing mixing try and non-try, at least for now
<Chipaca> (any mixing of try and non-try can be made explicit with flags, later, where we don't mix them in state but copy config over or whatever)
<Chipaca> this avoids all the uncomfortable corner cases of mixing the two modes
<Chipaca> and makes the current approach of having 'trymode' on the snap (instead of the sequence) fine
<Chipaca> and gives us an easy approach to getting the snap path, whichi is to add it next to trymode
<Chipaca> the 'patch' code can look in changes for the snapsetup, or at the mount unit
<Chipaca> (or we could look at the mount unit in runtime, but that feels 15.04ish :-) )
<Chipaca> zyga: i'm creating a forum topic about this
<Chipaca> zyga: https://forum.snapcraft.io/t/disallow-mixing-try-and-non-try-snap-installs/484
<ogra_> Chipaca, yes ?
<Chipaca> ogra_: two questions for you sah
<Chipaca> ogra_: we nuke locale support from core, yes?
<Chipaca> or have we added it back recently
<Chipaca> ogra_: (good morning! how're you doing today?)
<ogra_> Chipaca, nope, actually locale support was nuked everywhere now (ubuntu-base, cloud images etc)
<Chipaca> ogra_: ok. 2nd question, what is the locale-control interface for, do you know?
<ogra_> i guess nothing ... but since we never shipped locales thats fine i guess
<ogra_> (thank you i'm fine :) )
<Chipaca> ogra_: i mean, we even have a snap to test it works
<ogra_> not on core
<zyga> Chipaca: thank you!
<ogra_> we never did to my knowledge
<Chipaca> so /etc/default/locale is from "outside", on classic?
<ogra_> thats a zyga question, not sure if snap-confine mounts it
<Chipaca> zyga: ^ :-)
<Chipaca> ogra_: by the way, it looks like core is currently shipping the locales for e2fsprogs
<Chipaca> ogra_: i assume that's a bug
<ogra_> hmm, i wonder how they get there
<ogra_> yes
<zyga> Chipaca: replied on the forum
<ogra_> seems fwupdate too
<zyga> Chipaca: mmm, /etc/default/locale is from classic
<Chipaca> zyga: ok, good
<Chipaca> ogra_: and is /etc/default/locale writable in core?
<zyga> Chipaca: but also (this is an ogra topic :) on core we do some writable path magic I'm not fully versed in
 * ogra_ hopes /usr/share/locale too
<ogra_> Chipaca, i dont think so ... it should be hardcoded to C.UTF-8
 * ogra_ checks
<ogra_> ogra@pi3:~$ mount |grep locale
<ogra_> ogra@pi3:~$ cat /etc/default/locale
<ogra_> LANG="C.UTF-8"
<ogra_> yep
<Chipaca> if the idea of locale-control is to not work at all on core, we should probably check for that
<Chipaca> ogra_: and non-writable?
<ogra_> see the mount :)
<ogra_> (yes, non-writable)
<Chipaca> ah :-)
<Chipaca> ok
<ogra_> doesnt mean that wont change in case we get langpack snapsd or some such indeed
<ogra_> *snaps
<Chipaca> I'm pretty sure locale-control needs fixing to work on !debianish
<Chipaca> morphis ^
<ogra_> i'm pretty sure they dont have /etc/default on non-debian
<zyga> Chipaca: I think the whole /etc design is broken today
<zyga> Chipaca: we want to entirely stop sharing /etc
<zyga> Chipaca: and share (or mirror) selective elements
<Chipaca> all these locale questions are because of https://askubuntu.com/q/910514/711 btw
<morphis> Chipaca: locale-control happy isn't "broken" on any !debian system today as we don't have confinement anywhere ..
<Chipaca> morphis: it's broken in that it doesn't do what's intended
<Chipaca> i.e. it doesn't change the default locale of the system
<morphis> Chipaca: doesn't it just allow access to /etc/default/locale via AppArmor?
<Chipaca> morphis: yes
<Chipaca> exactly
<Chipaca> that is not a thing in !debian, afaik
<morphis> sure
<morphis> but we don't have any AppARmor on anything else than Ubuntu today
<Chipaca> ah, now i gotcha
<Chipaca> ok
<morphis> if we get AppArmor anywhere else I think we can easily add the right paths to the AppARmor snippet
<ogra_> you can ship translations inside your snap and use them (not sure if the content interface would work here but i guess with the correct env set in your wrapper it should)
<ogra_> there are env variables for this
<AdamH_> Hello, is there a work around available for the problems with apt-get update on an arm board when running in classic snap on Ubuntu core?
<zyga> Chipaca: so quick question about try, is that the current design that if the directory goes away try mode snap should uninstall itself?
<zyga> AdamH_: hey, do you have some more details about the issue?
<AdamH_> zyga: This is the bug I am experiencing https://bugs.launchpad.net/snappy/+bug/1670475
<mup> Bug #1670475: apt-secure complaints with classic snap on arm <Snappy:New> <https://launchpad.net/bugs/1670475>
<zyga> ogra_: ^ I had a look at the bug but I don't know anything about it
<zyga> ogra_: do you know what the root cause is?
<zyga> ogra_: ports vs non-ports archive?
<ogra_> zyga, something with gnupg, i'm still not sure what ... has nothing to do with any archive servers, thats a local issue with the classic snap
<zyga> ogra_: any idea why it is specific to arm?
<zyga> ogra_: could it be some version of gpg that we've seeded into the images due to snappy?
<zyga> ogra_: gnupg 1 vs 2
<ogra_> zyga, that would be odd, i rather thing we remove to much when wrapping up the tarball for core
<ogra_> *think
<zyga> AdamH_: so there you go, I don't know anything more
 * zyga reviews https://github.com/snapcore/snapd/pull/3222/files
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<AdamH_> zyga: Thank you
<ogra_> AdamH_, the "workaround" is described in the bug though ... (turn off gpg checking)
 * ogra_ glares at the first line of https://forum.snapcraft.io/t/failed-to-flush-stdout-permission-denied/485 and tries to wrap his head around that command
<ogra_> wondering if he made a typo there or if there is actually a snap that calls apt install
<Chipaca> zyga: I thought it was, but it isn't
<Chipaca> zyga: (the current behaviour for snapd to remove a try that vanished)
<Chipaca> it goes into broken state
<AdamH_> zyga: Yes I tried sudo apt-get --allow-unauthenticated upgrade but still get the same error? Is there a better way to disable the check?
<ogra_> AdamH_, upgrade ? you mean update, right ?
<AdamH_> ogra: Yes sorry I mean update
<ogra_> heh, k :)
<ogra_> likewise you should be fine just typing Y on the question about unauthenticated packages
<pachulo> yes kyrofa ! I'm looking at this: https://github.com/nextcloud/nextcloud-snap/issues/60 and was trying to compile the nextcloud-snap for my rbpi3, after hitting the out of RAM issue when compiling mysql I found out your post (https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way) but I the 3 builds I tried all failed:
<pachulo> https://launchpadlibrarian.net/318427985/buildlog_snap_ubuntu_xenial_armhf_nextcloud-snap-pachulo_BUILDING.txt.gz
<AdamH_> ogra: I don't get a prompt when trying to update, only when I am installing a package
<ogra_> AdamH_, yeah, thats what i mean
<ogra_> it should install afterwards
<AdamH_> ogra: Yes it does
<Chipaca> pachulo: I think it's about 2am for kyrofa; try in a few more hours
<Chipaca> zyga: where does the decision to include or not include (say) unity7 in the core snap come from?
<Chipaca> jdstrand: when you're around, i'd like to look at the issue of _filedir
<zyga> Chipaca: in snap/implicit.go
<Chipaca> aha, no wonder i couldn't find it in interfaces :-)
<Chipaca> zyga: I think locale-control needs to move to implicitClassicSlots
<pachulo> thanks Chipaca !
<Chipaca> zyga: ogra_: right?
<mup> PR snapd#3274 opened: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
<zyga> Chipaca: I think some commercial products use that slot but if you guys say it does nothing on core we need to re-visit thi
<morphis> Chipaca: if you move it somebody should query the store to see if there are any snaps which use that interface already
<Chipaca> morphis: zyga: I can confirm that if a snap does use that interface, attempting to actually modify the locale fails
<Chipaca> in core
<morphis> Chipaca: yeah, however we need to ensure we don't break existing snaps which are installed on a core system today and use that interface
<Chipaca> morphis: yep
<morphis> Chipaca: if snapd handles that already nicely, then I am fine
<Chipaca> sadly answering that question is harder than it should
<Chipaca> cannot create lock directory /run/snapd/lock: Permission denied
<Chipaca> pstolowski: ^ halp?
<ogra_> Chipaca, yeah, i guess locale-control being classic only is fine
<Chipaca> pstolowski: suspect version mismash but i don't know of what :-)
<morphis> zyga: you got "cannot find package "golang.org/x/crypto/ssh/testdata"" fixed?
<morphis> seeing that on travis now
<pstolowski> Chipaca, where do you see that?
<Chipaca> pstolowski: when trying to run any app
<Chipaca> pstolowski: but i might have snap-confine from master and snapd from elsewhere
<pstolowski> uh
<Chipaca> so it's probably me (but please advise)
<zyga> morphis: no
<zyga> morphis: not sure what's going on really
<pstolowski> Chipaca, how about checking the versions? dpkg -l|grep snap
<zyga> Chipaca: snap-confine misalinged with profile
<zyga> Chipaca: seems exactly the same what morphis ran into yesterday
<Chipaca> pstolowski: i'm not running any of the things from the package at this point
<zyga> Chipaca: are you playing around with development versions of snap-conifne?
<Chipaca> snap-confine is from yesterday's master
<Chipaca> snapd is snapd/2.24+git605.g2eda802.dirty
<zyga> Chipaca: ok
<zyga> Chipaca: how did you install it?
<Chipaca> snap-confine? make hack
<zyga> Chipaca: in general you need make hack + several bind mounts :/
<zyga> Chipaca: one for the binary into core (or disable reexec)
<zyga> Chipaca: one for the apparmor profile into core
<Chipaca> snapd, built it by hand and run-snapd-srv
<pstolowski> ok, i'm glad zyga jumped in, because i'd never have guessed :}
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> Chipaca: the issue is that snap runs snap-confine from core and then the apparmor profile is in /etc/apparmor.d/snap.core.$number.usr.lib.snapd.snap-confine.real
<zyga> Chipaca: and then that thing must match the one that was made by make hack
<Chipaca> zyga: snap only runs snap-confine from core if it reexecs though
<zyga> Chipaca: except for the paths (revision in core0
<Chipaca> so maybe my snap is from package
<zyga> Chipaca: maybe bug? check if you have snap
<Chipaca> that might explain that
<zyga> Chipaca: (built from source)
<zyga> Chipaca: anyway, a dumb solution is just to bind mount the apparmor profile over that in core and restart snapd
<Chipaca> zyga: pstolowski: updated snap (manually) and snap-confine (make hack) fixed it
<Chipaca> no bind mounts needed
<zyga> morphis: https://github.com/snapcore/snapd/pull/3222#pullrequestreview-36469425
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<zyga> morphis: reading rest
<zyga> Chipaca: yep, this means that snap is honring reexec correctly!
<mup> PR snapd#3275 opened: snap: move locale-control to only be present on classic <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3275>
 * zyga finds code review in gitk better/faster than on github
<zyga> :/
<ogra_> trying to debug that apt issue i get the feeling it is related to how we handle /tmp
<zyga> ogra_: oh?
<zyga> ogra_: how do we handle /tmp on classic?
<zyga> it's just the regular tmp, right?
<zyga> (regular in snap execution environment)
<ogra_> we dont do anything at all
<ogra_> what i see in the logs is http://paste.ubuntu.com/24516298/
<ogra_> see how it tiresd to use /var/snap/classic/common/classic/tmp/fileutl.message.wopbff
<zyga> wow
<zyga> what an insane profile!
<zyga> ah wait
<zyga> name="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff"
<zyga> so /tmp is special!
<ogra_> it is --devmode
<zyga> it's a persistent /tmp in $SNAP_COMMON
<ogra_> (classic)ogra@pi3:~$ touch /tmp/foo
<ogra_> (classic)ogra@pi3:~$
<ogra_> (in one terminal)
<ogra_> ogra@pi3:~$ ls -l /var/snap/classic/common/classic/tmp/
<ogra_> total 0
<ogra_> -rw-r--r-- 1 ogra ogra 0 May  5 10:28 foo
<ogra_> (in the other)
<ogra_> so it actually writes there
<ogra_> permissions and all seem fine too
<ogra_> yet, apt prints exactly that line every time it spills the gpg error
<zyga> ogra_: that?
<ogra_> ?
<zyga> ogra_: "that line", which line is that?
<ogra_> the one from the paste above
<zyga> ogra_: what is ="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff"
<zyga> is that a socket?
<zyga> mknod being the thing that is not normally allowed
<zyga> maybe we can now allow it and use seccomp filtering
<ogra_> well, --devmode ... so it is aloowed
<ogra_> sigh .... i wish that log output would be somehow readable
<zyga> ogra_: yeah
 * zyga would like to understand what that profile name means 
<zyga> jjohansen: ^ if you can help me out
<ogra_> these lines are way to long to even grasp them
<zyga> to quote so that you don't have to hunt pastebins:
<zyga> May  5 10:12:22 pi3 kernel: [ 7741.891667] audit: type=1400 audit(1493979142.467:148626): apparmor="ALLOWED" operation="mknod"
<zyga> profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common
<zyga> /classic/usr/bin/apt-get" name="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff" pid=12088 comm="apt-get" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<ogra_> well, due to the ALLOWED it should technically work
<zyga> yes
<zyga> it does work
<zyga> whatever happens it is something else that's broekn
<zyga> broken*
<ogra_> well, nothing in classic changed when it started to happen
<ogra_> it must be releated to the surrounding env
<ogra_> i see that /etc/apt/trusted.gpg is intact and contains the right keys ... i can also list them with apt-key list ...
<ogra_> gnupg (1) is also installed fine and working otherwise
<ogra_> (i can also add/remove keys with apt-key just fine)
 * zyga has a crazy idea 
<zyga> to have a snapd that lives in an execution environment by itself
<zyga> so snapd would run in a snapd namespace
<zyga> that is consistent across distros more than the helper snapd outside
<zyga> morphis: one more question on that PR
<zyga> morphis: at the bottom
<mup> PR snapd#3276 opened: tests: additional setup in docker test for core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3276>
<zyga> Chipaca: hey
<zyga> Chipaca: back to that sequence topic
<zyga> Chipaca: do you think this is something worth tackling today or better next week when gustavo can voice his opinion?
<Chipaca> zyga: well, there's a bunch of work to be done. Is there any you can tackle without his input?
<Chipaca> zyga: e.g. the code to grab SnapPath from existing state, for the migration
<Chipaca> zyga: the code to determine whether a directory is part of an ecrypt-encrypted volume
<Chipaca> not volume. Tree? path? w/e
<Chipaca> zyga: i'd start there, and that's probably fiddly enough to take you over to monday
<zyga> Chipaca: that is actually easy (a simple extension of what I wrote yesterday) but I think it is stuck on a design decision: of how snaps behave when a volume is not mounted
<Chipaca> zyga: currently, they go to 'broken' state
<zyga> Chipaca: yeah but what do we _want_ to happen?
<Chipaca> zyga: yeah, that's design -> involves gustavo
<zyga> yeah
<zyga> let's do it next week
<zyga> ok next branch
<Chipaca> (worse, it's design i don't have an opinion on myself :-) )
<zyga> haha
<pstolowski> zyga, are you working on a fix for https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464/4 ?
<Chipaca> pstolowski: no, you were
<pstolowski> Chipaca, I intended to, but then zyga commented in the topic saying he would make it happen ;)
<Chipaca> pstolowski: (i mean, that's what you said yesterday in the standup? or did i misunderstand?)
<Chipaca> ahh
<Chipaca> see, ordering is important :-p
<Chipaca> ok
<Chipaca> pstolowski: maybe his intention was to make it happen by bossing you around
<pstolowski> :D
<zyga> pstolowski: not at present, I'm doing code reviews again
<zyga> hahaha
<zyga> pstolowski: I think I commented on that earlier but perhaps I'm mistaken :)
<zyga> pstolowski: feel free to take it
<Chipaca> zyga: With unity 8 going away, does adding online-accounts interface make sense?
<Chipaca> zyga: should we instead nuke all the unity8 support interfaces?
<Chipaca> as unity8-in-a-snap is prooobably not going to happen
<zyga> Chipaca: I'd not nuke anything, people are free to hack on those
<pstolowski> zyga, ok
<Chipaca> zyga: but if nothing is using them (and nothing is afaik) then they bitrot
<pstolowski> Chipaca, yeah, we talked about this some time ago on the standup.. unity8 may be developed by community, there is some interest in continuing the project
<Chipaca> fair enough
<Chipaca> brb (rebooting)
 * zyga thinks that bitroot is an interesting problem
<jjohansen> zyga: its a learning/complain mode profile. The name starts with the profile that caused the exec chain
<jjohansen>   snap.classic.classic
<jjohansen> and then each //null-  is a new layer of exec, so what ever was confined by snap.classic.classic did an exec of
<jjohansen>   /usr/bin/systemd-run  which called
<jjohansen>      /usr/sbin/chroot  which called
<jjohansen>           /var/snap/classic/common/classic/bin/dash  which called
<jjohansen>                /var/snap/classic/common/classic/usr/bin/script  which called
<jjohansen>                    /var/snap/classic/common/classic/bin/bash  which called
<jjohansen>                         /var/snap/classic/common/classic/usr/bin/sudo  which called
<jjohansen>                               /var/snap/classic/common/classic/bin/bash  which called
<jjohansen>                                     /var/snap/classic/common/classic/usr/bin/sudo   which called
<jjohansen>                                           /var/snap/classic/common/classic/usr/bin/apt-get
<jjohansen> that final descendant caused the log message
<dragly> zyga: What is the status on OpenGL with Intel drivers? Should it work? I'm having trouble getting Qt an OpenGL context.
<jjohansen> that is quite a call chain, under older versions of apparmor you would have only see null-XXX where XXX is a unique number instead of the actual exec names
<jjohansen> which was far less useful but did result in smaller names
<zyga> jjohansen: thank you for the description!
<zyga> dragly: there's no magic in snapd for opengl on intel, we don't bring any drivers form any other place, whatever the snap ships will run (or not)
<zyga> dragly: all openGL situation nees love
<ogra_> GL surely works on clasic with intel for me
<zyga> ogra_: sure but my point is that it depends on hardware *and* snap
<zyga> ogra_: snapd should use opengl indirection helpers and load the right driver
<ogra_> well, i only ever try witrh the krita snap
<zyga> ogra_: but nobody implemented that yet
<zyga> ogra_: and snaps should not ship drivers
<zyga> ogra_: (except for driver snaps)
<zyga> ogra_: but now none of that is true
<ogra_> i know that makes havy use of GL ... so if you can install and run that one there is *some GL*
<ogra_> (used to work also on my nvidia desktop)
<zyga> ogra_: as I said, there is whatever the snap author bundles
<zyga> ogra_: snapd doesn't help
<ogra_> yeah
<ogra_> yay ... ok, one issue found with the gpg stuff
<ogra_> (we dont bundle /var/lib/apt/keyrings in the tarball ...)
<dragly> zyga: Then I don't understand how it works to build on Travis (in a Docker container) and my own machines and run on Nvidia machines afterwards, but not Intel.
<ogra_> but even putting the right thing there doesnt fix apt :/
<zyga> dragly: we have some special handling for nvidia
<zyga> dragly: but it's neither generic nor particularly good
<dragly> Oh, that explains. Thanks!
<dragly> Are there any examples that I could look at (Krita?) that solve this manually either in the wrapper or by shipping GL drivers?
<zyga> dragly: no idea really, I can tell you what we do
<dragly> I don't mind doing it manually, I just don't know what to look for :)
<zyga> dragly: but ideally someone should use libglvnd all the way
<zyga> dragly: a snap that is linked so that it doens't link to particular things but to libglvnd
<zyga> dragly: and contains all the drivers (as a hack / demo)
<zyga> dragly: and can find the right one using libglvnd
<zyga> dragly: later on the drivers can be removed from the demo snap and moved elsewhere (TBD)
<zyga> dragly: and if connected via content should still work
<zyga> dragly: (as in, give you the right driver while the snap with the application code has none)
<dragly> so libglvnd is a wrapper for whichever GL lib is installed?
<zyga> dragly: libglvnd is an emerging way to do GL in a sane way on linux
<zyga> dragly: everything else is terrible
<zyga> dragly: (and deployed) ;-)
<zyga> dragly: but there are many parts missing
<zyga> dragly: improvements in snapd for the automatic driver installation, kernel parts, mouting the driver for the snap to see, working with libglvd to do the right thing, etc
<dragly> I see
<zyga> dragly: also build system improvements
<zyga> dragly: so when people build whatever snap they don't have to hand-hold it to do the right thing (not ship drivers but ship glvnd)
<dragly> we really want to use snaps to package our applications, but it sounds like its going to be a lot of work at the moment. Maybe its better to consider alternatives and wait for an "official" solution?
<zyga> dragly: on each distro the compiled userspace parts be shipped in blessed snaps
<zyga> dragly: but the kernel parts are an open problem
<zyga> dragly: you can just ship it the way everyone does (inside snaps) by bundling the zoo of FOSS userspace drivers
<zyga> dragly: and relying on the magic ubuntu+nvidia enablement
<zyga> dragly: we'll improve the situation with time but this is not something we're working on at the time
<zyga> dragly: what I gave you was the bleak reality about how it must be done to work correctly but what people do is very useful despite not having those things
<dragly> do you happen to know where I can find the zoo of userspace drivers to bundle? I suppose most of them are available through apt?
<ogra_> libgl1-mesa-dri and libgl1-mesa-glx should have them
<dragly> ogra_: great, and they go in as stage-packages, right?
<ogra_> installing into /usr/lib/x86_64-linux-gnu/mesa and /usr/lib/x86_64-linux-gnu/dri
<ogra_> (on amd64 that is)
<ogra_> zyga, so i clearly verified it is the execution environment causing the gpg error, not something missing in teh tarball ... when unpacking an ubuntu-base tarball over the chroot env for the classic snap the error persists
<ogra_> i'm now pretty sure it is related to the mknod
<zyga> ogra_: how sure?
<zyga> ogra_: can you replace the apparmor profile for classic
<zyga> ogra_: to allow everything?
<pstolowski> zyga, question to the hooks timeout problem - you metnioned https://github.com/zyga/snapd/tree/feature/debian-9-qemu ; why do i need that - because this is an old snapd?
<ogra_> gimme a moment ... (just uninstalled it to get a clean env again)
<zyga> pstolowski: because at that time you have snapd tree where this problem is trivial to reproduce and when you can use the only place that (non-tests) lets it happen easily (debian where we have seccomp but not apparmor)
<zyga> pstolowski: you can test this with unit tests with greater ease
<zyga> pstolowski: by just putting stuff into state the way 2.21 would do
<zyga> pstolowski: and starting the manager
<pstolowski> zyga, thanks. unit tests are tempting. i'm not sure what 2.21 would do though
<zyga> pstolowski: just not add the timeout field AFAIR
<zyga> pstolowski: it is in HookSetup
<ogra_> zyga, ok, back in business ... how do i allow everything again ?
<zyga> ogra_: edit /var/lib/snapd/apparmor/profiles for classic
<zyga> remove everything there (or set it aside) and place...
<ogra_> zyga, yeah, that bit i knowe :)
<ogra_> (what do i need to put in, how do i regenerate)
<zyga> ogra_: you load with "apparmor_parser -r /path/to/that/file"
<zyga> ogra_: as for the contents
<jdstrand> that path is already allowed
<zyga> ogra_: keep the initial part
<zyga> ogra_: and inside the {  }
<jdstrand> wait
<zyga> jdstrand: oh :)
<jdstrand> that path should already be allowed
<Chipaca> popey: you around?
<zyga> ogra_: jdstrand can give you better advice
 * zyga runs for lunch
<jdstrand> well, probably not, but I may have more information
<ogra_> http://paste.ubuntu.com/24516694/ is the current profile
<jdstrand> perfect
 * jdstrand looks
<ogra_> (but i'm also running in --devmode anyway)
 * jdstrand understands
<jdstrand> @{SNAP_NAME}="classic"
<nothal> jdstrand: No such command!
<jdstrand> /var/snap/@{SNAP_NAME}/common/** wl,
<jdstrand> /var/snap/classic/common/classic/tmp/fileutl.message.wopbff
<jdstrand> right, yes, there is a rule for that
<ogra_> well /var/snap/classic/common/classic/tmp/fileutl.message.wopbff is rather dynamically created
<jdstrand> ogra_: what is the output of 'snap info <the name of the kernel snap>'?
<ogra_> http://paste.ubuntu.com/24516706/
<ogra_> jdstrand, this is for Bug #1670475 BTW
<mup> Bug #1670475: apt-secure complaints with classic snap on arm <Snappy:New> <https://launchpad.net/bugs/1670475>
<jdstrand> interesting that beta and candidate have newer revisions than edge
<ogra_> i verified that nothing is missing in the classic chroot by simply using an ubuntu-base tarball inside that env ... it exposes the same issue
<jdstrand> ogra_: yes, I read backscroll. thank you for looking into this btw
<ogra_> jdstrand, yeah, i need to sync again ... i can swithc the board to beta if that helps ... (i doubt it though)
<ogra_> kernel team only releases to beta and candidate ... edge is for tinkering
<ogra_> (i.e. manual uploads)
<jdstrand> ogra_: what are the permissions of /var/snap/classic/common/, /var/snap/classic/common/classic/ and /var/snap/classic/common/classic/tmp/?
<jdstrand> hmm
<jdstrand> yes, answer that, but, the fact that this says ALLOWED is wrong because the rule is in the policy
<jdstrand> I think this is a complain mode denial bug
<ogra_> http://paste.ubuntu.com/24516718/
<jdstrand> s/is/may be/
<jdstrand> ogra_: can you use -ld
<ogra_> http://paste.ubuntu.com/24516723/
<ogra_> also a "touch /tmp/foo" from inside the running chroot shows up fine as /var/snap/classic/common/classic/tmp/foo
<jdstrand> right ok
<jdstrand> I think this is a complain mode denial bug
<ogra_> so the mknod will be denied while it shouldnt ?
<jdstrand> ogra_: can you boot into the highest revision available? iirc, there were some fixes for this sort of thing
<ogra_> sure
<jdstrand> ogra_: the bug (I suspect) is that even though there is a matching rule in the policy (the one I pasted), there is a bug that the file access isn't matching the rule (which is why we see ALLOWED). there is a second bug (my theory) that even though we are in complain mode, the kernel is still denying it
<jdstrand> ogra_: the fact that non-dragonboard kernels aren't seeing this gives support to a kernel bug
<ogra_> jdstrand, all arm kernels see it now
<jdstrand> but not amd64/i386?
<ogra_> (note i'm on a pi3)
<ogra_> i havent tried x86 ... you claimed in the bug i386 works
<jdstrand> ogra_: well, at the time, but at the time armhf worked too
<jdstrand> so maybe everything is broken
<ogra_> HA!
<ogra_> works !!!
<jdstrand> we are getting into jj territory here, but I'd like to have a simpler reproducer
<ogra_> crazy
<jdstrand> ok, good :)
<jdstrand> well, no, we had complain mode bugs that jj fixed :)
<jdstrand> so, it sounds like the pi3 kernel needs those fixes too
<jdstrand> iirc, pi3 is stuck due to boot image stuff
<ogra_> before: http://paste.ubuntu.com/24516746/ ... after: http://paste.ubuntu.com/24516747/
<ogra_> right
<ogra_> pi's are all stuck
<jdstrand> ok
<jdstrand> so now we have triaged the bug
<jdstrand> let me add a comment
<ogra_> there is another issue (we dont keep the keyring around in the tarball) but i'll fix that one today
<jdstrand> when the pi's are all updated with latest apparmor (I think I tried on bbb), they should be fixed
<jdstrand> ogra_: you went to beta?
<ogra_> yep
<jdstrand> ogra_: oh, that is a pi2-kernel. ok
<mup> PR snapcraft#1223 closed: kernel plugin: check_config() and check_initrd() support <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1223>
<ogra_> well, pi kernel
<ogra_> (it is identical for 2 and 3
<ogra_> )
<jdstrand> ogra_: I thought there was a forum topic on the boot/gadget/kernel issue. can you give it to me or a bug?
<ogra_> one sec
 * jdstrand couldn't find it
<ogra_> https://forum.snapcraft.io/t/updating-bootloader-assets-in-the-gadget-snap/70
<ogra_> just a serach for gadget reveals it
<jdstrand> oh, I did look at that
<jdstrand> but I thought that was different. ok thanks
<zyga> re
<ogra_> jdstrand, it is also supposed to be a hot topic at the current sprint
<mup> PR snapcraft#1294 closed: meson plugin: Add plugin for meson build system <Created by JulianLiu> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1294>
<zyga> ogra_: standup
<ogra_> zyga, yeah
<zyga> morphis: you are welcome to join us if you have no conflicts
<mup> PR snapd#3277 opened: cmd/snap, client: add "whoami" command <Created by chipaca> <https://github.com/snapcore/snapd/pull/3277>
<mup> PR snapcraft#1296 closed: rust snaps can now use source-subdir without failing on pull <Created by roxyd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1296>
<mup> Bug #1670475 changed: apt-secure complaints with classic snap on arm <Snappy:Invalid> <https://launchpad.net/bugs/1670475>
<jdstrand> Chipaca: hey, saw in backscroll you needed me, but not sure from backscroll if you still need me (fyi, I commented on locale-control PR)
<Chipaca> jdstrand: yes!
<Chipaca> jdstrand: about _filedir
<Chipaca> jdstrand: I'm pretty sure I addressed the biggest issue already
<Chipaca> jdstrand: the only place it trips up now is from the outside in
<Chipaca> (so there's some mis-quoting going on but i'll have to dig)
<Chipaca> but for example if something has spaces I correctly get back things that backslash the space
<Chipaca> ie âScreenshot\ from\ â
<Chipaca> jdstrand: could you take a poke and see if you see the same?
<AdamH_> Gents, I have been watching the comments and can see the issue with apt-get requires a newer kernel. Is there a how-to or guide anywhere on how to update to a new one?
<Chipaca> AdamH_: I think as long as you can reflash, yes
<jdstrand> Chipaca: you updated the PR for this?
<Chipaca> AdamH_: ogra_ knows more
<Chipaca> jdstrand: 1 sec
<Chipaca> jdstrand: there was a bug in compopt
<Chipaca> jdstrand: https://github.com/snapcore/snapd/pull/3150/commits/8a60343a82a23d91284f863d8bff226dccdc21bd
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<Chipaca> jdstrand: actually https://github.com/snapcore/snapd/pull/3150/commits/8a60343a82a23d91284f863d8bff226dccdc21bd#diff-96d0d48e1bd095153ade81afdb99f7ebR85
<AdamH_> Chipaca: Yes I can reflash if needed
<jdstrand> Chipaca: ah, cool. ok. gimme a bit and I can take a look later this morning
<Chipaca> jdstrand: ok lurvely
<jdstrand> oh, heh
 * jdstrand just looked at the commit
<Chipaca> yeah
<morphis> zyga: sorry, got back to late from my lunch break
<zyga> morphis: no worries
<popey> Chipaca: sorry, was afk
<popey> Chipaca: if this is about the thread on forum about my sign on being broken, I can't reproduce it, unless IS nukes the password on my store account (that's how you reproduce it)
<popey> e.g. get your password leaked somewhere and IS pro-actively help you :)
<Chipaca> popey: so what's your password?
<Chipaca> popey: is it ********
<spineau> zyga: hi, I'm testing the ability to run other snaps commands from checkbox snap. That's amazing
<zyga> spineau: hey
<zyga> spineau: is it working ok? :)
<spineau> zyga: with core from beta yes, we can call them
<spineau> zyga: but I'm facing a limitation
<zyga> yes?
<spineau> zyga: for example I have a tpm2 command with a -o parameter to save something to a file
<spineau> zyga: it seems that the only allowed location is SNAP_USER_COMMON
<spineau> zyga: I'm not sure if there's a way to share data between snaps
<zyga> spineau: aha, interesting point
<zyga> spineau: if your test snaps have the home interface then you can connect it and just share data this way
<spineau> zyga: but SNAP_USER_COMMON which works is the one for the tpm2 snap (not the one fro mcheckbox of course)
<popey> Chipaca: indeed, hunter2 all the way
<spineau> zyga: ok, I'll try that. thanks for the tip
<zyga> spineau: there are other ways but I'd recommend against them until the (dreaded) update-ns feature is finished
<kyrofa> Oh man, pachulo, you and I are on very different timezones :P . This conversation might be best on a new issue against the snap
<kyrofa> pachulo, something is weird there: why is the php part pulling in python? Please log a bug against the snap, let me see the changes you're trying to make, and we can troubleshoot asynchronously there :)
<kyrofa> pachulo, thanks for taking a crack at that bug!
<AdamH_> ogra: How did you update the kernel on your rPi3 to resolve the apt-get issue?
<zyga> AdamH_: you have to rebuild the image and reinstall
<zyga> AFAIK
<AdamH_> zyga: By rebuilding do you mean grabing the latest daily build and re-imaging?
<zyga> AdamH_: I think so
 * zyga didn't try
<AdamH_> zyga: Thanks, will give it a go
<zyga> AdamH_: we're working on fixing the root issue but it will still take a while to plan/schedule
<AdamH_> zyga: Yes understood
<ogra_> zyga, huh ?
<ogra_> AdamH_, if you use a stable image there is no way ... if you use a daily/edge image: snap refresh pi2-kernel --beta
<ogra_> that will switch you over to the beta kernel
<ogra_> (do not run that on a stable pi image, it wont boot anymore)
<ogra_> (well, it will roll back ... but never boot into the new kernel)
<zyga> ogra_: hm?
<ogra_> zyga, why would he need to rebuild
<zyga> ogra_: I thought because to boot one needs to get a fresh image with edge kernel
<ogra_> zyga, if you are on an edge image you can just switch channels for the kernel via refresh
<ogra_> i do that all the time ... in fact i usually install a daily and then switch kernel to beta and core to stable after first boot ;)
<ogra_> thats the current way to keep a pi up to date
<zyga> ogra_: wait, I must be missing something; if I start on a stable image, can I use edge kernel/core?
<ogra_> zyga, you cant use an edge kernel on stable, no (wont boot and just roll back) ... you can use the edge core on stable ... and you can use edge/beta/candidate or whatever you want to all packages on a daily image
<ogra_> so it always depends what image you started from ... rebuilding anything wont gain you anything though
<ogra_> (stable gadget only goes with stable kernel ... nothing else will boot)
<pachulo> ok kyrofa , I will do that!
<mup> Bug #1621745 changed: snapd package is missing dependency on grub-common for grub-editenv <Snappy:Fix Released> <Ubuntu Image:Fix Released> <https://launchpad.net/bugs/1621745>
<mup> Bug #1534154 changed: BootAssetFiles have new "Dst" key that we should support <Snappy:Invalid> <https://launchpad.net/bugs/1534154>
<zyga> jdstrand: hey
<zyga> jdstrand: I have something, an experiment of afternoon friday hacking
<zyga> jdstrand: I was wondering if snapd could do the resolving on seccomp profiles
<zyga> jdstrand: so snap-confine could be easier and more portable
<zyga> jdstrand: so I came up with a way
<zyga> jdstrand: interested? :-)
<jdstrand> I'm not sure how it would be more portable. if this is something you are going to be pushing for, yes I definitely want to discuss it. however, my friday is completely booked for non-experimental stuff, so perhaps next week?
<jdstrand> zyga: ^
<zyga> jdstrand: perhaps portable is less iteresting; the point is that it would be smaller and would change less often
<zyga> jdstrand: yeah, this is a total RFC and idea
<zyga> jdstrand: I'll catch you next week
<jdstrand> cool, thanks
<jdstrand> Chipaca: fyi, I haven't forgot you. I'll get there
<jdstrand> forgotten*
 * Chipaca steps back from the ledge
<jdstrand> lol :)
<Chipaca> :-)
<Chipaca> jdstrand: I'm in a maze of twisted error messages, all different
<Chipaca> jdstrand: not busy-waiting on you
<jdstrand> ok cool
<jdstrand> well
<Chipaca> (but yeah i could do with landing that branch today, which i will do if you confirm what i found)
<jdstrand> nice that you aren't waiting on me. not so nice about the twisty maze
<Chipaca> jdstrand: that's ok, i get to use a type called "stringish"
<zyga> Chipaca: what are you hacking on?
<Chipaca> zyga: store
<Chipaca> zyga: some responses from sso are not what we expect
<Chipaca> zyga: have you figured out the test breakage
<zyga> Chipaca: no, I should probably have a look at that ...
<Chipaca> zyga: only if you haven't EOW'ed
<zyga> no, not yet, still digging
<cjwatson> elopio: doesn't look too difficult to sort out a git:// proxy in launchpad-buildd, so I'm working on that
<cjwatson> among the nineteen thousand other buildd patches I have queued ...
<zyga> fg
<Chipaca> zyga: fg: current: no such job
<zyga> are you saying I'm slacking ;)
 * zyga runs spread
<zyga> I wonder if it fails locally
<zyga> Chipaca: oddly it built fine locally (in qemu)(
<zyga> Chipaca: I'll try linode next
<elopio> cjwatson: thanks! I think for my case I can install phantomjs from the deb, but last time I tried that it ended in a mess. I'll try again.
<cjwatson> I have a juju tentacled monstrosity on my laptop to make it easier to test this stuff
<Chipaca> zyga: yeah i tried to say 'it works for me' in the standup but google hated me just then
 * zyga goes to pick up kids
<Chipaca> zyga: did you kick off the tests on snapd#3275 again?
<mup> PR snapd#3275: snap: move locale-control to only be present on classic <Created by chipaca> <https://github.com/snapcore/snapd/pull/3275>
<cjwatson> elopio: OK, I think I have this working locally \o/
<cjwatson> just waiting to see exactly how far it gets, since running snap builds behind slow ADSL isn't the quickest of experiences
<elopio> cjwatson: awesome!
<elopio> cjwatson: I'm happy you are done with that one, because, I have another one :( https://build.snapcraft.io/user/elopio/ipfs-snap/35231
<cjwatson> what the heck is gx
<elopio> cjwatson: it's a go package manager on top of ipfs.
<elopio> but I think that when you don't have ipfs, like in this case, it just uses http.
<cjwatson> elopio: anyway, it's 7pm on Friday, I'm unlikely to get to it today; can you file a bug on launchpad-buildd?
<cjwatson> I have a bunch of stuff queued up that may help, but I'd need to check it
<cjwatson> (particularly my local-snap-proxy branch which means we stop having to worry about client-specific support for authenticated proxies)
<elopio> cjwatson: sure. Thanks a lot, and enjoy the weekend.
<elopio> https://bugs.launchpad.net/launchpad-buildd/+bug/1688624
<mup> Bug #1688624: ipfs fails to build: no such host <launchpad-buildd:New> <https://launchpad.net/bugs/1688624>
<zyga> re
<zyga> Chipaca: looking
<zyga> Chipaca: no, I don't think I did
<zyga> Chipaca: did you figure anything out?
<Chipaca> zyga: no, but it came up green
<Chipaca> zyga: in fact both 3275 and 3277 are green in travis
<zyga> Chipaca: wasn't me
<zyga> maybe mvo fixed something?
<Chipaca> zyga: ogra left for the weekend and turned off his break-everything-inator
<Chipaca> zyga: ogra's surname is doofenshmirtz
<zyga> lol :)
 * zyga runs his locally built snapd
<zyga> Chipaca: this is why snapd should not become init ;-)
<Chipaca> popey: https://github.com/snapcore/snapd/pull/3278
<mup> PR snapd#3278: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <https://github.com/snapcore/snapd/pull/3278>
<mup> PR snapd#3278 opened: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <https://github.com/snapcore/snapd/pull/3278>
<zyga> surprisingly nothing explodes!
<jdstrand> Chipaca: commented
<jdstrand> Chipaca: I think you are good to go
<popey> Chipaca: yay
<cratliff_> kyrofa:  Have you had to do anything with adding rules to rosdep while making a snap?  Would any packages pointed to by custom rosdep rules need to be made as a part in the snap?
<zyga> some failures on the nice password policy error branch
<zyga> Chipaca: commented on the PR
<Chipaca> zyga: my bad, will fix
<zyga> Chipaca: hard to guess
 * zyga runs another spread run and EOWs
<Chipaca> zyga: guessing is super easy!
<Chipaca> i do it all the time
<mup> PR snapd#3150 closed: In-snap bash tab completion <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<Chipaca> ladies ^
 * zyga claps
<zyga> That's some fine work there mate!
<Chipaca> that was a cow of a thing, glad it's on the other side :-)
<Chipaca> now i need to write something up to explain it a bit
<Chipaca> also, chase down bugs i'm sure. But first i've got branches to polish.
 * mcphail wakes up. Wow. Cheers Chipaca 
<Chipaca> zyga: jdstrand: thank you :-)
<zyga> Chipaca: I ended this week with a small experiment, https://github.com/zyga/snapd/tree/feature/typed-syscalls
<zyga> Chipaca: works OK though not the full potential, the output is still rather ugly, I'll make it sort by interface so that it is nicer to look at
<Chipaca> huh
<zyga> ?
<zyga> anyway
<zyga> beer time
<zyga> and tomorrow
<zyga> farm!
<Chipaca> zyga: multiple iotas
<Chipaca> i'd always seen it written as a single thing
<Chipaca> like, const ( Foo = FooClass(iota); Bar; Baz; Quux )
<zyga> Chipaca: yeah, I think I wanted that without the many iotas but it didn't do the thing I expected
 * zyga tries
<zyga> ah, I'm drunk, it works ok
<Chipaca> as long as the type is on the expression, it works
<zyga> Chipaca: yep, pushed
<Chipaca> if instead you do const ( Foo FooClass = iota; Bar; Baz )
<Chipaca> then i think just Foo is FooClass, the others are just ints
<zyga> Chipaca: this branch might arguably fix the dreaded hrsearch_r failed :)
<zyga> hsearch_r *
<Chipaca> :-)
<zyga> as it does the hard work so that snap-confine can be ... dumb
<Chipaca> zyga: you need to sit down with jdstrand tho
<zyga> yes, I think he may dislike it
<Chipaca> zyga: then sit down with him before falling in love with this too much :-D
<zyga> but I wanted to do it anyway, to show that with some parsing the seccomp profiles can be better (nicer, sorted, de-duplicated, described, etc)
<zyga> Chipaca: well, it's a friday thing :)
<zyga> on the slower week
<Chipaca> yeah
<Chipaca> maybe i should've worked on the progress bar / terminfo thing
<Chipaca> :-)
<zyga> ohh
<zyga> terminal stuff is my other love
<zyga> that's for weekend tho
<Chipaca> proper colour support is _terrible_
<zyga> why?
<zyga> are you kidding me?
<Chipaca> no, no i'm not
<zyga> one sec
 * Chipaca is having a beer as well
<zyga> Chipaca: super ancient stuff I never landed https://github.com/zyga/guacamole/pull/15
<mup> PR zyga/guacamole#15: Add terminal awareness ingredient <Created by zyga> <https://github.com/zyga/guacamole/pull/15>
<zyga> Just scroll :D
<zyga> https://github.com/zyga/guacamole/blob/master/examples/rainbow.py is also fun to look at
<jdstrand> I'm about to head out but I can say a couple of things, drop the mic, then leave. the hsearch_r things should be fixed now with reexec so long as you build snap-confine and snapd and copy both over. I'm not 100% sure this is going to work the way you want by dropping the snapd binary anywhere. but more importantly, it makes policy development difficult cause the policy writer has to figure out the number to put in the policy
<jdstrand> most importantly, snap-confine can't be that dumb and will have to parse at least some things
<jdstrand> eg, the current real and effective user (for the user/groups branch I'm working on)
<zyga> jdstrand: no, it's still optional; the way I made it it could even fail at build time (loudly) but now just gets forwarded to snap-confine as-is
<zyga> jdstrand: sure, I know and I agree
<zyga> jdstrand: I think I wanted to do this to make the generated profiles nicer
<jdstrand> well, if you are trying to make snap-confine dumb, then it won't be optional
<zyga> jdstrand: dumber, not fully dumb
<zyga> jdstrand: it will not need a lot of those maps
<zyga> jdstrand: but anyway, this is a secondary goal, I really wanted to make profiles more readable
<zyga> jdstrand: right now they are a bit... well, mashed up
<jdstrand> I don't like the sort either
<zyga> jdstrand: (and FYI, I'm not fully happy with the output now, but it is better than before)
<jdstrand> we want comments inline with the rules that are there
<jdstrand> plus, the map stuff doesn't really look any prettier to me than then C
<zyga> jdstrand: those stay
<zyga> http://paste.ubuntu.com/24519406/
<zyga> jdstrand: (this is still with relatively naive output, it can look nicer still)
<jdstrand> I don't see how that output is any better... I see a bunch of comments explaining what you mapped to
<zyga> jdstrand: mainly by keeping the flow of snippets, adding headers "# this is what interface FOO added:" etc
<jdstrand> that is fine
<zyga> jdstrand: the previou output was worse as it was totally (crappily) sorted on huge multi-line strings
<jdstrand> but that is supposed to be at the top of the snippets for each interface anyway
<jdstrand> anyway, I gotta go
<zyga> jdstrand: oh, and one more thing, I didn't do it in this branch but the # description stuff really should not live in snippets
<zyga> jdstrand: o/ enjoy the weekend, see you next week :)
<jdstrand> you too! :)
<Chipaca> wrt colour support being terrible, there is no good way of detecting whether a terminal supports 16M colours
<Chipaca> terminfo have said they won't support it at all
<Chipaca> and of the terminals that support it, they only support it from a certain version on (if compiled with the right flags), and only VTE exposes something you might use to guess (the VTE version)
<Chipaca> so, you say, no problem, ignore 16M colours and use the paletted 256 colour support
<Chipaca> which is much more prevalent, and detectable (terminfo knows)
<Chipaca> but, but, it's a palette, and in some but not all terminals it's a _modifiable_ palette. And some of the terminals that let you modify it let you query it (in a horrible horrible way that involves termios things to read it back), but not all
<Chipaca> so there's absolutely no sane way of saying "make this text be of colour #c0ffee"
<Chipaca> you can say "make this be colour #2"
<Chipaca> which will be something blue, or green, depending, but only if the user hasn't changed it to something else
<zyga> Chipaca: yeah; hence I did the insane, locally see which terminal emulator is used ;D
<zyga> Chipaca: but actually most things support the 16M colors fine
<zyga> Chipaca: and the rest, well, screw that stuff
<Chipaca> zyga: the problem is that some of the stuff that _doesn't_ is actually important
<Chipaca> like, screen ant tmux
<zyga> Chipaca: it's also compound by the fact that multiplexers and even ssh can make stuff crazy
<zyga> Chipaca: ha, I know :)
<Chipaca> heh, see :-)
<zyga> Chipaca: I have a secret plan for that tho :)
<zyga> Chipaca: long standing desire to fix that properly
<Chipaca> so, I'm probably going to write something called schmerminfo
<zyga> what would that do?
<Chipaca> (it's half written in my head already)
<Chipaca> zyga: be a very opinionated thing that does the same sort of thing as terminfo does, but just for the stuff i care about
<Chipaca> alternatively i could make it fall back to terminfo (i mean, i already wrote _that_ one in go :) )
<Chipaca> and just sprinkle colour magic on top
<Chipaca> OTOH, i don't need all terminfo
<Chipaca> so ...
<zyga> Chipaca: how would the API look like?
<Chipaca> it's there at the back of my head percolating
<Chipaca> zyga: I've tried something like the terminfo api, and it's pretty nasty
<Chipaca> zyga: so I'll be looking at doing something fmt-ish next, see how that one feels
<zyga> Chipaca: yeah, I think that's the right intuition
<zyga> Chipaca: I tried it myself too earlier and anything heavier or more typed was too annoying to use
<Chipaca> anyway, that's backburner stuff for me
<zyga> Chipaca: btw, the guacamole thing I linked to has one fun element: colorblind mode
<Chipaca> and it's got so many branches, it never ends
<zyga> Chipaca: lets you run your app with color emulation to see how specific kind of colorblindness might be perceived
<Chipaca> zyga: ah, i'll look at that sometime then, as that was on my mind also
<Chipaca> zyga: one of the branches of this problem space (i.e., "make progress bars pretty and functional") was progress bar for transformative io
<zyga> Chipaca: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py
<Chipaca> ie a progress bar for decompressing something
<Chipaca> where it tells you what it's read, and what it's decompressed
<Chipaca> (or compressed)
<zyga> Chipaca: I recommend you to look at RHEL 7 bootup
<zyga> Chipaca: the progress bar is totally pretty
<Chipaca> zyga: the textmode one?
<Chipaca> haven't seen that
<zyga> Chipaca: or any opensuse/fedora thing that boots in text mode
<zyga> Chipaca: more crazy and fun stuff: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L404
 * zyga loves verbose python
<zyga> https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L500
<zyga> some more craziness: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L635
<Chipaca> zyga: guacamole seems to ignore the whole "paletted terms change their colours" thing :-)
<zyga> https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L769
<zyga> :D
<zyga> Chipaca: ah, no
<zyga> Chipaca: well
<zyga> Chipaca: there are sets that change
<zyga> Chipaca: and there are sets that don't change
<AdamH_> Gents, I have a mir-kiosk app that builds and runs fine on Ubuntu core running in KVM but I get the following error when built using classic snap on rPi3 - mirserver: Rejected and disconnected a client (Unsupported protocol version) Any idea where the mirserver logs are? Trying to debug
<zyga> Chipaca: if the programmer asked for a specific color then I use those that don't change
<zyga> Chipaca: if you asked for symbolic indexed 8 element palette then those change
<zyga> Chipaca: but...
<zyga> Chipaca: bare with me :-D
<zyga> Chipaca: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L302
<zyga> Chipaca: I also try to know what they were by default
<zyga> Chipaca: I also looked at how I can ask the terminal for the real values at runtime
<Chipaca> AdamH_: looks like your mir server and client have different libmirclients
<zyga> (guacamole was more of an experiment to explore colors than practical tool)
<zyga> Chipaca: this is fun because you can use gnome-terminal with guacamole to ask how your application would render on putty (color accurate) or apple's terminal emulator
<AdamH_> Chipaca: Thanks, is there a quick way to tell?
<zyga> Chipaca: using the right color mixer you can get that output
<zyga> Chipaca: guacamole has one big flaw though, it is a python library, not something universal
<zyga> Chipaca: slowly, I'm building a universal solution
<Chipaca> zyga: nice
<Chipaca> AdamH_: I'm not sure; check the soname?
<zyga> Chipaca: where it is more like modern graphical stack than terminal stuff, but we'll see :)
<AdamH_> Chipaca: Not sure what soname is, but you have given me something to read up on thanks
<zyga> Chipaca: anyway, I'll think I'll stop typing now, enjoy your weekend :)
<Chipaca> zyga: way ahead of you :-)
<mup> PR snapd#3275 closed: snap: move locale-control to only be present on classic <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3275>
#snappy 2017-05-06
<snapresearch> HI, I have a quick question - how to integrate openvpn (client) into a snap?
<shadeslayer> hey!
<flux242> Hi, What does this mean?$ sudo snap refresherror: cannot refresh []: Post https://search.apps.ubuntu.com/api/v1/snaps/metadata: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
<Chipaca> the package index is timing out; I've contacted IS.
<mup> PR core#37 opened: install keyring (LP: #1670475), update pkglists <Created by ogra1> <https://github.com/snapcore/core/pull/37>
<mup> PR core-build#10 opened: make /etc/environment writable <Created by ogra1> <https://github.com/snapcore/core-build/pull/10>
<Chipaca> ogra_: will that work with atomic writes?
<ogra_> Chipaca, no
<Chipaca> ogra_: what needs doing so it does?
<ogra_> like any ontgher single file we make writable like this
<ogra_> unionfs ... aufs, overlayfs ?
<Chipaca> ogra_: so this bind-mounts instead of being a symlink?
<ogra_> yes
<Chipaca> ogra_: how do you say "make it a symlink"?
<Chipaca> NicolinoCuralli: you're making me wish i disabled join/part notifications
<ogra_> you create a file in /etc/writable and link to it ...
<ogra_> problem is ...
<Chipaca> ogra_: any reason not to do that?
<ogra_>  /etc/environment is hardcoded in half the world ... so that wont work here
<Chipaca> why?
<Chipaca> they won't follow a symlink?
<ogra_> because i highly dbout anything reading it follows symlinks
<ogra_> we could try ... but i really doubt it
<Chipaca> people have to do extra work to not follow symlinks
<ogra_> why is atomic so important for you ? we wont allow more than a proxy setting ... writing to a tmp file and mv is close to atomic
<ogra_> it isnt like we could make the system unbootable or something if that fails
<ogra_> (and i will surely fight adding other random stuff to that file that might make it break the boot)
<Chipaca> ogra_: because if we don't, the file will get corrupted (most likely being zero'd out)
<ogra_> how ?
<ogra_> we dont open it
<ogra_> you cp it to /tmp ... change the file in tmp and then you mv ...
<Chipaca> ogra_: /tmp is a different filesystem, so mv is a cp, is an open and write
<ogra_> (you could add an additional check between editing and mv if that makes you feel safer)
<ogra_> well, then /var/tmp or whatnot ... you knwo waht i mean :)
<Chipaca> _as far as i know_ (but we can test if you want) they're all different filesystems as far as rename is concerned
<Chipaca> i mean, try it with python, easy enough to do
<ogra_> well, i dont really want to add all the problems we have with /etc/writable to that file
<ogra_> then i'll rather keep it readonly and have whatever adds the proxy add it differently
<Chipaca> ogra_: every time we come to this area I'm closer to thinking we need to reverse the logic
<Chipaca> ogra_: and make /etc writable except for <these things>
<ogra_> Chipaca, we need to change it ... weather it is by reversing the logic, i dont know .... it was on the "to discuss" list for the sprint ... lets see what came out of it
<Chipaca> ok
<ogra_> /etc/writable is an ugly wart
<Chipaca> lower your voice! don't want it to hear and throw a hissy fit
<ogra_> lol
<jfcastroluis> is snap store down?
<jfcastroluis> I can't install snaps
<jfcastroluis> Client.Timeout exceeded while awaiting headers
<jfcastroluis> network is working ok
<jfcastroluis> maybe the server?
<jfcastroluis> anybody with problems also?
<Chipaca> jfcastroluis: yes, the store is down, people are working on it
<jfcastroluis> Chipaca: ok, thank you! :)
<jfcastroluis> where is hosted snap store? aws?
<Chipaca> jfcastroluis: I think it's in one of canonical's DCs
<jfcastroluis> how you know is down? is there a status page? for next times (hope not many :)
<Chipaca> jfcastroluis: I know the URL to the store?
<Chipaca> and it times out
<jfcastroluis> ok, ok! :)
<sciencefyll> hellu
<sciencefyll> i hear du guys liked feedback
<sciencefyll> so i just wanted to say that on my fresh manjaro xfce install, it hangs right after you install it
<sciencefyll> i've run both systemctl start/enable snapd.socket and systemctl start/enable snapd.refresh.timer
<sciencefyll> running "sudo snap install discord" makes it hang at "[-] Run configure hook of "core" snap if present"
<sciencefyll> force stopping it, and running it a second time gives the issue:
<sciencefyll> "INFO snap "core" has bad plugs or slots: core-support-plug (unknown interface)"
<sciencefyll> is this chat dead? xD
<ogra_> sciencefyll, you are better off to post to the forum onn weekends (see the channel topic)
<mup> PR snapcraft#1300 opened: tools: add a script to install autopkgtest dependencies <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1300>
<ali1234> hi. i made a sigrok snap ages ago but it never worked outside dev mode because it needs raw usb access. should i just make it use classic mode and put it in the store?
<ali1234> and does anyone want to help me clean it up and do that?
<ali1234> its here: https://github.com/ali1234/mysnaps/tree/master/sigrok
<ali1234> upstream showed interest in it too
<ali1234> oh there's a raw-usb interface now
<ali1234> i built my snap to use the raw-usb interface and connected it but i still get "sr: backend: libusb_init() returned LIBUSB_ERROR_OTHER."
<ali1234> type=1400 audit(1494097705.817:107): apparmor="DENIED" operation="create" profile="snap.sigrok.sigrok-cli" pid=8274 comm="sigrok-cli" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create"
<mup> PR snapcraft#1301 opened: recording: record global build-packages installed on the host <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1301>
<ali1234> it still works in devmode
<fgfgffgfhfghsgh> ok
<fgfgffgfhfghsgh> now, please tell me
<ali1234> qt5 apps aren't themed correctly, not even in the store
<ali1234> also "snapcraft cleanbuild" still fails: HTTPSConnectionPool(host='parts.snapcraft.io', port=443): Max retries exceeded with url: /v1/parts.yaml (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fe2d6334898>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
#snappy 2017-05-07
<surveyor3> Hello! I installed hugo via snap. How can I start it? If i use the command "hugo" to start it doesn't work. Is it something like "snap run hugo"?
<mup> Bug #1689037 opened: apt-add-repository in classic snap on core always adds artful repos <Snappy:Triaged by ogra> <https://launchpad.net/bugs/1689037>
<Chipaca> niemeyer: https://www.reddit.com/r/golang/comments/69qmc8/why_gopkgin_hasnt_caught_on/
#snappy 2018-04-30
<Caelum> zyga: let me know how it goes with the factory submission
<Son_Goku> zyga, your SR got declined again: https://build.opensuse.org/request/show/601690
<Son_Goku> also, your SRs *will* be declined if you don't provide useful information in the changes entry about the new releases
<Son_Goku> at the minimum, changes entries need to be fixed to mention what versions they bumped to, and highlights of each release
<Son_Goku> zyga: for example: https://build.opensuse.org/package/view_file/openSUSE:Factory/dnf/dnf.changes?expand=1
<zyga> Good morning
<jamesh> hi zyga
<zyga> Iâm taking the dog for a walk, will be back soon
<pstolowski> morning
<zyga> re
<mup> PR snapd#5114 closed: release: 2.32.6 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5114>
<zyga> jamesh, pstolowski: good morning
<jamesh> zyga: so as far as user-mounts is concerned, there were two unresolved issues from niemeyer's review: each of which I'm addressing in subsequent PRs.  Would it be okay to merge the first PR?
<jamesh> the issues are (1) the Secure.BindMount only being used on directories, and (2) snap-update-ns using the value of $XDG_RUNTIME_DIR from the environment
<jamesh> the PR for (1) is ready, and I'm just finishing up (2) today
<zyga> jamesh: do you have the code ready?
<zyga> if so yes, let's merge it and then propose the other two
<jamesh> zyga: https://github.com/snapcore/snapd/pull/3963 is ready, and the CI tests passed when you restarted them on Friday
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<jamesh> zyga: https://github.com/snapcore/snapd/pull/5082 is ready for review, but the diff will probably make more sense after the first is merged
<mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
<jamesh> I'll have the third proposed soon.
<zyga> ok, let me merge the first branch then
<zyga> thank you for pushing it this far :)
<zyga> it is in
<jamesh> yay
<mup> PR snapd#3963 closed: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3963>
<zyga> jamesh: please merge master into your other PRs
<jamesh> will do
<snapuser52533> Hi
<snapuser52533> I have a question about snap and apparmor
<zyga> hey snapuser52533
<zyga> I can gladly answer that
<snapuser52533> Hi Zyga
<snapuser52533> I've installed pac-sv via snap
<snapuser52533> this is a ssh connection manager
<snapuser52533> now apparmor denies access to my ssh key
<snapuser52533> apparmor="DENIED" operation="open" profile="snap.pac-vs.pac-vs" name="/home/xxx/.ssh/id_rsa.pub" pid=11492 comm="ssh" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<snapuser52533> I added this in the profile:
<snapuser52533> owner @{HOME}/.ssh/ r,
<snapuser52533> and reloaded the profile
<snapuser52533> but it still gives me denied
<zyga> because you gave it access to read the contents of the directory
<zyga> nothing more
<zyga> but anyway, you don't need any of that
<zyga> you want to use the ssh-keys or ssh-public-keys interface
<zyga> snap interface ssh-keys
<zyga> :-)
<zyga> just add a plug to your snap and connect
<zyga> note that it will not auto-connect for obvious reasons
<snapuser52533> oh didn't know the plugin
<snapuser52533> i'm very new to snap
<snapuser52533> so, I undo my changes, reload the profile and install the plugin
<snapuser52533> just a sec
<snapuser52533> I still got the denied
<Chipaca> moin moin
<Chipaca> zyga: I've got an interesting day today -- might not be *here* here for much of the morning
<Chipaca> zyga: (just a heads up)
<zyga> Chipaca: ack
<zyga> I hope it is the good kind of interesting
<Chipaca> zyga: 50/50 :-)
<Chipaca> zyga: care to review #5111?
<mup> PR #5111: cmd/snap: update install/refresh help vs --revision <Created by pedronis> <https://github.com/snapcore/snapd/pull/5111>
<zyga> sure
<zyga> FYI 2.32.6 is in beta
<zyga> we will try to fast-track it to stable
<mup> PR snapd#5111 closed: cmd/snap: update install/refresh help vs --revision <Simple> <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5111>
<mup> PR snapd#5103 closed: tests: shellcheck spread tasks <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5103>
<Chipaca> hmm
 * Chipaca hmms in the PR where it'll lead to something
<jamesh> zyga: https://github.com/snapcore/snapd/pull/5082 shows a reasonable diff now.  I'm still testing the second branch, which enables document portal support in the desktop interface
<mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
<Chipaca> ok, afk
<mup> PR snapd#5113 closed: cmdstate: add missing test for default timeout handling <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5113>
<zyga> uh, need to power off for a moment
<zyga> re
<zyga> that was longer than expected
<zyga> my desk wiring was faulty
<zyga> I tweaked it to be more robust and also cleaned all the surfaces (that was dusty!)
<zyga> and re-wired everything
<zyga> back to work :)
<mup> PR snapd#5098 closed: Makefile: add initial makefile with live-check command <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5098>
<zyga> jamesh: reviewed
<Chipaca> zyga: looking at #5090
<mup> PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090>
<zyga> Thank you!
<Chipaca> zyga: in ensureSource, if the osLstat err is nil, and the kind is not one of the ones listed, what happens?
<jamesh> zyga: awesome.  Just getting ready to submit the second PR
<jamesh> it takes a while to locally test spread tests
<zyga> Chipaca: nothing smart I suspect let me look
<Chipaca> jamesh: updating and tweaking (pre-installing) the deps for the test suite on the images helps with that
<zyga> jamesh: do you have access to the google backend?
<zyga> it is far faster (network speed)
<jamesh> zyga: I've just been using the local kvm backend
<zyga> Chipaca: so if you think about symlink, it is specifically left out
<jamesh> I don't think I've got access to the google backend
<zyga> jamesh: ask gustavo for a key, it is x10 faster than running locally on slow network
<zyga> about https://github.com/snapcore/snapd/pull/5096 -- mvo is sprinting this week, let's pick it up, fix things and push
<mup> PR #5096: snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/5096>
<Chipaca> zyga: i'll do that
<jamesh> zyga, Chipaca: it'd be really useful to have a "spread best practices" document on the forum or somewhere.  I'm still working off some tips zyga gave me on IRC months ago, and I'm not sure how a new contributor would get started
<zyga> awesome, thanks Chipaca
<zyga> jamesh: I can do that, can you remind me what I told you?
<Chipaca> zyga: "blame gustavo"
<Chipaca> :-D
<jamesh> zyga: looking at my notes, it was to copy one of your VM images to ~/.spread/qemu, then run "SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/$test_name"
<zyga> jamesh: ack, thanks
<greyback> anyone understand how snapcraft knows where to go to locate the remote "desktop-gtk2" part?
<zyga> there's a wiki page
<zyga> but maybe it moved
<zyga> I mean
<zyga> snapcraft literally used wiki to locate remote parts
<greyback> yeah, I'm guessing there's a server somewhere
<mup> PR snapd#5115 opened: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5115>
<greyback> I'll grep hte source for a url
<greyback> zyga: ta
<greyback> https://wiki.ubuntu.com/snapcraft/parts for the record
<jamesh> zyga: here's the document-portal PR: https://github.com/snapcore/snapd/pull/5115
<mup> PR #5115: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5115>
<Chipaca> zyga: I'll merge #5096 once it's green
<mup> PR #5096: snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/5096>
<zyga> jamesh: partial review on 5115
<jamesh> zyga: I can separate out the fonts stuff.  I just started working on the AddUpdateNS stuff for desktop interface and it seemed like an obvious change that was touching the same code paths
<zyga> jamesh: yeah, +1 on that but please push that in a separate PR, it can land very quickly IMO
<jamesh> zyga: here's the second PR: https://github.com/snapcore/snapd/pull/5116 -- it is the first few commits on the other PR
<mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
<zyga> ack
<mup> PR snapd#5116 opened: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
<zyga> jamesh: 5116 reviewed
<greyback> anyone have thoughts on https://bugs.launchpad.net/snapd/+bug/1767372 ? I'd give it a go if someone suggested an approach
<mup> Bug #1767372: /dev/dri/card0 only available to root <snapd:New> <https://launchpad.net/bugs/1767372>
<zyga> greyback: looking
<zyga> uh, sadly this is a bigger nut to crack
<zyga> let me pull the docs
<zyga> hey mvo
<zyga> good morning
<greyback> zyga: ok, it's not urgent
<mvo> hey zyga
<greyback> zyga: part of that users/groups plan I guess?
<zyga> https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
<zyga> yes
<zyga> there's a reference to ACLs there
<greyback> ack
<jdstrand> popey: hey, where are the sources for Signal-Desktop? looking at https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/14
<popey> https://github.com/signalapp/Signal-Desktop
<jdstrand> popey: thanks
<zyga> jdstrand: hey, how is the sprint
<jdstrand> zyga: hey, so far fine :)
<jdstrand> popey: oh, heh, that was in the build script
<zyga> Afk for post office
<zyga> I can join the call from my phone
<Chipaca> zyga: are we doing a standup? i think it's just you, me, and pstolowski
<pstolowski> yeah.. let's skip
<Intruder777> hi guys. ho do I run some service (which was installed via snap) as non-root user?
<zyga> Lets have the call
<zyga> Even of brief
<zyga> Intruder777: can you vice us an example please
<mup> PR core#87 opened: snapcraft.yaml: update stage-packages during build <Created by mvo5> <https://github.com/snapcore/core/pull/87>
<Intruder777> zyga: let's say I have installed rocketchat-server via snap
<Intruder777> so now the rocketchat-server processes are running from root user
<Intruder777> how do I make them run from some custom low privilege user?
<zyga> This is not supported
<zyga> Note that it runs confined in a sandbox where the root is strongly limited
<zyga> Does anyone know if Sergio is working today?
<jdstrand> zyga: sergiusens? if so, I can see him across the room
<zyga> No, the other one
<zyga> Chipaca, pstolowski lets talk for 3 min please
<Chipaca> ztinw
<jdstrand> popey: do you know anything about npm run build-release? it seems to be cleaning up prime and I'd like to manipulate what it does
<pstolowski> ok
<popey> jdstrand: not really
<popey> jdstrand: magic black box to me
<jdstrand> I see that it pulls down appimage and has mksquashfs binaries down in ./.cache/electron-builder/appimage/appimage-9.1.0/linux-x64/
<popey> ah, i patch out the building of appimage
<popey> appimages are built by default in electron-builder
<popey> unless you override it
<jdstrand> I wonder if it is using those binaries for the snap build under the hood
 * jdstrand just finds it curious and wants to investigate
<zyga> re
<zyga> taxes filed
<zyga> man, so so so hot today
<zyga> 30C in the shade
<zyga> who needs Spain when Central Europe is melting away
<pstolowski> :)
<zyga> jdstrand: can you please look at https://github.com/snapcore/snapd/pull/5107 during a coffee break
<mup> PR #5107: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5107>
<zyga> it's a trivial PR adding mode,uid,gid options to tmpfs
<Chipaca> zyga: I've had to turn the heating on again
<zyga> WAT
<zyga> is it this cold in UK?
<popey> yes, buggering freezing
<zyga> man that's weird, we could call this July easily now
<Chipaca> I can't confirm that, but I can confirm it's quite cold
<Chipaca> so I do envy your 30C :-)
<Chipaca> that's what I call 'nice'
 * Chipaca really enjoyed the 2 days of summer this year
<mup> PR snapcraft#2111 opened: repo: rollback to using dpkg-deb for deb extraction <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2111>
 * zyga goes to make ice coffee
<mup> PR snapd#5117 opened: interfaces/apparmor: enable apparmor, even if partial <Created by zyga> <https://github.com/snapcore/snapd/pull/5117>
<mup> PR snapd#5118 opened: packaging/opensuse: build with apparmor support <Created by zyga> <https://github.com/snapcore/snapd/pull/5118>
<mup> PR snapd#5119 opened: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <https://github.com/snapcore/snapd/pull/5119>
<jdstrand> popey: ah: execute command           args=[/home/ubuntu/.cache/electron-builder/appimage/appimage-9.1.0/linux-x64/mksquashfs /home/ubuntu/tmp.0mPdLJ0eNz/latest/release/__snap-x64 /home/ubuntu/tmp.0mPdLJ0eNz/latest/release/signal-desktop_1.9.0-beta.1_amd64.snap -no-progress -quiet -all-root -no-duplicates -no-recovery] path=/home/ubuntu/.cache/electron-builder/appimage/appimage-9.1.0/linux-x64/mksquashfs
<popey> wow
<jdstrand> then later
<jdstrand> Appending to existing 4.0 filesystem on /home/ubuntu/tmp.0mPdLJ0eNz/latest/release/signal-desktop_1.9.0-beta.1_amd64.snap, block size 131072
<jdstrand> All -b, -noI, -noD, -noF, -noX, no-duplicates, no-fragments, -always-use-fragments,
<jdstrand> -exportable and -comp options ignored
<zyga> hmm
<zyga> what is appimage doing there?
<jdstrand> so it appears they are calling mksquashfs in an incompatible way, then appending to it in a roughly compatible way
<jdstrand> zyga: it isn't. electron-builder is reusing some appimage code to build the snap
<jdstrand> "If appending is not wanted, please re-run with -noappend specified!"
<zyga> heh, weird but ok :)
<jdstrand> let's try that for giggles
 * zyga goes to snap vim properly
<ogra_> strict ?!?
<popey> why? core ships with vi
<popey> should make a snap of emacs or nano if anything :)
<ogra_> i like cursor keys and syntax highlighting ;)
<popey> i like anything other than vi
<popey> but on my core system i have to keep running "sudo classic" to get any kind of decent editor
<ogra_> echo "set nocompatible" >>~/.vimrc
<ogra_> (and you have normal vim mode)
<Chipaca> ogra_: you seem to think "anything other than vi" means vim is ok
<ogra_> totally !
<ogra_> who needs more than vim !
<Chipaca> o/
<kyrofa> zyga, I'm in lxc, any idea what this is? error: cannot perform the following tasks:
<kyrofa> - Run configure hook of "nextcloud" snap if present (run hook "configure": cannot remount /tmp/snap.rootfs_vLM0cV/var/lib/snapd/lib/vulkan as read-only: Permission denied)
<kyrofa> (trying to install a new snap)
<zyga> this looks like an older snapd
<zyga> whats the version?
<kyrofa> $ snap --version
<kyrofa> snap    2.32.5
<kyrofa> snapd   2.32.5
<kyrofa> series  16
<kyrofa> ubuntu  16.04
<kyrofa> kernel  4.4.0-121-generic
<kyrofa> Xenial, both apt and snap are up to date (tracking stable)
<zyga> hmmm
<zyga> can you show me the denial you have
<zyga> I will investigate
<kyrofa> zyga, no denial, it seems, just this: Apr 30 14:32:29 nextcloud-snap-test snapd[369]: 2018/04/30 14:32:29.792734 handlers.go:372: Reported install problem for "nextcloud" as 5066946e-4c83-11e8-b6b2-fa163e8d4bab OOPSID
<zyga> nothing in dmesg?
<kyrofa> A bunch of appamor STATUSs
<zyga> hmm, let's see
<zyga> kyrofa: can you look at the apparmor profile of snap-confine
<zyga> and look for
<zyga> mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
<kyrofa> zyga, hmm.... where is it?
<zyga> in /etc/apparmor.d
<kyrofa>  /var/lib/snapd/apparmor/snap-confine/ is empty
<zyga> look at each one you find
<kyrofa> Ah
<mup> PR snapd#5120 opened: interfaces:interface-hooks for refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/5120>
<kyrofa> zyga, I see this: # Vulkan support
<kyrofa>     /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/{,*} w,
<kyrofa>     mount fstype=tmpfs options=(rw nodev noexec) none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
<kyrofa>     mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
<kyrofa> Darn, shoulda pastebinned that
<zyga> that's fine
<zyga> that corresponds to the error you saw
<zyga> but it's allowed there
<zyga> so ... no idea
<zyga> but also the only MS_REMOUNT in the tree
<zyga> so maybe bugs are present
<sveinse> With Ubuntu 18.04 I'm given a choice if I should install docker via apt or via snap. What is the arguments for getting docker via snap?
<zyga> sveinse: the snap is updated by docker inc at their own pace
<zyga> sveinse: the deb comes from the ubuntu archive and will not be updated apart from security updates
<sveinse> zyga: Snap adds another container layer on top of everything, doesn't it? So it has some overhead, right?
<zyga> What kind of overhead?
<sveinse> zyga: Does't it run in a jail?
<ogra_> it does ... but not "in a container"
<zyga> Snaps really just run the software as is, with a different mount namespace to let the thing use libraries independent from the host
<ogra_> it is confined through apparmor, seccomp, napespaces ...
<ogra_> *name
<zyga> Is that a container? Yes but not much more overhead imo
<ogra_> not sure, i always thinka container is closer to a full VM here than what snapd does :)
<sveinse> not quite sure about that, docker is somewhat inbetween all that. It certainly is not a full VM, but it can abstract some of the fs bits
<sveinse> So in my simplistic view I don't really see the difference from docker containers and snaps, but that snaps are built to be accessible from outside
<zyga> There are many differences
<zyga> But those require one to understand what both tools are doing
<zyga> A lot of the kernel tech is shared
<zyga> But also they do different things without correspondence to each other
<sveinse> I have a small server that I'm trying to decide on how to run the services: Either Ubuntu bare-metal (or whatever you want to call a "normal" server these days) or by using docker. And if docker, should it run from apt, given the standard location of the containers or from snap, where it is being updated more frequently. For snap one needs to handle the snap-specific locations of docker.
<zyga> Try the snap and report back on usability please
<zyga> For containers you can also use lxd
<zyga> It all depends on what you want to run inside
<sveinse> zyga: since I'm considering running the server bare-metal (keyword small server), I suppose the only added reason for doing containment is the added protection in case of internet breach. Doing a full VM is not an option.
<sveinse> For the record I have no experience with lxd
<zyga> None of those things use full virtualization
<sveinse> right
<zyga> Lxd runs machine containers
<zyga> Unlike docker which typically runs process or a single app with few cooperating processes
<sveinse> which is impacts the system less?
<zyga> It is not about impact imo
<zyga> And it all depends son what you mean
<zyga> Those are all different tools building on the same set of kernel features
<om26er> Hi! Is there a way to check the download size of a snap refresh ?
<om26er> One of my snap was updated automatically and I want to know the download size and if the delta update actually worked.
<om26er> s/updated/refreshed
<zyga> om26er: not as an end-user AFAIK
<sveinse> Yeah, I think I see the difference when reading on linuxcontainers.org/lxd/ and I think I'm aiming at docker type. One machine, multiple services. More abstraction than that, i.e. machine is not necessary
<sveinse> Thanks, zyga. I have something I'd like to test
<om26er> zyga: when the delta is downloaded, is that deleted after being applied ? (maybe I could check the delta size locally if possible)
<zyga> om26er: AFAIK yes
<zyga> om26er: it is deleted
<zyga> it is only kept to reconstruct the image
 * om26er will wait for blr to come online to inquire the delta size as its worrying android-studio snap may be re-downloading the whole thing with each update.
<mup> PR snapd#5121 opened: interfaces:minor autoconnect cleanuo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5121>
<Chipaca> om26er: if you've got SNAPD_DEBUG enabled you can read all about deltas in the lgos
<Chipaca> logs*
<Chipaca> om26er: also SNAPD_DEBUG_HTTP=3 would help (or even =7 if you're into reading json)
<om26er> Chipaca: its not enabled currently, will adding SNAPD_DEBUG=7 to /etc/environments suffice ?
<Chipaca> SNAPD_DEBUG=1 (or =true)
<Chipaca> SNAPD_DEBUG_HTTP=3 (or 7)
<om26er> then I can probably check on next update if the delta worked.
<Chipaca> om26er: is it your snap?
<Chipaca> om26er: if so, if you're logged in, you can 'snap install yoursnap --revision=theoldrevno' and then sanp refresh
<om26er> Chipaca: kind of: its owned by snapcrafters team but I am collaborator.
<Chipaca> om26er: that is: if you can push to it, you can do the above
 * om26er tries
<Chipaca> zyga: any idea what's up with the "no output received" things?
<popey> om26er: ping if you need something from me, obviously :)
<om26er> popey: thanks, no need, seems I was already able to test what Chipaca suggested.
<om26er> and the good news is: delta updates are indeed working :)
<om26er> Chipaca: where exactly can I see those logs ?
<Chipaca> om26er: journalctl  -u snapd
<om26er> ah, snapd.service: Ignoring invalid environment assignment 'export SNAPD_DEBUG=1': /etc/environment
<om26er> https://paste.ubuntu.com/p/vYJTQ8gX4w/
<mup> PR snapcraft#2112 opened: repo: fix all python shebangs in stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2112>
<om26er> so the delta was downloaded, saved more than 600+ megabytes. VICTORY.
<om26er> Thank you guys.
<popey> nice!
<Chipaca> maybe snapd should brag about that a bit
<Chipaca> I'm sure people would complain about it polluting the logs etc etc
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> No idea
<Chipaca> maybe we should have a BRAG log level :-D
<zyga> Maybe heat wave and slow VMs?
<Chipaca> zyga: dude, poland is the only place with a heat wave
<Chipaca> zyga: have you checked your nuclear reactors lately?
<zyga> We donât have any
<zyga> Coincidence? I donât think so ;-)
 * Chipaca shudders remembering chernobyl residents going to the roof of their buildings to enjoy the nice warm air
<zyga> Iâm going for a beer with kissiel
<Chipaca> zyga: dang
<zyga> To celebrate bionic
<Chipaca> i'm on meds, can't have beer
<zyga> But first I have to get there on a bike
<zyga> I got bike crazy
<zyga> I plan to take non alcoholic
<zyga> To ride back
<Chipaca> ah, i was about to tell you off
<zyga> Sorry to hear that though
<zyga> Are you ok?
<zyga> Iâm walking to the bike station
<Chipaca> zyga: yep! big teeth thing
<zyga> Ah
<zyga> It will heal
<Chipaca> yep
<Chipaca> just two more days
<ogra_> zyga, do yu happen to know if michael will be back on wed. ?
<ogra_> (or did he take off the whole week)
<mup> PR snapd#5096 closed: snap: improve error for snaps not available in the given context <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5096>
<zyga> ogra_: i think he will be back next week, he is sprinting
<ogra_> ah, crap crap crap ... k
<Saviq> hey guys, any idea about snapcraft just spinning at 100% CPU after "Preparing to build desktop-qt5", seemingly permanently?
<popey> it does take a while, yeah
<popey> but it does move on usually
<seb128> Saviq, popey, same issue than vlc is hitting, Sergio looked at it today, it's due to the switch from dpkg-deb to use the python binding they did, he said he's going to revert that change
<popey> ah okay
<popey> That's new to me, thanks.
<seb128> the reason that motivated the change isn't true anymore
<seb128> yw
<seb128> Saviq, popey, bug #1767119
<mup> Bug #1767119: snapcraft prime takes considerably more time on unpacking stage packages than before <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1767119>
<seb128> he put up a PR today
<Intruder777|1> guys, so running snap apps services as root is no security issue, right?
<Chipaca> Intruder777|1: strictly-confined snap apps, correct
<Chipaca> (we will support users anyway, at some point, but it should be fine for now)
<Intruder777|1> Chipaca: thanks
<Chipaca> ogra_: what did you nead a michael for?
<Chipaca> Intruder777|1: np, hth
<ogra_> Chipaca, approval tp potentially see dmsetup (needed for full-disk-encryption)
<ogra_> *to potentially seed
<popey> add gnu screen while you're there ;)
<Chipaca> ogra_: telegram; he's sprinting, not vacationing :-)
<Chipaca> and +1 to scren
 * Chipaca goes off to write an app call 'scren' just to not be wrong
<Chipaca> called
<Chipaca> gawd
<ogra_> i'm still researching why systemd misbehaves so badly all of a sudden (we have FDE working since a while and suddenly systemd creats random mount usins for the backing device)
 * Chipaca just take more pills and go to sleep
<ogra_> <- cant type anymore
<ogra_> popey, definitely not for this customer :P (there every byte counts ... super cut down device)
<Chipaca> popey: that's ogra_-speak for "if you can find something to remove that's the same size or bigger, sure"
 * Chipaca is helpful
 * popey runs ncdu /snap/core/current
<ogra_> popey, though you will be pleased to hear that i managed to implement the encrypted rootfs generic enough that we can also later have interactive passwd prompts or SD card keys (needs extra implementation indeed, but adding different key handlers should eb easy in my implementation)
<popey> so, tell me why we have perl in core :)
<ogra_> popey, some dependency of some low level package
<Chipaca> popey: now ask him about usr/share/X11/xkb
<popey> hah
<ogra_> Chipaca, michael added that for something yu demanded IIRC
 * Chipaca whistles innocently
<ogra_> support for non US keyboards in console-conf ?? yeah, i think that was it
<ogra_> that puls in a ton of stuff
<Chipaca> ogra_: is initrd supposed to be in core btw?
 * Chipaca forgets how that dance is
<ogra_> Chipaca, with split initrd it is loaded directly from the core snap ...
<ogra_> without it we theoretically wouldnt need it
<popey> do people need pppd in 2018?
<ogra_> (but we use split-initrd now in some customer setups)
<ogra_> popey, for GSM
<Chipaca> popey: yes :-) whether it should be in core is another question
<Chipaca> but, given it's setuid, probably
<ogra_> yeah
<ogra_> iirc that was the reason
<popey> python2.7 debconf.py
<popey> (I like this game)
<Chipaca> perl is probably there for debconf
<Chipaca> debconf is probably there for consoleconf or somesuch
<ogra_> perl is there for a ton of stuff thats used during build
<Chipaca> (pero is also not that big iirc?)
<Chipaca> perl*
<ogra_> the question is if any of this is also used at runtime (and it is really hard to tell without a detailed audit of every script and tool)
<Chipaca> 2.9M    ./usr/lib/x86_64-linux-gnu/perl-base
<Chipaca> hm
<ogra_> yeah, it is quite big
<Chipaca> hopefully for core18 we can do it the other way around
<Chipaca> :-)
<Chipaca> and build it up instead of down
<ogra_> anyway, back to my dmsetup problem
 * Chipaca can dream
<ogra_> well
<ogra_> the question is if you use debs ...
<ogra_> as long as you do you will always have a bunch of unwanted deps pulled in
<ogra_> ad with our policy to use binaries from the archive it is hard to work around using debs
<popey> organize:
<popey>  - -usr/bin/foo
<ogra_> the prob is always: "how much can you cut down without harming the functionality of a package"
<Chipaca> umm
<popey> Indeed, that's the fun bit!
<ogra_> you theoretically need to knwo each package in and out to judge that you can remove some dep
<Chipaca> popey: is it just the screen binary you need, or does it have more deps?
<popey> just the binary and a 777 directory /var/run/screen
<Chipaca> popey: because we're shipping ./usr/lib/python2.7/dist-packages/debconf.py â¦ and no python 2
<ogra_> huh ?
<popey> screen is 425K uncompressed though
<ogra_> we surel ship python2
<Chipaca> ogra_: python 3, yes
<Chipaca> 2? what for?
<popey> (see 5 mins ago where I mentioned this) :D
<ogra_> Chipaca, in 16.04 ?
<ogra_> i thought we still had 2 there
<Chipaca> ogra_: in core
<Chipaca> 16.04, yes
<Chipaca> core, nope \o/
<Chipaca> at least that is what my friend 'find' says
<ogra_> ogra@acheron:~$ apt-cache show python-minimal|grep ^Depends
<ogra_> Depends: python2.7-minimal (>= 2.7.12-1~), dpkg (>= 1.13.20)
<ogra_> Depends: python2.7-minimal (>= 2.7.11-1~), dpkg (>= 1.13.20)
<ogra_> we install python-minimal
<ogra_> (in core)
<ogra_> (and nly to make subiquity happy ... i wish we could just rip it out)
<Chipaca> ogra_: https://pastebin.ubuntu.com/p/HwVrYcdbMT/
<ogra_> oh, interesting
<Chipaca> ogra_: something's ripping it out :)
<ogra_> might be that we switched to python3-minimal and i forgot
<popey> how much close to getting screen does that get us? :)
<ogra_> removing python ?
<popey> 6kb!
<ogra_> just add 10 screens :)
<ogra_> removing python would clean up 5-10MB
<popey> how, it's not actually there
<Chipaca> ogra_: what uses dh-python in core?
<mup> PR snapcraft#2111 closed: repo: rollback to using dpkg-deb for deb extraction <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2111>
<ogra_> Chnothing
<ogra_> ^^ Cip
<ogra_> bah
 * Chipaca hugs ogra_ 
<ogra_> yeah, systemd is giving me a really bad day
<ogra_> trying to be clever ...
<Chipaca> ogra_: i'll let you get back to that
<Chipaca> need to go anyway
<ogra_> i'm totally not eager to :)
<mup> PR snapcraft#2113 opened: sources: don't clean target for FileBase sources <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2113>
<mup> PR snapcraft#2112 closed: repo: fix all python shebangs in stage-packages <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2112>
<mup> PR snapcraft#2113 closed: sources: don't clean target for FileBase sources <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2113>
#snappy 2018-05-01
<pbek> since yesterday my snappy builds (e.g. https://code.launchpad.net/~pbek/+snap/hswitch/+build/205732) get an error message "Store upload failed: Authorization failed.". Is this something I can fix myself?
<pbek> I guess I post this in #launchpad
<jamesh> pbek: have you changed your Ubuntu One password since setting up that recipe?
<jamesh> you might be able to get LP to ask for new auth details by updating the recipe to stop uploading to the store, then enable it again
<jamesh> if that doesn't help, perhaps ask on #launchpad
<pbek> jdstrand: thank you, no, I did no password change
<popey> pbek: I had some fail yesterday too
<jamesh> Is there something wrong with the google:debian-9-64 spread backend machines? I've been getting a number of CI failures on my PRs that seem to be unrelated to my changes.  It's either a timeout cleaning up the debian VM, or a sometimes a failure in interfaces-network test
<Chipaca> jamesh: I'm seeing lots of TLS failures, or timeouts waiting for shutdown
<Chipaca> jamesh: also the interfaces-network one yes
<Chipaca> jamesh: so, to answer your question, yes :-)
<Chipaca> jamesh: I'm hoping whatever it is unglues on its own, because the rest of the team is out
<Chipaca> and I'm working on a 20%
<Chipaca> or hoping to :-)
<zyga> jamesh: I think there's a real race or rare bug on debian
<zyga> jamesh: I restarted your branches a few times
<Chipaca> zyga: is that about the interfaces-network test?
<Chipaca> zyga: also what are you doing here, you're supposed to be off :-)
<Chipaca> ooooh
<Chipaca> nice one
<Chipaca> niemeyer: a spread run just ended in spread throwing an index-out-of-range panic. https://pastebin.ubuntu.com/p/6y65bmWYgR/ (full log at https://api.travis-ci.org/v3/job/373097606/log.txt )
<Chipaca> i'll leave that one up for now
<Chipaca> (that's running tests from #5121 fwiw)
<mup> PR #5121: interfaces:minor autoconnect cleanup <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5121>
<Chipaca> zyga: I'm getting 'permission denied' with a snap that uses layouts. Is {/: $SNAP/base} a supported layout?
<Chipaca> zyga: [316407.549782] audit: type=1400 audit(1525172894.246:2070): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.netscape-navigator" name="/" pid=26597 comm="3" srcname="/snap/netscape-navigator/x1/base/" flags="rw, rbind"
<Chipaca> fwiw
<zyga> Chipaca: re
<zyga> Chipaca: layouts on / are unsupported
<Chipaca> zyga: mimics on / also?
<zyga> Chipaca: correct
<zyga> Chipaca: we cannot support that yet
<zyga> Chipaca: we might with mimicfs or something
<Chipaca> zyga: i tried {/bin: $SNAP/bin} with the base not having /bin and it failed also
<zyga> but it would have to be one that is mounted at /
<zyga> Chipaca: that's expected
<zyga> we cannot make / writable
<Chipaca> zyga: I was trying to use layouts as a stepping stone to a base
<zyga> (technically)
<zyga> Chipaca: nah, use a proper base
<Chipaca> zyga: that's a lot more commitment :-) also i _liked_ the idea of using layouts as a steppinig stone to bases
<zyga> Chipaca: what do you need to create?
<Chipaca> zyga: could a readonly / layout work?
<zyga> no
<zyga> we cannot do the mimic on /
<Chipaca> zyga: i mean i know it doesn't
<zyga> so no matter if it writable or not
<zyga> maybe use a chroot?
<zyga> a snap with a chroot inside would be easier
<Chipaca> zyga: nm, i'll get it working
 * zyga gets back to cleaning the house
 * Chipaca remembers lunch, all of a sudden
<Chipaca> "$thing doesn't work as expected" "hm, that looks like $other_thing isn't running automatically, can you start it by hand?" "that's a very generic answer that doesn't apply here"
<Chipaca> wellp, glad you know what's going on, person
<zyga> Chipaca: Hmm?
<Chipaca> zyga: nm
<Chipaca> zyga: just me grumbling
<zyga> All Good?
<Chipaca> zyga: yep
<zyga> Iâm stuck at a family event
<zyga> Waiting till we can run and bike away
<pbek> popey: my QOwnNotes build today works, but hswitch is still failing. I'll try re-authenticate be disabling and enabling automatic store uploading
<dougie> What's the status of HiDPI on Snap packages? I've tried a few snaps (Such as notepadqq) and there have been problems on my display.
<seb128> what sort of problems? are you sure those issues are due to the fact that they are distributed as snaps and not by the upstream code not handling hidpi?
<dougie> For Electron apps, I'm noticing that it scales perfectly, but the cursor is super tiny. With Notepadqq, which uses Qt5, the cursor looks fine but the UI is 1/2 the proper scale.
<dougie> It appears the tiny cursor issue is also apparent in Chromium.
<dougie> The notepadqq issue might go away if I find a way to pass the variable QT_AUTO_SCREEN_SCALE_FACTOR to the snap app.
<Chipaca> dougie: if you do 'snap run --shell the-snap', is it set in there?
<dougie> Just did that and typed "env". Odd, looks like that variable is already there.
<dougie> And it's set to the proper value - 1
<Chipaca> dougie: the next step would be to look at how the app is being launched; maybe it's via desktop-launcher and it's somehow fumbling the environment
<Chipaca> dougie: or maybe the qt libraries in the snap don't understand hidpi
 * Chipaca knows nothing
<dougie> Maybe you're right about that. Pretty sure that this thread indicates that: https://github.com/giowck/symphytum/issues/48
<Chipaca> dougie: interesting link, i wonder if popey is aware (and if popey is the right person that needs to be aware)
<popey> I will take a look,thanks!
<popey> om26er: number of android studio installs has doubled in the last week
<klaasvakie> hi, I am using Ubuntu 16.04 and have the lxd snap installed. When running the "lxc" command, a "snap" directory appears under my home dir. Is it possible to move this somewhere less visible, like somewhere in .config?
<kyrofa> klaasvakie, I'm afraid not, that's where snapd places all snaps' user data
<kyrofa> klaasvakie, please see bug #1575053
<mup> Bug #1575053: Please move the "$HOME/snap" directory to a less obtrusive location <julyshakedown> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575053>
<klaasvakie> kyrofa, thanks, wow didn't realise I was stepping into such a high profile bug. ... tiptoes away ...
<kyrofa> klaasvakie, hahaha
<mup> PR snapcraft#2114 opened: meta: stop creating empty snap directory in prime <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2114>
<mup> PR snapcraft#2095 closed: lxd: proper error classes for container errors <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2095>
<mup> PR snapcraft#2115 opened: storeapi: ensure snap ID is sane before using it <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2115>
<mup> PR snapd#5122 opened: snap: add support for `snap advise-snap --from-apt` <Created by mvo5> <https://github.com/snapcore/snapd/pull/5122>
<mup> PR snapcraft#2116 opened: storeapi: handle 5xx error codes for all store endpoints <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2116>
<mup> PR snapcraft#2117 opened: pluginhandler: correctly dedent the run script <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2117>
#snappy 2018-05-02
<sergiusens> diddledan: ^^
<skunkos> hello guys, I need some help with fiddling with my yaml file - https://github.com/martinrotter/textosaurus/blob/master/snapcraft.yaml
<skunkos> It is text editor application - based on Qt, it seems that my test builds fail with rather cryptic error - https://build.snapcraft.io/user/martinrotter/textosaurus/206767
<Saviq> hi all, I made a mess and revoked a name registration for "subsurface", can someone please bring it back?
<mup> Issue snapcraft#2118 opened: How to install packages from custom repositories on build.snapcraft? <Created by martinrotter> <https://github.com/snapcore/snapcraft/issue/2118>
<Gargoyle> Morning all.
<popey> Morning
<Gargoyle> Is there a way to manually register gnome-calculator as a search provider?
 * Chipaca -> physio
<Saviq> zyga: hey, bump on https://github.com/snapcore/snapd/pull/4545 :)
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<Chipaca> Saviq: I'm (officially) the only snapd core dev working and not sprinting today
<Chipaca> and I'm trying to go to physio for an ah
<Gargoyle> And is my comment in this thread (https://forum.snapcraft.io/t/gnome-shell-search-providers/4322) accurate?
<Saviq> Chipaca: right, May 3rd, this week is so lazy ;)
<Saviq> Chipaca: no worries, go get your physio
<Chipaca> Saviq: i think it's mostly PTO
<Chipaca> k
<zyga> Saviq: Iâm off today. If someone can make it green ping me for merge
<Saviq> greyback: â does the travis failure make any sense to you?
<Chipaca> Saviq: I'll frob it unless something looks relevant to your pr
<Chipaca> and now yes i'm off
<greyback> Saviq: none. Nothing looks related to my changes
<Saviq> jdstrand: could you hit CI again on https://github.com/snapcore/snapd/pull/4545 please?
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<diddledan> audit: type=1400 audit(1525260867.024:62113): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="/usr/lib/snapd/snap-confine" name="snap.snapcraft-pr.snapcraft-pr" pid=26249 comm="snap-confine"
<diddledan> that's a new one on me
<Chipaca> diddledan: stop breaking stuff dude
<Chipaca> :-)
<Chipaca> Saviq: restarted again (grrrrrr)
<Saviq> tx
<mup> PR snapcraft#2117 closed: pluginhandler: correctly dedent the run script <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2117>
<Chipaca> oh ffs
<Chipaca> Saviq: and again
<Chipaca> Saviq: if it's any consolation, they're different each time
<Saviq> sounds like not our fault then ;)
<Chipaca> Saviq: well, maybe :-)
<Chipaca> Saviq: every test run is in a randomised order, so your test _could_ be failing the test right after it
<Chipaca> Saviq: but you'd have to be really creative :-)
<cachio_> Chipaca, are we going to do the standup today?
<Chipaca> cachio_: oh, that's right, you were working from today :-)
<Chipaca> cachio_: I don't think it's worth having it just for the two of us, but if you want we can
<cachio_> Chipaca, no, it is ok in that case
<Chipaca> ok
<cachio_> I'll continue validating 2.32.6
<Chipaca> cachio_: ah, neat
<zyga> diddledan: fixed in beta
<zyga> cachio_: hey
<zyga> Mvo released .6 as you know
<zyga> It is a tiny change on top of .5
<cachio_> zyga, yes, I am validating this one
<cachio_> zyga, I think today we are going to candidate
<zyga> Thank you! That is good news
<cachio_> zyga, so far so good
<Chipaca> zyga: you suck at not working
<zyga> Chipaca: the benefits of having irc on oneâs phone
<Chipaca> zyga: you mistyped "curse"
<ogra_> that was most likely his autocorrection
<Chipaca> Saviq: so, the last run, while also failed, is essentially green
<Chipaca> oh wait, no
<Chipaca> darn it
<Chipaca> 'error preparing' yadda yadda
<Chipaca> :-(
<Saviq> ...
<Chipaca> man i'm so glad i'm not writing this in c
<Chipaca> a function that takes a function that takes a pointer and a function that takes a pointer and returns bool, and returns a function
<Chipaca> even in english it's hard to say it right (and i think i didn't)
<Chipaca> but in go it's just func thing(f func(*state.State, []string, func(*state.Task) bool)) func()
<Chipaca> and of course that code was wrong, because that's how my day's going
<zyga> Hahah
<Saviq> aaand one more
<Chipaca> oooh
<Saviq> just timed out now?
<Chipaca> Saviq: do you have a link to it?
<Chipaca> niemeyer: we're getting a lot of spread runs where apparently travis times out waiting for gce to go away
<Chipaca> niemeyer: were you aware?
<cachio_> Chipaca, trying to reproduce it here
<cachio_> it is happening with arch and fedora 27
<Chipaca> Saviq: I mean, I lost the PR :-)
<Chipaca> Saviq: (had to restart X to switch video cards)
<Chipaca> #4545
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<Chipaca> niemeyer: e.g., https://pastebin.ubuntu.com/p/JxgM7vcnfT/
<Chipaca> Saviq: and yes, that was a perfect run until the timeout
<cachio_> Chipaca, it is weird because it is not happening just sometimes
<Chipaca> cachio_: :-(
<cachio_> so far 100% PASS here
<niemeyer> Chipaca: Uh.. wasn't aware no
<niemeyer> Need to look into it
<Chipaca> niemeyer: k
<niemeyer> Chipaca: also need to look into that backtrace
<Chipaca> niemeyer: I know you have nothing else to do, so I find you stuff
<niemeyer> :)
<cachio_> Chipaca, snapd-control interface seems is being autoconnected when we install test-snapd-control-consumer
<cachio_> Chipaca, but in its declaration says that autoconnection is not allowed
<Chipaca> augh
<cachio_> Chipaca, is it a bug?
<Chipaca> cachio_: you can request (and get) autoconnection that overrides the default
<Chipaca> cachio_: http for example has snapd-control
<Chipaca> autoconnected
<cachio_> Chipaca, ahh, ok, I see that
<cachio_> thanks
<Saviq> is there a way to enable devmode on an installed snap?
<Saviq> or is refresh the only way?
<popey> Saviq: be aware that refresh is disabled for devmode snaps
<popey> (I know that's not what you asked, but you need to know)
<Saviq> right
<Chipaca> Saviq: GREEN
<cachio_> niemeyer, I am chasing this issue too
<cachio_> niemeyer, I'll send you any information I find
<niemeyer> Thanks!
<cachio_> niemeyer, today I killed about 30 instances that were created yesterday
<cachio_> niemeyer, all of them fedora 17 and arch linux
<cachio_> I just could reproduced the issue here once and with no -vv, so I didn't get so much info
<mup> PR snapd#5088 closed: tests: checking interfaces declaring the specific interface <Simple> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5088>
<mup> PR snapd#4545 closed: interfaces/x11: allow X11 slot implementations <Created by gerboland> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4545>
<ddstreet> hi guys, does anyone know if i have a systemd service that relies on a command provided by a snap, should i make the systemd service depend on snapd.service, or is there some other way to delay a systemd service from starting/running until after snap(s) are setup at boot?
<skomorokh> how do I purge old configs if I'm happy with how things are working? I have very limited space on my ssd and it's tedious to do so manually
<skomorokh> (the kind of things that I prefer to have snap manage have ludicriously massive directories because electron etc. is a plot by the nand/dram industry, must be :) )
<Chipaca> ddstreet: you know you can put a systemd service in a snap, yes?
<Chipaca> skomorokh: user data, or the old snaps?
<skomorokh> both!
<skomorokh> but especially user data
<rerst> Hello! I'm unable to run the majority of snaps as normal user. Is it normal that snaps must run with root privileges to work properly?
<mwhudson> rerst: no that is not normal
#snappy 2018-05-03
<mup> PR snapcraft#2119 opened: repo: automatically prune unneeded stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2119>
<mup> PR snapd#5123 opened: tests: skip test lp-1721518 for arch, snapd is failing to start after reboot <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5123>
<Chipaca> moin moin
<doko> why does snapcraft depend on binutils?
<Chipaca> doko: readelf
<Chipaca> doko: although that seems to be in tests, so maybe something else
<Chipaca> doko: why?
<jamesh> it was using readelf in the past (I ripped that code out to use pyelftools instead)
<jamesh> maybe the deb packaging is out of date?
<Chipaca> jamesh: when you ripped it out, did you also update stuff under debian/? :-)
<Chipaca> jamesh: (tbh there might be something else that needs it, dunno)
<jamesh> Chipaca: I didn't: https://github.com/snapcore/snapcraft/pull/1913/files -- I guess I wasn't sure whether it was in use elsewhere or not
<mup> PR snapcraft#1913: elf: pyelftools to parse ELF files rather than readelf <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1913>
<Chipaca> jamesh: you know how people sometimes annotate C includes with what they were included for, to track when to remove it?
<Chipaca> jamesh: i wish there was a similar practice for this
<Chipaca> although the answer might be 'move it to source-deps and see if anything breaks'
<jamesh> at the time, it sounded like the snapped version of snapcraft was the main focus
<Chipaca> mvo: o/!
<Chipaca> mvo: how's things?
<mvo> hey Chipaca - things are going well
<Chipaca> mvo: cool
<mvo> Chipaca: how are you?
<Chipaca> mvo: not envious
<mvo> Chipaca: hahahaha
 * mvo hugs Chipaca 
 * Chipaca hugs mvo back
<Chipaca> mvo: 'snap install mosaic' might bring a bit of levity to your day
<mvo> Chipaca: woah
<mvo> Chipaca: WOAH
<mvo> Chipaca: this even works without layouts and a custom base? nice
<Chipaca> mvo: yeah, this is a rebuild, nothing fancy
<Chipaca> mvo: still working on the other thing
 * mvo nods
<Chipaca> (not today though)
<Chipaca> mvo: also I somehow tricked popey into picking that one up :-D
 * popey shakes fists at Chipaca 
 * Chipaca likes this "break stuff and then make it somebody else's problem" MO
<Chipaca> popey: have you tested it on arm?
<popey> no, i dont have an arm machine which is connected to a display
<popey> actually, I could ssh -X
<popey> (or can I?)
<jamesh> expense a Chromebook?
<popey> hahahahahahaah
<jamesh> (if you need to touch arm often enough, that is)
<Chipaca> popey: IIRC you'd need x11-utils (or was it xauth)? for -X to work (use -v to see the error)
<popey> https://paste.ubuntu.com/p/n7nKkGwr42/
<Chipaca> popey: ssh -v and look at errors before you get shell
<Chipaca> there'll be something like 'nah nah no xauth'
<popey> maybe later :)
<Chipaca> k
 * Chipaca tries to get back to work that isn't emails
<Chipaca> cachio_: let me know when you're around
<doko> Chipaca: because binutils now triggers snapcraft autopkg tests, and these fail
<doko> Chipaca: when it's just a test dependency, then please remove it as a dependency
<Chipaca> doko: it'd be a build dependency, right?
<doko> Chipaca: yes. and you could even annotate it as <!nocheck>
<Chipaca> doko: I don't know what that means, but I'll forward the information to sergiusens or ev when they're around
<Chipaca> (I can imagine what it means, yes)
<nickman> Hey! I have tried to find some information about this, but haven't had any luck. Hopefully you can help me. Is there any way to set up Ubuntu Core on a RPi2 without a monitor and keyboard (headless)?
<Chipaca> nickman: yes, if you have serial
<nickman> Chipaca: okay, there is no way to just boot up directly with the SSO credentials and internet settings in place?
<Chipaca> nickman: AFAIK not without a custom gadget snap, but maybe ogra_ knows more
<Chipaca> auto-import only does assertions, which those aren't
<Chipaca> (auto-import is the feature where it'll load assertions from removable media)
<ogra_> well, it defaults to serial console ... so it depends how headless your definition oif headless is ;)
<Chipaca> ogra_: but there's no way to get sso creds and netplan on there, right?
<ogra_> but yes, you can use a user assertion via usb device to set up a user account ...
<nickman> ogra_: Headless as in, insert sd card, bootup, done.
<ogra_> Chthe user assertion provides the SSO  creds ... i think at least
<ogra_> Chipaca, ^^^
<Chipaca> nickman: out of curiosity, what do you need this for?
<Chipaca> and yes, i just checked and user assertions have ssh keys so you can do that
<Chipaca> (don't know how to do it myself, though -- maybe pedronis)
<Chipaca> still no answer for netplan though
<nickman> Chipaca: I have a bunch of RPis that will be running Ubuntu Core, they all are going to use the same SSO credentials. Connecting every RPi to a screen and keyboard is a bit tedious.
<nickman> SSHing to every one of them and finishing the set up in that way would also be nice and could easily be automed with the use of Terraform.
<Chipaca> nickman: sounds reasonable. You want to go to the forum with it? it sounds like a longer/deeper conversation than can be addressed here
<ogra_> yu could create your own gadget with an extzra vfat partition where you include the user assertion ... but that kind of defeats all security
<Chipaca> ogra_: security is overrated
 * Chipaca hides from jamesh
<Chipaca> er
<Chipaca> i meant from jdstrand
<ogra_> haha
 * Chipaca hides from all the jameses
<Chipaca> ogra_: also, https://www.heise.de/ct/artikel/Super-GAU-fuer-Intel-Weitere-Spectre-Luecken-im-Anflug-4039134.html
<ogra_> pfft intel ...
<ogra_> onbolete architecture
<ogra_> *obsolete too
 * Chipaca covers his processor's ears
<nickman> Chipaca: I suppose  I could post something on the forum. Can't seem to find any Ubuntu Core specific sub forum though?
<ogra_> nickman, the "device" topic
<Chipaca> nickman: 'device'
<Chipaca> heh
<nickman> I suppose Ask Ubuntu would suffice?
<ogra_> forum.snapcraft.io
<ogra_> (see channel topic btw :) )
<nickman> Hah, my bad. Sorry!
<mup> Issue snapcraft#2093 closed: manifest.yaml does not indicate the release the snap was built on <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapcraft/issue/2093>
<popey> cjwatson: do you know when we will get the ability to tell build.snapcraft.io to *only* trigger builds for specific architectures? (e.g. a snapcraft.yaml that ingests an amd64 deb only, won't build on armhf)?
<cjwatson> popey: Can't say, because I'm waiting for the snapcraft team to provide the necessary support as discussed in New York
<popey> Ok, thanks. kyrofa ^ When will snapcraft ( :) ) grow the abililty to say "only build this for $ARCH"?
<mup> PR snapcraft#2120 opened: many: dedup environment entries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2120>
<ogra_> Chipaca, uhm ... are we aware that a "snap switch core --$targetchannel" does not actually switch core at all on ubuntu-core devices ?
<Chipaca> ogra_: whaddya mean?
<ogra_> (it does not touch the bootloader, so the old core is booted, but in state.json the channel info is updated)
<Chipaca> ah
<Chipaca> oh
<Chipaca> oooh
<popey> just a little bit
<Chipaca> ogra_: can you file a bug?
<Chipaca> ogra_: I don't want to risk forgetting, and have too much state right now
<Chipaca> ogra_: and by 'state' i mean 'lunch'
 * Chipaca -> lunch
<ogra_> Chipaca, https://bugs.launchpad.net/snapd/+bug/1768822
<mup> Bug #1768822: snap switch core on ubuntu-core does not update the bootloader, but state.json <snapd:New> <https://launchpad.net/bugs/1768822>
<cjwatson> kyrofa: re popey's question, I believe the promise was also that snapcraft's parser would be split out in a way that we could consume from py2 code
<popey> ogra_: I always thought "switch" was supposed to be followed by a "refresh" - that was the design
<popey> when you "switch" it's instant, it doesn't actually do the download/install of the snap
<popey> ..until the next refresh
<ogra_> hmm, i thought it is only instant if the snap is installed and otherwise installs it
<popey> I *think* it's working as designed.
<ogra_> i'll try it on the next test run
<popey> no mention of switch in https://docs.snapcraft.io/core/usage
<ogra_> looks like someone didnt update the docs :)
<Chipaca> ogra_: popey:  having had a bit of lunch,
<Chipaca> ogra_: popey: snap switch <args> a-snap && snap refresh === snap refresh <args> a-snap
<Chipaca> that is, switch just changes what the snap is tracking
<Chipaca> even the --help output could use some love
<Chipaca> patches welcome :-D
<Chipaca> popey: ^ hint hint nudge nudge
 * Son_Goku waves
<Chipaca> Son_Goku: o/
<Son_Goku> zyga, so where's Zygoonix? :D
<Son_Goku> cjwatson, why do you need snapcraft's parser to be py2 compatible?
<cjwatson> Son_Goku: Because I need to use it in Launchpad
<Son_Goku> eh?
<cjwatson> It needs to know which architectures to dispatch to
<Son_Goku> you can't just read the yaml and figure that out?
<cjwatson> The parsing rules for architectures are non-trivial
<cjwatson> We *might* be able to duplicate it, but I'd rather avoid that if possible
<cjwatson> Sergio seemed OK with the idea of splitting out the parser.  If that's changed, we can of course revisit duplicating code
<cjwatson> It's not a completely hard requirement, but I don't want to drop it on the floor just because people forgot about it either
<Son_Goku> another way to do it would be to write a small Python 3 program that would output JSON that you'd capture from LP
<Son_Goku> as a stop-gap until LP itself can run that aspect in Python 3 natively
<cjwatson> Possible, but the build manager is a tight loop and we'd rather avoid the fork/exec overhead
<cjwatson> We already have problems with the one other place that we do fork/exec there
<Son_Goku> the build manager is difficult to port to Python 3?
<Son_Goku> independent of the rest of LP?
<cjwatson> Yes
<cjwatson> It doesn't have particularly py3-difficult bits itself, but it's not very separable
<zyga> Afk on a bike
<cjwatson> sergiusens: ah, good timing.  Is it still your plan to split out the snapcraft parser in a form that we could consume from LP (py2), or should we expect to need to duplicate the architectures parsing/interpretation code in the LP build manager?
<Son_Goku> brrr py2 :P
<cjwatson> believe me I'd rather we were on py3
<cjwatson> and I'm aware we only have a couple of years
<Chipaca> cjwatson: how split out does it need to be for you to be able to use it?
<cjwatson> Chipaca: in the previous discussion, my memory is that sergiusens said "separate PyPI package"
<cjwatson> of course this is worth rechecking from time to time
<Son_Goku> cjwatson, is there a py3 port of LP stuff in progress, out of curiosity?
<cjwatson> Son_Goku: it's been ongoing for some time, but it's a huge job
<cjwatson> Son_Goku: >700K lines of code and >200 dependencies
<Son_Goku> ooh
<Son_Goku> that's... a lot of code
<Son_Goku> that's a similar scale to what's going on in Fedora
<Son_Goku> though now we're _nearly_ done
<Son_Goku> we just have two major applications left to port
<Son_Goku> the Koji Build System and the Pagure VCS
<cjwatson> and I can't just down tools and work on nothing else for three months
<Son_Goku> cjwatson, well, you could :P
<Son_Goku> you'd just have to go on a sabbatical :P
<Son_Goku> dunno if your bossman would let you do that, though :)
<cjwatson> I kind of like the whole getting paid thing
<sergiusens> cjwatson: we can certainly consider splitting it out, but we are a very small team; I'll discuss with sparkiegeek whose sitting real close to me right now
<cjwatson> sergiusens: we're an even smaller team
<sergiusens> we might consider just going into launchpad code and adding the code there
<sergiusens> cjwatson: we are 2 people ;-) kyrofa and me
<cjwatson> sergiusens: I didn't expect this to be a new requirement, though - we've discussed this before.  I just wanted to check whether it was still a current plan
<cjwatson> sergiusens: LP is mostly just me at the moment
<sergiusens> cjwatson: right, so I proposed that we just do the work (kyrofa or myself) on launchpad itself
<Son_Goku> cjwatson, well, it'd be a paid sabbatical :D
<cjwatson> (not entirely, William does a lot of infra, but in terms of application code I'm producing most of the changes right now)
<Son_Goku> someone must see the value in having LP last beyond 2019, right?
<Chipaca> sergiusens: cjwatson: I don't know this variation of the three yorkshiremen sketch, but I'm not liking it
<cjwatson> sergiusens: I'm good with that too of course, but I thought snapcraft was going to have to have the corresponding code too
<sergiusens> cjwatson: the grammar we have is much more complex than what you need to do the detection and taking that back to python2 might be a huge pain
<cjwatson> sergiusens: OK, so if there's been a change of plan then that's fine, I just need to know
<hackeron> Hi, apologies for the ignorant question, I'm trying to choose a platform for an IoT Hub: I'm looking at Ubuntu Core and Yocto (and ResinOS also looks great). What would you say are the advantages/differences of Ubuntu Core over Yocto?
<cjwatson> sergiusens: is the which-architectures-should-this-snap-be-built-on logic (as discussed in New York) in snapcraft as yet, or still in progress?
<cjwatson> Son_Goku: Ubuntu has committed to supporting 2.7 out to 2023 by virtue of shipping it in 18.04 main; obviously it gets harder the longer we go
<cjwatson> (AIUI)
<sergiusens> cjwatson: it lives in snapcraft already and is documented https://forum.snapcraft.io/t/architectures/4972
<cjwatson> sergiusens: aha, nobody told me :)
<Son_Goku> cjwatson, sure, and it's supported in RHEL 7 until 2024
<sergiusens> cjwatson: hmm, I thought kyrofa discussed with you a couple weeks ago, I'll figure out where the communication broke down
<Son_Goku> and SLE 12 until 2027
<Son_Goku> cjwatson, but for the normies, py2 is dead on Jan 1, 2020
<Chipaca> hackeron: do you think you could ask that question on the forum? https://forum.snapcraft.io/c/device
<Chipaca> hackeron: answers are probably going to be interesting to other people as well
<hackeron> Chipaca: sure, I'm also on #yocto and so far my understanding is Yocto is more low level, allowing you to build exactly what you want and ubuntu-core is more of a higher level package, trying to tie you into their cloud services and container type but eeasier to get started
<cjwatson> argh sergiusens I was still typing something to you
<cjwatson> email it is I guess
<kenvandine> slangasek, i've opened and closed stable/ubuntu-18.10 branches for all of the seeded snaps
<kenvandine> seb128, ^^
<seb128> kenvandine, great, thx
<slangasek> kenvandine: does that include the gnome-3-26-1604 snap?
<kenvandine> slangasek, yes
<slangasek> kenvandine: excellent, thanks.  I'll kick off another image test build
<kenvandine> slangasek, let me know if you need anything
<cjwatson> sergiusens: taken to email, since you're bouncy here :)
<sergiusens> cjwatson: yeah, I am client mode and at the product sprint; email seems to be the best path forward :-)
<jdstrand> Chipaca: you cannot hide!
 * TotallyNotChipac whistles innocently
<jdstrand> hehe :)
<zyga> Hey guys :-)
<zyga> We have fantastic summer this spring
<Chipaca> zyga: shut up shut up shut up shut up
<Chipaca> :-)
<cachio_> zyga, Chipaca  when you have 1 minute #5123
<mup> PR #5123: tests: skip test lp-1721518 for arch, snapd is failing to start after reboot <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5123>
<Chipaca> cachio_: I've been looking at it
<cachio_> Chipaca, tx
<Chipaca> cachio_: is what you're seeing that Â«cannot reconnect may031403-609338 (google:arch-linux-64) after reboot: dial tcp 35.231.24.141:22: connect: connection refusedÂ» ?
 * zyga hugs chipaca wearing his sweaty biking shirt ;-)
 * Chipaca isn't wearing a sweaty biking shirt
<zyga> It is very warm even in the forest
<cachio_> Chipaca, it can reconnect
<Chipaca> cachio_: ok, i'll run it a few more times
<cachio_> after reboot it reconnects and tries to run the command to validate interfaces
<Chipaca> cachio_: i've been trying to reproduce the error you were seeing and every time getting a different, unrelated error
<cachio_> and it hungs doing that
<Chipaca> :-(
<Chipaca> cachio_: right
<cachio_> Chipaca, snapd is not starting correctly
<cachio_> after the reboot
<Chipaca> cachio_: yes, that's what I understood from the PR
<Chipaca> cachio_: I'm trying to get in to it to figure out why
<Chipaca> cachio_: I'd rather not disable the test if it's going to hide an issue
<Chipaca> cachio_: but if I can't figure it out before eod i'll +1 so we're not blocked on this
 * Chipaca extends his eod a bit
<cachio_> Chipaca, well the idea is not to hide an issue, the idea is stop making the builds fail until we discover why it is happening
<Chipaca> cachio_: yes
<Chipaca> cachio_: hiding the issue is a side-effect of that though :-)
<cachio_> Chipaca, I mean, we already know there is an issue there, and as it is causing machines don't die and keeping consumig resources
 * Chipaca nods
<cachio_> Chipaca, I'll continue working on this today
<Chipaca> cachio_: I'm hoping I can get in with -debug
<cachio_> Chipaca, if you use -vv you will see the details
<Chipaca> cachio_: yep
<Chipaca> cachio_: but so far it's failed twice with some TLS nonsense, and once with the above 'cannot reconnect' thing
<Chipaca> Â¯\_(ã)_/Â¯
<hackeron> Chipaca: done :) < https://forum.snapcraft.io/t/ubuntu-core-vs-yocto-and-resinos/5266
<Chipaca> hackeron: thanks! looking forward to the replies :-D
<cachio_> Chipaca, https://paste.ubuntu.com/p/cXdsZV8Rg3/
<cachio_> it remains in activating
<cachio_> and I see "Dependency failed for Snappy daemon."
<cachio_> I just retriggered the test becuse the machine was killed
<Chipaca> cachio_: do you still have that shell?
<cachio_> Chipaca, no, I rexecuted and I got this https://paste.ubuntu.com/p/CQvw6mSRh5/
<cachio_> Chipaca, I triggered another run
<cachio_> I'll hopefully have a similar shell in few minutes
<cachio_> Chipaca, it is like there are different problems when we reboot arch
<Chipaca> niiice
<Chipaca> for very small values of nice
<mup> PR snapcraft#2114 closed: meta: stop creating empty snap directory in prime <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2114>
<kyrofa> sergiusens, cjwatson communication breakdown was my fault, we were sort of talking here https://github.com/snapcore/snapcraft/issues/1685 but then in the 18.04 ramp I never managed to circle back
<kyrofa> cjwatson, things have greatly simplified, there's no special grammar anymore like there was in the previous proposal
<cjwatson> kyrofa: all right, hopefully the duplicated code won't be too bad then
<cjwatson> kyrofa: and you're right, sorry, I'd forgotten about the discussion in that issue
<kyrofa> cjwatson, no apology necessary, I'm sorry for not getting back to you
<kyrofa> cjwatson, there should actually be very little overlap. If you take a look at the proposal sergiusens linked, you'll see that snapcraft is really only concerned with a specific host, where build.snapcraft.io has the big picture
<sergiusens> kyrofa: we solved all problems already, no need to go into them again ;-)
<kyrofa> Ha!
<cjwatson> kyrofa: (see email, too)
<cjwatson> strictly speaking BSI doesn't really have the big picture, LP does :)
<kyrofa> Ah, should have looked there first
<cjwatson> BSI is probably just going to say snap.requestBuilds() or similar and let LP figure it out
<kyrofa> sergiusens, read the email, I'll take that task unless it's one you want
<kyrofa> cjwatson, python2, right?
<cjwatson> kyrofa: Yep - ideally the sort of bilingual code that doesn't impede porting
<kyrofa> Yep, easy
<cjwatson> kyrofa: Don't worry too much though, I'll massage it into shape, it's more the logic I want
<kyrofa> Cool
<Caelum> zyga: was switching to quassel, let me know if you need me to do anything re: factory submission
<zyga> Iâm off now. We need to file bugs to unblock badness on our package
<zyga> Join opensuse-admin perhaps, I was talking there a few days ago
<Pharaoh_Atem> Caelum: there's quite a few things that the snapd package currently does that's completely against Factory policy
<Pharaoh_Atem> Caelum: the number one thing is that you can't have an rpmlintrc file for factory submissions
<Pharaoh_Atem> which means you have to make rpmlint actually pass your package
<Caelum> Pharaoh_Atem: I see, and for things that can't be fixed, we file bugs, what do we file bugs against?
<Pharaoh_Atem> you don't get to file bugs
<Caelum> ok but, like, there's an apparmor file for instance, it has to be there
<Pharaoh_Atem> well, the stuff with permissions and whatnot requires a bug request to security team
<Caelum> ok
<Pharaoh_Atem> well first take care of the rpmlint errors
<Pharaoh_Atem> for example, FHS compliance and things like that
<Caelum> FHS compliance might not be possible
<Caelum> but we'll look
<Pharaoh_Atem> actually, it is
<Pharaoh_Atem> we did this for the Fedora package
<Pharaoh_Atem> https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec
<mup> PR snapd#5123 closed: tests: skip test lp-1721518 for arch, snapd is failing to start after reboot <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5123>
<Wimpress> diddledan: https://transfer.sh/gceSf/snapcraft-pr2120.snap
<Wimpress> Should fix the Gimp 2.10 issues
<zyga> Pharaoh_Atem: at a cost, you know that :)
<zyga> Pharaoh_Atem: it's all a matter of people acking that
 * zyga is happily tired after biking with family lately
<diddledan> Wimpress: seems not
<diddledan> I used `snapcraft-pr 2120 cleanbuild`
<mup> PR #2120: Fix installed-size not being set in GET v2/snaps <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2120>
<popey> diddledan: don't use snapcraft-pr, I did and it seems a bit broken
<diddledan> https://www.irccloud.com/pastebin/qScXIxcH/
<diddledan> oh
<popey> I think it still uses the deb
<popey> so you're not actually using the new version
<popey> might be "easier" to grab the pull request, and make a snap from it, install that in devmode and use that to build cleanbuild style
<diddledan> ok, I've pulled the snap that Wimpress built now
<popey> or that
<kyrofa> diddledan: snapcraft-pr is still running from source. When snapcraft is running from source and requested to cleanbuild, it doesn't copy that source over to the container, it installed the deb instead
<kyrofa> diddledan: so it's only really useful if you're building locally (on the host or in a container)
<kyrofa> If you're testing out PRs, I suggesting running it either without cleanbuild, or building a snap and cleanbuilding with that, which will copy that snap into the container
<hackeron> Quick question from a noob, this SSO account I register, if I deploy Ubuntu Core on 2,000 devices, is there any pricing or limits? - Is there an overview of what is sent to the cloud servers and is there a way to disable them if needed?
<mup> PR snapcraft#2121 opened: cli: add provides command <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2121>
<hackeron> I installed latest Ubuntu Core but the "snappy" and "ubuntu-core-upgrade" commands are both missing. How would one update the OS/kernel? -- Also, I checked cfdisk /dev/sda and there's just 1 single root filesyste, how would one rollback a failed kernel without having 2 root partitions?
<Chipaca> hackeron: hi
<Chipaca> hackeron: what are you reading, that it talks about "snappy" and "ubuntu-core-upgrade"?
<Chipaca> hackeron: in ubuntu core everything is a snap, the root filesystem, the kernels, and everything
<hackeron> Caelum: all over the place, e.g. https://www.unixmen.com/getting-started-with-snappy-ubuntu-core/ -- I guess things have changed since then :) -- so how would you upgrade from 16 to the new 18 that was out? - or is that just ubuntu, not yet on core?
<hackeron> Caelum: and it doesn't seem very resiliant to filesystem corruption, I would've thought it would use something like this? < https://mender.io/user/pages/02.product/02.How-it-works/arch-1HTTPS.png -- any reason it doesn't?
#snappy 2018-05-04
<hackeron> Whoops, sorry that should be Chipaca
<zyga> good morning!
<zyga> Caelum: hey
<zyga> Caelum: to answer your question, snappy used to do that in 15.04 days
<zyga> Caelum: snappy used a/b updates exclusively
<zyga> Caelum: but this method used way too much space
<zyga> Caelum: snappy now uses a single writable space and can use any rootfs and kernel without unpacking them, if the architecture supports that
<zyga> Caelum: so we can have any number of new core snaps, new kernel and new gadgets to test
<zyga> Caelum: and choose the one to run in the boot loader
<zyga> Caelum: this is especially important on devices with very littte storage
<zyga> Caelum: but in general it means that you have all the space to use
<zyga> Caelum: and as for mender, you can ask mborzecki next week, he used to work on mender before he joined canonical
<zyga> hackeron: ^
<zyga> hackeron: sorry, I'm not really awake yet it seems, this was the answer for your questions
<zyga> hackeron: the way we can do this is that the boot loader can pick wich kernel to load and in turn the kernel can pick (based on bootloader data) which rootfs to mount (from squashfs)
 * zyga -> breakfast
<jamesh> zyga: hi.  w.r.t. my document-portal branch, the main issue at the moment is how to handle systems without the document portal available.  I don't want snapd trying to create missing directories, so what do you think of an extra mount option to tell it to ignore when there is a missing source path? (and maybe target path?)
<zyga> hmm
<zyga> x-snapd.no-create-{source,target} ?
<zyga> something like this?
<jamesh> I was just thinking of x-snapd.ignore-missing
<jamesh> but no-create could work too
<zyga> or x-snapd.skip-if-missing
<zyga> something appropriate
<zyga> but yeah, +1 on the idea
<zyga> I'm wondering what's wrong with CI
<zyga> everything is read
<zyga> red
<jamesh> I'm thinking doing the check on the source only would be sufficient
<zyga> for this case, yes
<jamesh> this could also be used for the host font mounts, where we currently check if the various font directories exist on the host before adding the mount entries
<jamesh> we could just add them unconditionally with the ignore-missing option
<zyga> yeah, that's a nice cleanup
<jamesh> zyga: btw, CI finally passed on https://github.com/snapcore/snapd/pull/5082
<mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
<zyga> did it pass just now?
<jamesh> that was from earlier today
<jamesh> 2 hours ago according to Travis
<zyga> hmm, let's hope that whatever was slower/wrong is fixed now
<zyga> I saw that some branches exceeded 49 minute mark
<zyga> perhaps store downloads are much slower (or were) lately
<jamesh> I haven't tried to prod https://github.com/snapcore/snapd/pull/5116 again: last time it failed with the debian backend timing out
<mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
<jamesh> It's probably okay though
<mup> PR snapd#5124 opened: many: add `snapd.seeded` service <Created by mvo5> <https://github.com/snapcore/snapd/pull/5124>
<Odd_Bloke> \o/
<doko> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dpkg snapd autopkg test failures
<cachio_> Chipaca, I have updated the arch image to avoid this problem when rebooting
<Chipaca> cachio_: what was the issue?
<cachio_> I found an issue in the snapd test code doing that
<cachio_> the issue that the google shutdown script hungs
<cachio_> more than 30 minutes when the machine is shuting down
<cachio_> Chipaca, we don't configure that shutdown script, it already comes with the image and we don't use it
<Chipaca> cachio_: and the state error?
<cachio_> Chipaca, still working on the other error where snapd does not start properly after reboot
<Chipaca> cachio_: ah ok
<Chipaca> cachio_: i thought it was that one that you'd figured out :-D
<cachio_> there are 2 issues around arch
<Chipaca> cachio_: 1. ar, 2. ch
<Chipaca> ?
<cachio_> Chipaca, no, the other one
 * Chipaca hides
<mup> PR snapd#5125 opened: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5125>
<cachio_> the other was more important beause it could leave headless machines also preparing the test suite because arch is also rebooted there
<Chipaca> cachio_: and it gets expensive, also
<cachio_> yes
<cachio_> Chipaca, then I found our test code fails when we have an arch image which has not any package to install during the upgrade
<cachio_> I need to talk to maciej about this
<zyga> doko: addressed in master,
 * Chipaca -> lunch, probably
<zyga> Chipaca: #5125
<mup> PR #5125: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5125>
<mup> PR snapd#5126 opened: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
<jamesh> zyga: ^^^ here's a branch implementing the ignore-missing logic
<zyga> jamesh: ack, thank you
<zyga> jamesh: reviewed
<jamesh> zyga: thanks.  I've made the change
<cachio_> Chipaca, https://paste.ubuntu.com/p/gcGHFVYYmf/
<cachio_> Service hold-off time over, scheduling restart
<cachio_> it is taking few minutes to start after reboot and I see this log
<Chipaca> cachio_: the hold off is set to 0, ie no hold off afaik
<Chipaca> cachio_: snapd is crashing
<Chipaca> or otherwise not happy
<cachio_> Chipaca, :(
<Chipaca> cachio_: question is, why don't we see the debug messages
<cachio_> I'll increase the journlal log to degug
<Chipaca> cachio_: SNAPD_DEBUG=1 is set, right? (in the .conf.d thing
<cachio_> yes
<Chipaca> so we should be seeing them
<Chipaca> ah, i don't know how our debug interops with journald's
<Chipaca> anyway, i need to get lunch
<cachio_> Chipaca, sure
<Chipaca> bbiab
<cachio_> enjoy it
 * cachio_ afk
<doko> zyga: I don't care, I need it in cosmic
<doko> will haress mvo in person ... ;p
<zyga> doko: is c- named now?
<jamesh> zyga: I'm knocking off for the day.  I think all my PRs except the xdg-document-portal one (i.e. #5082, #5116, and #5126) should be ready to land if you're happy with the code.
<mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
<mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
<mup> PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
<zyga> yeah, I really hope to get some 2nd review but today may be tough
<zyga> thank you for this! it's very close to being all in
<jamesh> yeah.  There's probably some more stuff needed to get portals working really well, but I think we're reaching the end of the mount related parts
<jamesh> you've been a great help with all this
<jdstrand> niemeyer: hey, the forum seems to be down
<jdstrand> zyga: can you tg niemeyer? ^
<zyga> ack
<jdstrand> thanks
<niemeyer> Will look into it
<niemeyer> Seems back
<niemeyer> jdstrand, zyga: ^
<zyga> confirmed
<doko> let's make it cockroach
<jdstrand> huh, weird
<jdstrand> niemeyer: it does indeed seem to be working again. it was several pages in the span of a few minutes
 * jdstrand is curious if the snap got upgraded
<niemeyer> jdstrand: Might have been a forced reboot
<zyga> Chipaca: standup today?
<zyga> my daughter just asked me to go to a coffee shop for a shake
<Chipaca> zyga: I don't have anything
<zyga> I'm preparing some code for next week
<zyga> and I'm looking at the forum, one case is interesting again
<zyga> the lowercase vs uppercase bug
<mup> PR snapd#5125 closed: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5125>
 * zyga preps laptop for the move
<zyga> re
<zyga> organizing kids == going into production :)
<mup> PR snapd#5127 opened: HACKING: fix typos <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5127>
 * zyga removed a bucket load of stale braches
<Son_Goku> zyga, it looks like snappy is finally getting looked at in opensuse-factory
<Son_Goku> in the ML
<zyga> Son_Goku: oh, I need to check then
<zyga> I have to file some bugs but I was looking for someone that would be interested in guiding me from the other end, I think we may finally got that
<Son_Goku> zyga, well, I could have helped you too :P
<Son_Goku> I've gotten my fair share of packages in openSUSE :)
<zyga> Son_Goku: you _always_ help :-)
 * zyga hugs Son_Goku 
<zyga> thank you
<zyga> and I'm sorry about that vodka
<Son_Goku> haha
<Son_Goku> it only took you a year to apologize :P
<zyga> I was secretly hoping you would enjoy it after some time
<Son_Goku> yeah, that didn't happen
<zyga> Son_Goku: the systemd unit thing is a clear win for presets
<Son_Goku> yes
<Son_Goku> but fortunately that's easy to do
<Son_Goku> we've done that rodeo before
<zyga> Son_Goku: the rpmlint thing is a two fold case: one is easy (I suspect) - the polkit side
<zyga> the other one is probably just us aking and waiting but I don't know
<Son_Goku> Simon let me know that the FHS compliance check in rpmlint is going to turn from a warning to an error soon
<Son_Goku> it's technically an error by policy
<zyga> the /snap thing is something I'd like not to change and I would argue that it makes sense to do FHS aside (until FHS allows for /snap eventually when everyone will say "of course it should be /snap, read the FHS man" ;-)
<zyga> Son_Goku: it's all about what suse wants
<zyga> if they want it in, that's in
<Son_Goku> what I never understood is why wasn't it /run/snap/ for snap mounts?
<Son_Goku> the mounts are managed as systemd units, so they come up early enough anyway
<zyga> Son_Goku: it could be but that's not what (I think) this is about
<zyga> it's about the /snap being a first-class concept and the /snap/bin launchers being visible easily
<zyga> Son_Goku: even with /run/snap/ with mount points, you need /snap/bin
<Son_Goku> ah, right, you need a persistent place for the bin files
<zyga> and the concept can be grown, maybe we will do /snap/man/
<Son_Goku> that's why we put it in /var/lib/snapd/snap
<Son_Goku> I feel like maybe we should split the two
<zyga> yeah, which is a "unnice" place because it is "far", I think this is just that
<zyga> Son_Goku: splitting it out would be fine IMO
<zyga> they are managed by one variable today
<zyga> but it should be non-painful to fix
<Son_Goku> the location where the mounts are and where the persistent files are would make it better
<Son_Goku> and less dumb for other reasons
<zyga> what may be more painful is that snapd doesn't manage exisitng mount units
<zyga> it doesn't update them in place
<zyga> I would say that this is a prerequisite
<Son_Goku> doesn't that happen on snap refresh?
<zyga> it does
<Son_Goku> we could force a refresh on upgrade
<zyga> but it also affects unit names
<Son_Goku> to migrate all the units
<zyga> we would need some non-trivial code to get the transition correctly
<Son_Goku> hmm
<zyga> (should I stop snap-$SNAP_NAME-$SNAP_REVISION.mount
<Son_Goku> maybe a helper program that would be executed for migrating legacy locations to the new split layout?
<zyga> or that other ting)
<zyga> well
<zyga> in all cases
<zyga> I think it sucks because it's a transition
<zyga> and it can go south on us
<Son_Goku> historically, transitions aren't handled very well in snapd :/
<zyga> so I'd really do something this cosmetic only iff we had a solid framework for altering those units correctly
<Son_Goku> right
<Son_Goku> we probably should have it for other reasons
<zyga> well, it depepnds on which one but yeah, it's complex to do
<zyga> offtopic
<zyga> deja-dup / duplicity suck at backups
<zyga> they are so worthless I cannot believe there's nothing better that's also simple
<zyga> I'm trying to backup while on my LTE data
<zyga> and so far I'm streaming the backup back here
<zyga> to "compare"
<zyga> how moronic is that
<zyga> it's been going on for an hour at least
<Son_Goku> there's definitely good backup solutions
<Son_Goku> I'd probably agree those two aren't it
<zyga> Anything that is nice on a laptop and not highly complex?
<popey> restic?
<zyga> restic?
<popey> snap install restic ;)
<popey> https://restic.net/
<popey> "Backups done right!" (apparently)
<popey> cjwatson: I have a snap which appears to have gotten wedged in launchpad https://launchpad.net/~build.snapcraft.io/+snap/4b4138ec2bc6c3cd4339177e27938c64-xenial/+build/208186
<popey> it says it's been building for 22 hours.  but looks stuck
<kyrofa> zyga: I've been pretty impressed with the nextcloud clients
<cjwatson> popey: I've cancelled it to free up the builder, but I don't know what the actual problem is
<popey> I'll re-trigger if that's okay, to see if it was a one-time thing?
<zyga> kyrofa: thanks for the advice
<zyga> Texting while riding a bike is not safe
<zyga> re
<popey> diddledan: we're looking into the gimp 2.8 issue
<mup> PR snapcraft#2120 closed: many: dedup environment entries <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2120>
<popey> zyga: how can i find the revision number for a previous release of core, I'm trying to debug something and need to go backwards
<zyga> popey: AFAIK you cannot easily
<popey> that is frankly insane
<zyga> popey: snap list --all
<zyga> if you have it
<zyga> if you are a contributor you can see the channel map
<diddledan> what's the issue, popey ?
<zyga> but there is no easy nice history
<popey> gimp wont launch at all anymore
<diddledan> oh
<zyga> !
<diddledan> fudge
<popey> https://github.com/snapcrafters/gimp/issues/17
<diddledan> I'm currently working on getting 2.10 building
<popey> broken on 16.04, 17.10, 18.04. All on 2.32.5
<popey> and I want to roll back to .4 but see no easy way to do that
<zyga> popey: if you have it locally you can rollback
<zyga> if you don't you cannot
<zyga> .4 and .5 differ a bit
<popey> this is not optimal behaviour
<zyga> .5 and .6 a little
<diddledan> can we just add the gtkrc file into the build (don't unstage it)
<zyga> popey: this is the design
<zyga> popey: unless you are a snap owner
<popey> I _think_ core 4452 is amd64 2.32.4
<popey> so how do I debug this?
<zyga> no idea actually
<zyga> do you have .4 on disk?
<zyga> if not you cannot do it
<popey> no
<popey> i (as a reviewer) can find the snap in the store and manually download it
<popey> ok, done it
<popey> gimp works fine on 2.32.4, 2.32.5 broke it
<popey> perhaps we were unfortunately relying on broken behaviour in 2.32.4 and that got 'fixed' in 2.32.5?
<zyga> popey: hmm
<zyga> http://people.canonical.com/~mvo/core-changes/html/stable/2.32.3r4407_2.32.5r4486.html
<zyga> .4 was not published, was it?
<zyga> 4->5 change was AFAIK tiny
<popey> shall i file a bug in snapd?
<zyga> please
<zyga> popey: I bet it is something else
<zyga> .4 and .5 are the same really
<zyga> it must be something else that is changing
<popey> well, it's something in between revision 4452 and 4486
<popey> https://bugs.launchpad.net/snapd/+bug/1769210
<mup> Bug #1769210: snapd 2.32.5 broke gimp <snapd:New> <https://launchpad.net/bugs/1769210>
<diddledan> gimp is working for me on 2.32.5
<popey> wat
<diddledan> somehow the error message refers to files which are in a different location - it's trying to copy files from $SNAP/usr/etc when they're installed to $SNAP/etc
<popey> try removing it completely and reinstalling
<popey> perhaps you already had some of this in snap/gimp
<zyga> popey: question, could gimp benefit from layouts?
<cjwatson> popey: re-trigger> sure
<mup> PR snapd#5128 opened: Revert "Skip test lp-1721518 for arch, snapd is failing to start afteâ¦ <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5128>
<teward> is there a rule against snap applications requiring donation/payment before you can actually use the applications?
<diddledan> super helpful errors for the win (AGAIN!)
<diddledan> https://www.irccloud.com/pastebin/2wco9wZB/
<diddledan> what kind of error is that? surely I need to know why it thinks lib isn't a directory and what it's trying to do with it to figure out what I did wrong?!!
<kyrofa> diddledan: I'd need to see the YAML to help
<diddledan> hah
<diddledan> it's huge
 * diddledan pushes it to git
<diddledan> kyrofa: https://github.com/diddledan/gimp-snap/blob/2.10-gold/snap/snapcraft.yaml
<diddledan> what's 1400 lines between friends
<kyrofa> Oh darn, it's a remote part
<diddledan> yeah it was fine until I added the pulseaudio part to that yaml
<diddledan> alsa normally installs fine but I've tweaked it for this build to not install any prereqs in the `alsa-plugins` part
<diddledan> instead the pulseuadio is supposed to be picked up from my shipped pulseaudio part in gimp's yaml
<diddledan> I've got this in the gimp yaml:
<diddledan> https://www.irccloud.com/pastebin/ZQQ9O5rq/
<diddledan> so something with either the dependency on pulseaudio or the build-packages or stage-packages override is killing it
<kyrofa> diddledan, from the error, it sounds like a part that gets staged ahead of alsa-plugins has a lib directory, but somehow alsa-plugins is providing a file there instead of a dir
<diddledan> nope, there's no ./lib in parts/alsa-plugins/install
<diddledan> there is a ./lib in stage, yes, which is why it's complaining, but what it's trying to do with it I can't tell
<kyrofa> Is the lib in stage a directory or a file?
<diddledan> it's a directory with libraries in it
<kyrofa> diddledan, if there's no lib in parts/alsa-plugins/install, why does it have a `stage` keyword with `lib` in it?
<diddledan> o_O
<diddledan> ok, I see that now. thanks for the eyes :-) the remote part has a define to include ./lib while staging but that folder doesn't now exist because I overrode the stage-packages to be null
<diddledan> we could do with an error condition for such cases, then, where stage: or prime: keywords include references to paths that don't exist
<diddledan> that was a much simpler problem than I thought it was going to be
<diddledan> I'm gonna clean my build and start it anew to be sure that it's definitely that
 * diddledan cuddles kyrofa 
<mup> PR snapd#5129 opened: cmd/snap-confine: allow any base snap to provide /etc/alternatives <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5129>
<zyga> jdstrand: ^
<mup> PR snapcraft#2122 opened: many: introduce variables for part src and build <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2122>
<mup> PR snapd#5130 opened: interfaces/apparmor: allow bash and dash to be in /usr/bin/ <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5130>
<zyga> jdstrand: one more
<mup> PR snapd#5127 closed: HACKING: fix typos <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5127>
<diddledan> yup, kyrofa , that was the problem - having a path specified in stage: that didn't exist
<diddledan> (my build finally got there)
<diddledan> twenty minutes of building to get to that point :-p
<diddledan> it's not a small build by any means :-D
<mup> PR snapcraft#1064 opened: pluginhandler: support colliding with directories <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1064>
<kyrofa> diddledan, yeah... I'll never understand why you guys use cleanbuild to iterate :P
<kyrofa> You could have just cleaned that one part and tried again
<diddledan> :-p
<kyrofa> Heck I still iterate on bionic before throwing to LP for final builds
<kyrofa> I very rarely use cleanbuild
<kyrofa> If I have larger projects, I have lxd containers dedicated to iterating on them so I don't dirty my host
<kyrofa> With ccache installed on them, haha
 * zyga found a bug in base snaps
<zyga> (well, a new bug)
<mup> PR snapcraft#2123 opened: file_utils: don't let FileNotFoundError escape <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2123>
<mup> PR snapd#5131 opened: tests: fix interfaces-network test for systems with partial confinement <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5131>
#snappy 2018-05-05
<mup> PR snapd#5132 opened: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/5132>
<mup> PR snapd#5133 opened: spread.yaml: add cosmic (18.10) to autopkgtest/qemu <Created by mvo5> <https://github.com/snapcore/snapd/pull/5133>
<mup> PR snapd#5134 opened: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<mup> PR snapd#5135 opened: Docs moved to forum <Created by abitrolly> <https://github.com/snapcore/snapd/pull/5135>
<mup> PR snapcraft#2124 opened: snapcraft.yaml: update apt repo location <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2124>
<mup> PR snapcraft#2124 closed: snapcraft.yaml: update apt repo location <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2124>
#snappy 2018-05-06
<mup> PR snapcraft#2125 opened: Fix running python plugin on Fedora <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2125>
<mup> PR snapcraft#2125 closed: Fix running python plugin on Fedora <Created by abitrolly> <Closed by abitrolly> <https://github.com/snapcore/snapcraft/pull/2125>
<mcphail> Is there any way I can specify the source-tag: for a part to automatically be the latest annotated git tag? Or should I omit the source-tag: stanza and try to do some magic in override-pull: ?
<mcphail> Looks as if the override-pull: thing is the best way. Maybe it would be worthwhile adding this feature to source-tag: as it must be a common requirement?
<mcphail> Which bug tracker is being used for snapcraft? There's one on launchpad and another on github
<mwhudson> mcphail: i think both are monitored
<mcphail> mwhudson: ok. thanks
#snappy 2019-04-29
<mborzecki> morning
<zyga> good morning
<zyga> mborzecki: what a weird day, it's cold but forecast shows it will be 20+ in a few hours :)
<zyga> mborzecki: how was your weekend?
<mborzecki> zyga: hey, tiring
<zyga> I was sleeping through most of Saturday and about a third of Sunday
<mborzecki> zyga: allergy?
<zyga> just not enough sleep :D
<zyga> mborzecki: wanna read the next chunk: https://github.com/snapcore/snapd/pull/6788/files ?
<mborzecki> zyga: will do next, looking at 6782 now
<zyga> thanks!
<mborzecki> heh, 6782 unit tests fail, i'm guessing it's because we're using 1.9 in travis, while go buildid is from 1.10+
<zyga> mborzecki: hmmm
<zyga> extra status 2?
<zyga> no idea
<mborzecki> mvo: morning
<mborzecki> mvo: got a little for for 6782
<mvo> mborzecki: hey, good morning
<mvo> mborzecki: aha, yes, I figured that "file" is too old, a bit of a PITA, I need to figure out how to meaningful test this on older distros
<mborzecki> mvo: i'll push a fix in a minute
<mvo> mborzecki: oh? what will you do?
<mborzecki> mvo: fwiw, i'm just forcing a specific build ID
<mvo> mborzecki: neat! curious how you manage that given thats a composition of all inputs
<mvo> mborzecki: will you push also update the comment? or should I do that?
<mborzecki> mvo: i'll push it too
<zyga> Hey mvo, good morning
<zyga> ãã¯ããããã¾ã
<mvo> mborzecki: \o/
<zyga> One of the surprising things about learning Japanese is that it is completely natural to just read this now
<mvo> zyga: hey, good morning
<mvo> zyga: amazing!
<mborzecki> mvo: pushed, waiting for travis unit test job to explode now :)
<mvo> ta
<mborzecki> mvo: hah, so go build ID test worked now, but --build-id=0x<hexstring> did not :P
<pstolowski> mornings
<mvo> hey pstolowski - good morning
<mborzecki> pstolowski: hey
<mborzecki> opensuse failing again?
<Chipaca> https://github.com/snapcore/snapd/pull/6743 could use a second review
<pstolowski> looking
<Chipaca> thanks!
<mborzecki> packages.ubuntu.com is quite confusing
<mborzecki> https://packages.ubuntu.com/source/disco/desktop-file-utils leads to debian salsa as package source, but apparently that's not what is built
<zyga> re
<zyga> back from calls
<mvo> we have a bunch of stuff targeted for 2.39 for review, would be great if we can focus on this to land this by tonight if possible
<pstolowski> Chipaca: #4673 has 2 +1s
<Chipaca> pstolowski: yes, thank you!
<zyga> brb, coffee
<Chipaca> mvo: what should we do with https://github.com/snapcore/snapd/pull/6404 ?
<mvo> Chipaca: we need to ignore it for now, I will un-milestone it
<pstolowski> mborzecki: gadget layouts +1
<Chipaca> mvo: ok
<Chipaca> mvo: there's two other blocked
<mvo> Chipaca: at least the commandfromcore fix needs to land first
<mvo> Chipaca: yeah, same for these, let me fix things
<Chipaca> mvo: and user removal probably also needs demilestoning
<mvo> Chipaca: 6404 has a (tiny) chance
<mvo> Chipaca: but not until all the other bits are in
<mvo> Chipaca: yeah, same for user removal
<Chipaca> mvo: i think auto-install has two +1's now
<mvo> Chipaca: I had hoped samuele could have a look tomorrow
<Chipaca> he's back tomorrow? nice
<mvo> Chipaca: its one of the features that are slightly in the danger-zone
<Chipaca> yeh
<mvo> Chipaca: yeah, unles I misremember we should have him back soon :)
<mvo> Chipaca: please reload, list should be more sane now
<Chipaca> noice
<mborzecki> pstolowski: wow, really feel sorry for you with all error peeling cruft you had to go through
<pstolowski> hehe
 * zyga found a small bug in snapcraft
 * zyga sighs 
<Chipaca> mvo: in reviewing #6741 I had to make a change to get snapcraft to work (but it's still failing even after that0
<Chipaca> mvo: not sure if there's a trick to it i'm missing :-/
<mvo> Chipaca: what kind of error do you get?
<Chipaca> mvo: maybe i should cleanbuild it? the unit tests are failing because it's getting a context somehow?
<Chipaca> it's weird
<mvo> Chipaca: this sounds like cleanbuild may help here, yes
<zyga> mvo: is samuele back?
<zyga> https://github.com/snapcore/snapd/pull/6791#issuecomment-487540857
<zyga> I wanted to discuss this
<mvo> zyga: he is back tomorrow
<zyga> I s ee
<mvo> zyga: so we should discuss this tomrrow early (ish) to ensure it does not block things
<cmatsuoka>  /query cjwatson
<cmatsuoka>  oops
<Chipaca> mvo: even when I apply http://paste.ubuntu.com/p/g7NYVXdB7y/ I still see a -Zxz during the snapcraft, but not sure what's causing it. If you care to look, it's https://pastebin.ubuntu.com/p/bhq2vWtWVW/
<mvo> Chipaca: hm, that is strange
<Chipaca> mvo: anyway +1 to the fromCore pr
<mvo> Chipaca: thank you, I like your suggestion to be more selective about picking the right binaries
<mvo> Chipaca: I play with this now, its a bit of a PITA (as its slow to test). thank you!
<Chipaca> mvo: all it takes is a stage section in the same part
<Chipaca> maybe cmatsuoka knows how to remove all the snap/**.go files with a scriptlet or sth
<mvo> Chipaca: yeah, I'm playing with it right now, I think I know what to do, the testing is a slightly annoying (cleanbuild etc)
 * mvo lunches first though
<Chipaca> mvo: buen provecho
<dot-tobias> kyrofa: Read your article about stage-snaps (https://kyrofa.com/posts/speed-up-your-ros-snap-builds), thanks! I'm wondering if one could use the official ruby snap like this to speed up Ruby-based parts, or does its classic confinement prevent this?
<cmatsuoka> Chipaca: I'll have a look
<mborzecki> anyone up for a simple PR? https://github.com/snapcore/snapd/pull/6792 just renames and reshuffling some code
<jdstrand> mvo: hi! do we have an eoan image in travis yet? libseccomp finally migrated
<zyga> jdstrand: eoan?
<zyga> is that the new name?
<jdstrand> zyga: ubuntu 19.10
<zyga> oh, nice
<cmatsuoka> Chipaca: how was the snap dir problem handled until now?
<jdstrand> mvo: also, I *think* I'm through the obstacles so will be focusing on adding tests and testing libseccomp 2.4.1 in all ubuntu releases. we should have a chat this week on what to do about 2.4.1 with core/core18/snapd snaps. maybe wednesday-ish?
<mvo> jdstrand: we don't have this is travis yet, we tend to add it late, we should add it to spread.yaml in qemu though, should be a trviaial PR
<mvo> jdstrand: wednesday is a public holiday here, but thu, fri sounds fine
<jdstrand> mvo: it is already there for qemu (I'm using it)
<jdstrand> mvo: ack on thursday
<mvo> jdstrand: thanks!
 * zyga lunch break
<kyrofa> dot-tobias, great question! I believe you can use classic snaps as stage-snaps (sergiusens will know for sure), but if your snap isn't classic there's the possibility of issues. I haven't tried that particular case, but you should!
<Chipaca> cmatsuoka: it's not handled; the snapd snap has .go files in snap/
<cmatsuoka> oh I see
<zyga> back from lunch
<cachio> mvo, 2.38.1 in stable now
<cachio> mvo, now promoting snpad
<mvo> cachio: thank you!
<cachio> snpad snap 2.38.1 already in stable
<cachio> I'll monitor the snaps now
<zyga> I have a simple CUDA app running, now let's see if I can snap it
<zyga> mborzecki: let me add another GPU to see if that works too
<zyga> mborzecki: I have an ancient quatro GPU as well
<zyga> I got it for free once
<zyga> heh, no X now :)
<zyga> restarting gdm (it helped last time)
<zyga> heh
<zyga> yes it helped
<zyga> let's install the 340 driver version
<pstolowski> uh, one more timings PR coming from me, i was sure it landed already until i tried passing --ensure to snapd debug timings.. oh well :(
<Pharaoh_Atem> zyga, mvo, mborzecki, kyrofa, sergiusens: so... how far are we from me being able to propose a talk at Flock this year about "creating your first Fedora-based snap"?
<Pharaoh_Atem> the Flock 2019 CfP hasn't opened yet, but I want to think about this now, so that maybe we can figure out what we need to do to make that a thing
<zyga> Pharaoh_Atem: hmm, no idea, I'm deep in CUDA, let me think and get back to you tomorrow
<zyga> mborzecki: ^
 * Chipaca goes to the gym before he starts breaking things
<mvo> enjoy Chipaca
<mvo> hrm, lots of red tests, does anyone looked what is breaking?
<kyrofa> Chipaca, decided to start before going to the gym?
 * cachio lunch
<Chipaca> kyrofa: nope!
<kyrofa> Stupid tab-complete adding that comma...
<Chipaca> although i've seen the test-snapd-appstreamid test fail a lot
<Chipaca> dunno why
<Chipaca> now yes i go
 * zyga EODs to stay sane and healthy :)
<jdstrand> roadmr: hey, can you pull r1225? it isn't urgent
<mvo> pstolowski|afk: for tomorrow - one idea that came up was to measure how long state loading (the json stuff) takes, i.e. adding this to the measurements taken
<mvo> cachio: hey, I see some failures related to "google:ubuntu-16.04-32:tests/main/appstream-id" in recent PRs, would be great if you could check if its just a fluke or something with the store or snapd (but not rush, I get dinner now and mostly EOD)
<cachio> mvo, hey, I saw the mame
<cachio> the error is because the store is taking more than 1 second to answer
<cachio> there is a PR fixing it
<cachio> let me check i
<cachio> t
<cachio> mvo, I retriggered travis for #6789
<cachio> It failed last time trying to download a golang dependecy
<roadmr> cachio, mvo : fwiw it's probably taking a bit longer than expected due to the extra load from the recent core release :) should subside in a few hours
<roadmr> jdstrand: just saw this! sure, r1225 pull coming up
<cachio> roadmr, it is ok, I already fix that in a test, I added a longer timeout to support this kind of situations
<roadmr> crap, I seem to have deleted my "bump-crt" script inadvertently :( jdstrand hehe no worries I'll figure it out
<jdstrand> roadmr: thanks and whoops!
<jdstrand> sergiusens[m], kyrofa: hey, if one of you are around, I'm curious about how to handle multiarch. I've read some of the docs but still not sure. I'd like on amd64 to build with gcc-multilib both amd64 and i386 (eg, -m32), but on i386 to only build its native arch. then I'd like to apply that process to arm64/armhf and I guess ppc64el/powerpc
<jdstrand> sergiusens[m], kyrofa: is this possible with a single snapcraft.yaml such that I can have LP builds and end up with result I just described?
<kyrofa> jdstrand, so you want the snap for amd64 to be built for both amd64 and i386, but also want one built for i386? I'm confused why you care about the amd64 one being compatible with i386 then
<kyrofa> i.e. it will never be installed on i386. Wouldn't you want the same snap released to both architectures in that case?
<jdstrand> kyrofa: let me rephrase. the end result should be a snap that contains its native architecture and any supported secondary architectures
<jdstrand> kyrofa: so, on amd64, that is a snap that has both amd64 and i386 binaries (think wine), but on i386, just i386 binaries
<kyrofa> Ah, the wine example makes this more clear
<jdstrand> kyrofa: eg r1 is amd64 and has amd64 and i386 code. r2 is i386 so only has i386 code
<jdstrand> r3 is amr64 with arm64 and armhf, r4 is armhf with only armhf
<jdstrand> etc
<kyrofa> jdstrand, in that case, it's all about the build system, and the `architectures` field doesn't matter (since the default uses the build arch). Correct?
<jdstrand> I know how to generate an individulat snapcraft.yaml for each individual situation, but not one that works for all where the same snapcraft.yaml is used by LP to build all the archs with the secondary arch support as described
<kyrofa> jdstrand, can you show me the difference between your amd64 and i386 yamls?
<jdstrand> kyrofa: I figured I could adjust the Makefile to look at some things to decide when to build with -m32, but I need the gcc-multilib only sometimes, etc
<kyrofa> That's doable
<kyrofa> build-package, right?
<jdstrand> kyrofa: between amd64 and i386, it's just about build-packages
<kyrofa> Try this:
<jdstrand> kyrofa: I guess I might conceivably need different stage-packages. I'm going to need the :i386 and the :amd64 packages in the amd64 build
<kyrofa> jdstrand, https://paste.ubuntu.com/p/3z4VgPpcxg/
<kyrofa> stage-packages should work the same way
<jdstrand> ok, then I can use the equivalent gcc-... for arm64, etc
<jdstrand> ok, that makes sense
<kyrofa> Yeah you get the idea
<jdstrand> kyrofa: thanks! I may have another question, but this is helpful :)
<kyrofa> jdstrand, it's been a while since I did any of that, so let me know if you run into issues
<kyrofa> Of course!
<jdstrand> well, the paste helps me know what to focus on a lot
<mvo> cachio: aha, thanks! I remember the PR now
<cachio> mvo, I'll try to merge it today
<mvo> cachio: yeah, once its green, go for it :)
<cachio> mvo, sure, thanks
<mvo> thank *you*
<mvo> cachio: one more question - I see some failures in     - google:ubuntu-core-18-64:tests/core18/ and     - google:ubuntu-core-18-64:tests/main/ and its "rsync: write failed on "/mnt/user-data/gopath/src/github.com/snapcore/snapd/tests/main/interfaces-broadcom-asic-control/snapd-unpack/usr/lib/snapd/snap-repair": No space left on device (28)" - did anything change here recently (with the image or something else that you can think of?)
<cachio> mvo, no, do you have a link?
<mvo> cachio: this was in this pr https://github.com/snapcore/snapd/pull/6741
<cachio> mvo, checkign
<cachio> mvo, this is something new
<mvo> cachio: maybe its a one-off, did not happen in the previous run (3h ago)
<kyrofa> mvo, is `base: core` still not a thing? I'm getting "- Mount snap "foo" (unset) (cannot find required base "core")"
<cachio> mvo, I am reviewing other logs to see if it is related to that PR or it is happening in others as well
<kyrofa> sergiusens, I get that ^ when trying to install a snap I build using `base: core`
<ijohnson> kyrofa: I thought that `base: core` only worked inside snapcraft.yaml and that when that's there snapcraft just generates a snap.yaml without a `base` spec
<ijohnson> kyrofa: and AFAIK, the core16 snap isn't ready yet (it's not in stable at least)
 * kyrofa sanity checks
<sergiusens> kyrofa: are you using the snapcraft snap? It is valid in snapcraft.yaml but not snap.yaml
<kyrofa> *sigh* please give me ten minutes while I try to figure out why multipass decided to stop working
<kyrofa> "shutdown called while starting"...
<ijohnson> kyrofa: `snap remove multipass && snap install multipass --beta --classic` always does the trick for me :-)
<kyrofa> Hahahaha
<ijohnson> I do that probably at least 2-3 times a week
 * kyrofa does just that
<kyrofa> Man... that's saving some sort of snapshot now that's taking forever. It snapd seriously backing up all the multipass VMs?
<kyrofa> I just want to get back up and running!
<ijohnson> :-( I don't see the snapshot behavior on stable snapd
<kyrofa> Oh no
<kyrofa> Crap, how did I end up on edge
<kyrofa> This might explain a few things
<ijohnson> good luck!
<kyrofa> sergiusens, ah, it's the snapcraft .deb (issues from a customer)
<kyrofa> sergiusens, that puts the base into the final YAML
<kyrofa> You're right, the snap does the right thing
<kyrofa> sergiusens, have you considered updating the deb to suggest the snap?
<bdx> hello everyone
<bdx> hitting a strange issue when building my snap https://paste.ubuntu.com/p/YV2vz6RMJF/
<bdx> the plugin I'm using: https://gist.github.com/jamesbeedy/1f592f9beddf8f2973452d0dc742c09f
<bdx> nothing has changed in my plugin/source since the last time I built the snap that uses ^ plugin
<bdx> all of the sudden its barfing with ^^
<bdx> I'm wondering if there is something that may have changed about how plugins are used to override steps?
<cmatsuoka> bdx: did you install snapcraft using snap?
<bdx> yes
<bdx> I get that error both when using `snapcraft cleanbuild` and `snapcraft`, so both in the lxd build environment and on my local (both of which are 18.04)
<cmatsuoka> bdx: could you paste your snapcraft.yaml file somewhere? (you may also want to join #snapcraft)
<bdx> https://gist.github.com/jamesbeedy/c81decb3625999f75e04564d3b19b71e
<bdx> cmatsuoka: want me to bring this over to #snapcraft ?
<cmatsuoka> bdx: just a sec, I'm building it locally to see what happens
<cmatsuoka> bdx: sent you some suggestions in #snapcraft
<mvo> cachio: re 6741> I think I found the issue, sorry, the out-of-space thing was an error in this PR
<om26er> Hi! It seems Ubuntu Core does not have the avahi-control interface, how do I make it available to my snap ?
<om26er> ogra ^^
<om26er> also, when did you lose that underscore in your nick ;-)
<om26er> who takes care of those "human review required" failures while publishing snaps ?
<om26er> I created a plug and it apparently needs an approval of some sort https://forum.snapcraft.io/t/human-review-required/11158
<jdstrand> roadmr (cc msalvatore): hey, can you make that r1226 instead? this adds a 'system-users' check to support upcoming yaml)
#snappy 2019-04-30
<mborzecki> morning
<mborzecki> brb, new kernel
<zyga> good morninf
<mborzecki> zyga: hey
<zyga> hey hey
<zyga> I'm trying to fix what I prepared yesterday and add the CUDA test as well
 * zyga fights tab creep
<mborzecki> zyga: next step https://forum.snapcraft.io/t/do-snaps-apps-support-vulkan/10534/2
<zyga> mborzecki: yeah, I will find some hello-vulcan code
<zyga> mborzecki: the interesting experience started when I removed various random bits of MESA from my test snap
<zyga> it shrank significantly and no longer ran without the "driver" snap connected
<zyga> but first things first
<zyga> fight tab creep, restore opengl part to working order, get cuda to work in confinement
<mborzecki> mvo: morning
<zyga> hey mvo :)
 * zyga managed to reduce tab creep to ~ 10 tabs 
<mvo> hey mborzecki and zyga good morning
<mborzecki> zyga: can you take a quick look https://github.com/snapcore/snapd/pull/6792 ? just renames and moving the code around
<zyga> mborzecki: looking
<zyga> I had a look last night but it was a bit more complex
<zyga> mborzecki: question: why PositionedVolume contains a *Volume rather than Volume?
<mborzecki> zyga: avoiding another copy, no other reason
<zyga> are we mostly working with Positioned or the plain version?
<mborzecki> zyga: depends where, validation works with Volume mostly, update works with Positioned*
<zyga> a copy has its cost but also has the property of not being related to something anymore, so you can clobber the volume but the positioned volume stays intact
<zyga> mmm
<zyga> +1 but consider if it is easier to reason about this without the pointer
<mvo> hm 6782 has no +1 but surely mborzecki has an opinion on this one :)
<mborzecki> mvo: looking
<zyga> commented
<mborzecki> zyga: thanks
<zyga> mborzecki: and then perhaps https://github.com/snapcore/snapd/pull/6788 :)
<zyga> simple and just a 2nd +1
<mborzecki> mvo: lgtm, though i can only +1 the parts i didn't touch :)
<zyga> woot, thank you!
<mvo> mborzecki: that seems to be fine, I will +1 the parts you did touch
<zyga> mborzecki, mvo: one simple argument removal https://github.com/snapcore/snapd/pull/6794
<mborzecki> zyga: more lines removed than added, +1 :)
<mvo> zyga: 6782 had a +0.9 from you - is the final 0.1 there now? with that we can merge jamies 6759
<zyga> Thanks guys!
<zyga> mvo: looking
<zyga> mvo: https://github.com/snapcore/snapd/pull/6782/files#diff-bdab0f3d09049605d4bd7bc4892a6a4bR91 !!!
<zyga> was this always broken>?
<mvo> probably :/
<zyga> but the test did not catch this before
<zyga> interesting
<mvo> zyga: yeah, definitely worth looking why
<zyga> mvo: and it was failing for you without this extra dash, right?
<zyga> mvo: but not initially,
<mborzecki> mup still silent?
<mvo> zyga: I think mborzecki fixed this particular one
<mvo> mborzecki: I think so
<zyga> mvo: so something that changed in the patch caused it to fail
<mborzecki> --build-id?
<zyga> aha
<zyga> yes
<mvo> mborzecki: we probably need to poke gustavo about it
<zyga> mup_: hello
<pstolowski> morning
<mborzecki> zyga: mvo: fwiw both -build-id and --build-id, the manpage though says --build-id
<mvo> hey pstolowski
<mvo> mborzecki: aha, nice
<pstolowski> mvo: i saw your idea from yesterday, ty, i'm looking at it
<pstolowski> (timing for state loading)
<mvo> pstolowski: cool, thanks
<zyga> did anyone restart https://github.com/snapcore/snapd/pull/6794 ?
 * mvo didn't 
<mvo> zyga: if you could add a test to 6751 this one is fine to go in, sorry that the review for this took so long, its nice and small and ready
<zyga> checking
<zyga> yes, I plan to
<zyga> that's an early branch,
<zyga> just didn't go anywhere last week
<pstolowski> mvo: to clarify - the idea with timings is to measure state.ReadState() on startup correct?
<mvo> pstolowski: yes
<zyga> mvo, mborzecki: another simple chunk https://github.com/snapcore/snapd/pull/6796
<Chipaca> moin moin
<niemeyer> mvo, mborzecki_: May I help somehow?
<mborzecki_> niemeyer: hi, mup is awfully silent
<niemeyer> Sorry, I still haven't fixed its ability to self-identify
<niemeyer> I'll poke it
<mborzecki> niemeyer: thanks!
<zyga> hello Chipaca, hey niemeyer :)
<niemeyer> mup_: Should work now
<mup_> niemeyer: In-com-pre-hen-si-ble-ness.
<niemeyer> Hmm.. and somebody took over its nick
<niemeyer> zyga: Heya
<mvo> zyga: hey, do you have time for a quick about the static attibutes PR?
<zyga> mvo: hey, sure
<mvo> zyga: cool, lets hop to the standup channel, I will be there in 30s
<zyga> mvo: sure
<zyga> pstolowski: hey
<mvo> pstolowski: hey, want to join the standup channel?
<zyga> pstolowski: we have the call about stale connection attributes
<zyga> pstolowski: could you join us please
<zyga> pstolowski: sorry for not pinging you earlier, but we just started a moment ago
<pstolowski> zyga: sure, coming
<zyga> thank you Pawel!
 * Chipaca hates 409s
<mup> PR snapd#6797 opened: overlord/ifacestate: revert the initial fix for lp #1825883 <Created by stolowski> <https://github.com/snapcore/snapd/pull/6797>
<pstolowski> zyga, mvo: ^
<zyga> done
<zyga> pstolowski: and update the bug report with additional information that this is unfixed
<mvo> pstolowski: ta!
<pedronis> mvo: we still need to decide what to do with https://github.com/snapcore/snapd/pull/6638/files, no ?
<mup> PR #6638: interfaces: add support for the snapd snap in the dbus backend  <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
<mvo> pedronis: yes
<mvo> pedronis: its a re-exec thing but yeah, without it there is a (small) regression
<mvo> pedronis: thinking about it, it might be racy but worst case is that the same file is written twice - unless I miss something
<pedronis> Chipaca: mvo: hi, is the cohort stuff in 2.39? what is still missing?
<Chipaca> pedronis: it is not in 2.39, no
<Chipaca> pedronis: create-cohort landed just last night finally
<Chipaca> pedronis: i'm working on install, tests are looking good and hoping to get it covered and up today
<Chipaca> switch and refresh should be a small thing after that, and then commands to expose this to the user
<Chipaca> still thinking about leave-cohort a bit, but expect it to emerge naturally as i get there
<mup> PR snapd#6798 opened: gadget: introduce checkers for sanitizing structure updates <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6798>
<mborzecki> another bulky one ^^, fortunately tests are 75+% of the whole thing
<mvo> pedronis: should I de-conflict 6747 for you?
<mborzecki> mvo: can we just bump go to 1.10 in travis? iirc it's the oldest one we build with anyway
<mvo> mborzecki: iirc EPL and RHEL were holidng us back, but if that got updated to 1.10 +1
<mborzecki> mvo: it would also fix the madness with go fmt indent chnges in 1.10
<mvo> mborzecki: what is the version in centos right now? (and rhel?)
<mborzecki> mvo:  checking right now
<mvo> mborzecki: ta
<mvo> pedronis: fwiw, I have a PR almost ready to add deviceCtx to checkSnap* and update the tests (just the mechanics at this point, no functional changes)
<mborzecki> mvo: golang-1.11.5-1.el7
<mup> PR snapd#6799 opened: travis: bump Go version to 1.10.x <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6799>
<mvo> mborzecki: \o/
<Chipaca> mborzecki: I don't think the .x is literal
 * Chipaca looks
<Chipaca> well it worked Â¯\_(ã)_/Â¯
<mborzecki> Chipaca: that should be last tagged patch release in given major.minor
<Chipaca> mborzecki: isn't "1.10" the same?
<mborzecki> Chipaca: i was bit surprised suprised that 1.10 is 1.10 exactly
<Chipaca> that is surprising indeed
<Chipaca> the documentation i saw didn't point this out either
<Chipaca> hm
<Chipaca> anyway, eh, if it works it works
<pedronis> mvo: if you want/can, I'm trying to take care of errands and then do the 2.39 reviews
<mvo> pedronis: thanks!
<mvo> pedronis: pushed the update for devicectx
<mvo> 6747 needs a second review btw :)
<mvo> (its this devicectx PR)
<Chipaca> luuuuuuuunch
 * Chipaca is zombie
<pedronis> mvo: gave some feedback on #6778
<mup> PR #6778: [RFC] snapstate: auto-install snapd when needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/6778>
<pedronis> mvo: commented also in #6638
<mup> PR #6638: interfaces: add support for the snapd snap in the dbus backend  <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
<pedronis> marked it for 2.29 as well
<pedronis> heh, 2.39
<mborzecki> off to pick up the kids
<dot-tobias> kyrofa / sergiusens: Is it possible (and feasible) to use classic snaps as stage-snaps? The ruby snap seems to work fine so far, but suddenly the bundled libraries are not found by apps in the snap. I guess it has something to do with this snapcraft notification: âpart X needs the following libraries that are not included in the snap or base: lib64/ld-linux-x86-64.so.2â
<pedronis> pstolowski: question in #6755
<mup> PR #6755: overlord/snapstate: tweak autorefresh logic if network is not available <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6755>
<cmatsuoka> Chipaca: can the snapd snap be built with base: core? it could solve the snap dir clutter problem
<mup> PR snapd#6799 closed: travis: bump Go version to 1.10.x <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6799>
<pstolowski> pedronis: replied
<mup> PR snapd#6797 closed: overlord/ifacestate: revert the initial fix for lp #1825883 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6797>
<pedronis> pstolowski: couple of comments, thank you
<pedronis> mvo: thanks for #6771 , I was thinking about something like that
<mup> PR #6771: cmd: add `snap debug validate-seed <path>` cmd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6771>
<pedronis> mvo: zyga: this is bad tough:  #6763
<mup> PR #6763: overlord/snapstate: remove PlugsOnly <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6763>
<zyga> pedronis: oh?
<zyga> pedronis: can you clarify?
<pedronis> zyga: it's needed for this at some point: https://forum.snapcraft.io/t/cross-snap-operations-bases-and-concurrency/5685
<zyga> pedronis: I wasn't aware of this, is having just plugs somehow special though? (or having just slots?)
<Chipaca> cmatsuoka: if that now works, yes
<pedronis> zyga: yes, it's special, two snaps having only plugs can't interfere with each other
<Chipaca> cmatsuoka: assuming base: core doesn't actually reach the snap.yaml
<zyga> pedronis: how about two snaps with just slots?
<pedronis> (unless they are a special snap like bases or kernel etc)
<cmatsuoka> Chipaca: worked in a quick PoC, let me try with the real thing
<pedronis> zyga: that's not as useful, they interfere each with snaps with plugs
<pedronis> anyway that change needs reverting
<pedronis> atm
<sergiusens> dot-tobias: you will need to organize or set the library paths appropriately... I don't think the "fine" part has been nailed if libraries are not found
<sergiusens> dot-tobias: also, if the publisher decides to change the base then when you stage that snap you will potentially have a broken snap, more than potentially, most likely as the path to the linker loader is fixed to the base
<sergiusens> kyrofa: we do have a bug for that about the deb and bases... it just requires time... I am not missing the SRU process at all
 * sergiusens scratches head as he does not see his replies from yesterday on this irc session
<dot-tobias> sergiusens: Thanks for the info, I'll test if a fork of the snap works better (I haven't found an issue yet, but I guess somewhere down the road the ruby snap's classic confinement will break something?). Anyway, the snapcraft notice about ld-linux doesn't occur if I switch back to stage-packages and the ruby plugin, but still one service suddenly cannot find a library pulled in via stage-packages (not stage-snaps) â¦ puzzles me
<tomwardill> hi! Is there a snapd environment variable (or other method) that will get me the response payload from the store?
<zyga> Chipaca: ^
<Chipaca> tomwardill: hi! yes 1 sec
<tomwardill> ta
<Chipaca> tomwardill: SNAPD_DEBUG_HTTP, more in https://github.com/snapcore/snapd/blob/master/HACKING.md#testing-snapd
<jdstrand> ogra: hey, I just noticed on my arm64 device, 'sudo classic' results in no /etc/alternatives, which causes anything you install with apt that uses alternatives to fail. have you seen this?
<tomwardill> Chipaca: that doesn't appear to dump the response body
<tomwardill> (Or I'm doing it wrong)
<Chipaca> tomwardill: it does :-) how are you doing it?
<tomwardill> oh, I might have the wrong number in the wrong place
<tomwardill> one sec :)
<tomwardill> Chipaca: sorry, I was holding it wrong.
<Chipaca> tomwardill: https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537
<tomwardill> I had '9' rather than '7', because obviously a higher number is better...
<Chipaca> :-D
<cachio> mvo, https://paste.ubuntu.com/p/ztGGVFZsF6/
<cachio> mvo, this is the output, last line is stuck
<mvo> cachio: /o\
<mborzecki> cachio: is this what the stuck code is doing? http://paste.ubuntu.com/p/KpGxWdFfVJ/
<cachio> mborzecki, yes
<cachio> mborzecki, for i in $(seq 130); do echo $i && snap run --strace="-tt" test-snapd-tools.echo "hello-world"; done
<cachio> mborzecki, that was the line
<mborzecki> cachio: hmm, bad news, seems to run fine locally, with that script i had ~2k iterations before i killed it
<mborzecki> cachio: let me try that under spread
<cachio> mborzecki, I can generate a debug session on gce
<jdstrand> cjwatson: hey, so I've got this in my snapcraft.yaml (https://paste.ubuntu.com/p/kmCRMGGCkk/; note, I tried https://paste.ubuntu.com/p/WPSBFbbPhs/, but that didn't seem to work (didn't pull in gcc-multilib on either amd64 or arm64), but I digress)
<cjwatson> jdstrand: this is all up to snapcraft I'm afraid; LP has no say in that
<jdstrand> cjwatson: this successfully pulls in gcc-multilib on amd64 (good), but on arm64, it does not. it seems that gcc-multilib is gcc-multilib:armhf in the archive and the chroot in LP doesn't include armhf on arm64
<cjwatson> jdstrand: LP chroots have indeed never had cross-architecture config, and are unlikely to
<cjwatson> if snapcraft needs that then it has to set it up itself
<jdstrand> cjwatson: on amd64 gcc-multilib is in gcc-multilib:amd64, not gcc-multilib:i386
<jdstrand> in the archive
<jdstrand> so I'm a bit puzzled by either snapcraft, the chroot or the archive
<cjwatson> this is really just something we dispatch and let other tools deal with it.  I can only reiterate that nobody should be expecting the base image (chroot) to contain foreign-architecture config
<jdstrand> interesting
<jdstrand> so I'm just lucky that I could install gcc-multilib on amd64
<mup> PR snapd#6800 opened: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <https://github.com/snapcore/snapd/pull/6800>
<cjwatson> I guess ... I've only used that in very limited cases
<jdstrand> cjwatson: ok, thanks
<cjwatson> I think in general gcc's multilib config is supported in Ubuntu only where there's been a positive need for it
<cjwatson> I guess you'd need to talk to Matthias about that though
<jdstrand> cjwatson: in my 'sudo classic' chroot on arm64 device, installing gcc-multilib works great, but it has armhf configured. interesting, in trying to reproduce this I see:
<jdstrand> $ sudo dpkg --remove-architecture armhf
<jdstrand> dpkg: warning: cannot remove non-foreign architecture 'armhf'
<cjwatson> perhaps that's actually its native architecture; try dpkg --print-architecture
<jdstrand> $ dpkg --print-architecture
<jdstrand> arm64
<jdstrand> which is why I came to you. things aren't quite lined up in all the different places
<cjwatson> Uh.  Pass :)
<jdstrand> I can accept that classic chroot is wrong
<mborzecki> cachio: can reproduce that, somehow appears more often with --strace='-tt'
<cjwatson> You do also get that message if the architecture hasn't actually been added to dpkg as a foreign architecture (try "dpkg --print-foreign-architectures")
<jdstrand> but it seemed odd that gcc-multilib was in the amd64 part of he archive and not in arm64, but instead in armhf
<cjwatson> I suppose it could be that the classic environment just crowbarred that package in
<cjwatson> Well, that's entirely up to the gcc maintainers
<jdstrand> dpkg --print-foreign-architectures prints nothing. anyway, like I said, I'm fine to accept the classic chroot is setup wrong
<cachio> mborzecki, nice
<cjwatson> And classically multilib has required non-trivial per-architecture effort to maintain
<jdstrand> interesting
<jdstrand> ok, well, now I'll ask kyrofa and sergiusens how I can setup snapcraft.yaml so it adds armhf lines if I use gcc-multilib:armhf
<jdstrand> kyrofa, sergiusens: ^
<jdstrand> cjwatson: thanks
<cjwatson> np, I think that's likely to be the best path
<jdstrand> kyrofa, sergiusens: recall that on arm64 I have a makefile that will detect the SNAPCRAFT_ARCH_TRIPLET and decide if it should build some binaries with -m32. I can't use -m32 without gcc-multilib, but I can't install gcc-multilib on arm64 in LP because the chroot doesn't have cross build env by design (see above) and sources.list doesn't include armhf lines
<jdstrand> kyrofa, sergiusens: (this isn't an issue on amd64 since by chance, I only need amd64 configured to install gcc-multilib, but on arm64 I need gcc-multilib:armhf)
<jdstrand> kyrofa, sergiusens: if there is a path forward today, I'd like to use it, but since I've got amd64 working with -m32, I can skip this on arm64 if I need to
<jdstrand> kyrofa, sergiusens: as an aside, I thought this would (try to) install gcc-multilib on amd64 and arm64, but gcc was always installed: https://paste.ubuntu.com/p/WPSBFbbPhs/. I worked around it with this: https://paste.ubuntu.com/p/kmCRMGGCkk/
<mup> PR snapd#6791 closed:  overlord: update static attrs when reloading connections (2.39) <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6791>
<mborzecki> ps -ef | grep /sbin/strace shows that we're leaving some strace processes behind
<sergiusens> jdstrand: I don't think we support commas there, have you tried multiple "on" statements?
<sergiusens> I also don't think we ever tested the construct of having "on, else" statements with just plain packages listed, if that works, great I guess
<mup> PR snapd#6741 closed: osutil,cmdutil: move CommandFromCore and make it use the snapd snap (if available) <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6741>
<mup> PR snapd#6801 opened: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <https://github.com/snapcore/snapd/pull/6801>
<jdstrand> sergiusens: multiple on works fine. I read the docs on advanced grammar and they suggested that would work. that isn't the part I care most about though. its installing gcc-multilib:armhf on arm64 in LP:
<jdstrand> Could not find a required package in 'build-packages': gcc-multilib:armhf
<jdstrand> Build failed
<jdstrand> sergiusens: this is because the arm64 chroot in LP intentionally leaves out armhf. is there something I can do today to make this work in LP?
<jdstrand> sergiusens: (again, it's ok if there isn't, I'll just move on, but if there is, I'd like to do it)
<sergiusens> jdstrand: the "add ppa hack" from the forum could work by overriding the pull step and apt updating
<sergiusens> jdstrand: I think that now that we assume all environments where run are disposable, we can certainly "try" and enable the arch from our repo handler
<sergiusens> if you don't mind logging a bug, that would be great
<mvo> mborzecki: 6759 keeps on giving - now it fails in google:centos-7-64 .../tests/main/base-snaps#
<mvo> mborzecki: it seems to be a real issue
<mvo> mborzecki: I see that it fails to exec snap-exec - https://paste.ubuntu.com/p/BZ5VQY2cjK/
<jdstrand> sergiusens: do you use launchpad bugs or github issues?
<mborzecki> mvo: hmm
<mvo> mborzecki: which is strange as we did not change anything here
<mvo> mborzecki: I have a meeting now so can't dig deeper
<sergiusens> jdstrand: lp bugs, our issue tracker on github is closed
<jdstrand> ok
<sergiusens> that said, I have been looking into using github projects, need to convince mvo of something we can consolidate on
<mborzecki> mvo: fails only on centos and amzn2, /etc/os-release is not a symlink on either distro, wonder if that could cause something (and wouldn't explain why it happens only now)
<mvo> sergiusens: I would not mind using gh projects, I just did not investigate this much yet
<mvo> mborzecki: interessting
<mvo> mborzecki: I guess its related to us no longer using cgo in some interessting and yet mysterious way
<sergiusens> mvo let's discuss in Lyon... I really like the cross project functionality of LP bugs, but it misses all the nice features of things built around 2010, like a nice dashboard to manage milestones and such... and since our code is on github, auto closing issues becomes much easier
<jdstrand> sergiusens: ok, filed https://bugs.launchpad.net/snapcraft/+bug/1827067. let me know if you need anything else
<mvo> sergiusens: sounds good, lets sit together in lyon
<mup> Bug #1827067: need a way to add foreign architecture to sources.list for build-packages/stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1827067>
<mborzecki> mvo: snap-exec is not a static binary
<cachio> jamesh, hi, could you please take a look to this change 6541
<kyrofa> jdstrand, (cc sergiusens) regarding your last point first, we do support commas but the grammar enforces an AND relationship, not an OR
<cachio> #6541
<mup> PR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<kyrofa> e.g. `on amd64,ubuntu` or `on armhf,fedora`
<cachio> jamesh, any suggestions about how to improve that, still failing sporadically
<sergiusens> kyrofa: compressed nesting; I wish we had better syntax for that... I completely forgot about that scenario and assumed the opposite on first read
<mvo> mborzecki: its not? hm, how did that work in the past then - I mean, this test?
<kyrofa> sergiusens, maybe it SHOULD be... but yeah
<mborzecki> mvo: idk, everything seems to be in order
<mborzecki> mvo: /usr/lib/golang/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=tDnwG8u1pBmUWQO10qzA/_x6vj92SB3p958rhGThv/9RCsi
<mborzecki> VE8AphCR9FsbPHc/tDnwG8u1pBmUWQO10qzA -B 0x2b904b806d8f25f00e904ab996b99be6dc650588 -extldflags "-Wl,-z,relro  -static" -extld=gcc $WORK/b001/_pkg_.a
 * mvo weeps a bit in the corner
<mborzecki> mvo: -static seems to be passed to gcc/ld
<mvo> mborzecki: oh, so by not having gcc anymore we loose this? that makes sense
<mvo> mborzecki: now the question is how to pass -static to go without cgo
<mborzecki> mvo: CGO_ENABLED=0 basically :) but, ther's something fishy about that still
<Chipaca> pedronis: silly question about context (the go one), as i've seen opinions on both sides: would it be the right place to use to store the client's user-agent to then send it to the store? that was my plan way back before i read people saying context was evil or sth
<ogra> jdstrand, hmm, i think mvo added some code to fix alternatives in core itself in the past. perhaps the classic snap needs some adapting to that
<pedronis> Chipaca: in a meeting
<pedronis> Chipaca: I think the best use case is a layer talking to itself across others, but once context is around there be some other legitimate use cases
 * zyga lunch
<pedronis> or not too bad abuses
<pedronis> 2nd reviews of https://github.com/snapcore/snapd/pull/6731 would be appreciated
<mup> PR #6731: overlord: make the store context composably backed by separate backends for device asserts/info etc <Created by pedronis> <https://github.com/snapcore/snapd/pull/6731>
<mborzecki> mvo: CGO_ENABLED=0 or -buildmode=pie seems to trigger the right behavior, but the PIE build fails as centos glibc-statc was not built with -fPIC
<mborzecki> mvo: oh, and the same macro on fedora adds -buildmode pie
<mup> PR snapd#6802 opened: overlord/ifacestate: update static attributes of "content" interface <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6802>
<cachio> jamesh, hi
<cachio> jamesh, could you please take a look to #6541
<mup> PR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<mup> PR snapd#6803 opened: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803>
<Chipaca> pedronis: i'll review composable thing this evening if nobody else has gotten to it
<Chipaca> now i'm going for a run, i think
<jdstrand> kyrofa: that would explain while that wouldn't work there. it could never be true. thanks!
 * zyga makes more progress :)
<zyga> ltrace was the missing link towards visibilty of what was going on
<zyga> quick coffee break is deserved :)
<mvo> pedronis: 6778 is green and I addressed your points, let me know if I can do more
<pedronis> let me look
<pedronis> mvo: it looks fine, I don't know how likely those files are to change soon?
<mvo> pedronis: you mean the dbus ones? that is not likely but I was refering to the auto-install snapd when needed PR :)
<mup> PR snapd#6800 closed: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6800>
<pedronis> mvo: there is the the question about the signature of coreSnapInstalled and snapdSnapInstalled
<mvo> pedronis: if its considered important I can change it, the call side will become a bit more unwieldy - but happy to do that
<pedronis> mvo: I think it would be better to differentiate the errors
<mvo> pedronis: ok, I will update the code (after dinner)
<zyga> re
<zyga> Bike break
<pedronis> mvo: I fixed an annoying spread failure in my other PR, let me know if you want me to re-review something else today
<mvo> pedronis: 6778 should be ready in ~5min
<mvo> pedronis: but given that things will not be ready tonight anyway its fine to do all of this tomoorow
 * cachio afk
<mup> PR snapd#6804 opened: [RFC] store,daemon,client: allow user-agent setting for Search() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6804>
<mup> PR snapd#6805 opened: interfaces/docker-support: support overlayfs on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6805>
<mup> PR snapd#6806 opened: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806>
<mup> PR snapcraft#2545 opened: catkin plugin: use build-packages for compilers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2545>
<mup> PR snapcraft#2546 opened: [legacy] catkin plugin: ensure cxxflags are consistent <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2546>
#snappy 2019-05-01
<mup> PR snapd#6731 closed: overlord: make the store context composably backed by separate backends for device asserts/info etc <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6731>
<pedronis> there are also problems with the centos repos: https://api.travis-ci.org/v3/job/526762904/log.txt
<mup> PR snapd#6807 opened: tests:  reduce snapcraft leftovers from PROJECT_PATH,  temp disable centos <Created by pedronis> <https://github.com/snapcore/snapd/pull/6807>
<pedronis> Chipaca: hi, could you look at ^
<Chipaca> yes
<Chipaca> I should make a PR with just the cleanups from the invariant pr, until i can get the pr to pass fully
<Chipaca> pedronis_: why the convoluted logic of '! command -v snapcraft >/dev/null || snapcraft clean'?
<Chipaca> pedronis_: I suspect you didn't mean to write that :-| but if you did i'd like to understand why
<pedronis> Chipaca: #6803 looks reasonable, some lateral comments
<mup> PR #6803: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803>
<Chipaca> woo
<Chipaca> pedronis: thanks
<mup> PR snapd#6807 closed: tests:  reduce snapcraft leftovers from PROJECT_PATH,  temp disable centos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6807>
<pedronis> Chipaca: #6447 also needs/can be reviewed, a bit big
<mup> PR #6447: polkit: cast pid to uint32 to keep polkit happy for now <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6447>
<Chipaca> that's merged tho
<Chipaca> #6747 ?
<mup> PR #6747: many:  make access to the device model assertion etc contextual via a DeviceCtx hook/DeviceContext interface <Created by pedronis> <https://github.com/snapcore/snapd/pull/6747>
<pedronis> yes, sorry
<Chipaca> pedronis: bit of a cow to review, but, done! and, nice. thank you.
<pedronis> Chipaca: thank you
<Chipaca> pedronis: none of those nits are worth another spread run on their own, fwiw
<Chipaca> if you happen to do one, fine; otherwise i am content
<pedronis> Chipaca: let's see how it goes, anyway there's already an immediate follow up by mvo
<pedronis> that needs tweaks
<pedronis> so it could go there
<pedronis> Chipaca: we should try to land #6806
<mup> PR #6806: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806>
<Chipaca> i was wondering if that was the best approach
<Chipaca> probably fine for now tho
<Chipaca> but i'd rather ship static binaries than the whole of libc
<Chipaca> just for those two binaries i mean
<pedronis> Chipaca: I see, reasonable but is a larger change
<pedronis> atm snapd snap was breaking hard a bunch of spread tests
<pedronis> mvo had to revert it in edge
<pedronis> also a bit weird why the tests were using the snapd from edge
<pedronis> and not something built then
<mup> PR snapd#6806 closed: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6806>
<pedronis> Chipaca: is your thinking to have again a single Install later taking a struct?
<Chipaca> pedronis: yes
<pedronis> but is a big refactor
<Chipaca> exactly
<Chipaca> didn't want to do it as part of cohort work
<Chipaca> but it clearly needs to move to be that way
<pedronis> Chipaca: in that case either name is fine for the new helper
<pedronis> s/helper/taskset producing function/
<Chipaca> in fact i'd expect InstallPath to also get absorbed into the new thing
<Chipaca> at which point Try is probably on the chopping board too :-)
<Chipaca> we'll see (installpath does a bunch of stuff that needs dissecting at this point)
<pedronis> not sure it will be worth trying to merge back Path or Try
<pedronis> it might make things less readable actually
<pedronis> Chipaca: anyway I think it would be good to add some // TODO: merge back with Install taking a struct
<pedronis> explicitly though
<Chipaca> didn't i?
 * Chipaca thought he had
 * Chipaca checks
<Chipaca> / TODO: refactor things so there's a single install that takes a struct, mayeb a bit more like doInstall but public-er.
<pedronis> you did
<pedronis> but maybe s/install/Install/ there
<pedronis> actually s/install/Install again/
<pedronis> I read that commented and thought it meant that but wasn't super clear
<Chipaca> ok
<pedronis> s/commented/comment/
<Chipaca> pedronis: wrt leave-cohort, should I declare a special cohort that means 'leave' internally, or should i have a flag for it?
<Chipaca> on the fence on that
<pedronis> it will not be store in SnapState to be celar
<pedronis> it will remove what is there
<pedronis> s/celar/clear/ ...
<Chipaca> yes, it'd be in SnapSetup but not in SnapState
<Chipaca> in the client action structs, from there to snapInstruction, from there to SnapSetup
<pedronis> Chipaca: I fear on the API side a different flag seems better
<pedronis> Chipaca: unless we  go dinstihishgin  no cohort-key  vs cohort-key: null vs cohort-key: string
<pedronis> (which is doable but a bit annoying in go9
<Chipaca> ew
<Chipaca> leave-cohort: true seems weird tho :-)
<pedronis> cohort-key: "<leave>" is also weird
<Chipaca> yes, yes it is
<Chipaca> error: you can't leave a cohort, it's for life
<Chipaca> \o/
<pedronis> Chipaca: 6747 is green, so I'm going to merge it, and take care of you remark at the start of tweaking the follow up
<pedronis> *remarks
<Chipaca> pedronis: np
<Chipaca> pedronis: did you see what i meant about cohort-key + revision being ok in context?
<Chipaca> as opposed to in action
<pedronis> yes
<Chipaca> k
<mup> PR snapd#6747 closed: many:  make access to the device model assertion etc contextual via a DeviceCtx hook/DeviceContext interface <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6747>
<Chipaca> grmbl out-of-space errors
 * Chipaca lunch quick before standup
<pedronis> Chipaca: where, I thought I fixed some of those
<Chipaca> pedronis: in cross-compiling
<Chipaca> pedronis: merged master in case it was in that delta
<pedronis> Chipaca: I landed a fix for that, or so I hope
<pedronis> this morning
<mup> PR snapd#6808 opened: overlord: pass a DeviceContext to the CheckSnap implementations <Created by pedronis> <https://github.com/snapcore/snapd/pull/6808>
<pedronis> Chipaca: ^  it's small, follow up  to previous and adding deviceCtx arg to checkSnap, otoh the test changes maybe are too noisy, don't know
<Chipaca> pedronis: looks like a lot of the 'noise' is to pass an argument that isn't used?
<pedronis> Chipaca: it will be used, but I can simply merge this in the next one
<Chipaca> ah because. got it.
<pedronis> that one will be big(tm) though
<pedronis> if you prefer
<Chipaca> CheckSnapCallback
<pedronis> yes
<pedronis> but it would make mvo and my self harder
<Chipaca> nah it's fine
<Chipaca> also, TMI
<pedronis> because we are both working in different areas at intersection of this
<pedronis> oops
<pedronis> missing a life there
<Chipaca> :-)
<Chipaca> +1, looks good
<pedronis> Chipaca: standup?
<Chipaca> yep
<pedronis> Chipaca: seems bundling the libc in snapd didn't quite work, we get segfaults now, fun
<Chipaca> pedronis: segfaults are libc's way of telling you it loves you
<Chipaca> or was it that it hated you and wanted you dead
<Chipaca> one of those
<tooijar> If I run `snapcraft init` in folder B, then `snapcraft` in folder A no longer looks at folder A/snap. It builds from folder B.  I was expecting the snapcraft command to look for `snap/` in the current directory.
<tooijar> Is this expected?
<pedronis> Chipaca: I reverted snapd edge for now
<pedronis> and pinged mvo
<Chipaca> tooijar: wat
<Chipaca> pedronis: ack
<Chipaca> tooijar: what does running 'snapcraft init' in folder B have to do with running 'snapcraft' in folder A?
<tooijar> Chipaca: That's what I'm wondering. When I run snapcraft in folder A, it builds from the snapcraft.yaml in folder B (!)
<Chipaca> tooijar: are these two projects using base: <something>, and are they called the same?
<tooijar> Chipaca they're both using base: core18
<brlin> tooijar: Are you running these commands in a snap build environment?  Snapcraft handles directories quite differently in a build environment
<tooijar> Their name fields are different.
<tooijar> I'm running in Ubuntu 1804
<tooijar> Maybe cleanbuild will fix it?
<Chipaca> tooijar: could you pastebin the console output of running snapcraft in both directories?
<Chipaca> tooijar: it would be very interesting to get a way to reproduce this
<Chipaca> tooijar: if you are able to get those steps, file it in a bug please
<tooijar> https://pastebin.com/LpMdFWsf
<tooijar> The output is identical in both directories. Problem is the ./snap/snapcraft.yaml in directory A is not 'my-snap-name'
<tooijar> fixed with snapcraft clean && snapcraft build
<diddledan> tooijar: sounds like your "folder A" and "folder B" are named the same but in different locations?
<diddledan> if so it is expected that you'll get into a confused mess because the VM name is set to the folder name
<tooijar> diddledan: they're both different folders in my home directory
<tooijar> Of course the snapcraft.yaml is in a directory named "snap" in both folders.  And they're both set to use base: core18
<Chipaca> tooijar: how do we reproduce the issue?
<Chipaca> i've run multiple snapcrafts simultaneously before now and things work fine, so i'm puzzled
<Chipaca> tooijar: is one a subdirectory of the other?
<tooijar> Chipaca: I've corrected it now with snapcraft clean
<tooijar> no, they're both in ~
<tooijar> So ~/A and ~/B
<Chipaca> tooijar: did you copy one to the other?
<tooijar> no
<tooijar> I'll try to reproduce
<Chipaca> tooijar: ie did you 'snapcraft' and then copy the snap/ directory
<tooijar> Chipaca: no, but there are no hidden files in the snap folder. Why would copying break things?
<Chipaca> ah, that's right, the state is kept in the vm
 * Chipaca hates spread
<Chipaca> only worse thing than spread is everything else that tries to do the same thing it tries to do
<tooijar> Chipaca: Since running snapcraft clean I can't reproduce anymore.
<alan_g> jdstrand, could you clarify your seccomp denial question here? https://github.com/snapcore/snapd/pull/6790#discussion_r279408775 (I just need it explained to an idiot).
<mup> PR #6790: interfaces: add login-session-control interface <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/6790>
<jdstrand> alan_g: yes, I plan to go through that again today
<mup> PR snapcraft#2547 opened: [legacy] catkin spread test: allow python2 as well as python <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2547>
<alan_g> jdstrand, thanks. I don't know if this should be related, but you were mentioned: https://forum.snapcraft.io/t/installing-a-desktop-file-in-usr-share-wayland-sessions/11173
<jdstrand> that's another on my todo for today
<alan_g> \o/
<mup> PR snapd#6699 closed: daemon: add RootOnly flag to commands <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6699>
<tooijar> How can I install a library into a prime/ directory for faster testing?  I don't want to add to stage-packages and re-run snapcraft over and over until the last unmet dependencies is added.
<brlin> Simply copy them into it and run `snapcraft pack prime`
<kyrofa> tooijar, actually, modifying stage-packages and re-running is a good way to do it, but you may need to restructure your project ever so slightly. Does your snapcraft.yaml specify a `base`?
<tooijar> kyrofa: yes, base is core18
<tooijar> Reason I don't want to re-run is ...it just takes a long time.
<kyrofa> tooijar, I assume you have a part that takes a while to build, and you're adding the stage-packages to that part? Modifying the list means it needs to rebuild, yada yada
<kyrofa> tooijar, correct so far?
<tooijar> kyrofa: source-type is local so it's not building as in compiling / linking....but it does take a long time at "snapping test-snap". I'm not sure what it's doing that's taking so long.
<kyrofa> tooijar, that's creating the squashfs image out of the priming area. If you're creating a snap you'll always pay that cost regardless of how you choose to get the lib into the priming area
<tooijar> kyrofa: yeah, 'snapcraft pack prime' doesn't speed things up much
<tooijar> I guess I should find a better way of identifying all dependencies rather than just building / running and waiting to see what shared library error is thrown.
<kyrofa> tooijar, are you using multipass, then?
<tooijar> kyrofa: Not specifically by choice, but yes, I believe snapcraft is using multipass on my Ubuntu1804 machine.
<kyrofa> tooijar, how are you accessing the prime directory?
<tooijar> I had done `snapcraft try prime` and it put prime/ in my current directory
<tooijar> Then I just cd'd into it
<kyrofa> Ah! I didn't realize sergiusens had implemented that yet, very nice
<kyrofa> tooijar, so then, here's what you need to do
<kyrofa> Stop messing about with the prime directory, and stop running `snapcraft` with no args. Basically, stop creating a snap
<kyrofa> Alter the stage-packages as necessary, and run `snapcraft prime` only
<kyrofa> That will do everything EXCEPT create a snap
<kyrofa> Since you have `snapcraft try` already, all you need to do at that point is try running the app again
<kyrofa> The libs will be in prime
<pedronis> Chipaca: we have never used the internal package mechanism right, how do you feel about it?
<tooijar> kyrofa: that works, but because stage-packages has changed, it does a build, then stage, then prime when I run `snapcraft prime` so it's not much faster than just running snapcraft.  What I was hoping what that it could load the new libraries into the existing image, and be done. Without then having to build/stage/prime.
<tooijar> I just want to do the equivalent of `sudo apt install missing-lib` in the already built prime folder
<tooijar> Maybe I just need a better build machine.
<diddledan> dang, I missed the dockercon keynote
 * diddledan makes a note to watch that later
<brlin> tooijar: You can put the `stage-packages` entries under another fake part, in this case changing them won't clean the entire part's progress
<diddledan> hmm, come on travis-ci!!
 * diddledan pokenprod mit deine pokiestick
<tooijar> brlin: that sounds promising, thanks.
<diddledan> I'd recommend merging that fake part back into the part you're not wanting to rebuild once you have the right packages sorted so that it's obvious which part they really belong to :-)
<diddledan> but while you're working out what you need brlin 's idea is solid to prevent long waits
<tooijar> ok, thanks for the help folks.
<mup> PR snapd#6808 closed: overlord: pass a DeviceContext to the checkSnap implementations <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6808>
<Chipaca> pedronis: I wish we had used internal
<Chipaca> pedronis: I'd like to transition to it yesterday
<Chipaca> pedronis: failing that, tomorrow is ok
<Chipaca> pedronis: further I think some things are internal-internal, but dunno if go supports that or even if it's a good idea
<pedronis> Chipaca: ok, I have I use in current refactoring, actually a slightly strange use but seems to work
<Chipaca> pedronis: e.g. some things in *util only meant to be used from overlord
<Chipaca> pedronis: >shocked pikachu<
<Chipaca> pedronis: if it's "use internal because it has a side effect that the compiler does things in reverse order so things no longer segfault" then i'm against it
<Chipaca> pedronis: :-)
<Chipaca> but also ha-ha-but-seriously
<pedronis> Chipaca: no, is to have something that is exposed to tests via a *test package but otherwise not accesible except in its home package
<pedronis> the only other solution I could think of would need repeating the impl twice
<Chipaca> pedronis: what do we say to the god of repeating ourselves?
 * Chipaca came back from the gym more memetic than usual
<tooijar> Can someone clarify why "allow-sandbox" is defaulted to "false"?  "The allow-sandbox attribute may be used to give the necessary access to use the browserâs sandbox functionality."
<tooijar> Given that the browser sandbox is a security measure, shouldn't it default to true?
<Chipaca> tooijar: AIUI, it's because it weakens the snap's security, in exchange for trusting the browser to enforce it
<Chipaca> tooijar: jdstrand might be able to explain more, but that's my understanding
<Chipaca> tooijar: also see https://forum.snapcraft.io/t/sandboxing-with-the-browser-support-interface/1984/2
<Chipaca> degville: jdstrand: what happened to the "Note:" in that ^ topic, that is no longer in https://docs.snapcraft.io/the-browser-support-interface/7775 ?
<tooijar> Chipaca: Thanks for the link....this explains it well enough to satisfy my curiosity: "Since the browserâs internal sandbox requires a lot of privileged security policy rules to work, use of --allow-sandbox=true is limited to trusted publishers"
<Chipaca> tooijar: in other words, it needs manual review
<tooijar> Chipaca: Would be good to have that same explanation on the main docs here https://docs.snapcraft.io/the-browser-support-interface/7775
<Chipaca> tooijar: the funny thing is that that is a quote from the docs, hence my question to jdstrand & degville
<Chipaca> we've lost something in a cleanup somewhere
<degville> (looking)
<Chipaca> as they stand the docs don't say that allow-sandbox:true is privileged
<Chipaca> anyway, i need to go to the shops before they close
<Chipaca> ttfn, ttyl
<degville> Chipaca:see you! I'll look into the docs.
<jdstrand> Chipaca: that note never made it to https://forum.snapcraft.io/t/the-browser-support-interface/7775. I'll let degville decide how to incorporate it
<jdstrand> degville: if you do, feel free to drop the reference to oxide
<degville> jdstrand: thanks - not sure what happened, but I'll re-instate it now and drop the oxide reference.
<jdstrand> tooijar: Chipaca is right. the snap sandbox and the browser sandbox have different ideas about things. outside of snapd, the browser is considered trusted and may even have a setuid binary to setup its sandbox, or use kernel features like user namespaces that are well mediated with current LSM, seccomp, etc yet
<jdstrand> tooijar: within sanpd, allowing anyone to use that functionality without explicit permission means that snaps could abuse the system or break out of the sandbox
<jdstrand> tooijar: so allow-sandbox: true is reserved for major browsers from established publishers
<kenvandine> jdstrand: i got a USN email about the gtk-common-themes snap
<kenvandine> Revision r1198 (all; channels: stable)
<kenvandine>  * libpng16-16: 3962-1
<jdstrand> tooijar: your typical electron app gets plenty of security from the snapd sandbox, for example
<kenvandine> jdstrand: but that snap doesn't actually contain any libs
<jdstrand> tooijar: so allow-sandbox: false is fine for all of them
<tooijar> jdstrand: Thanks. That's even more helpful. Would be nice to have that level of explanation in https://docs.snapcraft.io/the-browser-support-interface/7775
<jdstrand> kenvandine: I'm guessing your manifest.yaml says something different
 * kenvandine looks
<jdstrand> tooijar: that is what degville is looking at fixing
<tooijar> jdstrand: My only concern is that chromium states that -no-sandbox is only for testing. That's from their point of view. Which is fine. But I wonder if they might one day decide that even for testing it shouldn't be used.
<tooijar> And then disable that option altogether.
<jdstrand> tooijar: sure. the chromium snap is allowed to use allow-sandbox: true
<kenvandine> jdstrand: so that's the installed packages at build time right?
<jdstrand> tooijar: so is brave
<jdstrand> kenvandine: yes. ie, what is in stage-packages
<jdstrand> kenvandine: you might 'organize' things away, but the tool doesn't know about all that
<kenvandine> sure
<kenvandine> ok
<kenvandine> for gtk-common-themes i can ignore these then :)
<jdstrand> kenvandine: you might spot check that someone didn't change the snapcraft.yaml, but sure, it is up to you to decide if you need to do anything
<kenvandine> i did
<jdstrand> this is but one reason of many why we don't do a report card on snaps or publishers
<kenvandine> and there are no libs at all in the installed snap
<kenvandine> which i confirmed
<jdstrand> kenvandine: yeah, I meant going forward if you get it, just double check someone didn't change it out from under your expectations
<kenvandine> will do
<mup> PR snapcraft#2548 opened: integration tests: use correct series in get_package_version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2548>
<jdstrand> roadmr: hey, I don't recall if you responded to my request to pull r1226
<roadmr> jdstrand: oh! I didn't :( r1225 was deployed yesterday. I'll put r1226 in the usual queue
<mup> PR snapd#6809 opened: snapcraft.yaml: fix links ld-linux-x86-64.so.2/ld64.so.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6809>
<jdstrand> roadmr: thanks! :)
<Chipaca> jdstrand: that's the *second* time I get to quote you as '<jdstrand> Chipaca is right'
<Chipaca> not that I'm keeping a tally or anything
<mup> PR snapd#6801 closed: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6801>
<jdstrand> Chipaca: \o/ :)
<jdstrand> roadmr: actually, I'm going to have an r1227 for a new override in a moment
<roadmr> jdstrand: oh! I haven't done r1226 because $reasons, so I might as well wait for that :)
<jdstrand> roadmr: ok, can you pull r1228* ? (I forgot r1227 had a new override from yesterday)
<roadmr> lol :)
<roadmr> sure
<mup> PR snapcraft#2549 opened: [legacy] integration tests: use correct series in get_package_version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2549>
<jdstrand> degville: curious, is the updating of https://docs.snapcraft.io/the-*-interface automatic from https://forum.snapcraft.io/t/the-*-interface? do you get a report and manually update?
<jdstrand> degville: there is no problem. I see that my recentish changes to the personal-files docs in the forum are represented in docs.snapcraft.io so was just curious
<degville> jdstrand: it's automatically updated. The delay is usually less than 5 mins.
<jdstrand> nice
<mup> PR snapd#6810 opened: many:  do without device state/assertions accessors based on state only outside of devicestate/tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6810>
<mup> PR snapcraft#2548 closed: integration tests: use correct series in get_package_version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2548>
<mup> PR snapcraft#2549 closed: [legacy] integration tests: use correct series in get_package_version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2549>
<mup> PR snapd#6811 opened: tests: make create-user test support managed devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6811>
#snappy 2019-05-02
<mup> PR snapcraft#2545 closed: catkin plugin: use build-packages for compilers <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2545>
<wadedy> Anyone have any experience with nextcloud on ubuntu server 18?
<mup> PR snapd#6809 closed: snapcraft.yaml: fix links ld-linux-x86-64.so.2/ld64.so.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6809>
<pedronis> mvo: morning
<mup> PR snapd#6812 opened: snapcraft: also include ld.so.conf from libc in the snapcraft.yml <Created by mvo5> <https://github.com/snapcore/snapd/pull/6812>
<pedronis> mvo: on the systems where we do repack_snapd we could also build with snapcraft, no ? are we just trying to avoid the double build?
<mvo> pedronis: we avoid the double build
<mvo> pedronis: its slow
<mvo> pedronis: like really slow
<mvo> pedronis: we could look into cheating somehow, i.e. build the snap from a binary deb
<pedronis> mvo: but the slow parts are probably not snapd, no? they are likely building the font cache stuff?
<pedronis> just installing the fc build deps takes forever
<mvo> pedronis: good point, I have no looked at what part takes how long. but that sounds plausible
<mvo> pedronis: another part of the problem is that for a realisitic test the snapd test has to be build in a 16.04 environment (gcc/toolchain etc). however then it needs to run on all distros
<mvo> pedronis: we could try with snapcraft cleanbuild or similar
<pedronis> mvo: so the build on LP takes 10 minutes (for amd64)
<pedronis> if I'm looking right: https://code.launchpad.net/~snappy-dev/+snap/snapd-master/+build/546252
<mvo> pedronis: yeah, the travis log tells a similar story, about 10min
<pedronis> also indeed we do build it anyway, in the snapd-snap test
<pedronis> mvo: our quick tests take 6 mins
<pedronis> mvo: there is some argument to be made that maybe it would make sense to build our most used deb and the snap in the quick phase
<pedronis> and then use it in the integration stage
<mvo> pedronis: yeah, that sounds very reasonable
<mvo> pedronis: we would have to have some external mechanism for the data sharing, I guess we can just GCE for this (?)
<mvo> pedronis: but I like this a lot, two jobs that build deb/snap and then pass it on to the integration stage
<pedronis> there are probably multiple options
<pedronis> also I think if we had a 16.04 prepared image with the right packages
<pedronis> that 10 minutes would go down a bit
 * mvo nods
<mvo> pedronis: I poked a bit, it looks like we need sergio and/or gustavo to setup a GCS bucket to upload the builds into but then this looks doable
<mvo> (a bit of work though)
<pedronis> mvo: yes, and yes it's some work
<pedronis> but the build can be run by spread I suppose
<pedronis> it's basically the snapd-snap test
<mvo> pedronis: indeed
<pedronis> plus putting the build somewhere
<pedronis> and using a dedicated system/image
<mvo> pedronis: this way we can optimize the build-deps and give it a machine with lots of horse-power(?)
<pedronis> don't know about the latter
<pedronis> but for sure we can have a build image
<pedronis> with more packages
<mvo> +1
<mvo> pedronis: this will be super nice because for 6 workers we don't need to build snapd 6 times anymore :)
 * mvo is a bit excited
<pedronis> heh
<pedronis> it's more complexity, so not so excited, but also the current approach is fragile, which is my main worry here
<mvo> yeah
<pedronis> I mean fragile in the sense that tests pass and shouldn't
<pedronis> mvo: I need to revert snapd edge again
<mvo> indeed, thats how I understood it
<mvo> pedronis: I thought I had done this already, if not I have it in my history
<pedronis> it gets build again
<mvo> pedronis: so can run it now
<pedronis> I have done it
<mvo> thanks
<pedronis> also I think the version you mention on TG were a bit off
<mvo> 6812 should *finally* fix it
<mvo> pedronis: oh? was I wrong there, sorry for that
<pedronis> one was from a different tag
<pedronis> I'm using the revisions for 2.38.1+git1331.gc314589
<pedronis> 3211-3216
<mvo> ta
<mup> PR snapd#6812 closed: snapcraft: also include ld.so.conf from libc in the snapcraft.yml <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6812>
<Chipaca> pedronis: got a question about 'snap refresh --list --cohort=xyzzy a_snap'
<pedronis> Chipaca: yes?
<Chipaca> pedronis: two things: one, that's doubly-specifying a thing (right?), and two, we don't even support 'snap refresh --list a_snap' today
<Chipaca> the a_snap will get quietly ignored and you'll get a list of everything
<pedronis> what is doubly specified?
<Chipaca> in fact, because for hysterical reasons 'snap refresh --list' is actually 'snap find --select=refresh', there isn't a good way to specify snaps to limit it to
<Chipaca> pedronis: because cohort implies snap name
<pedronis> Chipaca: it doesn't for us
<pedronis> nor for the store really
<pedronis> you need to send the name and the cohort
<pedronis> can't just send the cohort
<ackk> hi, is there a way to include a deb not from the archive in a snap, similarly to what stage-packages do?
<Chipaca> pedronis: sigh, ok. But still, there isn't a good way to send anything.
<Chipaca> pedronis: I could add client-side filtering to 'snap refresh --list'
<Chipaca> if that is what we want
<Chipaca> actually a_snap is not quietly ignored: you get 'error: --list does not accept additional arguments'
<pedronis> Chipaca:  to be quite frank I'm not sure why we though implementing snap refresh --list
<pedronis> as part of find
<pedronis> was a good idea
<Chipaca> pedronis: i totally agree
<Chipaca> i'd much rather it were dry-run, on the refresh endpoint
<pedronis> yea
<pedronis> so we can do that
<Chipaca> not as part of cohorts work though
<pedronis> (and maybe at some point deprecate the other thing)
<Chipaca> i'll leave this bit of wrk for after this refactor
<Chipaca> and move on with the rest
<pedronis> Chipaca: yes
<pedronis> we'll need to update the docs to say not yet implemented though
 * Chipaca hands pedronis the Red Seal of Not Implemented
<mvo> looks like the snapd snap is finally happy again for cmd.CommandFromSystemSnap (yay)
<degville> (I've just got to head out to vote in a local council election (thought I was registered for postal, but it appears not)).
<mvo> degville: thanks for letting us know
 * Chipaca agrees degville should avoid going postal
 * degville has been going postal for around 3 years now.
<Chipaca> oh dear
 * Chipaca LARTs pedronis 
 * Chipaca also LARTs github for not highlighting this
<pedronis> Chipaca: ?
<Chipaca> pedronis: commit message with lines that are â¦ dunno, 200+ chars long?
<Chipaca> 'git log' is now a mess
<Chipaca> 329 characters long
<Chipaca> wide i mean
<pedronis> that is a workflow problem on my side, so I should fix it, but hard
<Chipaca> pedronis: what'd be a good name for a struct with all options of snapstate.Update? going with snapstate.UpdateSpec as a strawman (it contains everything in current update args plus cohort, except state and user)
<Chipaca> Update explodes the test a lot less than Install does so i'm going with the refactor inline
<Chipaca> hmmm, otoh it explodes the helpers
<Chipaca> but that might be unavoidable
<Chipaca> hmm, hmm, hmm
 * Chipaca hmms more
 * Chipaca goes for coffee
<pedronis> Chipaca: not a big fan of Spec, but we use it elsewhere
<pedronis> so seems ok
<pedronis> Chipaca: in the client code the same thing is just called SnapOptions though fwiw
<Chipaca> pedronis: but that's because it's not update-specific (tho why not UpdateOptions)
<pedronis> Chipaca: yes, that was more my point, most of things are Options
<mup> PR snapd#6813 opened: data: update XDG_DATA_DIRS via the systemd environment.d mechanism too <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6813>
<Chipaca> yep, going with that
<Chipaca> hoping it doesn't explode in my face now :-)
<Chipaca> i need to take a break, go for a walk, and have lunch
<Chipaca> ttfn
<pedronis> Chipaca: mvo: will automatic snapshots be in 2.39 ?
<pedronis> or is it 2.40 ?
<Chipaca> pedronis: it's tagged 2.39
<Chipaca> pedronis: e.g. #6669
<mup> PR #6669: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6669>
<Chipaca> pedronis: there's some related PRs that weren't tagged 2.39 but they merged earlier than that one
<Chipaca> e.g. #6727
<mup> PR #6727: data/selinux: allow snapd to execute runuser under snappy_t <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6727>
<Chipaca> without that ^ snapshots on selinux are wonky
<pedronis> Chipaca: thanks, will try to understand more at the standup
<Chipaca> ok
<Chipaca> i might be a bit late for the standup, i need to pick up the dog from the vet and the timing is a little close
 * Chipaca â runch
 * Chipaca steals ideas from twom
<cmatsuoka> mvo: is https://github.com/snapcore/snapd/blob/master/parts/plugins/x_builddeb.py#L27 still working? I think we'll be able to drop that using base: core
<mup> PR snapcraft#2550 opened: storeapi: move from details (v1) to info (v2) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2550>
<sergiusens> cmatsuoka: what, the entire idea behind build-aux was to be able to drop that :-)
<cmatsuoka> sergiusens: yes, but currently snapcraft doesn't like build-aux/snap/plugins, mind if I fix that?
<cmatsuoka> (i.e. it gets snapcraft.yaml from build-aux/snap, but plugins are still loaded from snap/plugins)
<sergiusens> cmatsuoka: yes, please do
<cmatsuoka> okeydokey
<mvo> cmatsuoka: x-builddeb is still working
<wis> Hey, does the ubuntu core support wifi on RPI2, by adding wireless adapter interfaces of a wifi adapter?
<wis> how can I connect to wifi with a wifi adapter on Ubuntu Core on RPI2?
<Chipaca> wis: i'd ask ogra :-)
<ogra> wis, the kernel is the same as the one for classic ubuntu pi images, all wifi usb plugs that one supports are also supported by core
<mup> PR snapd#6814 opened: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) - 2.39 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6814>
<mup> PR snapd#6755 closed: overlord/snapstate: tweak autorefresh logic if network is not available <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6755>
<mup> PR snapd#6638 closed: interfaces: add support for the snapd snap in the dbus backend  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6638>
<mup> PR snapd#6802 closed: overlord/ifacestate: update static attributes of "content" interface <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6802>
<Chipaca> I was so, so wrong about a change to Update's arity breaking less tests
 * Chipaca perseveres
<mvo> Chipaca: while I wait for some spread run - did we agree to pass the user-agent via a context? I heard yes just wanted to double check
<Chipaca> mvo: I heard yes, in that it's not the ideal but it's ok
<Chipaca> but maybe pedronis can confirm
<Chipaca> (ideal is when it's the same layer stuffing and unpacking the values
<Chipaca> )
<mvo> Chipaca: excellent, I think that is what he said as well
<pedronis> they can be the same layer
<pedronis> it depends on details
<pedronis> :)
<Chipaca> pedronis: i think we're looking for a yes/no answer
<pedronis> it's possible, I'm still unclear where/who do make this contexts
<Chipaca> pedronis: this would be: daemon creates the context, stuffs it with a value for the ua, and then store.Find takes a context, and unstuffs the value
<pedronis> ok
<Chipaca> pedronis: alternative approach would be to add the ua to store.Search
<pedronis> it's not only for search
<pedronis> anyway atm only UpdateMany takes a context
<Chipaca> pedronis: in both cases, with a mind on this being the pattern we'd also use later from the sync bits of refresh/install/info/etc
<Chipaca> pedronis: yes it's not only search, search is just the first one
<Chipaca> (search also covers 'snap info' fwiw)
<wis> orga: I noticed that by ls ing the /lib/firmware and my device's firmware is there (ath9k_htc, Chipset: Atheros AR7010 & AR9287)
<Chipaca> mvo: ^ that means daemon's search hits store.Find and store.SnapInfo fwiw
<mvo> Chipaca: ok, I will look at the context then
 * mvo pokes hard at some tests first
<wis> orga: but it's not being listed by: $ nmcli d wifi list and $ ip a show's it's (wlan0)'s state is down
<pedronis> Chipaca: mvo: to be clear it will be the same layer talking to itself because we probably want a helper in store that takes a request and makes a context
<wis> I followed these docs: docs.ubuntu.com/core/en/stacks/network/network-manager/docs/configure-wifi-connections and wiki.debian.org/WiFi/HowToUse#WPA-PSK_and_WPA2-PSK
<mvo> pedronis: aha, that makes sense
<pedronis> store.UseContext(request (can be nil)) context.Context
<pedronis> or something like that
<ogra> wis, well, i never use NM on core ... you dont see the device inn console-conf ? (the UI that comes up on first boot and lets you set up the user and netwrok config)
<wis> orga, I did, and configured the wifi by selecting the ssid and entering the passhphrase (although I'm not sure if correctly because I did't see what I was typing carefully and there was no option to show the characters)
<ogra> well, then it should be properly set up already
<ogra> if you were able to advance to the user creation your network should be properly set up
<wis> it's connected to ethernet too
<ogra> console-conf uses the network connecion when creating the user ... so if that worked your wlan worked too
<wis> is there a way to redo the console-conf after first boot?
<ogra> ah, try to do the initial config without plugged in ethernet then
<wis> I'll need to reinstall to do that?
<ogra> you can try "sudo console-conf" when logged in via ssh ... but be aware that it does not allow you to ctrl-C it, you can not get out anymore if you do not finish it properly
<wis> okay I'll do it over ssh and If it fails I don't mind reinstalling at this point.
<ogra> and indeed if you ssh you can not easily cancel the ethernet ... since you need to use it ... the easier alternative is surely a re-install
<ogra> after all re-installing core is pretty quick
<wis> oh right.. I need ethernet for ssh
<Chipaca> wis: or you could use serial
<ogra> in any case, if you see a wlan0 device during console-conf your wlan should theoretically work.., at least from the kernel/driver side
<ogra> if you want to use serial, make sure to set a password for the user .. do: "sudo passwd $USER" to set one (and use the $USER variable there)
<ogra> else you wont get a login prompt ... local consoles are only enabled if a password exists
<ogra> (and serial is considered a local console)
<wis> it looks like serial requires a USB to serial adapter which I don't have, so i'll just reinstall.
<Chipaca> wis: keyboard and screen? :-)
<Chipaca> wis: or just reinstall :-)
<wis> same way I did it the first time, flash sd card, plug keyboard, hdmi and boot, only with ethernet disconnected, .. and more careful typing.
<wis> :D
<mup> PR snapd#6778 closed: snapstate: auto-install snapd when needed <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6778>
<wis> I can't enter a forward slash (/) in the subnet mask field, only numbers and dots, despite requiring it in CIDR format
 * cachio lunch
<wis> the good news is that with ethernet disconnected my routers SSID displayed and I selected it, that means the wifi adapter is working.
<ogra> yup, it should ... you will definitely know it if your user creation worked
<ogra> the forward slash is probably a bug with console-conf input filtering (most people simply use DHCP and dont fiddle with the netmasks, so it is likely that nobody did hit that issue yet)
<wis> good to know that I helped find a bug, I'll use dhcp for now and do a nmap scan to find the RPi's ip each time it changes, to be able to ssh
<wis> on a second though I think I can just use the raspberry.local hostname
<mup> PR snapd#6815 opened: snapstate: auto-install snapd when needed (2.39) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6815>
<Chipaca> pedronis: i'm going to push the updates pr, which is nominally done, but i haven't gone over it to make sure it doesn't have any think'os
<Chipaca> so quality might be iffy
<Chipaca> but, maybe it's fine :-D
<Chipaca> and then, *then*, I'm going to EOW
<Chipaca> like a BOSS
<Chipaca> pedronis: vvv
<mup> PR snapd#6816 opened: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>
 * Chipaca soft-EODs, getting ready to leave but still paying some attention to IRC
<wis> wohoo, ping cern.org returns results with ethernet disconnected. Linux always surprises for good with out-of-box drivers.
<wis> although the default (non-cloudflare) dns was concerningly slow
<mup> PR snapd#6817 opened: overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/6817>
<pedronis> mvo: ^
<wis> after reinstalling and installing snap available memory is 770MB. I know that core is a stripped down server. how does the baseline memory consumption compare?
<wis> installing htop*
<Chipaca> pedronis: I'm off, see you wednesday!
<Chipaca> pedronis: (but telegram in emergencies)
<pedronis> Chipaca: bye, have fun
<jdstrand> mvo: hey, so, I'm not done testing yet (it has so far been going fine), but libseccomp 2.4 has a performance regression: https://github.com/seccomp/libseccomp/issues/153
<jdstrand> mvo: 'real0m0.083s' with 2.38 template policy and 2.3.1 vs 'real0m0.242s' with 2.38 policy and 2.4.1
<mvo> jdstrand: uh, that will make a difference I suppose, snap debug timings should give us some data here
<jdstrand> mvo: I mention this as an fyi since the security team plans to push libseccomp 2.4.1 out to fix the CVE and bad bpf generation anyway
<jdstrand> mvo: ie, even if you skip it now and forego the daemon user feature, you'd get it in your next sru
<jdstrand> mvo: that said, people seem keen to fix it, so we could always sru those changes when they mature
<mvo> jdstrand: ok
 * mvo needs to get some dinner 
<jdstrand> mvo: enjoy :)
<mup> PR snapd#6818 opened: snapshotstate: disable automatic snapshots on core for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/6818>
<mup> PR snapcraft#2547 closed: [legacy] catkin spread test: allow python2 as well as python <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2547>
 * cachio afk
<cmatsuoka> niemeyer: hi, any news on the extension review?
<niemeyer> cmatsuoka: Sorry, got distracted elsewhere.. I'll get to it first thing in the morning tomorrow
<cmatsuoka> niemeyer: thanks! sorry for being annoying about that, but it's in our plans for lyon to have these properly merged :)
<niemeyer> cmatsuoka: Not annoying at all.. I apologize as I should have done it earlier in the week
<mup> PR snapcraft#2546 closed: [legacy] catkin plugin: ensure cxxflags are consistent <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2546>
#snappy 2019-05-03
<mup> PR snapcraft#2550 closed: storeapi: move from details (v1) to info (v2) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2550>
<mvo> I need a review for the 2.39 PRs
<pedronis> mvo: I double-checked quickly and approved the backports
<pedronis> and hi
<mvo> pedronis: thanks! and good morning :)
<mup> PR snapd#6814 closed: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) - 2.39 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6814>
<mup> PR snapd#6815 closed: snapstate: auto-install snapd when needed (2.39) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6815>
<mup> PR snapd#6818 closed: snapshotstate: disable automatic snapshots on core for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6818>
<mvo> pedronis: good news, all PRs for 2.39 are in, there is a travis failure right now that I'm looking at though, not sure if its a fluke or not
<pedronis> ok
<mvo> pedronis: do you think 6810 can go in with just one review? its mostly shuffling things around so it seems that is ok(?)
<pedronis> mvo: I suppose so, a bit your call, it would be good if somebody outside of us was aware of the change
<mvo> pedronis: yeah, that pushes it to monday but thats ok I think
<pedronis> I probably will have 3 more PRs today, getting quite close to the core of rereg, and also to your code/PRs
<mvo> pedronis: great
<mvo> pedronis: my afternoon will be full of meetings
<mvo> pedronis: but I hope to spent the morning in a productive way
 * mvo looks at one build failure in sbuild though
<pedronis> yea, I'll try also do some reviewing but yes, most of the meetings I'm also there
 * mvo nods
<pedronis> mvo: it would also be good to land your Remodel PRs because I probably need to touch that code a bit as well soon
<pedronis> but probably Monday at this point
<mvo> pedronis: yeah, they need reviews
<pedronis> mvo: also, for next week but I was reminded that we need undo tests for remodeling and that's there a bug related to queueCommand (using service commands from configure hooks) that affects seeding but will also affects more annyoingly remodel
<mvo> pedronis: hrm, that sounds annoying
<pedronis> mvo: slightly rare, but yes annoying, still need to think out to fix it
<mup> PR snapd#6819 opened: osutil: fix TestReadBuildGo test in sbuild <Created by mvo5> <https://github.com/snapcore/snapd/pull/6819>
<pedronis> mvo: the issue is that as it is queueCommand puts stuff after mark-seeded, and now set-model
<pedronis> which relates to lanes and undo and how we use them or not
<pedronis> as well
<pedronis> bit of a tangle
<mup> PR snapd#6820 opened: snap-confine: improve error when running on a not /home homedir <Created by mvo5> <https://github.com/snapcore/snapd/pull/6820>
<pedronis> mvo: let me know when you have the new changelog for 2.39 since pre1
<mup> PR snapd#6821 opened: many: make which store to use contextual  <Created by pedronis> <https://github.com/snapcore/snapd/pull/6821>
<mvo> pedronis: mailed it to you
<pedronis> thx, opening one more PR and then will look at it
<mvo> pedronis: ok, I prepare the release but will wait for you with this then
<mvo> pedronis: test building in the ppa now to ensure we have no build failures in sbuild
<pedronis> mvo: looks as expected but aren't we missing the PR by maciej about runuser and selinux and snapshots?
<pedronis> mvo: https://github.com/snapcore/snapd/pull/6748
<mup> PR #6748: data/selinux: tweak the policy for runuser and s-c, interpret audit entries <SELinux> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6748>
<pedronis> or is the changelong missing some bits
<pedronis> it was tagged 2.39
<pedronis> mvo: mmh, same question about #6802
<pedronis> mvo: did we forget some backports?
<mup> PR #6802: overlord/ifacestate: update static attributes of "content" interface <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6802>
<mvo> pedronis: let me double check
<mvo> pedronis: 6802 is in (unless I miss something), b2c4893 is there in 2.39
<mvo> pedronis: but the selinux is missing, thanks for this one
<pedronis> mvo: it's interesting that 6802 is not in the changelog
<pedronis> are we dropping some stuff?
<pedronis> but yes, I see it in the branch
<mvo> pedronis: maybe a bug in the script, let me debug
<mup> PR snapd#6822 opened: overlord/devicestate: introduce registrationContext <Created by pedronis> <https://github.com/snapcore/snapd/pull/6822>
<mvo> pedronis: found the issue, the commit is malformated, we usually have pattern: "cmd,snapd: what changed"
<mvo> pedronis: this one is missing that
<mvo> pedronis: I will add it manually and think a bit more about if the script should warn about those
<pedronis> mvo: the PR looked right https://github.com/snapcore/snapd/pull/6802 so it was are intefact of merging or the backport
<mup> PR #6802: overlord/ifacestate: update static attributes of "content" interface <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6802>
<mvo> pedronis: oh, indeed
<niemeyer> cmatsuoka: Review is in.. just a couple of last points
<mvo> pedronis: I updated the changelog manually now and once travis is green I will upload and push to beta
<mup> PR snapd#6823 opened: [RFC] packaging: build empty package on powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/6823>
<mvo> pedronis: we *may* want 6823 for 2.39, I will try to get opinions from foundations
<mvo> pedronis: it will mostly make their processes easier as all arches will have packages
 * mvo gets lunch first
<pedronis> mvo: happy to do what they prefer there
<mvo> pedronis: yeah, I had the impression this is good for them but its a hack so I want to confirm first
<cmatsuoka> niemeyer: thanks!
<pedronis> mvo: I did a bit of reviewing
<mup> PR snapcraft#2542 closed: meta: Validate common ID against appstream metadata <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2542>
<petan> how can I reset release number back to ^ ?
<petan> I changed candidate and beta in past to certain number, I don't want that anymore, I want them to fall back to release number as they do by default
<petan> but no idea how to reset it back to original state
<pedronis> petan: maybe you mean  "snapcraft close candidate beta",  after that they will follow stable
<pedronis> sorry "snapcraft close <snap-name>..."
<mup> PR snapd#6824 opened: release: 2.39 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6824>
<mup> PR snapcraft#2551 opened: project: read local plugins from build-aux <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2551>
 * cachio afk
<mvo> kenvandine: beta has the fix now (version is still 2.39~rc1 but will become 2.39 in some minutes)
<kenvandine> mvo: thanks
<mvo> cachio: core 2.39 is in the beta channel now
<cachio> mvo, starting validation
<cachio> thanks
<mvo> cachio: thank you!
<mup> PR snapcraft#2552 opened: release: 3.4.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2552>
<clobrano> hi! I have some problems installing snapcraft for development after upgrade to 19.04, specifically installing python-apt I got a huge error message https://paste.ubuntu.com/p/tjQM3HJrrg/
<clobrano> I meant, installing snapcraft dependencies
<kenvandine> mvo: confirmed it seems to fix the issue, thanks!
<sergiusens> clobrano: you need to develop inside a 16.04 environment, easiest way is to "lxc launch ubuntu:16.04" and setup in there
<sergiusens> you would be using the incorrect python version if not
<mvo> kenvandine: \o/
<mvo> kenvandine: thanks for double checking
<nemosupremo> Hi, I'm trying to understand the process of building ubuntu-core images. Some of the software I need on the image can't be packaged into a snap, as well as I want to copy some configuration files directly on the device itself. Is there a way I can run a shell script before the image is created?
<cachio> mvo, changelog was not generated here https://people.canonical.com/~mvo/core-changes/html/beta/
<mvo> cachio: looking
<mvo> cachio: should be good now
<cachio> mvo, thanks
<clobrano> sergiusens: oh, I missed this important info :D, thanks!
<jdstrand> niemeyer: hey, fyi https://github.com/snapcore/snapd/pull/6681#issuecomment-489150666
<mup> PR #6681: many: support system-users for 'daemon' user <Complex> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
<jdstrand> joeubuntu: fyi, mvo changed ^ that to be in 2.40, not 2.39, so it is officially out for sprint
<jdstrand> mvo: since you did that, there is no rush in getting libseccomp 2.4.1 in core/core18 or snapd
<joeubuntu> thanks for the heads up jdstrand
<jdstrand> testing is so far good with 2.4.1, we'll likely have it in a security update sometime after the sprint
<jdstrand> at which point, the core, core18 and snapd snaps will just have it
<mvo> jdstrand: yeah, sorry, this one was a tough call
<jdstrand> mvo: np. that feature was plaugued with difficulty. I'm surprised we are as far along as we are :)
<jdstrand> mvo: so many steps back before we could be where we are today
<joeubuntu> mvo jdstrand I'd rather do it right then rush it and introduce an error.
<wis> ogra, is there a way for core to connect a different wifi network other than the console-conf(igured) one on first boot?
<wis> I am following the docs.ubuntu.com/core/en/stacks/network/network-manager/docs/configure-wifi-connections
<wis> nmcli r wifi on is not listing the WiFi network i'm connected to
<wis> `nmcli d wifi list` * I meant to paste ^
<tooijar> Do 'prepare' and 'install' properties work as described here https://docs.snapcraft.io/snapcraft-parts-metadata
<tooijar> I'm getting "Additional properties are not allowed"
<mup> PR snapcraft#2553 opened: ci: use --destructive-mode to build snap in travis <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2553>
<mup> PR snapd#6641 closed: snap-gdb-shim: switch to the SUDO_UID when available <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6641>
<mup> PR snapd#6825 opened: cmd: rework `snap run --gdb` to work as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/6825>
<mup> PR snapd#6826 opened: tests: enable tests on centos 7 again <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6826>
<mup> PR snapcraft#2554 opened: release: 3.4.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2554>
<om26er> Hi! Are there instructions somewhere on how to build a snap on Travis ?
<om26er> I found these instruction https://docs.travis-ci.com/user/deployment/snaps/ but they seem to be for deploy only
<tooijar> To answer my own question, for anyone who might be curious..."prepare" and "install" do NOT work as described at https://docs.snapcraft.io/snapcraft-parts-metadata
<tooijar> They are deprecated https://docs.snapcraft.io/t/deprecation-notices/8396
<tooijar> I submitted a request for docs update https://forum.snapcraft.io/t/snapcraft-parts-metadata/8336/6
<AlexPortable> Can someone help me creating a wine snap?
<AlexPortable> https://github.com/mmtrt/wine-platform
<AlexPortable> I currently found this, but how do I merge my wine installation with this snap?
<AlexPortable> and how can i set a weekly refresh for my snaps?
<mup> PR snapd#6827 opened: tests: fix "Placeholer" is a misspelling of "Placeholder" issue <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6827>
<zyga> AlexPortable: hey, please come back on Monday for more help but you can probably find examples on the forum. Look for snap set core refresh.schedule please.
<AlexPortable> what is the difference between system refresh.timer and core refresh.schedule ?
<luke-jr> How do I get snapcraft installed without a 4.4 kernel?
<luke-jr> ugh, and it wants root too?
#snappy 2019-05-04
 * luke-jr gives up on snaps for now
<AlexPortable> How do I solve launch failed: CPU does not support KVM extensions
<mup> PR snapd#6827 closed: packaging: fix changelog typo <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6827>
<mup> PR snapd#6828 opened: many: use a fake assertion model in the device contexts for tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828>
<mup> PR snapd#6829 opened: devicestate: use deviceCtx in checkGadgetOrKernel <Created by pedronis> <https://github.com/snapcore/snapd/pull/6829>
<antis> Hey, has anyone experience with building snaps on manjaro? I read on the documentation (https://docs.snapcraft.io/build-on-docker) and wonder if the "Multipass" works (better?)â¦
<tooijar> Is there an easy way to get X11 connectivity for a service running as a daemon? I'm starting my app as a daemon but the logs are showing Unable to open X display.
<tooijar> I have app.environment.DISPLAY=":0"
<brlin> antis: Currently only Multipass is fully supported AFAICT
<zyga> tooijar: hey, it's in general hard-ish
<zyga> tooijar: in a portable way, that is
<tooijar> zyga: what about a non-portable way :)    Even just Ubuntu1804 LTS would be nice for now.
<ogra> tooijar, thats trivial ... you need to use mir-kiosk and can then use XWayland on top of it
<ogra> well ... FSVO "trivial" :)
<ogra> tooijar, not sure how outdated this is (some things might have changed since it was published) https://tutorials.ubuntu.com/tutorial/x11-kiosk#0
<tooijar> Seems like a permission problem because after 'xhost +' it started up just fine
<ogra> note though that the combination of X11 and "daemon" will make your snap get stuck in manual review when uploading to the store ... it needs one initial approval typically
<tooijar> ogra: thanks...maybe I can just go with a desktop file that has autostart in it.
<tooijar> ogra: Perhaps you could clarify....if I end up using mir-kiosk (which as far as I understand adds additional security since it isn't traditional X) would I still need manual review with the daemon option?
<mup> PR snapcraft#2554 closed: release: 3.4.1 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2554>
<mup> PR snapcraft#2553 closed: ci: use --destructive-mode to build snap in travis <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2553>
#snappy 2019-05-05
<mup> PR snapcraft#2552 closed: release: 3.4.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2552>
<fastfresh> How do I pass environment variables to snap package? I need to run vscode snap with some additional PATH paths
#snappy 2020-04-27
<mborzecki> morning
<zyga> mborzecki: good morning
<mborzecki> zyga: hey
<mborzecki> deconflicted https://github.com/snapcore/snapd/pull/8464
<mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<mborzecki> otherwise out doing errands, i'll be back for sprint meetings
<mborzecki> oh and install/re(install)/recover worked with pc_98.snapm, pc-kernel_473.snap and snapd from edge
<zyga> Good luck and see you later mborzecki
<pstolowski> morning
<zyga> hey pawel
<zyga> this will be a quiet morning
<pstolowski> yep
<mup> PR snapd#8436 closed: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <â Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8436>
<mup> PR snapd#8436 opened: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <â Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
<zyga> pedronis: good morning
<zyga> pedronis: I will write the details of the inhibit lock idea and share the link with you
<pedronis> ok
<mup> PR snapd#8562 opened: store: implement DownloadAssertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/8562>
<zyga> pedronis: https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/33
 * zyga AFK for some time
<zyga> actually no
<zyga> store is still responding with 429 - too many requests - sometimes
<mup> PR snapd#8563 opened: asserts/internal: introduce Grouping and Groupings <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8563>
<mup> PR snapd#8564 opened: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8564>
<pedronis> lots of red again afaict
<mvo> pedronis: do you have an example of a recent run with reds?
<mvo> pedronis: what PR should I look at?
<pedronis> mvo: here for example: https://github.com/snapcore/snapd/pull/8436  I suppose it's the store but haven't looked at the logs
<mup> PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <â Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
<mvo> pedronis: yeah, anything that fetches core runs into timeouts it seems
<zyga> I saw store returning errors
<zyga> 429
<mup> PR snapd#8565 opened: osutil: expand FileLock to support shared locks and more <Created by zyga> <https://github.com/snapcore/snapd/pull/8565>
<mborzecki> re (kind of)
<mborzecki> mvo: pedronis: any high priority 2.45 PRs that need reviews/fixes?
<mup> PR snapd#8566 opened: cmd/cmdutil: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<pstolowski> sil2100: hey! do you have a moment to take a look at https://github.com/snapcore/core-build/pull/59 ?
<mup> PR core-build#59: initramfs: add new handle_writable_defaults() <Created by mvo5> <https://github.com/snapcore/core-build/pull/59>
<sil2100> pstolowski: hey! Is this the same as for core20?
<pstolowski> sil2100: no, core20 is separate (https://github.com/snapcore/core20/pull/46, which you commented on)
<mup> PR core20#46: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>
<mup> PR snapd#8567 opened: o/devicestate: core20 early config from gadget defaults <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<sil2100> pstolowski: yeah, I guess I'll have the same weird question here, since the code is the same - can someone explain the meaning of the -L check in that particular conditional?
<mvo> sil2100: I replied in the PR, this is to ensure that broken symlinks will still get created
<mvo> sil2100: as -e will follow the symlink target and return false if there is a symlink but it point's to the void
<mvo> sil2100: hence we need -L in addition, there is a "unit" test for this as well
<mup> PR core#112 opened: Fix English in comment around usage of spellcheck <Created by ykoehler> <https://github.com/snapcore/core/pull/112>
<mup> PR snapd#8568 opened: asserts: rest of the Pool API <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8568>
<mup> PR snapd#8569 opened: o/assertstate,asserts: use bulk refresh to refresh snap-declartions <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
<mup> PR core#112 closed: Fix English in comment around usage of spellcheck <Created by ykoehler> <Merged by mvo5> <https://github.com/snapcore/core/pull/112>
<ijohnson> zyga: is there no SU today?
<zyga> hey
<zyga> I don't think so
<zyga> but we can meet if you have something to share
<zyga> pstolowski: ^ ?
<zyga> I have some cool stuff
<ijohnson> my update is just UC20 UC20 UC20
<zyga> https://meet.google.com/rni-xhsz-uqt
<zyga> :)
<pstolowski> zyga: ijohnson hi, i'm in the opening plenary
<zyga> pstolowski: can you share the link in private?
<pstolowski> perhaps when it's over?
<zyga> ijohnson: join and I can share some fun stuff
<ijohnson> sure
<pstolowski> zyga: i can, it's from the calendar you gave me in the morning ;)
<mup> PR snapd#8570 opened: many: allow using ~/.snapdata instead of ~/snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8570>
<Gargoyle> Is it necessary for every snap app to spam the journal with these messages:- Apr 27 14:11:21 zion2 audit[359771]: AVC apparmor="DENIED" operation="connect" profile="snap.mysql-workbench-community.mysql-workbench-community" name="/run/uuidd/request" pid=359771 comm="mysql-workbench" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
<mborzecki> Gargoyle: thanks for reproting, afaik access to /run/uuidd/request was part of one specific interface, but since 2.45 (to be released soon) is aprt of the base template
<Gargoyle> Seems every snap I've installed (clean install of 20.04 a few days ago) is reporting the same message over and over.
<ogra> the next snapd update will fix this as mborzecki said ...
<pstolowski> zyga, ijohnson standup?
<ijohnson> pstolowski: we are in zyga link above
<Gargoyle> Ahh. OK
<mborzecki> Gargoyle: yeah, seems like a popular way to obtain uuids (idk why /proc/sys/kernel/random/uuid isn't as popular and does not require a separate daemon)
<zyga> pstolowski: can you join?
<pstolowski> ijohnson, zyga 4 people are in regular standup HO
<zyga> oh
<zyga> I didn't get the link
<ogra> you guys are entertaining today !
<cmatsuoka> ijohnson, pstolowski, cachio: I just ran another test here and it works well before the refresh, but it fails at the-tool in the post-refresh boot
<cmatsuoka> I'll try it non-encrypted to be able to see what's going on
<ijohnson> cmatsuoka: I assume that's with edge everything and remastered kernel snap ?
<cmatsuoka> ijohnson: it's core20 602, gadget 96, remastered kernel 470
<cmatsuoka> ijohnson: did something important change in core20 or gadget?
<cmatsuoka> I mean, core20 or kernel?
<ijohnson> well the kernel was revved over the weekend, I see rev 473 on edge now
<cachio> cmatsuoka, here it is still running
 * cmatsuoka updates kernel
 * zyga -> lunch
<pstolowski> cmatsuoka: what about nested/basic core20 test? does it work
<cachio> pstolowski, I am running these tests now
<cachio> I'll tell you
<pstolowski> cachio: ok, ty
<cachio> pstolowski, I'll let you know
<cmatsuoka> store is very, very slow right now
<cachio> last run I got kill timeout downloing the kernel snap
<zyga> re
<zyga> cmatsuoka: yes, painfully slow :/
<mborzecki> release effect stilll?
<zyga> mborzecki: compound effect, more than one issue
<zyga> I've updated https://github.com/snapcore/snapd/pull/8570 with some more expectations
<mup> PR #8570: many: allow using ~/.snapdata instead of ~/snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8570>
<cmatsuoka> ijohnson: apparently the problem was caused by a local change that I thought it would be totally harmless
<ijohnson> cmatsuoka: good to know, what was the change?
<cmatsuoka> ijohnson: experimentations moving the snap-bootstrap bootstrap and partition packages to gadget
<ijohnson> ah I see
<pedronis> cmatsuoka: that needs a bit of design btw, it's not just mechanical
<pedronis> there is some semi-duplication between bits of gadget and partition
<pedronis> that is not super clear what to do about
<cmatsuoka> pedronis: yes, I noticed that it wouldn't be a simple move
<pedronis> cmatsuoka: maybe you can have a chat with mborzecki, he might have input on that
<pedronis> there's an unclear relation between the bits that existed for snap-image
<pedronis> and the stuff for snap-bootstrap
<cmatsuoka> pedronis: the other thing I was going to examine was to integrate the new helpers from secboot
<cmatsuoka> pedronis: perhaps that would be a more productive thing to do right now?
<pedronis> cmatsuoka: it might be easier,  if you look at that my comments on the measure model PRs, there are a couple of helper in snap-boostrap
<pedronis> that belong in secboot I think
<pedronis> cmatsuoka: a question is a bit whether we want them as functions or we want some kind of wrapper around a tpm connection
<pedronis> that can be set up even if there's no tpm
<cmatsuoka> pedronis: I'll have a look
<pedronis> but then the functionaliy/some functionality becomes NOPs
<cachio> pstolowski, tests are failing
<cachio> pstolowski, can't validate the fix
<pstolowski> cachio: kill timeouts? or store?
<cachio> pstolowski, the store
<cachio> getting kill timeout but downloading snaps
<ijohnson> cachio: downloading snaps for me is incredibly slow right now
<roadmr> having slow snap downloads? kill it then restart. Also wait a bit, things are being tweaked right now
<ijohnson> roadmr: I've killed it at least 5 times now and keep getting 503s eventually
<roadmr> then please wait a bit, things are being tweaked right now :)
<ijohnson> sure
<cachio> ijohnson, yes
<cachio> ijohnson, it is making all the tests fail
<zyga> is anyone upgrading to groovy yet?
<ijohnson> hah
<ijohnson> a
<zyga> that's it, I'm moving to groovy ;)
<roadmr> the name conflicting with groovy is slightly unfortunate heh
<roadmr> "why do you move to groovy! it's java deep down inside,argh"
<roadmr> cachio, ijohnson : are things  happier for you folks now?
<ijohnson> roadmr: let me check now
<cachio> roadmr, running tests, I'll let you know in few minutes
<cachio> roadmr, thanks
<roadmr> well "snap download whatever" and if it doesn't 503 or be dog-slow then you're ok :)
<ijohnson> roadmr: much much much much much much much better now
<ijohnson> thank you!
<roadmr> I did nothing :)
<ijohnson> (and the whole snapstore team in general too :-) )
<roadmr> thanks !
<cachio> roadmr, seems to be working much better now
<roadmr> thanks for confirming cachio :)
<zyga> degville: hey, not sure if you look at github notifications
<zyga> degville: I've opened a small PR with two paragraphs of text
<zyga> degville: I think the text I've used is terrible and I need some help
<zyga> https://github.com/snapcore/snapd/pull/8571
<mup> PR #8571: overlord/snapstate: warn of refresh/postpone events <Created by zyga> <https://github.com/snapcore/snapd/pull/8571>
<zyga> the text is right up front in the diff
<mup> PR snapd#8571 opened: overlord/snapstate: warn of refresh/postpone events <Created by zyga> <https://github.com/snapcore/snapd/pull/8571>
<zyga> in the tests below you can see how it would look like at runtime: https://github.com/snapcore/snapd/pull/8571/files#diff-5a74ab37983225c1b7fd74b7f20746e0R670
<degville> zyga: thanks for letting me know! I'll take a look (I do try to keep on top of GH notifications)
<zyga> if you have a moment I would love to get some better sentences instead
<zyga> super, thank you :)
<mup> PR snapd#8572 opened: packaging: add the inhibit directory <Created by zyga> <https://github.com/snapcore/snapd/pull/8572>
<mup> PR snapd#8573 opened: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
 * zyga EODs
<mup> PR snapd#8560 closed: tests: disable "searching" test <â  Critical> <â Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8560>
<cmatsuoka> ijohnson: have you seen this error before? https://pasteboard.co/J5Mjrds.png
<ijohnson> cmatsuoka: no sorry I don't have time to debug it right now
<ijohnson> and also to be clear I haven't seen that error
<cmatsuoka> thanks, just checking
<cachio> cmatsuoka, still I see the smae issue https://paste.ubuntu.com/p/3C8Xg6WjcZ/
<cachio> cmatsuoka, at some point the message Press enter to configure. should appear
<cachio> cmatsuoka, right?
<cachio> I am runnign without the -cpu host
<cachio> because it make qemu fail on google
<cachio> cmatsuoka, should I try to find an alternative?
<cachio> for -cpu host
<pedronis> I suspect yes,  the default has other problems
<cmatsuoka> cachio: checking the log...
<cachio> I see this error. qemu-system-x86_64[62220]: qemu-system-x86_64: /build/qemu-74sXTC/qemu-4.2/target/i386/kvm.c:2680: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
<cachio> when I use -cpu host
<cmatsuoka> cachio: it's a bit unclear to me what could be happening there, I'm researching a little bit
<cachio> thanks
<Saviq> jdstrand: hey, when you get a chance, could you please add `interface: home; read-all: true` to auto-connections for Multipass?
<jdstrand> Saviq: why is that needed? (I need to document this)
<Saviq> jdstrand: to allow launching images coming from user's homes
<Saviq> jdstrand: we may avoid it long-term by amending our own profile runtime
<Saviq> to allow access to that one file (which could be outside of /home at that point)
<jdstrand> Saviq: ok, thanks
<cmatsuoka> cachio: debugging msr failures seems to be hard: https://bugs.launchpad.net/qemu/+bug/1661386
<mup> Bug #1661386: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed <QEMU:Fix Released> <https://launchpad.net/bugs/1661386>
<Saviq> cachio, cmatsuoka: zyga came to us yesterday with a strangely similar issue, is this nested on VMWare Fusion? If not, please ignore :)
<cmatsuoka> Saviq: it's nested but on gce
<cmatsuoka> Saviq: I'm googling for similar reports and they're quite weird
<cmatsuoka> Saviq: I think gce uses kvm
<Saviq> the last update to qemu on bionic was in February, so unlikely for that to be related http://changelogs.ubuntu.com/changelogs/pool/main/q/qemu/qemu_2.11+dfsg-1ubuntu7.23/changelog
<zyga> Saviq: could you rebase on core 20?
<zyga> I suspect is is the same security they paper over
<cmatsuoka> Saviq: what we actually need is a qemu cpu with rdrand so we're using -cpu host, and doing that triggered the msr problem cachio reported
<zyga> This is the same as I debugged
<zyga> Dropping -cpu host fixes it for me
<cmatsuoka> hmm, I see that vmware rejects pmu msr accesses
<cmatsuoka> zyga: is your problem related to pmu?
<cmatsuoka> zyga: if so -cpu host,pmu=off might help
<zyga> I did not use pmu
<cmatsuoka> cachio: I don't have any good idea on how to address that, I think it's better to open a bug for kernel reporting it and see if anyone suggests a flag to use or a workaround
<cmatsuoka> cachio: I see similar problems reported for azure and other nested cases, but not this problem exactly
<cmatsuoka> cachio: I mean, for qemu
<cmatsuoka> cachio: not kernel
<cachio> cmatsuoka, it is weird because it was working 2 weeks ago
<cachio> then a change made that it didnt work any more
<cmatsuoka> cachio: oh really? hmm, what could have changed?
<cachio> cmatsuoka, not sure
<cachio> last week I started to see that new behaviour
<cmatsuoka> cachio: can we try an older image to see if it still works?
<cachio> no
<cachio> cmatsuoka, we build the image in the test
<cachio> I cant re-create an old image
<cachio> but I could use snapd from beta
<cachio> does it make sense?
<pedronis> but the bug is in qemu
<pedronis> so it's about the host
<pedronis> not the uc image
<cachio> pedronis, there are 2 things
<pedronis> unless is the kernel in the uc image triggering something
<cachio> a bug in qemu and also this issue that I see that the first boot does not finish
<cachio> install mode goes well
<cachio> then in run mode it does not finish
<cachio> and it was working 2 weeks ago with the same qemu/kvm
<cachio> pedronis, I'll try with an older kernel and older snapd to see what happens
<roadmr> hey who knows a bit about spread? :) Cannot allocate lxd:ubuntu-18.04: cannot list lxd remotes: exec: "lxc": executable file not found in $PATH
<mup> PR snapcraft#3090 closed: ci: move staging store tests to spread <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3090>
<roadmr> sergiusens: maybe you know about that error I got above? lxc/d is installed, though from deb, not snap
<roadmr> sergiusens: btw this looks much easier to set up / run than the old way :) thanks
<mup> Bug #1875493 opened: [core] log rotation doesn't properly restart rsyslogd <Snappy:New> <https://launchpad.net/bugs/1875493>
<ijohnson> roadmr: are you using spread via the snap ?
<ijohnson> oh well nvm
<diddledan> jdstrand, if you're about, is the gnome session manager dbus api (for uses other than screen-inhibit-control) omitted from the desktop or desktop-legacy plugs because we're expecting snaps to define their use via a custom plug?
<diddledan> specifically it's on the session bus at endpoint org.gnome.SessionManager member RegisterClient
<diddledan> possibly also an UnregisterClinet?
<diddledan> for an example snap that is trying to use the api:: https://forum.snapcraft.io/t/openaudible-bounty/16835/8
#snappy 2020-04-28
<mup> PR snapcraft#3095 opened: plugins: break out rosdep resolve parsing for external use <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3095>
<mup> PR snapcraft#3096 opened: pluginhandler: export SNAPCRAFT_BUILD_BASE to build environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3096>
<mup> PR snapcraft#3015 closed: [WIP] ros2 (colcon) extension preview <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3015>
<mup> PR snapcraft#3097 opened: [WIP] colcon v2 plugin + ros2 extension <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3097>
<mup> Bug #1875543 opened: Ubuntu 20.04 "A stop job is running for Snappy Daemon" during shutdown <20.04> <ubuntu> <Snappy:New> <https://launchpad.net/bugs/1875543>
<zyga> Good morning
<mborzecki> morning
<mvo> good morning mborzecki
<mborzecki> mvo: hey, meeting is at 11 right?
<mvo> mborzecki: yes
<zyga> Hey
<zyga> How was day one?
<mborzecki> mvo: cool, i'll go for a walk with kids and do groceries, will be back before 11
<mvo> mborzecki: sounds good, note that you are optional for the meeting, no worries about this
<pstolowski> morning
<zyga> good morning pawel :)
<zyga> let's see if the store works better today
<pedronis> hello, how are tests doing today?
<zyga> pedronis: running now, all yesterday was red red red
<zyga> pedronis: I'll let you know if a single run can pass
<pstolowski> hi pedronis, i just kicked one of my PRs, will know soon
<mborzecki> re
<pedronis> zyga: pstolowski: I have a PR that I would like to land to let people test in edge, but I will not trigger it if it's hopeless
<pedronis> zyga: pstolowski: thanks
<zyga> ack
 * zyga tests a fix for opensuse 
<zyga> google:ubuntu-core-16-64:tests/main/core-persistent-journal failed
<zyga> + snap set core journal.persistent=false
<zyga> 886
<zyga> grep error: pattern not found, got:
<zyga> 887
<zyga> error: cannot communicate with server: Put http://localhost/v2/snaps/core/conf: EOF
<zyga> preseed tests also failed on 19.10
<zyga> ++ find /mnt/cloudimg/var/lib/snapd/seed/snaps/ -name 'core_*.snap'
<zyga> 1316
<zyga> + CORE_IMAGE=
<zyga> 1317
<zyga> + unsquashfs ''
<zyga> 1318
<zyga> Could not open , because No such file or directory
<zyga> 1319
<zyga> pstolowski: let's finish that branch that fixes this
<zyga> pstolowski: you said that you had more improvements to my PR?
<pstolowski> zyga: i pushed them all to #8528
<mup> PR #8528: tests: fix for pre-seeding failures <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<zyga> super, let's see
<zyga> when did you restart this last?
<pstolowski> zyga: let me merge master & push
<pstolowski> was last week
<zyga> pstolowski: thanks
<zyga> pstolowski: perhaps rebase, the merges are just confusing
<pstolowski> zyga: hmm too late
<zyga> no worries
<pstolowski> zyga: do you have a link to core-persistent-journal failure?
<zyga> yes, one sec
<zyga> https://github.com/snapcore/snapd/pull/8565/checks?check_run_id=625210861
<mup> PR #8565: osutil: expand FileLock to support shared locks and more <Created by zyga> <https://github.com/snapcore/snapd/pull/8565>
<pstolowski> i cannot reproduce google:ubuntu-core-16-64:tests/main/core-persistent-journal failure
<zyga> may have been a random one :/\
<pstolowski> zyga: we have some selinux denials on centos, and tests failing because of them, looking
<zyga> I saw that but I'm unsure how to fix it
<pstolowski> zyga: did we change snap-update-ns recently?
<zyga> noo
<zyga> no*
<pstolowski> hmm
<zyga> I suspect it's the nss modules
<zyga> but I didn't go deep on that
<pstolowski> indeed, only a few irrelevant changes there
<pstolowski> zyga: pressed PR failed, i think 19.10 now has core18+snapd too, fun
<pstolowski> zyga: i'm on it
<zyga> heh
<zyga> thank you
<zyga> I'm looking at base policy issue
<zyga> pedronis: is it possible to look at earlier revisions of assertions somehow? I'd like to see snap declarations
<zyga> pedronis: no longer needed!
<pedronis> zyga: the answer is no basically, not easily
<pstolowski> zyga: pushed fix to #8528
<mup> PR #8528: tests: fix for pre-seeding failures <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<zyga> \o/
<zyga> thank you!
<pstolowski> zyga: have you found anything about opensuse failures?
<zyga> I looked but my trivial fix failed, I need to boot suse and just look around
<zyga> I suspect I know what it is
<zyga> I will probably couple that with package update
<zyga> but after the meeting today
<zyga> brb
<jdstrand> diddledan: hey, I responded in the forum
<pstolowski> zyga: #8525 green everywhere except for opensuse and centos 8
<mup> PR #8525: tests: ignore user-12345 slice and service <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8525>
<pstolowski> zyga: ups, i mean #8528
<mup> PR #8528: tests: fix for pre-seeding failures <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<zyga> pstolowski: on unstable systems, can we merge regardless?
<pstolowski> zyga: yes, we should. needs 2nd review
<zyga> ok
<zyga> maybe ijohnson is around now?
<ijohnson> whats up zyga
<zyga> ah, on a call
<ijohnson> also good morning
<zyga> ijohnson: just queue it for later ^^^
<ijohnson> 8258 ?
<pstolowski> hey ijohnson
<ijohnson> hey pstolowski
<pstolowski> ah, actually it needs 2 reviews ;)
<zyga> I just cannot review as I wrote some part of it
<pstolowski> i suppose i can't review it
<pstolowski> yeah
<pstolowski> zyga: maybe your and my review would count 0.5 each ;)
<zyga> haha, yeah
<zyga> I think that's ok
 * juergh_ juergh
<juergh_> I need to install an old version of snapd that doesn't seem to be in any of the channels anymore. How would I go about that?
<zyga> juergh_: hey, unless it's available in one of the channels you cannot do that
<zyga> juergh: is there a particular reason you need to use a older snapd?
<juergh> zyga, 2.43.x introduced a workaround for what some people believe is a kernel issue. I need to test with the old snapd that dosn't have the workaround to debug this.
<zyga> juergh: perhaps you can download a package from the archive (.deb) and see if that's sufficient
<zyga> juergh: I think there are some places that cache them
<juergh> zyga, are you saying we don't archive old snaps?
<zyga> juergh: we do but we don't allow everyone to download them
<juergh> zyga, and you're saying as an Ubuntu kernel maintainer and Canonical employee I'm not allowed :-)
<zyga> juergh: only the publisher of a given snap can get every revision
<roadmr> (and collaborators)
<juergh> zyga, whom do I need to talk to get the revision that I need?
<zyga> juergh: sorry, in a call
<zyga> juergh: I think someone from the store or snapd might be able to help you
<zyga> juergh: you need to find a revision of core or snapd that has what you want
<zyga> and download that
<zyga> juergh: I'll break for lunch now, I can try to help you after the break
<zyga> mvo: not sure if you have time but we need https://github.com/snapcore/snapd/pull/8528 to unbreak master
<mup> PR #8528: tests: fix for preseeding failures <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<zyga> mvo: its green apart from unstable systems and has one review from Pawel who contributed a good chunk of the work
<mup> PR snapd#8574 opened: tests, selinux: update SELinux rule affecting snap-update-ns on centos 8 <Created by stolowski> <https://github.com/snapcore/snapd/pull/8574>
<pstolowski> mborzecki: ^ if you have a sec.. not sure if there is a magic macro anywhere in the policy, but this should do ..
<cmatsuoka> zyga, cachio: going to SU?
<zyga> no, I'm in the public review session
<cachio> yes
<cachio> but trying t o login
<cachio> mvo, hi
<zyga> cachio: mvo is speaking now
<cachio> zyga, ouch
<cachio> zyga, thanks for the heads up
<ijohnson> zyga: pstolowski: I have reviewed 8528
<pstolowski> ijohnson: thanks! i'll remove the TODO comment on next occasion
<ijohnson> sounds good
<mvo> cachio: hi
<cachio> mvo, sorry for the interruption
<cachio> cwayne, asked me to create a test-snapd-tools-core20 snap
<cachio> mvo, you created the other 2 ones
<cwayne> i did do that
<cachio> and I cant find where you have the snapcraft.yaml
<mvo> cachio: thanks, let me check
<cachio> and the snap recipe
<mvo> cachio: looking now
<cwayne> that's the main stuff failing on uc20 runs for us
<cachio> mvo, thanks
<cmatsuoka> cachio: where can I find the core image inside the classic test machine?
<cachio> cmatsuoka, /tmp/work-dir/image
<cachio> there
<mvo> cachio: it's a hand crafted one, I pushed a new one and shared with you, we should make it owned by test-snaps@c.c
<mvo> cachio: anyway, should unblock you
<cachio> mvo, thanks
<mup> PR snapd#8528 closed: tests: fix for preseeding failures <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8528>
<cmatsuoka> cachio: one of the flags made the nested vm boot
<cachio> cmatsuoka, awesome
<cachio> cmatsuoka, panic?
<cmatsuoka> cachio: now I must find which one, there are four possibilities
<cachio> cmatsuoka, I can help
<cmatsuoka> cachio: I tried it with -cpu host,-vmx-apicv-register,-vmx-apicv-vid,-vmx-ple,-vmx-rdrand-exit
<cmatsuoka> cachio: but I also ran with -smp 4 and it rebooted later, so perhaps -smp 1 could help in this case?
<cachio> cmatsuoka, yes
<cmatsuoka> cachio: what I actually did was to run my usual qemu script inside the google-nested machine with -nographics
<cmatsuoka> adding the extra flags to cpu
<cachio> ahh, I am trying now with your parameters
<cmatsuoka> cachio: there are four flags there but probably one one fixes the msr issue
<cachio> cmatsuoka, I am trying now the regular nested with those parameters
<cmatsuoka> cachio: -vmx-rdrand-exit prevents the crash, let's see if it doesn't cause entropy starvation problems
<cachio> cmatsuoka, awesome
<cachio> cmatsuoka, so far I couldn't connect through ssh
<cmatsuoka> cachio: I think it's better to monitor the console to actually see what's going on there, it could be many things now including our dreaded entropy starvation
<cmatsuoka> I'm not sure what exactly this flag does and documentation isn't great
<cachio> cmatsuoka, yes
<cachio> cmatsuoka, I see that goes into an infinite loop
<cachio> using -smp 1
<cmatsuoka> cachio: it freezes?
<cachio> cmatsuoka, no
<cmatsuoka> cachio: or is it a reboot loop?
<cmatsuoka> does this problem also happen without -cpu?
<cachio> it rebooted in install mode many times
<cachio> without -cpu I didnt see those reboots usign -smp 1
<cmatsuoka> and without -cpu, where did the problem happen again?
<cachio> cmatsuoka, so
<cachio> I don't see the menu anymore
<cachio> so I cant update the kernel command line any more in run mode
<cachio> cmatsuoka, also when I run console-conf I dont see any network: https://paste.ubuntu.com/p/2J4vjjxvHw/
<cachio> cmatsuoka, I am going to have lunch now
 * cachio lunch
<mup> PR snapd#8575 opened: packaging/fedora: disable FIPS compliant crypto for static binaries <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8575>
<mborzecki> pstolowski: ^^
<mup> PR snapd#8574 closed: tests, selinux: update SELinux rule affecting snap-update-ns on centos 8 <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8574>
<pstolowski> drat, another failure of google:ubuntu-core-16-64:tests/main/core-persistent-journal, something is flaky after all
<cmatsuoka> cachio: so if you're reaching console conf the system is booting correctly to run mode, except network?
<cachio> cmatsuoka, yes
<cmatsuoka> cachio: and this is with -cpu or without?
<cachio> without
<cmatsuoka> ok, so entropy starvation was not an issue
<cmatsuoka> good
<cachio> with -cpu it goes to a infinite loop
<cachio> cmatsuoka, do you know how to edit the kernel commandline now?
<cachio> the menu does not appear anymore
<cmatsuoka> do you want to edit it for install mode or run mode?
<cmatsuoka> for run mode it's part of the tpm measurements so you can't change it
<cachio> cmatsuoka, ahh
<cachio> that makes sense
<cmatsuoka> now this network problem seems strange, did you see something similar before?
<cachio> no
<cachio> perhaps this is the reason why ssh cannot be stablished
<mup> PR snapd#8575 closed: packaging/fedora: disable FIPS compliant crypto for static binaries <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8575>
<mborzecki> yay, thanks mvo!
<mborzecki> hm maybe we could move centos8 back to stable systems now
<cachio> cmatsuoka, now without -cpu I see a reboot loop again
<cachio> cmatsuoka, this is dmesg output on the host machine https://paste.ubuntu.com/p/JD5WgQkBQG/
<cachio> cmatsuoka, for each reboot I see a vcpu0, guest rIP: 0xffffffffb5e788b4
<cachio> xnox, hey, any idea about what be causing that error?
<cmatsuoka> this seems to be just a notification message, not necessarily an error
<cachio> cmatsuoka, but this vcpu0, guest rIP:
<cachio> means that something happens and hte vm was killed right?
<cmatsuoka> I think it's just a message telling that the guest is trying to access the msr
<cmatsuoka> if something is crashing you should see a more detailed message
<Saviq> zyga: LOL, `sejwy`? ;D
<zyga> Saviq: *comprehensible* ;)
<zyga> Saviq: are you following all new posts? :D
<Saviq> zyga: only the interesting ones :P
<Saviq> zyga: "remainder", btw :)
<zyga> ah, thanks
<zyga> fixed
<zyga> Saviq: feedback welcome, it's just an idea at this stage
 * zyga EODs
<cachio> cmatsuoka, did you remember the kvm parameter used to show extra info like crashes?
<cachio> do you ?
<cmatsuoka> cachio: hmm, no, I don't know this parameter
<cmatsuoka> cachio: maybe Saviq knows?
<Saviq> no, sorry
<mup> PR snapd#8576 opened: tests/main/lxd: add test for snaps inside nested lxd containers <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8576>
<jdstrand> mvo: hey, fyi the discussion in https://github.com/snapcore/core20/issues/48#issuecomment-620509641
<mvo> jdstrand: thanks, checking
<mvo> jdstrand: right, I agree we should use the updated libseccomp and rebuild snapd/core with that
<mvo> jdstrand: timing is not great, I can probably work on this tomorrow (my) morning but it requires hte updated libseccomp to be available in ppa:snppay-dev/image
 * mvo actually should write this in the bug
<ijohnson> also mvo I proposed the nested lxd test and it fails
<ijohnson> need someone to look into why it fails
 * ijohnson doesn't know
<mvo> ijohnson: might be worthwhile to check with stgraber
<jdstrand> mvo: yeah. I'm not pushing for a particular time, just wanted to make sure you saw it
<jdstrand> mvo: thanks
<mvo> jdstrand: yeah, if snapcraft enables it we should fix the issue ASAP :)
<mvo> ups, ijohnson -^
<ijohnson> yeah, I mean we could also ask snapcraft team to delay if really needed
<ijohnson> stgraber: is running snapd inside a lxd container which is a nested lxd container supported?
<ijohnson> stgraber: we test that snapd inside a lxd container works as expected and that we can create nested containers, but we heard from the juju team that sometime around eoan release it stopped working to install snaps inside the inner nested container
<mvo> ijohnson: it's probably ok, I check in my morning, shouldn't be much work to do a 2.44.4, the only annoying part is that we only have a single beta channel and 2.45~pre1 is there right now, so it needs to go to candidate quickly or we test from a branch or something as we also need to build the beta cu20 image from the beta/ channel
<ijohnson> mvo: I thought that ~pre* releases don't ever got to candidate ?
<mvo> ijohnson: yeah, we usually put 2.44.x into beta so it would override 2.45~pre1 etc, I need to think a little bit about this
<ijohnson> ack, let me know if there's anything I can help with
<mvo> ijohnson: it's probably fine if we keep 2.44.4 in beta just shortly, 2.44.4 has almost no changes so the regression risk is minimal
<mvo> ijohnson: thanks, will do!
<mup> PR snapd#8577 opened: [RFC] secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8577>
<stgraber> ijohnson: apparmor only supports one level of nesting, so you can install snaps in a LXD container but you cannot install snaps inside a nested LXD container
<stgraber> ijohnson: LXD itself if not installed through snapd can nest all the way to the max 32 levels deep and will just re-use the parent level's apaprmor profile when detecting that it can't create a new apparmor namespace
<ijohnson> stgraber: ack,  I will let Tim Penhey know
<stgraber> I had someone reach out about this setup a week or so ago too
<ijohnson> thanks, I can't seem to find him on IRC so I'll drop him an email and CC you on it
<mup> PR snapd#8475 closed: tests: port snap-session-agent-* to session-tool <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8475>
#snappy 2020-04-29
<mborzecki> morning
<mvo> mborzecki: good morning
<mvo> mborzecki: I cherry-picked 8575 to 2.44
<mvo> mborzecki: that is needed, right? we will need a new 2.44.4 with a fix for syscalls with base: core20
<mborzecki> mvo: thanks!
<mborzecki> mvo: yes, it fixes the problems with libcrypto dependency being injected on centos
<mborzecki> mvo: i'll need to add a similar change in downstream packaging for fedora/epel
<mvo> ta
<zyga> Good morning
<zyga> How are you guys?
<zyga> I will start late but I will look at opensuse a little today
<zyga> Iâll fix our tests there and update the packaging /release
<mvo> zyga: hey, I'm good, thanks!
<mborzecki> qemu 5.0 is out, supports emulating tpm for arm
<zyga> Groovy
<zyga> Can we snap it? :-)
<mborzecki> mvo: hmm 2.44 travis unit test job runs with different go version?
<mborzecki> ah, it's go master
<mvo> mborzecki: yeah, just removed that
<mvo> mborzecki: I want to see the spread run
<mborzecki> i'm out for a bit, and yay it's raining!
<pstolowski> morning
<mvo> hey pstolowski - good morning
<juergh> mvo, zyga can one of you help me with that snapd download, please?
<zyga> I will try
<zyga> Which version do you need?
<zyga> juergh: ^ ?
<ogra> did xdg-open change recently ?
<ogra> error: error running snapctl: Unknown command `user-open'. Please specify one command of: get, is-connected, restart, services, set, set-health, start, stop or unset
<zyga> ogra: hmm, weird
<zyga> ogra: perhaps a bug
<ogra> i'm not yet sure, might be that the app changes ... the snapctl got me hooked though
<ogra> *changed
 * zyga breakfast
<juergh> zyga, snapd 2.43.3
<zyga> ok
<zyga> give me a moment please
<zyga> juergh: which architecture do you need?
<juergh> zyga, amd64
<zyga> juergh: hmm, but wait, 2.43.3 is latest stable
<zyga> ah
<zyga> sorry 44
 * zyga needs coffee
 * zyga looks at fixing the opensuse build issue now
<tpreston> Hi, is there a reason why snapd /etc/profile.d/snapd.sh *appends* snap_bin_path to PATH, rather than prepends?
<tpreston> https://forum.snapcraft.io/t/should-snap-bin-be-prepended-to-path/4506
<zyga> tpreston: it's a more conservative choice, I suspect
<tpreston> I have ctags installed at a system level (because of a package dependency), but I'd prefer to use snapd universal-ctags
<tpreston> zyga: I guess so, maybe I should alias ctags then
<doko> how can I make how can I make file:///usr/share/doc/python3-doc/html/index.html  work with the chromium snap?
<zyga> doko: apart from serving it over http, I guess you cannot
<zyga> doko: maybe copy it to ~ ?
<doko> zyga: broken by design to access anything in /usr/share/doc ?
<zyga> doko: not broken by design
<zyga> doko: it's just not designed to access arbitrary host locations
<zyga> doko: there are two elements at play, the view of the filesystem and the sandbox
<doko> well, copying everything from /usr/share/doc to ~ is not viable
<zyga> doko: chromium and your system see different filesystem
<zyga> doko: and while /usr/share/doc is probably safe and could be allowed, it's not a general property
<doko> is there a bug report about that?
<zyga> doko: before you file one, do you have an idea of how it should work?
<zyga> doko: I mean, I share the sentiment of it feeling broken
<zyga> doko: but what could we do?
<doko> well, for me it then not using the snap anymore
<ogra> have a "host-documentation" interface that lallows reading /usr/share/doc content ?
<zyga> doko: to partially answer my own question, at some point the document portal could be integrated into chromium, so that it could open a file
<zyga> but IIRC the portal does not handle directories yet
<zyga> doko: while I agee it's a regression I think using chromium to browse debian-style local documentation is fortunately niche
<zyga> ogra: if you do that then the snap won't be able to see the /usr/share/doc from the base, I guess that's acceptable but rather obscure
<zyga> ogra: but I think that's a good idea
<ogra> yeah, i doubt the base will actually have content in /usr/shar/doc apart from copyright files
<zyga> doko: I would strongly encourage you to file a bug or open a forum thread, I think ogra's idea is viable and well worth discussing
<ogra> unless the building has changed massively (we used to remove everything there in the expectation that nobody would every want to use docs inside a base)
<zyga> ogra: yes, I think we are lucky in a sense
<zyga> if it was something other than that directory, it's probably not something that we could rely on
<ogra> yeah
<ogra> btw, using a portal would be horrible i fear, every link inside that index.html would pop up a new portal window
<doko> zyga: where to file a bug?
<zyga> ogra: I think there's a plan to open an entire directory as a portal
<ogra> ah
<zyga> doko: please file the bug on snapd on launchpad
<doko> https://bugs.launchpad.net/snapd/+bug/1875860
<mup> Bug #1875860: local documentation is not accessible from the chromium snap <regression> <snapd:New> <https://launchpad.net/bugs/1875860>
<zyga> ogra: I added a comment explaining your idea
<zyga> doko: thank you!
<ogra> :)
<ackk> hi, are these error coming from snapd itself  https://launchpadlibrarian.net/477374648/DpkgTerminalLog.txt ?
<zyga> yes
<zyga> ackk: udev in containers
<zyga> ackk: it's a known topic that's on the backlog
<ackk> zyga, what's the issue there?
<zyga> ackk: snapd tries to reconfigure udev but udev is not meant to be used in containers (we pull it as a debian dependency) and it fails
<ackk> zyga, for context, https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1875741 is the bug for that trace. basically a bionic->focal dist-upgrade with maas transitioning from deb to snap broke
<mup> Bug #1875741: package maas 2.6.2-7841-ga10625be3-0ubuntu1~18.04.1 failed to install/upgrade: new maas package pre-installation script subprocess returned error exit status 1 <amd64> <apport-package> <focal> <third-party-packages> <uec-images> <maas (Ubuntu):New> <https://launchpad.net/bugs/1875741>
<zyga> ackk: on subsequent runs snapd things everything is okay and no longer tries
<ackk> zyga, so trying once again should fix it?
<zyga> ackk: it's a topic we know about since Fra but we haven't managed to discuss at depth with Security
<zyga> ackk: yes
<zyga> ackk: there are some disagreements and we frankly didn't have time to sit down and discuss this
<ackk> zyga, did anything change recently? I did test maas deb->snap transition in containers, never seen this issue
<zyga> not that I know of
<ackk> zyga, won't that break anyone dist-upgrading a container with snapd installed to focal? or is some kind of race that might happen?
<zyga> ackk: it probably will
<zyga> ackk: just a fire more distant than fires close up
<sparkiegeek> zyga: got a bug number for it?
<zyga> sparkiegeek: yes, let me find it
<zyga> sparkiegeek: I tried addressing it before
<zyga> one sec
<ackk> zyga, sure, not implying anything, just trying to understand if there's something on the maas package side we could do, which it seems ther's not?
<zyga> https://github.com/snapcore/snapd/pull/8219
<mup> PR #8219: interfaces: use udev backend if udev socket exists <Security-High> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8219>
<zyga> this is my idea and the bug is https://bugs.launchpad.net/snapd/+bug/1865503
<mup> Bug #1865503: snapd (deb) fails to install snapd (snap) inside LXD on a buildd based image <core20> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1865503>
<zyga> the discussion there is interesting as well
<zyga> my idea is that we should not depend on udev, not pull it in for containers, not use any udev when there's no real udev or real /dev
<zyga> sparkiegeek, ackk: if you have opinions I'd love to learn from you as well
<sparkiegeek> zyga: no educated opinion here :|
<ackk> zyga, same here...
<mup> PR snapd#8578 opened: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<mborzecki> pstolowski: does your PR now work on centos 8 with the fix in master?
<pstolowski> mborzecki: which PR?
<mborzecki> pstolowski: don't remember :P one that was blocked by selinux basically, or was there none?
<pstolowski> mborzecki: master was blocked
<mborzecki> ahh cool
<zyga> doko: https://github.com/snapcore/snapd/pull/8578
<mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<zyga> doko: it even has a test: https://github.com/snapcore/snapd/pull/8578/files#diff-aea859a8dd781e56f1c21b809b953d95R13
<ogra> oh, look someone found the mvo backdorr in ubuntu core !!! once you create an mvo account you can never delete it anymore !! https://forum.snapcraft.io/t/login-and-delete-user-created-with-v2-create-user/17019
<mborzecki> all devices belong to mvo ;)
<ogra> yeah !
<mvo> ogra: haha
<ogra> i really wonder what makes people use some random accounts found on the internet for such stuff :)
<mvo> it's baffling!
<zyga> mvo: lol
<zyga> mvo: I wonder if the user found this is our tests or if there is some documentation example
<mvo> probably
<zyga> I could use a review for rather simple https://github.com/snapcore/snapd/pull/8565
<mup> PR #8565: osutil: expand FileLock to support shared locks and more <Created by zyga> <https://github.com/snapcore/snapd/pull/8565>
<zyga> ok, i have my opensuse install under control now
<pstolowski> +1
<zyga> thanks!
<zyga> ijohnson: do you have a moment  ^ it's pretty simple
<zyga> ijohnson: it would unblock a host of other PRs
<ijohnson> zyga: will look in a bit busy atm
<zyga> sure
<mborzecki> mvo: pstolowski: do you think we can land https://github.com/snapcore/snapd/pull/8536 to unblock the rest? with any tweaks in the followups (there's a bunch of PRs stack on top of this one)
<mup> PR #8536: store,asserts,many: support the new action fetch-assertions <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8536>
<mborzecki> hm pedronis isn't around
<zyga> brb
<zyga> tea
<pstolowski> mborzecki: best to ask him actually... don't know if there is any risk
<mup> PR snapd#8536 closed: store,asserts,many: support the new action fetch-assertions <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8536>
<mvo> mborzecki: I think it makes sense, done
<mborzecki> thanks!
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/8578/files#diff-aea859a8dd781e56f1c21b809b953d95R13
<mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<jdstrand> zyga: cool thanks. I have it on my list to review, but note I'm sprinting/etc
<zyga> no rush :)
<ijohnson> cmatsuoka: I hit the infinite loop of failed to transient mount unit for ubuntu-seed you had the other day
<cmatsuoka> ijohnson: it's quite infrequent, but it's something we'll have to fix
<ijohnson> cmatsuoka: did the issue go away when you rebooted ?
 * ijohnson would like to debug but is afraid that when rebooting the issue goes away
<cmatsuoka> ijohnson: yes, when I booted the same image again it worked as expected
<cmatsuoka> looks racy
<ijohnson> mmm yeah
<ijohnson> ah actually I can consistently reproduce this now on my image
 * ijohnson debugs
<cmatsuoka> oh that's good, I couldn't reproduce it
 * cachio lunch
<ijohnson> cmatsuoka: I video recorded the boot and caught this in the first few seconds of the log
<ijohnson> https://usercontent.irccloud-cdn.com/file/84WtzfpC/loop%20uc20%20edge.png
<ijohnson> the last line `systemd-fsck CP437 Invalid argument` is suspicious
<cmatsuoka> oh interesting
<cmatsuoka> yes, very suspicious
<ijohnson> https://usercontent.irccloud-cdn.com/file/uYCPMgpF/loop%20uc20%20later.png
<ijohnson> cmatsuoka: then this is also suspicious where run-mnt-ubuntu\x2dseed.mount fails because wrong fs type, bad option, etc.
<cmatsuoka> ijohnson: maybe you could inspect the image file? (it could be a good idea to make a copy first in case you end up fixing the problem)
<cmatsuoka> ijohnson: and check if the partition contents are there or the filesystem seems right
<ijohnson> cmatsuoka: yes I am doing that now
<ijohnson> the partition was mounted fine with kpartx + mount of the loopback device
<cmatsuoka> does it look good?
<ijohnson> yeah it has all the expected files and such
<cmatsuoka> hmm
<ijohnson> should I try to run fsck on the partition in the .img file ?
<cmatsuoka> yeah, let's see what happens
<ijohnson> huh fsck.etx4 says ubuntu-seed is actually a vfat partition?
<ijohnson> https://www.irccloud.com/pastebin/C2v5Dpoz/
<cmatsuoka> mm, yes, seed is vfat
<ijohnson> really? I thought seed was ext4 on amd64 ?
<cmatsuoka> we must EFI boot it
<ijohnson> ah okay so I was just wrong about that then
<cmatsuoka> seed is vfat, the rest is ext4
<ijohnson> ok, fsck.vfat doesn't complain about the partition at all then
<ijohnson> cmatsuoka: anything else I should check about the partition you think?
<cmatsuoka> did it complain about code pages or something like that?
<cmatsuoka> or maybe systemd-fsck does something different?
<cmatsuoka> does it still fail if you boot the image again?
<ijohnson> cmatsuoka: yes it reliably fails every time I boot now
<ijohnson> cmatsuoka: all I got from fsck.vfat output was this:
<ijohnson> https://www.irccloud.com/pastebin/nuIWXTi1/
<cmatsuoka> hmm
<ogra> xnox, when you disabled the ability to disaable console-conf in ubuntu-image, did you make sure it still works for core18 builds ?
<ogra> (someone just said it is completely gone, we have customers usign that option to build their images)
<cmatsuoka> ijohnson: so the fs is good but for some reason it's not being mounted
<ijohnson> yes
<ijohnson> I can mount it fine though when the image is not booting
<ijohnson> actually you know what, since this is still in install mode I can change the kernel cmdline since we never make it out of the initrd
<ijohnson> so unsealing doesn't affect anything at this point
<cmatsuoka> yes, you're right, let's inspect it while it's happening
<ogra> xnox, ah, nevermind ... it still works but the --help info about it is gone
<ijohnson> well damn now it boots fine
<cmatsuoka> did you make a copy of the original image?
<ijohnson> yes I did
<ijohnson> let me make a copy of that original image and try again
<ijohnson> ah now the copy of the original broken image works too :-/
<cmatsuoka> oh noes
<ijohnson> so this definitely seems like a race
<cmatsuoka>  /o\
<ijohnson> well on the other hand, I notice that in the log of the failed boot that goes into this loop there's this message too:
<ijohnson> [    1.342368] FAT-fs (vda2): IO charset iso8859-1 not found
<ijohnson> and that message doesn't appear in a good boot
<ijohnson> so perhaps it's a race with some kernel module being loaded?
<cmatsuoka> that sounds plausible
<cmatsuoka> but then if it's desperately retrying, at some point it should work
<cmatsuoka> ijohnson: https://askubuntu.com/questions/372445/fat-fs-io-charset-iso8859-1-not-found-error-while-mounting-fat-drives
<ijohnson> cmatsuoka: what's so weird about this issue, is that it finishes the fsck check on /dev/vda2 in the loop case
<ijohnson> ah but it wouldn't be loading the kernel module from that partition at this point, it would be loading it from the initrd in the kernel
<ijohnson> so perhaps that kernel module in the initrd is corrupted somehow?
<cmatsuoka> but then why it would work in the next boot?
<ijohnson> well tbh I didn't quite make a perfect backup of the original image that was always reproducing, what I did was this:
<ijohnson> 1. tried booting same img over and over again always reproducing infinite loop
<ijohnson> 2. tried mounting the img file with kpartx and ran fsck.ext4 on it as explained
<ijohnson> 3. unmounted with kpartx and made a backup copy
<ijohnson> 4. re-mounted it and tried with fsck.vfat
<ijohnson> 5. booted it and it didn't work first time
<ijohnson> 6. rebooted it and changed kernel cmdline in grub menu, now it works every time
<cmatsuoka> well, it still didn't boot in step 5
<ijohnson> yes but somehow changing the kernel cmdline made it boot fine
<cmatsuoka> that's weird
<ijohnson> I set the kernel cmdline to this: `console=tty1 console=ttyS0 rd.systemd.journald.forward_to_console=1 systemd.journald.forward_to_console=1 rd.systemd.debug_shell=1 dangerous panic=-1`
<ijohnson> let me try re-creating this image fresh the way I did originally
<cmatsuoka> I'll break for lunch and hopefully have a good idea while eating
<cmatsuoka> because right now I don't have any
<ijohnson> yeah just doing same thing again to build the image didn't reproduce it
 * ijohnson runs it in a loop
<ijohnson> hey I reproduced it again!
 * ijohnson saves that img
<zyga> you guys are having some fun :)
<ijohnson> uc20 is too much fun
<ijohnson> alright so every few time it hits that loop and fails, I see the IO charset iso8859-1 not found message, but when it does boot, I don't see that message, so it definitely is related
<xnox> ogra_:  i didn't change anything in ubuntu-image, and do not do any ubuntu-image development there.
<xnox> ogra_:  open an issue against ubuntu-image repository, with any bugs.
<thresh> hi.  I see my snapcraft push nightlies/vlc_*.snap --release beta, has succeeded in my CI, and I also see it under "Latest revisions for amd64" list.  However it's not in the beta channel.
<thresh> why would that happen, on the store?
<zyga> thresh: this is more of a snapcraft question but perhaps snapcraft devs are around as well
<thresh> thanks zyga, I'll complain in the related channel too :-)
<zyga> thresh: I don't use snapcraft that often but I usually separately upload and release
<zyga> cachio: are tumbleweed images updated periodically somehow or are we running a snapshot until something happens explicitly?
<cachio> zyga, failed yesterday
<zyga> sorry, I don't understand
<cachio> let me try to fix it
<zyga> cachio: can you please answer my question :-)
<cachio> I mean
<zyga> I' just want to understand what the process is
<zyga> you can tell me what failed and about fixing it as well
<zyga> but that's not what I was asking about
<cachio> the process is:
<cachio> the image is updated to a tamporal image
<cachio> then the snapd tests are executed
<cachio> if tests pass, then we turn that temporal image in a test image
<cachio> otherwise the image is discarded
<cachio> yesterday it failed running tests
<cachio> failed preparing the the snapd teest suite
<zyga> is there any notification when that happens?
<cachio> no
<zyga> that's not great, can we try go get some
<cachio> it is in the brnaches board
<cachio> ans it happens every monday
<zyga> what is "branches board"?
<cachio> https://travis-ci.org/github/snapcore/spread-cron/branches
<cachio> https://travis-ci.org/github/snapcore/spread-cron/branches
<cachio> zyga, this is the last log https://travis-ci.org/github/snapcore/spread-cron/builds/680087171#L2749
<cachio> sometimes I manually run the jobs to update the images
<cachio> zyga, I see this Package 'python-docutils' not found.
<zyga> I see, I think this package just got removed, it's a python 2 package
<cachio> zyga, also 'pkg-config' not found in package names.
<zyga> cachio: why are we installing python-docutil?
<zyga> I don't see it in anything related to opensuse
<zyga> cachio: yes, that's also been removed and replaced by something else
<cachio> zyga, this is the snapd test suite which fails
<zyga> cachio: python-docutils is only listed in arch
<zyga> cachio: why are we installing python-docutils, do you know?
<cachio> zyga, don't know why it is installed
<cachio> I guess  a test need it
<ogra> xnox, oh, sorry, GH tricked me ... you were just a reviewer on https://github.com/CanonicalLtd/ubuntu-image/pull/186
<mup> PR CanonicalLtd/ubuntu-image#186: Some options are unsupported for UC20 builds <Created by sil2100> <Merged by sil2100> <https://github.com/CanonicalLtd/ubuntu-image/pull/186>
<zyga> cachio: do you know which part of the code is installing it? I certainly don't see it in pkgdb.sh
<zyga> I see it in opensuse dependencies but that's not managed by pkgdb.sh
<zyga> cachio: ok, I see the problem now
<cachio> packaging/opensuse-15.0/snapd.spec:
<zyga> cachio: I think for sid, tumbleweed and arch we should not stop
<zyga> cachio: if we stop and use some ancient version because tests don't pass
<zyga> that's pretty much because snapd is in a way broken
<zyga> the world has moved on
<zyga> staying on an old image without alerting the team could be a problem later
<zyga> in a sense those systems are all unstable because they never stop
<cachio> zyga, for arch is not a problem because we update in every run the image
<zyga> cachio: regardless of how we update
<cachio> zyga, but I could remove snapd tests validation for tumbleweed and sid
<cachio> it is very easy
<zyga> cachio: yeah, I think we should do that
<zyga> cachio: we can have them in unstable systems
<cachio> zyga, yes
<zyga> cachio: in reality, the package is gone from the archive
<cachio> totally agree
<zyga> cachio: not updating a stale image is not buying us anything
<zyga> cachio: the package cannot be built
<zyga> cachio: CI is not functioning as CI :)
<zyga> cachio: cool, I'll send a patch to fix our packaging
<cachio> zyga, nice, thanks!
<zyga> cachio: but please let's figure out how to make some notifications flash on everyone's systems
<zyga> cachio: so that next time we know earlier
<cachio> zyga, sure, I'll configure to send emails
<zyga> super, thank you :)
<cachio> zyga, yaw
<zyga> cachio: https://github.com/snapcore/snapd/pull/8579
<mup> PR #8579: packaging: stop depending on python-docutils <Created by zyga> <https://github.com/snapcore/snapd/pull/8579>
<mup> PR snapd#8579 opened: packaging: stop depending on python-docutils <Created by zyga> <https://github.com/snapcore/snapd/pull/8579>
 * zyga goes to make coffee ahead of the meeting
<cachio> zyga, thanks
<cachio> lets test it whith the new image once it is ready
<zyga> sure
<kyrofa> If someone runs `snap revert`, will it run the refresh hooks?
<ijohnson> kyrofa: afaik it won't
<kyrofa> ijohnson, any hooks? Any way the snap to which is being reverted can know that a revert happened?
<ijohnson> no, I think that's by design that the snap doesn't know it got reverted
<kyrofa> Fair enough, thanks ijohnson
<ijohnson> cmatsuoka: ah I think I understand the problem now
<ijohnson> cmatsuoka: what's happening is this sequence of events:
<ijohnson> 1. there is a systemd unit for running fsck on /dev/disk/by-label/ubuntu-seed that just always runs, so it happens to run first
<ijohnson> 2. snap-bootstrap via "the-tool" runs, says to mount /run/mnt/ubuntu-seed _with transient unit_ (that's important)
<ijohnson> 3. that fails because systemd-modules-load has not run, or finished running yet
<ijohnson> 4. so we see IO charset iso8859-1 not found from the kernel because nls_iso8859_1 was not loaded
<ijohnson> 5. systemd-modules-load eventually runs/finishes running and does load nls_iso8859_1: systemd-modules-load[238]: Inserted module 'nls_iso8859_1'
<ijohnson> 6. the-tool keeps running snap-bootstrap, which says to mount /run/mnt/ubuntu-seed, however because of how the-tool tries to do the mount, it just requests a transient unit for the mount
<ijohnson> 7. the transient unit was already started/created by systemd so systemd doesn't try again and just complains thusly: the-tool[380]: Failed to start transient mount unit: Unit run-mnt-ubuntu\x2dseed.mount already exists.
<ijohnson> 8. thus we get stuck in an infinite loop where the-tool never exits because the-tool doesn't run systemd-mount with set -e, it explicitly runs systemd-mount with set +e first, then turns set -e back on after running systemd-mount
<cmatsuoka> that makes perfect sense
<ijohnson> cmatsuoka: so I have a few thoughts on how to fix this, 1) make the-tool depend on systemd-modules-load, 2) make the-tool eventually give up (because since it never gives up systemd never allows a debug shell to be started either)
<ijohnson> 3) don't have a unit which runs fsck always on ubuntu-seed, instead have the-tool dynamically do that when snap-bootstrap requests something to be mounted
<ijohnson> wdyt?
<cmatsuoka> 2 looks like a good thing to have in case we run into problems again
<cmatsuoka> 1 + 2 maybe?
<ijohnson> yes actually I requested a very similar thing when mborzecki's original PR to ubuntu-core-initramfs was proposed, but I confused myself and said it wasn't a problem haha
<ijohnson> (for 2 that is)
<mborzecki> hahah
<cmatsuoka> well I'm very happy now that this mystery is solved
<mborzecki> it does make sense, i mean there's not gooing to me more than some limited number of mounts
<cachio> zyga, hey, I also see this error https://paste.ubuntu.com/p/gcw9dTrRGm/
<ijohnson> alright I will propose a PR to ubuntu-core-initramfs to fix this, but I was going to file a LP bug first to summarize all this, but seems LP just died, so I will have to do that later
 * ijohnson goes back to console-conf on core20 hacking
<zyga> ack
<zyga> cachio: please release the image anyway, I will send another change to address that
<cachio> zyga, ok
<mup> PR snapd#8579 closed: packaging: stop depending on python-docutils <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8579>
<cachio> mvo, hi, any idea about this ppa ? https://paste.ubuntu.com/p/ttF5CHt56X/
<ijohnson> cachio: launchpad is/was down for a bit
<cachio> ijohnson, ah, thanks
<mvo> cachio: looks like a LP issue
<cachio> mvo, yes
<cachio> thanks
<mup> PR snapd#8580 opened: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>
<mborzecki> any zsh users here?
<mup> PR snapcraft#3095 closed: plugins: break out rosdep resolve parsing for external use <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3095>
<mup> PR snapcraft#3098 opened: build providers: bootstrap with dirmngr <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3098>
<cmatsuoka> ijohnson: just hit the problem again here, and in the next boot it's gone
<ijohnson> cmatsuoka: yes I'm not sure what changed, but something seems to make it more likely to happen recently as I never saw it before yesterday
<cmatsuoka> and it seems that I'm having some dns issues with the store
<ijohnson> there was a big outage with launchpad a while ago that maybe propagated to the store? I dunno store seems a little slow but otherwise operational on my end
<cmatsuoka> right now I can't resolve snapcraft.io
<Lukewh> seems ok here cmatsuoka where are you based?
<cmatsuoka> I'm in brazil
<cmatsuoka> oh, and now it's back
<cmatsuoka> a few days ago there were some routing problems from brazil to the rest of the world so it can be something weird on my side again
<mup> PR snapcraft#3099 opened: repo: always refresh cache when build packages are required <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3099>
<cmatsuoka> oh, it seems that the ipv4 addresses are resolving correctly but AAAA is not for some reason
<cmatsuoka> anyway, let's just use ipv4
<zyga> I will fix the damn pulseaudio test tomorrow
<zyga> now that other stuff is not red anymore
<mup> PR snapd#8565 closed: osutil: expand FileLock to support shared locks and more <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8565>
<zyga> \o/
<zyga> thank you Ian :)
<cjwatson> ijohnson: it was a Canonical network issue, not specifically LP, so there'll have been various bits of fallout
<ijohnson> yaw zyga
<ijohnson> cjwatson: yeah that's kinda what I expected
<cjwatson> (GS2 I think)
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8566/files is next on the r-a-a pipe
<zyga> but it has probably-poor names
<mup> PR #8566: cmd/cmdutil: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<zyga> I was split between lock naming
<zyga> and totally not lock naming
<ijohnson> mmm zyga does that need samuele review for names?
<zyga> ijohnson: for sure but we can do the technical review
<ijohnson> ack will try to get to it today, but probably that one will have to wait for tomorrow
<zyga> ijohnson: or maybe better this:
<zyga> https://github.com/snapcore/snapd/pull/8571
<zyga> this is self-sufficient
<mup> PR #8571: overlord/snapstate: warn of refresh/postpone events <Created by zyga> <https://github.com/snapcore/snapd/pull/8571>
<zyga> and useful today
<zyga> and actually tiny apart from tests :)
<zyga> just two print-like calls
<zyga> but I should EOD
<zyga> or I'll start sending more things
 * zyga waves
<ijohnson> haha
<ijohnson> have a good night zyga
<zyga> one last thing: https://github.com/snapcore/snapd/pull/8572#event-3283181589
<zyga> I like this line
<mup> PR #8572: packaging: add the inhibit directory <Created by zyga> <https://github.com/snapcore/snapd/pull/8572>
<zyga> "via automation"
<zyga> meh
<zyga> I fixed the stupid test
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8581 draft for now
<mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
<mup> PR snapd#8581 opened: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
<zyga> so, session-tool on 16.04 - it needs to start doing upstart things, I guess
<ijohnson> sad
<ijohnson> that's unfortunate
 * ijohnson EODs early
<mup> Issue core20#48 closed: python3 from base causes segfault for confined snaps on armhf <question> <Created by sergiusens> <Closed by xnox> <https://github.com/snapcore/core20/issue/48>
#snappy 2020-04-30
<mup> Bug #1871827 opened: git ubuntu submit fails on focal <snap> <submit> <Snappy:New> <usd-importer:New> <https://launchpad.net/bugs/1871827>
<zyga> https://github.com/snapcore/snapd/pull/8581/checks?check_run_id=631328561 <- persistent journal failed
<mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
<mup> PR snapd#8582 opened: github: register matchers before running spread <Created by zyga> <https://github.com/snapcore/snapd/pull/8582>
<pstolowski> morning
<mvo> hey pstolowski
<pstolowski> mvo: hi! how is the sprint going?
<zyga> hey guys
<zyga> I'm doing some test fixes
<zyga> pstolowski: do you have backscroll?
<zyga> pstolowski: can you see my message at 7:58?
<pstolowski> zyga: i don't have it
<zyga> https://github.com/snapcore/snapd/pull/8581/checks?check_run_id=631328561 <- persistent journal failed
<mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
<zyga> the failure is silly but wonder why
<pstolowski> zyga: yeah it consistent with the previous failures, no idea. looks like snapd gets restarted (or crashes) during configure hook. i will think about a debug section for this test. thanks
<zyga> is there something in the logs?
<pstolowski> zyga: nothing obvious, "Running task 84 on Do: Run configure hook of "core" snap" is the last task run, and snap set fails with 'error: cannot communicate with server: Put http://localhost/v2/snaps/core/conf: EOF'
<zyga> hmm
<zyga> what ran before?
<pstolowski> it's just snap set with true/false in this test
<zyga> can you report a bug with the failure fragment, the list of tests that ran before and any additional insight
<zyga> I mean tests that ran on this machine before this one
<pstolowski> ah, that
<pstolowski> yep, good idea
<pstolowski> main/cgroup-devices is right before it
<zyga> add the complete list
<zyga> maybe next time we
<zyga> maybe next time we'll know more
 * zyga -> breakfast
<pstolowski> done, https://bugs.launchpad.net/snapd/+bug/1876053
<mup> Bug #1876053: occasional spread test failure on core-persistent-journal <snapd:Confirmed> <https://launchpad.net/bugs/1876053>
<zyga> thanks!
<zyga> one day we'll learn and understand :)
<pstolowski> in the initial version of this code i was restarting journal service which had an undesired effect of restarting snapd during configure hook, but now it's misterious as there is no direct interaction with systemd, just removing/creating journal dir
<zyga> do you know why restarting journal restarts snapd?
<zyga> is it just snapd that is being restarted in that case?
<pstolowski> dunno
<zyga> pstolowski: hmm, perhaps we can do a small experiment with a simple service and see what happens
<zyga> maybe it's documented
<zyga> I think we ought to know, feels wrong to ship this to devices with potential for failure
<zyga> offtopic: https://thepihut.com/products/raspberry-pi-high-quality-camera-lens !!! :)
<zyga> i'm so getting this
<zyga> and setting up a monitoring with a pi :)
<zyga> and botland has it
<zyga> https://botland.com.pl/pl/szukaj?controller=search&orderby=position&orderway=desc&search_query=Nowa+kamera+do+Raspberry+Pi&submit_search=
<mborzecki> morning
<zyga> mborzecki: hey
<mvo> pstolowski: when you have a couple of minutes, could you please double check trello doing? just making sure it's a bit more up-to-date
<pstolowski> mvo: sure
<mvo> pstolowski: fwiw, the current trello has a bit too many lanes, this will get cleaned in the following days, so don't worry if it's a bit crowded :)
<zyga> I need reviews for https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> it's super close and I'd love to land it this week
<mborzecki> zyga: can yuo remind me whether the session-tool stops the session after the command exits?
<zyga> no, because --prepare enables linger and --restore disables linger
<zyga> what are you seeing?
<mborzecki> so `session-tool -u test --restore` will kill the session then in restore right?
<zyga> yes
<zyga> it would be good to focus on making master less red
<zyga> something broke in debian-sid now, we cannot compile our golang+C tests
<zyga> would be worth taking a look,
<zyga> I can in ~3-4 hours
<zyga> but perhaps someone can fix it faster
<mborzecki> zyga: got log?
<zyga> mborzecki: plenty, check any of my latest PRs
<zyga> mborzecki: asm/geneeric.h is missing or something like that
<zyga> mborzecki: it fails each time
<zyga> mborzecki: on tests/unit/go
<mborzecki> master seems to be green
<zyga> mborzecki: nope, it's red red red here :)
<zyga> mborzecki: or did it magically go away just as it showed up?
<mborzecki> zyga: https://github.com/snapcore/snapd/commits/master looks green
<zyga> mborzecki: try debian-sid-64:tests/unit/go
<zyga> the tick is confusing
<zyga> it's just travis
<mborzecki> w8, what's that tick?
<zyga> we don't run spread there
<mborzecki> pfff
<mborzecki> yeah
<zyga> yeah
<mborzecki> omg
<zyga> ?
<mborzecki> so, the gh actions only runs on PRs
<zyga> yes
<zyga> we configured that deliberately
<mborzecki> ok, so we do not run spread on master then
<zyga> otherwise everything costs x2 more
<zyga> we said we should extend that to run on all landings to release branches
<zyga> as we land things regularly it's a reasonable tradeoff
<mup> PR snapd#8583 opened: tests: add debug to core-persistent-journal test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
<mborzecki> 2020-04-29T17:55:01.8596162Z + su -l -c 'XDG_RUNTIME_DIR="/run/user/12345" DBUS_SESSION_BUS_ADDRESS="" test-snapd-desktop.cmd xdg-open http://www.example.org' test
<mborzecki> 2020-04-29T17:55:01.8596782Z user-open error: exec: "dbus-launch": executable file not found in $PATH
<mborzecki> heh, on sid
<zyga> mborzecki: I really want to burn user.sh and the hacks with fire
<zyga> all those XDGD_RUNTIME_DIR=... things are so bogus
<zyga> mborzecki: I have a patch that moves one more tests over
<zyga> maybe I can remove all of them today
<zyga> I'm stuck on "serious" reviews anway
<mborzecki> ok, let me see what i can do about that snap-seccomp unit test failing on sid
<zyga> thanks!
<zyga> one by one
<zyga> and we can ask mvo to merge despite other failures
<zyga> I'd love to end the week with totally green master
<zyga> so that next week is not like a torture :/
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/8580 ? or even try it out if you have zsh installed
<mup> PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>
<zyga> mborzecki: sure
<mborzecki> just dropping _snap file into /usr/share/zsh/vendor-completions/ should do the trick
<mborzecki> or site-functions on other non deb distros
<mborzecki> now that it works locally i see i've been missing out on some goodies :P
<mborzecki> btw the zsh documentation is awful
<zyga>   that doesn't seem to work
<zyga> I installed that on my system
<zyga> invoked zsh
<zyga> and nothing
<zyga> in comparison other completers work ok
<zyga> reviewed
<mborzecki> hmmm
<zyga> also packaging seems to be broken
<zyga> (check the various error logs)
<mborzecki> heh, forgot to list the file for opensuse
<zyga> check the suse error
<zyga> it says something is listed twice
<zyga> maybe a drive-by
<mborzecki> zyga: https://asciinema.org/a/wXGEu1Ky2To2osTCJ8Wl1rD8b
<zyga> weird
<zyga> that's not what I'm seeing
<zyga> I'll recheck
<mborzecki> zyga: on ubuntu you need to move it to /usr/share/zsh/vendor-completins/_snap (with _)
<zyga> that's where I put it
<zyga> I naively tried to debug it by sourcing
<zyga> fyke% source _snap
<zyga> _setup:37: compstate: assignment to invalid subscript range
<mborzecki> no, it won't work that way :)
<zyga> I don't know how to debug it
<mborzecki> zyga: that's on opensuse?
<zyga> no, focal
<zyga> weird, right
<zyga> but I didn't set shell to zsh
<zyga> just execed zsh
<zyga> maybe that's why?
<mborzecki> idk, maybe you need to enable completion? try `autoload -Uz compinit ; compinit` ?
<zyga> it works for everything else in that directory
<zyga> all the other commands generate completios
<zyga> *completions
<mborzecki> zyga: did you wget/curl the file or pasted it?
<zyga> ...
<zyga> pasted
<zyga> is that relevant?
<zyga> Omg :D
<mborzecki> check whether the first line is `#compdef snap`
<zyga> it is
<mborzecki> idk, wget https://raw.githubusercontent.com/snapcore/snapd/060556f7adcf748546cd7c3c97f3254f0bd58644/data/completion/_snap ? :)
<zyga> same result
<mborzecki> pfff idk then
<zyga> can you try?
<mborzecki> you could try an wipe ~/.zshrc if you're not to used to it and start over
<zyga> I mean, just spawn focal (multipass) and put that file
<zyga> mborzecki: my zshrc is empty
<mborzecki> zyga: that asciinema is on 20.04
<zyga> mborzecki: yes but from spread
<zyga> mborzecki: maybe there's a more magic button somewhere
<mborzecki> ah, ok
<mborzecki> zyga: yup, works
<zyga> IDK
<zyga> let's ship it then ;D
<zyga> I tried setting the GO_... variable for completions and that does print stuff
<zyga> did you exec zsh or did you do something more elaborate?
<mborzecki> zyga: rm ~/.zshrc and run zsh again, that should suggest using the default config
<zyga> tried
<zyga> doesn't fix this issue :)
<zyga> zyga@fyke ~ % snap inst
<zyga> Completing `file' or `corrections'
<zyga> I hit <tab> at inst<tab>
<mborzecki> zyga: gcc-multilib isn't installed in sid images
<mborzecki> zyga: that's why the unit test fails
<zyga> cool, ping me for a patch
<mborzecki> btw. i don't understand why test/unit build and install the snapd package
<zyga> mborzecki: weird
<zyga> probably for no reason at all?
<mborzecki> that's a huge waste of time
<zyga> I also wonder where we waste time
<zyga> run 10 tests on a single machine
<zyga> with -repeat 10
<zyga> that does "true"
<mborzecki> also, building the package runs unit tests /o\
<zyga> it's incredibly slow
<zyga> we are probably wasting loads of time doing something silly somewhere
<mborzecki> uff, at least we pass nocheck to deb-bp
<mborzecki> dpkg-buildpackage
<mup> PR core#113 opened: Makefile: conditionally use the "edge" PPA in live-build <Created by mvo5> <https://github.com/snapcore/core/pull/113>
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8584
<mup> PR #8584: packaging/debian-sid: add gcc-multilib to build deps <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8584>
<mup> PR snapd#8584 opened: packaging/debian-sid: add gcc-multilib to build deps <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8584>
<zyga> mborzecki: are we running tests on debian?
<zyga> as in, unit tests while building the debian sid package?
<mborzecki> zyga: it was the one that failed in this test
<pstolowski> #8537 needs 2nd review
<mup> PR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>
<mborzecki> pstolowski: trying to review that since morning
<mborzecki> zyga: there's only a bunch of systems we don't run unit tests on: [-ubuntu-core-*, -fedora-*, -opensuse-*, -arch-*, -amazon-*, -centos-*]
<zyga> mborzecki: my question was different, we had a missing dependency, how come it didn't come up when building snapd in a pristine environment of a buidd?
<zyga> mborzecki: are we running unit tests on package build on debian?
<mborzecki> zyga: perhaps gcc-multilib is one of base dependencies already included?
<mborzecki> zyga: which test runs buildd? i don't see one
<zyga> mborzecki: perhaps :)
<zyga> mborzecki: I mean "make check" style
<zyga> go test ./...
<mup> PR snapd#8585 opened: release: 2.44.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8585>
<mborzecki> zyga: prepare sets nocheck in DEB_BUILD_OPTIONS, there's a nightly test that runs sbuild, but nobody looks at the result?
<zyga> heh
<zyga> ok
<zyga> thanks for fixing htis
<zyga> *this
<mborzecki> zyga: where are the nightly test results?
<zyga> replied to https://github.com/snapcore/snapd/pull/8581
<mup> PR #8581: tests: port pulseaudio test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8581>
<zyga> I have no idea
<zyga> probably nowhere
<zyga> just read the travis runs
<mborzecki> cachio probably knows
<mborzecki> zyga: so mvo pointed me to where the nightly tests are and as suspected sbuild test was failing, but even before it reached the package build step /o\
<zyga> heh
<zyga> where are the results?
 * pstolowski lunch + errand
<mborzecki> zyga: https://travis-ci.org/github/snapcore/spread-cron/branches and look for nightly
<zyga> mmm
<zyga> thanks
<mborzecki> hm, we don't install sbuild and then run sbuild in the test
<mborzecki> perhaps sbuild is no longer in the sid image?
<zyga> IIRC we did but perhaps we stopped
<zyga> for efficiency?
<mborzecki> idk, let me check that test
<mborzecki> hm sbuild is installed, wth?
<doko> next chromium issue: https://bugs.launchpad.net/snapd/+bug/1876083
<mup> Bug #1876083: chromium snap from focal fails DNS lookups, or delays them <snapd:New> <https://launchpad.net/bugs/1876083>
<zyga> doko: in your report you said "that is using IPv6 only" - what do you mean by that?
<mborzecki> hm idk, looks like sbuild-createchroot is broken
<doko> zyga: my provider is doing IPv6 by default
<zyga> I see
<zyga> doko: what are the consequences of that, that you don't have an ipv4 address? that you cannot resolve ipv4 domains?
<doko> no, I have an ipv4 address
<zyga> mborzecki: we should nuke fedora 28, 29
<zyga> and perhaps 30
<zyga> and just have 31 and 32
<mborzecki> 30 is eol in a mongth?
<zyga> I will look after I wrap up this task
<zyga> mborzecki: yeah, they go very quickly
<zyga> the nature of fedora community is to move on
<mborzecki> zyga: fwiw, the examples in sbuild-createchroot manpage don't work either, pfff
<zyga> mborzecki: haha
<zyga> I was in that same boat
<zyga> mborzecki: with my recent debian maintainer hat
<zyga> mborzecki: the wiki is broken
<zyga> mborzecki: but also all of the tools behave different if they detect debian vs ubuntu
<zyga> which is enormously confusing
<mborzecki> eh, a wall of perl code :*
<mborzecki> :(
<zyga> heh
<zyga> if that helps I have a magic line that gives you a working cowbuilder
<zyga> it's really really great
<zyga> and I use it for git-buildpackage
<zyga> but most of the documentation is broken
<zyga> and there is some overlap between those tools that doesn't help
<zyga> btw, I need to thank stgraber and the team
<zyga> lxd is really amazing
<zyga> it's revolutionized how I think about systems
<zyga> and the container registry is fantastic
<zyga> I would love to have a vagrant-like tool for lxd
<zyga> that bridges a project directory to the container ootb
<cachio> zyga, hey
<zyga> hey
<cachio> I was trying to merge the no recommends branch
<cachio> zyga, but I see these errors https://paste.ubuntu.com/p/BhXjghQ6Nh/
<cachio> https://paste.ubuntu.com/p/hNRPxH7n6D/
<cachio> both in the same test
<cachio> zyga, I already tried with other dependencies
<cachio> any idea what could be the cause?
<zyga> lack of /lib/systemd/user/dbus.socket
<zyga> I rewrote this test (though I haven't pushed it as I'm working on a prerequisite)
<zyga> is that the only failure?
<cachio> zyga, yes
<zyga> do you have a debug shell?
<cachio> no, let me create it
<zyga> is dbus-user-session installed?
<cachio> no
<cachio> but it pass in other systems where it is not installed
<zyga> ah, I missed that there are two test failures
<cachio> zyga, yes, different
<zyga> dbus-launch is a separate problem
<zyga> the tests are really written in a way that won't work
<zyga> I'm working on porting them over
<cachio> zyga, I can disable it for those systems
<cachio> and then we fix it
<cachio> zyga, does it make sense?
<zyga> can you add a comment like "TODO:session-tool: port and re-enable"
<zyga> yeah
<zyga> cachio: do you know if we are using different instances by any chance?
<zyga> we've noticed that tests are much slower today
<cachio> zyga, no
<cachio> same
<zyga> ok
<cachio> zyga, I'll check
<zyga> mborzecki: ^^ what do you think about the comments to disable the two tests sergio mentioned
<zyga> cachio: today I'm going through failing tests and porting to session-tool, to unbreak from random annoying failures
<zyga> so at some point I'll go through all the user.sh users and make them more robust
<cachio> yes
<cachio> zyga, it caused several issues already
<cachio> zyga, pushed the change nad added the comment in both tests disabled
<zyga> thanks
<cachio> just disabled the failinf systems
<cachio> not the test
<zyga> do you need a review for the test changes?
<zyga> cachio: uh, that's a bit heavy, I think we should not disable debian-sid
<cachio> it is already  apporoved
<zyga> 19.10 is a different story and I would not mind dropping it TBH
<zyga> cachio: oh? where is it?
<cachio> zyga #8468
<mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
<zyga> cachio: ah, ok,
<zyga> I misunderstood what you said
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8468#pullrequestreview-403460795
<mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
<mborzecki> zyga: yay, Chipaca is presenting ;)
<zyga> watching :)
<mborzecki> zyga: thanks for spotting, i left a comment there
<zyga> cool!
<doko> jdstrand: thanks, but now I'm facing LP: #1876083
<mup> Bug #1876083: chromium snap from focal fails DNS lookups, or delays them <snapd:New> <https://launchpad.net/bugs/1876083>
<doko> oops, wrong channel
<mborzecki> mvo: can we merge https://github.com/snapcore/snapd/pull/8584 ? we'll need another PR for the xdg-desktop-portal test
<mup> PR #8584: packaging/debian-sid: add gcc-multilib to build deps <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8584>
<mborzecki> (needs your superpowers)
<mvo> sure
<mvo> ta
<mup> PR snapd#8584 closed: packaging/debian-sid: add gcc-multilib to build deps <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8584>
<mborzecki> mvo: thank you!
<zyga> small improvement to session-tool, will replace some hand-crafted checks elsewhere: https://github.com/snapcore/snapd/pull/8586
<mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
<mup> PR snapd#8585 closed: release: 2.44.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8585>
<mup> PR snapd#8586 opened: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
<zyga> currently a draft, running one more pass of the full set, will open shortly
<mborzecki> google:debian-sid-64:tests/main/xdg-open-portal fails in a weird way
<mborzecki> user-open error: exec: "dbus-launch": executable file not found in $PATH
<zyga> mborzecki: yeah, we looked at this
<zyga> mborzecki: cachio disabled this test, it's on my list to port next
<mborzecki> zyga: i replaced some bits with session tool, but i tlooks like the user dbus is not started
<zyga> yeah, I know
<zyga> my test actually shows that :)
<mborzecki> i'm probably doing something wrong here
<zyga> dbus-session-bus is not preinstalled
<zyga> presumably --no-install-recommends
<cachio> cmatsuoka, using new snapd still getting stuck https://paste.ubuntu.com/p/gScx3yH59y/
<cachio> cmatsuoka, line 1353
<cachio> is the last I see
<cmatsuoka> let me see...
<cachio> thanks
<cmatsuoka> cachio: this is happening in graham's image as well
<cachio> cmatsuoka, ahh
<cmatsuoka> cachio: did you inject snap-bootstrap into the initramfs?
<cachio> cmatsuoka, yes
<cmatsuoka> I'm investigating here to see what could be happening
<mborzecki> zyga: ok, fixed the portal-open test, but other portal tests need fixing too now
<cachio> cmatsuoka, I am running repack_snapd_snap_with_deb_content_and_run_mode_firstboot_tweaks
<zyga> mborzecki: ok
<cachio> for the image
<cmatsuoka> mborzecki: I moved the TPM-related stuff from initramfs-mounts to secboot in PR #8577, could you have a look when you have time? It's trying to not expose TPM to initramfs-mounts so it could work later with a TrustZone-based solution as well
<mup> PR #8577: [RFC] secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8577>
<mborzecki> cmatsuoka: sure
<mborzecki> zyga: i think i've ported the portal tests now
<zyga> mborzecki: to session-tool? :-)
<mborzecki> yeah
<zyga> \o/
<zyga> awesome
<zyga> push that!
<zyga> I'm looking at the user-env test
<zyga> I mean, I ported it but I'm adding some more bits before that can be proposed
<zyga> I have a working branch that removes user.sh
<zyga> and just fixes stuff that breaks
<zyga> mborzecki: did you port all of the portal tests?
<mborzecki> zyga: xdg-open-portal and desktop-portal-{filechooser,screenshot,open-file,open-uri}
<zyga> awesome
<zyga> ijohnson: I pushed to https://github.com/snapcore/snapd/pull/8586 and opened it normally now
<mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
<zyga> ijohnson: I made a small change to move the test to a new task
<zyga> ijohnson: and I highlighted that https://github.com/snapcore/snapd/pull/8586/files#diff-e14795fd89d2bab1c7f6486851d463c0R15 sid has no session support somehow
<zyga> this test is nice because it will show us changes in the distros
<mborzecki> cmatsuoka: i think you added some standup notes under friday (tomorrow)
<ijohnson> that's awesome very nice
<zyga> I was thinking to move tumbleweed, sid and arch to unstable
<ijohnson> is arch unstable ?
<zyga> so that they reflect the unstable nature of the distributions they are
<ijohnson> arch seems to be relatively stable for us recently I think
<ijohnson> maybe I'm wrong though
<zyga> so that we can get a heads up in case it affects the rest of the stack over time
<zyga> ijohnson: yeah, it's relatively stable
<zyga> but the point is not the measure our feeling about snapd in that distribution
<zyga> but to measure the stability of the distribution - in the sense of debian stable
<zyga> not sure if this makes sense to you
<zyga> since those distributions move rapidly they can change like the wind at a seaside town :)
<mup> PR core18#152 opened: Make .disk/info visible on the root partition <Created by sil2100> <https://github.com/snapcore/core18/pull/152>
<cmatsuoka> mborzecki: I'm starting my annotations for the next day after the current SU to be in sync with people that have SU at the end of the day
<cmatsuoka> (so the activities between SUs can be reviewed in the next SU)
<zyga> ijohnson: one more small improvement, https://github.com/snapcore/snapd/pull/8587
<mup> PR #8587: tests: session-tool allows preparing/restoring for many users <Created by zyga> <https://github.com/snapcore/snapd/pull/8587>
<zyga> this will be used by changed user-env test
<mup> PR snapd#8587 opened: tests: session-tool allows preparing/restoring for many users <Created by zyga> <https://github.com/snapcore/snapd/pull/8587>
<zyga> that has test and test-zsh users
<mup> PR snapd#8588 opened: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
<mborzecki> zyga: ^^
<zyga> looking
<zyga> mborzecki: the pkg change is tricky, I would rather depend on it in snapd
<zyga> mborzecki: otherwise we are testing something and users are running something else
<zyga> mborzecki: wdyt?
<mborzecki> zyga: suggests/reccomends?
<zyga> yeah
<zyga> suggests seems ok
<zyga> or recommends
<zyga> though we no-install-recommends
<zyga> heh :)
<zyga> not sure
<mborzecki> aren't we suggsting/recommending portals already?
<zyga> just don't want to let it slip like that
<zyga> if we do we should bundle dbus in the same set
<mborzecki> i would expect that to pull in relevant dbus packages
<om26er> popey ping! I believe this will need your "blessings" https://forum.snapcraft.io/t/auto-connection-request-for-easy-installer/17063
<zyga> the portal teardown should happen beore --restore
<zyga> inside the portals you can probably remove loads of redudancy as well
<popey> om26er bless you
<zyga> it still calls start_user_session
<zyga> and uses as_user
<zyga> mborzecki: ^ review here :)
<cmatsuoka> degville, cachio: something changed between gadget 96 and 98 that's causing the problem
<mborzecki> zyga: portals teardown removes files and so on, it should probably be done after we know that session is stopped
<zyga> mborzecki: look closer
<zyga> it does more
<zyga> purge_user_session-data
<zyga> and stop_user_session
<zyga> I think those two must go
<degville> cmatsuoka: ah, thanks for the update.
<cmatsuoka> degville: I'll diff them to see what changed
<ijohnson> cmatsuoka: could it be https://github.com/snapcore/pc-amd64-gadget/pull/45 ?
<mup> PR pc-amd64-gadget#45: Use UC20 signed grub <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/45>
<popey> om26er I'll take a look
<cmatsuoka> ijohnson: it looks very suspicious
<zyga> mborzecki: reviewed but it's the same as I said here
<ijohnson> cmatsuoka: indeed
<om26er> popey thanks. I am in touch with the upstream, I was asked to help with snap packaging. After quite a few iterations we came to the point of pushing it to store.
<zyga> mborzecki: thank you so much for pushing this :)
<mborzecki> zyga: hmm not sure which portal helpers, there's only 2 of those, and they no longer start or stop session
<cachio> cmatsuoka, ahhh
 * zyga looks
<cmatsuoka> ijohnson: this looks suspicious too:
<zyga> mborzecki: doh!
<zyga> I'm blind
<zyga> this is so weird
<cmatsuoka> -    - shim-signed=1.41+15+1552672080.a4a1fbe-0ubuntu1
<cmatsuoka> -    - shim=15+1552672080.a4a1fbe-0ubuntu1
<cmatsuoka> +    - shim-signed=1.40.3+15+1533136590.3beb971-0ubuntu1
<cmatsuoka> +    - shim=15+1533136590.3beb971-0ubuntu1
<zyga> I didn't see this file before :)
<cachio> cmatsuoka, I'll try in that case by using the pc snap from stable
<ijohnson> cmatsuoka: so the version of shim was reverted to an older one?
<zyga> mborzecki: +1
<popey> om26er it's a really nice looking app!
<cmatsuoka> ijohnson: it seems so, and if this older one is the one without chris coulson's patches, it would fail like that
<zyga> mborzecki: can you remove . user.sh in desktop-portal.sh?
<ijohnson> cmatsuoka: yeah makes sense probably needs a comment from Dmitri
<cmatsuoka> ijohnson: I pinged him about that
<ijohnson> ack
<cmatsuoka> degville, cachio: bad shim in recent gadgets, dimitri is fixing it
<zyga> mborzecki: superb
<zyga> mborzecki: we will have much fewer users of user.sh
<cachio> cmatsuoka, awesome
<degville> cmatsuoka: thank you!
<cachio> cmatsuoka, the fun part is that I tried with older snapd snap, pckernel snap and core20 snap
<cachio> cmatsuoka, but didnt try with older pc snap
<cmatsuoka> when unlock fails, the prime suspects are the command line and shim, and they're both from gadget
<zyga> mborzecki: once your branch lands this will be fixed, right?
<zyga> https://github.com/snapcore/snapd/pull/8586/files#diff-e14795fd89d2bab1c7f6486851d463c0R19
<mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
<zyga> debian-sid-*/test exception will disappear
<pstolowski> how do i restart github actions if they seem to be stuck? https://github.com/snapcore/snapd/pull/8583
<mup> PR #8583: tests: add debug to core-persistent-journal test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
<zyga> pstolowski: looking
<zyga> close and reopen
<zyga> I saw that once before
<zyga> seems like event got lost
<pstolowski> mhm
<pstolowski> ok,thanks
<zyga> queued :)
<zyga> and in progress
<zyga> I'll break now
<zyga> back hurts
<pstolowski> magic
<zyga> magic? :)
<zyga> could you ask mvo to merge the two session-tool improvements once they are green enough
<zyga> I have more follow ups that this enables
<zyga> mborzecki: I approved https://github.com/snapcore/snapd/pull/8580#pullrequestreview-403616086
<mup> PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>
<zyga> but there's a conflict now
<zyga> mborzecki: maybe move pkgver next to pgkname
<zyga> so that it conflicts less frequently
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8576#pullrequestreview-403618621
<mup> PR #8576: tests/main/lxd: add test for snaps inside nested lxd containers not working <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8576>
<pstolowski> anyone up for #8583? needs 2nd review, it's a simple test change
<mup> PR #8583: tests: add debug to core-persistent-journal test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
<zyga> pstolowski: perhaps just ask mvo, master is broken now so you will nedd an override anyway
<morphis> zyga, mvo: have you guys seen any problems with snapd in lxd with focal images? running into https://pastebin.canonical.com/p/SkdNKHCyNy/
<morphis> snapd seems to fail to initialize the system
<zyga> morphis: can you do snap tasks 1 or [345]
<zyga> I don't think we've seen this
<morphis> https://pastebin.canonical.com/p/fwChrpCB49/
<morphis> didn't knew `snap tasks` gives you that level of details
<morphis> this is a LXD container with: https://pastebin.canonical.com/p/fQJHJq5R6t/
<morphis> which works fine for bionic
<zyga> morphis: so the preinstall hook fails
<zyga> hmmm
<zyga> er, install hook
<zyga> 2020-04-30T14:58:46Z ERROR run hook "install": cannot perform operation: mount --rbind /var/lib/dhcp /tmp/snap.rootfs_hzQTBP//var/lib/dhcp: Permission denied
<zyga> oh
<zyga> that's new!
<zyga> this is surprising
<zyga> morphis: do you have denials?
<zyga> on the host container
<zyga> container host
<zyga> jdstrand: ^ remember this?
<zyga> I wonder if there's a regression that the lxd profile doesn't allow snapd to perform this
<morphis> zyga: let me check
<zyga> morphis: does it go away if you rmdir /var/lib/dhcp in the machine that you "snap install lxd" on?
<zyga> we won't try it then
<morphis> zyga: https://pastebin.canonical.com/p/NHKWyxpwQj/
<morphis> let me check
<zyga> [ 1113.914649] audit: type=1400 audit(1588259357.291:359): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_de7sTW/var/lib/dhcp/" pid=61879 comm="snap-confine" srcname="/var/lib/dhcp/" flags="rw, rbind"
<morphis> that looks like it
<jdstrand> what's up with locking /dev/null?
<morphis> but the container has lxc.apparmor.profile=unconfined so I wouldn't expect that
<zyga> hmmm
<zyga> is that supported for snapd?
<zyga> I'm never sure what the various lxd configuration options do
<zyga> and which disable nested apparmor
<zyga> jdstrand: maybe libc?
<morphis> we have a lxd-profile.yaml in our lxd charm which adjusts the container config, k8s does the same AFAIK
<morphis> https://github.com/charmed-kubernetes/charm-kubernetes-master/blob/master/lxd-profile.yaml
<jdstrand> I've never seen that before
<zyga> we have this rule:
<zyga>     mount options=(rw rbind) /var/lib/dhcp/ -> /tmp/snap.rootfs_*/var/lib/dhcp/,
<zyga>     mount options=(rw rslave) -> /tmp/snap.rootfs_*/var/lib/dhcp/,
<zyga> which should cover the dhcp directory you had
<zyga> I wonder what's wrong there
<zyga> morphis: can you file a bug with repro instructions,
<jdstrand> I'm going into a meeting, but if you set lxc.apparmor.profile=unconfined, I'm not sure the profile stacking is going to work correctly
<morphis> zyga: rmdir /var/lib/dhcp doesn't seem to help
<jdstrand> that is a stgraber question
<morphis> now it runs into: 2020-04-30T15:28:45Z ERROR run hook "install": cannot open file /sys/fs/cgroup/freezer/snap.lxd/cgroup.procs: Permission denied
<zyga> morphis: it's late today and I wanted to focus on some more bits but I will try to look either later today or on Monday (I'm off tomorrow)
<morphis> zyga: sounds good!
<zyga> morphis: I'm suspecting this is an unsupported config, please make sure to loop in stgraber
<morphis> jdstrand: will check with him later
<jdstrand> this is because the policy is shared between the host and the container I think
<zyga> and we should document this somehow
<jdstrand> because there is no stacking
<zyga> yeah, I think jamie is spot on
<jdstrand> yikes
 * jdstrand -> meeting
<morphis> just wondering as this worked well for bionic
<jdstrand> yeah, I forget otoh the details of how lxd sets up the profile stacking
<jdstrand> but this sounds like what I described
<zyga> morphis: some incorrect configurations do seem to work
<zyga> morphis: but not by design
<zyga> and it depends heavily by what is on the container
<pstolowski> zyga: what's broken in master now?
<zyga> pstolowski: a few tests
<zyga> pstolowski: but those are all with PRs now I think
<zyga> pstolowski: your branch will likely fail on them
<zyga> pstolowski: watch https://github.com/snapcore/snapd/pull/8588 :)
<mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
<zyga> maybe it will be green
<zyga> then we can just work normally again
<pstolowski> great
<pstolowski> ty
<cachio> cmatsuoka, I used the pc 93 and I see the same problem
<morphis> zyga, jdstrand: dropping "lxc.apparmor.profile=unconfined" fixes it
<zyga> great :)
<zyga> mvo: could you please override/merge https://github.com/snapcore/snapd/pull/8586
<mup> PR #8586: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <https://github.com/snapcore/snapd/pull/8586>
<zyga> it's +2 and it fails on a known debian-sid failure maciek has fixed in a separate branch
<zyga> thanks!
<mup> PR snapd#8586 closed: tests: add session-tool --has-systemd-and-dbus <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8586>
<zyga> mborzecki: can you merge master into https://github.com/snapcore/snapd/pull/8588 and remove the debian-sid-*/test exception from tests/main/session-tool-support
<mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
<zyga> mborzecki: or I'll just open a follow-up as soon as this lands
<zyga> opensuse has fails on degraded systemd unit
<zyga> I had a look and it both looks familiar
<zyga> and weird
<zyga> not sure if we can just disable that service?
<zyga> it's something related to tty, let me check...
<cmatsuoka> cachio: 96 should work
<cachio> cmatsuoka, it is not published anymore right?
<cmatsuoka> cachio: no, the current one is 98
<mup> PR snapd#8589 opened: tests: port user-session-env to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8589>
<zyga> ijohnson: I opened one more https://github.com/snapcore/snapd/pull/8589 <- I'm somewhat worried about 14.04 test coverage thourh, not sure if this is something I should bring back with a separate test that just tests "env"
<mup> PR #8589: tests: port user-session-env to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8589>
<zyga> ijohnson: actually, the realization that 14.04's systemd build is *not* connected to dbus was my biggest worry/surprise recently
<zyga> ijohnson: I don't think we really had this internalized before
<jdstrand> morphis: glad to hear
<zyga> mborzecki: I think we have only one user of user.sh left
<zyga> once that is gone I will update the PR from jamesh
<zyga> jamesh: ^ if you are reading backlogs, we are working on removing user.sh hacks
<zyga> jamesh: but we don't want to leave you on ice
<stgraber> morphis: lxc.apparmor.profile=unconfined will break apparmor, don't do that
<stgraber> morphis: and that would indeed cause breakage for the snap
<morphis> yeah, makes sense
<morphis> something we should fix at https://github.com/charmed-kubernetes/charm-kubernetes-master/blob/master/lxd-profile.yaml#L5 as well unless they use it different
<zyga> morphis: imperfect but interesting https://github.com/search?l=&q=lxc.apparmor.profile%3Dunconfined+language%3AYAML&type=Code
<zyga> jdstrand: ^ all the unconfined lxds
<zyga> stgraber: do you know if there's a way for snapd to detect that it's running in lxd and that lxc.apparmor.profile=unconfined has been set?
<stgraber> zyga: it's doable, yeah
<mborzecki> zyga: updated #8588
<mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
<zyga> looking
<mborzecki> and feel a bit dizzy, just traversed through QDesktopServices down to xdgDesktopPortalOpenFile() and omg
<zyga> mborzecki: I think you need to drop the sid fragment now
<zyga> mborzecki: because your PR adds the dbus-user-session package to sid
<zyga> and that will be detected by tests/main/session-tool-support
<zyga> mborzecki: what did you find?
<stgraber> zyga: if /sys/kernel/security/apparmor/.ns_level doesn't exist or is < 1 + /proc/self/attr/current is unconfined
<mborzecki> zyga: i think there's a bug in the portal handler, https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI states that calling that with file:// fails (by design), while the QDesktopServices::openURL() calls that for file://
<stgraber> zyga: that should indicate lxc.apparmor.profile=unconfined I think
<zyga> stgraber: I'll try that, thanks!
<zyga> hmm
<zyga> mborzecki: is there any remapping done?
<zyga> I didn't check though, perhaps that's a question to jamesh/kenvandine
<zyga> mborzecki: we could also ask flatpak developers
<mborzecki> zyga: and there's an unhappy user in the forum
<mborzecki> zyga: i mean that's the spec, and the portal works according to the spec
<zyga> mmmm
<mborzecki> zyga: suggested the user to drop file:// from the url, which triggers the path that calls OpenFile()
<zyga> mborzecki: ah, I thought the bug is in the app itself
<zyga> and it seems you say that the problem is with the usage pattern
<mborzecki> but i can understand his frustration, even if he files a bug, and it gets fixed, it's probably not goiung to see the fix for the next 6 months or so
<zyga>  /snap/test-snapd-desktop/x1/bin/cmd: 4: exec: sh -c 'echo hello world': not found
<zyga> mborzecki: we could fix it in qt
<zyga> is the app using a shared qt runtime?
<mborzecki> zyga: i could even submit a patch if i got qt building locally and signed cla, but that's like a over-the-weekend recreational activity ;)
<zyga> I think the desktop team can help with that
<mborzecki> hmm otoh, that app is in qt, i see a segfault starting it on arch
<mup> PR snapd#8468 closed: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
<zyga> cachio: \o/
<zyga> cachio, mborzecki: make sure there's a follow-up for https://github.com/snapcore/snapd/pull/8468#discussion_r417975489 please
<mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
<zyga> cachio: thank you for pushing this forward :)
<cachio> zyga, yaw
<zyga> :)
 * cachio lunch
<cjp256> hello, anyone by chance have thoughts on https://travis-ci.org/github/snapcore/snapcraft/jobs/681562924#L432 ?  this is the first time i've seen snap report that LXD is already installed, but `lxd` not found...
<cjp256> fwiw, it happened on the 20.04 image
<zyga> cjp256: probably $PATH
<zyga> can you debug with echo $PATH
<zyga> or you can work around with "snap run ..."
<cjp256> zyga: there's a bunch of other tests that ran fine alongside it.   Appears random.  I'll restart it and see if it repros, then I'll print PATH.
<zyga> cjp256: you can debug it with things like echo $PATH, snap list, find /snap/bin
<cjp256> will do, thanks
<zyga> type=AVC msg=audit(04/30/20 17:13:46.842:526) : avc:  denied  { write open } for  pid=27614 comm=systemd-logind path=/var/lib/systemd/linger/test dev="sda1" ino=417790 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file permissive=1
<zyga> but I think that's actually my fault
<zyga> :)
<zyga> fixing now
<mup> PR snapd#8590 opened: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
<mup> PR snapcraft#3100 opened: Removed ``key`` from ``progressive`` dict following changes in the server API <Created by nessita> <https://github.com/snapcore/snapcraft/pull/3100>
<mup> PR snapcraft#3098 closed: build providers: bootstrap with dirmngr <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3098>
<zyga> ijohnson: you may want to have a 2nd look at https://github.com/snapcore/snapd/pull/8590
<mup> PR #8590: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
<zyga> I added one more bugfix for session-tool on selinxu
<zyga> *selinux
<zyga> namely this: https://github.com/snapcore/snapd/pull/8590/files#diff-a8fce2de6a6829d98f798117050b6c93R287
 * ijohnson should probably stop reviewing things that are drafts
<zyga> haha
<zyga> I'm very grateful that you did
<zyga> makes fixing those annoying failures gratifying :)
<ijohnson> do non selinux systems just ignore The SELinuxContext in the dbus call to StartTansientUnit ?
<ijohnson> zyga: ^
<zyga> yeah
<ijohnson> cool
<zyga> session-tool is this little thing that turns out to be a big sprawling mess
<zyga> but I think it's better than what we had before :)
<ijohnson> it's at least more uniformly a big sprawling mess
<ijohnson> and when it's used everywhere it makes it easier for everything to be closer to the right thing
<zyga> hopefully very close to having that
<zyga> I need to update incoming branches that use user.sh as well
<zyga> there's one heavy use in user session services branch
<zyga>  I hope we can land all the test fixes
<zyga> we have 73 PRs
<zyga> but a good chunk of those are recent fixes
<zyga> I pushed a small patch to https://github.com/snapcore/snapd/pull/8588 to reflect a new test in master
<mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
<zyga> I think I'll EOD now
<zyga> it's almost 21:30 here
<zyga> mvo: are you going to be around tomorrow?
<mvo> zyga: yes
<zyga> ok
<cachio> cmatsuoka, https://paste.ubuntu.com/p/hxnGhxdH7F/
<cachio> works well with the pc 96
<cmatsuoka> \o/
<cachio> so, I need to wait for the new gadget
#snappy 2020-05-01
 * cmatsuoka EODs
<cmatsuoka> good night everyone!
<zyga> o/
<mborzecki> morning
<zyga> mborzecki: hey
<mborzecki> zyga: hey, any clue why fedora 30 fails in https://github.com/snapcore/snapd/pull/8588 ?
<mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
<zyga> Failed to connect to bus: No such file or directory
<zyga> hmmmm
<zyga> mborzecki: what's the likelikhood that magic prepare/restore handling tarballs /run? :D
<mborzecki> maybe that's dbus-monitor?
<zyga> mborzecki: I don't know
<zyga> I mean, session-tool requires system bus
<mborzecki> zyga: iirc it only tarballs the test directory and some bits of /var/lib/snapd/
<zyga> does it happen each time?
<zyga> there's one more possible aspect
<mborzecki> yeah, for each test i believe
<zyga> can you run it with debug as a single test and see it fail?
<zyga> ah
<zyga> sorry
<zyga> I was talking about the failure
<zyga> so, before we land all the fixes
<zyga> we still have user.sh and rather brute force operations it does
<zyga> it's likely something nuked /run/user/12345 "harder"
<zyga> dunno
<mborzecki> ok, let me try to run this test on f30 only
<mborzecki> i mean locally
<zyga> once mvo is around it would be good to get some 2nd reviews for the many branches from yesterday
<zyga> and just land things
<zyga> I suspect that once we land them all the number of random failures will dramatically drop
<mborzecki> he'll probably be online around 13
<zyga> ok
<zyga> https://github.com/snapcore/snapd/pull/8590 was fun
<mup> PR #8590: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
<zyga> it passed on all fedora/centos systmes :)
<zyga> https://www.irccloud.com/pastebin/2VA6WffF/
<zyga> ha
<zyga> this is fun
<zyga> if this fails then something is nuking dbus.socket and not bringing it back
<zyga> I bet it's one of the tests that installs/removes it unconditionally
<zyga> could you grep for dbus-user-session and make sure we don't install/remove it blindly
<zyga> maybe send a patch to add a debug: | section to this test, to dpkg --get-selections | grep dbus-user-session on apt-able systems
<mborzecki> zyga: funny, the test passed in isolation
<zyga> yeah
<zyga> I bet there's some test that somehow breaks user sessions
<zyga> what is curious
<zyga> is that it happens this way for fedora
<zyga> IIRC we routinely install debian packages
<zyga> but not fedora
<zyga> do you think anything in user.sh could be responsible
<zyga> I strongly believe we leak dbus-daemon's lurking
<zyga> because nobody is managing that unless used via systemd --user
<zyga> maybe it binds to abstract socket
<zyga> and newly started daemons cannot start
<zyga> dunno :/
<mborzecki> idk, there's only 2 tests that use as_user now
<zyga> could be something eles
<mborzecki> one of those is the pulseaudio test which iirc has a PR porting it to session-tool
<zyga> one other idea is to change the main/session-tool-support test
<zyga> to have a up-front check
<zyga> for dbus-daemon running as test user
<zyga> if so that means something broke before us
<zyga> yeah
<zyga> I think we are close
<zyga> we just need to land the lot
<zyga> and see what remains
<zyga> I think it's going to be much less unpredictable
<zyga> mvo: o/
<zyga> mvo: when you have a moment, it would be good to merge some of the branches that are red and have two reviews
<zyga> mvo: things are a bit unstable because each branch changes one or at most a few tests and we can estimate what's left only after they all land
<mvo> zyga: sure, in a meeting righ tnow
<mvo> zyga: but if you point me to things I can merge when I have some minutes
<zyga> mvo: sure
<zyga> mvo: I'm not working today, just cleaning the office
<zyga> mvo: perhaps mborzecki can point you to things as well
<zyga> (tough I understand you both share meetings)
<mborzecki> mh
<mborzecki> mhm
<zyga> small scary blurb from the release page
<zyga>  New bugfix release 2.44.5
<zyga> @mvo5 mvo5 released this yesterday Â· 1628 commits to master since this release
<mvo> zyga: aha, right. enjoy your day off
<mborzecki> we should print out instructions about a day off for zyga :P
<zyga> mborzecki: I'm cleaning the office
<zyga> so many little things to tidy here
<mborzecki> haha
<roadmr> hey folks who know about spread:
<roadmr> Cannot allocate lxd:ubuntu-18.04: cannot list lxd remotes: exec: "lxc": executable file not found in $PATH
<zyga> roadmr: spread as a snap cannot invoke lxd
<roadmr> what's going on? lxc *is* installed and working. spread was installed from snap.
<zyga> roadmr: it's not coded to use the LXD API
<zyga> roadmr: you need to use a hand-built version
<roadmr> oh... zyga can I get non-snapped spread? and/or how do I get this to work?
<roadmr> oh... argh.
 * roadmr rolls up sleeves
<zyga> roadmr: go get github.com/snapcore/spread/...
<zyga> and you will find it in ~/go/bin
<zyga> (assuming defaults)
<roadmr> yay :)
<roadmr> thanks zyga !! that sets me on the right path
 * roadmr sadly deletes the spread snap
<zyga> roadmr: I have several patches that greatly expand spread's support for lxd
<roadmr> \o/
<mup> PR core#113 closed: Makefile: conditionally use the "edge" PPA in live-build <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/113>
<mup> PR snapcraft#3101 opened: package repositories: avoid setting up on host when not the target <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3101>
<ogra> zyga, it is super interesting how you manage to produce proper sentences on IRC by just cleaning your keyboard ! :)
<zyga> ogra: years of experience
<mup> PR snapcraft#3100 closed: Removed ``key`` from ``progressive`` dict following changes in the server API <Created by nessita> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3100>
<mup> PR snapd#8588 closed: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8588>
<mborzecki> yay, thanks!
<zyga> oh
<zyga> mvo: merge https://github.com/snapcore/snapd/pull/8590 as well please
<mup> PR #8590: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
<zyga> mvo: I'll dig what's left to make master green
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8587 needs a 2nd review
<mup> PR #8587: tests: session-tool allows preparing/restoring for many users <Created by zyga> <https://github.com/snapcore/snapd/pull/8587>
<zyga> (super trivial)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8589 also but is less trivial
<mup> PR #8589: tests: port user-session-env to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8589>
<mvo> zyga: thanks, looking
<zyga> thanks!
<zyga> I'm outside soldering GPIO headers
<mvo> zyga: haha
<zyga> just came to the office to print the pinout
 * mvo hugs zyga
<zyga> seriously ;D
<mup> PR snapd#8590 closed: tests: port selinux-clean to session-tool <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8590>
<mvo> zyga: I know, just find it funny that it's so opposite what I'm doing right now
<zyga> you are unsoldering GPIO headers in the sun? :D
<zyga> https://github.com/snapcore/snapd/pull/8583 is also +2 and simple (just debug code)
<mup> PR #8583: tests: add debug to core-persistent-journal test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
<zyga> mvo: I did the early github action matchers but it doesn't seem to work :(
<mvo> zyga: meh, that's sad
<mup> PR snapcraft#3099 closed: repo: always refresh cache when build packages are required <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3099>
<mup> PR snapcraft#3074 closed: package-repositories: draft spec and cleanup <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3074>
<mup> PR snapd#8583 closed: tests: add debug to core-persistent-journal test <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8583>
<mup> PR snapd#8582 closed: github: register matchers before running spread <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8582>
<mup> PR snapcraft#3102 opened: build providers: prevent snap refreshing in build environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3102>
<mup> PR snapcraft#3103 opened: python v2 plugin: set path to the interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3103>
<cjp256> How should one hold a refresh on a base other than 'core'? `snap set core20 refresh.hold=2020-05-02T19:01:49.211053Z  -- error: cannot configure snap "core20" because it is of type 'base'`
<cjp256> would setting than on `core` affect all core images?
<mborzecki> cjp256: it's a system wide setting, not per snap
<cjp256> oh :facepalming:
<cjp256> thank you :D
<mborzecki> cjp256: aiui the `core` bit in `snap set core` is legacy, we've support for using system in place of core to make things more clear, so you shoudl be doing `snap set system foo.bar=..`
<cjp256> will do that, thanks!
<mborzecki> bits inside snapd are still called configcore tho :P
<cmatsuoka> ijohnson: interesting, the ubuntu-seed problem is more and more frequent now
<ijohnson> cmatsuoka: yes it happens a lot which is annoying
<ijohnson> cmatsuoka: my MP to fix it however has not landed :-(
<cmatsuoka> a few days ago I tried many times and wasn't able to reproduce it, now it happens in almost every image build
<ijohnson> cmatsuoka: yes needs that MP to merged ASAP, but I also don't want to bother folks over the weekend, so let's see how annoying it is on Monday
#snappy 2020-05-02
<mup> Bug #1876478 opened: Automatic snap refreshes changes state of service from stopped to running <Snappy:New> <https://launchpad.net/bugs/1876478>
<mup> Bug #1876482 opened: There is no way to trace the upgrade history of a snap <Snappy:New> <https://launchpad.net/bugs/1876482>
<klaasvakie> Hi, I have recently started playing with various snap packages in preparation for rolling out some select systems on 20.04. I have read https://snapcraft.io/docs/keeping-snaps-up-to-date and I think the hold timers are sufficient for my use cases. One thing I can't find in the docs is how do I get notified when a new snap is available? Looks like "snap changes" and friends only  help you after the update
<bdx> kyrofa: https://github.com/omnivector-solutions/snap-slurm/blob/master/snap/snapcraft.yaml#L201
<bdx> ^ thank you
<bdx> the mysql part from the nextcloud snap has been extremely useful in our project
#snappy 2020-05-03
<georged4s> hi, is there any workaround for this bug? https://github.com/bitwarden/desktop/issues/81
<georged4s> I have tried the workaround by export XCURSOR_PATH=$RUNTIME/usr/share/icons but didnt work
<georged4s> also tried changing the inherit in /usr/share/icons/default/index.theme but stil doesn't work
<mup> PR snapd#8591 opened: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
<mup> Issue core-build#60 opened: Consider setting RPATH for executables and libraries <Created by mikix> <https://github.com/snapcore/core-build/issue/60>
