#snappy 2015-08-03
<dholbach> good morning
<fgimenez> good morning
<JamesTait> Good morning all; happy Monday and happy Watermelon Day! ð
<ogra_> yummy !
<ogra_> matches the weather :)
<ogra_> ppisati, is https://github.com/piso77/ubuntu-embedded/tree/master/boards/raspy2/bootloaders just a cloned snapshot of https://github.com/raspberrypi/firmware.git ? or did you compile anything in that dir ?
 * ogra_ would like to use upstream for the oem snap, but if that needs modification i'll fall back to yours)
<ppisati> ogra_: no compilation
<ppisati> ogra_: it's a copy of the binary stuff that was shipped with the original raspi2 img long ago
<ppisati> ogra_: let me check one thing
<ogra_> k, thx ... they seem to set a kernel version inside their dtb's there
<ogra_> (which points to 4.0.9)
<ppisati> ogra_: i didn't update mine
<ppisati> ogra_: so they probably update it
<ogra_> yes, they do
<ogra_> since we need to use their dtb's for the initialization i wonder if that could cause issues
<lool> rsalveti: I guess we might want to escalate https://bugs.launchpad.net/bugs/1470727 to Critical as it prevents creating images of rolling? or is there another way to get to latest rolling edge?
<ubottu> Launchpad bug 1470727 in Snappy "ubuntu-device-flash touch fails with: failed to find user uid/gid" [Undecided,Confirmed]
<ogra_> lool, that should be fixed in the proposed PPA asince a while
<lool> (I tried updating form oldest working image but that got me into a broken state -- empty GRUB menu)
<lool> ogra_: which one is that?
<lool> I have the snappy-dev tools PPA only
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed
<lool> ogra_: and that's pending promotion with next image promotion?
<ogra_> hmm, and even that is behind, i thinnk there is a 0.28 in wily already
 * ogra_ checks -changes
<ogra_> ah, no
<ppisati> ogra_: right, cause we use that dtb now
<ogra_> lool, i'm not exactly sure how the promotion of udf works
<ogra_> i knwo it forst goes into that PPA before being released though
<lool> ogra_: I have a side question for you: how would you find livefs builds older than a week? the launchpad /+livefs page only lists less than ten or so
<ogra_> lool, there is an LP REST api for that (but i'm not sure it goes back further) and cjwatson could probably point you to an easy way to get more listed on the LP page
<ogra_> (read: i dont actually know)
<lool> ogra_: hmm I guess there might be links in the cdimage logs triggering the lp builds
<ogra_> there are, definitely
<ogra_> i would hope theer is an easier way though
<lool> it's likely LP API exposes it, I'm just lazy
<lool> (besides, I dont need it anymore if it's fixed in latest tools, it was just in case I'd have to dive into the issue  :-)
<lool> rsalveti: confirmed fixed with tools-proposed, nevermind; marking fix-committed
<lool> hmm I have to reboot to get network up
<lool> due to interface renaming it seems
<ogra_> hmm, i thought Chipaca had fixed that
<ogra_> (well, at least i know he was working on it )
<lool> hmm I'm trying to enable SSH after booting an image without it; I see it's ssh_enabled: true in some yaml file, but can't figure out which
<lool> ah cloud-init userdata
<lool> ok, answer: sudo rm /etc/ssh/sshd_not_to_be_run and reboot (note for self)
<ogra_> GRRR
<ogra_> MMC:   bcm2835_sdhci: 0
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<ogra_> WHEE !
<ogra_> MMC:   bcm2835_sdhci: 0
<ogra_> reading uboot.env
<ogra_> In:    serial
<ogra_> that looks so much better :))
<ogra_> grmbl ...
<ogra_> so switching to uboot.env on the rpi actually wipes the env of the preloader ... crap
<ogra_> EEEK !
<ogra_> probably because nothing in the oem snap lands where it should
<ogra_> sergiusens, hulp !
<ogra_> sergiusens, is there a way for me to have a whole subdir copied into the snap 1:1
<ogra_> http://paste.ubuntu.com/11992407/ ... everything with "overlay" in the name should be in an overlay/ subdir
<ogra_> bah ... and it puts the totaly wrong snappy-system.txt in place, thats really bad
<sergiusens> ogra_: hmm, there was no dir copy support, just files
<sergiusens> we can add it, but it's not there
<ogra_> http://paste.ubuntu.com/11992517/
<ogra_> hmm
<ogra_> well, the preloader has that subdir hardcoded, so if we ant to be able to use overlay dtb's it needs to exist
<ogra_> wasnt there a hack via the device tarball ?
<sergiusens> ogra_: so all those files will be copied to the base, if you want a target, give it a target
 * ogra_ thinks he remembers something like that +
<ogra_> in the -path: line ?
 * ogra_ tries
<sergiusens> ogra_: http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/view/head:/diskimage/common.go#L90
<ogra_> Installing pi2_0.15_all.snap
<ogra_> stat /tmp/oem231909283/oem/pi2/0.15/boot-assets/overlays/ads7846-overlay.dtb overlays: no such file or directory
<sergiusens> it should work, but 'should' is a strong word
<sergiusens> ogra_: hmm, I can fix that
<ogra_> well, can i fix it from the snap side ?
<sergiusens> ogra_: I can't think of anything
<ogra_> i kind of dont want to modify the stable released image :)
<sergiusens> ogra_: oh, it's just one bug fix to u-d-f
<sergiusens> not the actual image
<ogra_> ah
<ogra_> cool, yeah that will work
<sergiusens> ogra_: to be able to deploy directories
<rsalveti> lool: both tools and tools-proposed are currently in sync
<rsalveti> I sync the ppas when doing the stable release
 * ogra_ sighs ...
<ogra_> i'll try with the old rpi preloader after lunch ... thats depressing :/
<lool> rsalveti: hmm I tried this like Friday with I believe up-to-date tools but perhaps I hadn't apt-get updated hmm
<lool> rsalveti: anyway, I've marked this fix committed
<lool> you can mark fix released if it's in wily too
<lool> (not sure what rule we follow there)
 * ogra_ wonders why lool's uboot.env works but not mine ... life is so mean :P
<lool> ogra_: might be the time at which it's loaded?
<lool> ogra_: also, are you sure yours is loaded?
<ogra_> lool, yes, my prob is that i can get certain vars only from the preloader ... it hands them to u-boot once it loads it ... loading my env file wipes these vars, loadin yours keeps them
<ogra_> (well, loading yours using your uboot binary ... and loading mine using my uboot binary)
<ogra_> http://paste.ubuntu.com/11993082/ specifically "args" and "usbethaddr" are the ones i need
<ogra_> the only difference is that i bumped the uboot-env size to the same 128k that we use on the BB
<ogra_> lool, did you patch anything or did you just build using the defconfig  ?
<lool> ogra_: just defconfig and the patch to allow raw initrd
<ogra_> oh, i forgot that one !
<lool> but it's not needed in recent upstream versions
<ogra_> though i doubt that would unset atags or dtb values (or however the pre-loader hands them to uboot)
 * ogra_ starts over and tries a completely unpatched build 
<elopio> sergiusens: do you see any problem with backporting the gocheck update? https://code.launchpad.net/~elopio/snappy/backport-gocheck/+merge/266663
<ogra_> hmpf
<ogra_> U-Boot> printenv
<ogra_> fdtfile=bcm2836-rpi-2-b.dtb
<ogra_> usbethaddr=b8:27:eb:04:db:1c
<ogra_> still no args
<mterry> jdstrand, what is the "mac-based isolation" security provided by snappy?
<sergiusens> elopio: added to my todo
<elopio> tx
<lool> ogra_: it's odd that you're not getting more in your environment
<lool> ogra_: it looks like you're not even getting the default environment
<ogra_> lool, i load an empty uboot.env
<ogra_> thats on purpose
<lool> ogra_: maybe the u-boot logic behaves differently in this case though in that you're not getting the default env like bootcmd etc.
<ogra_> (i first need to make sure the values from the preloader actually end up in my env)
<lool> ogra_: so perhaps you need to do a dump of the default environment and copy that in your env file
<ogra_> lool, yes thats what i'll do in the end
<ogra_> and thats how we worked on the BBB
<ogra_> but i need the intersection between the default env and the atags the rom hands ove
<ogra_> r
<ogra_> for the BBB i just loaded the emopty env file and got all the ROM values set
<ogra_> so i knew what to leave out of my env file (to have it "saveenv'ed" on first boot, since they are HW specific (MAC, seial etc)
<ogra_> i wanted to do the same on the rpi ... but seemingly these values are comletely gone now
<elopio> fgimenez: lets skip today.
<elopio> sorry.
<fgimenez> elopio: ok np
<elopio> rsalveti: I can land things in the 15.04 branch, right?
<rsalveti> elopio: yes
<jcastro> any options as to mounting an NFS share on a snappy machine?
<mterry> sarnold, jdstrand: what is the "mac-based isolation" security provided by snappy?
<ogra_> it puts all the ipads and iphones in a corner and tells them to be ashamed ?
<roadmr> :D
<sarnold> mterry: I assume this use of "mac" means mandatory access control
<mterry> sarnold, not sure -- it's a phrase from https://developer.ubuntu.com/en/snappy/
<mterry> sarnold, I'm guessing so though
<sarnold> mterry: I guess the authors figured "mandatory access control" right next to "human friendly" didn't make sense. :)
<mterry> sarnold, so it's basically apparmor looks like from a quick search?
<sarnold> mterry: sorry, I don't understa
<sarnold> understand
<mterry> sarnold, I'm not familiar with "mandatory access control" either -- searching online for that phrase makes it sound like what apparmor does
<sarnold> mterry: ah! yes, apparmor is one implementation of a mandatory access control system, yes
<jjohansen> yes, its a variant of mac
<mterry> sarnold, jjohansen: cool, thanks!
<jjohansen> specifically its a variant of dte instead of just te
<sarnold> a discretionary access control system allows data owners to set policies -- e.g., the unix permissions bits, acls, etc; mandatory access controls have a system adminstrator or security officer set permissions
 * ogra_ definitely liked the naughty step explanation above more 
<lool> mterry: it's true that tomcat wont start out of the box with example snap, but the mvn plugin itself works and I'd like to keep demoing it; would you mind merging the branch?
<lool> mterry: or I can remove the sample snap if that's comfort
<lool> (from the branch)
<mterry> lool, OK, let me look again
<lool> mterry: the other way to fix it would be to launch tomcat ourselves (or fork catalina.sh) but I wanted to avoid this hardcoding and didn't have time to research why systemd wouldn't launch tomcat in the default script, sorry
<lool> mterry: I'm about to close laptop and leave for travel, worst case I'll demo from the branch and we can land it later
<mterry> lool, I'm finding a few nits, yeah.  Will comment.  But if time is pressing, demo from the branch is fine
<lool> mterry: yeah, I have a fallback dont worry
<mterry> lool, sorry didn't know this was a time-sensitive branch for ya
<mterry> Or didn't realize when it would be at least
<lool> mterry: yeah, it's ok, I can do it from branch
<lool> mterry: reason I wnted to land it soon is because we're releasing a video to demo snapcraft with maven plugin, so would be nice if it was in tip
<mterry> lool, commented
<lool> mterry: thanks
<utlemming> rsalveti: is there a pythononic way to know if you're on snappy?
<utlemming> rsalveti: python -c 'import platform; print(platform.dist())' doesn't distinguish between regular Ubuntu and Snappy Ubuntu
#snappy 2015-08-04
<fgimenez> good morning
<dholbach> good morning
<clobrano> hi
<JamesTait> Good morning all; happy Coast Guard Day! ð
<ogra_> sergiusens, hmm, is there anything more needed for the fan support stuff ? i think that can be moved to done actually
<sergiusens> ogra_: oh, it was in TODO, I moved it to WiP just in case
<sergiusens> as I wasn't sure what the status was
<ogra_> yeah,. not sure what beyond seeding it is actually needed
 * sergiusens was doing trello board cleanup
<ogra_> but i would expect nothing more :)
<sergiusens> ogra_: testing and maybe docker support ;-)
<ogra_> ah
<ogra_> k
 * ogra_ sighs ... i have the feeling i'm getting nowhere with the rpi :(
<ricmm> ogra_: what are you trying to do with it :p
<ogra_> ricmm, the blob sets the default commandline (handing over board serial and MAC address) ... i can not manage to get uboot to see that var ...
<ogra_> i had it working before but now cant get it to work anymore
<ogra_> hmm
<ogra_> i havent tried shuffling around the start.elf binaries yet ...
<davmor2> ogra_: what happens when the elves go on strike?
<ogra_> then santa has to do all the work himself
<sergiusens> davmor2: if elf doesn't work you ask help from a dwarf ;-)
<davmor2> sergiusens: if the dwarf is red then the H isn't help it's rimmer's head ;)
<rsalveti> ogra_: sergiusens: fan is a mix of a few things, right?
<rsalveti> seeding it is just one part, not sure if we got a new docker that is somehow compatible with it
<rsalveti> and I remember that sergiusens was a bit worried about the dependencies and the side effect of that
<sergiusens> rsalveti: I'm not worried anymore; docker was on kickinz1 but we need some testing on it aside from just seeding
<rsalveti> right
<rsalveti> elopio: sergiusens: need some help for the tarmac machine
<rsalveti> for https://code.launchpad.net/~mterry/snapcraft/arch-fixes/+merge/266149
<rsalveti> FileNotFoundError: [Errno 2] No such file or directory: '\''dpkg-architecture'\'''
<rsalveti> need dpkg-dev installed
 * rsalveti never tried accessing the tarmac machine 
<kyrofa> seb128, I can't install clicks using the click scope on Personal. Is there something preventing clicks and snaps from working together there? Or just a piece missing?
<seb128> kyrofa, is the click scope installed on personal?
<seb128> kyrofa, snappy and click are sort of conflicting
<seb128> we shouldn't even have the click user on that image
<mterry> elopio, can you install dpkg-dev on the tarmac instance please?
<ogra_> seb128, i guess it is seeded by default
<fgimenez> rsalveti, i've added your public key, you should be able to login with ssh ubuntu@10.55.32.153
<rsalveti> mterry: yeah, just asked that right before you joined :-)
<mterry> rsalveti, :)
<mterry> rsalveti, I also updated the branch to depend on dpkg-dev
<seb128> ogra_, that's a bug then
<rsalveti> fgimenez: awesome, thanks
<rsalveti> mterry: installed, let's give it another try
<fgimenez> mterry, your's is added too
<elopio> good morning.
<ted> ogra_, So my rootstock build is failing. I know you said I needed to do wily (which is fine) do you mean as the host or target (I changed the target, but want to make sure that's not my problem)
<ogra_> rsalveti, http://people.canonical.com/~ogra/bootfiles.tgz just extract that in a working rpi system-boot
<ogra_> ted, no, wily is broken, i said you cant use wily :)
<ogra_> vivid works
<ogra_> rsalveti, hmm, hold back with pulling that tarball seems my uplink has issues :/
<rsalveti> mterry: there is a failing test still it seems
<ted> Heh, okay.
<mterry> rsalveti, yeah I saw...  I don't get it locally so this will be a bit of a hunt
<mterry> rsalveti, but am distracted by today's MIT demo
<rsalveti> mterry: yeah, no rush
<rsalveti> mterry: how is that going btw?
<mterry> rsalveti, prep is good.  just running through it again today.  It was useful for finding pain points.  The go-on-arm branch and a fix in the arch-fixes branch are from that work (the store doesn't support 'architectures' yet, only 'architecture'!)
<ogra_> rsalveti, upload done
<rsalveti> mterry: indeed, nice
<ogra_> rsalveti, note that uboot.env only includes "foo=bar" so the boot will stop at the uboot prompt
<ogra_> and what i need is the "args=" var to be set http://paste.ubuntu.com/11993082/ (in that example cmdline.txt has "elevator=deadline" in it and nothing more ... start.elf prefixes what is in cmdline.txt with the HW values to become args=
 * rsalveti grabs his rpi2
<ogra_> uh
<ogra_> DT and ATAGs are mutually exclusive. As a result, passing a DT blob to a kernel that doesn't understand it causes a boot failure. To guard against this, the loader checks kernel images for DT-compatibility, which is marked by a trailer added by the mkknlimg utility ... Any kernel without a trailer is assumed to be non-DT-capable.
<ogra_> now i wonder, how would start.elf then recognize that uboot is DT capable ... since we dont load a kernel
<rsalveti> not sure this would have weird side effects on us
<rsalveti> guess it might just be used to protect the users somehow
<rsalveti> <utlemming> rsalveti: is there a pythononic way to know if you're on snappy?
<rsalveti> <utlemming> rsalveti: python -c 'import platform; print(platform.dist())' doesn't distinguish between regular Ubuntu and Snappy Ubuntu
<rsalveti> sergiusens: ^ any idea?
<sergiusens> rsalveti: we don't have a distinguishing factor between the ubuntu's
<beuno> try apt-get'ing  :)
<ogra_> sergiusens, rsalveti, sheck for system-image ?
<sergiusens> beuno: ogra_ right, apparmor has a check jdstrand doesn't like which goes along those similar lines
<sergiusens> well, not that I like it either
<ogra_> yeah
<ogra_> not sexy indeed
<rsalveti> we could check for system-image, I guess that's how we currently do for phone
<rsalveti> but I guess it would be good to export something
<ogra_> i wonder is a special entry in /etc/os-release would make sense
<rsalveti> ogra_: yeah, /etc/os-release might be the way to go
<rsalveti> ogra_: care to take a look at that tomorrow?
<mterry> rsalveti, elopio: it looks like ubuntu-snappy-cli is not installed on tarmac?  snapcraft tests need it
<rsalveti> hm
<rsalveti> mterry: yeah, wasn't installed
<rsalveti> mterry: it is now
<mterry> trying arch-fixes again
<mterry> elopio, for your base_plugin_tests branch -- which looks great, thanks, especially the fatal() typo fix  :) -- you'll want to add wget to Build-Depends too (we didn' use it during tests before)
<elopio> mterry: pushed. Thanks for the review.
<mterry> elopio, text conflict with trunk?
<elopio> grr
<elopio> mterry: ready
<mterry> elopio, nice, approved
<elopio> thanks.
<elopio> mterry: do we want plainbox tests for all the examples?
<mterry> elopio, well I suppose so.  But usually a "test" gets put in examples because it needs big downloads like the go compiler or python3 or whatever
<mterry> We need a solution for those kinds of tests
<mterry> They can get put in as a plainbox test category "external" or whatever.  Instead of "normal"
<mterry> And then we can have something that runs those tests once a day or once a week or whatever
<elopio> mterry: do you know how to tell plainbox to run only one category?
<mterry> elopio, in runtests.sh, you can see how we do it for 'normal': plainbox run -T 2015.com.canonical.snapcraft::normal ...
<elopio> ok. Let me try to make a simple one. I'm not sure what we want to verify here.
<elopio> maybe just that the .snap was generated, maybe even do a snapcraft run.
<elopio> mterry: when trying to build the py2 example, I get http://paste.ubuntu.com/12003190/
<elopio> any idea about that?
<mterry> hrm... that should be provided by python-dev, installed by the plugin....
 * mterry tries
<elopio> ah, missin python-dev, right.
<mterry> elopio, but it should be provided by the plugin!
<elopio> I don't understand that part. Where does the plugin install it?
<mterry> elopio, snapcraft/plugins/python2.py
<elopio> mterry: yes, I see it in UbuntuOptions. But does it get python-dev from the archive and install it somewhere?
<mterry> elopio, yes.  Try now, merged from trunk and updated to use snappy-metadata instead of old method
<elopio> cool, works now.
<elopio> mterry: can you snapcraft run that one? I get http://paste.ubuntu.com/12003271/
#snappy 2015-08-05
<dholbach> good morning
<fgimenez> good morning
<JamesTait> Good morning all; happy Work Like A Dog Day! ð
<ogra_> ppisati, help ! ... i know i managed once to get the rpi bootloader to hand the cmdline.txt over to u-boot ... but i cant manage that anymore, do you remember if we needed to use the mkknlimg tool against uboot.bin to achieve that ?
<ogra_> or was that kernel only (which wouldnt help for plain u-boot indeed)
<ppisati> ogra_: hi
<ppisati> uhm
<longsleep> oh joy - cant you guys get rid of the rpi bootloader?
<ogra_> nope
<longsleep> :/
<ogra_> pi cant boot without it
<ogra_> uboot is just a chainloaded thing here
<ppisati> ogra_: i don't remember ever doing that
<longsleep> so it could boot without uboot then?
<ppisati> ogra_: let me grab my pi board
<ogra_> (and for the fun, all DTB overlay handling also has to happen in the blob bootloader)
<ppisati> yep
<longsleep> oh
<ogra_> longsleep, it could boot, but not update and rollback ... or failover
<longsleep> ogra_: i see - and the rpi bootloader loads something from disk itself?
<longsleep> ogra_: so it has fat read drivers and all itself?
<ogra_> yeah, it loads either uboot.bin or the kernl
<ogra_> (and aside from that it is also the binary GPU driver as well)
<longsleep> is that new for rpi2?
<ogra_> nope
<ogra_> has always been like that
<ogra_> there is no free bootloader for it ... and the bootloader is the GPU driver (it even loads into the GPU to then init the HW afterwards before loading kernel or uboot)
<longsleep> ogra_: ok - let me check one of the rpi's i have then
<ogra_> the thing is that this bootloader has its own config file and also a file where you can put the cmdline in ... if there is something inside that cmdline file it creates a cmdline from ROM values merged with the file content it hands over to uboot as "args=" variable ...
<longsleep> ah yes - seems that i am not even using u-boot then
<ogra_> these ROM values contain the board serial and the MAC address ...
<longsleep> urg
<ogra_> i need them in my uboot env and cant get them to show up anymore
<longsleep> thats config.txt and cmdline.txt you are referring to?
<longsleep> i see these both
<ogra_> yeah
<ogra_> http://paste.ubuntu.com/11993082/
<ogra_> see the "args=" line at the top
<longsleep> right
<ogra_> that comes from the bootloader (my cmdline.txt contained elevator=deadline in that case)
<longsleep> do you have the fixup.dat as well?
<ogra_> yes
<ogra_> i have start.elf, bootloader.bin and fixup.dat ... the configs and the respective DT
<longsleep> so, for you the args value are the defaults and you cannot change them>
<longsleep> ?
<ogra_> no
<ogra_> the args value is unset now
<longsleep> ah ok
<ogra_> it doesnt get handed over to uboot at all
<ogra_> there seems to be some chack for DT capability of the kernel in the bootloader ... if it doesnt find that, it uses ATAGs, which i think is my prob
<ogra_> *check
<ogra_> you need to use a special tool that adds a suffix to the kernel binary which makes the bootloader know the kernel is DT capable
<longsleep> oh joy
<ogra_> and i think that is what i'm missin on my uboot binary
<ppisati> wait
<ppisati> i had an email about that
<ogra_> (we had some mail discussion about that before, thats why i asked ppisati if he still remembers)
<ogra_> *snap*
<ppisati> right
<ogra_> :)
<ogra_> but that doesnt talk about uboot at all
<ogra_> only about the kernel
<longsleep> ogra_: and in your config you set kernel=uboot.bin or something?
<ogra_> i need the var before the kernel is loaded
<ogra_> longsleep, right
<ogra_> the silly thing is that i had it working properly ... as you can see in the paste
<ogra_> but then the file corruption issie showed up, i forgot to write down what i had done and now i cant get it to work anymore
<longsleep> ogra_: mhm you think it is a u-boot compile time flag?
<ogra_> no, we didnt patch uboot much
<ogra_> there is the raw initrd patch, thats all (one config line)
<longsleep> right, so you use latest mainline u-boot for the rpi?
<ogra_> and for the new uboot.env stuff i changed the file size of uboot.env ... but i cant even get it to work without that
<ogra_> i tried both, mailine and srwarrens tree
<ppisati> ogra_: do you recall the subj of that email conversation? i can't find it right now...
<ogra_> i dont think it is uboot
<ogra_> ppisati, "Snappy Core Image for Raspberry Pi"
<ogra_> 1) You need to use the 'mkknlimg' utility to append a trailer to the kernel image. Without this, the loader doesn't know that the kernel is DT-capable, and will use ATAGs instead.
<ogra_>     Follow the (recently updated) instructions here: https://www.raspberrypi.org/documentation/linux/kernel/building.md
<ogra_> uh, oh
<longsleep> whoah that script looks scary
<ogra_> ppisati, i remember there was some uboot cmdline you gave me to have the content of "0x100" stuffed into the env ...
<ogra_> (it slowl comes back ...)
<ogra_> *slowly
<longsleep> ah that would make sense
<ppisati> ogra_: i'm passing directly what i get from the rpi loader to the kernel
<ogra_> i can actually see the cmdline with md 0x100
<longsleep> then just import it
<longsleep> if the rpi bootloader writes its args to 0x100
<longsleep> ogra_: something like 'env import -t 0x100'
<longsleep> (sorry i got distracted)
<ogra_> longsleep, no, i found the old conversation ... it isnt an env but actually the start if the devicetreew i see with md
<ogra_> fdt addr 0x100 ... should theoretically work ... but gives me an error
<ogra_> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
<ogra_> but i'm on the right track now so i should get it working
<ogra_> aha !
<ogra_> Jun 16 13:32:43 <ppisati>       ogra_: BTW, the patched uboot is here if you want to try it - http://people.canonical.com/~ppisati/uboot.raspy2
<ogra_> ppisati, do you remember what you patched there ?
<ppisati> i think i know
<ppisati> let me check
<longsleep> yes i think it must be u-boot
<ogra_> (i would just take your binary but i need additional patching sadly)
<ppisati> right
<ppisati> so
<ppisati> ./mkknlimg --dtok ./uboot.bin.old ./uboot.bin
<ppisati> to get that uboot
<ogra_> bah, i had --dtok --283x in my last try
<ogra_> i guess thats it :P
<ogra_> so close (and just by guessin)
<ppisati> ogra_:
<ppisati> ops
<ogra_> U-Boot> fdt addr 0x100
<ogra_> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
<ogra_> grrr
<ppisati> even with the patched uboot
<ppisati> fdt addr 0x100
<ppisati> works here
<ppisati> ok, forget bout that
<ogra_> the error looks like the dtb file is messed up ...
<ppisati> i was able to boot a kernel
<ogra_> but why would it be loaded to ram just flawless if it was
<ppisati> U-Boot> fdt addr 0x100
<ppisati> U-Boot> run loadkernel
<ppisati> 4537616 bytes read in 3313 ms (1.3 MiB/s)
<ppisati> U-Boot> bootz ${kernel_addr_r} - 0x100
<ppisati> and i got to a booted system
<ogra_> sure
<ogra_> i'm far from that point ... i need the values in my uboot env to assmeble a proper cmdline first :)
<ogra_> then i'll care for booting :)
<ogra_> i guess i should start over from a clean state
<ogra_> U-Boot> fdt addr 0x100
<ogra_> U-Boot> fdt get value serial /system linux,serial
<ogra_> U-Boot> echo ${serial}
<ogra_> 000000001cdb048b
<ogra_> \o/
<ogra_> yippie !!
<ogra_> U-Boot> fdt get value args /chosen bootargs
<ogra_> U-Boot> printenv args
<ogra_> args=dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa01041 bcm2709.serial=0x8b04db1c smsc95xx.macaddr=B8:27:EB:04:DB:1C bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
<ogra_> there we go
<longsleep> what did you change?
<longsleep> and what do you use the serial for?
<ogra_> i used ./mkknlimg --dtok on the uboot binary ... and actually copied the dtb files freshly in
<ogra_> the serial is needed if you want to buy the video codecs
<longsleep> ah yes
<ogra_> so it must be set in /proc/cpuinfo
<ogra_> and indeed you want the persistent MAC
<longsleep> do you know how the bootloader generates it?
<ogra_> from msc95xx.macaddr=B8:27:EB:04:DB:1C
<ogra_> afaik the first stage loader reads it from ROM
<longsleep> mhm you think they fuse it on the chip?
<ogra_> well, i dont know how it exactly works, but it must come out of the HW somehow ... i guess they imprint it with the first stage loader in the ROM
<longsleep> it is probably derived from the serial number in some way - i was just wondering if there could be collision (which i have seen in ODROID land).
<ogra_> yeah, hard to tell ... that bootloader is a blackbox
<longsleep> yes - closed source bootloaders make me sad
<ppisati> ogra_: cool
<ogra_> ppisati, thanks a lot !
<ppisati> ogra_: how do you make printenv print on different lines?
<ppisati> ogra_: i totally forgot about all this stuff
<ppisati> ogra_: i mean, instead of clobbing a single line
<ogra_> me too, thats was my prob for the last three days :P
 * ogra_ is banging his head against that since friday
<ppisati> poor friday
<ogra_> ppisati, i dont do anything, printenv has a newline at the end of each line here
<ppisati> uhm
<ppisati> not here
 * ppisati sad panda
<ogra_> what terminal do you use ?
<ogra_> screen /dev/ttyUSB0 115200 ...
<ppisati> minicom
<ppisati> let me try screen
<ogra_> that gets me poper terminal shaped output
<ogra_> (and i can detach ... ssh from my laptop in the livingroom into the machine with the serial line and take over the console from there ... very helpful)
<ppisati> so you have a host in betweeb?
<ppisati> *between
<ogra_> not atm
<ogra_> but i can if needed/wanted
<ppisati> i mean, i can detach too
<ppisati> anyhow
<ppisati> let me try screen
<ppisati> fuck
<ppisati> it works
<ogra_> well, screen keeps the terminal up but detaches the tty ... so i can switch machines
<ogra_> indeed :)
 * ogra_ gave up on all other terminal emulators years ao
<ogra_> *ago
<ppisati> i've always used cu
<ppisati> then minicom since i have problems with cu and some boards
<clobrano> Hello, I was wondering if packages already in ubuntu repository (e.g. iperf) could be submitted to snappy store or is it something that will be done automatically
<ogra_> clobrano, depends ... what would you use iperf for ? if it is something inside your snap that wants it you would ship it in your project snap
<ogra_> if it is for general convenience it would go into the "comfy" snap which we are working on ... thats a snap to make your shell experience a bit more convenient as a developer that actually works on the snappy box and will include a bunch of helpful tools
<clobrano> ogra_: well, not directly used by my snap, but iperf like other tools are useful when testing some applications
<ogra_> right, then it would be a comfy thing
<clobrano> ok, perfect
<clobrano> that's exactly what I was thinking
<ogra_> (along with a proper vim ... htop etc etc ... )
<clobrano> I would love vim :)
<ogra_> there was a ML discussion about comfy iirc ... started by lool
<ogra_> i think for the start it will likely be something like the dependencies of the ubuntu-minimal metapackage +/- one or the other tool
<ogra_> and then we'll ghrow it over time
<clobrano> nice
<longsleep> yay proper vim!!!
<longsleep> ogra_: so, regarding the rpi you now modify the u-boot after you created it?
<ogra_> longsleep, well, i run it through the mmknimg tool to get the suffix set
<ogra_> http://paste.ubuntu.com/12005875/
<ogra_> my notes for next time :)
<longsleep> ogra_: You should fork my make files for the ODROID :)
<longsleep> ogra_: https://github.com/longsleep/snappy-odroidc
<ogra_> i got shellscripts for that ;)
<ogra_> (just not for the rpi yet)
<longsleep> ogra_: by the way, mu odroidc oem new version is still not reviewed, any idea how to get this going>
<longsleep> ?
<ogra_> lets get sergio on it once he shows up
<longsleep> it could be a issue as well, it is in published state and a new version was uploaded. Maybe there is no notifications as the snap is not in pending review state
<ogra_> we'll see what he says
<ogra_> worst case we'll get beuno to fix it :)
<longsleep> and i noticed another inconsistency in the store, I have two snaps now, but i see only one /dev/click-apps and both in /dev/click-apps/?format=snap
<longsleep> (and the oem snapp also shows up for /dev/click-apps/?format=click)
<ogra_> hmm, i see all my 60 click apps without the format snap thingie
<ogra_> and with it i see the snaps
<ogra_> clikc will hopefully not persist for to long anymore though
<longsleep> it seems that one only sess click apps by default and the oem snap is counted as format=click and format=snap
<ogra_> so this will solve itself :)
<kivi> snappy-tools still a thing? Its not on 15.10
<ogra_> kivi, what do you mean by that ? snapppy-tools is a PPA that contains the tools we use
<kivi> ogra_, okay thanks
<ogra_> (ubuntu-device-flash for example)
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/tools
<ogra_> the tools themselves should all be in 15.10
<ogra_> the PPA has backports for older releases
<kivi> ogra_, ah
<kivi> okay
<kivi> sorry, just following a tutorial for making python snaps, and the apt-get did not mention the ppa
<ogra_> ah
<longsleep> sergiusens: Hey, any chance you can review the new version of https://myapps.developer.ubuntu.com/dev/click-apps/2822/ at some point. I uploaded a new version a week ago and i am not sure if anyone did see that.
<sergiusens> longsleep: sure, I'll add to my TODO
<longsleep> sergiusens: great thanks
<dholbach> can somebody review https://code.launchpad.net/~dholbach/snapcraft/doc-fixes/+merge/267010? (just syntax fixes)
<longsleep> dholbach: not sure if it helps if someone from the community approves but i did it because all those special characters needs to go away asap and you merge just did that :)
<dholbach> longsleep, we're all part of the community :)
<dholbach> can somebody review https://code.launchpad.net/~dholbach/snapcraft/docs-next-steps/+merge/267019 too? :)
<dholbach> longsleep, sergiusens, elopio, merged now - thanks for the reviews
<sergiusens> longsleep: hey, ogra_ tells me you've used snapcraft to build armhf snaps, did you do that on  native armhf env?
<dholbach> dpm, I'll put the snapcraft docs online in a bit - we should be ready to go
<dholbach> and another one: https://code.launchpad.net/~dholbach/snapcraft/rename-tutorial-file/+merge/267031 :)
<elopio> zyga: the snapcraft tests print lots of warnings. Any tips to clean it up?
 * dholbach hugs elopio
<elopio> :)
<longsleep> sergiusens: no - i wrote my own plugin which allows to pull in built deb files into the snap. That way i can build any deb using pbuilder for any target platform and just create a snap with those.
<longsleep> sergiusens: if you want to review/comment: https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650
<zyga> elopio: can you pastebin something?
<zyga> elopio: I'll help you out
<longsleep> sergiusens: Or you can also comment on https://bugs.launchpad.net/snappy/+bug/1480144 which tries to cover the whole picture
<ubottu> Launchpad bug 1480144 in Snappy "Snapcraft should be able to run in clean environment with pbuilder/cowbuilder" [Undecided,New]
<elopio> zyga: http://paste.ubuntu.com/12006977/
<zyga> elopio: so for the leftover thing
<zyga> elopio: I can quickly add a flag that will say the job is expected to dirty the temporary working directory (it's not default before it was often a bug on our part in the old jobs)
<zyga> elopio: and you can use that flag to get rid of those parts
<longsleep> sergiusens: so the deb packages i need in the snap are built on a build system for the target platform and snapcraft runs afterwards, using the produced deb files. The debs plugin also can pull in deb files from URL locations to make it easy to test.
<zyga> elopio: is there anything else you'd like to change there specifically?
<zyga> elopio: can you file a bug on that (tag it 'snappy') and I'll try to fix it ASAP
<zyga> elopio: we should sync next week, I have some interesting bits coming that should be able to help you a lot
<elopio> zyga: I tought first about making the snapcraft build out of the working directory, but if you thing the flag would be better lets do it.
<elopio> zyga: other than that, I would like to have subunit test results.
<zyga> elopio: mmm, another bug, if you show me a simple snippet of python that does that (create some result object, set data, etc,) then I can write that today as well
<zyga> elopio: so both on the "plainbox" project and both with "snappy" tag pretty please
<elopio> zyga: ok.
<elopio> about a simple snippet, it depends on how your test suites are implemented.
<zyga> elopio: mmm
<elopio> If you are using a test runner, just replace it with the subunit test runner. https://bazaar.launchpad.net/~subunit/subunit/master/view/head:/README.rst
<zyga> elopio: the way I understand it you could ask plainbox to exports results to subunit format
<zyga> elopio: maybe I misunderstand what subunit is
 * zyga looks
<elopio> zyga: you can convert to subunit after the fact, or you can make a subunit stream and fill it while the tests are running.
<elopio> the stream is nicer, but both work.
<elopio> mterry: any clues about what's wrong here? http://paste.ubuntu.com/12007001/
<elopio> that's the simple-cmake integration tests running from adt-run.
<zyga> elopio: mmmm
<zyga> elopio: the former is easy, streaming is harder but we could do it with the new API that I worked on
<zyga> elopio: it would not be a new exporter format
<zyga> elopio: but a small tool that uses stable, public plainbox APIs and subunit to stream stuff
<zyga> elopio: that's the thing I was talking about earlier (new shiny stuff == public api)
<elopio> fgimenez: with one command, I magically have a snappy jenkins running :)
<elopio> zyga: sounds good.
<fgimenez> elopio, great! :)
<elopio> so, feel free to join us next week, any time you want.
<mterry> elopio, cc is broken...
<mterry> :(
<mterry> elopio, can I see those logs it mentions?
<elopio> mterry: the thing is that if I ssh into the machine and run it, it works.
<elopio> mterry: you can, but I need like 15 minutes. This is slow.
<elopio>  mterry: are we going to have snapcraft in the archive soon?
<longsleep> mterry: Do you have any more comments on my snapcraft debs plugin? https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650 - Do you think something like this makes sense to upstream to you guys?
<mterry> elopio, I can upload it to the archive, when we think it's ready.  rsalveti, do we think it's ready?  :)
<rsalveti> mterry: elopio: we can upload to the archive already, sure
<mterry> longsleep, sorry for slow reply  :)
<mterry> longsleep, so your use case is sort of a workaround the fact that we don't have cross building.  Plus an emphasis on making sure you have the exact version you want
<mterry> rsalveti, ok, can upload to wily later today then
<mterry> elopio, ^
<longsleep> mterry: yes - the cross building might go away in the future, but i still need to build in clean environment (which is provided by pbuilder for deb file)
<longsleep> mterry: From my point of view, this was the easiest way to build a snap from existing deb files. It was even easy to add another deb file as i found i had to ship openssl binary inside my snap.
<ted> Could we build an ARM Snappy image that's like this one: https://fedoraproject.org/wiki/Architectures/ARM/F22/Installation#For_Versatile_Express_Emulation_with_QEMU
<mterry> longsleep, it seems like you may have dependency problems a lot with this strategy
<longsleep> mterry: i also have the idea that this could be extended to build multi arch snaps by creating sub folders per arch and extract the corresponding deb files to this subfolders and detect the arch in start script.
<longsleep> mterry: Yes, it does not resolve dependencies automatically. Though the developer writing the snap file can resolve those manually.
<mterry> longsleep, if we had cross building support, would pointing at a git branch with a tag be enough of reproducable build for you?
<guest42345> how big is ubuntu personal image? i want to try it from USB
<mterry> dholbach, why did you remove my utf8 characters from the docs?
<mterry> They were so pretty
<longsleep> mterry: No, reproducable builds need to pull and install dependencies required at compile time. Thus i would always go through a debian package to have reproducable builds.
<dholbach> mterry, when I ran markdown on the file, the output wasn't pretty
<ogra_> guest42345, a month ago the img that ubuntu-device-flash produced was 9GB
<longsleep> mterry: dpkg gives that all, i think it will a lot of work to replicate that within snapcraft
<ogra_> not sure if it changed
<mterry> elopio, your makedirs branch failed to merge
<elopio> wtf, simple cmake passed now.
<longsleep> mterry: alternative would be to run snapcraft in pbuilder environment and have it produce a snap instead of deb
<guest42345> ogra_, thanks :> that's pretty BIG! i have a tiny 4G USB stick, i guess it's time to buy new ones
<mterry> longsleep, that would be something we'd expect would work
<mterry> dholbach, markdown doesn't handle utf8?  shocking...
<guest42345> ogra_, so.. for now there is no way to install ubuntu personal on a diff partition, right?
<guest42345> i can't have ubuntu 14.04 and ubuntu personal on the same hdd
<elopio> mterry: let me check tarmac.
<longsleep> mterry: well thinking anbout it .. that will not work because that environment mit not be able to compile all the stuff in one shot. It would need to setup a environment for each dependency. I think that is too complicated.
<ogra_> guest42345, there surely is a way to dd the img file to some other device from a live-booted system or so
<ogra_> but yeah, you would need to overwrite the whole device ... there is no dual boot or anything
<longsleep> mterry: I think lots of people might like to simply extract their deb files into a snap and add a start script. That is simple and people need to know about their dependencies only.
<ogra_> (and snappy is really not designed for something like that)
<sergiusens> longsleep: Weâve been working on adding support for building snap packages (#1476405), but thereâs still more to do here; we should be able to make this available to some alpha testers around mid-August
<sergiusens> http://blog.launchpad.net/general/launchpad-news-july-2015
<sergiusens> https://bugs.launchpad.net/launchpad/+bug/1476405
<ubottu> Launchpad bug 1476405 in Launchpad itself "Add support for building snaps" [High,In progress]
<sergiusens> mterry: to build for armhf I'd need native/emulated arm, right?
<longsleep> sergiusens: launchpad building snaps would be nice.
<guest42345> ogra_,  thanks, that's what i thought.. i don't know how to feel about it
<guest42345> ogra_, i need some beer :)) thanks again
<longsleep> sergiusens: lots of stuff does not build on emulated arm
<ogra_> enjoy the beer :)
<guest42345> mmmm delicious
<longsleep> sergiusens: that is why we have a arm build cluster here, though that only supports pbuilder
<sergiusens> longsleep: oh, I know... I hate it, I'm just avoiding pedantic people clarifying that it could be done with qemu-arm-static
<sergiusens> :-P
<longsleep> sergiusens: so, when you have launchpad building snaps, i suppose you will activate armhf only upon request similar as for debs?
<mterry> sergiusens, yeah
<ogra_> sergiusens, did you just call me pedantic ?
<ogra_> :P
<tasdomas> does the orange box mac address change on reboot?
<ogra_> tasdomas, yes, working on a fix, a new image should be ready before end of the week
<ogra_> (the current bootloader setup swallows the MAC and serial of the rpi)
<longsleep> mterry: So explaining my current use case: I have clean built spreed-webrtc deb packages and want to make a snap out of it.
<mterry> longsleep, I follow...  Hrm, let me look at MP again
<mterry> longsleep, thanks for explaining to me
<longsleep> mterry: Sure - with that suff i was able to add the snap to the store, so either nobody is as crazy as me yet or everyone sets up a clean build system for every build :)
<sergiusens> mterry: I notice that easy install/py2 rewrites the shebang to my local machine; any way around that? (thinking of my binary entry calling out python2 explicitly)
<mterry> sergiusens, easy install/py2?
<longsleep> sergiusens: by the way, any chance that at some point Go can be built by launchpad on armhf: https://launchpadlibrarian.net/207704013/buildlog_ubuntu-trusty-armhf.golang_2%3A1.4.2-1%2Bstruktur0%2Btrusty0_BUILDING.txt.gz ?
<sergiusens> mterry: setuptools/easy_install/python 2
<sergiusens> mterry: did you see my diff?
<sergiusens> mterry: http://paste.ubuntu.com/12006412/
<longsleep> sergiusens: We have all the gear on lp to provide debs for armhf but go builds crash with Segmentation fault
<sergiusens> mterry: I think I just duplicated some work there
<sergiusens> longsleep: oh, you are using virtual builders I guess
<longsleep> sergiusens: yes
<sergiusens> longsleep: I don't know a way out of that
<longsleep> sergiusens: i mean it is not a big deal as we build locally as well, though i think Golang should be buildable for all platforms on launchpad :)
<ted> mterry, So, on your comment to rename ubuntu.package to just ubuntu.packages everywhere... I'm not against that, but I'm curious if it'll break too many folks at this point.
<ted> mterry, Perhaps we change the plugin yaml and take both
<mterry> ted, and warn on both being used maybe?
<mterry> ted, I mean error out I guess
<ted> Yeah, I'm fine warning in that it will *work*
<mterry> ted, are there too many people now?
 * ted assumes everyone is using snapcraft now
<sergiusens> mterry: I seem to be able to get away with it with 'binaries:\n  name: python ./usr/bin/app'
<ted> IBM is probably already working on an XML schema for it.
<mterry> sergiusens, yeah, snapcraft has special logic (thanks to ted) to repurpose your 'python' call to the internal python
<mterry> ted, I bet it's fine to break world
<mterry> :)
<ted> K, I'll break 'em ;-)
<mterry> ted, as long as we error on unknown options?  I don't think we do yet
<mterry> ted, maybe add that to your branch too?
<mterry> ted, OR....  have a warning saying it's deprecated but still accept it
<ted> mterry, Well I was just gonna require packages
<mterry> ted, and error out if both are used
<mterry> ted, fair on requiring packages, forgot that detail
<mterry> ted, oh wait, you don't get to auto-infer package name?
<mterry> ted, I loved that feature
<mterry> was I the only one?
<sergiusens> mterry: you mean the magic symlinking?
<mterry> sergiusens, hrm?
<sergiusens> mterry: you sai special logic
<ted> mterry, Heh, not sure it's really practical. Doubt anyone will have a single package that often.
<dholbach> dpm, mterry, rsalveti: https://developer.ubuntu.com/en/snappy/snapcraft/ - it's not auto-imported yet, nor announced anywhere
<mterry> sergiusens, oh no, we change how we wrap your binary call to make your 'python' bit be found  (normally snappy binary paths are relative paths to the executable in the snap, not PATH-resolved commands)
<mterry> ted, what, you're crazy
<sergiusens> mterry: this is what I have now http://paste.ubuntu.com/12007310/ but if I specifically launch as 'python app' I can get around the broken shebang
<rsalveti> dholbach: nice
 * sergiusens starts the trek back home
<mterry> elopio, in your dep8 branch, why not just run the unit tests too?  If they end up being broken (by unittests api changing or wget being broken), we'd want to know about that as well.  At the least it means snapcraft would ftbfs on a rebuild
<elopio> mterry: the unit tests are run when the deb package is built.
<elopio> then it is installed, and we run the test-as-installed, the dep8.
<elopio> if we put the unit tests in dep8 they would run twice.
<mterry> elopio, yup.  But when a depends of snapcraft is uploaded, snapcraft's dep8 tests are run.  And we want the unit tests run then too
<elopio> mterry: ok, that makes sense I think. Do you want to keep the integration-tests/runtests.sh script, or should I merge it back?
<mterry> elopio, I'm fine with those split sure
<elopio> now if only it passed...
<kyrofa> Hey ogra_ any update on the rpi2 i2c and gpio stuff?
<ogra_> kyrofa, on it ... right now :)
<ogra_> (some blockers showed up that i had to fix first)
<longsleep> qjkc
<longsleep> err sorry
<kyrofa> ogra_, awesome! I have to work up a demo by this time next week. Do you suggest waiting for i2c for my plan A, or start working on my plan B?
<longsleep> quick question, how does the snappy tool access the store, where does the configuration come from>
<longsleep> ?
<ogra_> kyrofa, i should have some image for testing later tonight or tomorrown morning
<kyrofa> ogra_, ah! Okay, I'll wait :)
<ogra_> you will still have to hack something if you want to use overlay dtb's though, since i dont expect the needed udf fix to land in time for that
<ogra_> (unless sergiusens secretly developed something i dont know about )
<kyrofa> ogra_, I'm fine hacking stuff to work as long as you're willing to guide me... ?
<ogra_> sure, np
<kyrofa> longsleep, it hits system-image.ubuntu.com, using the image channel and device to build the URL
<kyrofa> longsleep, well, that's what happens when I try to update the index anyway
<longsleep> kt
<longsleep> kyrofa: yes
<longsleep> kyrofa: but how does it find and download snaps?
<kyrofa> longsleep, it's the same store as clicks
<longsleep> kyrofa: ok - but where does the URL come from?
<longsleep> kyrofa: i found the configuration for the system image - but no luck for the store yet
<kyrofa> longsleep, snappy/snapp.go: https://search.apps.ubuntu.com/api/v1/
<longsleep> kyrofa: thanks! i am just blind obviously
<kyrofa> longsleep, no problem!
<kyrofa> Hey ogra_ got a sec for a framework question?
<ogra_> not sure i can answer it, but sure, shoot :)
<kyrofa> ogra_, well with my (limited) understanding of frameworks, I felt that apache or nginx should be frameworks, but you felt differently which means you obviously know more about them than I do :P
<kyrofa> So I have something else I feel should be a framework, and wanted to bounce it off of you
<kyrofa> ogra_, are you familiar at all with ROS?
<mterry> elopio, have you tried your new dep8 branch in a chroot?  I'm guessing that @ isn't enough to cover all the deps you need (it's only run time deps, not build time deps, right?).  Like it won't have python3-testscenarios, needed for the unit tests
<ogra_> only via reading about it :)
<elopio> mterry: I've added them, let me push.
<kyrofa> ogra_, that's probably good enough. ROS Core is the hub of the star-like message architecture, with various clients connecting to the core in order to learn about other clients and pass messages around
<elopio> still, I can't get it to pass. Errors range from unable to install all the deps to gcc not found.
<kyrofa> ogra_, would ROS Core make
<elopio> I'll put it back to work in progress.
<kyrofa> ogra_, a good framework?
<kyrofa> ogra_, since there can only be one that all clients must share
<ogra_> yeah, but i'm not the master of frameworks or even their definition ... to me ROS definitely looks like a good framework but i'm guessing as much as you here :)
<mterry> elopio, you can do @builddeps@!  I didn't know that before now
<elopio> mterry: right, but in the docs it says we should probably not use it.
<mterry> elopio, that could be your entire line.  Depends: @builddeps@
<kyrofa> ogra_, alright, thank you! I just wanted to get your impression before I looked any further
<ogra_> our framework definition definitely needs a better description of what a framework is or can be
<kyrofa> ogra_, agreed... a bit muddy
<mterry> elopio, hmph
<ted> mterry, Okay, pushed the 'packages' changes. It required a bunch of changes in different places, but not as big of a diff as I was worried about.
<sergiusens> mterry: git@github.com:sergiusens/galileo.git
<elopio> s/dep8/pep8. /me needs sun light.
<longsleep> kyrofa: I think that Nginx should be a framework as well. But i have no idea about what a framework is supposed to be :)
<kyrofa> longsleep, ogra_ who knows that stuff? Or is it still being fleshed out?
<ogra_> kyrofa, i guess one of the architects (lool perhaps) could shed more light on it for you
<longsleep> ogra_, kyrofa : Yes lool had some ideas about this a couple of days ago. I think his suggestion was just to move forwards and see how it goes.
<ogra_> lol
<ogra_> right
<ogra_> diplomacy FTW :)
<kyrofa> longsleep, that's potentially brutal advice :P
<longsleep> well the stuff is fresh - so whoever comes first defines the standard :P
<kyrofa> longsleep, or goes to the effort of trying it only to get told "that's not how we use frameworks," heh
<longsleep> kyrofa: well yest - but if you have the need to do it exactly that way and it is not possible with the existing definition the world needs to expand
<longsleep> i like the idea to see how it goes
<longsleep> and i need a Nginx framework as well and i might go forward with writing one, or i add Nginx to my system image ..
<longsleep> probably a bad idea :D
<longsleep> ogra_: I am back to resarch on system image building. What i understand is that i should run ubuntu-cdimage with http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/live-build/ubuntu-core/ hooks - does that make sense?
<ogra_> longsleep, no. you really dont want to run ubuntu-cdimage :)
<ogra_> what you want to run is live-build with the changes from the livecd-rootfs package applied
<ogra_> (this is essentially all that ubuntu-cdimage would do)
<longsleep> ok - what is live-build ? another couple of scripts?
<ogra_> longsleep, https://code.launchpad.net/~ogra/project-rootstock-ng/trunk
<longsleep> ogra_: awesome thanks
<ogra_> look at the rootstock-touch script ... it essentialyl does what a buildd does
<ogra_> (note also that it cant build wily for core currently, but vivid works ... just takes ages)
<ogra_> it shoudl give you an idea ...
<longsleep> ogra_: well i have gear to build a rootfs for normal Ubuntu already. Do you think it would make sense to start from that and just apply the changes for snappy?
<ogra_> no, it wouldnt, it would make sense to just use -core as is and make your changes in the snaps ... or to ask us to add/remove bvits from core as needed
<longsleep> ogra_: yes - but not everything can be done in snaps and not everything should be in core. Some things are specific to a single device. I still fail to see how that can work without modification of the boot process or other things in core.
<ogra_> via unconfined snaps for example
<longsleep> mhm - could i overwrite stuff from the base system? That sounds iffy on update
<ogra_> the plan is that you have a gadget snap for your appliance ... that is the only snap that can actually have dependencies -...
<ogra_> these dependencies would be your add-on snaps that enhance core
<longsleep> all right - i think i can try that
<ogra_> in any case you should never need to modify core
<longsleep> what if i want to use another system image server, or even another api endpoint for the store?
<ogra_> if you have to, we either have to much or not enough functionality in core :)
<longsleep> like a self controlled one, or a local one
<ogra_> system-image will go away soon, it will only be the store
<ogra_> (core will become a snap too)
<ogra_> and for the store bits i can point to beuno :) as usual :)
<longsleep> hehe - well i will be among the first to test all this once it is available - in the meantime i will experiment
<sergiusens> mterry: is the source_type key in yaml source_type as well?
<elopio> mterry: this is the only remaining failure: http://paste.ubuntu.com/12007972/
<elopio> the message is not useful, and when I ssh into the machine, extract the tar and run make, it just works.
<beuno> longsleep, the store's endpoint won't be changeable (and isn't)
<mterry>  sergiusenswhat was that about source-type in yaml?
<mterry> elopio, yeah, that looks like gcc failing...
<mterry> sergiusens, what was that about source-type in yaml?
<elopio> mterry: how can we print the error? I added gcc -v, but no output on is printed.
<mterry> elopio, it might be crashing?
<sergiusens> mterry: ah, thanks
 * sergiusens wants a schema
<mterry> sergiusens, well the source-type stuff is plugin-specific (though shared between a lot of plugins, granted)
<sergiusens> mterry: we probably want to document those anyways
<sergiusens> mterry: I have to argue that it is not plugin specific as it is part of PluginsBase ;-)
<sergiusens> even if private
<sergiusens> mterry: anyways that's me arguing about nothing important :-)
<mterry> sergiusens, well the CODE is shared.  But plugins can expose/parse the option how they like.  We just have helpers.  But yes, they are so common as options, we should document them
<sergiusens> mterry: care to look at https://code.launchpad.net/~sergiusens/snapcraft/mercury/+merge/267080 ?
<mterry> ted, don't you think all those packages: [onething] lines are grosser than the implicit package?
<sergiusens> mterry: hey, there isn't much of a test base for code checkout; I need to remember how to mock to mock the run commands; maybe elopio can help template that for bzr/hg/git pull
<ted> mterry, I think that they are uglier, but I guess I see it as an exception more than the rule. The examples are simpler than most projects.
<ted> mterry, I'd be happy to put back the implicit package if you feel strongly though.
<mterry> ted, so there are two major types of projects: ones that use parts as dependencies and 'integration' projects that pull things together.  In integration projects, you'll want toplevel packages like 'apache2' or whatever.  Or fswebcam in examples.  Logically distinct, toplevel parts.  I think for those it makes sense for the implicit syntactic sugar
<mterry> sergiusens, doesn't that already exist in test_base_plugin?  we do something with bzr there
<sergiusens> mterry: I only see error checks for setting branch in bzr and the most complex test there is pull_tarball
<mterry> sergiusens, yeah... Ok.  So maybe just add error checks for yours.  Unless you feel fancy and want to mock hg
<sergiusens> mterry: I'd rather have elopio write me a template ;-)
<sergiusens> mterry: and I did convert the git/hg into a scenario based test class for errors
<mterry> sergiusens, and you've tested this I assume on real hg branches?
<mterry> sergiusens, ooh wait
<mterry> sergiusens, the integration-tests have some live git/bzr tests.  hg would be good to add to that, to confirm we don't break cloning or updating
<sergiusens> mterry: yes, I already replaced my codebase
<sergiusens> mterry: oh, and --user + --root (instead of --prefix doesn't require a PYTHONPATH, I haven't tested if it produces anything that works yet)
<sergiusens> mterry: sure, I will add an integration-test
<sergiusens> oh, I need a newer plainbox
<sergiusens> mterry: what was the ppa I needed for that?
<mterry> sergiusens, ppa:hardware-certification/public (from HACKING.md)
<sergiusens> mterry: silly me, I only search for 'plainbox'
<sergiusens> thanks
<ted> mterry, implicit package is back :-)
 * mterry dances
<ted> mterry, What did you do to work around the store not supporting architectures
<ted> ?
 * beuno squints
<beuno> not supporting architectures?
<ted> beuno, The 'architectures' key in the yaml
<beuno> ah
<beuno> the store doesn't look at the yaml
<beuno> it looks at the json
<beuno> that is created on build time
<ted> Oh, interesting.
<beuno> it still treats it as a click
<ted> Everyone uses JSON :-)
<mterry> ted, used architecture instead
<ted> mterry, Can that be an array?
<mterry> ted, I think so?
<ted> K
<rsalveti> ted: how is the qml mr going?
 * ted is trying to make mterry happy :-)
<rsalveti> :-)
<mterry> hmm..  i should look at that again
<mterry> I think it's ready
 * ted buys flowers
<mterry> ted, run ./runtests.sh
<mterry> ted, need to update test_get_all_dep_packages_with_unrecognized_package
<ted> mterry, "Everything passed"
<mterry> ted, merge from trunk then?
<ted> Ah, K, that breaks it :-)
<ted> mterry, Updated
<sergiusens> mterry: updated the mercurial branch (took longer than expected)
<sergiusens> I also played a bit with --user and such, but everything goes bonkers wrt to path rewrites
<ogra_> rsalveti, that livecd-rootfs stuff slowly turns into an all nighter :(
<mterry> Uploaded initial version of snapcraft to wily!
<ogra_> \o/
<ted> *snap* !
<mterry> ted, your qml plugin made it
<ted> Oh, cool.
<ted> Are the docs live?
<ted> I should put links in my blog post and get that out.
<rsalveti> ogra_: oh crap
 * rsalveti hugs ogra_ 
<rsalveti> mterry: nice
<mterry> ted, it hasn't landed in wily yet, has to be manually approved since it's a new package
<mterry> ted, I don't know if docs are live
<davmor2> ogra_: like you need sleep
<ogra_> davmor2, :P
<davmor2> ogra_: you know you're not happy unless you wake up the shapes of keys imprinted on the side of your face ;)
<ogra_> yup, if they are not there my GF doesnt actualy recognize me anymore
<davmor2> ogra_: or wants to know what you've been up to :)
<ted> Seems like there's no way to specify a service with a timer, to start it hourly or whatever
<ted> Is that on purpose or just not got there yet? :-)
 * ogra_ triggers another phone image and goes afk for a bit
<ogra_> phew, finally
<sergiusens> elopio: mind checking https://code.launchpad.net/~sergiusens/snapcraft/mercury/+merge/267080 ?
<ogra_> slangasek, did you see my PM from earlier today (no action needed right now, i just want to make sure the question got through to you)
<elopio> sergiusens: looks good. But you are missing the data dirs.
<elopio> cp: cannot stat â/home/elopio/workspace/canonical/snapcraft/reviews/sergiusens/mercury/integration-tests/data/hg-headâ: No such file or directory
<sergiusens> elopio: err, let me bzr add!
<slangasek> ogra_: hi - yes, I did; the whole thing looks fine to me, so I wasn't sure what needed commenting on
<ogra_> slangasek, ah, cool, i just didnt want to say yes or no without feeling qualified enough
<ogra_> slangasek, mainly marks comment of using a new distributor ID for snappy
<ogra_> (instead of "Ubuntu" ... )
<slangasek> so it's possible that third-party things may make assumptions about the values of these field
<slangasek> s
<slangasek> but those things are likely not looking at the snappy one
<ogra_> ok
<sergiusens> elopio: there we go (network was slow)
<sergiusens> elopio: I don't mind a top approve ;-)
<elopio> sergiusens: let me run the tests.
<elopio> sergiusens: I like that you left the error conditions for unit tests, and the snapcraft command for integration.
<elopio> any thoughts about writing tests for snapcraft?
#snappy 2015-08-06
<sergiusens> elopio: I hinted earlier that if we get the right mocking level I don't mind extending the unit tests for snapcraft itself
<sergiusens> elopio: but there is no test code for that in there and I didn't want to deviate from the current status quo in my first contribution ;-)
<sergiusens> elopio: and you last comment taken into account
<elopio> sergiusens: top-approved.
<elopio> sergiusens: I think I wouldn't want to mock hg, or git. But I don't like the tests written in those plainbox commands.
<sergiusens> elopio: \o/ one more MP and I can build py2 and hg projects from the ether
<elopio> I would prefer to have integration tests written in python.
<sergiusens> elopio: heh, feel free to change it all ;-)
<sergiusens> elopio: would it be python snippets given plainbox?
<elopio> well, I first need a good reason to re-do all the work.
<elopio> I'm not sure why do we want plainbox here. So I'll wait for our qa meeting next week to talk about it with zyga.
<sergiusens> elopio: what I like of it being a script is that I can read all about it when it fails really easily, aside from that, nothing else; I prefer compiled languages these days to not run things and find typos along the way ;-)
<elopio> he did a lot of work to get it working with plainbox, so...
<elopio> what I don't like is the lack of cleanups, fixtures, assertions.
<sergiusens> elopio: latest snapcraft is broken for me, can you check? I think it's 'self.recommends = options.recommends or False' whereas we probably want getattr there
<elopio> sergiusens: what command are you running? Some commands work for me using trunk.
<sergiusens> elopio: right, it's when executing certain projects that use the ubuntu plugin
<sergiusens> elopio: http://paste.ubuntu.com/12010834/
<sergiusens> elopio: that's what I mean
<elopio> right, that looks good.
<elopio> sergiusens: + one test, it would look perfect :)
<sergiusens> elopio: let me propose an MP and see if I can write a small test
<elopio> sergiusens: there's test_ubuntu_plugin.py
<sergiusens> elopio: is there an assertNotRaises?
<elopio> sergiusens: no, for that case what I do is just to end the test with the call.
<elopio> if it raises something, the test will fail.
<elopio> a comment saying like # The call should not raise an error. would be nice.
<sergiusens> elopio: https://code.launchpad.net/~sergiusens/snapcraft/recommendedOptions/+merge/267119
<sergiusens> elopio: took a slightly different approach
<sergiusens> elopio: https://code.launchpad.net/~sergiusens/snapcraft/setuptools/+merge/267121
<sergiusens> see if you have a better idea there
<elopio> sergiusens: can't you specify the python-setuptools dependency in the yaml of your package?
<elopio> there are other setup packages, so not all will require setuptools.
<sergiusens> elopio: I can, but I thought it be pretty common
<sergiusens> elopio: well now that I know about the 'after' keyword; but the PYTHONPATH gimmick would go where?
<sergiusens> anyways, bed time :-)
<ToyKeeper> Snapcraft looks very helpful...  am hoping to try it this week.  :)
<ToyKeeper> (building and packaging a python-based network game)
<fgimenez> good morning
<dholbach> good morning
<JamesTait> Good morning all; happy Fresh Breath Day! ð
<longsleep> i think i have found a bug in snapcraft ubuntu plugin, it does not fix up symlinks to folders, but it seems that os.walk does list symlinks to directories which exist in dirs rather than in files and the plugin only checks the files.
<ogra_> well, i guess at this state snapcraft bugs are still pretty expected ;)
<ogra_> file it :)
<longsleep> right - my Python got a little rusty since Go is around ..
<hio> what is the ETA?
<ogra_> 7am on a sunday
<hio> i mean the ETA of snappy
<ogra_> for what exactly ?
<hio> so that i can use it as my production server environment
<ogra_> snappy is out there and is used by projects already ...
<hio> ogra_: i cant find the iso download?
<ogra_> really depends what you want to do with it
<hio> well i told you: server for my webapps
<sergiusens> hio: it's available on the major cloud envs already fwiw
<hio> well i have a VPS / root server
<hio> i need to install it there with an ISO
<longsleep> ogra_: made a patch instead https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176
<hio> and on vmplayer too
<ogra_> there is no installer yet and it is currently mainly focusing on IoT, cloud and embedded
<ogra_> you would have to boot from some other media and then dd the img file to disk ... not sure that will work with a VPS at all though ... since you often dont have control over the kernel in such setups
<ogra_> and snappy has pretty specific requirements on the kernel config
<ogra_> (and on the bootloader for all the rollback functionality)
<Mikaela> hio: https://developer.ubuntu.com/en/snappy/start/
<longsleep> So, someone would be so kind to review https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176 please
<sergiusens> mterry: do you have your snapcraft project for the webcam thing available anywhere?
<mterry> sergiusens, my own code for the demo is lp:~mterry/snapcraft/mitdemo (mostly just trunk's webcam-webui example + go-on-arm branch + a couple change to the webcam code to work in my case)
<longsleep> mterry: have you seen https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176 - i think it is important to merge that asap to avoid problems with absolute directory links with the ubuntu plugin.
<mterry> longsleep, yeah I did, thanks!  Good catch.  I approved it, but then noted that I realized that you weren't in the contributor agreement LP team.  Have you signed the contributor agreement?
<longsleep> mterry: no i did not - can it be signed on compay level?
<longsleep> company
<mterry> longsleep, yes -- I gave a link in the MP
<mterry> longsleep, www.ubuntu.com/legal/contributors
<longsleep> oh i missed that sorry
<mterry> longsleep, no worries, LP mail gets delayed or filtered weird sometimes  :)
<longsleep> mterry: I gave the contributor agreement to my boss and he will eventually sign it. I think the symlink patch is trivial and you can just merge that. I will let you know when the agreement is signed. Let me know if you have any further comments to the debs plugin.
<mterry> longsleep, I'm off tomorrow (and am switching teams shortly) -- you may want to poke mvo or rsalveti after today.  Just heads up  :)
<mterry> longsleep, but understood re: symlink
<longsleep> anyone got thoughts how to run multiple services from a single snap? I consider to use supervisord similar like it is used with Docker. What do you think?
<ogra_> ARGH !
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ifconfig
<ogra_> enxb827eb04db1c Link encap:Ethernet  HWaddr b8:27:eb:04:db:1c
<ogra_>           inet6 addr: fe80::ba27:ebff:fe04:db1c/64 Scope:Link
<ogra_> yay for discoverable interface names
<longsleep> lol
<ogra_> but even worse :/
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv
<ogra_> Warning: Bad CRC, using default environment
<ogra_> damn
<longsleep> 4 byte 5 byte problem?
<longsleep> check the hexdump
<ogra_> could be, not sure
<ogra_> though no, the snappy code fails too
<ogra_> and that should be safe against the header byte issues
<longsleep> how did you create the file? saveenv?
<ogra_> mkenvimage -s 131072 -o uboot.env uboot.env.in
<longsleep> uh
<ogra_> well, it works just fine in uboot
<ogra_> and i see onyl 4 bytes in hexedit
<longsleep> ogra_: try adding -r parameter to mkenvimage
<ogra_> then uboot doesnt accept it anymore
<longsleep> but the snappy tool loads it?
<ogra_> though let me try again, might have been the other build
<longsleep> then you have 4 bytes header if you did not add -r
<longsleep> you have to use 5 bytes to make fw_* tools work
<longsleep> (or change their config)
<ogra_> reading uboot.env
<ogra_> *** Warning - bad CRC, using default environment
<longsleep> right, make sure you have #define CONFIG_ENV_SIZE                 (128 * 1024) and #define CONFIG_SYS_REDUNDAND_ENVIRONMENT in your u-boot config
<longsleep> then you will have 5 bytes header and i guess it will just work
<ogra_> ah, the latter was missing
<ogra_> thanks !
<longsleep> i hope that was it
<joc_> could someone provide some assistance in checking whether an app we have snapped is running unconfined? (app is plainbox)
<longsleep> ogra_: still trouble that the snappy tool fails to parse the env file with 4 byte though
<ogra_> longsleep, thanks, that helped, looks all fine now
<longsleep> ogra_: great
<ogra_> so what the heck do i do with the NIC now :/
<joc_> ogra_: ricmm might one you be able to help with the above please?
<ogra_> joc_, sorry, i dont know how to determine that, perhaps from syslog
<longsleep> ogra_: where does that name come from? Check /etc/udev/rules.d/70-persistent-net.rules i think it should define the name alias there
<ogra_> well, where would that file come from on a readonly system ? :)
<longsleep> that file is writable
<ogra_> hmm, true
<longsleep> if you do not have it, it explains the strange name
<ogra_> right
<ogra_> so why dont i have it :P
<longsleep> now you are closer to the solution :D
<longsleep> but it is good that you have a problem with that file, because i have one too :P
<longsleep> (my nic is there twice with the same MAC)
<longsleep> elopio: Hi, the symlink directory problem can be seen in openssl for example. I pull in the openssl debs file with my debs plugin.
<joc_> hmm i'm seeing a lot of..
<joc_> Aug  6 15:14:12 localhost kernel: [ 8857.835029] audit: type=1400 audit(1438874052.138:70): apparmor="DENIED" operation="open" profile="plainbox.sideload_plainbox_0.23.dev0" name="/proc/1162/fd/" pid=1162 comm="python3.4" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<elopio> longsleep: ok, let me see if I can reproduce it.
<elopio> thanks for the patch btw.
<ogra_> joc_, that looks like confined (and with wrong profile actually)
<longsleep> elopio: sure, to reproduce just add openssl package to a snapcraft file using the ubuntu plugin
<joc_> ogra_: what looks wrong about the profile?
<ogra_> you get denials
<sergiusens> ogra_: seb128 is input known to not work in a kvm for ubuntu personal?
<ogra_> worked for me ... but i last tested a month ago or so
<ogra_> (mouse input)
<sergiusens> ogra_: yeah, thats what I recall too, not anymore it seems :-P
<ogra_> pitti, bah ... i cant get the network on my rpi 15.04 imae up anymore ... what was the magic incarnation to force it to be called eth0 ?
<pitti> ogra_: see /usr/share/doc/udev/README.Debian.gz
<ogra_> hmpf
<pitti> ogra_: either boot with net.ifnames=0, or touch /etc/udev/rules.d/80-net-setup-link.rules
<pitti> whatever is better
<ogra_> i cant really fiddle with udev rules, this is a released image
<ogra_> ah, that was what i was lookin for
<ogra_> kernel cmdline ;)
<ogra_> (for this image i can only change the bootloader setup actively )
<longsleep> ogra_: Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.
<longsleep> ogra_: haha - "should fix real problems"
<ogra_> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
<ogra_> i got that in front of me :)
<longsleep> interesting read
<ogra_> doesnt mention the boot option at all !
<longsleep> i wonder why the odroid does get named eth0
<ogra_> oh, it does
<longsleep> it does
<ogra_> i just gave up reading to the end :P
<longsleep> ogra_: why do you need to change it by the way, or why does the interface need to be named eth0?
<ogra_> because the 15.04 image has /etc/network/interfaces.d/etc0 hardcoded by default
<ogra_> *eth0
<longsleep> ah
<ogra_> that was only fixed in the rolling image
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv board
<ogra_> board=rpi_2
<ogra_> :D
<longsleep> (ODROIDC)root@odroid:~# fw_printenv board
<longsleep> ## Error: "board" not defined
<longsleep> should i have that?
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /proc/cpuinfo |grep erial
<ogra_> Serial          : 000000008b04db1c
<ogra_> \o/
<ogra_> i doubt the odroid uses board= anywhere
<ogra_> (i even doubt the rpi does :P but it is in teh default env)
<longsleep> (ODROIDC)root@odroid:~# cat /proc/cpuinfo |grep Serial
<longsleep> Serial		: 1b00000000000000
<longsleep> i am not sure that serial of mine makes any sense
<ogra_> well, nothing you need it for, do you ?
<ogra_> rpi needs it for the codecs
<longsleep> yes - well some snaps might want it
<ogra_> mine here gets seeded from the binary blob bootloader
<longsleep> mhm in u-boot i have a more complicated serial
<ogra_> the rpi kernel accepts a cmdline option to set it
<ogra_> perhaps the odroid has somethin similar
<longsleep> no - i think the kernel has the means to read the serial directly
<longsleep> what i do not understand why i get eth0 in my image
<longsleep> shouldnt i have some other name as well ?
<longsleep> well the serial is the same for the stock kernels from Hardkernel - at least its not my fault :)
<longsleep> dpkg -l|grep systemd
<longsleep> sorr
<longsleep> y
<ogra_> while you say systemd http://blog.darknedgy.net/technology/2015/08/05/0-androidinit/
<ogra_> :D
<ogra_> such an awesome trolling attempt :)
<longsleep> ahaha
<longsleep> nice
<sergiusens> stgraber: hey, do you have an lxd snap for armhf?
<cwayne> barry: hiya, was it you that was working on snaps based on .pex files?
<cwayne>  barry: hiya, was it you that was working on snaps based on .pex files?
<cwayne> (sorry if that repeated, my irc's been a bit wonky lately)
<ogra_> ( RaspberryPi2)ubuntu@localhost:~$ cat /proc/device-tree/soc/i2c\@7e804000/status
<ogra_> okay
<ogra_> \o/
<barry> cwayne: yep: http://www.wefearchange.org/2015/04/creating-python-snaps.html
<cwayne_> barry, yeah, so I believe we'd basically followed that, and we seem to be having some confinement issues :/  getting the following denial: Aug  6 15:14:12 localhost kernel: [ 8857.835029] audit: type=1400 audit(1438874052.138:70): apparmor="DENIED" operation="open" profile="plainbox.sideload_plainbox_0.23.dev0" name="/proc/1162/fd/" pid=1162 comm="python3.4" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<cwayne_> was wondering if that looked familiar
<ogra_> tyhicks might be able to help
<ogra_> being our fake jdstrand this week :)
<tyhicks> I can but I'll need a bit so I can finish something up
<cwayne_> tyhicks, hiya :)  any advice ^  I think we have security_template: unconfined set, so i imagine we should have access
<cwayne_> ah, ok
 * ogra_ tries snappy update on the rpi and crosses fingers
<ogra_> (using image 8 from 15.04 alpha)
<elopio> mterry: longsleep: https://code.launchpad.net/~elopio/snapcraft/symlinks/+merge/267218
<elopio> there are tests that check symlinks to directories. I think your bug is slightly different to that.
<ogra_> yay, boots from b :D
 * ogra_ tries rollback
<barry> cwayne: yeah, that doesn't ring a bell.  must be a new constraint since i wrote that blog
<tyhicks> cwayne_: ok, looking now
<elopio> longsleep: these are your problematic links, right?
<elopio> /tmp/stage/usr/lib/ssl/private
<elopio> /tmp/stage/usr/lib/ssl/certs
<elopio> um, no, those should work fine too.
<elopio> I'm confused.
<stgraber> sergiusens: sorta. I have one but it doesn't work. It's on my todo for next week to fix.
<elopio> ahh, I get it.
<elopio> the link destination must be an existing directory.
<longsleep> elopio: yes
<elopio> that's the bug in the original test.
<longsleep> if it is existing (means not broken) then it ends up as dir
<sergiusens> stgraber: thanks for the update!
<longsleep> elopio: and for openssl these dirs probably always exist
<longsleep> other question, snappy port conflicts - is the negotiable key actually implemented? How do i know which port i should listen?
<cwayne_> tyhicks, the thing we're talking about is plainbox btw, (lp:checkbox, then the manifest is in checkbox/plainbox/Makefile)
<ogra_> elopio, if you feel like http://people.canonical.com/~ogra/snappy/test/ has two rpi images, one built from stable 15.04 that i plan to release and one built from the 15.04 alpha channel with --revision=-1 for testing upgrade/rollback
<ogra_> (not urgent, but i would like someone else but me test it additionally before i release ... as extra datapoint)
<ogra_> kivi, ^^^
<kivi> ogra_, ?
<elopio> longsleep: sorry for being so dense. This should expose the bug and confirm your fix:
<elopio> https://code.launchpad.net/~elopio/snapcraft/symlinks-2/+merge/267240
<ogra_> kivi, err, ignore that ... tab mistmatch :)
<ogra_> kyrofa, ^^^
<elopio> ogra_: ok, I'll check after lunch.
<elopio> ogra_: I thought updates were not psosible with rpi.
<ogra_> i plan to release it tomorrow, so no hurry
<ogra_> elopio, kernel/oem updates arent
<ogra_> ubuntu-core wasnt until we fixed our uboot setup to use the uboot.env file ;)
<ogra_> so now pi users can at least get rootfs updates :)
<elopio> I see, that's nice.
<ogra_> yep
<ogra_> i2c should work too
<ogra_> (not that we ship any tools to test it actually though :P )
<elopio> woot for i2c.
<elopio> now I don't want to have lunch.
<ogra_> lol
<ogra_> there is also a way to use pverlay DTBs but i need to document that ... it isnt straightdforward until sergio adds directory support for oem snaps to u-d-f
<ogra_> *overlay
<kivi> ogra_, Aww... I thought I was special...
 * ogra_ hugs kivi 
<kivi> !hugs
<kivi> ubottu can't hug...
<tyhicks> cwayne_: my apologies, too many distractions for me today
<tyhicks> cwayne_: can you paste the relevant plainbox file in /var/lib/apparmor/profiles/ ?
<tyhicks> cwayne_: there should be 1 per binary but it looks like you only have 1 binary
<cwayne_> tyhicks, sorry, was afk for a bit: http://paste.ubuntu.com/12013969/
<tyhicks> cwayne_: ah, that's definitely not the unconfined template
<tyhicks> # Description: default AppArmor template
<cwayne_> ah, so are we setting it incorrectly?
<tyhicks> cwayne_: that's what I'm looking into
<tyhicks> https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
<tyhicks> cwayne_: ^ that page suggests that security-template is specified underneath 'binaries:'
<tyhicks> (all the examples show it underneath 'services:' but I think that should be interchangeable)
<cwayne_> tyhicks, hm ok, i think that may be it then, will play around with it
<cwayne_> tyhicks, thanks for taking a look!
<tyhicks> cwayne_: no problem - let me know if you still have trouble and I can dig some more
#snappy 2015-08-07
<dholbach> good morning
<JamesTait> Good morning all; happy Friday, and happy Particularly Preposterous Packaging Day! ð
<ogra_> kyrofa, did you see my ping yesterday ? there is an rpi image for testing with i2c enabled
<kyrofa> ogra_, wonderful! No, I must have missed it, I'm sorry :(
<ogra_> kyrofa, http://people.canonical.com/~ogra/snappy/test/ubuntu-15.04-snappy-armhf-rpi2.img.xz
<kyrofa> ogra_, I'll do that today :)
<ogra_> cool, thanks ... let me know if anyhting is missing
<cwayne> ogra_: is the rpi2 still 'unsupported'?
<ogra_> cwayne, until it can be built completely from upstream...
<ogra_> (which doesnt work even with the first pi yet i think)
<ogra_> cwayne, but the next image (above) will allow you update the rootfs now ... (not the kernel or bootloader though, so as soon as incompatible changes in the initrd happen you have to reinstall)
<elopio> good morning.
<elopio> hey ogra_, I ran the automated suite on the raspi image and it gets stuck in one of the failover tests. Should it support automatic rollbacks in case of failure?
<ogra_> elopio, hmm, i didnt test automated rollback, snappy rollback definitely works (as does snappy update) ... since updates did never work at all before it is at least not a regression ;)
<elopio> ogra_: yes, the tests that fake an update and rollback worked.
<ogra_> does the automated rollback work with the BBB ? perhaps it is a general thing with the new uboot setup we use ?
<elopio> I'm going to trigger the suite on the -1 image now.
<ogra_> cool
<elopio> ogra_: yes, bbb passed all the automated test on the latest 15.04 stable
<ogra_> well, i dont see it as a blocker if automated rollback doesnt work yet ... (since it never worked)
<ogra_> though we need to have a place for filing Pi specific bugs like that i suppose :)
<elopio> ogra_: agree to that. This release is clearly a huge improvement.
<ogra_> yep
<ogra_> the uboot re-org helped a lot in getting this to work :)
<elopio> ogra_: if you want to run the suite: branch snappy/15.04 in your GOPATH and go run _integration-tests/main.go --ip ... --arch arm
<elopio> more info in the _integration-tests/README.md file.
<ogra_> for next time :)
<ogra_> elopio, what did you have to do to get the piglow to work btw ? any extra config ?
<elopio> ogra_: no. I compiled https://github.com/schoentoon/piglow tests, scp to the board and ran with sudo.
<ogra_> but you didnt have to do anything on the board/image ?
<ogra_> (any extra config)
<elopio> ogra_: not that I remember. I did this half asleep, so I will try again. Maybe package a demo snap for the store.
<ogra_> cool
<ogra_> well, as long as it works i'm happy
<mhall119> does snappy use versioned frameworks like click does?
<ogra_> i dont think i have seen version strings in package.yaml files for frameworks (but that could mean nothing)
<ogra_> s/for frameworks/for packages using frameworks/
<mhall119> so, that's not good, having versioned frameworks for Click was intentional, it let's us guarantee backwards compatibility
<ogra_> swell, i dont really know .... frameworks are still a bit fuzzy wrt definition
<dpm> rsalveti, ogra_, I was thinking of a weekend project to snappify bonescript (http://beagleboard.org/support/bonescript) with the intention of also snappifying cloud9 IDE. Is this something I can give a go to with snapcraft? Do we have a nodejs plugin?
<ogra_> dpm, i tried packaging cloud9 in the past, it requires a certain(very old) version of nodejs, so you need to build that first
<ogra_> and i'm not sure there is a nodejs plugin yet ...
<ogra_> definitely worth a look :)
<dpm> ah, bummer. I had had a look at it already a while ago with node-snapper (I started with bonescript first, I didn't get to cloud9 yet), I thought it might be the time to try with snapcraft.
<ogra_> well, once you have a working binary packaging it is trivial
<dpm> Also it seems cloud9 have a new repo, perhaps they've also updated their old nodejs dependency? https://github.com/ajaxorg/cloud9
<ogra_> i know they were working on that ... but there was no ETA back then
<ogra_> so yeah, that would indeed be cool
<elopio> dpm: if you start write a nodejs plugin for snapcraft, that would be really nice.
<dpm> elopio, well, my intention wasn't to hack on snapcraft, but rather to use it :)
<longsleep> elopio: Do you have any plans for supporting multi arch snaps with snapcraft? I am wondering if i should add that to my debs plugin to have something similar to the webdm snap.
<elopio> longsleep: I'm not quite sure about the plan, but I think the original idea is to make containers with snapcraft and other development tools that can be easily deployed.
<elopio> so instead of handling all possible archs, you deploy the container on your target and build there.
<longsleep> elopio: ok - but how do the multiple archs end up in a single snap?
<elopio> longsleep: but you better ask rsalveti next week for a more accurate plan.
<longsleep> elopio: ok - sure. Is he also the one to ask about how the webdm snap is currently built?
<elopio> longsleep: I do not know. I haven't been paying a lot of attention to the future yet, looking more at the current code base. :)
<elopio> longsleep: https://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/README.md have you seen this?
 * longsleep takes a look
<longsleep> yes i have seen that - i guess should look at the build.sh script
<longsleep> elopio: ah yes that was helpful - thanks!
<elopio> longsleep: for webdm sergiusens is probably the best to answer your questions. He'll also be back next week.
<longsleep> sure, i think the target should be to build webdm with snapcraft :)
<elopio> longsleep: we are just waiting for dpm's npm plugin ;)
 * dpm hugs elopio :)
<ogra_> dpm, are we there yet ?
<ogra_> longsleep, sergiuens usually builds the webdm package
<dpm> ogra_, not weekend yet, so I haven't started ;)
<ogra_> lol
<longsleep> Are there any snaps which expose some configuration through Webdm or any other means?
<fgimenez> nice weekend everyone o/
<elopio> longsleep: like this? https://developer.ubuntu.com/en/snappy/guides/config-command/
<sergiusens> elopio ted: ogra_ I was trying the snapcraft qml plugin and noticed that the ubuntu plugin does not target a release, I think it should, right now I don't get the benefits of the qml plugin as I'm on trusty ;-)
<ted> sergiusens, Heh, yeah. I think it should grow to add PPAs as well.
<ted> sergiusens, Though, upgrade from Trusty man. Those are like old bits!
<sergiusens> ted: well, I was told that we need to use this as a validation for our tools
<sergiusens> ted: ;-)
<longsleep> elopio: yes thats what i have been searching for - all the stuff there should work?
<ted> We're probably going to have to wait for mvo to get back to seriously upgrade the Ubuntu plugin. He knows a bit about the apt python library. :-)
<elopio> longsleep: yes. If it doesn't, please report a bug and link it here to make it critical.
<sergiusens> ted: right, the problem is we probably need to extend apt to read from an 'alternate' sources.list for these things to work
<elopio> we don't have automated user acceptance tests for that, yet.
<ted> sergiusens, I think the lib can do that, you can configure the repos that it uses. That's just "advanced usage."
<elopio> sergiusens: isn't that the same case as cross arch compilation?
<sergiusens> elopio: sort of, except the runtime issues aren't there
<elopio> instead of doing cross distro, you should get a wily container and build things there, I guess.
<ted> sergiusens, If you want you can use the snapcraft-daily docker image and build in there. That's a more modern Ubuntu.
<sergiusens> ted: right, I'm not sure the plugin should behave differently depending on the release we want to target 15.04, 16.04, rolling
<sergiusens> today we don't have to make that distinction, not sure if it would be required in the future though
<ted> I think we'll always need to set it. Some people will want LTS versions of libs, others will want bleeding edge.
<longsleep> elopio: The config which gets passed to the hook is the complete config for all packages or is it somehow filtered?
<longsleep> elopio: btw - config for webdm seems to be broken - http://paste.ubuntu.com/12022165/
<sergiusens> ted: oh, I was creating an lxc install for wily ;-)
<elopio> longsleep: I'll let sergiusens answer your question, 'cause I don't know.
<sergiusens> ted: we should create an ubuntu-snapcraft template for lxc/d
<ogra_> +1
<elopio> longsleep: please report a bug in webdm.
<longsleep> elopio: ok
<ogra_> i really dont want to taint my host by installing dev packages for creating a snap
<sergiusens> longsleep: can you log a bug for that?
<ted> sergiusens, Eh, we're kinda taking it the other direction. Assuming a Ubuntu system and letting people build one up around there.
<longsleep> sergiusens: sure
<ted> sergiusens, So if you want, you can do it in Virtual Box or whatever the kids use on OSX today.
<longsleep> ted, sergiusens you should look at the debs plugin i made: Helps a lot to build snaps when you have deb files already (which you can build in pbuilder) - https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650
<longsleep> elopio: btw - who is reviewing/merging snapcraft stuff now - mterry said something about he switches team?
<ogra_> longsleep, i guess ted
<ogra_> (who deliberately stayed silent i guess :D )
<ted> Hehe
<longsleep> :D
<ted> Uhm, yeah, we honestly hadn't discussed that yet. But I'm guessing it'll fall on me as well.
<ted> Honestly though, we should get someone with more Python experience to review as well.
<ogra_> just rewrite it in shell
<ted> I'll go put tabs in everywhere and piss off all the Python people ;-)
<ogra_> its sanr anyway :P
<ogra_> *saner
<longsleep> sergiusens: bug #1482720
<nothal> Bug #1482720: Webdm config seems to be broken / KeyError on snappy config webdm <webdm:New> <http://launchpad.net/bugs/1482720>
<ubottu> bug 1482720 in webdm "Webdm config seems to be broken / KeyError on snappy config webdm" [Undecided,New] https://launchpad.net/bugs/1482720
<elopio> longsleep: yes, we'll have to share the load. With when mvo and chipaca are back it should be easier.
<longsleep> ted: haha i had to change my python code to use spaces to be in line with snapcraft code ..
<ted> :-)
<ted> Okay, lunch bbiab.
<sergiusens> ted: I don't follow the direction comment, but we can discuss it next week
<ogra_> sergiusens, does udf check the content of id_rsa.pub when enabling developer mode ?
<sergiusens> ogra_: no
<ogra_> ah, cool ...
<sergiusens> ogra_: are you thinking of a hack? ;-)
 * sergiusens will make ogra_ life more complicaed
<sergiusens> :-P
<ogra_> sergiusens, no, i just re-built the rpi image
 * sergiusens jokes
<ogra_> and that has --developer-mode by default ... to be on the safe side i created an enty with only zeros ... but that might not be so clever :)
<ogra_> sergiusens, hmm, but udf definitely mangles it
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat .ssh/authorized_keys
<ogra_> None
<ogra_> i had added a nice descriptive comment there originally :)
<ogra_> (not that it matters much(
<longsleep> elopio: Is it possible to provide a default config with a snap, or does it run the hook after installation?
<ogra_> longsleep, hmm, should your spreed app actually switch on the camera on my laptop ?
<ogra_> (installs fine on rpi btw)
<ogra_> taking a picture woorks fine though
<longsleep> ogra_: if you make a call yes
<longsleep> if you do not make a call then no
<ogra_> ah
<longsleep> so for testing open up another tab an call yourself
<ogra_> i thought it was just a chatroom
<longsleep> its more like a phone system
<ogra_> k
<ogra_> looks really nice
<longsleep> thanks for testing!
<longsleep> i will add some configuration for the ports and certificate - then i am pretty much done
<ogra_> hah !
<ogra_> funny sounds
<longsleep> :D
<kyrofa> ogra_, I'm downloading the image now (was at the mechanic's this morning)
<kyrofa> ogra_, I'm not super clear from your email what needs to happen to get the overlay dtb working. Extract /boot/uboot/overlays.tgz into /boot/uboot, and then put what in the config.txt?
<kyrofa> I've not messed with that file before
<kyrofa> ted, are you a snapcraft maintainer?
<ted> kyrofa, Sure, what's up?
<kyrofa> ted, a simple snapcraft recipe using only the ubuntu plugin uses dget, which is in devscripts, which isn't pulled in as a dep when installing snapcraft. Is that something that should be fixed?
<ted> kyrofa, Uhm, yea.
<ted> It should work out of the box :-)
<kyrofa> ted, want me to make an MP?
<ted> kyrofa, Sure, or a bug.
<kyrofa> ted, both it is
<asac> kyrofa: ted: not sure if its a bug or the spirit ... but when i used snapcraft it lazily/ondemand asked for installing the dependencies of the used plugin (e.g. it asked me for sudo pass when snapping something with ubuntu plugin)
<asac> did it ask you for a password to install it lazily? or just error?
<kyrofa> asac, no, just error: https://bugs.launchpad.net/snapcraft/+bug/1482747
<ubottu> Launchpad bug 1482747 in Snapcraft "Snapcraft uses dget but doesn't depend upon devscripts" [Undecided,Fix committed]
<asac> kk
<kyrofa> asac, but perhaps that means the fix is different than what I proposed
<asac> maybe its fixed in trunk then... as it did this for for the wget example
<asac> right
<kyrofa> asac, trunk is ahead of the latest in the PPA?
<asac> not sure .)
<asac> i am always using trunk directly. updated bug with what i remembered
<asac> lets see what folks say
<asac> kyrofa: are u using daily build ppa?
<asac> e.g https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily ?
<kyrofa> asac, yes
<asac> i am on 130
<asac> ppa seems to be on 129, but i had this experience yesterday so i assume used 129
<asac> *shrug*
<asac> thanks!
<kyrofa> asac, hmm, alright. No problem!
<asac> kyrofa: https://pastebin.canonical.com/137108/
<asac> and yes i am on 129 :) ... found out that 130 is my own local commit
<kyrofa> asac, huh....
<kyrofa> asac, I just purged devscripts as well, and now exactly what happened to you happened to me
<kyrofa> asac, does apt leave something behind that helps snapcraft here?
<lool> rajen: hey there
<rajen> Hi there
<rajen> Hi Loic
<sergiusens> ogra_: https://code.launchpad.net/~sergiusens/snapcraft/dget/+merge/267411
<kyrofa> sergiusens, hey daddy. Congratulations :)
<sergiusens> kyrofa: lol, thanks
<kyrofa> sergiusens, hey dude, get in line! https://code.launchpad.net/~kyrofa/snapcraft/add_devscripts_to_depends/+merge/267402
<kyrofa> :P
<kyrofa> sergiusens, although asac had some interesting things to say about that ^^
<sergiusens> kyrofa: oh look at that, it is as if you found this minutes ago :-P
<kyrofa> sergiusens, hahaha
<kyrofa> sergiusens, although notice if you now purge devscripts, snapcraft will prompt you to install it
<kyrofa> sergiusens, so something weird is happening. I'm setting up an lxc real quick to test on a clean system again
<kyrofa> sergiusens, asac huh... worked fine in lxc. I have no idea why it sometimes doesn't work
<sergiusens> kyrofa: about requiring devscripts?
<kyrofa> sergiusens, yeah
<sergiusens> kyrofa: I guess the use of dget is not the right thing here
<kyrofa> sergiusens, sometimes it just offers to pull it in for you, but sometimes it breaks trying to just exec dget
<sergiusens> kyrofa: it should use the python api for apt more and get links to the actual deb
<kyrofa> sergiusens, ah, yeah that would be better
<sergiusens> kyrofa: in the end, dget is just a perl script
<sergiusens> ted: how are you running the vm to test your photoviewer app?
<ted> sergiusens, With libvirt in vm-manager
<sergiusens> ted: and mir just works? I'm getting connection issues
<ted> sergiusens, Are you using QXL and Spice?
<sergiusens> ted: qxl, what is spice?
<ted> sergiusens, Like VNC
<ted> It shouldn't matter, as long as QXL.
<sergiusens> ted: let me see if using virt-manager toggles some extra options I'm missing
<sergiusens> need to logout for a bit
<sergiusens> ted: are you running on rolling or 15.04?
<ted> sergiusens, I believe 15.04, let me check.
<sergiusens> ted: and where did you get mir from? Manual download from the store?
<ted> sergiusens, Yes, just snappy install mir
<sergiusens> ted: 'snappy install mir' does not work :-P it doesn't have an alias
<sergiusens> ted: works in virt manager btw, not sure why it doesn't with my magic kvm cli
<sergiusens> ted: thanks for the fish ;-)
<ted> How do I find what channel I'm on?
<sergiusens> ted: snappy info
<ted> Ah, yeah. 15.04
#snappy 2015-08-09
<pindonga> hi, I'm creating a snappy pkg, and I have almost everything working, but I still got 2 questions
<pindonga> 1. how can I make it so a config file is placed in the right location when the pkg is installed ? whatever I put into the source folders gets written to /apps/<pkg>.sideload/<version>/ but when running snappy config it expects the file in /var/lib/apps/<pkg>.sideload/<version>/
<pindonga> 2. is there an easy way to get the config also exposed via the webdm ui, so that users can edit it from the webui?
<pindonga> 3. the pkg provides a service, but the service will not start properly unless some hardware has been plugged in (a printer in this case)
<pindonga> is there a way to restart the service via the webui? or maybe I need to add some dbus rules so it restarts when the device is plugged?
#snappy 2016-08-08
<menn0> I have a question about developer namespaces. can anyone help?
<ahoneybun> sergiusens: could you share your snapcraft.yaml or update the telegram one?
<dholbach> hey hey
<didrocks> good morning dholbach
<dholbach> salut didrocks
<zyga> good morning everyone :)
<zyga> I officially give up on reading backlog for the last three weeks
<dholbach> zyga, break with the past! move on to new things! ;-)
<zyga> dholbach: speaking of which, https://bodhi.fedoraproject.org/updates/FEDORA-2016-0137e29c1e
<zyga> https://bodhi.fedoraproject.org/updates/FEDORA-2016-0233975de8
<dholbach> very nice :)
<zyga> Son_Goku: hey, I cannot send bodhi request for f25 for golang-github-mvo5-goconfigparser -- I keep getting http://pastebin.ubuntu.com/22671527/
<morphis> ogra_: ping
<morphis> zyga: welcome back!
<zyga> morphis: hey
<zyga> morphis: I saw you made a branch for udev fix, I also made one two weeks ago
<zyga> morphis: did your version land?
<morphis> zyga: hope you enjoiyed your time off
<morphis> zyga: not yet, waiting for next review round
<zyga> morphis: yes, I really needed that :-)
<zyga> morphis: ok, great, I'll review it today if I can; I have a huge backlog of things to do
<morphis> zyga: thanks, niemeyer is looking at it too
<morphis> zyga: one other thing, you remember that we talked about loading kernel modules with interfaces once connected?
<zyga> morphis: yes, I do, some people asked about that in Leiden AFAIR
<morphis> zyga: yeah there is a kernel-load PR now, but this is more for the ppp interface where we don't want to give the plug side the ability to load modules but do that from snapd directly
<morphis> zyga: wanted to check with you how we implement that the right way
<zyga> morphis: I see, I think we need both types, free-form loading from within the app process and snapd-directed loading
<morphis> zyga: yes
<zyga> morphis: I'll make sure to review that one
<zyga> ara: hey, long time no see :)
<ara> zyga, hey, how were the holidays?
<zyga> ara: busy :) I'm looking forward to having some peace and quiet work time :)
<ara> zyga, hehe
<morphis> ara: morning!
<ara> hey morphis :)
<morphis> zyga: you have an idea in mind how to implemnt the snapd-directed loading?
<morphis> zyga: we could add another security system or extend the interface API to return something like PermanentSlotKernelModules
<zyga> morphis: yes, I talked to jdstrand about it; there are two parts; one that drops a line/file in /etc/modules-load.d for load on boot and another one that just modprobes the thing
<morphis> yeah
<zyga> morphis: I think using another security system is easier
<zyga> morphis: the only thing we were worried about is options
<zyga> morphis: but that all
<morphis> yeah options might be tricky, but as we're doing specific modules here we may have to encode such a thing as attribute
<morphis> not free-form but something we translate
<zyga> morphis: jdstrand was worried that some options might be too powerful for an unrestricted interface
<zyga> morphis: anyway, I think we can solve it on a case-by-case basis
<morphis> yes
<morphis> zyga: for now we have some well-defined use cases
<morphis> ogra_: ping
<ysionneau> hi!
<didrocks> hey ysionneau
<ysionneau> about my friday question, someone said "SNAP_COMMON could be your solution" but I don't get how it can help me to make 2 different *snaps* communicate through unix socket
<ysionneau> I thought I had a solution by having autopilot (which is devmode snap) create the unix socket in the SNAP_DATA of facedetect (which is a contained snap)
<ysionneau> but since autopilot is already running when facedetect is not yet installed, it does not work
<ysionneau> the PATH does not exist yet and the socket creation fails
<didrocks> ysionneau: lool mentioned SNAP_COMMON as, contrary to SNAP_DATA, it's a fixed path for whatever version of facedetect is running
<didrocks> but yeah, what you told is an issue if autopilot is already running before facedetect is installed
<zyga> ysionneau: you need an interface for that
<zyga> ysionneau: you can only communicate over tcp/ip without an interface
<ysionneau> didrocks: ah ok goot to know, anyway I was using /current/
<ysionneau> zyga: :(
<ysionneau> I guess I'll end up recompiling snapd to add my interface and stuff it into ubuntu-core
<ysionneau> I however have no idea on how to recompile snapd =)
<zyga> ysionneau: look at two links: https://github.com/zyga/devtools/ and at snapd docs (how to build)
<zyga> https://github.com/snapcore/snapd/blob/master/README.md
<ysionneau> thanks!
<zyga> ysionneau: just a side note: ubuntu-image sccript in devtools is broken
<ysionneau> ok thanks
<ysionneau> I'm not using ubuntu-image from internet anymore
<ysionneau> I had too many issues with updates
<ysionneau> I commited one version that works in my repository
<zyga> ysionneau: that won't work with recent snapd
<zyga> ysionneau: on the upside ubu tu image official upstream is close to making first releases
<ysionneau> zyga: "ubu tu image", that's the real name ? :D
<ysionneau> 10:59 < zyga> ysionneau: that won't work with recent snapd < hmmm strange, I'm using an old ubuntu-image and a recent ubuntu-core :o
<ysionneau> and it seems to work :o
<ogra_> morphis, hey
<zyga> ysionneau: it might break at any time
<morphis> ogra_: just a quick check, your all-snap pi3 image doesn't support the onboard wifi yet, right?
<ogra_> yeah, missing the firmware
<ogra_> i'll get to that once i have https://code.launchpad.net/~ogra/+snap/kernel-test-snap fully working (EOW i think)
<ysionneau> zyga: when it will break, just updating my ubuntu-image will fix the issue?
<zyga> ysionneau: you may need to remake the image
<morphis> ogra_: any chance I can get the firmware manually in?
<ysionneau> zyga: no problem, I remake the image each time I flash
<ogra_> morphis, you can unsquashfs the kernel snap, add the filesw and run snapcraft snap squashfs-root
<ogra_> then use the local kernel in u-d-f
<morphis> yeah good idea
<ysionneau> is this the official webdm repository (up to date?) ? : https://code.launchpad.net/~snappy-dev/snappy-hub/webdm
<morphis> ysionneau: https://github.com/snapcore/snapweb is getting the new one
<ysionneau> morphis: is this the current "webdm" package ? The one I can fetch by doing "sudo snap install webdm" ?
<morphis> ysionneau: not sure, all I know is that webdm gets replaced by snap-web
<zyga> ysionneau: I think the snap should be renamed to snapweb as well
<zyga> but yes, that's the old webdm
<ysionneau> hmm there is no "snapweb" snap in the store
<ysionneau> but there is "webdm"
<ysionneau> so far webdm works for me so I would like to use it, is it https://code.launchpad.net/~snappy-dev/snappy-hub/webdm ?
<zyga> ysionneau: unlikely, try github.com/snapcore/snapweb perhaps
<ysionneau> thanks
<ysionneau> zyga: AH ok, it's the correct repository but webdm package got renamed to snapweb
<ysionneau> https://github.com/snapcore/snapweb/commit/978fc76a95199aecb1ae735fe3c4459068eb9318
<ysionneau> right?
<zyga> yes
 * ysionneau thinking about what's easier between adding an interface to snapd, recompile, repack ubuntu-core. or modify snapweb to always install everything in devmode, recompile and repackage snapweb
<ysionneau> one is the "clean way", the other might be easier
<zyga> ysionneau: try my devtools
<zyga> ysionneau: you can just compile and run fresh version directly
<zyga> ysionneau: no rebuilding of any snaps required
<zyga> ysionneau: see the docs there
<zyga> ysionneau: that's *the* purpose of devtools, rapid interface development
<ysionneau> zyga: I kind of get used to that :p
<ysionneau> ah sorry was replying to something else
<ysionneau> so, I recompile snapd and I push it via  refresh-bits ?
<zyga> ysionneau: refresh bits does all, just see what it does
<ysionneau> k!
<zyga> ysionneau: refresh-bits setup snap snapd run-snapd restore
<zyga> ysionneau: with --host if needed
<zyga> ysionneau: read the source, it's very easy to follow
<zyga> ysionneau: note that run-snapd blocks, ctrl-c it to continue
<ogra_> cjwatson, bug 1610916 for you ...
<mup> Bug #1610916: s390x snap builds on launchpad fail with no build log <launchpad-buildd:New> <https://launchpad.net/bugs/1610916>
<cjwatson> Thanks.
<pmp> zyga: on debian-testing there is no systemd-activate - needed by refresh-bits
<lool> didrocks: heya
<lool> ysionneau: and hi
<didrocks> hey lool
<zyga> pmp: I heard, any chance on how to trigger socket activation now?
<zyga> s/chance/advice/
<pmp> zyga: I don't know much about systemd... sry
<pmp> zyga: Plus I'm cross-compiling (well I try to)
<zyga> pmp, no worries, thanks for letting me know
<kaisoz> Hi there!
<cjwatson> ogra_: Can you try an s390x build again?
<cjwatson> ogra_: Firewall should be fixed, though there's still the exception-handling bug
<ogra_> cjwatson, triggered
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/2574
<ogra_> that looks better
<cjwatson> You haven't hit the previous failure yet
<ogra_> ah, i thought the build didnt even start the last time
<cjwatson> Oh, maybe
<cjwatson> No, I think it started, but it crashed in such a way as to leave no log
<cjwatson> So you wouldn't know unless you happened to be watching it
<ogra_> ah, k
<cpaelzer> just to check - anybody else working on a waf plugin (https://github.com/waf-project/waf) ?
<cpaelzer> I need that to try ntpsec, but wanted to avoid too much collisisons so I thought I poll for others that might work on it
<ogra_> cjwatson, ... so while this runs, i have another issue ... when i select Proposed from the LP UI and have picked a PPA as the archive,  proposed isnt actually used unless the PPA is also enabled for proposed ... i.e. i can not get snapcraft from proposed for testing for example even though i pick it ... the UI option should set proposed regardless of the picked archive imho
<ogra_> (in the case of my ubuntu-core builds, i can not actually get livecd-rootfs from proposed since the outer sources.list doesnt contain it unless the image PPA defaults to it too)
<ogra_> cjwatson, build is done, i got a buildlog link \o/
<ogra_> hmm, but i get a "404 client error" from the store ... i wonder why
<ogra_> clicking the upload button manually uploads it fine ... strange
<ogra_> geez ...
<ogra_> Launchpad uploaded this snap package to the store, but the store failed to
<ogra_> scan it:
<ogra_>   A file with this exact same content has already been uploaded
<ogra_> why did it tell me about the 404 error then ... :P
<cjwatson> ogra_: proposed> please file a bug; I think I probably agree but doing anything about that will be a bit complicated
<ogra_> cjwatson, will do
<cjwatson> [2016-08-08 11:11:45,875: DEBUG/Worker-1] "POST /dev/api/snap-push/ HTTP/1.1" 202 None
<ogra_> hmm, the above looks like a race in the store ... LP obviously uploaded it fine but the scanner tried to scan it to early or some such
<cjwatson> [2016-08-08 11:11:45,988: DEBUG/Worker-1] "GET /dev/api/snaps/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7/builds/5ee23940-f5f8-49bb-9ab1-ec7b0bf4315d/status HTTP/1.1" 404 None
<cjwatson> I think this must be an SCA bug.  It should not be possible for it to return a status URL from snap-push that can't be immediately fetched.
<ogra_> yeah
<cjwatson> I don't know about the "exact same content" thing.
<ogra_> cjwatson, well, that was mme manually clicking the "upload" button on LP ... my fault
<ogra_> i think i actually saw a bug fly by about the 404 error ...
<cjwatson> Ah, right, because the 404 meant we thought it was retryable even though it actually wasn't.
 * ogra_ digs his bugmail
<cjwatson> Unfortunate.
<ogra_> yeah
<dz0ny> cpaelzer: https://github.com/ubuntu/snappy-playpen/blob/master/mpv/parts/plugins/x-waf.py but it's very optiniated
<ogra_> looks like bug 1572963
<mup> Bug #1572963: snapcraft upload can fail while monitoring scan status <verification-done> <Snapcraft:Fix Released by vila> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1572963>
<ogra_> hmm, or probably not ... but related at least
<ogra_> ah, because the original description was changed ... https://bugs.launchpad.net/snapcraft/+bug/1572963/comments/0 pretty much describes what i see
<mup> Bug #1572963: snapcraft upload can fail while monitoring scan status <verification-done> <Snapcraft:Fix Released by vila> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1572963>
<ogra_> sergiusens, not sure if bug 1610948 is for you or the store people
<mup> Bug #1610948: automated snap uploads from launchpad often cause pointless 404 errors <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1610948>
<ogra_> (i assigned to to SCA and snapcraft for now)
<ogra_> sigh ...
<ogra_> the arm builders are really busy since last week ...
<cpaelzer> dz0ny: thanks for the link - I'm gonna take alook and maybe once I'm happy with the one I'm working on we can prep a PR for snapcraft
<pmp> zyga: I issued a pull-request for devtools, not sure if it is ok for all platforms - please review
<pmp> zyga: I could cross-compile snapd with these changes on debian testing.
<pmp> zyga: at least that what I think I did ;-)
<Son_Goku> zyga, f25 hasn't been bodhi activated yet
<Son_Goku> branching and the bodhi activation point are two different times
<Son_Goku> zyga: https://fedoraproject.org/wiki/Releases/25/Schedule
<Son_Goku> Bodhi activation is tomorrow
<Son_Goku> if everything makes it in today, we don't have to worry about bodhi for f25
<mup> PR snapd#1648 opened: overlord,store: set store device authorization header <Created by matiasb> <https://github.com/snapcore/snapd/pull/1648>
<zyga> pmp: thanks, will do
<zyga> Son_Goku: yep, I learned about that since asking :)
<zyga> Son_Goku: I had a look at gettext but I was busy writing a blog post about snap-confine
<zyga> Son_Goku: I cannot see anything wrong but I didn't check all of my email yet
<kaisoz> Hi again
<Son_Goku> zyga, the issue with gettext is that there's a file that says it imports go-flags
<Son_Goku> but for whatever reason, it's not a dependency in gettext
<Son_Goku> zyga, the go-xgettext code uses it
<Son_Goku> actually, now I realize the thing
<Son_Goku> go-xgettext is an example program, isn't it?
<ogra_> jdstrand, are you around today ?
<sergiusens> ogra_ the uploads from launchpad are driven by launchpad using the store api and not involving snapcraft at all
<sergiusens> I'll make a note on the bug
<ogra_> sergiusens, thanks, feel free to invalidate it then
<ogra_> (teh snapcraft task)
<Son_Goku> zyga, actually, it looks like you need to add go-flags as a BR at least because it's used during the %check section
<morphis> ogra_: you know directly which firmware files are missing?
<zyga> Son_Goku: look now
<ogra_> morphis, not from the top of my head ... i think ppisati already packaged it though ... in his embedded ppa
<zyga> Son_Goku: go-xgettext is a real xgettext replacement for golang sources
<zyga> Son_Goku: it's a tool though you don't have to use it
<Son_Goku> ah
<zyga> Son_Goku: the advantage over *gettext is that it parsers go code with go itself
<morphis> ogra_: I see, thanks
<zyga> Son_Goku: so it is more reliable
<Son_Goku> does it conflict with system gettext?
<Son_Goku> if not, why not slightly adjust the package so that it builds it and makes it available?
<Son_Goku> people might want to use it
<zyga> Son_Goku: no, the binary is separate
<zyga> Son_Goku: hmm, didn't I do exactly that? (me checks)
<Son_Goku> nope
<Son_Goku> you don't
<zyga> I probably did that in suse
<Son_Goku> yeah, probably
<zyga> sorry, I'll copy that change
<Son_Goku> okay, cool
<Son_Goku> be sure to update the bug with a comment indicating new changes, link the new srpm, and link to spec
<zyga> yep, I'll do exactly
<zyga> that
<Son_Goku> once you've done that, I can approve the package and you can push it
<Son_Goku> after I take a look at it, of course :P
<zyga> yep, just looking at the suse version of the package to compare
<zyga> gofed makes it a bit noisy
<Son_Goku> gofed was designed to automate packaging and updating golang libraries
<Son_Goku> as very early on, it looked like golang was going to turn into the same mess nodejs is with npm
<Son_Goku> it doesn't mean you get to switch your brain off entirely, as there are definitely certain aspects you should probably handle yourself if the package is slightly unusual
<Son_Goku> but it does make the process simpler
<morphis> ogra_: also it looks like the pi3 doesn't get an IP address on subsequent boots
<ogra_> morphis, do you see an entry for the NIC in /etc/network/interfaces.d ?
<morphis> need to pull the sdcard, sec
<ogra_> iirc there is still an issue with the firstboot job that doesnt always create the setup
<morphis> I see the greenlight continously blinking
<ogra_> well, what do you see on the serial console ? :)
<morphis> don't have one connected
<morphis> :-)
<morphis> but there is a e/n/i.d file
<ogra_> then it shold also get the NIC up
<morphis> yes
<morphis> ogra_: we're using predictable network iface names now?
<ogra_> are you sure it is the NIC itself or just i.e. ssh
<ogra_> we set net.ifnames=0 on the kernel cmdline ...
<ogra_> which should prevent "predictable" names
<morphis> I get enxb827eb0c621b as eth name
<morphis> ogra_: no, its the NIC
<ogra_> then i guess there iis a bug with the net.ifnames=0 recognition somewhere
<morphis> otherwise nmap would find the host as up
<ogra_> (which i fear needs pitti input ... who is on vac.)
<morphis> :-)
<ogra_> for the moment you can mv the eth0 file to the right name
<ogra_> that should get you up and running
<zyga> the user experience of fedpkg vs using rpm* directly is staggering
<zyga> most of the stuff that is annoying is fixed by fedpkg
<ogra_> hmm ... so i wonder if https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2575 will actually work now
<zyga> but you cannot use it before you get the database updated :)
<cpaelzer> I might have totally missed if something like it is already available, but if a snap provides man pages "in" the snap - is (?could?) there be some auto-registration into man - so that man yousnap.command auto-maps and opens the matching snap manpage?
<kalikiana> There's a bug for that
<ogra_> that will also onlly work on classic installs ...
<kalikiana> Specifically bug 1575593
<mup> Bug #1575593: Snappy installed manpages aren't accessible through man <Snappy:New> <ubuntu-snappy (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575593>
<kalikiana> ogra_: Why? Is there a known plan to implement it?
<ogra_> (all-snap imges do not have man installed at all ... nor does the ubuntu-core snap itself ... on purpose)
<cpaelzer> thanks kalikiana and ogra_
<ogra_> kalikiana, no idea, if there is any plan ... but it would need to happen by using the hosts "man" on classic and would need to detect if it is running on classic or an actual snappy image
<Son_Goku> zyga, the only thing I use rpmbuild for is making the SRPM
<Son_Goku> everything else is done with mock or fedpkg
<kalikiana> Using the host makes no sense... you want the man pages of the binaries you actually run, regardless of whether they're in the core snap or any other snap.
<ogra_> kalikiana, well, you need the manpages in the man db and you need a man/groff binary
<ogra_> neither is available in ubuntu-core
<ogra_> and we will definitely not add it
<ogra_> (since the ubuntu-core snap is still megabytes to big)
<kalikiana> ogra_: Can't all of that go to a man snap?
<ogra_> that could work, but then you only have man support if you have the man snap installled ...
<ogra_> and you get into trouble with mandb still ... since yu need to auto-update it for every snap
<ogra_> that requires some interaction between snaps that we dont have today
<ogra_> not saying it is impossible, but the interface you would need would be pretty complex
<kalikiana> The obvious alternative would be a server - I use a script to do that today to read manpages of packages I don't have installed. But it only works for packages in the archive, so snaps wouldn't work.
<kalikiana> Unless the store would extract man pages.
<camako> trying to run 'snapcraft cleanbuild' on my snap, but I'm getting "500  Internal Server Error"... here's the log ---> http://pastebin.ubuntu.com/22691796 my lxd otherwise appears sane
<camako> any idea what might be the problem?
<kalikiana> Thinking about it, maybe I should snap that script
<ogra_> +1
<ogra_> :)
<cpaelzer> ogra_: kalikiana: thanks for the discussion - I subscribed to the bug and will think about it a bit as well
<cpaelzer> ogra_: kalikiana: eventually /etc/manpath.config already has a path mapper, maybe we just have to find a way to append for installed snaps so the hosts mandb updates will pick it up
<ogra_> cpaelzer, well, that would break confinement ... you dont really want to blindly pull in manpages that could ppotentially be malicious binaries instead of manpages ...
<arges> jdstrand: hi
<cpaelzer> ogra_: sad but true, thanks for keeping the confinement thought up
<ogra_> you actually need an interface i think
<jdstrand> arges: hey
<jdstrand> ogra_: yes
<arges> jdstrand: https://github.com/snapcore/snapd/pull/1602#issuecomment-237949753 working on this PR. Even with apparmor rules allowing /proc/version_signature I can't seem to open the file... are there other permissions I need to worry about?
<mup> PR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602>
<ogra_> jdstrand, awesome ... so we have auto-builds for ubuntu-core in place now ... together with auto-uploads ... the one remaining prob for me is that "type: os" now blocks the auto-accepting, could we do wsome special casing in the review tools ?
<jdstrand> arges: no. what are the permissions of the file from within the snap?
<arges> jdstrand: is there a simple way to check this.. i know there was a wrapper script at some point?
<jdstrand> ogra_: yes. can you give me a list of snap names that should be auto-approved?
<ogra_> oh, and one other thing, when i build with snapcraft ... which i now do for kernel and os, the review tools complain about confinemment (obviously a snapcraft bug that it secretly adds it) ... could we also ignore that ?
<ogra_> ("confinement: strinct" i mean)
<ogra_> jdstrand, for now only ubuntu-core ... by EOW i can give you names for the kernel snaps
<ogra_> jdstrand, https://myapps.developer.ubuntu.com/dev/click-apps/4142/
<jdstrand> ogra_: ack, I'll take a look and handle all that
<ogra_> thanks !
<ogra_> :)
<jdstrand> arges: what I personall would do is create a 'sh' command in 'apps'. just copy the one from hello-world, adjust your yaml to copy it into place and expose it in 'apps' with whatever 'plugs' you need. then your-snap.sh and do whatever
<jdstrand> arges: that's a handy method for testing. you can drive your other commands within confinement and iterate a bit easier
<arges> jdstrand: ok i've done it that way before... I remember there was a snap shell command, but didn't know if there was a better way todo it
<jdstrand> there's another way that I know people have talked about. snap try or snap shell I think-- I don't know if those are implemented
<arges> jdstrand: ack i'll poke around and see what i can find. thanks
<jdstrand> arges: I'm not 100% sure that is an exact runtime environment with try or shell
<didrocks> jdstrand: so, imagine I have an unix socket to communicate between a cli (running as a user) and a service (running so as root), any advice/idea where to put it to get both communicating?
<didrocks> I can use SNAP_COMMON + make it +w for everyone, but other opinions would be welcomed
<didrocks> (both ends are from the snap)
<zyga> didrocks: I'd use /run
<zyga> didrocks: one sec, let me check the template
<mhall119> didrocks: dholbach: do we have a snapcraft plugin for ant?
<didrocks> zyga: ah, they are common between apps from the same snaps?
<didrocks> mhall119: there is on built-in, yeah
<didrocks> mhall119: btw, snapcraft list-plugins :)
<zyga> didrocks: yes though run may not be what you want
<zyga> didrocks: also I should hit a publish button
<mhall119> didrocks: nice, thanks!
<didrocks> zyga: ;) well, we do use /run for this kind of socket communication on traditional desktop
<didrocks> mhall119: yw!
<zyga> didrocks: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<zyga> fresh off my todo list
<zyga> now let me check that run for you
<didrocks> thanks! I think there is a pattern like /run/snap.<snapname> something in the apparmor profile
 * didrocks reads the new blog post
<mhall119> sergiusens: when will snapcraft let me set envvars for a snap? That's blocking a few that are otherwise upstreamable
<zyga> didrocks: it's not in the default template
<zyga> didrocks: that's something we should consider improving
<didrocks> zyga: oh? indeed, sounds like it should be there
<zyga> mhall119: when new snapd allows this, it's almost complete on this side
<zyga> didrocks: I agree, I'll talk to jdstrand about this
<mhall119> zyga: oh, I thought it was just going to inject them into the generated wrapper
<zyga> mhall119: I think that this falls under 'sensible defaults' as long as it doesn't allow IPC
<zyga> mhall119: (across the snap boundary)
<zyga> mhall119: similar to how we allow /dev/shm/...   /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,
<zyga> mhall119: for cross snap IPC you always need an interface
<didrocks> yep!
<mhall119> uh, I just was to set SQLITE_TMPDIR=/tmp
<arges> jdstrand: ok... so I want my bash to have the same permissions as what 'daemon: simple' gives a program to see what it sees..
<didrocks> mhall119: I guess zyga was talking to me :)
<mhall119> I hope so :)
 * zyga needs to get his blog federated on planet arch linux
<arges> jdstrand: any suggestions for making this work with snap/snapcraft?
<zyga> arges: it is just a systemd unit that runs your snap as root, with HOME set to /root and pretty much no change to how snaps otherwise execute
<arges> zyga: i'm trying to debug a daemon, and jdstrand suggested trying things as bash. So I'm trying to debug from the daemon perspective
<arges> adding 'bash -u root' to the command doesn't work, so trying to figure it out
<jdstrand> arges: use the same plugs and execute 'sh' under sudo
<jdstrand> arges: a few env variables aren't going to be the same but that should be good enough
<arges> jdstrand: so 'sudo su' in the snap bash shell doesn't work, so I'm guessing you mean change the command in the snapcraft.yaml to 'sudo su' ?
<jdstrand> didrocks, zyga: /run/shm/snap.$SNAP_NAME.** is in the default template and can be used for cross-app communications, but not cross-snap communications
<didrocks> excellent, exactly what I wanted!
<jdstrand> arges: sudo /snap/bin/your-thing.sh
<didrocks> thanks jdstrand
<arges> jdstrand: ok. using that i am able to read /proc/version_signature  ... hmm
<jdstrand> arges: check that the resulting security policy is sufficiently the same: diff -Naur /var/lib/snapd/profiles/snap.your-thing.daemon /var/lib/snapd/profiles/snap.your-thing.sh (and do the same for seccomp)
<jdstrand> arges: if they are, then you might look at systemd to see if it is doing anything weird with /proc that it maybe shouldn't be
<jdstrand> arges: or maybe there is a bug in your code... (hard to say, but the fact that 'sh' can access it suggests it is something outside of the sandbox that is causing the problem)
<arges> jdstrand: well it works running without snappy fwiw
<arges> i'll check the above
<cpaelzer> zyga: thanks for that blog series btw - really providing some extra insights once through the usual entry docs
<arges> jdstrand: no diff except for profile name.
<zyga> cpaelzer: my pleasure, feel free to send me suggestions
<zyga> jdstrand: hey, long time no see, how are you doing
<zyga> jdstrand: I didn't notice the /run/shm part, just /dev/shm, is there any reason or plan for long term standarization of that? should we offer /run/snap.$SNAP_NAME.* ?
<mup> PR snapcraft#713 opened: rust plugin: mock downloads in unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/713>
<jdstrand> zyga: we do offer /run/snap.$SNAP_NAME.**. look at template.go
<jdstrand> zyga: oh sorry, I thought you meant /run/shm
<jdstrand> zyga: there is no reason we couldn't offer /run/snap.$SNAP_NAME.** technically-- it is clean from an application isolation pov, but /run is typically for well-known locations like mir, lxd, docker, etc and they won't want to conform to snap.$SNAP_NAME
<ogra_> GRRR
<jdstrand> so I suspect it won't really help anything, but if it makes things easier, I'm fine with it
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/
<ogra_> unset
<ogra_> why does u-d-f not like me !
<ogra_> *sniff*
<zyga> jdstrand: I did check template.go, I just missed it among the {/dev,} variants
<jdstrand> arges: ok, then I suspect systemd is doing something. why or what, I don't know (but that is really the only thing that is different)
<jdstrand> zyga: well, it doesn't help that /run/shm/$SNAP_NAME.** and /run/snap.$SNAP_NAME.* look pretty similar when reading quickly :)
<zyga> jdstrand: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html :)
<jdstrand> zyga: so, /run/shm/$SNAP_NAME.** is allowed now, /run/snap.$SNAP_NAME.* is not. if want /run/snap.$SNAP_NAME.*, that is easy, but see above
<jdstrand> zyga: nice! /me reads
<zyga> yes, I wonder about this myself, some of the apps would probably happily switch to /var/snap.$SNAP_NAME
<zyga> but perhaps not all and this is a tricky subject
<jdstrand> maybe
<jdstrand> I mean, we can allow it
<zyga> I'd perhaps offer /run/$SNAP_NAME.* directly
<jdstrand> it's fine from an application isolation perspective
<zyga> because snap names are something that can be managed separately
<jdstrand> no
<zyga> no?
<jdstrand> that is not fine
<jdstrand> need snap.
<jdstrand> or an interface
<sergiusens> mhall119 as soon as I can get to it; probably 2.15
<zyga> what's the difference betwen /run/$SNAP_NAME and /run/snap.$SNAP_NAME?
<jdstrand> cause people will create an 'acpid' snap and be allowed to create /run/acpid.socket and wreack havoc
<jdstrand> wreak
<zyga> acpid should be reserved for other reasons
<jdstrand> it's all the same arguments for why we have snap. prefixed everywhere already
<zyga> and if and when it is a genuine snap, why wouldn't it be ok to access?
<jdstrand> ntpd? docker? lxd? ekeyd? etc etc
<zyga> yes
<zyga> docker, for sure!
<zyga> think about it
<jdstrand> snap.$SNAP_NAME is ok by default. $SNAP_NAME needs an interface
<zyga> if you own docker name, docker executable name, etc
<zyga> well, /run won't be available to anyone outside of the snap
<ogra_> that makes you non-evil ?
<zyga> I totally agree about cross-snap IPC
<jdstrand> why?
<jdstrand> we are mounting /run separate too?
<jdstrand> that is going to be really complicated for cross-snap stuff
<zyga> jdstrand: because $various_projects use /run/$SNAP_NAME already
<zyga> ah, I see
<zyga> I was just curious
<jdstrand> I think we should avoid bind mounts except where absolutely necessary and stay in the global namespace
<mup> PR snapcraft#713 closed: rust plugin: mock downloads in unit tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/713>
<jdstrand> we are already seeing lots of complications with what we are doing and they are only going to get more complicated
<jdstrand> cause then there is ordering, uninstalls are problematic, etc, etc
<zyga> jdstrand: I don't think we'll get many more non-interface-specific bind mounts
<jdstrand> ok
<jdstrand> I think it is worth taking a moment to think about why apps are creating sockets and stuff in /run-- it is for IPC. inter-snap IPC is supposed to be governed by interfaces (a design goal). inter-app communication within a snap we can do whatever makes sense
<jdstrand> so, if you want to add /run/snap.$SNAP_NAME.** today, I'm ok with that. but /run/$SNAP_NAME.** I think we'd need to have a conversation about with nie meyer so we are all on the same page
<zyga> jdstrand: agreed
 * zyga -> break
<jdstrand> zyga: reading your article, I didn't see you reference scmp_sys_resolver (and that it must be run on the same arch as the snap). or hint towards using snappy-debug.security scanlog (we should rename that since it seems clear nothing else is going to end up in snappy-debug)
<zyga> jdstrand: I did mention snappy-debug but not any details
<jdstrand> ah, I see that now
<zyga> jdstrand: I decided not to mention scmp_sys_resolver because it is geeky and doesn't win much
<jdstrand> I didn't get that far yet
<zyga> jdstrand: :-)
<zyga> jdstrand: I'll probably upload syscall snap to the store that resolves syscall numbers across architectures
<jdstrand> zyga: note, apparmor cannot check system call arguments
<jdstrand> zyga: that is for seccomp (and not necessarily for the article, only integers, not structs, etc)
<zyga> jdstrand: ah, so the fact that you can open /foo is implemented as LSM check in the VFS, not on open itself?
<jdstrand> zyga: correct
<cpaelzer> a daemon: forking snap should automatically get some sort of generated systemd service that one can check right?
<zyga> jdstrand: I know about the seccomp not reading userspace memory
 * cpaelzer searches the hiding systemd unit
<ogra_> cpaelzer, yeah, snapd creates it at install time ... it gets prefixed with snap.*
<zyga> jdstrand: I really wonder how apple's sandboxd works now
<zyga> jdstrand: anyway, noted, thank you for being precise
<jdstrand> there are a ton of LSM hooks that give access to the thing being mediated. seccomp isn't consulted at the same points so doesn't have the ability to look at the filename of 'open', for example
<ogra_> (as long as you defined it in your "app:" entry in snapcraft.yaml)
<cpaelzer> ogra_: it is in the app entry I'd have expected snap.ntpd for this http://paste.ubuntu.com/22698736/
<jdstrand> zyga: I suggest s/ulted at the same points so doesn't
<jdstrand> zyga: strike that-- bad paste
<ogra_> cpaelzer, try: snap-ntpsec.ntpd.service
<ogra_> or some such
<jdstrand> zyga: I suggest: s/system call arguments/traditional UNIX IPC like signals and sockets,/
<jdstrand> zyga: 2 cents
<ogra_> cpaelzer, systemctl | grep ntp
<ogra_> ;)
<cpaelzer> obviously :-) thanks why didn't I just search that way :-)
<cpaelzer> thanks
<ogra_> oh, actually snap.ntpsec.ntpd.service
<cpaelzer> snap.ntpsec.ntpd.service
<cpaelzer> ack
<ogra_> (sorry, typoed that)
<zyga> jdstrand: updated :)
 * zyga -> really ADFK
<mup> PR snapd#1634 closed: store: add device nonce API support <Reviewed> <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1634>
<mup> PR snapd#1648 closed: overlord,store: set store device authorization header <Reviewed> <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1648>
<mup> PR snapd#1493 closed: store/auth: add SnapUbuntuStoreAuthService with device identity methods <Created by wgrant> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1493>
<mup> PR snapd#1528 closed: overlord/devstate: add DeviceManager which checks assertions <Created by wgrant> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1528>
<jdstrand> niemeyer: hi! fyi, https://github.com/snapcore/snapd/pull/1409#issuecomment-238269429
<mup> PR snapd#1409: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1409>
<jdstrand> niemeyer: basically an integration test is failing that is unrelated to the PR
<jdstrand> niemeyer: also as fyi, I got the PR pings for other stuff and will take a look a bit later
<john-mcaleely> ogra_, how long do you expect it to take for an rpi3 to boot all-snaps image? it seems to be aaaageeess
<qengho> 10 minutes?
<ogra_> john-mcaleely, around 1-2 mins for the first boot
<ogra_> subsequent ones take aless
<ogra_> *less
<john-mcaleely> hmm, more like 15 so far. green led blinking. raspberries just disappeared
<john-mcaleely> will let you know if it completes
<john-mcaleely> I assume I get a login prompt?
<ogra_> note that it only boots to serial console
<cpaelzer> since there is no "snap config" https://developer.ubuntu.com/en/snappy/guides/config/ feels outdated. If I need to provide a /ect/something.conf to a snap app that is somewhat user controllable what is the best current doc or example to start with?
<john-mcaleely> ogra_, which appears where? (I am stupid!)
<ogra_> on your attached serial cable indeed :)
<ogra_> it should eventually also pop up a login prompt on the screen though
<john-mcaleely> ogra_, ah. I need to google how to get such a thing :-)
<ogra_> (ubnless systemd doesnt spawn consoles if you dont set console=tty1)
<john-mcaleely> (still wating on the HDMI output)
<ogra_> are oyu using my image ?
<ogra_> or something self breed
<ogra_> *bewed
<ogra_> bah
<ogra_> *brewed
<john-mcaleely> ogra_, yours indeed: http://people.canonical.com/~ogra/snappy/all-snaps/
<ogra_> yeah, that should boot ... it dpoes at least on serial
<ogra_> ( i always test the early builds with serial and eth attached)
<john-mcaleely> ok, I need to rummage for a serial port then
<qengho> john-mcaleely: Is there a change in eth status?
<john-mcaleely> lights, sure
<john-mcaleely> (on the eth)
<qengho> john-mcaleely: I think you can change the boot config files to make it try hdmi.
<john-mcaleely> hmm
<ogra_> qengho, seems we are suffering from a systemd bug ... i.e. net.ifnames=0 isnt respected anymore all of a sudden
<ogra_> so there wont be any config
<qengho> Oh man.
<ogra_> (for the NIC that is)
<ogra_> john-mcaleely, try editing the cmdline.txt and add console=tty0 to the end of the line in that file ... directly on the SD card
<ogra_> that should redirect output to the LCD so you can debug without serial cable
<john-mcaleely> ogra_, aha, ok I will rummage there!
<john-mcaleely> thank you!
<ogra_> :)
<arges> jdstrand: ok figured it out. I forgot to restart the daemon after connecting it.
<arges> * connecting the interfaces that is
 * qengho still wishes for image build bots. pi2, pi3, pandaboard, etc. Built nightly if any change.
<arges> I'm guessing that restarting it reloads the apparmor profile?
<john-mcaleely> +1
<ogra_> qengho, working on that ...
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core was the first step ... just needs some review tools fixage now then we have dailies for the ubuntu-core snap ... i'm battlling with the same setup for kernels ... once we have daily auto-pushes to the store we can have daily images from these packages
<qengho> ogra_: Awesome!
<ogra_> (btw, you can actually branch the bzr branch this uses to inject personal changes and do sideloaded images with them)
<ogra_> (i'll blog about it once everything is in place)
<stgraber> jdstrand: when you have 5 minutes, can you review https://github.com/snapcore/snapd/pull/1598 ? it's a simple fuse interface to run a fuse filesystem
<mup> PR snapd#1598: interfaces: implement a fuse interface <Reviewed> <Created by stgraber> <https://github.com/snapcore/snapd/pull/1598>
<mup> PR snapcraft#714 opened: Release changelog for 2.14 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/714>
<ogra_> whee !
 * ogra_ looks forward to drop the hacked snapcraft from the image build PPA
<jdstrand> stgraber: it's on my todo for later today
<sborovkov> ogra_: hello. do you by any chance have some recent RPI2 snappy only image? Accidentaly removed one I built 2 weeks ago and I can't build now because of some errors popping up about hardware configuration...
<ogra_> sborovkov, yes, as announced last week on the ML :)
<ogra_> http://people.canonical.com/~mvo/all-snaps/16/
<ogra_> note that this is all still experimental
<stgraber> jdstrand: cool, thanks
<sborovkov> ogra_: ah cool, so it's out. missed that
<ogra_> sborovkov, nothing is out ... it is really highlly experimental still and will likely stay so for a while
<sborovkov> But it was the same before, was not it? )
<ogra_> yeah
<ogra_> since we started on series 16
<mup> PR snapd#1649 opened: store: minor store improvements from previous reviews <Created by matiasb> <https://github.com/snapcore/snapd/pull/1649>
<john-mcaleely> ogra_, so, adding tty0 got output on screen. It's to a busbox prompt, which is a surprise
<ogra_> yeah, that sounds messed up
<john-mcaleely> last line of log above is 'no init found. try passing init= bootarg'
<ogra_> yeah, thats useless
<ogra_> the actual error is lines above
<ogra_> most likely scrolled off screen ...
<john-mcaleely> right. looks that way. i have a screen full of errors
<john-mcaleely> I will set up a UART so these things are captureable
<ogra_> (this is where you actually need serial to capture the logs)
<john-mcaleely> odd though - I assumed my pi3 was a standard object...
<ogra_> well, you are testing the very first experimental image for a new setup
<john-mcaleely> ha
<ogra_> (which only got a very lax smokke test before being published ... i.e. snap install hello-world after manually setting up networking)
<john-mcaleely> my pi is silkscreened 'Raspberry Pi 3 Model B V1.2'
<ogra_> well, it should just work
<john-mcaleely> as always!
<ogra_> but there can be bugs where a failed firstboot setup eats your filesystem and such stuff
<ogra_> try a fresh flash and edit the cmdline.txt before the first boot
<john-mcaleely> hmm. now I know the tty0 trick, let me see what a fresh sd card does with just that change
<ogra_> yeah
<john-mcaleely> snap!
<ogra_> snappy !!
<ogra_> :)
<ogra_> schnaps !
<john-mcaleely> better
<john-mcaleely> best!
<niemeyer> jdstrand: Sweet, thanks!  Want to try getting some of those interfaces handled today
 * ogra_  sighs ... something is really wrong with either u-d-f or our new kernel spec
<mup> PR snapd#1409 closed: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1409>
<john-mcaleely> ogra_, fyi. it's alive! logged in, and installed hello-world
<ogra_> yay
<ogra_> did the NIC come up properly OOTB ?
<john-mcaleely> should I raise a bug to add tty0 to the cmdline? seems useful for typical pi3 hackers ogra_?
<ogra_> no, i explicitly removed it :)
<john-mcaleely> sigh
<ogra_> it will come back once the images have stabilized :)
<mup> PR snapd#1643 closed: many: support interactive payments in snapd, filter from command line <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1643>
<ogra_> (no worries, i wont forget it)
<john-mcaleely> sometimes I wonder if anyone wants us to use this stuff. I shall sign off for the day
<ogra_> well, that is what "experimental" means :)
<john-mcaleely> it's a long word for 'broken' ;-0
<ogra_> we are still developing these images ... everything will change
<ogra_> and for development we need the defaulting to serial
<john-mcaleely> I get that. in the mean time I need to pass a hardware hazing ritual (install a uart) in order to follow along
<john-mcaleely> I'm a software dude, and snappy is cool software
<ogra_> sure and i can give you a hand (like i did) to get your use-case going ... but the image might completely eat itself with the first update for example
<ogra_> nothing is stable there yet
<john-mcaleely> I understand and expect that part
<john-mcaleely> :-)
<ogra_> so even if you try your SW on it ... take everything with a grain of salt
<qengho> Weird that it doesn't detect carrier or clear-to-send pin to decide whether to use serial or HDMI.
<ogra_> (i cant even guarantee yet that it will survive a few reboots)
<ogra_> qengho, we can surely add such features to uboot one day
<ogra_> note that we can not use the rpi bootloader
<ogra_> (only as jumpstart thing )
<john-mcaleely> anyway, thanks for the help ogra_. As you say, I'm now up and playing
<john-mcaleely> I will expect breakage
<ogra_> cool
<ogra_> tell me about it if you hit it
<john-mcaleely> ok!
<niemeyer> joc_: snapd#1644 is ready for some love
<mup> PR snapd#1644: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <Conflict> <https://github.com/snapcore/snapd/pull/1644>
<niemeyer> joc_: With that plus jdstrand's security review, we can land this
<niemeyer> morphis: ^
<joc_> niemeyer: thanks, i'll get on those comments
<arges> I'm getting integration test failures that I don't think are caused by my PR... is this a known issue?
<arges> http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/4129/
<mup> PR snapd#1649 closed: store: minor store improvements from previous reviews <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1649>
<arges> jdstrand: ^^^ not sure if you are the one who knows about this stuff. still having fun with https://github.com/snapcore/snapd/pull/1602
<mup> PR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602>
<mup> Bug #1611063 opened: can't mkdir SNAP_USER_COMMON directory <Snappy:New> <https://launchpad.net/bugs/1611063>
<blackboxsw> hmmm peeking around the cmdline snap tool docs, what is a snap assertion. cmdline help is slightly lacking about the intent
<jdstrand> arges: I know about it and hit it in one of my PRs. There seems to be a problem with one of the integration tests. I don't know if elopio or others are aware. I suggest adding a comment in the PR that the test isn't due to you
<arges> jdstrand: ok thanks
<ahasenack> does the name of the slot have to match the name of the plug? Or all we care about is the interface name?
<ahasenack> because the example on snapcraft.io (front page) uses "db" for A, and "database" for B
<mup> Bug #1611078 opened: could not install hello-world snap <Snappy:New> <https://launchpad.net/bugs/1611078>
<blackboxsw> so, the howto for creating a snap references snapcraft version 2.11 as required to get through the tutorial, but only snapcraft version 2.8.4 is available in xenial/universe. Where should folks go to get 2.11?
<blackboxsw> http://snapcraft.io/create/ is the reference page I'm using
<ahasenack> I was also wondering about ppas for a more up-to-date version
<blackboxsw> yeah, it'd be nice to document that at the top  (whatever the solution is)
<ahasenack> the instructions on snapcract.io prefix every command with sudo, but that doesn't seem needed anymore
<dpb1_> you should just create a snap for it
<dpb1_> :)
<ahasenack> and snap find doesn't have the --broad option the docs talk about
<blackboxsw> heh
<ahasenack> blackboxsw: I got 2.11 from xenial-updates
<ahasenack> ah, snapcraft
<ahasenack> sorry
<ahasenack> blackboxsw: I have snapcraft 2.13.1 from xenial-updates/universe
<blackboxsw> hrm
<blackboxsw> trying apt-get update
<blackboxsw> http://paste.ubuntu.com/22720373/
<ahasenack> blackboxsw: you don't seem to have xenial-updates for universe enabled
<mup> Bug #1611080 opened: snapcraft.io says snap find has --broad, but it doesn't <Snappy:New> <https://launchpad.net/bugs/1611080>
<blackboxsw> yeah I'm adding the source now
<mup> Bug #1611083 opened: Users without xenial-updates/universe can't get snapcraft  version 2.11 tour. <Snappy:New> <https://launchpad.net/bugs/1611083>
<morphis> niemeyer: great, lets wait for jdstrand_ then
<stokachu> how do i include files from my parts/build?
<ahasenack> the "parts:" key shown in the first snapcraft example isn't described in http://snapcraft.io/docs/snaps/metadata
<ahasenack> are these things out of date? Too old or too new?
<qengho> ahasenack: The docs are ancient and so is "parts:".
<qengho> ahasenack: What do you want to know?
<ahasenack> what you just said, "docs are ancient" :)
<ahasenack> i.e., want to know what to trust
<ahasenack> should I file a bug?
<cpaelzer> isn't this just metadata vs snapcraft yaml content?
<ahasenack> this is a first-journey type of thing
<qengho> ahasenack: Sure.
<cpaelzer> parts is part of the snapcraft yaml
<cpaelzer> and there it is fine and current IIRC
<ahasenack> so snapcraft.yaml is like snap.yaml plus snapcraft specific things?
<cpaelzer> and if you use snapcraft it will build the meta/snap.yaml for you (but you could build a snap without) and in there there is no parts
<qengho> ahasenack: snapcraft is still in development. I don't think there's anything to "trust". There is a new version every couple of days.
<cpaelzer> ahasenack: snapcraft will build the snap and its metadata - so snapcraft yaml has some similar content - but it is not just like a superset
<ahasenack> cpaelzer: ah, I see
<qengho> ahasenack: You should be writing for snapcraft. That is the human end of making a package.
<cpaelzer> ack
<qengho> ahasenack: All the rest of the details, you shouldn't care about.
<cpaelzer> and as a first journey I'd recommend the tour
<cpaelzer> ahasenack: http://snapcraft.io/create/
<ahasenack> it's where I am at now, that's where I saw this new "parts:" key
<morphis> niemeyer: can you give https://github.com/snapcore/snapd/pull/1623 another round?
<mup> PR snapd#1623: interfaces/udev,osutil: avoid doubled rules and put all in a per snap file <Reviewed> <Created by morphis> <https://github.com/snapcore/snapd/pull/1623>
<cpaelzer> ahasenack: so you just want a link at some doc telling you more about it?
<ahasenack> cpaelzer: no, I was just wondering if http://snapcraft.io/docs/snaps/metadata was outdated
<qengho> ahasenack: "parts" are the parts needed to construct the package. Have a source tree somewhere? That's a part. Have some other component you need to include? That's another part.
<cpaelzer> ahasenack: everything is a bit outdated as it is evolving, but not that bad - the reason is not there is just as it was a snap.yaml and not a snapcraft yaml
<cpaelzer> ahasenack: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-parts/ that would be some place to look at for parts
<ahasenack> cpaelzer: cool, thanks for the explanation
<qengho> ahasenack: Inside part, you need a name key that you invent, and inside that, you use some names that are part of every part, and some that are specific to the kind of part that is, which you will have indicated by the plugin needed to handle that part, like "plugin: cmake" or "plugin: go" or "plugin: autotools" or "plugin: copy"
<cpaelzer> ahasenack: or rather clsoe to the link you had http://snapcraft.io/docs/build-snaps/syntax
<cpaelzer> ahasenack: http://snapcraft.io/docs/build-snaps/parts
<qengho> Here's a big snapcraft yaml that has a while bunch of kinds of parts needed to construct a package.
<qengho> http://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/view/head:/snapcraft.yaml
<ahasenack> nice
<ahasenack> one more quick question about the docs, they show "sudo snap <command>", but I've been using it without sudo and it's working, or looks like it
<ahasenack> even the tour
<ahasenack> i.e.,
<ahasenack> $ snap install ./hello_2.10_amd64.snap
<ahasenack> hello 2.10 installed
<ahasenack> is that something new?
<cpaelzer> ahasenack: with sudo it goes to /snap without to ~/snap
<ahasenack> or am I setting myself up to fail soon?
<ahasenack> ah
<cpaelzer> ahasenack: depending what it is supposed to do you are prepping some pitalls  -but in general it can work
<cpaelzer> a (little) bit like (sudo) make install
<ahasenack> hm, my ~/snap is empty
<cpaelzer> to a different prefix
<Ursinha> without sudo it says I have to login
<Ursinha> with sudo it just works
<ali1234> right.
<ali1234> without sudo you have to log in to the snap store through U1
<Ursinha> why is that?
<ali1234> no idea
<Ursinha> :)
<ali1234> ~/snap is where snaps write data
<ahasenack> yeah, the user data bits
<ahasenack> common and versioned
<Ursinha> right, trying to understand what logging in the store has to do with local permissions, there might be an explanation I'm sure :)
<ahasenack> hm, everytime I repeat "snap install ./mysnap"
<ahasenack> its rev gets bumped in "snap lisT"
<Ursinha> yeah
<Ursinha> it installs normally and increases the count
<ahasenack> ok, I remember reading somewhere that the snap version doesn't mean anything
<Ursinha> xN
<ali1234> revision isnt the same as version
<qengho> ahasenack: The version is defined by the developer. The revision is local to you.
<ali1234> you can install the exact same snap multiple times and each one will get a different revision
<ali1234> like literally the same .snap file
<Ursinha> yeah, I did that here
<ali1234> it tends to happen a lot when you are developing
<Ursinha> do you know why is that?
<ali1234> so that you can revert to the previous version
<qengho> ahasenack: You will be able to set particular local revisions to be active. So, if a new install or something has trouble, you can back out.
<Ursinha> ali1234: version or revision? :)
<ahasenack> is there a way to list all revisions, other than ls -la /snap/<name>?
<ali1234> either. whatever you had before, you can go back to it
<Ursinha> right
<qengho> Ursinha: In normal, nondevelopment usage, a new version and only a new version will become a new local package revision.
<Ursinha> qengho: because you wouldn't install the same snap twice?
<qengho> Because you can't.
<Ursinha> hm?
<qengho> Ursinha: That revision will equal version.
<Ursinha> maybe I'm not that far in the tour yet to know there are other "usages"
<ali1234> most of this stuff isn't even decided yet
<Ursinha> ah, right
<ali1234> notice that there isn't even a 16 release yet
<mup> Bug #1611094 opened: http://snapcraft.io/create/ mentions readmes in each tour subdirectory, they are missing <landscape> <Snappy:New> <https://launchpad.net/bugs/1611094>
<dpb1> Ursinha: ya, I get the same login issue you do.
<dpb1> (as non sudo)
<dpb1> did you file an issue?
<Ursinha> not yet
<dpb1> Ursinha: k
<Ursinha> dpb1: have you tried logging in and then without sudo? does that work?
<dpb1> hm
<Ursinha> login is being difficult for me now
<dpb1> no
<mup> Bug #1611098 opened: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611098>
<mup> Bug #1611099 opened: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611099>
<dpb1> Can snaps work in lxd containers?
<dpb1> I got this
<Ursinha> dpb1: it works after login
<dpb1> - Mount snap "ubuntu-core" ([start snap-ubuntu\x2dcore-122.mount] failed with exit status 1: Job for snap-ubuntu\x2dcore-122.mount failed. See "systemctl status "snap-ubuntu\\x2dcore-122.mount"" and "journalctl -xe" for details.
<dpb1> ah, ok
<dpb1> maybe system wide it doesn't in a lxd?
<ericsnow> dpb1: I opened bug #1611078 for that
<mup> Bug #1611078: could not install hello-world snap <Snappy:New> <https://launchpad.net/bugs/1611078>
<dpb1> ericsnow: ty
<ericsnow> sparkiegeek: apparently LXD and snappy aren't compatible yet
<dpb1> I'll back out from the container
<sparkiegeek> ericsnow: huh? wrong ping?
<dpb1> hah
<ericsnow> sparkiegeek: yep :)
<ericsnow> sparkiegeek: must have been thinking about you :)
<sparkiegeek> ericsnow: :)
<dpb1> awww
<Ursinha> qengho: do you know of any docs that would explain having to login to u1 to install snaps without sudo?
<qengho> Ursinha: No. I think someone confused a permission problem with installing with a non-authorized problem with downloading restricted/paid snaps. Same exception, different uses. Maybe.
<qengho> Ursinha: No need to speculate.  $ ubuntu-bug snapd  and say it's confusing and broken anyway.
<dpb1> :)
<Ursinha> qengho: alright, checking first :) thanks for the information
<stokachu> whats the proper way to copy files from one parts build dir to another parts build dir?
<stokachu> right now im just copying the files into the top level directory of the snapcraft.yaml and then using the copy plugin
<niemeyer> morphis: Out on a bike ride and not quite back yet, but will check for sure once back
<qengho> stokachu: The "organize:" section in a part is probably best.
<mup> Bug #1611108 opened: snap install without sudo asks to login to snap store <apport-bug> <i386> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1611108>
<ahasenack> so build-packages is more or less like build-depends,
<ahasenack> and stage-packages is like Depends
<ahasenack> these "cloud" parts, are they really taken from the wiki at https://wiki.ubuntu.com/Snappy/Parts?
<niemeyer> ahasenack!
<ahasenack> niemeyer: hey
<elopio> ahasenack: https://wiki.ubuntu.com/snapcraft/parts
<ahasenack> elopio: hm, Snappy/Parts is what's in the snapcraft tutorial
<niemeyer> morphis: Still around?
<elopio> ahasenack: can you please report a bug? That's old.
<ahasenack> elopio: https://github.com/ubuntudesign/snapcraft.io/issues/170
<elopio> thank you.
<ahasenack> welcome
<dpb1> when publishing a snap, should I publish a trunk version as 'blah-snapshot', or should I use the edge/beta/etc channels to do that?
<qengho> dpb1: depends on who your audience for that version is for.
<qengho> Will blah ever see a stable, tagged version?
<dpb1> qengho: yes
<dpb1> thinking more about it
<dpb1> I could see people wanting to install 'edge'
<dpb1> and I would keep updating that
<mup> PR snapd#1650 opened: Merge master onto #1623 to check tests <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1650>
<mup> PR snapcraft#715 opened: Add artifacts option to make plugin <Created by jhobbs> <https://github.com/snapcore/snapcraft/pull/715>
<blackboxsw> how does a person find a list of defined slots. I'm currently combing through examples in https://github.com/ubuntu/snappy-playpen and I know that can't be right
<niemeyer> blackboxsw: $ snap interfaces
<blackboxsw> cheers gustavo, that was easy, thx.
<niemeyer> np!
<rcj> speaking of interfaces.  I'm having problems connecting a snap to an interface (I think).  snapcraft.yaml is http://paste.ubuntu.com/22748234/
<rcj> running the command in the snap shows that /run/cups/cups.sock access is denied when not in devmode.
<rcj> 'snap interfaces' output @ http://paste.ubuntu.com/22748234/
<rcj> (correction) 'snap interfaces' output @ http://paste.ubuntu.com/22748451/
<rcj> I know that cups-control is restricted so I attempted to connect it with 'snap connect cups-control cloudprint:cups-control' but that returns: error: cannot perform the following tasks:
<rcj> - Connect :cups-control to cloudprint:cups-control (cannot connect plug "cups-control" from snap "", no such plug)
<invapid> is there a default thread for compiling snap dependencies (made via cmake)
<invapid> I'm seeing -j4 being used when running snapcraft, but never specified that
<mup> PR snapd#1623 closed: interfaces/udev,osutil: avoid doubled rules and put all in a per snap file <Reviewed> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1623>
<mup> PR snapd#1644 closed: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <Conflict> <https://github.com/snapcore/snapd/pull/1644>
#snappy 2016-08-09
<mup> PR snapd#1651 opened: More create-user fixes <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1651>
<mup> PR snapd#1652 opened: Correct interface connection JSON documentation (used an object insteâ¦ <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1652>
<mup> PR snapd#1653 opened: Correct documentation on refresh action (referred to an old update acâ¦ <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1653>
<mup> PR snapd#1654 opened: Fix typo mutlipart -> multipart <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1654>
<mup> PR snapd#1654 closed: Fix typo mutlipart -> multipart <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1654>
<mup> PR snapd#1652 closed: Correct interface connection JSON documentation (used an object insteâ¦ <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1652>
<zyga> good morning
<cpaelzer> good morning zyga
<cpaelzer> I wonder is there a way to refer to snap paths like $SNAP_DATA from the snapcraft yaml when specifying commands
<cpaelzer> I have a forking daemon, and wonder if I could modify it's "command" to include such
<cpaelzer> that would allow to avoid a lot of glue-code just to pass the right config file directory
<cpaelzer> I have seen in snappy-playpen others used a launcher.sh to pickup the path
<cpaelzer> but there could (should?) be a way to do e.g.
<cpaelzer> command: usr/local/sbin/ntpd -c $SNAP_DATA/etc/ntpd.conf
<cpaelzer> maybe just the right amount of escaping ...
<cpaelzer> the given example above resolves to just /etc/ntpd.conf for now
<cpaelzer> hmm - just wondered about the ML archives - was the snappy-devel list discontinued for the snapcraft list?
<cpaelzer> "Please use https://lists.ubuntu.com/mailman/listinfo/snapcraft instead."
<cpaelzer> ah yes, ok
<zyga> cpaelzer: hey
<zyga> cpaelzer: the command field of each app should be able to resolve environment variables (they are just copied and eventually are resolved by the shell)
<zyga> cpaelzer: hmm
<zyga> cpaelzer: can you look at the prime directory and see if it is resolved early? My point is that it should be present there verbatim, as you spelled it above
<cpaelzer> yeah I just examined the systemd service
<cpaelzer> it is just referring to its "usual" warpper
<zyga> cpaelzer: and it doesn't contain $SNAP_DATA?
<cpaelzer> it does
<cpaelzer> so the wrapper is "good"
<cpaelzer> let me check all of this for typos and such
<cpaelzer> exec "$SNAP/usr/local/sbin/ntpd" -c $SNAP_DATA/etc/ntpd.conf "$@"
<zyga> cpaelzer: hmm cna you pastebin the systemd unit?
<cpaelzer> sure, just a sec
<cpaelzer> systemd http://paste.ubuntu.com/22782806/ wrapper http://paste.ubuntu.com/22782810/
<cpaelzer> uh that is nice
<cpaelzer> zyga: I found it
<cpaelzer> it is actually an application issie I think
<cpaelzer> service snap.ntpsec.ntpd status reports 30780 /snap/ntpsec/x1/usr/local/sbin/ntpd -c /var/snap/ntpsec/x1/etc/ntpd.conf
<cpaelzer> so it did resolve
<zyga> yes, it looks correct
<cpaelzer> I was tricked by seeing that in journal for it "getconfig: Couldn't open </etc/ntp.conf>: No such file or directory"
<cpaelzer> so it is more an app bug to ignore its arg for whatever reason
<dragly> Tried building and installing the ubuntu-clock-app example with snapcraft + snap install now. I get the following errors: "libGL error: failed to load driver: swrast" "Unrecognized OpenGL version".
<cpaelzer> anyway it was good to go down the snap-systemd unit -> wrapper -> command path at least once
<dragly> Should this work with the current version of snapcraft and snap?
<cpaelzer> zyga: thanks
<zyga> dragly: does the old version from the store work?
<dragly> what's the name in the store?
<zyga> dragly: ubuntu-calculator-app
<dragly> can't find anything with that name in Ubuntu Software nor with apt
<dragly> I'm running Ubuntu 16.04
<dragly> the one I tested was from https://github.com/ubuntu/snappy-playpen
<cpaelzer> dragly: snap find clock gives me "ubuntu-clock-app" from the store
<cpaelzer> trying to install now on my16.40 just to check
<cpaelzer> dragly: fetch & install from store worked fine - was your issue that the one from playpen didn't build or install ?
<dragly> ah, sorry, I forgot that snap install != apt install
<dragly> cpaelzer: it both builds and installs, but when running I get the OpenGL errors
<netphreak> hi, guys!
<dragly> same with the one from "snap install ubuntu-clock-app"
<cpaelzer> running the one from store http://paste.ubuntu.com/22783564/ (works)
<netphreak> Anynews on Ubuntu core and RPI3?
<dragly> cpaelzer: doesn't work here, seems to be the same issue as others are reporting: https://askubuntu.com/questions/759647/opengl-error-in-snaps-ubuntu-16-04/760096#760096
<dragly> I had the same issue previously, but thought it was fixed
<dragly> I think there is a bug report on it somewhere. Let me see if I can dig it up.
<dragly> cpaelzer https://bugs.launchpad.net/snappy/+bug/1574851
<mup> Bug #1574851: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851>
<dragly> I haven't tried to workaround, but will be distributing an app to others with Nvidia machines, so I'm wondering if there's anything I can do without having to ask the users to copy the nvidia libGL.so to /var/lib/snapd/lib/gl ?
<mvo> dragly: can you please try to install "snap-confine ubuntu-core-launcher" from xenial-proposed? that should fix the nvidia problem
<seb128> mvo, hey
<zyga> mvo: I understand that there are some regressions that are blocking the update out of the SRU proposed pocket, correct?
<mvo> hey seb128
<mvo> zyga: yes, however I think those got all resolved by now, I think its good to go now
<zyga> mvo: including the one you pinged me about last week, the X11 one?
<seb128> mvo, attente, unsure when/where snapd-xdg-open was discussed but I would like to start a discussion about removing the whitelist, filed https://github.com/ubuntu-core/snapd-xdg-open/pull/12 for that but maybe a mailing list would be better? can you do suggestions?
<mup> PR ubuntu-core/snapd-xdg-open#12: don't restrict the urls that are handled <Created by seb128> <https://github.com/ubuntu-core/snapd-xdg-open/pull/12>
<mvo> zyga: yes, this no longer happens with snapd 2.11 and I think its was adt artifcat
<mvo> seb128: iirc gustavo suggested to put this in place, he is probably the best one to discuss how to ease/remove it
<zyga> mvo: that's good to know, thank you
<seb128> mvo, ok, thanks, I'm unsure what we protect against and ideally we are going to want to let apps open the urls they handle, like skype handles x-scheme-handler urls and you are going to want that to work without us having to patch the helper to know about every application on earth
<seb128> x-scheme-handler/skype I meant
<mwhudson_> mvo: did you get the "add to whitelist" syntax wrong on https://github.com/snapcore/snapd/pull/1651 ?
<mup> PR snapd#1651: More create-user fixes <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1651>
<mvo> mwhudson_: I did, thanks! should be fixed now
<zyga> mwhudson_: congratulations to your family :)
<mwhudson_> zyga: thanks :)
<mwhudson_> mvo: i'm hacking on adding --sudoer and --yaml flags now
<mwhudson_> the 'details' link on the test results on my PR isn't working for me
<mwhudson_> "162.213.35.179 took too long to respond"
<zyga> mwhudson_: on integration tests?
<mwhudson_> yeah
<zyga> mwhudson_: that's over VPN
<mwhudson_> oh
<zyga> mwhudson_: aka annoying ylink
<mwhudson_> not very community?
<mwhudson_> but not too bad for me :)
<mwhudson_> ah duh
<mwhudson_> zyga, mvo: what does snappy think about rebasing?
<zyga> mwhudson_: doesn't like it much
<zyga> mwhudson_: merges are more welcome
<mwhudson_> zyga: well my PR fails a test
<zyga> mwhudson_: merge with master to fix it (if that fixes it)
<mwhudson_> zyga: i could rebase and fix the problem, or push a new commit
<mwhudson_> it's a real problem :)
<zyga> oh, just push a new fixing commit then
<mwhudson_> ok
<mwhudson_> related
<mwhudson_> can i run the integration tests locally easily
<mwhudson_> ?
<zyga> mwhudson_: sure
<zyga> mwhudson_: with the exception of magic version of ubuntu-device-flash you should just be able to run run-tests --integration
<zyga> mwhudson_: it's tad slow though
<mvo> the u-d-f from http://people.canonical.com/~mvo/all-snaps/16/ should work with this
<zyga> mwhudson_: maybe something has changed since I first looked, fgimenez knows this part better than I do
<zyga> mwhudson_: so just staick that in your $PATH and you should be ok
<zyga> s/staick/stick/
<mwhudson_> ok
<zyga> my link is laggy today, downloading some stuff for work later
<imexil> Hi, is there a quick way to get out of "error: cannot remove "X": snap "ipe" has changes in progress" limbo
<imexil> I already tried to restart snapd but that did not help
 * mwhudson_ lols at the ascii art "crushing failure and despair"
<zyga> imexil: can you tell me what does "snap changes" say
<imexil> well I cancelled an install with CTRL+C and that's what it is still doing.
<zyga> imexil: unlike apt or yum, snapd remembers and retries requests
<dragly> mvo: Sorry, I managed to overlook your message earlier. Installed snap-confine ubuntu-core-launcher now.
<imexil> zyga: 123  Doing   2016-08-09T08:14:25Z  -  Install "ipe" snap from file "ipe_7.2.5_amd64.snap
<dragly> Now ubuntu-clock-app.clock returns "multiple nvidia drivers detected, this is not supported. errmsg: No such file or directory"
<zyga> imexil you just quit the front end, the backend (snapd) is still doing what you asked it to do
<zyga> dragly: can you report a bug on snap-confine
<zyga> dragly: with all the details you can add
<imexil> zyga: so how do I kill the backend?
<mvo> dragly: and pastebin "ls -d /usr/lib/nvidia*" please?
<zyga> dragly: especially output of /usr/lib/nvidia-[1-9][0-9][0-9]
<zyga> imexil: you don't have to
<dragly> zyga: Sure! Do you happen to know what returns the error message so that I can try to figure out why it detects multiple versions?
<dragly> I get /usr/lib/nvidia/  /usr/lib/nvidia-352/  /usr/lib/nvidia-361/  /usr/lib/nvidia-361-prime/
<zyga> imexil: what do you want toarchive?
<zyga> *achieve
<zyga> dragly: yes, I wrote that code :/
<dragly> The install on this machine is an upgrade, could that be why I have multiple nvidia versions in that folder?
<imexil> zyga: well I can't do anything since it just sits there in limbo for 30 mins or more now
<zyga> dragly: can you try rmeomving all except the one you actually want to use
<zyga> imexil can you do this: snap abort 123
<zyga> (123 i the identifier of the task)
<zyga> s/task/change/
<fgimenez> zyga, mwhudson_, mvo yep, with the new udf all should be fine to run the remaining integration tests (most of them have been ported to spread)
<zyga> you can salso see snap change 123
<zyga> for details
<imexil> zyga: Thanks!
<imexil> That worked
<zyga> imexil: note that if you had killed snapd it would just restart the next time and resumed the whole activity
<imexil> I see.
<mwhudson_> i think http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/4144/console is going to make me very upset with adduser(1)
<dragly> zyga: I tried to remove the nvidia-352 with "sudo apt remove nvidia-352" and also checked dpkg --get-selections for any other nvidia packages. However, the folder still remains. I'll remove it manually now, but I suspect the script might need to verify if multiple packages are really installed.
<zyga> dragly: what is inside?
<dragly> I currently only find libnvidia-fbc.so.1@  libnvidia-wfb.so.1 in the folder
<dragly> two dead symlinks to libnvidia-fbc.so.352.63 and libnvidia-wfb.so.352.63
<zyga> dragly: you can use dpkg -S to find which package puts stuff inside that folder
<zyga> dragly: yeah, please try to remove them
<mwhudson_> uh
<dragly> seems like noone is taking responsibility for those files
<mwhudson_> how _do_ you add a user to a group with extrausers
<zyga> dragly: then they must be created by postinstall scripts
<dragly> now I'm back to the "libGL error: failed to load driver: swrast"
<zyga> dragly: hmm
<dragly> trying to update all packages with xenial-proposed now
<dragly> I guess snapd should be updated too?
<zyga> dragly: snapd doesn't affect this but sure
<zyga> dragly: you can update it
<zyga> dragly: I think someone with nvidia hardware of the same / similar era should be able to explore this bug in detail
<mwhudson_> can i d/l an ubuntu-core image yet?
<mwhudson_> oh, http://people.canonical.com/~mvo/all-snaps/16/
<dragly> zyga: Sure. I would also be happy to explore it further myself. Should any links have automatically been created in /var/lib/snapd/lib/gl/ with the above packages installed? Currently this folder is empty.
<mwhudson_> uh does libnss-extrausers just not support supplementary groups at all
<dragly> Tried the workaround by copying the files from nvidia-* to /var/lib/snapd/lib/gl, but that didn't work either.
<ogra_> mvo, so i'm a bit desparate with my kernel snap creation ... whatever i try with u-d-f i can not get any working arm images (funnily kvm works, even if the kernel package isnt built correctly) ... when i mount a pi2 or dragonboard image after dd'ing i end up with:
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/
<ogra_> unset
<zyga> dragly: re, sorry I was on a call
<zyga> dragly: it is a bit magic, you need to read this to understand what is going on
<zyga> dragly: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<zyga> dragly: the only way to see the actual environment is to experience it at runtime, try the hello world snap or anything that includes bash (I use snapd-hacker-toolbelt snap)
<zyga> dragly: then you can see what the /var/lib/snapd/lib/gl folder really contains
<zyga> dragly: you should also, after you get familiar with the ideas, look at github.com/snapcore/snap-confine
<zyga> dragly: there's src/mount-support-nvidia.c there that does all the nvidia work
<zyga> dragly: so please explore that and get in touch when you have some ideas
<mvo> ogra_: is this a sideloaded kernel?
<ogra_> yes
<ogra_> i didnt want to upload potentially broken ones to the store
<om26er> I am running snappy on my RPi2 after a while, seems there is no longer enable-classic command ? Was that removed or is that another way for that ?
<ogra_> (and currently my kernel build script is broken wrt pi2 so i cant quickly give you something to test)
<mvo> ogra_: aha, ok. I think that is the issue, i.e. a bug in that code path
<om26er> downloaded from https://people.canonical.com/~mvo/all-snaps/16/
<ogra_> ah, phew
<ogra_> mvo, another thing ... did you ever try to reboot a kvm image 3-4 times ?
<zyga> hey ogra_ how are you doing? :-)
<ogra_> about the 3rd time it wipes the grub variables
<zyga> ogra_: magic broken grub thing?
<mvo> ogra_: I have a vague idee what it is, I can give you something in maybe 1h or so, just ping me when you have your script ready again
<ogra_> yeah
<ogra_> mvo, ok
<mvo> om26er: please try "snap install classic"
<mvo> ogra_: uh :( does it happen if you randomly reboot in the middle of the boot process?
<mvo> ogra_: or normal reboots?
<ogra_> normal reboots
<ogra_> fresh install, do the first boot and check you can log in ... reboot ... do that again ... grub dead
<mvo> ogra_: ta, I have a look
<ogra_> i forgot if it is the second or third time ... but it is reliably reproducable
<mvo> ta
 * zyga recalls checkbox reboot stress test (just 30 reboots)
<om26er> mvo, says snap not found
<ogra_> yeah, that would have hit it quickly
<mvo> om26er: sorry, "sudo snap install --devmode classic"
<ogra_> om26er, --devmode --edge
<om26er> ogra_, does --edge give me yakketty ?
<mwhudson_> uh uh is /etc/sudoers.d supposed to be writable?
<ogra_> mvo, also, if you check the store ... ubuntu-core auto-uploads work ... i talked to jdstrand_ about getting an exception into the review tools to auto-publish (i was hoping it was done today, seems not... i should have turned off auto-build :) )
<ogra_> mwhudson_, yes, cloud-init needs to put a file in there
<dragly> zyga: Ok, thanks. I'll try to package a bash script and see what I can figure out.
<ogra_> om26er, no, yakkerty is dead beef ... all channels are xenial ... edge is just the test channel
<mwhudson_> oh right
 * mwhudson_ was being dumb
<zyga> dragly: you can use my snapd-hacker-toolbelt snap
<zyga> dragly: just install it and run snapd-hacker-toolbelt.busybox sh
<zyga> dragly: then explore
<dragly> Great!
<morphis> ogra_: do I have to change any configuration file to enable the pi3 serial console with your image?
<ogra_> morphis, nope, serial is the default
<morphis> hm
<ogra_> works here  ...
<morphis> 115200 8n1?
<ogra_> yeah
<ogra_> (i just use screen for that: screen /dev/ttyUSB0 115200)
<morphis> let me verify my pin connection
<ogra_> third pin is ground ...
<morphis> ogra_: following https://www.element14.com/community/servlet/JiveServlet/previewBody/73950-102-10-339300/pi3_gpio.png?01AD=3qQ4vBf_OyjHCgCsVfVCaOLElbWZscIAIt5xnDSIb_jh1EytwTHJ-Ag&01RI=4BD464EBE91DD68&01NA=na
<ogra_> yeah
<morphis> and https://www.sparkfun.com/products/9873
<ogra_> ah, i just use a cable ...
<morphis> hm
<morphis> ogra_: works
<morphis> my fault
<ogra_> phew
<mup> PR snapd#1655 opened: integration-tests: look for ubuntu-device-flash on PATH before calling sudo <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1655>
<morphis> ogra_: ok, a manual ifdown/ifup makes ethernet working
<ogra_> yeah, there is some race that mwhudson filed a bug about (cant find it atm)
<zyga> Son_Goku: hey, I cracked the go-xgettext issue
<zyga> Son_Goku: I pushed the package to github.com/zyga/snapcore-fedora, just doing local builds in mock to ensure it is good
<Son_Goku> zyga, sweet
<zyga> Son_Goku: morning :)
<zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1359802#c9
<ogra_> sergiusens, marking bugs as inclomplete but not asking for and info ? (bug 1608432)
<mup> Bug #1608432: snaps with type: os should allow publishing of .manifest files <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432>
<ogra_> s/and/any/
<Son_Goku> zyga, approved
<zyga> Son_Goku: woot, thank you, looking at snap-confine now
<Son_Goku> you should go ahead and import go-xgettext and prepare the bodhi things now
<Son_Goku> Bodhi has now been activated for F25, too
<zyga> yep, I read the mail today
<zyga> I see a few things that rpmlint reports on snap-confine, I'll do as you said and then return to snap-confine
 * zyga returned from small lunch :-)
<zyga> Son_Goku: package requested, focusing on snap-confine now
<morphis> ogra_: what are you building the pi3 kernel snap from? is there a snapcraft.yaml?
<zyga> Son_Goku: someone finally updated pkgdb code to select rpms by default (instead of the docker images) :-)
<Son_Goku> yeah
<Son_Goku> that drop down is going to be get really annoying
<Son_Goku> especially once we have modules :/
<Son_Goku> and if the snapcraft stuff gets done, snaps too
<zyga> I heard about modules last week but I didn't dig into it, what are they?
<Son_Goku> zyga, they're some abstract definition of a collection of software that provide a specific capability
<Son_Goku> for now, a module is a definition that pulls in a bunch of RPMs and generates a self-contained repository of them
<Son_Goku> and when you install a module, it installs all of the repository
<Son_Goku> I'm not entirely sure why we're doing this, since (to me) it looks like it's the same thing as the comps groups (composition groups)
<zyga> Son_Goku: looks like old package collections
 * Son_Goku shrugs
<Son_Goku> https://fedoraproject.org/wiki/Modularity
<ogra_> morphis, it is the pi2 kernel actually (same thing, just additional FW for the pi3 is needed)
<ogra_> morphis, this is the (currently still broken) attempt to roll automated kernel snaps https://code.launchpad.net/~ogra/+junk/kernel-test-snap ... https://code.launchpad.net/~ogra/+snap/kernel-test-snap
<ogra_> the original code for this lives in livecd-rootfs in the live-build/auto/build script
<sergiusens> ogra_ I did reply to that
<sergiusens> ogra_ hmm, didn't make it through :-/
<zyga> Son_Goku: does this look sensible http://pastebin.ubuntu.com/22798002/
<zyga> Son_Goku: I see the setuid bit, the setgroups that is actually desired in this case (I checked with the security team) and the script in /lib/udev/
<Son_Goku> does snap-confine not support using capabilities in-place of setuid?
<zyga> Son_Goku: capabilities?
<Son_Goku> https://fedoraproject.org/wiki/Features/RemoveSETUID
<zyga> Son_Goku: well, I'm not sure
<zyga> Son_Goku: let me check
<zyga> oh, I see
<zyga> cool, let me try
<zyga> it *probably* is enough
<zyga> though snap-confine still checks for uid == 0
<zyga> I think that check is obsolete when capabilities are in use
<Son_Goku> if it supports using file capabilities instead of needing setuid/setgid bits, then you should probably adjust the build system to offer the choice
<Son_Goku> both SUSE and Fedora prefer caps over setuid/setgid
<zyga> Son_Goku: upstream code doesn't support this yet but it seems easy enough to implement
<Son_Goku> cool
<zyga> Son_Goku: where are the authoritative caps I can use?
<zyga> I see     Invalid capability: cap_setuid,cap_dac_override,cap_sys_admin
<zyga> +%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin) %{_libexecdir}/snap-confine
<Son_Goku> I think file caps are documented in the capabilities manpage
<Son_Goku> man 7 capabilities
<zyga> thanks
<Son_Goku> zyga, also, it should be /usr/libexec/snapd
<Son_Goku> err
<Son_Goku> ... /usr/libexec/snapd/snap-confine
<Son_Goku> snap-confine needs to be in a folder in /usr/libexec
<zyga> noted, let me change that
<Son_Goku> it's essentially the same rule as in debian, except we actually use /usr/libexec for helper programs
<Son_Goku> instead of stuffing them into /usr/lib
<Son_Goku> honestly don't know why debian hasn't adopted it, especially since it's now part of the FHS spec as an optional component
<timothy> libexec is not present in hier anymore
<Son_Goku> yes it is
<Son_Goku> FHS 3.0 includes it
<timothy> drizzt@liara ~ % man hier | grep libexec
<timothy> drizzt@liara ~ %
<Son_Goku> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
 * zyga tries to guess the %caps() syntax
<timothy> To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself.
<Son_Goku> timothy, yes, I know
<Son_Goku> hence "optional"
<timothy> for example systemd uses /usr/lib/systemd by default :)
<zyga> Son_Goku: https://fedoraproject.org/wiki/How_to_create_an_RPM_package talks about %caps(cap_net_admin=pe) FOO.BAR
<zyga> Son_Goku: do you know what =pe is for?
<Son_Goku> nope
<Son_Goku> we're getting into weird stuff now :)
<Son_Goku> one sec
 * zyga googles
<Son_Goku> dwalsh is online on #fedora-devel
<Son_Goku> you could ask him
<zyga> yep, let's try that
<Ursinha> where do I report issues with the docs? in tour instructions, to be precise
<Son_Goku> he's usually the guy to turn to on these things
<mup> Bug #1611287 opened: provide canonical way to install templates and configuration files into $SNAP_* dirs <Snapcraft:New> <Snappy:New> <snappy (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611287>
<renatu> I am trying to create a snap for EDS and I am using "plugin: autotools   configflags: [..]". It is running configure with the correct flags. But looks like it is trying to use the configflags as gcc arg as well.
<renatu> Which is causing problems
<renatu> like that: gcc-5.real: error: unrecognized command line option â--sysconfdir=/etcâ
<renatu> How I can solve that?
<timothy> renatu: i's not an autoconfig configure
<renatu> timothy, what you mean?
<zyga> renatu: maybe it is a configure script but it is not a real autoconf configure script
<zyga> renatu: but a hand-written one
<renatu> zyga, timothy, I am using the same flags that I found in debian/rules: DEB_CONFIGURE_EXTRA_FLAGS += [...]
<timothy> renatu: as CFLAGS or what?
<renatu> I did not see any special case
<renatu> this is the full log: http://paste.ubuntu.com/22799750/
<timothy> yes, you are passing configure flags as CFLAGS
<renatu> timothy, how I can avoid that?
<timothy> what is you yaml file?
<renatu> timothy, http://paste.ubuntu.com/22799877/
<dpb1> hey guys: anyone know the story here: https://bugs.launchpad.net/snappy/+bug/1611078  installing snaps in containers needs some more tricks?
<mup> Bug #1611078: could not install hello-world snap in lxd container <landscape> <Snappy:New> <https://launchpad.net/bugs/1611078>
<ogra_> cjwatson, do you have an opinion about bug 1608432 ? (specifically about sergiusens' comment)
<mup> Bug #1608432: snaps with type: os should allow publishing of .manifest files <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432>
<cjwatson> ogra_: it would make more sense to do it in launchpad-buildd, since that has the build tree right there
<ogra_> cjwatson, ok, any preference for the location or the naming ?
<ogra_> (do you want me to sort the full naming scheme and just put it in meta/ so you can just blindly cp *.manifest)
<cjwatson> ogra_: well, could be even simpler
<cjwatson> ogra_: can you just write another file to the same output directory that the .snap is written to?
<cjwatson> ogra_: (it would certainly be best if launchpad-buildd didn't have to have a pile of naming logic in it)
<ogra_> i can try to, yes (the files already exist i think. live-build hasnt changed in that regard and i dont explicitly remove them)
<qengho> Cool if that manifest had a checksum in it too.
<cjwatson> ogra_: launchpad-buildd would have to whitelist the file too
<cjwatson>             if entry.endswith(".snap") and not os.path.islink(path):
<cjwatson>                 self._slave.addWaitingFile(path)
<Son_Goku> timothy, systemd was granted an exception back in 2012 in Fedora
<Son_Goku> it's not allowed without good reason
<timothy> claro
<ogra_> hmm, i see:
<ogra_> [2016-08-08 04:33:53] lb_binary_manifest
<ogra_> P: Begin creating manifest...
<cjwatson> Son_Goku: Debian never adopted /usr/libexec basically because it would have been a ton of work for negligible benefit
<ogra_> but i dont see the .manifest file anywhere (i thought i had some "ls" in the build to show the output dir)
<ogra_> i need to check that
<Son_Goku> what work? even debhelper still sets it by default
<cjwatson> it's hardly that simple
<Son_Goku> the debian maint stuff overrides that explicitly
<cjwatson> lots of little details of hardcoded paths etc.
<cjwatson> and nobody felt it was important
<fginther> Is there an official snappy app store?
<fginther> a browsable URL?
<ogra_> fginther, only https://uappexplorer.com/apps?sort=relevance&type=snappy
<fginther> ogra_, thanks
<ogra_> (semi official ... (i.e. even linked from official pages but run by a community member)
<ogra_> )
<Ursinha> ogra_: that says is unofficial
<ahasenack> where does it get its data from? API calls to the snap store?
<ogra_> Ursinha, and it is ... but we link to it from i.e. snapcraft.io because we have no better alternative
<qengho> fginther: $ snap find ...
<ogra_> Ursinha, thus "semi official" :)
<qengho> fginther: It reproduces the search queries that "snap find" uses. There's a RESTy API for the store.
<ogra_> well, snap find wont give you anything if you dont use a query string
<ogra_> so getting all snaps available is currently impossible via snap find
<Ursinha> ogra_: right
 * Ursinha tcpdumps to find the actual API call
<Ursinha> :)
<ogra_> lol
<stokachu> how can you specify the SNAP_USER_DATA in the snapcraft.yaml so that built files can be placed there
<stokachu> and accessed during runtime
<ogra_> i dont think you can
<ogra_> (in snapcraft.yaml at least)
<ogra_> you can use it in a wrapper script for your binary though
<stokachu> so the issue is we're building some dll's with dotnet that gets created during build
<stokachu> but we need to have the lockfile writeable when someone runs our snap and that happens in the same directory as our build
<zyga> stokachu: you cannot because that happens at runtime not at build time
<zyga> stokachu: just use a wrapper for your apps/services that copy data there if missing
<stokachu> ok
<zyga> stokachu: SNAP_USER_DATA is not a part of the snap
<zyga> stokachu: it's not in the squashfs file
<zyga> stokachu: so you cannot place anything there at build time
<stokachu> ok, makes sense
<mup> PR snapcraft#716 opened: Add Waf plugin (LP: #1611335) <Created by cpaelzer> <https://github.com/snapcore/snapcraft/pull/716>
<balloons> is a new release planned soon?
<la_juyis> hi popey, for compiling mono would you recommend a plugin different than autotools?
<mup> Bug #1611384 opened: Change detection not working, have to "snapcraft clean" between builds when modifying snap contents <Snappy:New> <https://launchpad.net/bugs/1611384>
<sergiusens> balloons fighting adt and yakkety even as worthless as it is to release to yakkety for us
<sergiusens> same old same old fighting build systems for days
 * sergiusens cannot wait for snapcraft to be released as a snap
<sergiusens> but work needs to happen for that to be viable
<balloons> sergiusens, yuck. I'm sorry to hesar that. I know all about
<ogra_> sergiusens, is it actually worthless for snapcraft ? (i imagine yakket users might want to roll snaps too)
<ogra_> it likely is useless for snapd
<sergiusens> ogra_ snaps that might or might not work as the base is different
<ogra_> well, you'd have to add libc to stage-packages for sure
<ogra_> but the rest should still work i imagine
<jamespage> o/
<mup> PR snapd#1656 opened: snap: do not sort the result of `snap find` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1656>
<zyga> sergiusens: hey, what are your plans to let snapcraft consume RPMs?
<popey> la_juyis: I haven't built any mono things yet, sorry
<ogra_> popey only builds stereo :)
<matteo> don't worry, be snappy ;)
<ogra_> !
<dpb1> I don't want that song in my head
<dpb1> :)
<matteo> LOL
<jamespage> ok folks - so I did a simple bit of openstack and snapped the nova compute control plane services - that works OK
<jamespage> going for the harder one now - specifically nova-compute - which will have to interface to libvirt or lxd and openvswitch or <insert sdn choice here>
<jamespage> anyone looked at snapping libvirt yet?
<jamespage> nova would need to access the local libvirt socket, and allow libvirt to consume qcow2 disk files that its sourced and setup
<ogra_> jamespage, well, there would have to be an interface that provides libvirt access for your snap
<ogra_> (you can not access anything outside of your snap without an interface)
<jamespage> yeah got that bit - so something like 'libvirt-manage' or suchlike
<jamespage> maybe 'libvirt-control' inline with other interfaces
<zyga> dpb1: let it snow, let it snap ;-)
<mup> PR snapd#1657 opened: tests: add udev rules spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1657>
<mup> PR snapd#1658 opened: partition: fix cleaning of the boot variables on the second good boot <Created by mvo5> <https://github.com/snapcore/snapd/pull/1658>
<sergiusens> zyga they are plans; it will happen when I get kyrofa back
<sergiusens> so I can dive into that and not fix all the minor problems everyone runs into
<zyga> sergiusens: understood, thanks
<mvo> ogra_: the bug about cleaning the boot vars is fixed (well, PR is up)
<jamespage> ogra_, is there an existing interface that allows a snap to share a directory with other snaps?
<jamespage> so nova-compute could expose a slot to allow libvirt to access its qcows2's for example
<zyga> jamespage: content
<jamespage> zyga, ta
<zyga> jamespage: but it cannot be used to share anything in $SNAP_DATA yet
<zyga> jamespage: but AFAIK that is the plan, for now it can only be used to share $SNAP
<zyga> jamespage: (or a fraction of $SNAP)
<jamespage> zyga, it would need to be the writable area that was sshared
<jamespage> so $SNAP_COMMON I think for this instance
<jamespage> as the data is not specific to a version of the snap
<zyga> jamespage: I see, in both cases it would require new code in snapd
<ogra_> mvo, great, thanks !
 * zyga focuses on snap-confine capabilities
<jamespage> stgraber, do you have a lxd snap yet?
<camako> folks, in the yaml, is there a way to copy a file under multiple names? Something like this ---> http://pastebin.ubuntu.com/22805771/
<jdstrand_> zyga: you'll need to think through using fscaps. the fs needs to support xattrs. snaps are typically built with -no-xattrs. the core snap may or may not be (I don't know), but if it is, the fscaps will be stripped for all snaps
<jdstrand_> zyga: s/all snaps/all snap systems/
<zyga> jdstrand: this is just for fedora (and perhaps suse) when snap-confine is packaged in the distribution-native format
<zyga> jdstrand: I'm trying to wrap my head around https://lwn.net/Articles/528542/
<mup> PR snapd#1653 closed: docs: fix references to refresh action <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1653>
<zyga> jdstrand: nothing I'm doing is changing snap-confine anywhere else
<zyga> jdstrand: and I must say, the way caps work makes me want to shout and run :)
<zyga> jdstrand: I will build a test app that shows all capabilities set and see how it behave
<zyga> *behaves
<camako> dholbach, thanks for reviewing the mesa-demos snap. I see that it failed for you. What GPU do you have?
<dholbach> camako, i915
<dholbach> in an x220 if that matters
<camako> dholbach, hmm interesting... Also, I'm not sure why this dir doesn't exist in your snap --> /snap/mesa-demos/x1/egl/opengles2
<camako> do you at least have /snap/mesa-demos/x1 ?
<dholbach> camako, http://paste.ubuntu.com/22806726/
<cjwatson> ogra_: so I can easily enough do http://paste.ubuntu.com/22806674/, but let me know first if you manage to get something spitting out the file to the right place
<camako> dholbach, I think I'm missing egl/gles packages in the snap... I'm assuming the gl apps worked for you (mesa-demos.{gears|teapot})?
<dholbach> they do! :)
<stgraber> jamespage: kinda
<stgraber> jamespage: snap install --edge --devmode lxd
<stgraber> jamespage: that will work, but we still need to sort out the interface we need and get some bits done on the snapd side (socket activation and group management at least)
<jamespage> stgraber, ack
<jamespage> stgraber, 'lxd-control' type or something I guess
<jamespage> stgraber, just thinking about a nova-compute snap
<jamespage> :)
<stgraber> jamespage: yeah, so we'll have a lxd interface which will both allow lxd to do all that it needs and will allow other snaps to connect to it
<stgraber> jamespage: it's not going to auto-connect for obvious security reasons, so you'll have to install the nova-compute snap, and then use "snap connect" to attach to the lxd interface so you can drive it
<jamespage> stgraber, I was making that assumption
<jamespage> good
<mup> PR snapcraft#717 opened: fix checker errors to let runtests.sh pass again <Created by cpaelzer> <https://github.com/snapcore/snapcraft/pull/717>
<ogra_> cjwatson, i can surely get it there (might need some test builds, but effectively it is just the builddir)
<elopio> mhall119: do you have a project that fails because of https://github.com/snapcore/snapcraft/pull/688 ?
<mup> PR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/688>
<elopio> well, that failed before your patch.
<sergiusens> elopio the arduino thing
<sergiusens> look at his g+
<mup> PR snapd#1659 opened: wrappers: ensure services have a valid SNAP_USER_DATA dir <Created by mvo5> <https://github.com/snapcore/snapd/pull/1659>
<SamYaple> https://github.com/snapcore/snapcraft/pull/657
<mup> PR snapcraft#657: Add constraints to python2 plugin <Created by SamYaple> <Conflict> <https://github.com/snapcore/snapcraft/pull/657>
<SamYaple> im goign to assume 5 days to complete teh tests is not normal...
<SamYaple> how do i trigger a recheck?
<sergiusens> SamYaple let me check
<sergiusens> SamYaple oh, travis even
<sergiusens> SamYaple can you do a noop commit --amend and push to trigger? travis didn't even assign it a job to retrigger
<SamYaple> okie dokie. will do. ill get it going again
<elopio> sergiusens: https://gist.github.com/elopio/a749810edd9a80517b46ace63d45b166 This is the testing for the SRU.
<elopio> ppisati: can you give me please the steps you are following to build the kernel snaps?
<ppisati> elopio: e.g. git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
<ppisati> elopio: git checkout master-next (beucase it contains the snapcraft.yaml file)
<ppisati> elopio: and then execute snapcraft
<ppisati> elopio: bear in my mind that you need *at least* one patch
<ppisati> elopio: to cope with the vmlinuz -> kernel.img rename
<ppisati> elopio: http://paste.ubuntu.com/22810646/
<ppisati> this is the snapcraft patch
<ppisati> with this, it won't boot at all
<ppisati> nonetheless, it'll hang during the initrd phase ATM, i'm trying to debug why
<elopio> thank you!
<ppisati> i need to compare the snap created using the snapcraft's plugin vs ogra's kernel snap
<ppisati> ogra's kernel work are ok, snapcraft's kernel plugin hangs @ initrd
<ogra_> weird
<ppisati> ogra_: indeed
<ppisati> ogra_: do you have a kernel snap somewhere that i can use?
<ogra_> did you try just dumping my initrd into your sanp ?
<ppisati> ogra_: if i can get my hand on your snap, yes
<ppisati> i mean, i'll do
<ogra_> ppisati, i think this pone worked
<ppisati> ogra_: which one?
<ogra_> lol
<ogra_> https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2559
<ppisati> k, me tris that
<ppisati> *tries
<mup> Bug #1611424 opened: Additional "lts" channel or support for upstream series <lxd> <Snappy:New> <https://launchpad.net/bugs/1611424>
<ogra_> sorry, pasted the url into the terminal instead of the irc client :P
<ali1234> how do i write new interfaces?
<ogra_> i'm trying alongside ...
<ogra_> ali1234, zyga had a series of blog posts about that somewhere
<mhall119> elopio: yes, it was arduino
<elopio> mhall119: can I get the link to the snapcraft please?
<ali1234> i need a bunch of sysfs access
<ali1234> gpio, backlight, maybe iio
<ali1234> and i2c-dev
<ogra_> gpio is in the works
<ali1234> and spidev
<mhall119> elopio: https://github.com/ubuntu/snappy-playpen/tree/arduino/arduino
<ogra_> (and i think i2c as well)
<elopio> ty.
<ali1234> also i need device tree overlays working
<ali1234> bug 1607447
<mup> Bug #1607447: Please install device tree overlays <apport-bug> <armhf> <xenial> <linux-meta-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1607447>
<ogra_> thats a problem until we can make them fully work in uboot (for which i currently dont have the time)
<ali1234> just let the blob load them and don't mess with it
<ogra_> (i know there was upstream work for generic overlay support)
<ogra_> the overlays are in the pi2-kernel snap
<ali1234> cool
<ali1234> is that usable yet?
<ogra_> but you still need to copy them around manually
<ogra_> (they have always been there)
<ali1234> they aren't in the classic image
<ogra_> ah, classic
<ogra_> yeah, never touched that :P
<ali1234> unless they are really well hidden
<ogra_> under lib/firmware/device-tree
<ogra_> that is where i drag them from in the snap  creation
<ogra_> ppisati, tested again., that snap boots here
<ali1234> well that's not very much use. they need to be on the fat partition or the bootloader can't see them
<elopio> fgimenez: do we have the hubot deployed somewhere?
<ogra_> ppisati, that was built using https://code.launchpad.net/~ogra/+junk/kernel-test-snap rev 36
<ogra_> ali1234, so you need to copy them there
<ogra_> not different to the snap image
<ali1234> that directory doesn't exist on the classic image, what package do they belong to?
<ogra_> just a different location to copy from
<ogra_> they shoould be in the linux-image-raspi2
<ali1234> they aren't
<ogra_> or linux-image-$version-raspi2 rather
<ogra_> well, i pull them from there
<ppisati> ah!
<ppisati> ogra_: ok, i installed your vanilla pc-kernel snap
<ppisati> ogra_: same exact problem upon boot
<ali1234> how can linux-image install things in /lib/firmware? everything in it needs to be versioned?
<ogra_> ali1234, http://paste.ubuntu.com/22812010/
<fgimenez> elopio, not currently, we had it while testing a not landed PR, whith the last wipeouts of the cluster it went away
<ogra_> thats the code that copies them in livecd-rootfs
<balloons> is there a snapcraft whomai command? in other words, what's my login creds?
<ogra_> ppisati, what u-d-f and what channel do you use ?
<fgimenez> elopio, this should be enough to redeploy it https://github.com/ubuntu-core/snappy-jenkins/pull/164/files
<mup> PR ubuntu-core/snappy-jenkins#164: hubot <Created by fgimenez> <Conflict> <https://github.com/ubuntu-core/snappy-jenkins/pull/164>
<ppisati> ogra_: i'm using mvo's all-snaps-amd64 img, scp the snap over and installing it
<elopio> fgimenez: awesome, thanks.
<sergiusens> balloons no, but that warrants a wishlist bug ;-)
<ogra_> ppisati, oh ... not sure that works
<balloons> sergiusens, ack, filing
<ogra_> ppisati, i always build a fresh iimage
<ogra_>  sudo ./ubuntu-device-flash core 16 --channel edge --kernel pc-kernel_4.4.0-31_amd64.snap --gadget pc --os ubuntu-core -o test.img
<sergiusens> balloons right now you can check in .local/share/snapcraft if really needed
<ogra_> with the last u-d-f from mvo's dir
 * ppisati tries to build a new image, can you try to install your pc-kernel snap like a regular snap pkg?
<ali1234> okay so they are actually in /lib/firmware/4.4.0-1009-raspi2/device-tree/ - ie it is versioned
<ogra_> ah, right
 * ogra_ is spoiled by the handy find command :)
<balloons> sergiusens, I see a headers.yaml and parts.yaml in there.
<ogra_> ppisati, i can, but i doubt that works correctly
<ogra_> ppisati, since  the magic for the bootloader wont kick in
<balloons> sergiusens, I know I asked earlier, but I realized I can't have lp build my snap until the godeps plugin is released. So now I really am curious when it might land :-)
<elopio> balloons: yakkety today, xenial as soon as the SRU process is done.
<balloons> elopio, can you land the SRU on a one day turnaround?
<balloons> do you have an exception to do so?
<ppisati> ogra_: guess what if i create an img instead of trying to install a new kernel on it?
<elopio> balloons: yes. I takes me like a couple of hours to test it, and then it's a matter of finding a free person with permissions.
<ppisati> it works
<ogra_> indeed :)
<mup> PR snapd#1660 opened: add vim swap files to gitignore <Created by tych0> <https://github.com/snapcore/snapd/pull/1660>
<ogra_> i dont think sideloading kernels is actually supported atm ... ask mvo though
<balloons> elopio, as soon as it's in proposed, let me know. That's enough to get the lp builders working for me
<elopio> balloons: I think you could do a trick to get it earlier. The launchpad page has a ppa textfield, I wonder what happens if you put https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily in there.
<ppisati> the kernel.img patch for snapcraft is still needed, so i'll fill a bug for that
<balloons> elopio, hmm. good idea, I'll try
<ali1234> what should i put in the version field in my snaps?
<ali1234> the version of the software i am snapping? something else?
<ogra_> ppisati, that should be tied to "type: kernel" not actually too the kernel plugin though ... (then it helps me too)
<ogra_> ali1234, whatever you want ... its just a string after all and does not have any effect
<ali1234> anything at all?
<ogra_> i think you need something in there, else snapcraft complains
<ali1234> is the version used for anything?
<ogra_> but you could put "foobar" in
<ogra_> no
<ali1234> like does it have to always be increasing?
<ogra_> no
<ali1234> if i make a newer release how does it know?
<ogra_> the store (or snapd for sideloaded snaps) cares for that via the revision
<ogra_> in case of sideloading it just is $current_revision+1 ...
<ali1234> so i can just leave it on version 0 forever?
<ogra_> in case of store packages the revision gets created at snap upload time
<ogra_> yeah
<ali1234> can i make snapcraft automatically fill the version field with something from the build?
<ogra_> not atm
<ali1234> okay, 0 it is then
<ogra_> i think there is work being done that you can use the version from snapcraft.yaml inside your build
<ali1234> that's not very helpful
<ogra_> (so the other way around)
<ogra_> it totally is :)
<balloons> elopio, that works for me, ty :-)
<ogra_> for me at least
<ali1234> the build knows what version it is
<elopio> balloons: cool. Remember to remove it after the release :)
<ogra_> i.e. building a kernel snap i need the version in certain moments ... today i have to grep snapcraft.yaml for that
<ali1234> i don't know before i run snapcraft what revision it is going to pull from git... or the repo
<ogra_> having a var for it is massively helpful here
<ogra_> right
<ogra_> in that case it isnt
<ogra_> as i said, the other way around than what would be helpful for you
<ali1234> what is the proper syntax for multiline texts in yaml?
<ppisati> sergiusens: lp1611435
<ppisati> bug1611435
<ppisati> bah
<ali1234> nvm found it
<ogra_> bug 1611435
<mup> Bug #1611435: kernel plugin: hard link vmlinuz to kernel.img <Snapcraft:New> <https://launchpad.net/bugs/1611435>
<ogra_> :)
<ogra_> ppisati, just confirming, sideloading my kernel snap in the working image gets me the initrd prompt on reboot
<ppisati> ogra_: that's the stuff i was hitting today
<ogra_> yeah
<ogra_> not sure if it is a bug though
<ogra_> assertions might make sideloading kernels impossible by design
<ogra_> (they havent landed yet)
<ppisati> ogra_: and how do i test a new kernel? from a developer POV
<ogra_> you have to ask the core team
<ogra_> you build an image
<ogra_> probably niemeyer or pedronis can chime in here ... they are the assertion masters and can tell if sideloading kernels will be possible in the future
<ogra_> (i would assume not, but that you can always build a local image using your local kernel snap instead ... for testing)
<ali1234> is there a plugin that dumps a text fragment from the yaml into a file?
<ali1234> like copy except without needing a separate file
<ali1234> would be handy for the one-line wrappers that literally everything seems to need
 * ogra_ would just use the make plugin and a makefile
<balloons> kyrofa, can you take a look at this error lp got trying to build juju using the godeps plugin? https://launchpadlibrarian.net/277983664/buildlog_snap_ubuntu_xenial_amd64_juju_BUILDING.txt.gz
<ali1234> a makefile is an external file
<kyrofa> balloons, looking now
<kyrofa> balloons, eww
<kyrofa> balloons, I have no clue what that means. Do we have any bzr people around here?
<kyrofa> sergiusens, you're a bzr pro, aren't you?
<niemeyer> ogra_, ppisati: Loading of custom kernel snaps will definitely possible.. we'll probably tweak settings to account for the fact the kernel is unknown, but the system should boot fine
<ogra_> niemeyer, ok
<ogra_> ppisati, then it is a bug, please file one
<sergiusens> kyrofa balloons feels like a proxy issue, cjwatson might now better
<kyrofa> balloons, looks like cjwatson and ogra_ may have had a conversation about this already
<balloons> it feels like it's something to do with the builder
<cjwatson> kyrofa: no, that was entirely unrelated
<ogra_> kyrofa, about what exactly ?
<niemeyer> ogra_, ppisati: Note that I'm literally reviewing mvo 's prepare-image *today*, so the fact you even have an image is surprising!  ;)
<ogra_> niemeyer, we have a hacked up u-d-f that mvo provided last week
<ogra_> (which is supposed to give us everything but model assertions afaik)
<cjwatson> balloons: can you make it use lp:tomb etc. rather than https://launchpad.net/tomb ?
<ogra_> (with a ton of hardcoding atm)
<niemeyer> ogra_: I know, I'm half-joking.. just pointing out there are obviously missing pieces, and we're working on fundamental parts of that problem still
<ogra_> :)
<cjwatson> ah, or in fact ogra_ and I did talk about this some days ago I think
<balloons> cjwatson, umm, yes I can do that, assuming nothing breaks
<kyrofa> ogra_, cjwatson bug #1606203
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203>
<kyrofa> balloons, ^^
<ogra_> niemeyer, that is why i summoned you since i wasnt sure it is desired behaviour ;)
<cjwatson> yeah, I remember now
<niemeyer> ogra_: I don't think it gives you everything either, but mvo would know more
<ogra_> yeah
<ogra_> it fakes a lot
<cjwatson> so I don't remember whether lp: will actually help
<balloons> hmm
<cjwatson> this is basically a bzr bug but there's a not very difficult workaround possible in snapcraft
<ogra_> by just using git ? :)
<kyrofa> ogra_, hahaha
<cjwatson> oh, hmm
<cjwatson> in this case bzr is being called via godeps, right?
<balloons> get those dependencies out of launchpad
<balloons> cjwatson, yes
<cjwatson> so unsetting https_proxy would be problematic
<cjwatson> who said out of launchpad?  we have git suppor t:P
<cjwatson> *support
<balloons> ohh true..
<ogra_> :D
 * balloons notes it's building from a git repo on lp
<cjwatson> I don't really know what to do here; maybe somebody has to spend a few days fixing bzr
<cjwatson> you might be able to bribe vila perhaps
<mup> Bug #1611444 opened: Cannot share a namespace between apps in a SNAP <Snappy:New> <https://launchpad.net/bugs/1611444>
<balloons> I'm guessing I can get those maintainers to host outside of bzr. But I suppose we should update the bug report with the latest thoughts
<niemeyer> joc_: one last comment on snapd#1644 and we can merge it
<mup> PR snapd#1644: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1644>
<mup> PR snapcraft#714 closed: Release changelog for 2.14 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/714>
<morphis> ogra_: installing my own kernel snap always gives me : https://paste.ubuntu.com/22818250/
<morphis> is that expected?
<mvo_> ogra_: sorry, I miss a bit of context here, whats the issue? that sideloading kernels fails currently? I think this is just a bug ("just" ;)
<ogra_> mvo_, sideloading kernels on amd64 works but leaves you with a broken boot on reboot
<ogra_> what morphis sees above is presumably the same issue you fixed today and unrelated to what ppisati has
<morphis> ogra_, mvo_: so that is expected :-)
<ogra_> morphis, there was a bug in general with arm kernels that left me with broken images ... mvo_ fixed that one today ...
<morphis> ogra_: in snapd or u-d-f?
<ogra_> snapd
<ogra_> (but thats the same here ... )
<morphis> :-)
<morphis> means building a new core snap with new snapd or do we have daily's already?
<SamYaple> sergiusens: https://github.com/snapcore/snapcraft/pull/657
<mup> PR snapcraft#657: Add constraints to python2 plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/657>
<SamYaple> it really doesnt like that PR, tests still havent run
<mup> PR snapd#1657 closed: tests: add udev rules spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1657>
<mup> PR snapd#1659 closed: wrappers: ensure services have a valid SNAP_USER_DATA dir <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1659>
<ogra_> morphis, i dont think the fix was released yet
<morphis> ogra_: I really had waiting for things ..
<morphis> mvo_: https://people.canonical.com/~mvo/all-snaps/16/ubuntu-device-flash is the latest u-d-f to generate images?
<ogra_> yep
<mvo_> morphis: yeah, anything missing or not working?
<morphis> mvo_: no, just trying it :-)
<morphis> ogra_: you have the cmdline handy you use for the all-snap pi3 image?
<ogra_> mvo_, do we have a snapd with your fix for the arm kernels yet ?
<morphis> ogra_: did this https://bazaar.launchpad.net/~morphis/+junk/pi2-kernel-snap/revision/38 dirty thing to include the wifi firmware now
<ogra_> udo ../ubuntu-device-flash core 16 --channel edge --kernel pi2-kernel --gadget pi3 --os ubuntu-core -o test.img
<ogra_> something like that
<ogra_> heh
<ogra_> you could just unsquashfs ... cp the files in there and run snapcraft snap squashfs-root
<morphis> yeah
<joc_> niemeyer: thanks, made the change
<niemeyer> joc_: Just saw it, thanks!
<niemeyer> joc_: Just waiting for tests to go green
<morphis> ogra_: getting: cannot use "pi3", must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" "pi2" "canonical-dragon" "dragonboard" "beagleblack"]
<morphis> looks like my u-d-f version isn't correct
<mvo_> morphis: hm, i may need to build an update
<ogra_> weird
<ogra_> oh
<ogra_> right, you telegrammed me the fixed version
<morphis> ah :-)
<morphis> suspected sth like this
<morphis> mvo_: you should create a devmode snap with that u-d-f version
<sergiusens> SamYaple travis is just busy this time it seems
<mvo_> morphis: heh, good idea
<morphis> mvo_: if you don't have time let me do that
<morphis> but that would semi-solve this situation :-)
<morphis> mvo_: if you have a branch somewhere we can build from that
<mup> PR snapd#1405 closed: interfaces: add zigbee-dongle interface <Reviewed> <Created by jocave> <Closed by jocave> <https://github.com/snapcore/snapd/pull/1405>
<mvo_> morphis: excellent idea
<morphis> mvo_: so if you want I can cerate a snapcraft.yaml quickly tomorrow morning
<morphis> mvo_: https://code.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image is the right one?
<mvo_> morphis: sounds great, if there is no ubuntu-device-flash by tomorrow then that is very welcome
<mvo_> morphis: sorrect
<mvo_> morphis: correct
<ahasenack> hm, does it make sense to include manpages in a snap?
<ahasenack> the system-wide man command obviously can't see them
<lazyPower> ahasenack - i dont think so, i would think we want the snaps to be as slim as possible, especially considering the system man command cannot find the shipping manpages
<lazyPower> its extra bits on disk with no use unless you're bundling man with your snap
<ahasenack> yeah
<ahasenack> how do I include some files that "make install" didn't install? using filesets?
<kyrofa> ahasenack, essentially create a new part that uses the same source and use the copy plugin to get them where you want them
<ahasenack> ok, let me try that
<morphis> mvo_: ok, created it now
<morphis> just one issue:
<morphis> simon@nirvana ~/Work/ubuntu/snappy/hwe/ubuntu-device-flash (master*) $ ubuntu-device-flash.run
<morphis> Unknown command `/snap/ubuntu-device-flash/x1/bin/ubuntu-device-flash'. Please specify one command of: core, personal, query or touch
<mvo_> morphis: woah!
<mvo_> morphis: \o/
<morphis> somehow the flags parser gets sth wrong
<morphis> the problem are not the wrapper scripts
<morphis> if I take just the binary I get the same problem
<mvo_> morphis: sounds like its in the code :/
<morphis> $ prime/bin/ubuntu-device-flash
<morphis> Unknown command `prime/bin/ubuntu-device-flash'. Please specify one command of: core, personal, query or touch
<mvo_> morphis: what ubuntu-core snap do you have? the latest from edge?
<morphis> mvo_: https://code.launchpad.net/~morphis/+git/ubuntu-device-flash/+ref/master
<morphis> mvo_: you mean on my desktop?
<morphis> mvo_: fetching the newest now
<morphis> mvo_: but that one doesn't fix the "unknown command" problem
<mvo_> morphis: I have a look after dinner
<morphis> mvo_: thanks
<morphis> mvo_: same result with a manual: go build -v -a launchpad.net/goget-ubuntu-touch/ubuntu-device-flash
<mvo_> morphis: it rings a bell, it smeels like a bug in snap-exec, but I'm not sure right now why its happening, this got fixed a while ago
<stokachu> so im getting a failure attempting to create a directory in $SNAP_DATA
<stokachu> https://www.irccloud.com/pastebin/8XM5AilK/
<stokachu> not sure why since $SNAP_DATA should be writeable
<ogra_> stokachu, for daemons ...
<ogra_> (which run as root by default)
<morphis> mvo_: possible just an old version of the flags GO lib?
<SamYaple> sergiusens: for the python plugins, requirements.txt and constraints.txt can both be http url addresses rather than files. I can write a quick'n'dirty check to not run it through os.path.join if it begins with http[s]:// , does that seem useful?
<ogra_> stokachu, do you try to use it for a binary a user runs manually ?
<SamYaple> or do we not want http[s]:// addresses?
<mvo_> morphis: maybe, if you share your snapcraft.yaml (or create a PR) I will debug
<stokachu> ogra_: would be nice if the docs mentioned that
<stokachu> ogra_: yes this is a binary
 * mvo_ dinner
<ogra_> stokachu, for user invoked binaries you want $SNAP_USER_DATA instead
 * ogra_ takes a bit from mvo_ to check if he actually tastes like dinner
<ogra_> *bite
<morphis> mvo_: https://code.launchpad.net/~morphis/+git/ubuntu-device-flash/+ref/master
<stokachu> so the frontpage on snapcraft.io doesn't mentioned SNAP_DATA being for daemons only
<ogra_> stokachu, well, it is under /var/snap...
<morphis> mvo_: do you think we're ok with uploading the snap as canonical?
<stokachu> ogra_: why does that matter if the app is self contained?
<mvo_> thanks morphis
<morphis> or do we want to keep it personal to not make it official?
<mvo_> morphis: a good question, its probably ok for now and has the advantage that we can collaborate on it easily
<morphis> yeah
<ogra_> stokachu, well, /var is usually not writable for normal users ...
<stokachu> ogra_: but the app is self contained
<ogra_> nno matter what the snap does in a subdir there
<stokachu> lol that is so confusing
<ogra_> even with confinement the normal filesystem permissions apply
<stokachu> if the app is self contained why do we care where it is
<lazyPower> is there something special I have to do to set the GOPATH and GOROOT tha ti'm not seeing?  http://paste.ubuntu.com/22824346/   -  heres my snapcraft.yaml, and it looks pretty straight forward, however my build fails gloriously
<stokachu> ogra_: so you're saying the app is not fully self contained?
<ogra_> stokachu, now thats a question for someone from the core snap team :) it could indeed be anywhere (theoretically)
<ogra_> wht does the confinement have to do with it ?
<stokachu> if the app is confined why does it matter where the "host" allows you to write data
<ogra_> if you invoke a snap binary as stokachu, it runs under your system credentials ... if you have permission to write to a dir the binary will too
<mmcc> hi ogra_: re stokachu's question about SNAP_DATA, I think the distinction wrt SNAP_USER_DATA needs to be clarified in the docs on snapcraft.io - mind if I try to paraphrase you in a bug on that site?
<ogra_> if you dont, the binary wont either
<ogra_> mmcc, sure. go ahead
<stokachu> ogra_: wouldnt i have permission to write to /var in a snap?
<ogra_> (feel free to just copy/paste the conversation above )
<stokachu> isn't it just /var with regards to the snap itself?
<ogra_> stokachu, try "touch /var/foo.txt" ... what do you get ?
<stokachu> that fails  obviously
<ogra_> well, and why would a binary you run as stokachu on your machine have any more permissions on /var ?
<stokachu> why is snap trying to access /var on the host system??
<ogra_> (unless it would be suid root)
<stokachu> rather than within it's confined space
<ogra_> because it needs to store stuff in some writable space
<ogra_> for processes that run with high enough permissions variable data goes to /var
<lazyPower> http://paste.ubuntu.com/22824864/ -- here's the build log from my attempt to build with the snapcraft.yaml from above ^
<ogra_> for processes that run under user permissions such data usually goes to some place in /hoem/$USER
<ogra_> *home
<ogra_> snappy doesnt change that fundamental setup ...
<ogra_> you cnt write in /snap/$yourapp ... simply because that is a readonly squashfs
<stokachu> yea i just figured you would keep it all within /snap
<ogra_> so you need places where your variable data can go ... which is either $HOME/snap/$yourapp for user related data ... or /var/snap/$yourapp for system related data
<lazyPower> and since i biffed on the OG paste, here's a re-paste with all the build log info i was trying to send in teh first place:  http://pastebin.ubuntu.com/22825168/
<mup> PR snapcraft#495 closed: Add in command to list-parts, this could be useful to further enhanceâ¦ <Created by cwayne18> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/495>
<ogra_> lazyPower, perhaps someone with some go background can help you here ... i.e. kyrofa ?
<kyrofa> Sad... I'm known as the guy with the go background?
<kyrofa> Where has my life gone?
<ogra_> lol
 * ogra_ hugs kyrofa 
 * kyrofa hugs ogra_ back
<kyrofa> Okay lazyPower what's going on here...
<lazyPower> kyrofa - we're looking into snapping up kubectl, the kubernetes client side application to communicate with a k8s api server
<lazyPower> kyrofa - i'm not a gopher, but i'll give it a whirl :) I'm not sure if this is due in part to a misconfigured go workspace, or if i need to send some additional love to the snapcraft yaml to get it to properly fetch those godeps
<kyrofa> lazyPower, offhand the yaml looks fine
<kyrofa> Let me look at this project a little closer
<ahasenack> I'm kind of regretting adding perl to my snap, but now I'm curious why this isn't working: http://pastebin.ubuntu.com/22825810/
<ahasenack> the file seems to be there at the right place
<ahasenack> the only interesting thing maybe is that the 5.22 component of that path is a symlink:
<ahasenack> lrwxrwxrwx 1 root root 6 Mar 13 08:54 /snap/bip/x4/usr/lib/x86_64-linux-gnu/perl/5.22 -> 5.22.1
<ahasenack> are there issues following symlinks? Maybe something security related?
<ogra_> ahasenack, heh
<ogra_> https://code.launchpad.net/~ogra/+junk/ircproxy
<ogra_> (i havent found the time to port it to series 16 yet ... there is a 15.04 snap in the store)
<ahasenack> ogra_: I'm using this as a learning experiment
<ogra_> if you want to use perl, you need to bend the module paths and stuff
<ahasenack> why? Because of the symlink?
<ahasenack> or something deeper
 * ogra_ digs ... my very first snap from two years ago actually did that but i dont have a public branch 
<kyrofa> lazyPower, sorry, I made the poor choice of working from a remote cabin this week. The power just went off for a few seconds so the router had to reboot :P
<lazyPower> \o/ power issues
<kyrofa> lazyPower, anyway, this looks like it's due to the use of absolute imports, which means you need to use the go-importpath
<lazyPower> if its any consolation, i found that snapcraft fetch would tank my network connection from my VM, so i'm now doing this in the cloud
<kyrofa> Hahaha
<lazyPower> kyrofa - ok, that go-importpath that i have commented in teh yaml doesn't look correct?
<lazyPower> everything i'ms eeing from the dump of errors is referencing k8s.io
<kyrofa> lazyPower, indeed, that's odd eh?
<kyrofa> lazyPower, but yeah, check this out: https://github.com/kubernetes/kubernetes/blob/master/cmd/kubectl/kubectl.go
<kyrofa> lazyPower, so try making go-importpath: k8s.io/kubernetes
<lazyPower> 1 sec, standup, sorry
<kyrofa> lazyPower, no problem, give that a try when you're able and get back to me
<ogra_> ahasenack, phew, that took some digging http://paste.ubuntu.com/22826676/
<ogra_> ahasenack, look at the "start: " line
<ogra_> nowadays you would prefix perl/ with $SNAP ... but that should give you an idea
<ahasenack> I see
<ahasenack> thanks
<ogra_> (the perl installation in that snap obviously lived under perl/ ... so "perl/usr/bin/perl -I perl/usr/lib/arm-linux-gnueabihf/perl/5.20.1 -I perl/usr/share/perl/5.20.1" execs the interpreter with the -I paths for modules)
<ogra_> hmm, i should actually re-vive that snap and finally control my heating with it
<ogra_> (and replace the 10 year old fhem machine that does it today with a snap based one)
<lazyPower> kyrofa - aha! new errors, much progress, such excitement
<mmcc> hi folks, simple question - the first body paragraph of snapcraft.io currently describes snaps as "secure, sandboxed, *containerised* applications" -- does anyone else think that saying "containerised" might be confusing for people new to snaps, who might know more about docker/lxd containers?
<qengho> Docker doesn't own containerhood.
<qengho> The bug in that sentence is the missplled "containerised".
<SamYaple> qengho: "Docker doesn't own containerhood."
<SamYaple> that gave me a good chuckle
<SamYaple> i want to paste that in #docker
<SamYaple> mmcc: saying something is "containerised" is refering to the linux tech behind containers (namespaces) which snappy absoletly does use.
<SamYaple> i agree though, it tends to feel more like packaging than "containers" if you are familiar with docker
<qengho> We need a de-brainwashing paragraph, maybe.
<SamYaple> i wont argue with that qengho
<mvo_> morphis: I can reproduce it, checking but it smells like the binary is broken for some reason, running /snap/ubuntu-device-flash/x1/bin/ubuntu-device-flash directly gives the same error
<mmcc> SamYaple: thanks - I should've looked further into how the confinement was implemented. I just skimmed some of the snapd core docs, but didn't see references to user namespaces
<sergiusens> qengho isn't containerised correct in the UK? Kind of like color colour?
<qengho> sergiusens: Yes, okay in the UK. At least, no one will send you to gaol.
<SamYaple> mmcc: im not sure if user namespaces are actually
<stokachu> https://www.irccloud.com/pastebin/2EcZeSdH/
<stokachu> anyone seen anything similar to ^?
<stokachu> if i try to load the yaml outside of the snap it loads just fine
<mmcc> As far as placing a claim on the term 'containerised', I will just say that if you want to describe it that way, it might be best to clarify it in contrast to LXD and docker containers.
<kyrofa> stokachu, any chance that has something to do with locales?
<SamYaple> mmcc: and lxc and rkt? what about openvz?
<SamYaple> mmcc: a comparison page seems useful, but its certainly not a requiremetn everytime you say "container"
<stokachu> https://www.irccloud.com/pastebin/YylwY9Rq/
<stokachu> kyrofa: ^ is my locales inside the snap
<stokachu> maybe i need to force LC_ALL?
<mmcc> SamYaple: sure, I wouldn't want to include a big feature comparison matrix in the first paragraph. If the consensus here is that it's not confusing, I won't push it further
<kyrofa> stokachu, I suspect you've hit bug #1576411
<mup> Bug #1576411: UTF-8 is not very well supported inside snaps <xenial> <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1576411>
<kyrofa> Which isn't titled all that well
<mup> PR snapcraft#718 opened: Fix bug lp:1586546 allowing setup.py to work on some projects <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/718>
<kyrofa> stokachu, essentially, the environment in which your snap runs says it wants en_US. The desktop has the en_US locale, but the environment in which the snap runs does not
<stokachu> ah ok
<kyrofa> stokachu, there are some workarounds on the bug
<stokachu> yea im going to try those now
<kyrofa> stokachu, in one of my snaps I work around it by setting LC_ALL=C.UTF-8
<kyrofa> stokachu, but obviously that's a limited "fix"...
<stokachu> yea im going to start with a wrapper that has that in there
<stokachu> see if it gets us passed this
<sergiusens> josepht seems something went wrong with your merge/rebase https://github.com/snapcore/snapcraft/pull/658
<mup> PR snapcraft#658: parser - Return non-zero code for wiki errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/658>
<josepht> sergiusens: argh! I'll fix it.
<mup> PR snapd#1658 closed: partition: fix cleaning of the boot variables on the second good boot <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1658>
<ahasenack> is there the concept of applying patches or fixes to a source tarball in snappy, before building?
<ahasenack> or running a simple command, that would also work
<lazyPower> kyrofa : I think that sorted me, there's additional work to be don ehere, like not building the whole k8s ecosystem in this snap, but that fully sorted me. Can i ask how you came ot the conclusion thats what i needed to do?
<kyrofa> lazyPower, excellent!
<kyrofa> lazyPower, I knew because of the errors you were getting-- complaining about not being able to find itself, but in a different path
<kyrofa> lazyPower, particularly one that wasn't github was easy to spot
<josepht> sergiusens: that PR should be fixed now
<lazyPower> ah ok, so this really is golang internals
 * lazyPower makes a note to read a book on go
<kyrofa> lazyPower, indeed. go directly maps import "foo/bar/baz" to filepath positions: $GOPATH/foo/bar/baz
<mup> PR snapd#1644 closed: interfaces/builtin: add gpio interface <Reviewed> <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1644>
<niemeyer> joc_: ^^^
<dpb1> ahasenack: I'm interested as well, did you find anything out?
<lazyPower> kyrofa - any chance we can pass extra env vars during the build? i'm not seeing that outlined in the tour
<ahasenack> no, not yet
<lazyPower> kyrofa - we should be able to pair this down with a WHAT=kubectl, then firing off the go build, and i think that sorts it
<ahasenack> dpb1: so far I'm leaning towards forking the tarball, and shippig the files I need as I need them
<ahasenack> shipping*
<dpb1> :(
<kyrofa> lazyPower, no, no build environment yet, but it's on the roadmap
<dpb1> that sounds less than ideal
<ahasenack> maybe "organize" in my case
<ahasenack> a fancy name for "rename"
<kyrofa> ahasenack, no, no concept of patching yet. But it's pretty easy to create your own local plugin for snapcraft to use if you want to go down that path
<sergiusens> elopio 2.14 is in -proposed https://launchpad.net/ubuntu/+source/snapcraft/2.14
<elopio> sergiusens: ok. I'll it while it syncs in the archive
<elopio> *eat :D
<ahasenack> the copy plugin, looks like it doesn't create directories
<kyrofa> ahasenack, it should be. How are you using it?
<ahasenack> kyrofa: I have a conf file at the same directory level as my snapcraft file, I want it to land in etc/squid-deb-proxy/squid-deb-proxy.conf
<ahasenack> ah, let me try something
<kyrofa> ahasenack, try:
<kyrofa> files:
<kyrofa>   conf-file: etc/squid-deb-proxy/
<kyrofa> I suppose that would actually be:
<kyrofa> files:
<kyrofa>   squid-deb-proxy.conf: etc/squid-deb-proxy/
<ahasenack> it worked now, but I might still be doing it wrong
<ahasenack>        files:
<ahasenack>           squid-deb-proxy.conf: /etc/squid-deb-proxy/squid-deb-proxy.conf
<ahasenack> before I had
<ahasenack>        files:
<ahasenack>           squid-deb-proxy.conf: /etc/squid-deb-proxy
<ahasenack> and that just created the file under that other name
<ahasenack> maybe because I missed an ending /
<ahasenack> let me try with an ending /
<wililupy|travel> Is the snappy store down?
<stokachu> kyrofa: yea putting LC_ALL=C.UTF-8 in a wrapper fixed the encoding error
<kyrofa> stokachu, good deal. That's annoying, I'm sorry. Please say something on that bug
<stokachu> will do, thanks
<ahasenack> I'm getting a file not found error at the and of the snapcraft run, yet the file seems to be right where it needs to be
<ahasenack> [Errno 2] No such file or directory: '/usr/sbin/squid'
<ahasenack> http://pastebin.ubuntu.com/22836747/
<kyrofa> ahasenack, seems it's actually looking in /usr/sbin/squid (on the system)
<ahasenack> yeah, I feared that
<kyrofa> ahasenack, is there a symlink pointing there perhaps?
<ahasenack> here I was trying to use squid as a run-time dependency (stage-packages), instead of building it as part of the snap
<ahasenack> since this snap is really just a set of config files for squid (squid-deb-proxy)
<ahasenack> kyrofa: no, no symlink
<kyrofa> ahasenack, hmm... odd that it's happening in prime, then
<kyrofa> ahasenack, all that happens there is file migration and ldd crawling
<kyrofa> ahasenack, do me a favor and run snapcraft -d
<ahasenack> sure
<kyrofa> ahasenack, so you can get a trace
 * ahasenack cleans first
<kyrofa> No no
<kyrofa> Just the prime would be fine, you don't need to clean completely
<kyrofa> Though it doesn't hurt anything
<ahasenack> yeah, it's quick
<kyrofa> Good deal
<ahasenack> kyrofa: it's during ldd of sorts: http://pastebin.ubuntu.com/22837387/
<kyrofa> ahasenack, mind if I take a quick look at your yaml?
<ahasenack> not at all
<ahasenack> but keep in mind it's super work in progress, I'm trying things
<ahasenack> building it step by step
<kyrofa> ahasenack, haha, don't worry, I won't judge ;)
<kyrofa> ahasenack, you should see some of mine
<ahasenack> kyrofa: http://pastebin.ubuntu.com/22837563/
<kyrofa> There it is
<ahasenack> it needs to be a daemon, etc
<kyrofa> ahasenack, your command is specifically trying to call /usr/sbin/squid
<kyrofa> ahasenack, which doesn't exist
<ahasenack> hm
<ahasenack> how do I reference it, should I drop the first /?
<ahasenack> or just let PATH sort it out?
<kyrofa> Sure, try that. Most of the bins are added onto the PATH by snapcraft, but I'm not sure it'll grab the sbin
<kyrofa> sergiusens, should snapcraft add the sbin directories to PATH as well?
<kyrofa> I don't think it does, but should it?
<Ursinha> ahasenack: what I'm doing is to define the command as only foo if foo can be found in the path (in the case /snap/bin)
<ahasenack> kyrofa: dropping the starting / worked
<ahasenack> kyrofa: thx
<kyrofa> ahasenack, good deal, though it might break when you actually run it since it may depend upon cwd
<ahasenack> yeah
<kyrofa> ahasenack, worst case, you ship a shell script that runs $SNAP/usr/sbin/squid
<ahasenack> kyrofa: I will need a shell script anyway I think, because squid needs to create those cache directories when first started on a fresh system
<kyrofa> Ah yes
<ahasenack> kyrofa: something the deb initscript does
<kyrofa> Then do that. And put it in bin
<ahasenack> kyrofa: here I will have to adapt
<kyrofa> Then make your command just call that (it'll be in PATH)
<mup> Bug #1611068 opened: 401 when trying to install hello-world <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611068>
<kyrofa> ahasenack, I'm still lobbying for an install hook that can be used to setup that initial stuff
<ahasenack> kyrofa: I missed a way to patch or run commands pre-build time (from the top of my huge 1,5 day experience with snappy)
<mup> Bug #1611493 opened: No TTY in snaps. <landscape> <Snappy:New> <https://launchpad.net/bugs/1611493>
<ahasenack> but it's an experiment, and I don't want to be biased by the deb packaging world
<ahasenack> which is much harder I think
<mbruzek> Can anyone help me with how to install snapcraft from source?
<mbruzek> I found this url: https://github.com/snapcore/snapcraft/blob/master/HACKING.md
<mbruzek> I ran ./setup.py install without any luck.
<mbruzek> That step failed
<mbruzek> error: The 'requests' distribution was not found and is required by snapcraft
<kyrofa> mbruzek, you can just run it: <snapcraft>/bin/snapcraft
<kyrofa> mbruzek, no need to install
<mbruzek> kyrofa: I installed in in a virtual env, and when I run $snapcraft build, I got an error that "yaml" could not be imported
<mbruzek> so pip3 install pyyaml
<mbruzek> then I ran snapcraft build again
<mbruzek> jsonschema was missing
<mbruzek> pip3 install jsonschema
<mbruzek> now I get the following
<mbruzek> http://pastebin.ubuntu.com/22839534/
<mbruzek> I tried it another way and got an import error on progress bar: http://pastebin.ubuntu.com/22839680/
<mbruzek> When running it from the github cloned location
<lazyPower> mbruzek - i took the liberty of filing: https://bugs.launchpad.net/snapcraft/+bug/1611498
<mup> Bug #1611498: snapcraft fails install using virtualenv instructions <Snapcraft:New> <https://launchpad.net/bugs/1611498>
<stokachu> mbruzek: you have python3-progressbar installed?
<mbruzek> stokachu: Yes. I tried to show that in the pastebin
<stokachu> mbruzek: you aren't running a venv or anything are you?
<mbruzek> stokachu: Yes I was trying to keep this in a virtualenv, following the HACKING.md instructions
<stokachu> mbruzek: try pip install progressbar2
<stokachu> pip3
<mbruzek> stokachu: Yep, I got past that one now, but ImportError: No module named 'magic'
<stokachu> hmmmm
<mbruzek> There are a ton of magic packages, not sure which one
<stokachu> yea hmm
<mbruzek> You know I _already_ did "pip3 install -r requirements"
<stokachu> mbruzek: try pip3 install pymagic
<kyrofa> stokachu, mbruzek sorry, internet flaked again. Anyway yeah, the setup.py needs some love. We don't typically use it (we just run straight from src)
<mbruzek>   Could not find a version that satisfies the requirement pymagic (from versions: )
<mbruzek> No matching distribution found for pymagic
<mbruzek> How can I install from source?
<kyrofa> mbruzek, you don't need to-- you can run straight from it
<kyrofa> mbruzek, just run the bin/snapcraft executable
<kyrofa> Add it to your PATH if you want
<stokachu> kyrofa: he's in a venv and missing some modules it seems
<sergiusens> kyrofa maybe, but we will be adding the environment keyword soon
<mbruzek> kyrofa: I __changed__ the code and want to run with some modifications
<stokachu> mbruzek: oh pip3 install libmagic
<mbruzek> stokachu: That install worked, but still getting the same import error
<mbruzek> ImportError: No module named 'magic'
<kyrofa> mbruzek, I'm not sure where we're missing each other, here :P . If you run bin/snapcraft it'll use your changes
<stokachu> mbruzek: try python-libmagic and python-magic
<mbruzek> kyrofa: Yep I get that.
<mbruzek> kyrofa: I am running it this way....
<mbruzek> (matt3) mbruzek@warhorse:~/workspace/snapcraft/kubectl$ ~/workspace/git/snapcraft/bin/snapcraft build
<mbruzek> ~/workspace/git/snapcraft/bin/snapcraft is giving me these import error
<mbruzek> s
<stokachu> mbruzek: s/and/or
<kyrofa> mbruzek, _not_ in the venv? Just install the stuff in debian/control
<mbruzek> and pollute my development system?
<mbruzek> kyrofa: I thought the beauty of python was we could use virtualenvs
<mbruzek> Plus the HACKING.md file told me to
<stokachu> mbruzek: maybe it's one of these? :X https://www.irccloud.com/pastebin/Vi90hD8i/
<mbruzek> stokachu: yeah I found  a ton of them when searching too
<mbruzek> which is why I am asking here
<kyrofa> mbruzek, just trying to give some suggestions. Please feel free to develop with whatever setup you desire
<mbruzek> kyrofa: Not trying to be critical, I am just following the instructions
<mbruzek> stokachu: http://pastebin.ubuntu.com/22841208/  the install of the python magic worked, or maybe it did not
<stokachu> mbruzek: :(
<stokachu> couldnt we just make a snap out of snapcraft? :)
<mbruzek> stokachu: Wouldn't that be nice
<sergiusens> kyrofa does this ring a bell http://paste.ubuntu.com/22841604/ ?
<kyrofa> sergiusens, sounds like some environment variables aren't being set correctly
<kyrofa> sergiusens, to redirect it
<kyrofa> sergiusens, rosdep init isn't being run with sudo since it should be writing into parts/foo/rosdep or something like that
<sergiusens> kyrofa I did not touch the catkin plugin though
<kyrofa> sergiusens, looking a little closer
<kyrofa> sergiusens, huh... yeah ROSDEP_SOURCE_PATH is set in _Rosdep._run
<kyrofa> sergiusens, from what I've seen so far, I have no explanation why your branch is causing that to be weird
<kyrofa> sergiusens, and you can duplicate locally?
<sergiusens> kyrofa with my branch, yes
<sergiusens> kyrofa the paste is from a local run
<sergiusens> well define local ;-)
<kyrofa> sergiusens, and what you've pushed is up-to-date?
<kyrofa> sergiusens, heh, not adt :P
<sergiusens> kyrofa yes, up2date
<kyrofa> Well, CI-driven, I guess
<kyrofa> sergiusens, okay let me take another pass here...
<sergiusens> kyrofa and working off of a server lately
<kyrofa> sergiusens, yeah
<lazyPower> kyrofa - i don tknow what sorcery you have lead us to, but that bin/snapcraft does do what you claim it does despite my best efforts at being a skeptic
<kyrofa> lazyPower, hahaha
<kyrofa> sergiusens, dude, this makes no sense
<kyrofa> sergiusens, let me try this myself...
<kyrofa> sergiusens, ... this works for me ...
<kyrofa> sergiusens, that was a pull, right?
<kyrofa> sergiusens, right at the beginning of the pull?
<sergiusens> kyrofa yes, pull indeed
<kyrofa> sergiusens, yeah... it works here
<kyrofa> But you're seeing that in CI as well?
<sergiusens> kyrofa yeah
<kyrofa> sergiusens, x, right? Not y?
<sergiusens> yeah, always X, x-men here
<sergiusens> although I think I am generation y
<kyrofa> :P
<sergiusens> kyrofa so my branch works for you?
<kyrofa> sergiusens, oh... wait I'm stupid
<sergiusens> kyrofa why is that?
<kyrofa> sergiusens, testing again
<sergiusens> not running from the branch?
<kyrofa> sergiusens, maaaybe
<kyrofa> sergiusens, there it is
<sergiusens> kyrofa the solution to the problem?
<sergiusens> official word was we could break this before it spread
<cwayne> sergiusens: hey, would i need to be part of any specific team to add a part to the wiki?
<sergiusens> but getting everyone on the same page might be worthwhile
<kyrofa> sergiusens, you're far too optimistic. No, but now I can see the breakage at least :P
<sergiusens> cwayne logged in and an ubuntu member I guess
<sergiusens> cwayne if you want to be on the good side of things, don't use subparts
<sergiusens> cwayne https://github.com/snapcore/snapcraft/pull/705
<mup> PR snapcraft#705: parser - Remove namespacing and subparts <Created by josepht> <https://github.com/snapcore/snapcraft/pull/705>
<cwayne> didn't even know subparts was a thing
<sergiusens> cwayne keep it that way!
<cwayne> will do :)
<qengho> SUBPARTS WAT?
<kyrofa> sergiusens, does this change any of the apt params other than the caching one?
<jhobbs> this python application i'm trying to snap wants to play in "/home/jason/.testrepository" - is there some interface to allow this? or will the application need to be changed to work elsewhere?
<sergiusens> kyrofa there are no apt params changed really
<sergiusens> jhobbs does it repect xdg?
<jhobbs> i don't know
<kyrofa> sergiusens, something is clearing out the rosdep folder in your branch
<kyrofa> sergiusens, I suspect https://github.com/snapcore/snapcraft/pull/677/files#diff-e8d25d56f5ed513cad7c55002a709f32R178
<mup> PR snapcraft#677: playing with caching <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/677>
<kyrofa> sergiusens, that directory is used for more than just debs in the case of rosdep
<sergiusens> kyrofa ah, that can be it, let me refine this
<kyrofa> sergiusens, we might be able to change that a bit on the catkin side, too
<kyrofa> sergiusens, but yeah
<ahasenack> I have maybe a basic question,
<sergiusens> kyrofa no, deleting rootdir was an experimental shortcut (well I assumed the directory was private to this, but fine ;-) )
<ahasenack> but for the app inside the snap, it's not in a chroot, right?
<ahasenack> I mean, /etc/foo for the app is the real /etc/foo in the system where it's running, if referenced like that?
<kyrofa> sergiusens, heh
<kyrofa> ahasenack, indeed
<ahasenack> kyrofa: hm
<ahasenack> kyrofa: that can get interesting in the case of a config file that includes other config files
<ahasenack> using absolute paths
<kyrofa> ahasenack, indeed, absolute paths means it makes some assumptions about how it's packaged
<ahasenack> kyrofa: is the absolute path that begins with /snap "stable", as long as it uses the "current" symlink? Is that a reasonable alternative?
<ahasenack> like /snap/squid-deb-proxy/current/etc/squid-deb-proxy/squid-deb-proxy.conf
<kyrofa> ahasenack, I'm probably not the best person to ask, there. zyga and slangasek probably have some feelings on that matter
<ahasenack> that conf file includes other conf files in that directory, I'm not sure I can use relative paths
<ahasenack> kyrofa: cool, thx
<kyrofa> ahasenack, and these conf files are dynamically generated? Or do you ship them yourself?
<ahasenack> I ship them
<kyrofa> ahasenack, can they accept environment variables?
<ahasenack> doubtful
<ahasenack> maybe in my script that starts the service I could generate them dynamically, if it comes to that
<ahasenack> adjust paths according to some $SNAP_var, then start the service
<ahasenack> sounds overkill at first
<ahasenack> but I'm new here :)
<kyrofa> ahasenack, hmm. Yeah I had to do that for redis, check this out: https://github.com/kyrofa/nextcloud-snap/blob/master/src/redis/scripts/start-redis-server
<ahasenack> SNAP_DATA is the versioned system-wide writable directory, right?
<ahasenack> not the user one, and not the common one that is unversioned
 * ahasenack getting used to these names
<kyrofa> ahasenack, indeed this might be helpful: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
<ahasenack> kyrofa: I see you had to do that exactly because it's versioned, so it's kept on upgrades
<ahasenack> and indeed, I will have to do that too, if I want to preserve config files during upgrades
<kyrofa> ahasenack, nah, I did that because I didn't want to write the config file anywhere
<ahasenack> kyrofa: but there is a current symlink in there too
<ahasenack>  /var/snap/<name>/current
<kyrofa> ahasenack, indeed, that is SNAP_DATA
<ahasenack> hm, no, my SNAP_DATA uses the revision
<ahasenack> export SNAP_DATA="/var/snap/squid-deb-proxy/x3"
<ahasenack> (from the bin script)
<kyrofa> ahasenack, right, current points to the currently active revision
<kyrofa> ahasenack, you shouldn't need to care about that though, no?
<ahasenack> but there is no var with "current" in it
<kyrofa> ahasenack, true. Why do you need that?
<kyrofa> Oh, to write to config files?
<ahasenack> kyrofa: I hope not. I hit this now because (I think) I added squid to the snap by installing the package in stage-packages, instead of building it
<ahasenack> I think when I build it with snapcraft, it will take care to put the config files in the right places, but I'm not there yet
<ahasenack> via ./configure --things I mean
<kyrofa> ahasenack, snapcraft won't put anything in SNAP_DATA and its ilk
<ahasenack> that got me thinking about config files
<ahasenack> hm, not even --sysconfdir=DIR
<ahasenack> so that will be /etc by default
<ahasenack> in my mind, SNAP_DATA would be the place for system-wide configuration files that you want preserved across upgrades, among other things
<ahasenack> stuff that would normally be in /etc
<ahasenack> and SNAP_USER_DATA for files that are usually ~/.something
<ahasenack> because the script generated by snapcraft does export HOME="$SNAP_USER_DATA"
 * ahasenack reads that askubuntu question now
<ahasenack> yeah, that's it
<ahasenack> it just doesn't mention /etc specifically, or system config files in general
<kyrofa> ahasenack, it's impossible for snaps to pollute other snaps, so you can really use those directories for whatever you wish
<kyrofa> ahasenack, but people use them differently, and they're runtime-specific things, so snapcraft doesn't deal with them
<kyrofa> snapcraft just gives you a squashfs image
<slangasek> ahasenack, kyrofa, zyga: my feeling is that for the cross-distro story, /snap is a bit of a time bomb because it's not in the FHS, it's unrealistic to think it'll be in the FHS before the heat death of the universe, and there have already been examples given of it conflicting with local usage
<kyrofa> slangasek, agreed
<kyrofa> ahasenack, so probably try to avoid if at all possible
<ahasenack> slangasek: so how should I best handle config files? Where should they live?
<slangasek> ahasenack: I assume they live in the snap and you should locate them relative to the $SNAP_* variables?
<ahasenack> slangasek: that's doable, but SNAP_* has the revision in it, not "current"
<ahasenack> slangasek: am I fine in using "current" instead of the revision?
<slangasek> I don't have a convenient solution for this for software that has to hard-code a path at build time
<ahasenack> slangasek: yeah, sorry, I'm just looking for best practices
<slangasek> hmm, I think by definition the running instance is always "current"
<slangasek> in which case, "yes" that should work :)
<slangasek> however, current is always a symlink to the revision one
<ahasenack> I just checked the vars set by the /snap/bin/foo wrapper, they have the revisions
<slangasek> so if you're resolving the variable at runtime, that should also still work?
<ahasenack> slangasek: my specific problem is a config file that includes other config files by absolute path
<slangasek> ah
<ahasenack> slangasek: yeah, but I will have to regenerate that config then
<ahasenack> everytime I start the service
<slangasek> I see
<slangasek> yes, I think "current" is doable there
<ahasenack> unless "current" was stable enough, then I could just use "current" in the path
<ahasenack> but still, I would then have /snap/foo/bar in there, hardcoded...
<ahasenack> not pleasant
<sergiusens> kyrofa just for the kicks, look at distutils.file_util.copy_file ;-)
<jhobbs> is there a way to provide a file by default in /home/<user>/snap/<snap>/<rev> ?
<kyrofa> sergiusens, I've seen it, but didn't want to introduce another dependency
<sergiusens> kyrofa could get rid of link_or_copy and is part of the stdlib already
<kyrofa> sergiusens, I seem to remember people saying to avoid distutils for some reason...
<ahasenack> slangasek: kyrofa thanks guys
<kyrofa> Yeah slangasek thanks for jumping in
<mup> Bug #1611526 opened: temp directories not deleted when snap fails to start <lxd> <Snappy:New> <https://launchpad.net/bugs/1611526>
<mup> Bug #1611530 opened: can't install devmode snap from store <landscape> <Snappy:New> <https://launchpad.net/bugs/1611530>
<jdstrand> noise][: hi! can someone a store pull for review tools r705? fyi, I'm going to have another commit tomorrow morning, but r705 has (among other things) the update to allow the tools to not block uploads of the ubuntu-core snap
<jdstrand> cc ogra_ ^
<jdstrand> noise][: I guess it is fairly urgent due to auto-uploads
<noise][> jdstrand: EOD here, but i'll see if there's anyone that can pick that up
<noise][> jdstrand: likely will be tomorrow morning though
<EAbdel> Hi
<EAbdel> IS there any one ?
<EAbdel> please i have an issue
<EAbdel> about snapcrafts
<EAbdel> hiiiiii
<qengho> That solved itself.
<sergiusens> kyrofa yes, you should use setuptools, https://docs.python.org/3/library/distutils.html
<EAbdel> Hi please, is there any one i can talk to ?
<mup> PR snapd#1661 opened: Remove documentation on a 'private' flag to /v2/find that doesn't seeâ¦ <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1661>
#snappy 2016-08-10
<mup> Bug #1603838 opened: Interface for reading files in /usr <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1603838>
<mup> Bug #1594324 opened: pulseaudio interface needs access to pulse libraries <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1594324>
<skiboy> So I feel uncertain about how apps/snap packages will improve the Linux desktop.  Could someone share their reasoning on why apps will improve the user experience?
<skiboy> Let's take the example of a security update.  Let's say that OpenSSL has a critical vulnerability, and 5 different apps are all bundled with it.  Wouldn't this mean that all 5 apps need to be updated?
<skiboy> Especially in third-world countries, where every byte of data matters, wouldn't this be detrimental?
<skiboy> Do apps actually help the user? Are they worth the bloat? Are they just an easy way out for application developers?
<Son_Goku> skiboy, in many ways, it's essentially an easy way out
<Son_Goku> one of the things that the snap/flatpak/appimage/etc model does is return the full burden of security to the upstream author
<Son_Goku> the blame lays squarely on them
<skiboy> And I can see the hassle in packaging something for so many different distros...  But I feel it will be to the detriment of the end user...
<Son_Goku> packaging for Linux doesn't have to be so hard, and indeed there are several people working on this problem all the time
<Son_Goku> but at the end of the day, most people like to cling to enough differences that unifying the underlying architecture that allows for software delivery is not likely to happen
<Son_Goku> everyone is guilty of this, even myself
<Son_Goku> in many ways, the development of flatpaks, snaps, appimages, etc. is a signal that we've all thrown in the towel
<Son_Goku> after nearly 20 years of trying to push for the better model, most of the folks who are commercially invested in Linux are trying to switch to the Windows model of software distribution
<skiboy> how frustrating
<Son_Goku> nearly a decade ago, the Linux Standards Base attempted to solve this problem, but some distros never fully agreed to implement the specifications
<Son_Goku> the Debian family was a rather big opponent back in the day
<skiboy> but snap packages aren't replacing apt-get, right?  I can still easily update my system with one command?
<Son_Goku> eventually, it will
<Son_Goku> at least, in Ubuntu
<Son_Goku> the Ubuntu Snappy Core is the prototype of the future of Ubuntu
<mup> PR snapd#1662 opened: client, cmd, daemon, osutil: support --yaml and --sudoer flags for create-user <Created by mwhudson> <Conflict> <https://github.com/snapcore/snapd/pull/1662>
<mup> PR snapd#1663 opened: disallow create-user on classic systems <Created by jaymell> <https://github.com/snapcore/snapd/pull/1663>
<mup> PR snapcraft#719 opened: support dest-subdir on dump plugin <Created by ycheng> <https://github.com/snapcore/snapcraft/pull/719>
<liuxg> didrocks, I just tried to search for "mysql" and I find a few of them. I want to know how mysql and tomcat are installed in the snap. I think it could be good to have them preassembed somewhhere..
<didrocks> liuxg: it seems you just volounteered :)
<liuxg> didrocks, frankly, I have not tried that yet. I do not know the process for it.
<didrocks> liuxg: maybe a good opportunity to explore and learn IMHO
<mup> Bug #1611639 opened: docs/package-names.md is out of sync with the rest of the project <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1611639>
<mup> Bug #1611641 opened: Running "snap" should produce more helpful output <Snappy:New> <https://launchpad.net/bugs/1611641>
<mup> PR snapd#1656 closed: snap: do not sort the result of `snap find` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1656>
<morphis> ogra_: not sure, but a sudo /snap/bin/ubuntu-device-flash core 16 --verbose --channel edge --kernel pi2 --gadget pi3 --os ubuntu-core -o test.img gives me an image where the bootloader can't read the initrd
<morphis> ogra_: getting https://paste.ubuntu.com/22893704/
<ogra_> morphis, well, is there an initrd.img file in / of your boot partition ?
<ogra_> (that should be in a subdir named like the kernel snap)
<morphis> ogra_: https://paste.ubuntu.com/22896672/
<ogra_> morphis, yeah, thats what i thought ...
<ogra_> u-d-f issue
<morphis> hah
<morphis> mvo: ^^
<ogra_> (it shoudl copy the initrd and vmlinuz in place and set the snap_kernel var)
<mvo> morphis: please try "--kernel pi2-kernel"
<ogra_> ooh
<ogra_> i missed that one ...
<ogra_> it should error out there though
<mvo> morphis: ideally the code would verify that but I'm not sure its worth the work (given that u-d-f will go away soon)
<mvo> ogra_: yeah, see above
<ogra_> yeah
<morphis> ogra_: was using what you gave me yesterday :-)
<ogra_> mvo, hmm, dont you need --devmode for the snapped u-d-f ? (your mail doesnt mention it)
<morphis> ogra_: you need devmode, yes
 * ogra_ cant imagine we have loop device access
 * ogra_ answers the mail
<ogra_> sigh
<ogra_> and i'm blind !
 * ogra_ blushes
<mup> PR snapd#1664 opened: integration-tests: add update-rollback stress tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1664>
<zyga> http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
<zyga> :-)
 * zyga -> coffee 
<mvo> ogra_: heh, no worries
<morphis> ogra_, mvo: if I use a local kernel snap do I just have to pass --kernel my.snap or a absolute path?
<ogra_> both should work (if the snap is in the same dir at least)
<timothy> zyga: new failures on snapd-git on archlinux
<timothy> http://pkgbuild.com/~tredaelli/logs/snapd-git/x86_64.log
<zyga> timothy: looking
<zyga> timothy :thanks, I will report this
<zyga> timothy: I reported https://bugs.launchpad.net/snappy/+bug/1611706
<mup> Bug #1611706: Test suite failures on Arch <Snappy:New> <https://launchpad.net/bugs/1611706>
<mup> Bug #1611706 opened: Test suite failures on Arch <Snappy:New> <https://launchpad.net/bugs/1611706>
<zyga> dholbach: hey
<dholbach> hey zyga
<zyga> dholbach: I'd like to start publishing content on snapcraft.io
<dholbach> I don't have access to the page
<zyga> dholbach: how can I do that?
<dholbach> zyga, https://github.com/ubuntudesign/snapcraft.io
<zyga> dholbach: thank you
<dholbach> anytime
<morphis> mvo, ogra_: ok, using a local kernel snap doesn't wor
<morphis> it don't end up on the boot partition
<ogra_> morphis, hmm, i thought mvo had added a fix for that yesterday
<morphis> doesn't look like
<joc_> zyga: nice blog post, thorough and useful i think
<mvo> morphis, ogra_: sorry, did not manage that yet, will look after lunch, please keep poking, the world is a busy place for me currently, sorry for that
<ogra_> no worries
<morphis> mvo: np
<mwhudson> ogra_: hey hey did you do that thing about making paths writable yet?
<ogra_> mwhudson, bah, crap ... i forgot it ...
<ogra_> mwhudson, that was /var/lib/console-conf and /etc/netplan ?
<mwhudson> ogra_: yes
 * mwhudson checks his "things he was going to bug ogra_ about list"
<mwhudson> ;-p
<ppisati> does u-d-f accept local files for the gadget / core snap? i know it does the the kernel snap...
<ppisati> and where can i download those files?
<mwhudson> you can extract them from a downloaded image ;-)
 * mwhudson unhelpfuls
<zyga> joc_: thank you :)
<ppisati> i mainly want to avoid: 1) download time 2) development clashes (e.g. something changes in edge that breaks up my stuff)
<ogra_> ppisati, it used to, but i'm not sure about the current state, it changed a lot the last days
<mvo> I look into the kernel sideload bug now
<mvo> ogra_: sideloading amd64 kernel works, is that a problem with pi2 (uboot) only?
<ogra_> mvo, yeah, i only saw it on amr builds (dragonboard and pi2/3)
<ogra_> *arm
<mvo> aha, ok
<ogra_> [    6.377542] smsc95xx v1.0.4
<ogra_> [    6.435520] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:c9:2b:03
<ogra_> [    7.901142] smsc95xx 1-1.1:1.0 enxb827ebc92b03: renamed from eth0
<ogra_> hmm
<ogra_> ppisati, any idea why the kernel would ignore net.ifnames=0 ?
<ppisati> ogra_: it's not the kernel
<ppisati> ogra_: hold on
<ppisati> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1593379
<mup> Bug #1593379: systemd 229-4ubuntu6 ignores net.ifnames=0 on USB or /etc/udev/rules.d/80-net-setup-link.rules being a /dev/null symlink <verification-failed> <systemd
<mup> (Ubuntu):Fix Released by pitti> <systemd (Ubuntu Xenial):In Progress by pitti> <systemd (Debian):Fix Released> <https://launchpad.net/bugs/1593379>
<ppisati> fixed in yakkety, still open in xenial
 * ppisati goes for lunch, back later
<ogra_> ppisati, ah ... well, that wasnt systemd but the smsc95xx driver printing the above
<ogra_> would systemd change it back ? (i would expect the kernel to not rename it at all)
<mvo> ppisati, ogra_: can you please try r4 of u-d-f from the store? it should fix the kernel sideload bug
 * ogra_ just tested the pi3 image with the new ubuntu-core from the store, looks fine 
<ogra_> i'll test a sideloaded kernel next
<ogra_> hmmm .... hmmmmm ...
<ogra_> morphis, did you try to build an armhf snap for u-d-f too ?
<ogra_> i wonder if you could build an image on the pi or dragonboard on an all-snap system :)
<josepht> sergiusens: didrocks brings up a good point in the sub-parts mailing list thread regarding older versions of snapcraft needing the still namespaced part names.  I think we can work around it by having the namespaced part names explicitly in the wiki and updating the origins.
<josepht> i.e. parts: [desktop/gtk2, desktop/gtk3, ...] and another entry with "parts: [desktop-gtk2, desktop-gtk3, ...]
<jdstrand> noise][: that's fine. I've got a meeting in a few minutes but suspect that next commit in less than 2 hours
<morphis> ogra_: no :-)
<liuxg> has anyone ever snapped tomcat into snap?
<ogra_> yeah, in 15.04 ... not sure if there is a s16 snap
<liuxg> ogra_, would you please show me the project? thanks
<ogra_> no idea where that lives
<liuxg> ogra_, a customer is using apache, tomcat, mysql, java for a server on ubuntu core. I am trying to find out how we can package the stuff into a snap.
<ogra_> i only remember someone packaging it
<ogra_> iirc either asac or lool
<liuxg> asac, lool, have you every packaged tomcat into a snap? a customer is trying to build a apache server with tomcat. thanks
<ogra_> (probably asking on gitter in the snappy-playpen channel makes more sense though )
<ogra_> didrocks, ^^^ didnt mosquitto use tomcat ?
<ogra_> iirc you worked on that
<liuxg> ogra_, mosquitto does not use tomcat, it uses MQTT to do thaht.
<didrocks> yeah, only mqtt AFAIK
<liuxg> didrocks, ogra_,  if tomcat is not in the official ubuntu archive, we cannot install it directly from the debian packages, right? we have to use the source code to build it, right?
<ogra_> well, arent there tarballs with binaries ?
<ogra_> i see tomcat in the archive though
<ogra_> 7 and 8
<ppisati> ogra_: the kernel is printing it because the rename function (dev_change_name()) is invoked through an ioctl()
<ppisati> ogra_: if you try with the xenial's release systemd package, you won't hit that
<didrocks> liuxg: you can always at worse download the content of binaries and uncompress while using the copy/dump plugins
<ogra_> ppisati, ok, i was just curious since that happens before init even runs i think
<liuxg> didrocks, the thing is that we need to copy to the right place in the snap. we have to know where the files should go.
<lool> liuxg: Hi, here's the sample snap I did with Tomcat a long while ago https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml
<lool> liuxg: it is not very fancy, but it worked; let me know how it goes
<didrocks> liuxg: indeed
<lool> liuxg: I'm travelling this week, so a bit hard to reach
<liuxg> lool, many thanks for your help. I will take a look at it. Have a good trip!
<lool> thanks
<liuxg> didrocks, lool, strange, "dump" is not listed when I use "snapcraft list-plugins". is this a bug?
<lool> liuxg: It's the first time I hear about it; I think this example was modified when this plugin landed in snapcraft
<didrocks> liuxg: it will be available with the next version of snapcraft (which is in -proposed right now)
<ogra_> dump is the new name for the copy plugin i think
<liuxg> didrocks, my current snapcraft version is 2.13.1, what will be next release?
<ogra_> .14
<liuxg> ogra_, do you mean that I can use "copy" to replace it?
<ogra_> yes
<ogra_> or just look at an older version of the branch :)
<liuxg> ogra_, then in the example https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml#L17, it does not specify the destination, will it work?
<liuxg> ogra_, sorry, this is the line https://github.com/snapcore/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml#L22
<liuxg> didrocks,  do you know how I can make use of the latest snapcraft (-proposed)? my snapcraft is from the stable channel so far.
<didrocks> liuxg: you can just wget the package on launchpad and install it manually
<didrocks> with dpkg -i
<ogra_> liuxg, this is the snapcraft.yaml from before the rename (seems it wasnt only copy that got renamed to dump) https://github.com/snapcore/snapcraft/blob/f0a19ebccfa3f0502b792095d4b0edae4e04eb68/demos/tomcat-maven-webapp/snapcraft.yaml
<liuxg> didrocks, OK, I will have a try. thanks. previously, I just directly installed it from the source, and I messed up everything.
<didrocks> yeah, you can go this way, it's safer :)
<liuxg> ogra_, thanks for your help. yeah, it looks different
<liuxg> lool, what is the purpose of the file ".travis.yml" in the project https://github.com/lool/snappy-mvn-demo/blob/master/.travis.yml? thanks
<lool> liuxg: it's to trigger a travis build when something gets pushed or when a pull request is made
<lool> liuxg: see travis-ci.org
<lool> liuxg: I dont think it worked correctly for that project though
<liuxg> lool, I just tried to compile it, it failed. I compiled it using the its previous version http://paste.ubuntu.com/22912200/
<liuxg> lool, the error message is like http://paste.ubuntu.com/22912252/
<liuxg> didrocks, where did you find the binaries for the snapcraft on launchpad? I found a site https://launchpad.net/snapcraft/trunk, but I did not get the release file? thanks
<didrocks> liuxg: https://launchpad.net/ubuntu/+source/snapcraft/2.14/+build/10589180
<didrocks> see "built files"
<liuxg> didrocks, yes, I saw it. thanks
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo snap refresh --channel=beta ubuntu-device-flash
<ogra_> error: cannot refresh "ubuntu-device-flash": snap "ubuntu-device-flash" has no updates available
<ogra_> mvo, ^^^ did you publish the new u-d-f ?
<ogra_> oh
<ogra_> ignore that ... needs --devmode too
<ogra_> uuuh
<ogra_> error: cannot perform the following tasks:
<ogra_> - Setup snap "ubuntu-device-flash" (4) security profiles (cannot setup apparmor for snap "ubuntu-device-flash": cannot load apparmor profile "snap.ubuntu-device-flash.ubuntu-device-flash": cannot load apparmor profile: exit status 10
 * didrocks was going to suggest that
<ogra_> apparmor_parser output:
<ogra_> )
<mvo> ogra_: wuut
<mvo> ogra_: how can apparmor fail for a devmode snap :(
<mvo> ogra_: if the file is still there, can you pastebinit ? (I guess its not :/
<ogra_> now ... that didbnt go so well ... calling u-d-f anyway after that error had-locked my machine
 * ogra_ removes and re-installs
<ogra_> that looks better
<liuxg> lool, ogra_, I have upgraded my snapcraft to 2.14, but I still get the same error when I tried to build the tomcat demo example https://github.com/snapcore/snapcraft/tree/master/demos/tomcat-maven-webapp. the error message is like http://paste.ubuntu.com/22913740/, do I miss anything there?
<jdstrand> mvo: note, the apparmor policy is wholly present with --devmode-- all that is different is the complain flag
<zyga> jdstrand: hey, I posted another interface article on my blog, feedback welcome :-)
<zyga> mvo: hmm?
<mvo> ogra_: that is still pretty terrible, this is snapd 2.11?
<mvo> jdstrand: oh, ok
<zyga> mvo: devmode can still fail, it's just another profile
<jdstrand> mvo: so if there is an error in the policy then it will fail to parse. also, if this is done on a machine that doesn't have an updated parser for newer rules (like unix), it will fail to parse
<mvo> zyga: see above, ogra_ installed an update of ubuntu-device-flash and the install aborted with an exit 10
<ogra_> ogra@anubis:~/datengrab/images/snappy$ snap --version
<ogra_> snap    2.11+0.16.04
<ogra_> snapd   2.11+0.16.04
<ogra_> series  16
<ogra_> ubuntu  16.04
<jdstrand> is this by chance running on a trusty machine?
<ogra_> nope
<ogra_> there is no snap on trusty :)
<mvo> jdstrand: well, I did not do anything with the policy
<mvo> jdstrand: this is a quick-n-dirty devmode snap of ubuntu-device-flash
<zyga> mvo: we should see exactly what apparmor_parser said
<ogra_> it worked fine after snap remove and snap install
<zyga> ogra_: can you pastebin the profile from /var/lib/snapd/apparmor/profiles please
<ogra_> zyga, i fear thats gone now ... but indeed i can
<zyga> mvo: maybe there's a bug in some of the intefaces that causes this to fail
<ogra_> (i mean the broken one is gone)
<ogra_> http://paste.ubuntu.com/22914044/
<zyga> ogra_: this looks like a efault template
<mvo> ogra_: anything in snap changes or snap change XX (nr) that might give a clue?
<mvo> zyga: it is
<zyga> ogra_: if that fails then all the snaps will fail the same way
<zyga> ogra_: can you install hello-world snap please?
<ogra_> mvo, http://paste.ubuntu.com/22914167/
<jdstrand> artmello_: hey
<artmello_> jdstrand: hey
<ogra_> zyga, installed
<jdstrand> artmello_: are you planning on snapping the thumbnailer service or assuming it will be present on the system?
<mvo> jdstrand: does exit-code 10 has any meaning (context is http://paste.ubuntu.com/22914167/)
<artmello> jdstrand: snapping it. I have an untested snap of it but I was thinking about fixing the interface first
<artmello> jdstrand: but I can start using the snap thumbnailer during these tests
<jdstrand> artmello: ok, so 'classic' is the traditional Ubuntu desktop system and interfaces that access those services need different policy than those that are services as snaps
<artmello> jdstrand: ok
<jdstrand> artmello: because you are snapping thumbnailer, you don't have to worry about classic at this time
<artmello> jdstrand: right
<jdstrand> artmello: so, yes, do the ConnectedSlotAppArmor stuff I mentioned in privmsg. when testing, you'll want to remove the thumbnailer service deb and install the thumbnailer service snap
<jdstrand> (so the snap can bind to the dbus interface, etc)
<jdstrand> artmello: but you'll need to adjust the thumbnailer to not do the security label check any more (since it doesn't have to with interface connections)
<artmello> jdstrand: right, will change thumbnailer as you suggested
<jdstrand> artmello: (or again, if sharing codesbases for the thumbnailer with click, short-circuit with the snap. check I mentioned)
<artmello> jdstrand: ok, thx! I undertood it better now. Will apply the changes and see how it goes
<zyga> ogra_: hmmmm so if that doesn't fail then I have no idea
<zyga> ogra_: is the problem reproducible?
<ogra_> zyga, dunno, i can tell you the next time i upgrade something in --beta with --devmode from the store i guess
<kyrofa> ogra_, mvo can we release the OS snaps into staging as part of our process as well?
<sergiusens> josepht we can just pick up another cache file
<jdstrand> mvo: '10' doesn't mean much to me. that seems to be ECHILD...
<ogra_> perhaps mvo can upload a no-change snap of u-d-f so i can re-test (though perhaps that should wait til after the meeting, i dont want to have to hit the reset button during meeting :))
<ogra_> kyrofa, i just released a set today
<jdstrand> what is the snap.yaml of ubuntu-device-flash?
<kyrofa> ogra_, ah, into staging as well?
<mvo> kyrofa: staging? you mean candidate?
<kyrofa> mvo, no, the staging server
<kyrofa> mvo, staging store, whatever it's called
<mvo> kyrofa: oh, sorry. hm, yes we can :)
<ogra_> kyrofa, i'm waiting for jdstrand's review tools fix to land to see how the auto-landing goes ... but i think we still need to manually hit the publish button
<kyrofa> mvo, if you setup a clean machine and point it to staging, there's no OS snap to pull down so you can't install anything :)
<kyrofa> mvo, easy workaround, but if that's something we can automate it'd be useful
<mvo> kyrofa: I shared it with you, you can now just download it directly from the real store and upload to staging as you need
<kyrofa> mvo, ah, super useful thank you!
<mvo> kyrofa: +1 for automation, we are still working on that, its still very manual right now (manual approve, manual publish, lots of button clicks :/
<ogra_> kyrofa, i guess thats also a cjwatson question if LP can offer uploads to staging
<ogra_> (if there is a way i'll happily add a parallel ubuntu-core build, thats trivial)
<ogra_> reading pi2-kernel_x1.snap/kernel.img
<ogra_> ** Unable to read file pi2-kernel_x1.snap/kernel.img **
<ogra_> reading pi2-kernel_x1.snap/initrd.img
<ogra_> ** Unable to read file pi2-kernel_x1.snap/initrd.img **
<ogra_> Bad Linux ARM zImage magic!
<kyrofa> ogra_, oh, good point
<ogra_> mvo, ^^^
<cjwatson> ogra_: only from LP staging
<ogra_> ah, well, then i should be able to set something up (i have to check if i still have staging access)
<cjwatson> staging access isn't a special thing
<cjwatson> but it does require a separate staging SSO account
<cjwatson> and staging LP isn't up all the time
<mvo> ogra_: can you run "file pi2-kernel_x1.snap/kernel.img" (and the same for initrd.img?
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/
<ogra_> unset
<ogra_> ogra@anubis:~/datengrab/images/snappy$
<mvo> ogra_: and what commandline did you use? I will try to reproduce
<ogra_> same issue as before
<mvo> ogra_: hm, hm
<ogra_> and no kernel/initrd in system-boot at all
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo /snap/bin/ubuntu-device-flash core 16 --channel edge --gadget pi3 --kernel pi2-kernel_4.4.0-1019-raspi2_armhf.snap --os ubuntu-core -o test-pi3.img
<ogra_> that was what i used for building ... the kernel was manually downloaded from the store
<mup> PR snapcraft#719 closed: support dest-subdir on dump plugin <Created by ycheng> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/719>
<stokachu> is network-control the only plug i need so that my snap can create a network bridge?
<ogra_> well, you probably also want to use thenetwork .. so the "network" plug would also be handy in that case
<stokachu> ok, problem is when i set those 2 and attempt to run my snap it just errors with "Bad system call"
<stokachu> this is running in strict mode
<stokachu> https://www.irccloud.com/pastebin/F04R1oh6/
<stokachu> thats my log output
<jdstrand> stokachu: assuming this is amd64, you need network-bind (scmp_sys_resolver 49 shows as bind)
<jdstrand> stokachu: no if you aren't actually binding to a network port, then the network-control interface should probably include bind
<jdstrand> s/no/now/
<stokachu> jdstrand: yea im just creating a bridge for my lxd containers to use
<jdstrand> stokachu: can you file a bug and add the 'snapd-interface' tag with a simple reproducer for needing bind?
<stokachu> jdstrand: sure thing
<jdstrand> stokachu: and mention the workaround is to use 'network-bind'
<jdstrand> stokachu: thanks! :)
<stokachu> jdstrand: np, building now and testing to make sure it won't fail
<sergiusens> elopio do you want to tackle https://bugs.launchpad.net/snapcraft/+bug/1611498 ?
<mup> Bug #1611498: snapcraft fails install using virtualenv instructions <Snapcraft:Triaged> <https://launchpad.net/bugs/1611498>
<sergiusens> next week
<sergiusens> or maybe josepht as you got this going in the first place ^
<stokachu> jdstrand: cool! works
<josepht> sergiusens: I can take care of that
<josepht> elopio: ^
<liuxg> sergiusens, I just tried to build the demo example at https://github.com/snapcore/snapcraft/tree/master/demos/tomcat-maven-webapp, there was an error. I do not know how to correct the problem for it. I have upgraded my snapcraft to 2.14 already. thanks
<jdstrand> stokachu: nice! :)
<dragly> is http://search.apps.ubuntu.com down?
<ppisati> Getting details for ubuntu-core
<ppisati> Expecting value: line 1 column 1 (char 0)
<ppisati> ...
<ppisati> snapcraft just returned this while trying to fecth ubuntu-core
<OerHeks> dragly, there is an update going on, launchpad is down too.
<ogra_> ppisati, funny error ... and so descriptive :P
<dragly> OerHeks: Okay. Thanks :)
<ppisati> ogra_: :(
<ppisati> i hope is connected to the lp / store/ etc downtime
<ogra_> ppisati, thats the kernel plugin trying to get the initrd from the store ?
<ahasenack> is it true you cannot snap an app that starts as root and then drops its privileges?
<ppisati> ogra_: yep, to download the ubuntu-core snap i think
<ahasenack> I'm checking https://developer.ubuntu.com/en/snappy/build-apps/debug/#common-problems
<ahasenack> the switch from root to unprivileged user (or any other user) is blocked?
<ogra_> ahasenack, where to would it drop its privs ?
<ogra_> there are no users
<ahasenack> is that the reason?
<ahasenack> or is the set?uid call blocked?/
<ogra_> asnd there is no ability to create any from a snap
<ahasenack> it could be a default user from /etc/passwd
<ogra_> setuid gets stripped out by snapcraft at build time
<ahasenack> shipped in the base system
<ogra_> and daemons/services always run as root
<ahasenack> I meant the syscall, not the setuid bit on a file
<ogra_> yeah,m i think thats blocked, together with fchown and others
<ahasenack> not in the real world, there good services run as unprivileged users. I understand apparmor can confine root, sure
<niemeyer> ahasenack: A couple of aspects to that:
<niemeyer> ahasenack: snapd can easily mediate any interactions around that, including privilege dropping
<niemeyer> ahasenack: So if there are requirements, we can cook the proper interface lifting the exact allowances the application would need for doing its job
<niemeyer> ahasenack: Unfortunately and ironically, "dropping" privileges is often done with system calls that allows *gaining* privileges
<sergiusens> ppisati please log a bug for that :-)
<niemeyer> ahasenack: So although the app intent is good, relinquishing access to certain things, from a system perspective it may not be advantageous to allow even the initial phase of the application to do those actions
<niemeyer> ahasenack: So, YMMV.. I wouldn't strongly prescribe anything at this point.. I know you are very security-mindful, and if you have suggestions or would like to research about how much to give and how much to take, that'd be very welcome
<mup> Bug #1611819 opened: implement a way for daemons to play audio <Snappy:New> <https://launchpad.net/bugs/1611819>
<elopio> sergiusens: pong.
<jdstrand> ahasenack: we are going to support privilege dropping, we first need snap-confine in xenial-updates, then we'll allow something, perhaps priv dropping to 'daemon'. later we might allow requesting a uid and/or gid and dropping to that (that would be farther out)
<niemeyer> jdstrand: Nice
<jdstrand> I feel like I keep talking about snap-confine landing. fingers crossed it will be soon :)
<jdstrand> that said, I have several things on my plate to get to before that, so that's ok
<jdstrand> noise][: hey, Canonical irc seems down so mentioning here
<jdstrand> noise][: r706 is ready to pull. that, among other things, will do what ogra_ asked me to address wrt auto-approve of the ubuntu-core snap
<kyrofa> jdstrand, yep, lost it here too
<ogra_> jdstrand, that includes the confinement complaint too ?
<ogra_> (or was that not causing a block)
<jdstrand> ogra_: can you give me the link to the snap that had that?
<ogra_> if the store lets me in :P
<jdstrand> ogra_: the issue was 'confinement' not being present?
<ogra_> no, being present in a non "app" snap
<joc_> jdstrand: hi, i'm trying to confirm if the udev tagging for cgroup access is working for me as discussed yesterday, i'm finding that i get access to everything matched by /dev/** though
<ogra_> https://myapps.developer.ubuntu.com/dev/click-apps/4142/rev/176/
<mup> PR snapcraft#679 closed: add multiple generator script options to autotools <Created by apachelogger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/679>
<ogra_> jdstrand, the messages are:
<ogra_> 'confinement' should only be specified with 'type: app' lint-snap-v2_confinement_valid
<ogra_> (NEEDS REVIEW) type 'os' not allowed lint-snap-v2_snap_type_redflag
<jdstrand> ogra_: I fixed the second
<ogra_> sadly snapcraft forcefully adds "confinement: strict" to all builds regardless of type
<joc_> jdstrand: do i need to check that i have a particular version of snap-confine running?
<ogra_> can we have the first one not be a blocker ?
<jdstrand> ogra_: ok, yeah, I didn't fix the first one.
<sergiusens> ogra_ sadly there is no requirement for it to be any different either ;-)
<jdstrand> noise][: give me a few minutes for r707
<ogra_> sergiusens, well, it will make all auto uploads for os or kernel snaps fail atm
<jdstrand> joc_: use snap-confine from xenial-proposed
<ogra_> sergiusens, but yeah, it is completely ignored by snapd at install or image build time
<jdstrand> confinement makes no sense with the core snap
<sergiusens> ogra_ a requirement means that all interested members of the party should comply for things to work though ;-)
<ogra_> jdstrand, agreed, but it also doesnt do any harm since it is ignored everywhere
<joc_> jdstrand: i'm using an all-snap image to test on device
<jdstrand> I'm just saying why the test is what it is
<ogra_> jdstrand, i'd be fine with a warning as long as it doesnt block the upload
<jdstrand> ogra_: I'll fix it. I'm not saying I won't, just saying snapcraft imho shouldn't adding meaningless yaml
<ogra_> jdstrand, agreed, i blame kyrofa and sergiusens :P
<sergiusens> jdstrand ogra_ if it makes no sense a bug report is enough
<ogra_> i think i opened one
 * ogra_ goes digging
<sergiusens> ogra_ I blame you for not doing a full end to end analysis ;-)
<jdstrand> joc_: I haven't used all snaps systems in ages cause of all the churn. I don't know if it is using snap-confine or not. does /usr/lib/snapd/snap-confine exist?
<ogra_> sergiusens, bug 1607459
<mup> Bug #1607459: type:os should prevent adding "confinement" to the snap.yaml <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1607459>
<dholbach> all rightie - I call it a day - see you in two weeks! :-)
<sergiusens> kyrofa ^
<ogra_> i should change that to "os and kernel"
<sergiusens> want to take that confinement thing?
 * ogra_ hugs sergiusens 
<sergiusens> ogra_ there you go, bug only said os ;-)
<ogra_> heh
<sergiusens> ogra_ what about gadget?
<ogra_> yeah, that too i guess
<sergiusens> the kernel can have hooks
<jdstrand> well
<joc_> jdstrand: no it's not in my image
<jdstrand> it is less clear for kernel and gadget
<sergiusens> don't you think running the hooks in devmode might be a good thing?
<ogra_> i doubt we will have gadget auto-uploads though
<sergiusens> jdstrand which is why I bring it up :-)
<sergiusens> hooks change everything
<ogra_> these things are usually one-time uploads that do not change very frequently once they are stable
<jdstrand> I don't have an answer for those. my understanding is for both they may have parts that are confined
<jdstrand> at some point
<jdstrand> but I don't know the status today
<sergiusens> jdstrand also, once we have the core for say fedora, won't confinement make a little sense at least for the os snap in case the confinement part is not fully implemented
<sergiusens> but that is all zyga's grand scheme of things thing ^
<jdstrand> joc_: can you give me ~20 minutes then I can give you my full attention?
<joc_> jdstrand: sure
<jdstrand> but... ogra_ what needs to happen to make snap-confine in the core snap instead of ubuntu-core-launcher? snap-confine landing in xenial-proposed and because ubuntu-core-launcher is a transitional package it will pull in snap-confine?
<ogra_> jdstrand, we need to drop u-c-l and add snap-confine to the "seed" (which we dont really have, it is a hardcoded package list in livecd-rootfs)
<jdstrand> ogra_: I'm somewhat concerned if that is the case because snap-confine continues to not make it through SRU and joc_ and his team are going to need this for their testing
<ogra_> (bacuse you cant change seeds for released LTSes)
<jdstrand> ogra_: will that process pull in from xenial-proposed?
<kyrofa> sergiusens, sure, assign that one to me, I'll put it on my snapcraft backlog
<ogra_> you mean move it to the archive ?
<ogra_> thats an archive admin task ...
<ogra_> totally unrelated ot any seeds or dependencies
<ogra_> moving it to main once it did move to the archive proper will need a dependency ... but getting out out of proposed has nothing to do with this
<jdstrand> ogra_: no. well, I don't know. joc_ and his team will need snap-confine in the image ideally now so they can test with the real bits that will be in rtm. it is in xenial-proposed. is there a way to make that happen?
<sergiusens> kyrofa just make sure to bring up the conflicts about type: core, gadget and kernel and if confinement makes sense; also think about core coming from say another distro (think about the built-on tag we discussed in Heildelberg) and think about the fact that some cores might not implement all the confinement primitives (where in that case the core snap would be devmode I guess)
<jdstrand> ogra_: I'm talking about core snap, not classic
<jdstrand> not sure if that makes a difference
<sergiusens> kyrofa more of a research first implement later
<ogra_> jdstrand, let me check ...
<ogra_> Get:77 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main armhf snap-confine armhf 1.0.38-0ubuntu0.16.04.4 [19.6 kB]
<ogra_> https://launchpadlibrarian.net/278185694/buildlog_snap_ubuntu_xenial_armhf_ubuntu-core_BUILDING.txt.gz
<kyrofa> sergiusens, indeed, good points
<kyrofa> I'll mention in standup tomorrow
<ogra_> seems it is alreayd pulled in but someone forgot to delete an older version from the image PPA
<sergiusens> kyrofa let me just add that to the bug
<ogra_> OH, wait
<ogra_> Get:77 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main armhf snap-confine armhf 1.0.38-0ubuntu0.16.04.4 [19.6 kB]
<ogra_> yeah, it comes from porposed ... the ppa just confused me
<jdstrand> joc_: ^ perhaps you can work with ogra_ on obtaining the correct core snap?
<ogra_> joc_, jdstrand so it is in the last edge ubuntu-core
<jdstrand> ogra_: great, thanks! :)
<sergiusens> ogra_ don't log ubuntu bugs!
<sergiusens> ogra_ those get ignored by us
<ogra_> btw, daily builds and build logs are at https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core
<ogra_> sergiusens, so ignorant :P
<sergiusens> this is why we missed it
<ogra_> sergiusens, what if people follow the distro guidelines for filing bugs then ?
<ogra_> (which tell you to use "ubuntu-bug snapcraft" )
<sergiusens> ogra_ the distro guys should then link them ;-)
<joc_> jdstrand: ogok thanks, i can try and use the recent ubuntu-device-flash to spin a new image
<sergiusens> ogra_ as any other upstream
<ogra_> sergiusens, which distro guys would look at them, i dont hink anyone is subscribed to the package
<ogra_> yxou would need a responsible team that subscribes to them
<sergiusens> ogra_ and that is why so many bugs get unresolved ;-)
<ogra_> yeah
<ogra_> someone needs to take them
<dragly> zyga: I might be using it wrong, but running snapd-hacker-toolbelt.busybox ls /var/lib/snapd/lib/gl/ gives me "Permission denied". Could that be the issue, or do I have to give the snapd-hacker-toolbelt some permission before it can do ls?
<ogra_> since ubuntu users are told to zuse ubuntu-bug by all docs we have
<zyga> dragly: connect the opengl interface
<sergiusens> ogra_ in any case, if I look at the bugs on the package I see most of them are logged by distro people. All others consuming snapcraft drt ;-)
<zyga> dragly: by default it is probably off-limits
<sergiusens> ogra_ more reason to move to a snap ASAP as well ;-)
<ogra_> sergiusens, well, you should talk to foundations i guess to subscribe to the distro bugs then
<dragly> Can I do that after installing it or do I need to rebuild the snapd-hacker-toolbelt snap?
<ogra_> sergiusens, will a snapcraft snap work in classic mode on an all snap image ?
<ogra_> mvo, ^^^ do you know ?
<ogra_> (thats most likely the biggest reason to use a classic shell on an all-snap image)
<sergiusens> ogra_ nah, I'll let you do it; the package bugs are pretty much the same as someone mentioning bugs in a mailing list, forum or redit
<sergiusens> ogra_ we won't need classic
<sergiusens> ogra_ all we will need is lxd
<ogra_> ok
<mvo> sergiusens: but we can use classic until lxd is ready?
 * sergiusens is feeling feisty today
<sergiusens> mvo yeah, just like before it went away :-)
<dragly> zyga: Or is editing snaps directly in the /snap folder okay while debugging?
<mup> PR snapd#1665 opened: many: do not require root for `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1665>
<ogra_> mvo, well, i can still imagine that people using the classic shell want to use binaries from installed snaps in there, we should plan for that
<ogra_> (it isnt like we dont have everything we need in there already)
<ogra_> (but i doubt the setup is ready OOTB currently)
<mup> Bug #1611837 opened: all-snaps: Boot breaks on reset in VirtualBox <Snappy:New> <https://launchpad.net/bugs/1611837>
<mvo> sergiusens: pfffff ;)
<mvo> ogra_: the way the kernel.img/initrd.img is extracted will change soon, once that change lands we can no longer use a symlink inside the kernel, it needs to be the actual file, could you please update livecd-rootfs so that the real file is kernel.img/initrd.img and the others are symlinks?
<ogra_> mvo, well, i'll ripp all that code out of livecd-rootfs ... but yeah, i'll take it into account for the automated kernel snaps
<ogra_> mvo, do we need the versioned filenames at all then ?
<mvo> ogra_: no, it might just be nice for manual inspections
<ogra_> (i remember some requirement about matching versions in the kernel yaml spec)
<mvo> ogra_: we may need it soon, but I can can manually tweak the snaps if needed, it just needs to be there
<mvo> ogra_: kernel.yaml got killed
<ogra_> ok
<ogra_> oh ?
<ogra_> when ?
<ogra_> today ?
<ogra_> :)
<mvo> ogra_: during the heidelberg sprint, I think you were in the session ;) but maybe not, I'm not sure, its definitely in the notes
<ogra_> NO, I WASNT IN ANY KERNEL SESSION, WHEN I ASKED ABOUT IT I WAS TOLD EVERYTHING WAS DONE
<ogra_> ARGH
 * ogra_ rips caps off his kbd
<mvo> ogra_: but the kernel version and the version string in snap/meta.yaml much match (eh meta/snap.yaml)
<mvo> ogra_: uh, no need to shout
<ogra_> yeah, sorry
 * ogra_ hands out earplugs
<kyrofa> jdstrand, zyga where is the SRU bug for snap-confine?
<mvo> ogra_: aha, ok. well, I don't remember the details but I have it in the kernel/gadget.yaml notes, so less work
 * mvo switches network
<kyrofa> Jeez ogra_, take it easy
<ogra_> mvo, werll, thats a snapcraft thing, none of my code touches snap.yaml anymore ... it is all snapcraft now
<jdstrand> kyrofa: https://people.canonical.com/~ubuntu-archive/pending-sru.html
<jdstrand> kyrofa: oddly, it is listed but with no bugs
<kyrofa> jdstrand, indeed, I was just looking to subscribe to it so I knew when it made it through
<jdstrand> kyrofa: I think that is because 1.0.38-0ubuntu0.16.04.4 fixed something and it needed -v
<stokachu> so im trying to access a binary that I pull in via stage-packages and getting this error in strict mode:
<ogra_> mvo, so what exactly needs to match ... snapcraft.yaml's version vs /lib/modules/$name-$version/ ?
<stokachu> Aug 10 11:54:32 deadpool kernel: [898974.105170] audit: type=1400 audit(1470844472.128:48571): apparmor="DENIED" operation="bind" profile="snap.conjure-up.conjure-up" pid=9807 comm="juju" family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@/var/lib/juju/mutex-/store-lock"
<jdstrand> kyrofa: mvo, I see snap-confine in pending-sru has no bugs. as such it will never get attention from the sru team. I think you needed to have the changelog include pervious versions
<kyrofa> stokachu, try adding the network-bind plug
<stokachu> i have network, network-control, network-bind as my plugs
<stokachu> https://www.irccloud.com/pastebin/0qC1iYnF/
<kyrofa> Oh, /var/lib/juju, yeah
<stokachu> do i need to do plugs for the juju binary?
<jdstrand> stokachu: https://bugs.launchpad.net/snappy/+bug/1604967
<mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
<stokachu> ah :)
<jdstrand> I have a PR that is started but it got pushed behind a couple other things
<stokachu> jdstrand: ok, i can run in devmode for now
<jdstrand> yeah, was just going to suggest that
<stokachu> jdstrand: thanks, ill keep an eye on that bug
<jdstrand> mvo_: s/changelog/changes/
<dragly> Should --devmode allow a snap to access the entire system or is it still sandboxed?
<mvo_> jdstrand: sorry, I got disconnected, what did you say earlier?
<kyrofa> mvo_, you mean this?
<kyrofa> <jdstrand> kyrofa: mvo, I see snap-confine in pending-sru has no bugs. as such it will never get attention from the sru team. I think you needed to have the changelog include pervious versions
<jdstrand> s/changelog/changes/
<jdstrand> thanks kyrofa :)
<jdstrand> mvo_: that was it ^
<jdstrand> ogra_: with r707: $ PYTHONPATH=./ ./bin/click-review ../click-reviewers-tools-test-packages/ubuntu-core_176.snap
<jdstrand> ../click-reviewers-tools-test-packages/ubuntu-core_176.snap: pass
<jdstrand> ogra_: I requested a pull with the store team a moment ago
<mvo_> jdstrand: oh, ok. it has a regression anyway so I will have to do a new uplaod soonish
<jdstrand> mvo_: ok, thanks
<ahasenack> jdstrand: niemeyer: sorry, I had lunch and irc dropped
<ahasenack> good to hear something is coming
<mvo_> jdstrand: but thanks!
<ahasenack> and sure, setuid can be used to either drop or gain privileges
<jdstrand> mvo_: fingers crossed your next upload is the *one* :)
<ahasenack> I think selinux allows for an "order" of sorts here, i.e., "root" can drop to "squid" in this certain application
<ahasenack> don't know if apparmor has the same concept
<jdstrand> ahasenack: we will have something similar
<mvo_> jdstrand: yeah, snap-confine was more difficult than expected
<jdstrand> ahasenack: it doesn't (yet), but with newer snap-confine, we can do it with seccomp
<ahasenack> jdstrand: ok, so for today, the only option is to patch the app to not drop privileges?
<jdstrand> ahasenack: yes, or use devmode
<jdstrand> well, or use an unrelated interface
<ahasenack> devmode defeats the purpose I think, I'm trying to avoid it really hard
<ahasenack> patching the app might be hard too, since some go to great lengths to ensure they really dropped the privs
<jdstrand> ahasenack: devmode is meant only as a temporary thing
<ahasenack> jdstrand: is there a blueprint or bug tracking this privilege dropping work/intent?
<jdstrand> we'll allow privilege dropping. at first it will be to a fixed uid, but will expand on that
<ahasenack> that would be enough to snap this app already
<jdstrand> there is a trello card, let me check on the bug
<jdstrand> a bug
<ahasenack> since it allows configuring the user it runs as
<ahasenack> (as most do)
<jdstrand> ahasenack: bug #1581310 is in the same realm (it is for chown). if you are in trello I can add you to the card
<mup> Bug #1581310: ubuntu-core doesn't allow sed -i (fchown syscall) <snapd-interface> <snapd (Ubuntu):Triaged by jdstrand> <https://launchpad.net/bugs/1581310>
<ahasenack> jdstrand: does the card get more updates than the bug, or is it enough if I subscribe to the bug?
<jdstrand> ahasenack: subscribing to the bug would be fine. I will be fixing that bug at the same time as setuid
<ahasenack> cool, thanks
<ogra_> jdstrand, yay, thanks !
<dragly> zyga: Built ubuntu-clock-app with snapcraft now, and it works with strict confinement. Seems snapd-confine works as expected. However, the ubuntu-calculator-app does not work after installing with "snap install ubuntu-calculator-app". Trying to build it manually now.
<dragly> Yes, it works after building it manually. Any reason this should differ from installing it from the repository?
<mup> PR snapd#1661 closed: docs: private flag doesn't exist on /v2/find (it's select) <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1661>
<joc_> jdstrand: i built a new image from edge as ogra suggested and confirmed it has at least /usr/lib/snapd/snap-confine present, i'm still not getting the behaviour i expected from the interface though
<ogra_> joc_, snap list|grep ubuntu-core
<ogra_> what revision do yu have
<joc_> ogra_: 178
<ogra_> ok, thats the recent build
<ogra_> Get:4 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 snap-confine amd64 1.0.38-0ubuntu0.16.04.4 [20.4 kB]
<ogra_> and thats the version it installed
<EAbdel> Hey
<EAbdel> please is there any one connnected here ?
<jdstrand> joc_: ok. did a file in /etc/udev/rules.d/ get created?
<joc_> jdstrand: yes
<jdstrand> joc_: can you paste the contents?
<joc_> http://paste.ubuntu.com/22929166/
<jdstrand> joc_: can you paste 'udevadm info /dev/the-thing-you-tried-to-tag'?
<EAbdel> hi
<EAbdel> need some help
<EAbdel> somone here to help me ?
<joc_> jdstrand: http://paste.ubuntu.com/22929677/
<jdstrand> joc_: ok, so it should have something like: E: TAGS=:systemd:nap_miniterm-joc_open:
<jdstrand> joc_: but it only has TAGS=:systemd:
<jdstrand> (obviously I meant 'TAGS=:systemd:snap_miniterm-joc_open:')
<jdstrand> joc_: because that tag isn't present, snap-confine isn't creating a device cgroup
<jdstrand> and so the /dev/** line allows everything
<elopio> sergiusens: josepht: I have a problem here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/yaml.py#L136
<joc_> jdstrand: ok, makes sense, to work out why the tag isnt applied then
<elopio> sergiusens: josepht: why are we getting the remote parts every time? Can we be lazier than that?
<mup> PR snapd#1666 opened: osutil: change escaping for create-user's sudoers <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1666>
<sergiusens> elopio in the tests? Because some tests use remote parts and some don't
<EAbdel> hi
<jdstrand> joc_: so, ID_VENDOR_ID=10c4
<EAbdel> somone workign with snaps ?
<EAbdel> please
<elopio> sergiusens: no, every time we load the config we get the remote parts.
<sergiusens> elopio we clear the xdg home as part of the main test fixture
<jdstrand> joc_: but you have ATTRS{idVendor}=="0003"
<sergiusens> elopio let me think into why that is
<elopio> we should load the remote parts only when they are needed.
<jdstrand> joc_: did you mix up vendor and product?
<sergiusens> elopio yes that should be the case
<sergiusens> elopio which is why I went with the current test solution; this should be fixed once josepht gets the yaml loader stuff refactored
<jdstrand> joc_: ID_MODEL_ID=0003. I guess that corresponds with the idProduct. anyway, yeah, it looks like things aren't quite right with the rule
<elopio> sergiusens: I think I can quickly put a property to solve it. /me tries
<joc_> jdstrand: oh good spot, i haven't in the plug defintion, sounds like i must have done in the interface code
<joc_> that generates the snippet
<jdstrand> joc_: feel free to adjust the file in /etc/udev/rules.d directly and then do: udevadm control --reload-rules ; udevadm settle ; udevadm trigger ; udevadm settle
<jdstrand> technically the settles shouldn't be required, but I found they were
<jdstrand> joc_: after that series of udevadm command you can do the udevadm info /dev/... command and see if it worked
<jdstrand> joc_: perhaps you knew all this-- if so, you get bonus help :)
<jdstrand> joc_: once happy, yeah, update the interface accordingly
<joc_> jdstrand: looking better, get an E: TAGS=:systemd:snap_miniterm-joc_open:
<jdstrand> ah good
<jdstrand> joc_: when you launch the app, the cgroup should be used
<joc_> jdstrand: excellent, getting operation not permitted when trying to open other /dev/ttyXXX now
<jdstrand> perfect-o!
<joc_> jdstrand: sorry about that, my fault with the code, but the help on the debugging was much appreciated
<jdstrand> np
<jdstrand> joc_: this actually makes me want to investigate something, so that is helpful
<sergiusens> is anyone having issues with write operations on launchpad?
<mup> PR snapcraft#657 closed: Add constraints to python2 plugin <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/657>
<joc_> jdstrand: something comes to mind for me too
<joc_> jdstrand: as this is a usb device i can unplug it
<joc_> and now there is no device with tag on so no cgroup and i have access to everything in /dev again
<jdstrand> joc_: yes, that is precisely what I was talking about investigating
<jdstrand> joc_: I've added it to the trello card for my part of this interface. it is a bug in snap-confine that will need to be fixed
<jdstrand> joc_: don't worry about snap-confine. I'll fix it
<jdstrand> joc_: but I think this shows we should be more defensive with the apparmor rule to limit damage in the event of bugs
<jdstrand> joc_: is it possible for you to use /dev/tty* instead of /dev/**?
<jdstrand> joc_: or /dev/ttyUSB*? whatever that can be more fine-granined but not all of /dev/**
<joc_> jdstrand: yes i can do and it would limit the damage of falling back to just the apparmor rule
<jdstrand> it might not be possible. I suspect with the tty subsystem it is though
<jdstrand> thanks
<jdstrand> joc_: note, I won't block the interface review on that, but I will mention it in the PR
<jdstrand> err
<jdstrand> joc_: by 'that' I meant the snap-confine bug
<jdstrand> joc_: I also know how to address that bug
<joc_> jdstrand: ok, i'll make the changes and propose it soon, thanks
<jdstrand> joc_: sure thing
<mup> PR snapcraft#720 opened: Start the fake parts server only in the tests that need it <Created by elopio> <https://github.com/snapcore/snapcraft/pull/720>
<jdstrand> joc_: you may be wondering why we have this combination of cgroups and apparmor when it would be arguably easier to just update the apparmor profile
<jdstrand> joc_: the reason is that updating the apparmor profile requires a policy recompile which while not terrible on x86 can be up to a second or more on armhf
<jdstrand> joc_: so do that on hotplug events is not ideal
<jdstrand> joc_: so we have cgroups for now. in the future apparmor will grow xattr support such that we will be able to add a rule to the default template that says 'any file with this xattr that matches this security label is allowed'. then we load the policy once and a udev script updates the xattr of the file instead of messing with cgroups
<jdstrand> joc_: and we can remove the apparmor glob rules and all is nice and clean :)
<jdstrand> hopefully we'll have that for series 18. we'll see
<mup> PR snapd#1651 closed: osutil: more create-user fixes <Reviewed> <Created by mwhudson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1651>
<mup> PR snapd#1665 closed: many: do not require root for `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1665>
<jdstrand> ratliff: you might actually be interested in that last bit with jo c_ ^
<jdstrand> ratliff: fyi only
<ratliff> thanks, jdstrand, interesting indeed
<ali1234> why isn't there a snapcraft snap?
<sergiusens> ali1234 because we cannot build from there yet
<sergiusens> keyword: yet
<ali1234> yes but why?
<ali1234> would it work in devmode?
<ogra_> it will even work with strict confinement ... just be patient ;)
<ogra_> GRR ...
<ogra_> https://code.launchpad.net/~ogra/+snap/kernel-test-snap
<ogra_> i start hating our arm builders
<ogra_> ("starting in 18min" ... since 2h :P )
<ali1234> what is the correct way to change the hostname on an all-snap system?
<ali1234> ogra_: i tried to make classic use an overlay, now it won't boot at all
<kyrofa> ogra_, have you tried the auto-upload from LP from an account with whom the snap was shared yet?
<mup> PR snapcraft#698 closed: Add option disable-parallel for all plugins <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/698>
<stokachu> do interfaces get installed automatically?
<stokachu> fo rexample if there is a juju interface that we would plug into
<stokachu> juju snap would need to be installed
<kyrofa> stokachu, that's likely a question for zyga
<josepht> sergiusens: do you mind adding notes from our discussion to the sub-parts bug? https://bugs.launchpad.net/snapcraft/+bug/1606933
<mup> Bug #1606933: parser - Make all parts top-level parts <Snapcraft:In Progress by joetalbott> <https://launchpad.net/bugs/1606933>
<josepht> sergiusens: I would but the reason for the new file idea escapes me :)
<mup> PR snapcraft#717 closed: fix checker errors to let runtests.sh pass again <Created by cpaelzer> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/717>
<arges> jdstrand: hey not sure if https://github.com/snapcore/snapd/pull/1602 is on your queue. The CI test failures seem to be random so i can never tell if its in a bad state or not
<mup> PR snapd#1602: interfaces: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602>
<jdstrand> arges: I'll give it a once over for the security policy bits and anything else I happen to see, but a core member of the snappy team will perform the merge
<arges> jdstrand: thanks.
<jdstrand> arges: as for the test failures-- yeah, that's annoying. not sure what's happening there lately; things were solid for quite a while...
<jdstrand> arges: I left two small things to adjust, then LGTM. Please ping me when you commit and I'll say as much in the PR
<arges> jdstrand: ok
<ali1234> hmm... the all-snap image stopped working after i rebooted it a couple of times
<ali1234> now it doesn't get past uboot
<tianon> seeing the same boot issues after updating all-snaps on an amd64 VM too (although stuck in grub, not uboot)
<ali1234> i didn't attempt to upgrade it
<ali1234> although i gather it does so automatically
<tianon> IIRC it has auto-update turned on by default
<tianon> yeah
<ali1234> however, i was attempting to reboot because i forgot to plug in the network cable
<jdstrand> ogra_: if you are still around, would you mind sharing your sshfs snap?
<ali1234> so i dunno how it could have downloaded the update...
<tianon> I can reproduce 100% consistently with https://people.canonical.com/~mvo/all-snaps/16/all-snaps-amd64.img.xz by doing "sudo snap refresh" followed by a reboot
<arges> jdstrand: fwiw. pushed an update with your changes. I rebased again so not sure what the results of the CI tests will be
<jdstrand> arges: I think the snappy team prefers to not have rebases fwiw, but I'll take a look
<ali1234> how do i make snapcraft use a local git repo?
<mup> PR snapd#1667 opened: many: implement snaptool command <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1667>
<ali1234> also what is the best practice when the snapcraft.yaml exists in the same repo as the source code?
<ali1234> hmm... desktop-launch went crazy
<mup> PR snapcraft#677 closed: playing with caching <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/677>
<kyrofa> arges, jdstrand indeed, you can squash up for the initial PRs if you want to start clean, but merges only once the PR is created
<camako> ali1234, this should work :
<camako> source: /path/to/my/repo
<camako>     source-type: git
<ali1234> thanks
<camako> yw
<camako> jdstrand, ping
<ali1234> but what about when the snapcraft.yaml exists within the project it is compiling?
<tianon> jdstrand: oh man, I've been updating my PR wrong /o\  I'll keep this in mind for future updates, sorry! :x
<camako> ali1234, "source: ."
<ali1234> yeah that specifically fails for me
<camako> looking at gitter-im in the playpen may help.. that's what it does.
<ali1234> it causes desktop-launch to try to create recursive directories, then it crashes when it hits the dir limit
<ali1234> i'm trying to reproduce it on amd64
<ali1234> then i'll upload an example to my museum of broken snaps...
<jdstrand> camako: hi
<camako> jdstrand, hi.. I was looking at the mesa gl/gles demos in terms of snappy interface requirements
<camako> I noticed that they use 'sendmsg' which gets a denial
<camako> further investigation revealed that it's used to talk to the X server
<camako> which is a legit thing to do
<camako> but x11 interface doesn't include sendmsg
<camako> only 'send' I think
<camako> and then I thought, other apps (non-gl) would use it too
<jdstrand> camako: seems fine to add. either file a bug with snapd-interface or do a PR against snapd
<jdstrand> camako: if filing a bug, please add the 'snapd-interface' tag
<jdstrand> then we'll get that fixed up
<jdstrand> I suspect it will want 'sendto' as well
<camako> jdstrand, will do... out of curiosity, how come no other X11 app has encountered this problem?
<jdstrand> camako: not sure. what architecture are you using?
<camako> I'm on AMD64 with intel (i965) gpu
<jdstrand> yeah, that's odd
<jdstrand> guess your snap made an api call that others don't typically use
<jdstrand> and that call ended up using sendmsg
<camako> jdstrand, I traced it to 'glXMakeCurrent'
<ali1234> most X11 code doesn't use GL, and most GL code doesn't use X11 features directly...
<jdstrand> there you go
<jdstrand> it's interesting how things like this crop up
<camako> jdstrand, don't we have apparmor protection on ubuntu outside snappy?
<jdstrand> it's an easy fix so we can get it into the next snapd release without issue
<jdstrand> camako: apparmor is used in various places, sure (/me notes we are talking about seccomp here)
<camako> jdstrand, abstractions/X (which allows 'send') is under apparmor, so I was going with that
<jdstrand> camako: that's a different send
<camako> so I'm wondering without sendmsg, how is an app like glxgears end up working?
<jdstrand> camako: in snappy we have both apparmor mediation and seccomp filtering
<camako> ah ok
<jdstrand> seccomp is the first line, then apparmor
<camako> ok I'll file a bug
<jdstrand> seccomp is way more coarse-grained, but the combination of the two is compelling
<camako> ack
<jdstrand> cause we can say, block module loading at the syscall level even if the apparmor policy would allow it
<jdstrand> (it doesn't, you'd need sys_module so not the best example, but the point is, we use them in combination for a strong sandbox)
<camako> right
<jdstrand> the sandbox is mostly apparmor, but the seccomp filtering comes in handy where apparmor doesn't yet implement an lsm hook
<jdstrand> kernel keyring is a good example. we can also block known problematic or ancient syscalls to reduce the kernel attack surface
<jdstrand> anyhoo, yes, file a bug and I'll get it fixed
<camako> jdstrand, I'll file a bug, but I am keen to understand why things are working on the desktop.
<camako>   # the unix socket to use to connect to the display
<camako>   /tmp/.X11-unix/*           w,
<camako>   unix (connect, receive, send)
<camako> ^^ these lines from the X file
<camako> caught my eye
<jdstrand> camako: so, on the desktop most X apps shipped as debs aren't confined by apparmor (or seccomp)
<camako> I'm assuming for non-snappy desktop apps,  this is used?
<camako> ah ok then..
<camako> :-)
<camako> thanks for the explanation
<jdstrand> camako: when you confine an X app with apparmor, then you need a unix rule from the X abstraction. those use apparmor syntax and are not syscalls
<camako> I see
<jdstrand> camako: when you then setup a seccomp filter for the app, then you see the syscalls it uses
<jdstrand> so on snappy you get both. on non-snappy, neither or possibly just apparmor
<camako> I was running an app that I compiled... would that have been confined by apparmor?
<zyga> o/
<jdstrand> camako: no
<ali1234> hmm... can't reproduce with a simple helloworld snap
<mup> Bug #1611978 opened: Incomplete x11 interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1611978>
<ali1234> well that's annoying
<sergiusens> robert_ancell hey, mind updating https://github.com/snapcore/snapcraft/pull/670 ?
<mup> PR snapcraft#670: Remove .la files generated by autotools <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/670>
<robert_ancell> sergiusens, ok
<ali1234> something is very wrong here: http://paste.ubuntu.com/22968449/
<sergiusens> ali1234 we had this same problem, well stokachu did and it was related to having a command in the snap calling an internal to the snap binary with the same name and exec doing its thing of infinitely calling upon itself due the the in snap command having a bad shebang
<ali1234> t worked fine yesterday :(
<ali1234> there are only two things in the snap: desktop-helper and my binary (infodump)
<ali1234> desktop-launcher sorry
<ali1234> hmm i see... so desktop-launch is running /snap/bin/infodump instead of /snap/infodump/current/bin/infodump
<ali1234> which causes the recursion
<sergiusens> ali1234 yeah, that would do it
<ali1234> but why?
<sergiusens> ali1234 is /snap/infodump/current/bin/infodump a binary?
<sergiusens> is it +x?
<sergiusens> if it has a shebang, is it correct?
<ali1234> it *should* be a binary
<ali1234> hang on i have to build it again to know for sure
#snappy 2016-08-11
<ali1234> there's a generated wrapper in the mix too
<ali1234> my command line in the snapcraft is : desktop-launch infodump --platform eglfs
<ali1234> okay infodump is completely absent from the snap... wat
<ali1234> oh wait, no it isn't
<ali1234> it is at /snap/infodump/x1/home/ubuntu/snaps/infodump-test/parts/infodump
<ali1234> /home/ubuntu/snaps/infodump-test is of course the directory with the snapcraft.yaml
<ali1234> command-infodump.wrapper has: exec "desktop-launch" infodump -platform eglfs "$@"
<ali1234> so of course infodump is not on the part
<ali1234> *path
<ali1234> hmm i see a snapcraft upgrade on desktop
<ali1234> maybe i can't reproduce it because it is a regression
<stokachu> whats your snapcraft.yaml look like ali1234
<ali1234> http://paste.ubuntu.com/22975659/
<stokachu> ali1234: i think the infodump under parts: is what is confusing snappy
<stokachu> call it like infodump-copy
<stokachu> ali1234: https://github.com/conjure-up/conjure-up/blob/master/snapcraft/snapcraft.yaml thats mine
<stokachu> i had the same problem with my binary 'conjure-up'
<ali1234> i have another one
<stokachu> had to make sure the keys didn't overlap
<ali1234> http://paste.ubuntu.com/22975816/
<ali1234> this one works fine
<stokachu> ah ok
<stokachu> may not be the same problem i had then
<ali1234> aaaaaaargh
<ali1234> found the problem :/
<ali1234> target.path = build in the stupid qmake file
<stokachu> ah
<ali1234> i thought i fixed that
<stokachu> well at least you know the issue now :)
<ali1234> yeah. i wonder why it reverted
<ali1234> probably forgot to commit the change on git
<stokachu> ive spent several days trying ot get my stuff packaged
<stokachu> i feel your pain
<ali1234> i keep running into walls tbh
<ali1234> missing interfaces mainly
<stokachu> yea same here
<stokachu> im just pulling everything i need into a single snap
<stokachu> makes it bloated but works
<ali1234> i'm making something for embedded use... at the moment i need: sysfs gpio, i2c-dev, sysfs backlight, uinput, videocore... and a patched Qt
<ali1234> oh and pulseaudio in the all-snap
<pbek> For some reason I get a "Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop/qt5'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache" again when building a snap with Launchpad or locally with snapcraft. It worked 12h ago.
<pbek> I locally have snapcraft 2.14 installed.
<didrocks> pbek: hey, did the issue just happened?
<didrocks> I wonder if the transition plan from josepht didn't work as expected
<pbek> yes, just now. worked 12h ago
<pbek> https://launchpadlibrarian.net/278346021/buildlog_snap_ubuntu_xenial_amd64_qownnotes_BUILDING.txt.gz
<didrocks> ok, can you try replacing it with desktop-qt5 and check if it works?
<didrocks> josepht: sergiusens: seems like something is wrong on the transition plan for / in parts, see ^
<jcjordyn120> go join #thelinuxgeekcommunity
<pbek> didrocks: I still get "Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'desktop-qt5'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache"
<didrocks> did you run snapcraft update as indicated?
<didrocks> (I think you did, but just checking ;))
<pbek> yes, I did
<didrocks> argh
<pbek> (it's part of my build script) ;)
<didrocks> I don't remember the API endpointâ¦ is it urgent, like, can this wait for josepht to show up online to debug with him?
<didrocks> I can give you a quick workaround, but I think you will not be the only one to get this
<didrocks> (but then, please stay online and revert the workaround to ensure we get to the bottom of this :))
<pbek> wgrant from the launchpad channel mentioned: https://parts.snapcraft.io/v1/parts.yaml's desktop part looks weird. I wonder if something's changed around subparts.
<didrocks> yeah, subparts changed
<didrocks> see the ML and my concerns about it :)
<didrocks> yeah, no dekstop/* or desktop-* entry here
<didrocks> that's why it's failing
<pbek> It's not urgent, I there are not many snap users yet...
<didrocks> pbek: I think they will be up in ~5-6h, mind pinging them then?
<pbek> https://code.launchpad.net/~pbek/+snap/qownnotes
<pbek> didrocks: I think I'll be gone by then...
<pbek> this is the repository I use: https://git.launchpad.net/~pbek/qownnotes-snap/tree/
<didrocks> pbek: perfect, I was going to ask you for the repo :) I'll ensure we have a look at it so that we can fix this. Sorry for the trouble
<pbek> snapcraft is software... always evolving :)
<didrocks> pbek: heh, I have a tab opened with your tree as a reminder :)
<pbek> *giggle*
<didrocks> pbek: btw, I think source-type isn't necessary in your snapcraft.yaml. Autodetection from extension should work
<didrocks> (if not, we can fix it)
<pbek> I will remove it in the next release, thank you
<didrocks> yw!
<pbek> I love snaps, I hope my last issues I have with the QOwnNotes snap will be gone some day (or I find a workaround).
<pbek> issues: https://github.com/ubuntu/snappy-playpen/issues/145 (on the bottom)
<didrocks> pbek: the home issue changing is more a feature than an issue, what's the pb with it?
<didrocks> Qt theme -> we have a plan with platform/runtime snaps for this :)
<pbek> QOwnNotes did detect the home directory and stored that as setting for the note folder (like  `/home/omega/snap/qownnotes/13`), but after an update the folder wasn't accessible any more because the revision changed ;)
<pbek> I worked around the problem by cutting out the `/snap/qownnotes/\d+` part
<didrocks> ahhhhhh, you save the folder to not really on env variable afterward, interesting
<didrocks> you could as well replace this version number with current/
<didrocks> scratch that, doesn't work for SNAP_USER_DATA
<pbek> I got that directory from QDir::homePath() ;) but in the case of QOwnNotes I wanted the real home directory of the user because ownCloud will be syncing with that anyway, so my workaround is ok
<pbek> the character set problems and the languages are more bothering...
<didrocks> yeah, there has been discussions on the ML. There are some ideas to explore to fix those
<pbek> +1 :)
<mup> PR snapd#1668 opened: tests: prevent restore error on test failure <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1668>
<liuxg> when I try to remove a snap from the system, it complains "error: cannot remove "tomcat-webapp-demo": snap "tomcat-webapp-demo" has changes in progress". is there any way to force to remove it from my system? thanks
<ogra_> sergiusens, kyrofa, josepht, bah, the final version of the "type: os" fix doesnt work, something you changed since the initial commit seems to have broken it ... (the snapcraft i used in the PPA had the initial patch only)
<ogra_> ubuntu@localhost:~$ ls -lh /home/
<ogra_> total 4.0K
<ogra_> drwxr-xr-x 3 root root 4.0K Aug 11 08:17 ubuntu
<ogra_> ubuntu@localhost:~$
<zyga> ogra_: http://www.cnx-software.com/2016/08/11/u-boot-now-supports-uefi-on-32-bit-and-64-bit-arm-platforms/?utm_campaign=shareaholic&utm_medium=google_plus&utm_source=socialnetwork
<ogra_> zyga, yeah, awful
<timothy> lol
<ogra_> zyga, oh, idmap ! thats indeed a good idea
 * ogra_ just read the bug 
<ogra_> s/bug/comment/
<ogra_> though that operates on a filesystem level
<ogra_> so you would have to hook iinto squashfs
<zyga> ogra_: you can either idmap all the snaps so that they look consistent or idmap the hostfs so that it looks consistent for running snap apps
<ogra_> well, doesnt that need support on the FS side ?
<zyga> ogra_: but yeah, I just don't know if idmap is available outside of nfs
<ogra_> (does it work with other filesystems than NFS)
<zyga> yeah
<zyga> well, just a kernel patch (rolls eyes)
<ogra_> but see my bug comment, seems squashfs actually creates a caching table for the uids
 * mwhudson reads macaroon code, feels his brain dribble out of his ears
<ogra_> so if something like idmap could hook in there and simply cheat them to the correct value, that could work
<zyga> ogra_: as for uefi on uboot, I think that's pretty useful :)
 * ogra_ hands mwhudson two cups for his ears
<ogra_> zyga, i dont ... but yeah, some cloud people might like it
 * ogra_ finds it as useful as chainloading grub from uboot ... :P
<ogra_> (just added useless complexity)
<ogra_> (since you need to hand the dtbs from one bootloader implementation to the next on the boards we use)
<mwhudson> ogra_: would you like some acpi too?
<ogra_> hahaha
 * mwhudson gets LEG flashbacks
<ogra_> heh, yeah, though didnt acpi for arm64 server boards actually happen in the end ?
<mwhudson> define 'happen'
<ogra_> well, being implemented ...
<mwhudson> i think there is support in the kernel at last, not sure about shipping hw actually using it...
<ogra_> i think there are some server boards
<ogra_> doing uefi and acpi ... so you dont need to adjust the cloud SW that runs on top
<mwhudson> i don't think ubuntu is supported on any of them using acpi though
<mwhudson> (might be wrong, i sort of agressively stopped paying attention a while ago)
<ogra_> yeah, that was a jonmasters thing ... i guess fedora supports it
<zyga> ogra_: if you think of it ubuntu-core is just like that cloud software, whatever you or I think about acpi or uefi, consistency is useful
<zyga> mwhudson, jdstrand, mvo: https://github.com/snapcore/snap-confine/pull/98/files
<mup> PR snap-confine#98: Move apparmor profile for snap-confine to src/ <Created by zyga> <https://github.com/snapcore/snap-confine/pull/98>
<zyga> this is a simple but tricky change, I just want to ensure that all the packaging gets it right downstream
<mwhudson> zyga: i certainly support the intent
<ogra_> hmpf ... linux-meta in proposed is out of sync ... that nicely made tonights ubuntu-core amd64 builds explode
<ogra_> mwhudson, seems you havhe e to wait a day longer for the netplan fix :(
<mwhudson> ogra_: it's ok, we're making our own snaps anyway still
<ogra_> err, so i can revert the writable dir ?
<mwhudson> well no, we'll need it sooner or later
<ogra_> ok
<mwhudson> just the failure of builds today is not a problem
<ogra_> good
<ogra_> i hope i have the separate kernel snap builds done today ...  then i can rip out all the breaking code from the ubuntu-core builds
<ogra_> oh, bah ... dear LP ... dont show me timeouts on the request-builds page and still run the builds ... grrr ... now i have two builds going in a row
<zyga> mvo, mwhudson: where do we keep snap-confine packaging for xenial and yakkety? I'm looking for something like a git repo that can be maintained and that is used the next time an upstream release has to be packaged
<zyga> I asking because I'm working on removal of stale debian/ from snap-confine source tree so that spread tests are ran against the source tree and current state of downstream packaging
<mwhudson> zyga: i haven't done any ubuntu specific stuff for snap-confine
<zyga> so that eventually we know if we can release now and if it really works as intended
<mwhudson> zyga: but, take the branch on alioth, push it to github or launchpad or something?
<zyga> debian is in the same boat but I want to start with ubuntu because all the tests are passing there
<zyga> mwhudson: yeah, that makes sense, I'm just asking if there's a branch like that already, I'll wait for mvo to reply
<mvo> zyga: I just use the packaging from the archive and apply the individual fixes for now
 * mwhudson zzz
<zyga> mvo: ok, would you oopse if I take the packaging form the archive and upload it to launchpad/github
<zyga> mvo: and so that the next time we do a release that packaging is combined with the upstream tarball to form a release
<zyga> mvo: my intent is to ensure that *tested* (during usual spread CI) code is released and packaged *as tested*
<mvo> zyga: sure, thats fine
<zyga> mvo: great, thanks!
<zyga> mvo: I will document everything in the upstream tree
<mvo> zyga: new snap-confine is uploaded to xenail-proposed, thanks for the fix. I also uploaded it to the ppa so I can test it with spread
<jdstrand> zyga: probably the easiest thing to do there would be a make install to /usr and then diff the resulting profile with what we had before. do the same to /usr/local and see it the correct parts change
<ogra_> mvo, so where do we stand with the kernel sideloading fix ? (i got new kernel snaps but yesterday the pi2-kernel was still not sideloadable)
<mvo> ogra_: do you have r4 for ubuntu-device-flash?
<mvo> ogra_: sudo snap refresh --devmode ubuntu-device-flash
<ogra_> yes, that was the one i had upgrade issues with ... i remved/reinstalled it yesterday to make it work again
<mvo> ogra_: ok, you got a zimage failure, iirc, could you please run "file" on the kernel.img and initrd.img
<mvo> ogra_: I wonder if something got corrupted
<ogra_> let me try a fresh build ...
<mvo> ogra_: it might be some corruption issue
<zyga> mvo: thank you
<zyga> jdstrand: good idea, I will do that in a second, just writing some documentation
<ogra_> ok, fresh build ...
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/writable/system-data/snap/pi2-kernel/
<ogra_> unset
<ogra_> err
<pbek> didrocks: 'desktop/qt5' reminder ;)
<ogra_> mvo, http://paste.ubuntu.com/23014754/ seems to be all fine
<zyga> jdstrand: I just checked, the profiles are identical except for the new features that were added (nothing is broken by the branch I linked to)
<zyga> jdstrand: if you can comment on https://github.com/snapcore/snap-confine/pull/98 that would give me more confidence in merging this
<mup> PR snap-confine#98: Move apparmor profile for snap-confine to src/ <Created by zyga> <https://github.com/snapcore/snap-confine/pull/98>
<ogra_> mvo, and along with the above paste http://paste.ubuntu.com/23015149/ thats the snap.yaml that snapcraft created for it
<mvo> ogra_: and if you boot that?
<ogra_> well, see the "unset" in the first paste ... the snap doesnt even end up on the image ... so i'm pretty sure it cant boot ... but let my try anyway
<ogra_> reading pi2-kernel_x1.snap/kernel.img
<ogra_> ** Unable to read file pi2-kernel_x1.snap/kernel.img **
<ogra_> reading pi2-kernel_x1.snap/initrd.img
<ogra_> ** Unable to read file pi2-kernel_x1.snap/initrd.img **
<ogra_> Bad Linux ARM zImage magic!
<ogra_> Scanning mmc 0:1...
<ogra_> there you go
<zyga> mvo: how can I apt-get source from the proposed pocket?
<ogra_> zyga, by adding a deb-src line to your sources.list for it
<ogra_> (and update ...)
<mvo> ogra_: uh, its not on the image - hm, what commandline did you use?
<mvo> ogra_: I will try to reproduce
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo /snap/bin/ubuntu-device-flash core 16 --channel edge --gadget pi3 --kernel pi2-kernel_4.4.0-1019_armhf.snap --os ubuntu-core -o test-pi3.img
<zyga> oh, nice, Ican use deb-src without deb, thanks
<ogra_> mvo, the snap i use is at https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2670
<zyga> will any apt-pinning get in the way?
<ogra_> mvo, this is the equivalent amd64 snap from the same build (with adjusted name/version in snapcraft.yaml) https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2681 which works fine in kvm
<ogra_> it is definitely uboot related
<ogra_> (or non-amd64 related ... however you want to put it)
<mvo> ogra_: hm, must be something subtle, I got a booting pi2 yesterday, lets see
<ogra_> mvo, from a local kernel snap ?
<mvo> ogra_: so I assume your system-boot does not have unpacked kernel subdir?
<mvo> ogra_: yes, local sideloaded kernel
<ogra_> nope
<ogra_> let me try with a kernel from the store again .... but i tried that yesterday with the same result ...
<ogra_> ... just to be sure
<zyga> timothy: did you get your spread key?
<mvo> ogra_: no need to try, I strongly suspect a bug somewhere in u-d-f
 * ogra_ tries to find some lÃ¼nch
<jdstrand> zyga: I plan to
<mvo> zyga: hm, looks like with snap-confine with the mkdir change the "failed to create user data directory. errmsg: Permission denied" is back on ecryptfs systems :(
<zyga> mvo: oh, drat
<zyga> mvo: we don't test that in spread :-(
<zyga> mvo: encryptfs is the thing where the home directory is encrypted
<mvo> yes
<zyga> mvo: or when the whole / is encrypted?
<zyga> jdstrand: ^^ can you please help us out?
<mvo> zyga: just home
<zyga> mvo: I don't have any test environment for that, I can try to install ubuntu in a VM with encrypted home but this will take me a while
<zyga> mvo: I assumed that during the sprint in leiden, when some people encountered this, the proposed version of snap-confine already fixed this
<zyga> mvo: do you have the apparmor denial?
<zyga> who might know about ecryptfs and how to set that up for a single test user?
<mvo> zyga: http://paste.ubuntu.com/23018211/
<mvo> zyga: tyhicks or jdstrand know about ecryptfs, afaik its possible to create it for a new user just for testing
<zyga> mvo: I want to have a spread test that has this, otherwise it will just break again :/
<mvo> ogra_: fwiw, I got the same error 10 today on my system when upgrading from r4 to r5 of u-d-f
<ogra_> crap
<josepht> ogra_: hrm, I'll take a look
<ogra_> mvo, seems to only happen for the --edge --devmode combo though
<ogra_> (or --beta --devmode)
<didrocks> josepht: hey, did you see the discussion we had with pbek earlier?
<didrocks> josepht: seems the transition doesn't work as expected (please scrollback)
<josepht> didrocks: looking
<mvo> ogra_: ha! I have a kernel OOPS
<ogra_> aha !
<ogra_> apparmor ?
<ogra_> or squashfs ?
<mvo> jdstrand: I got an apparmor oops :/
<mvo> ogra_: apparmor
<josepht> didrocks: I just replied to my PR, we need the plain version of the desktop sub-parts in the snapcraft-desktop-helpers repo.  Want me to file another PR?
<didrocks> josepht: sure, please do!
<didrocks> josepht: I don't know about the plain version as "gtk2", those never existed
<didrocks> people are using either desktop/gtk2 or desktop-gtk2, right?
<didrocks> now, if we look at the API, there is only "desktop" and that's it
<josepht> didrocks: right, but in the snapcraft.yaml for the origin they are just 'gtk2', etc
<didrocks> oki, trusting that would work :)
<mvo> ogra_: can you please try r5 of u-d-f from the store? I suspect it was snapcraft playing tricks with me
<mvo> ogra_: I will test in a sec too, but the oops killed my machine
<ogra_> i know what you mean :)
 * ogra_ snap removes and snap installs instead
<ogra_> WOAH !
<jdstrand> mvo: that's no good. can you file a bug with a reproducer? jj is off today, but he can perhaps look at it tomorrow (or perhaps tyhicks sooner)
<ogra_> mvo, jdstrand http://paste.ubuntu.com/23019578/
<josepht> didrocks: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/6
<mup> PR ubuntu/snapcraft-desktop-helpers#6: Add back the original parts as well so older versions of snapcraft-parser works <Created by josepht> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/6>
<ogra_> thins time even after a remove/install run
<ogra_> (i got a kernel updated today and havent rebooted yet though)
<ogra_> http://paste.ubuntu.com/23019750/
<ogra_> and also a kernel oops
<jdstrand> mvo: (cc tyhicks) that seems to be the same trace as bug #1579135
<mup> Bug #1579135: kernel BUG on snap disconnect from within a snap <apparmor (Ubuntu):Incomplete> <https://launchpad.net/bugs/1579135>
<josepht> didrocks: I just re-ran the parser and the desktop/xxx parts are back
<jdstrand> mvo (cc tyhicks): jj (and to some extent I) tried to get a reliable reproducer for that but were unable to
<josepht> pbek: can you try again after doing another 'snapcraft update' please?
<mvo> jdstrand: I commted with how it happend to me, I can try to reproduce but will need to reboot first, looks like apparmor_parser is hanging
<tealeg> hmmm... the desktop remote part seems to have been corrupted somehow
<ogra_> mvo, same here ... i tried to install it again but it doesnt move anymore
<josepht> tealeg: can you try 'snapcraft update' and see if they are fixed now?
<tealeg> josepht: yes!
<tealeg> josepht: ha.. I've been fiddling for 20 minutes, and the moment I come here it's fixed ;-)
<tealeg> josepht: cheers!
<josepht> tealeg: just good timing, I made a mistake in a PR to get ready for the removal of namespacing
<ogra_> hmpf ... and it seems the hanging apparmor_parser made my shutdown go stuck
<zyga> hanging?
<ogra_> yeah
<ogra_> see above
<ogra_> kernel oops on snap refresh .. after that the parser hangs
<didrocks> josepht: nice! :)
<josepht> ogra_: which livecd-rootfs package?
<morphis> mvo: I still have problems with the latest u-d-f: https://paste.ubuntu.com/23020975/
<ogra_> josepht, ?
<liuxg> kyrofa, ping
<ogra_> josepht, what do you mean
<kyrofa> liuxg, pong
<josepht> ogra_: to test the os snap ownership issue; there are three versions of livecd-rootfs.  I assume the latest?
<ogra_> josepht, ah, it is the one in the snappy image PPA
<liuxg> kyrofa, in China, a customer is trying to package mysql, tomcat into a snap. I refer to your owncloud example for the mysql part. it is a great example. I want to understand whether your mysql listens to port 3306 or just a socket?
<josepht> ogra_: here right? https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<ogra_> josepht, you can do a local build using lp:ubuntu-core-snap (needs sudo for the snapcraft call since it creates a bunch stacked of chroots)
<ogra_> and yes, then locally install that livecd-rootfs package first
<ogra_> (just wget and dpkg -i the deb)
<kyrofa> liuxg, just a socket, certainly
<jdstrand> ogra_: istr you saying you had an sshfs snap. would you mind sharing it with me?
<kyrofa> liuxg, but it requires the use of the my.cnf shipped in the snap, too
<kyrofa> liuxg, skip-networking, specifically
<ogra_> jdstrand, sadly i only tried to create one ... i didnt finish it
<liuxg> kyrofa, if I want to change it to listen to the 127.0.0.1:3306, how can I change it? https://github.com/kyrofa/owncloud-snap
<jdstrand> ogra_: would you mind sharing what you have?
<ogra_> i'll try to find the time before EOW
<kyrofa> liuxg, are you using that config file?
<liuxg> kyrofa, the customer is using jsp to develop the webserver.
<jdstrand> ogra_: I'm looking into the fuse interface and wanted to play with different things
<liuxg> kyrofa, yeah, I am trying to understand your code, or I just stage-package from the standard ubuntu archive?
<kyrofa> liuxg, you'll run into issues with using the stage-package: https://kyrofa.com/posts/snapping-nextcloud-mysql
<kyrofa> liuxg, but yeah, try just removing the skip-networking stanza in the config flag
<kyrofa> config file rather
<ogra_> jdstrand, http://paste.ubuntu.com/23021415/
<kyrofa> No coffee yet
<ogra_> jdstrand, you want to rip out the zenity bits though ... doesnt work
<ogra_> oh, and i dont have the sshfs bits in there anymore (and have no history)
<liuxg> kyrofa, thanks for sharing the article. do you have any links on how to configure it?
<ogra_> essentialyl you want to replace the ssh exec call with an sshfs mount call there
<jdstrand> ogra_: ack, thanks!
<liuxg> kyrofa, so removing skip-networking is the only place I need to change, do I need to set the IP address and port number there in the my.cnf file. thanks
<kyrofa> liuxg, try bind-address=127.0.0.1
 * ogra_ sighs and reboots his PC too ... same apparmor_parser hang and oops 
<kyrofa> liuxg, I think you can also use port=<whatever>
<liuxg> kyrofa, thanks. other than this, it should be fine. do I need to change anything there in the mysql.server file?
<ogra_> and indeed same hard hang on shutdown
<morphis> ogra_: did the new u-d-f work for you with a local kernel snap?
<liuxg> kyrofa, I have seen that you are using mysql.sock in the file mysql.server.
<ogra_> morphis, well, i could have tested it if the snap refresh call had not killed all my machines
<morphis> ogra_: oh, did apparmor crash on the kernel side?
<ogra_> yes
<morphis> ogra_: saw the same here
<kyrofa> liuxg, yeah I used the mysql.server file to put things in the right place
<jdstrand> huh
<pbek> josepht: I rebuilt QOwnNotes on https://code.launchpad.net/~pbek/+snap/qownnotes and it worked great! Thanks a lot!
<josepht> pbek: great! you're welcome
<josepht> pbek: ... and sorry for the trouble :)
<jdstrand> mvo, morphis, ogra_: if all of you are seeing the crash, can you give detailed instructions on how you are triggering it in bug #1579135. we weren't able to do it. eg, if using all snaps system include the core, kernel, gadget snaps used to create it (or where to fetch the image), the commands needed to trigger it, etc
<mup> Bug #1579135: kernel BUG on snap disconnect from within a snap <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1579135>
<jdstrand> it sounds like all of you have stumbled upon a reliable reproducer
<ogra_> yeah, i just need to snap remove/install the u-d-f package on my desktop PC to trigger it
<liuxg> kyrofa, do I need to change it if I use localhost:3306?  I found that you replaced it with your own. I am thinking whether I just use the original one without replacing it. thanks
<pbek> josepht: that's the beauty of free open source, problems can be found and fixed fast :)
<Ursinha> hi all, I created a snap that uses the camera interface but after I install it "snap interfaces" doesn't show ":camera" as being used, like other interfaces: http://paste.ubuntu.com/23022501/
<Ursinha> am I missing something or this is a bug?
<mvo> ogra_: did you had a chance to test u-d-f r5? if not I will do it now
<kyrofa> liuxg, you'll need to figure out some way of making mysql use $SNAP and $SNAP_DATA, then
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls -l /media/ogra/system-boot/pi2-kernel_x1.snap/
<ogra_> insgesamt 9464
<ogra_> drwxr-xr-x 2 ogra ogra     512 Aug 11 11:54 dtbs
<ogra_> -rw-r--r-- 1 ogra ogra 3029303 Aug 11 11:54 initrd.img
<ogra_> -rw-r--r-- 1 ogra ogra 6660128 Jul 23 00:35 kernel.img
<mvo> ogra_: oh, that looks promising
<ogra_> mvo, looks very good, havent tried to boot it yet ... gimme a bit i need to re-setup all my serial terminals again (rebooting sucks !!!)
<kyrofa> liuxg, you _might_ be able to do that all in the config file. But then I'm not sure why I didn't (this was a while ago, now). Maybe I couldn't get environment variables in there
<morphis> jdstrand: yeah, mvo already put in what I did too
<liuxg> kyrofa, yeah, right. I saw that in your code. you did change the directory paths there in the file due to security.
<jdstrand> ok, cool. maybe now that we have something more reliable jj can track down the bug (tyhicks and ratliff, fyi ^)
<liuxg> kyrofa, do you mean in the my.cnf file? maybe I can have a try. thanks!
<kyrofa> liuxg, indeed
<liuxg> kyrofa, it seems that we can do the configuration in the file my.cnf according to the article at http://www.cyberciti.biz/tips/how-do-i-enable-remote-access-to-mysql-database-server.html
<kyrofa> liuxg, not security just so much as to make it work in the snap period :)
<ogra_> [   97.091705] cloud-init[2602]: Cloud-init v. 0.7.7 running 'init-local' at Thu, 11 Aug 2016 13:40:53 +0000. Up 93.42 seconds.
<ogra_> [  OK  ] Started Initial cloud-init job (pre-networking).
<ogra_> [    **] A start job is running for Run snap...boot setup (1min 21s / no limit)
<jdstrand> kgunn: couple small things for the mir PR
<ogra_> mvo, it boots, but i get the above
<ogra_> (network connected etc)
<mvo> ogra_: aha, interessting
<ogra_> now it timed out and slowly moves on mounting the snap units
<kyrofa> liuxg, unfortunately that doesn't help you: https://serverfault.com/questions/476924/environment-varibales-in-mysql-configuration-file
<ogra_> but each of them seems to take ~30sec
<kyrofa> liuxg, unless you want to hardcode those paths, which I recommend against
<ogra_> ubuntu@localhost:~$ snap list
<ogra_> Name         Version     Rev  Developer  Notes
<ogra_> pi2-kernel   4.4.0-1019  x1              -
<ogra_> pi3          16.04-0.1   1    canonical  -
<ogra_> ubuntu-core  16.04.1     182  canonical  -
<ogra_> ubuntu@localhost:~$
<ogra_> \o/
<mvo> cool
<ogra_> yeah,., looks fine
<ogra_> that was a pi3 btw :)
<liuxg> kyrofa, ok. I understand you. the variables cannot be used in the my.cnf file. that is the purpose doing it in your mysql.server file, right?
<kyrofa> liuxg, indeed
<ogra_> and i can finally verify my kernels ... and they work
<liuxg> kyrofa,  do I need to change anything if I do not socket to connect to the database. I have not studied your mysql.server file too much yet.
<kyrofa> If you disable the socket then yeah, you'll probably want to remove the --socket param and related code
<jdstrand> zyga: fyi, https://github.com/snapcore/snapd/pull/1502 is tagged 'Reviewed' so I think it falls off people's radar, but it has my +1 (see my comment from a moment ago)
<mup> PR snapd#1502: Add an interface for tpm <Reviewed> <Created by jessesung> <https://github.com/snapcore/snapd/pull/1502>
<jdstrand> zyga: I might also mention that the team's use of 'Reviewed' is awkward since it then disappears from lists that people look at and people may not see the changes that the requestor makes. perhaps I don't understand the process you guys are using for that
<ogra_> sergiusens, kyrofa, so when building a snap with "type: kernel" in my snapcraft.yaml, but nmot using the kernel plugin itself, snapcraft populated snap.-yaml with "kernel: vmlinuz" as a default value ... mvo told me yesterday soon only kernel.img will be allowed for that entry, can we make snapcraft default to that (do you need a bug ?)
<liuxg> kyrofa, thanks. I will have a try.
<morphis> mvo: do you saw my paste from above?
<mvo> ogra_: this entry can go away entirely
<morphis> mvo: https://paste.ubuntu.com/23020975/ it is
<ogra_> mvo, does u-d-f/u-image ignore it (i.e. is it harmless) ?
<mvo> ogra_: yes
<mvo> morphis: hm
<ogra_> ah, then it is just cosmetics anyway
 * ogra_ doesnt care about lipstick :P
<mvo> morphis: ls -l kernel.img please? maybe a broken symlink?
<morphis> its a symlink but a valid one
<mvo> ogra_: yeah, it should still not be there
<ogra_> morphis, are you still using my branch ?
<morphis> ah wait
<josepht> kyrofa: it seems shutil.copystat doesn't do what I wanted/expected wrt ownership
<ogra_> i switched the kernel.img stuff yesterday
<morphis> ogra_: yes
<ogra_> probably re-sync then
<ogra_> (save your snapcraft.yaml somewhere, i cahnge that one all the time)
<kyrofa> josepht, ugh, darn. I saw that bug re-opened, wondered about that
<ogra_> so pi2-kernel and pc-kernel are good to go ... only dragonboard missing now ... then i can drop 200 lines (or so) from livecd-rootfs :D
<ogra_> lovely day that is :)
<mup> Bug #1612260 opened: My package is published but not showing up in the store <Snappy:New> <https://launchpad.net/bugs/1612260>
<jdstrand> mvo: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/21
<mup> Bug #1579135: kernel BUG on snap disconnect from within a snap <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1579135>
<kyrofa> josepht, does it not work at all, or just not the way we expected?
<josepht> kyrofa: it doesn't preserve owner/group
<josepht> kyrofa: everything else though
<kyrofa> josepht, ah, just the mode bits?
<kyrofa> Basically everything we don't need?
<kyrofa> josepht, ogra_ that's my mistake, I'm sorry
<ogra_> no worries
<ogra_> i just rolled back the PPA snapcraft
<josepht> kyrofa: nah, I should've caught that
<ogra_> once the full fix lands i can drop it again
<kyrofa> josepht, another reason I wish we could figure out a way to have an integration test for this
<ogra_> luckily thats super easy to do
<kyrofa> josepht, even when we do it right, we're wrong! :P
<mvo> jdstrand: its not so straightforward it seems, but i try some more
<liuxg> kyrofa, just confirm one thing, the database "owncloud" user is "root", and it has no password, right? thanks
<kyrofa> liuxg, I'm afraid it's far more complicated ;) . See https://github.com/kyrofa/nextcloud-snap/blob/master/src/mysql/start_mysql
<mvo> jdstrand: I'm trying it with a different version upgrade now (r3 -> r5) but hit a store issue
<liuxg> kyrofa, yes, it looks very complicated. it is random. In fact, I use "mysql-client", and I can create tables for owncloud. but it needs to have root proivilege to do it.
<mup> PR snapd#1668 closed: tests: prevent restore error on test failure <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1668>
<kyrofa> liuxg, yeah you can do it that way. But yeah, with the way the snap is configured all those files are stored in SNAP_DATA which is only readable by root
<kyrofa> (with the permissions I set, I mean)
<liuxg> kyrofa, so, it does not need to have a password in the sense?
<kyrofa> liuxg, it does actually. That's part of what's generated in start_mysql, and it's saved in a .ini in $SNAP_DATA/mysql
<kyrofa> liuxg, check out the mysql-client as setup in the snap
<kyrofa> You'll see it using that file
<liuxg> kyrofa, yes, it uses the root.ini file. I got it thanks.
<tyhicks> zyga: did you get an answer about how to set up an encrypted home user?
<tyhicks> zyga: on a classic system, `adduser --encrypt-home <username>` will work
<zyga> tyhicks: nope
<zyga> tyhicks: I popped up a new VM :)
<zyga> tyhicks: thanks, this will be valuable for spread
<tyhicks> zyga: it'll be a bit of a pain because you'll have to do an actual login and provide a password before the encrypted home directory will be mounted
<zyga> tyhicks: that's okay, for now I just want to do a one-off fix
<tyhicks> ok
<kgunn> jdstrand: hey so i do want the mir interface to work for actually 3 configs a kiosk/all-snaps, u8-system/all-snaps & u8-system/classic
<kgunn> knowing that....what would be the best category in implicit
<kgunn> ?
<kgunn> other than the name implying it....how do those implicit lists get treated differently by snapd?
<kgunn> zyga: ^ ?
<kgunn> @implicitClassic vs just implicit
<nothal> kgunn: No such command!
<zyga> kgunn: sorry I don't understand what you mean by that
<kgunn> zyga: so when adding a slot to the system you also add the interface to the list in
<kgunn> https://github.com/snapcore/snapd/blob/master/snap/implicit.go#L30
<kgunn> one list is implying Classic in the name
<kgunn> just wondering...do those interfaces get treated differently by snapd? or is it just convention that we're keeping seperate lists?
<SamYaple> sergiusens: ok. just to be clear, the approach i will take regarding refactor of python modules is a _new_ module called python, combine everything in like the qt module did with qt4 and qt5, then change the python2, python3 modules to super the python module for backawards compat
<SamYaple> then i guess we deperate python2 and python3? maybe?
<SamYaple> i guess we dont have to even
<zyga> jdstrand: hey, can you weigh your opinion on https://bugs.launchpad.net/snap-confine/+bug/1612291
<mup> Bug #1612291: cannot create $SNAP_USER_DATA when using ecryptfs and sudo <Snappy Launcher:New> <https://launchpad.net/bugs/1612291>
<zyga> kgunn: ah, I see, they are treated differently
<zyga> kgunn: based on release.OnClassic one of the lists is not used
<zyga> kgunn: classic being anything but an all-snap image
<tyhicks> zyga: why can't 'owner' be used? are there files being written to those directories that aren't owned by the user?
<zyga> tyhicks: because of sudo, I presume
<zyga> tyhicks: I just tested this
<zyga> tyhicks: the owner check probably checks euid
<tyhicks> zyga: that change allows snaps to read the encrypted files of any user
<zyga> tyhicks: with sudo
<zyga> tyhicks: or with services
<zyga> tyhicks: do you have any other suggestion?
<zyga> tyhicks: currently this is a blocker for SRU according to what mvo said
<tyhicks> zyga: that's the best that can be done in policy
<tyhicks> jdstrand: have any additional thoughts?
<zyga> mvo: ^^
<mvo> zyga: I wonder if we should bite the bullet and just not do it in snap-confine and land all the other fixes instead to avoid that this is needed
<mvo> zyga: seems its a can of worms :/
<liuxg> kyrofa, I just tried to remove the option "--socket="$SNAP_DATA/mysql/mysql.sock"" in the mysql.server, and the mysqld failed to get started. I found that "root.ini" file has only one field "password=xxxxxx".  is there any switch to turn off the "socket" besides that option there in the file? thanks
<jcastro> what component do I log a bug against for the store/login/auth piece?
<zyga> tyhicks: wait, I disagree, this is just for snap-confine, per-app policy already should allow this to make :home work
<tyhicks> oh
<zyga> tyhicks: this is just for snap-confine to setup the data directory, after that we switch the apparmor profile to one that already works OK
<tyhicks> I missed that this was a change for the snap-confine profile
<zyga> mvo: ^^ maybe not all is lost :)
<mvo> zyga: :)
<mvo> puhh
<tyhicks> zyga, mvo, jdstrand: since this is for snap-confine's profile, I'm fine with the change
<morphis> ogra_: ok, its your script creating incorrect symlinks: kernel.img -> vmlinuz-4.4.0-1019-raspi2-*
<mvo> morphis: ha! I suspected its a broken symlink :)
<morphis> :-)
 * mvo feels smug now
<zyga> tyhicks: thanks, I'll take that as an approval to make the change
<tyhicks> that's fine
<balloons> zyga, remember our bash completion discussion in Leiden? I thought there was a bug report for it, but it seems there isn't. I'd like to file one now, under snapcraft I think, as a request for a bash completion interface. Does that make sense?
<zyga> balloons: under launchpad.net/snappy plase
<zyga> please*
<balloons> zyga, do you think it's something snappy itself has to solve? that too was my initial thought, but then I wondered if framing it as an interace request made more sense
<jdstrand> zyga, tyhicks: that change is fine for snap-confine imo
<zyga> balloons: yes
<balloons> zyga, ack. I'll file requesting support. Thanks!
<jdstrand> zyga: I noticed that the /usr/src and /var/log changes aren't in xenial-proposed. can the next upload to xenial-proposed include those?
<jdstrand> zyga: not sure if you saw, I acked the .in PR just now
<zyga> balloons: I'm not sure, mvo is handling SRU in a custom way to make things effectively land; I'm working on upstream changes and on making testing reliable now
<zyga> balloons: that change will be in 1.0.40 upstram
<zyga> upstream
<zyga> jdstrand: thanks!
<mup> Bug #1612303 opened: Snaps don't support bash autocompletion <Snappy:New> <https://launchpad.net/bugs/1612303>
<balloons> zyga, are you saying the autocompletion is coming?
<jdstrand> balloons (and zyga): that is a dupe of bug #1590767
<mup> Bug #1590767: Support snap installed completion scripts <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1590767>
<balloons> jdstrand, bah I was looking and looking for the dupe bug. I swore I'd seen it
<mup> Bug #1612303 changed: Snaps don't support bash autocompletion <Snappy:New> <https://launchpad.net/bugs/1612303>
<zyga> balloons: no :)
<zyga> balloons: It's probabyl very hard or impossible for untrusted snaps
<zyga> balloons: and even if the actual runtime may require changes to existing completion support
<zyga> balloons: but you asked :)
<jdstrand> zyga: I actually outlined a way to pull it off in the bug
<zyga> jdstrand: oh, interesting, I'll read that with interest then
<kgunn> jdstrand: so based on what zyga's answer was, i think mir actually is an implicitslot (not classic)
<zyga> kgunn: is't mir a slot on the mir snap?
<zyga> kgunn: or on the core snap on classic when mir is a package
<zyga> mvo: can you please comment on https://github.com/snapcore/snap-confine/pull/97 so that I can land it
<mup> PR snap-confine#97: Restore creation of $SNAP_USER_DATA <Created by zyga> <https://github.com/snapcore/snap-confine/pull/97>
<ogra_> morphis, did you update to the latest ?
<ogra_> morphis, i fixed that yesterday morning
<tgm4883> What's the process for getting something added as an interface? I don't see an interface that would give access to what I need
<tgm4883> Looking at http://snapcraft.io/docs/reference/interfaces
<zyga> tgm4883: file a bug, work on a patch, discuss this, read http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
<liuxg> skip-networking
<tgm4883> zyga: ah cool, thanks
<kgunn> zyga: so it's actually kind of all of the above.... mir is a snap on core, mir is a package on u8-classic, mir will be part of some-os-snap for u8-personal
<zyga> kgunn: so the interface is the same in both cases, just the decision if classic should get the mir slot should be dynamic, based on availability of mir as a classic package
<zyga> kgunn: i'd start simple
<zyga> kgunn: make mir a snap, ignore the classic package
<kgunn> zyga: in which case, it should be an implicitslot right?
<kgunn> also fwiw, mir is in main, so technically all classic ubuntu will have it
<jdstrand> kgunn: you're goal is to have it be implicit on classic aiui. that's fine but it won't work as is since on unity8 classic mir will be unconfined and installed via debs. like I said, that can be fixed in a future. I suggest moving to implicitClassic then. that way the slot doesn't show up on all-snap systems unless the snap is installed and shows up on classic
<jdstrand> kgunn: or if you are keeping it simple now, just remove it from implicit altogether
<kgunn> jdstrand: but what about u8-personal?
<jdstrand> kgunn: you said that is an all snaps system
<kgunn> yes, all snaps
<jdstrand> kgunn: which means either it is installed as a snap
<jdstrand> kgunn: or there is a different 'core' image that has it preinstalled
<kgunn> yes
<jdstrand> kgunn: since that different core image doesn't exist today, don't pretend it does
<jdstrand> kgunn: therefore, leave out of implicit
<kgunn> ok
<jdstrand> when the landscape changes, we can adjust that
<kgunn> alright, was just trying to plan ahead
<jdstrand> it sounds like we may need some detection logic on whether or not it is implicit. again, future stuff
<kgunn> jdstrand: or would there be yet-another implicit list?
<jdstrand> maybe
<kgunn> like is implicit really just ubuntu-core?
<kgunn> implicit today that is
<jdstrand> well, afaik no one has blessed an alternative core for personal as a thing
<jdstrand> so it's not all thought through
<jdstrand> it could easily be implicitPersonal or something
<kgunn> jdstrand: oh i see, so you could say....it just shows up as part of some-other-snap-on-top-of-core
<jdstrand> or there could be detection
<kgunn> right, that's what i was thinking implicitPersonal
<jdstrand> kgunn: it depends on how personal is put together. is it core as it exists today plus a bunch of snaps or is it a fat alternative core
<kgunn> jdstrand: one last thing, you are right that today mir is on classic...in which case, i should move it back to classic
<kgunn> jdstrand: per the Heidelberg sprint I believe everyone wants core-as-today + another-snap-with-u8-on-top
<kgunn> niemeyer: ^ right ?
<jdstrand> afaik that question has never been answered. people have expressed opinions, but until we know the answer it is hard to implement for it. but this is minor/easy stuff to implement. I like zyga's advice of sticking with just as a snap for now and we adjust later
<zyga> ++
<ogra_> geez ... using apt (instead of apt-get) on a serial console ends in a large mess of chars on my screen
<jdstrand> kgunn: well, mir on classic... eh, it is possible there, but it isn't by default
<jdstrand> kgunn: ie, debs have to be installed and you have to be running the unity8 session
<jdstrand> kgunn: so it really shouldn't simply be offered on classic I don't think, cause most classic systems today don't actually have it (hence the detection idea)
<kgunn> jdstrand: no...that's not right, mir is there, you don't have to be logged in
<kgunn> mir can run on X too in u7
<kgunn> it's a tinker-toy....it can do a lot of differnt things
<kgunn> *logged into u8
<jdstrand> I'd really prefer to land this PR as is and work through the classic user cases in a separate PR
<kgunn> jdstrand: ok, no prob...so i remove from implicit altogether for the moment
<jdstrand> kgunn: I think that is best. once landed if in another PR you want to update the manual testing instructions for all the user stories on classic then we can advise on how to implement the policy changes
<kgunn> k
<joc_> zyga: interface question - should i be able to test the number of attrs on plug with len(plug.Attrs) in my SanitizePlug function?
<jdstrand> kgunn: based on your comment of core snap + u8 snap, it sounds like what would be committed today would work there. mir is either an installed snap or it is bundled in u8 and u8 slots: [mir]
<jdstrand> kgunn: so all good
<kgunn> yep
 * jdstrand suspects the nicest dev experience would be mir bundled in u8, so then clients could simply plugs: [unity8]
<jdstrand> anyhoo
<jdstrand> that's for another day :)
<zyga> joc_: yes but you have to remember about the type
<zyga> joc_: interface{} has no len()
<zyga> joc_: you have to type-assert
<zyga> joc_: (that can fail)
<zyga> joc_: then you can check the length
<ogra_> mvo, just FYI, all kernel snaps built from my new branchs work fine and sideload fine, tested on all boards and kvm (tomorrow morning i'll rip out everything unneeded from livecd-rootfs)
 * jdstrand is really not terribly excited that we aren't chdir()ing to some snap-specific dir
<zyga> jdstrand: hmm, that would break git/bzr/hg as a snap
<jdstrand> I realize that none of the options are perfect, but not doing it results in weird behavior
<jdstrand> zyga: well, every snap I do ends up in a dir that isn't accessible
<jdstrand> *every*
<joc_> zyga: something like len(plug.Attrs.(string)) ?
<jdstrand> why can't the git/bzr/hg snap developers do a chdir($OLDHOME) or something?
<zyga> joc_: no, because type assertion should be handled by an assignment to a pair
<zyga> joc_: look at how we extract stuff out of attrs in bool-file or serial-port
<jdstrand> the "don't do a chdir()" only makes any sense at all if you plugs home
<jdstrand> the home interface sucks
<zyga> anway, I have to go AFK now, sorry
<jdstrand> we shouldn't be pushing people towards using it
<zyga> jdstrand: I think we will have more interfaces later and doing this chdir would just break the world, plus there's devmode and we want people to feel at home with snaps
<jdstrand> zyga: how is: $ ls
<jdstrand> ls: cannot open directory '.': Permission denied
<jdstrand> feeling at home?
<jdstrand> you are forcing anyone who doesn't use 'home' to do the chdir
<zyga> jdstrand: more than ls /
<joc_> zyga: i understand how to get a particular attribute but just knowing how many there are of any type i'm not sure
<zyga> jdstrand: or /home/foo/stuff $ ls
<zyga> jdstrand: that prints stuff that's in another directory
<jdstrand> zyga: my point is if I don't plugs home I'm in a dir I can't do anything with. that is poor
<ogra_> [ 9037.726155] audit: printk limit exceeded
<ogra_> oh, lovely
<jdstrand> so devs will be conditioned to plugs: home
 * zyga needs to run now
<zyga> sorry joc jdstrand, let's talk later
<jdstrand> which is really bad security-wise
<jdstrand> that's fine. I'm mostly ranting
<jdstrand> though I would prefer to see this handled better
<jdstrand> ogra_: sudo sysctl -w kernel.printk_ratelimit=0
<ogra_> i think we really need to turn off the "ALLOWED" spam on all-snap images ... since you can only use the classic shell in devmode that makes the logs go crazy
<ogra_> jdstrand, ah, that should perhaps become a default firstboot setting on all-snaps
<ogra_> unless there are plans to quieten apparmor in --devmode
<ogra_> oh
<ogra_> now that one is actually more interesting
<ogra_> (classic)ubuntu@localhost:~/kernel-test-snap$ sudo cat snapcraft.yaml
<ogra_> cat: standard output: Permission denied
<ogra_> heh
<jdstrand> the whole point of --devmode is to log what is against policy
<jdstrand> --devmode with no logging is just unconfined
<ogra_> well, then we probably need an additional "mode"
<jdstrand> ogra_: why is it noisy?
<ogra_> like --unconfined ;)
<jdstrand> we should fix the noisy accesses
 * jdstrand notes that it shouldn't log something that is allowed by the policy, only something that is not allowed by the policy
<ogra_> jdstrand, well, i'm building packages inside a classic chroot ... and the classic snap uses the chroot command ... so nearly every action i do causes a line
<ogra_> though i'm more curious why i dont have access to stdout in the dragonboard classic shell
<ogra_> (classic)ubuntu@localhost:~/kernel-test-snap$ ls -l /dev/std*
<ogra_> lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stderr -> /proc/self/fd/2
<ogra_> lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stdin -> /proc/self/fd/0
<ogra_> lrwxrwxrwx 1 root root 15 Jan  1  1970 /dev/stdout -> /proc/self/fd/1
<ogra_> hmm, interesting date
<ogra_> (classic)ubuntu@localhost:~/kernel-test-snap$ ls /proc/self/fd/0
<ogra_> ls: cannot access '/proc/self/fd/0': Permission denied
<jdstrand> ogra_: classic chroot on all snaps hasn't been a focus yet for devmode. I suggest talking to tyhicks about the issues you are seeing. but it does seem that the classic snap is a very special case
<ogra_> it definitely is
<jdstrand> (tyhicks is working on various logging things related to devmode)
<ogra_> we should perhaps just makes it as special package with special apparmor profile
<jdstrand> classic chroot isn't really --devmode
<ogra_> it isnt urgent, i'm just playing around with the new images to see what works and what doesnt
<jdstrand> ogra_: that is what I was thinking
<ogra_> well, it moved into a snap
<jdstrand> sure
<jdstrand> and devmode was there so people used it
<ogra_> which we havent done before
<jdstrand> but that isn't disigned
<ogra_> yeah
<jdstrand> designed
 * ogra_ scratches head
<ogra_> (classic)ubuntu@localhost:~$ cat kernel-test-snap/snapcraft.yaml
<ogra_> cat: standard output: Permission denied
<ogra_> (classic)ubuntu@localhost:~$ cat kernel-test-snap/snapcraft.yaml |head -1
<ogra_> name: canonical-snapdragon-linux
<ogra_> so if the output goes through a pipe first i can write to stdout ... how weird is that
<ogra_> (this only happens on dragonboard)
<jdstrand> I bet it has to do with a bug I saw
 * jdstrand goes to find it
<jdstrand> ogra_: could it be bug #1611493
<mup> Bug #1611493: No TTY in snaps. <landscape> <Snappy:Confirmed> <https://launchpad.net/bugs/1611493>
<ogra_> ah !
<ogra_> yeah, that could be it
 * ogra_ lets the boards build their test kernels and goes afk for a bit
<jdstrand> kgunn: sigh, github removed a '*' in my suggestion :\
<jdstrand> kgunn: https://github.com/snapcore/snapd/pull/1299/files#r74456003
<mup> PR snapd#1299: create mir interface <Reviewed> <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1299>
<jdstrand> kgunn: apologies
<kgunn> jdstrand: weird i tested it manually and it worked!
<jdstrand> kgunn: it would work for /dev/tty0-9 but tty10 it would not
<jdstrand> kgunn: this is future proofing
<kgunn> k
<kgunn> i didn't think that looked right, i should've asked
<mvo> ogra_: cool, are they auto-uploaded yet ?
<mvo> ogra_: I see that core is now auto-accepted and auto-published, neat
<mvo> ogra_: is that all the chagnes in the review scripts?
<ogra_> mvo, kernels arent auto-uploaded yet i'lll get that going tomorrow
<ogra_> core is though ...
<ogra_> mvo, i cant tell what the review scripts will say about the LP build kernels yet
<ogra_> (but given that it takes weeks between kernel changes i'll happily go on doing them manually til everything is sorted ... core was more important due to daily builds
<ogra_> )
<mup> PR snapd#1548 closed: many: add new `snap prepare-image` command for ubuntu-image <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1548>
<mup> PR snapd#1664 closed: integration-tests: add update-rollback stress tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1664>
<powersj> Does the ant plugin allow parameters today so I can specify `ant exejar`?
<mup> PR snapcraft#721 opened: Set owner/group for directories in stage and prime <Created by josepht> <https://github.com/snapcore/snapcraft/pull/721>
<josepht>  powersj: it doesn't look like it from scanning the plugin source
<powersj> josepht, is this what you were looking at: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/ant.py
<josepht> powersj: yes
<powersj> josepht, thanks
<josepht> powersj: if it's something you need please file a bug so we don't forget about it. :)
<mup> PR snapd#1669 opened: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669>
<powersj> josepht, will do shortly, thanks! was trying to snap up weka
<mup> PR snapcraft#722 opened: Set owner/group for directories in stage and prime <Created by josepht> <https://github.com/snapcore/snapcraft/pull/722>
<mup> PR snapcraft#722 closed: Set owner/group for directories in stage and prime <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/722>
<mup> PR snapd#1670 opened: osutil: do not error if the SUDO_USER can not be looked up <Created by mvo5> <https://github.com/snapcore/snapd/pull/1670>
<mup> PR snapcraft#721 closed: Set owner/group for directories in stage and prime <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/721>
<mup> PR snapcraft#723 opened: Set owner/group for directories in stage and prime <Created by josepht> <https://github.com/snapcore/snapcraft/pull/723>
<mhall119> zyga: kyrofa: where do we have good documentation on the snap store API for publishing snaps?
<kyrofa> mhall119, like the API used by snapcraft to upload snaps to the store and release to channels?
<mhall119> yeah
<mhall119> http://snapcraft.io/docs/reference/snapcraft lists "upload" still, but not "push"
<niemeyer> kgunn, jdstrand: Yes, I've been hoping since we first talked about this that we'd have a single core snap
<niemeyer> In the last sprint, there were indications that this will indeed be the direction we'll move towards
<niemeyer> As in, not have a personal-ubuntu-core
<niemeyer> But just the one and true
<kyrofa> mhall119, this is the only one I know about: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex
<kgunn> jdstrand: so now that tests have passed...do i need to do anything? or will it eventually just get merged
<arges> sergiusens: hey. during the build phase of snapcraft, where does the snapcraft.yaml file go?
<arges> I have some code that parses version strings like so: VERSION=$(shell git describe --tags 2>/dev/null || grep ^version snapcraft.yaml | cut -f 2 -d ' ')
<mup> PR snapd#1670 closed: osutil: do not error if the SUDO_USER can not be looked up <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1670>
<kyrofa> arges, nowhere-- snapcraft generates the snap.yaml, and only reads the snapcraft.yaml to do that
<arges> kyrofa: could I read the snap.yaml during the build phase? Mostly a trick for me to parse a version string
<kyrofa> arges, no. The snap.yaml isn't actually generated until prime
<kyrofa> arges, also, during the build phase each part is built in what is intended to be an internal directory whose path could change, so we don't recommend hard-coding relative paths to get back to the snapcraft.yaml either
<arges> kyrofa: ok. i'll adjust looks like the .git directory is in the build
<arges> so I could parse things there
<kyrofa> arges, indeed, that could work
<arges> kyrofa: thanks
<jdstrand> kgunn: nothing you or I need to do. zyga or someone else will merge it
<jdstrand> kgunn: thanks for all the hard work on it! :)
<kgunn> cool, and thanks jdstrand for all the help and pateince...i learned a ton
<mhall119> kyrofa: it's for krita, who already use snapcraft, so I'll stick with it's interface
<jdstrand> glad to hear :) you're welcome
<arges> hi is there a good snapcraft example of handling sockets exposed in /var/run ?
<arges> i take it i'll have to move my socket from /var/run?
<kyrofa> arges, I put mine in $SNAP_DATA
<arges> kyrofa: yea that seems reasonable
<kyrofa> arges, if /var/run is writable (not sure), it's probably /var/run/snap.<snapname>/ or something similar
<arges> i didn't see the later grepping through the source. but I could be missing something
<jdstrand> ogra_: fyi, this isn't really more than what you had, but in the interest of sharing: lp:~jdstrand/+junk/snap-sshfs.jdstrand
<powersj> Is there a command to see all available parts? or is the wiki the primary list?
<popey> powersj: snapcraft search
<powersj> popey, oh it finds parts as well?
<popey> thats only what snapcraft search does
<powersj> ah, I was getting snap find and snapcraft search crossed in my head.
<blackboxsw> hmm, I'm getting ascii encode errors when I attempt to add after: [desktop/gtk2] to my snap.  it hangs on the slash any tips?
<blackboxsw> 'ascii' codec can't encode character '\u29f8' in position 38: ordinal not in range(128)
<blackboxsw> tried copying directly from snappy-playpen as other examples just worked and seem to have the same content
<mup> Bug #1612440 opened: Full systemd socket activation support <lxd> <Snappy:New> <https://launchpad.net/bugs/1612440>
<mup> Bug #1612441 opened: Cannot include wiki-defined part desktop/gtk2 in after clause <landscape> <Snappy:New> <https://launchpad.net/bugs/1612441>
<mup> Bug #1612441 changed: Cannot include wiki-defined part desktop/gtk2 in after clause <landscape> <Snappy:New> <https://launchpad.net/bugs/1612441>
<mup> Bug #1612453 opened: `snap connect` requires me to type ubuntu-core <Snappy:New> <https://launchpad.net/bugs/1612453>
<mup> PR snapcraft#724 opened: In travis, install the static checkers with pip <Created by elopio> <https://github.com/snapcore/snapcraft/pull/724>
<mup> Bug #1612459 opened: SM should by default point valid kickstart file if nothing is given <Snappy:New for sgurumurthy> <https://launchpad.net/bugs/1612459>
<mup> Bug #1612459 changed: SM should by default point valid kickstart file if nothing is given <Juniper Openstack:New for nitishk> <https://launchpad.net/bugs/1612459>
#snappy 2016-08-12
<mup> Bug #1611083 changed: Users without xenial-updates/universe can't get snapcraft  version 2.11 tour. <Snappy:Invalid> <https://launchpad.net/bugs/1611083>
<mup> Bug #1611080 changed: snapcraft.io says snap find has --broad, but it doesn't <Snappy:Invalid> <https://launchpad.net/bugs/1611080>
<mup> Bug #1611094 changed: http://snapcraft.io/create/ mentions readmes in each tour subdirectory, they are missing <landscape> <Snapcraft:Triaged by didrocks> <Snappy:Invalid> <https://launchpad.net/bugs/1611094>
<mup> Bug #1611098 changed: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611098>
<mup> Bug #1611099 changed: snap install tab completion lacking filenames <landscape> <Snappy:New> <https://launchpad.net/bugs/1611099>
<mup> Bug #1611108 changed: snap install without sudo asks to login to snap store <apport-bug> <i386> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1611108>
<lpotter> a debian build plugin would be nice
<tealeg> Hey, anyone about?  I have a question.
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/99
<mup> PR snap-confine#99: Disable owner checks for 14.04-style private home <Created by zyga> <https://github.com/snapcore/snap-confine/pull/99>
<tealeg> Is there an easy way to pass environment variables into the environment of an app delivered by a snap?
<tealeg> I've done this currently by wrapping the binary in a shell script that is the publicly available app
<tealeg> ... but that seems to leave the binary itself without the permissions provided by the plugs I associated with the wrapper script.
<tealeg> (that's my hypothesis at least)
<zyga> tealeg: can you give me a practical example
<tealeg> zyga: sure.
<zyga> tealeg: what you are doing works very well and is used by many apps already
<tealeg> zyga: I have an emacs snap
<zyga> tealeg: there's upcoming upstream support for defining environment in snapcraft.yaml but it's a long way to go (arguably very little works remains but it took as a while to get there)
<tealeg> zyga: when I run emacs from the snap, it cannot read files in my HOME directory, though the wrapper script has the home plug defined
<tealeg> zyga: (with strict confinement turned on, of course)
<zyga> tealeg: how do you determine that it cannot read files in the home directory?
<zyga> tealeg: do you see apparmor denials?
<tealeg> zyga: it tells me that - I try to open a file there, and it says it can't read it
<tealeg> zyga: I can look, just a mo
<zyga> tealeg: can you run 'journalctl -f' and try that now?
<tealeg> zyga: so, yes, apparmour is denying it
<tealeg> zyga: shall I paste the lines someplace?
<zyga> tealeg: yes, please
<zyga> one line should be enouh
<zyga> enough *
<zyga> tealeg: please also pastebin your snapcraft.yaml if you can
<tealeg> zyga: ok..
<tealeg> zyga: here's the apparmour: http://pastebin.com/wtxPkVTh
<zyga> ok, that's enough
<zyga> you cannot open dotfiles
<zyga> even with the home plug connected
<tealeg> zyga: oh?
<zyga> there's an ongoing discussion about this on the mailing list and on launchpad bug reports
<tealeg> zyga: let me try a non-dotfile :-)
<tealeg> zyga: yup, that's it!
<tealeg> zyga: thanks.  OK, I'll accept that as something ongoing for now.  Thanks for your time.
<ogra_> mvo, wow, you keep the builders busy today :)
<zyga> ogra_: ? :)
<mvo> ogra_: yes, created a candidate ubuntu-core for the next stable update of ubuntu-core
<mvo> ogra_: (the snap)
<ogra_> yay
<mvo> ogra_: its all in the candidate channel now, needs QA testing next
<ogra_> k
<ogra_> well, the arm builds are still sitting there (as usual since a week)
<mvo> ogra_: I will do one-off uploads for pi2 and dragonboard kernels that make kernel.img/initrd.img real files, this is important to unbreak ubuntu-image. just fyi
<morphis> ogra_: ok, building kernel snaps with your build scripts doesn't really work, no I get: Warning: no boot file name; using 'C0A8B2C8.img'
<ogra_> mvo, plkeas only dragonboard, i'm in the middle of setting up the auto-build for pc-kernel and pi2-kernel
<ogra_> *please
<ogra_> morphis, are you on the lates ?
<ogra_> t
<ogra_> morphis, they work fine on LP
<mvo> ogra_: if that is ready today thats good enough, otherwise I will just do it, its not much work and will unbreak people
<morphis> ogra_: hm, let me try that then
<ogra_> mvo, pc-kernel is ready in 10min or so
<mvo> ogra_: \o/
<ysionneau> zyga: hmmm your refresh-bits script says I don't have systemd but I do :/
<ysionneau> it searches for systemd-activate but indeed I don't seem to have it
<ogra_> mvo, do we want a pc-kernel-i386 or should i just build two arches under the same name ?
<zyga> ysionneau: are you on yakkety?
<ysionneau> I'm on Debian testing :o
<mvo> ogra_: pi2-kenrel is actually the one where this matters (the filename) and the dragonboard one of course
<zyga> ysionneau: or debian testing, yes
<mvo> ogra_: two under the same name seems ok, unless I hear otherwise
<zyga> ysionneau: i didn;'t have time to figure that out yet, how do you run socket activated services in more recent versions of systemd
<mvo> ogra_: its not clear yet if i386 will be "pc" as well for the gadget name
<zyga> ysionneau: if you figure it out please send me a patch
<zyga> ysionneau: that's something systemd changed upstream, maybe they just renamed the command
<ogra_> mvo, well, pi3 also ises pi2-kernel, so i  dont think the gadget name is that important
<ysionneau> zyga: to do that I usually just do a .service with a ListenStream part
<ysionneau> one unit file for the socket (WantedBy=sockets.target) and one unit file for the service
<ysionneau> ah to actually run it
<zyga> ysionneau: :)
<ysionneau> systemd-socket-activate <=
<ysionneau> this binary
<ysionneau> https://www.freedesktop.org/software/systemd/man/systemd-socket-activate.html
<ogra_> mvo, i'm picking 4.4.0-35-1 as the version. so we can bump the last part for package specific changes (the branch is set up for auto-build on commits, so if a new kernel lands we bump the version and it auto-builds (later i'll automate that and watch the linux-meta package in -updates)
<ogra_> is the versioning ok with you ?
<ogra_> (this is pc-kernel)
<zyga> ysionneau: please try to patch refresh-bits to use this
<ysionneau> anyway I don't seem to need this since I will run on a target
<zyga> ysionneau: as I said, I'd love to have the patch, I'm just hacking on something eles now (snap-confine)
<ysionneau> so I guess I'll just comment it since I'm in a hurry
<zyga> ysionneau: there's a bug in --host where it still looks for systemd-activate on the host
<ysionneau> yep no problem I'll comment the code
<zyga> ysionneau: thanks!
<ogra_> mvo, https://code.launchpad.net/~snappy-dev/+snap/pc-kernel ---> to build you do: bzr branch lp:pc-kernel-snap -> bump the version in snapcraft.yaml, commit -> bzr push lp:pc-kernel-snap ... go to the url and watch it build for i386 and amd64 :)
<mvo> ogra_: neat
<ogra_> (or just request a manual build on the page if you dont want to bump the version)
<ogra_> now setting up the same for pi2-kernel
<ogra_> note that this comes all from the same branch, they just differ in their snapcraft.yaml
<ogra_> (we should keep the Makefile in the branches in sync between them)
<ysionneau> zyga: very cool ! your script succeeded in building snapd o/ Thanks! One small remark, you base your detection on the user space arch by using uname -m on the target, which does not work in case your kernel is aarch64 and user space is armhf. I hardcoded armv7l to make it work
<ogra_> now the exciting moment ...
 * ogra_ watches the snaps being uploaded to the store
<ogra_> (havent tested that yet)
<zyga> ysionneau: interesting, please feel free to report thos bugs so that at least the problem is not lost
<zyga> ysionneau: (straight on github)
<zyga> ysionneau: and if you have time please send pull requests
<mvo> ogra_: a pi2 kernel upload will not break anything, right? this unblocks my new u-d-f (and ubuntu-image) so I'm keen to put it into the store for testing
<ogra_> mvo, well, how do you build it
<mvo> ogra_: manual, snapcraft snap
<mvo> ogra_: I just need to fix the symlinks
<mvo> (as a one-off build)
<mvo> (its trivial)
<ogra_> mvo, btw, we need store people to remove the review tools block for kernel for pc-kernel https://myapps.developer.ubuntu.com/dev/click-apps/5507/ (can you approve them =
<ogra_> ?)
<ysionneau> zyga will do the reporting at least, thanks
<mvo> ogra_: I can approve them, one sec
<ogra_> mvo, well, i would prefer we use the new way right away to test the symlinks there too :) but if you need it right now, go for it ... my set up takes still 10-15min
<ogra_> (thogh given the state of armhf builders it might end up being 3-4h)
<mvo> ogra_: 10,15min is fine, then I won't waste enegery on it, thank you
<mvo> ogra_: heh :) if 3-4h I may become too impatient ;)
<ogra_> mvo, can you bump build scores if needed ?
<mvo> ogra_: but its fine, its literally 5min work for me
<mvo> ogra_: unfortunately I can't :/
<ogra_> k, lets see ...
<mvo> ogra_: I think we should get auto-high-score just like for the old image builds
<ogra_> yeah
<mvo> ogra_: kenrels approved
<ogra_> thx
<ogra_> mvo, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel ... i asked for a score bump
<mvo> ogra_: ta
<ogra_> mvo, for that ... same procedure as above ... either bump the version and commit/push ... or do a manual build through LP
<mvo> ogra_: neat
<ogra_> for dragonboard i'll do a build in my own test branch since i cant really set up the snap package under the snappy-dev name when i dont have the correct name (i dont want to create cruft there)
<mvo> ogra_: +1
<ysionneau> when creating an interface, if I want to allow a snap to connect to a unix socket, do I just pretend it's like a file and I just give rw access to the file path ?
<ysionneau> or does it need some other special rights since it's not really "just" a file?
<zyga> ysionneau: yes
<zyga> ysionneau: it's just a file
<zyga> ysionneau: you will also need to add appropriate system calls like connect and what not
<zyga> ysionneau: but those are easy to add in a whack-a-mole fashion, just keep editing the generated apparmor and seccomp profiles until both sides work
<zyga> (plug and slot side)
<ysionneau> yes but then I guess I can just use the network interfaces in the snap?
<zyga> ysionneau: did you see my artice about how to create new interfaces from scratch?
<ysionneau> or is it cleaner if the "pimp" (that's my interface name) interface dierctly authorizes the network functions?
<zyga> ysionneau: that's subtly different, it's better to be explicit, over time the network interface may only work for AF_INET and AF_INET6
<ysionneau> zyga: nop, but so far it seems pretty simple
<zyga> ysionneau: so don't use it because it gives you extra thnigs you need, put the extra needs into your own iface
<zyga> ysionneau: zygoon.pl
<zyga> ysionneau: do read it please :)
<zyga> ysionneau: feedback is welcome and appreciated
<zyga> http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
<zyga> ysionneau: if it is real "connect to ip network" then do use the existing network/network-bind interfaces
<zyga> ysionneau: if it is something else, put it into the interface you are creating
<ysionneau> 11:44 < zyga> ysionneau: do read it please :) < ok I will!
<ysionneau> btw I created the "issue" on github for your script
<ysionneau> and added information on the already existing issue about systemd activated sockets
<ysionneau> zyga: ok then yes I need to add the syscalls in my interface since it's just for the unix socket
<zyga> ysionneau: note that we can now do partial argument filtering via seccomp
<ysionneau> "partial" ?
<zyga> ysionneau: https://github.com/snapcore/snap-confine#seccomp
<ysionneau> like only putting a requirement on arg1 and not arg2 ?
<jdstrand> well, when snap-confine finally is SRUd
<zyga> ysionneau: (only integeres, we cannot ever see through pointers)
<ysionneau> yep I know I've played with seccomp a bit in the past
<zyga> jdstrand: hello :)
<jdstrand> which I think has been a good decision-- we'd have to adjust the Depends of snapd to be a version of snap-confine and that would've stopped snapd uploads :)
<jdstrand> zyga: hi! :)
<ogra_> jdstrand, do i have to poke you to get a package exception for "(NEEDS REVIEW) type 'kernel' not allowed lint-snap-v2_snap_type_redflag " for https://myapps.developer.ubuntu.com/dev/click-apps/5507/ ? the builds now come from automatic LP builds (like ubuntu-core)
<ogra_> or is that a store people thing ?
<ogra_> (builds now come from https://code.launchpad.net/~snappy-dev/+snap/pc-kernel )
<ysionneau> I see stuff like that in some apparmor profile : http://pastebin.com/cuynSmmR
<ysionneau> what is it? is this for unix sockets?
<jdstrand> ogra_: you do for the moment but my patch for ubuntu-core can easily be updated for the kernel (and gadget) snaps
<jdstrand> ogra_: do you have a list of registered core, kernel and gadget names that you want me to add?
<ogra_> jdstrand, cool, i'll give you a list later today
<jdstrand> ok
<ogra_> currently pi2-kernel and pc-kernel ... i have some hope we'll get a proper name for the dragonboard soon ... thats the last one in the list
<mvo> jdstrand: hey, do you have a ecryptfs home system and a spare moment to test something? sudo snap intsall --devmode --edge ubuntu-device-flash and sudo DEBUG_DISK=1 /snap/bin/ubuntu-device-flash core 16 --kernel canonical-snapdragon-linux --gadget canonical-dragon --os ubuntu-core --channel=edge -o $(pwd)/dragon.img gives me an an permission denied error on my ecryptfs system but not on my other system. plus no denias in dmesg and I'm a bit lost
<mvo> and wonder if its reproducable on other ecryptfs systems
<jdstrand> mvo: what's the denial? note zyga just committed something to snap-confine yesterday for that
<mvo> jdstrand: no denial that is the "funny" part
<jdstrand> mvo: I can test in a vm easily enough
<jdstrand> mvo: xenial system?
<mvo> jdstrand: strace shows me stat("dragon.img") gets a permissions denied, but only if I run it with snap-confine, if I run the binary directly its fine
<mvo> jdstrand: yeah, xenial
<mup> Bug #1612595 opened: 'Bad system call' when running python3 snap in strict mode <Snappy:New> <https://launchpad.net/bugs/1612595>
<jdstrand> mvo: you said snap-confine-- is this the package from proposed?
<mvo> jdstrand: ups, sorry, ubuntu-core-launcher is the same
<mvo> jdstrand: I meant, when its running under confinement or bind mount stuff
<jdstrand> ok
<mvo> jdstrand: its not clear if its the confinment, probably not as no denials, but its something and I suspect it has to do with ecryptfs
<jdstrand> pulling in -updates now and then will run the command
<mvo> thanks
<mvo> jdstrand: and sorry for hijacking you in your morning :)
<jdstrand> it's fine. almost done confirming
<jdstrand> mvo: failed to create user data directory. errmsg: Permission denied
<jdstrand> mvo: is that what you are seeing?
<jdstrand> mvo: I see that with ecryptfs. without ecryptfs is works. I do have a denial: sec-xenial-amd64 kernel: [  463.066552] audit: type=1400 audit(1470997002.687:24): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/testuser/.Private/" pid=13878 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=0 ouid=1001
<ogra_> mvo, ok, both kernels are building now ... https://code.launchpad.net/~snappy-dev/+snap/canonical-snapdragon-linux https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel
<jdstrand> mvo: perhaps you are hitting kernel rate limiting?
<ogra_> i'll ping you when they are ready for store approval
<jdstrand> mvo: let me see if zyga's commit yesterday fixed that
<ogra_> bah, crap FTBFS
<mvo> ogra_: yay
<jdstrand> mvo: yes, see 450b660ac91d4ced15185dbdbd2b547ae74fdcec
<mvo> jdstrand: this is not what I am seeing, htis error is fixed with the version in -proposed
<jdstrand> is it?
<mvo> jdstrand: sorry, I should have mentioned this
<jdstrand> proposed still has .4
<mvo> jdstrand: well, in the latest snap confine upload
<jdstrand> it isn't fixed there
<mvo> jdstrand: its also in the ppa:snappy-dev/image ppa
<mvo> jdstrand: yeah, its not accepted yet
<jdstrand> I can try that ppa
<mvo> jdstrand: ppa:snappy-dev/image is the one
<mvo> jdstrand: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/6798247/+listing-archive-extra
<jdstrand> .7's yeah, I'm there. trying with .7
<ogra_> hmm, looks like snappy-dev can not builod from a branch owned by ~ogra ...
<jdstrand> mvo: upgrading to .7 it works fine
<jdstrand> mvo: perhaps you are hitting rate limiting *and* your profile in /etc/apparmor.d/usr.lib.snapd.snap-confine didn't get updated?
<jdstrand> (it's a conffile)
<mvo> jdstrand: oh, it works fine, the u-d-f is creating a dragon image?
<jdstrand> mvo: oh wait, I mispoke
<mvo> (i.e. downloading stuff etc)
<jdstrand> Error creating /home/testuser/dragon.img of size 3899999744 to stage image onto
<ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/5573/rev/4/ ready for approval
<mvo> jdstrand: woah, thats a differnt error than the one I got, vm size limitation maybe?
<mvo> ogra_: done
<ogra_> cool
<ogra_> i'll build a test image :)
<jdstrand> mvo: it worked outside of ecryptfs
<ogra_> (while waiting for the dragonboard kernel)
<mvo> jdstrand: oh, interessting
<mvo> jdstrand: the error is different than the one I got though, still interessting
<jdstrand> Aug 12 05:31:26 sec-xenial-amd64 kernel: [ 1346.914860] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-28]
<jdstrand> Aug 12 05:31:26 sec-xenial-amd64 kernel: [ 1346.914868] ecryptfs_write: Error encrypting page; rc = [-28]
<jdstrand> mvo: that is my issue ^
<zyga> jdstrand: you ran out of space
<zyga> ENOSPC
<jdstrand> it looks like I did
<jdstrand> yeah
<jdstrand> that's weird
<jdstrand> it completes in the non-ecryptfs
<jdstrand> which has the same 'not enough space'
<jdstrand> 2198480
 * jdstrand tries to free up some space
<mvo> hrm, 4gb is the minimium right now :/ which is silly, 2 is probably fine
<jdstrand> gimme a few minutes
<mvo> sure, no rush, I might consider lunch in the meantime :) fwiw, the error I get is "Error: Could not stat device /home/egon/tmp/10/dragon.img - Permission denied." (and strace shows that its indeed parted doing a stat() on that file and gets a permission denied error)
<ogra_> mvo, before you go, please approve https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/10/
<mvo> ogra_: sure thing
<ogra_> ubuntu@localhost:~$ snap list
<ogra_> Name         Version              Rev  Developer  Notes
<ogra_> pi2-kernel   4.4.0-1019-raspi2-1  4    canonical  -
<ogra_> pi3          16.04-0.1            1    canonical  -
<ogra_> ubuntu-core  16.04.1              215  canonical  -
<ogra_> ubuntu@localhost:~$
<ogra_> \o/
<ogra_> pi3 works fine, testing pi2 and dragonboard now
<jdstrand> mvo: /home/egon/tmp is an interesting path
<mvo> jdstrand: :)
<mvo> ogra_: nice!
<ogra_> mvo, fyi, once i know all images boot and run, i'll rip out all kernel code from livecd-rootfs, that will massively speed up ubuntu-core builds ...
<ogra_> (a build should be below/around 5min then)
<mvo> neat!
<ogra_> happy lunching :)
<jdstrand> ok
<jdstrand> Error: Could not stat device /home/testuser/dragon.img - Permission denied.
<ogra_> ubuntu@localhost:~$ snap list
<ogra_> Name         Version              Rev  Developer  Notes
<ogra_> pi2          16.04-0.7            12   canonical  -
<ogra_> pi2-kernel   4.4.0-1019-raspi2-1  4    canonical  -
<ogra_> ubuntu-core  16.04.1              219  canonical  -
<ogra_> ubuntu@localhost:~$
<ogra_> pi2 looks good as well ...
<jdstrand> mvo: ok, I can confirm the issue. stat("/home/testuser/dragon.img", 0x7ffe650b4c40) = -1 EACCES (Permission denied)
<jdstrand> mvo: I don't know why it is doing that
<jdstrand> the file exists
<jdstrand> but no denial in the logs suggests DAC
<mvo> jdstrand: thanks for confirming, its super confusing - and outside of ecryptfs it does work for you, right? i.e. in /root ?
<jdstrand> yes, outside of ecryptfs it works fine
<jdstrand> I thought it might've had something to do with the directory perms of the user since ecryptfs uses 700 for $HOME. that wasn't it
<mvo> jdstrand: utterly confusing, also working fine when I run it without ubuntu-core-launcher on ecryptfs
 * mvo really lunches now
<jdstrand> mvo: feel free to lunch-- just trying some stuff. I get the same issue if I 'apparmor_parser -R /etc/apparmor.d/usr.lib.snapd.snap-confine
<ogra_> ubuntu@localhost:~$ snap list
<ogra_> Name                        Version       Rev  Developer  Notes
<ogra_> canonical-snapdragon-linux  4.4.0-1022-1  10   canonical  -
<ogra_> dragonboard                 16.04-0.3     2    canonical  -
<ogra_> ubuntu-core                 16.04.1       218  canonical  -
<ogra_> ubuntu@localhost:~$
<ogra_> and here we go, dragonboard fine as well
 * ogra_ dances
<morphis> ogra_: can you give me again the link to your latest pi3 kernel snap?
<ogra_> morphis, it is in the store (auto-submitted now)
<ysionneau> zyga: I didn't follow your blog post yet but so far I just duplicated home.go builtin interface and modified it, but I don't see my interface when doing "snap interfaces". I added my interface in all.go
<morphis> ogra_: yeah, looking for a download link
<ogra_> morphis, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel
<morphis> thanks!
<zyga> ysionneau: follow my whoole series please, it's lal documented
 * zyga has laggy link today
<jdstrand> mvo: sorry, I think we need tyhicks
<ogra_> mvo, http://paste.ubuntu.com/23049201/ ... 300 lines dropped \o/
<ogra_> (well, actually more like 250 lines ... but still :) )
<morphis> mvo, niemeyer: can you guys merge https://github.com/snapcore/snapd/pull/1502 today?
<mup> PR snapd#1502: Add an interface for tpm <Reviewed> <Created by jessesung> <https://github.com/snapcore/snapd/pull/1502>
<jdstrand> tyhicks: http://paste.ubuntu.com/23049207/ . Note, depending on the diskspace you might need to rm the dragon.img between switching backing and forth from /home/testuser and /home/foo
<mvo> jdstrand: thanks so much
<ysionneau> zyga: yeahh I forgot to add my interface to snap/implicit.go :' good it works now
<mup> PR snapd#1502 closed: Add an interface for tpm <Reviewed> <Created by jessesung> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1502>
<ogra_> mvo, i'm building an ubuntu-core with the above livecd-rootfs change now, please dont publish this set until i did some basic local testing with it
<danwest> just got a messages from 2.14 that the 'copy' plugin was being deprecated in favor for the 'dump' plugin
<danwest> but dump does not seem to be documented on http://snapcraft.io/docs/reference/plugins
<popey> danwest: perhaps file an issue at https://github.com/ubuntudesign/snapcraft.io/issues
<danwest> popey, so I can do that but do we not have any notes, hints or something? looks like the syntax is completely different than 'copy'
<popey> sure, one moment
<popey> here's an example of a snapcraft.yaml which has been updated, linked to this so you can see the diff https://github.com/ubuntu/snappy-playpen/issues/216
<stokachu> zyga: if a snap requires an interface, does that interface get automatically installed?
<popey> copy -> dump, files -> organize, basically
<zyga> stokachu: interfaces are not installed, they are a part of snapd
<zyga> stokachu: plugs and slots exits on specific snaps
<zyga> stokachu: except for the core snap that has some implicitly defined slots, those are also defined by snapd
<stokachu> so if there is a juju plug do i need to make sure juju snap is installed
<zyga> stokachu: or anything else that provides juju slot
<stokachu> like is there a way to tell my snap that it has dependencies on juju
<zyga> stokachu: but yes
<stokachu> how would a user of my snap know to install juju as well?
<zyga> stokachu: not at present
<zyga> stokachu: if the interface name is just juju this could be documented somewhere (or your snap could detect this and recommend something)
<zyga> stokachu: though right now that is not implemented as interface hooks are not yet implemented
<stokachu> doesn't having dependencies on other snaps defeat the purpose?
<zyga> stokachu: it's not a dependency on a snap, it is a plug that is disconnected
<ogra_> mvo, ok, a build after the change takes 5-12 min now (fastest arch is 5 min, slowest (s390x) is 13), just amd64 is done in 6min
<zyga> stokachu: that's a *big* differene
<zyga> *difference*
<stokachu> zyga: right but you still have to install another snap to make the plug connected?
<zyga> stokachu: and connect it as well
<stokachu> so the only way a user would know that is if they readme some documentation after installing my snap?
<zyga> stokachu: yes
<zyga> stokachu: later on your snap can detect this properly and advise the user
<stokachu> would it just install it automatically?
<zyga> stokachu: snapd? not at present; I cannot comment on future features that are not planned at this time
<zyga> stokachu: I would recomemnd that you raise this issue on the mailing list as it is an interesting use case
<zyga> stokachu: and I see how it would be interesting to offer more streamlined integration
<stokachu> well it's basically doing what apt does
<danwest> popey, thanks
<zyga> stokachu: I disagree, there's a big importand difference here; your snap doesn't need juju, it needs what the juju interface provides, a socket, maybe there are many versions of juju
<stokachu> my snap does need juju though
<zyga> stokachu: or a very popular fork of juju called, say, fufu
<stokachu> i see
<zyga> stokachu: no, it needs juju *socket*, not some juju libraries or executables (as it cannot use those)
<stokachu> but if i need to bootstrap i need to run juju executable
<zyga> stokachu: you have to include that in your snap, you cannot use executables from other snaps
<zyga> stokachu: that executable can use a juju socket from the juju interface to talk to some juju (or over the network to talk to anything)
<mup> PR snapd#1550 closed: tests: base security spread tests <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1550>
<stokachu> ok
<stokachu> that clears it up, thanks
<zyga> stokachu: not all the concepts from classic packages and dependencies map to snaps in obvious ways but I strongly believe we're building something better here;
<stokachu> zyga: so do you think my snap is worth being a snap? i have to call out to other executables like lxc, juju, tail, etc
<popey> danwest: no problem
<zyga> stokachu: yes
<zyga> jdstrand: I looked at 14.04 support and it seems that some prctl arguments are not supported
<zyga> jdstrand: do you think it would be sensible to just not support them and not generate / use them in our seccomp profiles?
<mup> PR snapd#1299 closed: create mir interface <Reviewed> <Created by kgunnfront> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1299>
<jdstrand> zyga: hrmm, that is problematic. note that 14.04 also doesn't have apparmor unix mediation
<jdstrand> zyga: at least with apparmor we can update the tools and they will ignore unix rules on an old kernel
<jdstrand> zyga: I'm not sure how to do that with seccomp. I guess check for them at compile time and conditionally add them?
<mup> PR snapd#1671 opened: spread: Use /home/gopath in spread.yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/1671>
<stokachu> need some help with snapcraft, http://paste.ubuntu.com/23049396/ is packaging files twice, see line: 412
<stokachu> and here is my snapcraft.yaml http://paste.ubuntu.com/23049400/, notice that usr/share still exists in the snap even though i have it to be removed under no-docs
<mup> Bug #1612654 opened: snap interfaces cmd should allow printing of detailed plug/slot info <Snappy:New> <https://launchpad.net/bugs/1612654>
<stokachu> sergiusens: ^
<roadmr> hey folks! What's the interface I need for being able to use the setpriority syscall? (the application has a nice() call). Is it process-control IIRC? When will that be available? (it's not on my snapd 2.11)
<zyga> jdstrand: yep, we can do that
<zyga> jdstrand: for 14.04, we can update userspace too I guess (along with the kernel)
<zyga> jdstrand: so maybe the idea is to do nothing :)
<jdstrand> zyga: well, with prctl, I think that is libc. I doubt we want to update that
<zyga> ah I see
<zyga> hmmm, you are right
<zyga> though if it's just libc, we can hardcode the missing defines (somewhat iffy but it'd probably work)
<jdstrand> so apparmor should be fine-- SRU the tools and they'll work fine
<jdstrand> but yeah, will have to come up with something for snap-confine
<jdstrand> zyga: we could just distro patch snap-confine on trusty
<joc_> roadmr: looks like it is in 2.12 which is somewhere in sru
<roadmr> thanks joc_ !
<jdstrand> zyga: pull out the ones that don't exist there. it is cheap
<kalikiana> stokachu: you need to remove it in the part it came from. the no-docs part doesn't contain any files
<stokachu> kalikiana: dont i have to define what to include as well if imove it up to the conjure part?
<zyga> jdstrand: yep, but what I'm doing now allows us to do it pretty easily
<zyga> s/but/and/
<stokachu> kalikiana: what about the duplicate files?
<stokachu> ah the python plugin is pulling in those files
<stokachu> boo
<jdstrand> ogra_: fyi, finally circled around to adding pc-kernel and pi2-kernel to the review tools whitelist and it is in r708. I've not requested a store pull yet cause you said there was one more to add
<jdstrand> ogra_: so, ping me when ready
<ogra_> jdstrand, well, we should probably add that in a separate commit, i'm not sure when niemeyer can actually get hold of sabdfl to finish the dragonboard kernel naming decision
<ogra_> (but now i poked them both ;) )
<jdstrand> roadmr (cc noise][): hey, can you pull r708 of the review tools. it isn't urgent for before the weekend, but sometime next week would be good
<roadmr> jdstrand: sure, checking...
<jdstrand> roadmr (cc noise][): there might be an exceedingly small r709 based on what ogra_ just said
<roadmr> jdstrand: zise maters not, we do or do not :)
<jdstrand> hehe, yeah :)
<roadmr> jdstrand: ok, I'll pull 708 now so it's in the queue
<jdstrand> thanks
<roadmr> jdstrand: any rough ETA on possible 709? so I can remember to ping you $WHENEVER
<ogra_> roadmr, btw, this is awesome ... having the snaps auto-land ... but ... is there a chance that we can also have the publishing automated some day (for now my morning task will be to go to myapps.d.u.c and click publish for all of the nightly builds, would be nice to not have to do that)
<jdstrand> roadmr: no-- it is based on others deciding what to name something
<roadmr> jdstrand: ok no problem, I'll just lurk here then :)
<jdstrand> roadmr: I'll ping you-- you don't have to poll here
<roadmr> jdstrand: awesome, thanks!
<jdstrand> np
<mup> PR snapd#1672 opened: tests: add serial-port interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1672>
<roadmr> ogra_: hm let me poke a bit at publish behavior. So this is a new revision of an existing snap, right?
<ogra_> roadmr, yeah, daily builds of ubuntu-core
<roadmr> ogra_: (I vaguely remember those should be auto-published but I'm sure I'm wrong)
<ogra_> at least for edge they should get auto publishing ...
<ogra_> the other channels can stay on manual
<jdstrand> I thought that was a flag that was toggleable by the publisher (ie, ogra)
<ogra_> i wouldnt knwo where to toggle it then
<jdstrand> the store interface has changed since I last toggled that on something, so not sure it is still there
<ogra_> perhaps it is at the "create new snap" page ... but ubuntu-core was created ages ago
<ogra_> i definitely dont see such an option anywhere in the current UI for the existing package
<roadmr> ogra_: ok "There used to be an option to auto-publish - it's gone now"
<roadmr> on the store that is
<ogra_> yep
<roadmr> ogra_: but cjwatson tells me there's an auto-publish thing on Launchpad
<ogra_> yes, that is what we already use
<roadmr> oh and doesn't that do what you need? Colin says "(intended mainly for use for daily builds and such that publish to edge, but I'm sure there are other uses)"
<ogra_> well, it is "Automatically Upload"
<cjwatson> there are two things
<ogra_> and that works fine
<cjwatson> automatically upload and automatically publish
<mvo> jdstrand: I have an update for #1460 for you, I hope with my trivial changes it is now ready for merge
<mvo> jdstrand: (I'm cleaning out old PRs currently)
<cjwatson> on the edit page, it's the "Store channels:" widget
<cjwatson> so that is absolutely intended to be automatable right now and I believe that's in use
<ogra_> i dont see any publish related bit here
<ogra_> not sure if you have powers enough to see https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+edit ?
<cjwatson> it's spelled "release" there actually
<cjwatson> I think because that's what the terminology is eventually intended to be, though right now it's inconsistent
<jdstrand> mvo: I'll take a look. sorry I didn't circle back to it; it got deprioritized based on sprint outcomes so didn't get back yet
<cjwatson> look under "Automatically upload to store", there's "Store channels" with several checkboxes
<ogra_> nothing about release on that page for me either
<ogra_> there is one checkbox per channel
<cjwatson> right, and under that it says "Channels to release this snap package to after uploading it to the store."
<ogra_> (and only edge is checked, since we dont want to auto-upload to the others)
<ogra_> nope
<cjwatson> right, so that is auto-publishing
<mvo> jdstrand: sure, totally fine, should be good now with my PR
<cjwatson> I'm looking at it right now on prod
<cjwatson> albeit a different page
<cjwatson> ogra_: screenshot
<mvo> jdstrand: (conflict resolved and review feedback addressed)
<cjwatson> ogra_: so are you saying that this isn't auto-publishing to edge right now, despite you having checked that box?
<ogra_> cjwatson, http://imgur.com/a/A29SS and http://imgur.com/a/qQPIj
<ogra_> i get the thumbs up icon but still have to go to the specific revision, scroll to the bottom and click the publish button
<cjwatson> ogra_: the text that you say isn't there is in fact there in your screenshot
<cjwatson> ogra_: "Channels to release this snap package to after uploading it to the store.", right under the "Edge" checkbox
<ogra_> ah, i thought there should be another set of checkboxes along with it
<cjwatson> that is what those checkboxes do
<ogra_> ok, well, it only uploads then ... as you can see in the other screenshot
<roadmr> ogra_: tip: the sliding thingy at the top right also allows you to flip publish status, no need to scroll to bottom
<roadmr> "Publish your application", it will read if it's not published
<cjwatson> ogra_: what am I looking at in that screenshot that indicates that?  it says "Package status is Published"
<ogra_> roadmr, http://imgur.com/a/pfVa7 ... no sliding thing there :)
<ogra_> cjwatson, published are the geen box icons
<ogra_> cjwatson, reviewed and "ready to publish" are the tumbs up ones
<roadmr> ogra_: it's right there... "Package status is Published" followed by "Unpublish". That package *is* published
<roadmr> ogra_: if it were unpublished (actually, do try it; click on "unpublish") you'd get a "Pubish your application" clickable thingy right htere
<ogra_> roadmr, the upload isnt
<ogra_> roadmr, see what revision is selected on the left
<cjwatson> ogra_: how long are you leaving it before you click publish?  because I'm seeing LP hitting the snap-release endpoint in our logs
<roadmr> ogra_: right, I see that...
<ogra_> if i scoll down now, there is a publish button at the end of the page
<ogra_> cjwatson, dunno, the last onse were in that state for about 1h or so
<ogra_> *ones
<cjwatson> ogra_: next time this happens for that snap, please could you not hit Publish and ask me to look at it first?
<ogra_> i yep
<ogra_> -i
<cjwatson> AFAICS LP is doing everything it should
<jdstrand> mvo: oh, neat! I didn't know you could access a private method from the test.go files with builtin.FooPrivateThing
<tedg> So I have a public snap that is published, but I'm getting a 401 unauthorized when trying to install it.
<mvo> jdstrand: yeah, that is the export_test.go pattern, make stuff public *only* for the tests this way
<jdstrand> I wanted to do that with something else (that I fixed differently)
<cjwatson> and we're getting 200 back, so the store is *claiming* that it all worked
<ogra_> ok
<tedg> - Download snap "inkscape" (14) from channel "candidate" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/tIrcA87dMWthuDORCCRU0VpidK5SBVOc_14.snap)
<mvo> jdstrand: its really convinient in a lot of situations
<kalikiana> tedg: 'snap login' again
<jdstrand> mvo: yes :)
<jdstrand> mvo: thanks doubly for the PR-- I wouldn't have known that :)
 * jdstrand -> door
<tedg> kalikiana: Ah, cool. That worked. Does it expire or something?
<tedg> I wouldn't have thought a public published snap would require a login.
<roadmr> tedg: it's not the snap's fault
<roadmr> tedg: at some point you did login, so you have auth creds stored somewhere...
<roadmr> tedg: but those go stale, that's why you get the 401
<tedg> roadmr: Ah, I see.
<roadmr> tedg: if you ever logged in, snapd would send the creds regardless of the snap's freeosity
<roadmr> tedg: so 1) snap login fixes it now by manually updating the creds
<roadmr> tedg: soon snapd will take care of refreshing things in the background so you don't have to reauth
<roadmr> tedg: 3) sorry about that :(
<zyga> mwhudson, jdstrand: can I please have commit access to //anonscm.debian.org/collab-maint/snap-confine.git
<zyga> to the writable side
<ogra_> mvo, hmm, seems snap refresh for ubuntu-core on the pi2 breaks uboot.env
<mvo> ogra_: in what way?
<ogra_> after a frefrsh i just had the device sit at the uboot prompt ... a reset got it back booting
<mvo> ogra_: the very first image had a bug that would kill all vars on the first reboot (you reported that iirc). its not this issue, is it? that got fixed
<ogra_> but after this http://paste.ubuntu.com/23049560/ ... so it worked then ... i have to check what happened with uboot when we have a new ubuntu-core to upgrade to ... i was to slow with attaching screen to see what happened
<ogra_> mvo, no, then it wouldnt work fine after an extra reset
<ogra_> i didnt see what actually happened, but fater the reset i saw it writing uboot.env before it attepted the boot ... so there was a saveenv somewhere happeneing
<ogra_> s/fater/after/
<ogra_> anyway, with that one obstacle, upgrades seem to work
<ogra_> the system behaves fine
<ogra_> bah
<ogra_> next reboot is broken agan
<ogra_> http://paste.ubuntu.com/23049567/
<mvo> ogra_: this looks like snap_core/kernel is unset
<ogra_> and boots fine again after a reset
<mvo> ogra_: can you dump the environment?
<ogra_> (and the writing uboot.env is a red herring, it does that every boot)
<mvo> ogra_: I suspect it boots back to the previous core? or is it actually booting the write one?
<ogra_> it boots to the new core ... seems all fine after calling a reset
<ogra_> gime a sec while it finished the succesful boot
<jdstrand> zyga: I'm not a Debian dev (always been on my list, but alas)
<ogra_> *finishes
 * ogra_ reboots
<ogra_> bah, and now it doesnt fail
<ogra_> how weird
<ogra_> this seems to be random
 * ogra_ reboots franticly 
<DrZ> Hi All
<ogra_> mvo, could it be that when we update ubuntu-core we update the snap_core var but unset snap_kernel or some such ?
<mvo> ogra_: I don't know, the dump of the environment (or a copy of the uboot.env file for me) would be great
<mvo> ogra_: than I can debug
<ogra_> mvo, yeah, but it now boots reliably
<mvo> lol
<ogra_> so the dump wouldnt help
<mvo> totally random?
<mvo> crazy!
<ogra_> it did that in two boots after the update
<DrZ> Does anyone find the whole parts thing really confusing??
<ogra_> and since then the last 5 just worked
<DrZ> I don't understand it
<ogra_> and i'm on the right ubuntu-core (230)
<mup> PR snapd#1671 closed: spread: Use /home/gopath in spread.yaml <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1671>
<ogra_> mvo, oh, i'm worng it actually switched back to 219 ... so let me try that again ...
 * ogra_ snap refreshes ubuntu-core
<DrZ> How do I know what mystical keywords to use for parts?
<ogra_> mvo, eeek ... it now refreshes to the last stable ubuntu-core (the image was built with edge) ... so it goes backwards
<DrZ> Do I use the deb package name in stage-packages?
<ogra_> DrZ, yes
<DrZ> I want to depend on libgraphicsmagick but I don't know how
<mvo> ogra_: yeah, the switching back is expected, if it fails to boot it will revert to the previous one
<mvo> ogra_: that smells like snap_try_core was not setup
<ogra_> mvo, right, but in my case it actually first booted to 2330
<ogra_> err
<ogra_> 230
<ogra_> gimme a sec, refreshing with --channel edge
<ogra_> ok, rebooting now
<ogra_> or wait ...
<DrZ> @ogra Thanks!
<nothal> DrZ: No such command!
<ogra_> snap_core=ubuntu-core_219.snap
<ogra_> snap_kernel=pi2-kernel_4.snap
<ogra_> snap_mode=try
<ogra_> snap_try_core=ubuntu-core_230.snap
<ogra_> mvo, ^^
<ogra_> from fw_printenv before reboot
<mvo> ogra_: oh, that is the issue
<mvo> ogra_: thanks, I work on a fix
<ogra_> mvo, do you notice the issue ?
<ogra_> :)
<mvo> ogra_: yes
<ogra_> oh, how i love that we can now quickly build ubuntucore for quick update testing ... :)
<DrZ> Unknown plugin for sample ?
<roadmr> hey folks! the copy plugin says it's deprecated, replace with dump, but dump is not a drop-in replacement and I'm not finding any docs or examples on how to use it. Any pointers?
<DrZ> Oh I use this as the plugin for my Qt5 app "desktop/qt5" ?
<DrZ> Unknown plugin desktop/qt5 =/
<mup> PR snapd#1673 opened: partition: Revert "clear snap_try_{kernel,core} on success" <Created by mvo5> <https://github.com/snapcore/snapd/pull/1673>
<DrZ> http://pastebin.com/DAWbwUK5  Anyone have a min?
<DrZ> Source property doesn't match required schema
<DrZ> I give up. This just isn't easy to understand.
<stokachu> DrZ: hi
<stokachu> you need to set keys for each part
<DrZ> Oh hi
<stokachu> DrZ: https://github.com/conjure-up/conjure-up/blob/master/snapcraft/snapcraft.yaml
<DrZ> Keys?
<stokachu> look at mine for example
<mup> PR snapd#1674 opened: Interfaces: Builtin: add Udisks2 and Pluggable Storage <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1674>
<jdstrand> mvo: ok, I merged it. the integration tests are failing but in a way that looks unrelated
<jdstrand> mvo: other tests are still running
<mvo> jdstrand: yes, there is a regression with snap-confine
<DrZ> Which part is the keys/
<DrZ> ?
<DrZ> The conjure directly under parts:
<DrZ> Is that a key?
<stokachu> yea
<stokachu> conjure:, juju:
<stokachu> those define each section of your parts
<stokachu> you can name them whatever you want
<DrZ> Oh so my desktop/qt5 is wrong then
<stokachu> looks like your tabbing is off
<stokachu> everything under desktop/qt5 should be indented
<DrZ> Omg its doing something!
<ogra_> magic !
<DrZ> So it downloaded some stuff then tried to build desktop/qt5
<DrZ> Then failed because no make file
<DrZ> or targets
<DrZ> Not sure how to proceed.
<ogra_> DrZ, try https://gitter.im/ubuntu/snappy-playpen ... they are perhaps better at helpning with snap building
<DrZ> Thanks ogra.
<DrZ> Sorry for filling up the place with my spam. xP
<DrZ> I'll let myself out. x)
<ogra_> no, it is fine here, we're all just overly busy today it seems
<ogra_> this channel is correct ... but your chances are today better in the playpen gitter channel i guess
<elopio> didrocks: re https://github.com/ubuntu/snappy-playpen/pull/195#issuecomment-238778585 I need more permissions on the ubuntu org in order to use it in docker hub
<mup> PR ubuntu/snappy-playpen#195: Add docker files for testing the playpen snaps <Created by elopio> <Merged by didrocks> <https://github.com/ubuntu/snappy-playpen/pull/195>
<DrZ> Its alright I should get busy too.. since im currently at work. Trying to create a snap today on teh side. :)
<mup> PR snapd#1635 closed: interfaces: builtin: add pluggable storage interface <Created by ssweeny> <Closed by ssweeny> <https://github.com/snapcore/snapd/pull/1635>
<mup> PR snapcraft#725 opened: Support having the snapcraft.yaml in a subdir <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/725>
<DrZ> Chat later!
<mhall119> sergiusens: didrocks: is snapcraft cleanbuild completely broken for anything that uses a desktop launcher?
<mhall119> 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128)
<mhall119> Command '['lxc', 'exec', 'snapcraft-ethologically-animistic-corrinne', '--', 'snapcraft', 'snap', '--output', 'arduino_1.6.9_amd64.snap']' returned non-zero exit status 1
<mhall119> every time
<ogra_> mhall119, there is a bug open for that
<mhall119> which means that it's broken
<ogra_> bug 1607015
<mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015>
<mhall119> reported by Alan Pope î¿ on 2016-07-27
<mup> PR snapcraft#645 closed: If "source: .." do not copy the current directory into itself <Created by evandandrea> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/645>
<mhall119> which means it's been broken for at least 15 days now
<kalikiana> mhall119: for anything using remote parts
<mhall119> is there a work-around, or is that whole part of our developer story just completely blocked right now?
<mup> Bug #1611638 opened: snap upgrade hook <Snappy:In Progress by kyrofa> <snapd (Ubuntu):In Progress> <https://launchpad.net/bugs/1611638>
<mhall119> didrocks: can we rename the remote parts to something without a / ?
<stokachu> in my snap: section can i do - usr/bin/binary and then - -usr/bin?
<stokachu> so that it only includes that one binary and forgets the rest?
<ogra_> mhall119, iirc thats in the works as well
<mhall119> stokachu: you might need to do it in the opposite order, -usr/bin and then add usr/bin/binary back
 * mhall119 is real sure how the plugin resolves them
<mhall119> but it should be possible, yes
<stokachu> mhall119: ok lemme try that
<stokachu> mhall119: doesn't work :(
<mhall119> stokachu: doesn't work either way?
<stokachu> lemme retry the original way i had it
<stokachu> mhall119: yea doesn't work either way
<mhall119> sergiusens: didrocks: popey: ^^ can you help stokachu with his snap including only select files?
<mhall119> I've reached the extent of my knowledge on it
<stokachu> like i just want to pull something like /usr/bin/tail from coreutils but not the rest of the binaries in that package
<popey> i haven't used this method to remove files, but I am sure some of the examples in the playpen do
<didrocks> mhall119: you probably want josepht, he did care of the transition
<mhall119> and you're doing this in the stage: section? or snap: (which is prime now, I think)
<stokachu> in the snap:
<stokachu> should i try stage:?
<didrocks> mhall119: but we can't rename older/remove without a /, that breaks backward compability
<popey> duplicate?
<mhall119> stokachu: yes, stage would be the place to do it I think
<popey> well, we broke backwards compatibility when we went from copy -> dump...
<popey> (didn't we?)
<didrocks> elopio: which kind of perm do you want?
<kalikiana> stokachu: you want "snap:", that should get you only the files/folders you specify
<roadmr> \o/
<didrocks> popey: yeah, but I don't want to add more
<didrocks> popey: see the ML discussion
<popey> ah okay
<popey> sure.
<kalikiana> stokachu: note that you'll have to whitelist any libs needed in that case
<stokachu> kalikiana: ok so only define what i want and the rest is dropped automatically
<didrocks> seems like josepht had a plan to avoid breaking it, I'munsure why it doesn't work at all though
<kalikiana> stokachu: yeah
<mhall119> didrocks: backwards compatibility is alredy broken
<stokachu> kalikiana: so usr/lib won't get pulled in
<mhall119> literally breaks
<didrocks> mhall119: and I don't think it's nice for our users
<didrocks> mhall119: but the desktop launcher is shipping now with a /, with a - and with short name
<mhall119> it's not, but it's also already happened
<didrocks> ( so 3 parts for each flavor :( )
<kalikiana> stokachu: right. check ldd or run the bin from the snap to see if any libs are missing
<didrocks> so not sure what you want to do in the git repo?
<didrocks> seems like something needs to happen on the importer side
<stokachu> kalikiana: ok
<didrocks> elopio: which kind of power do you need for the ubuntu org?
<stokachu> kalikiana: is there a way to just still pull in everything from lib and usr/lib while just including the binaries i want?
<stokachu> problem i have is there are 7 binaries i need to use
<kalikiana> stokachu: http://paste.ubuntu.com/23049706/
<stokachu> ok cool
<kalikiana> the ones with a leading - will be removed
<josepht> didrocks, mhall119: we should be able to have entries in the wiki now for each of the non-namespaced versions of the desktop helpers.
<josepht> mhall119: which one are you using?
<mup> PR snapcraft#568 closed: New plugin: grunt <Created by mariogrip> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/568>
<mhall119> josepht: josepht desktop/gtk2
<arges> Is there a 'snappy' place to write data that I want to persist even after the snap gets removed?
<elopio> didrocks: I am not sure. I just know that I can't see it in my Users/Organizations in docker hub.
<stokachu> arges: google photos
<kalikiana> :-D
<josepht> mhall119: can you switch to using 'desktop-gtk2' and do a 'snapcraft update' please?
<elopio> didrocks: "Automated Builds currently require read and write access since Docker Hub needs to set up a GitHub service hook."
<arges> stokachu: hah perfect
<stokachu> :P
<elopio> didrocks: also: https://docs.docker.com/docker-hub/github/#/github-organizations
<jacekn> where can I find example uses of "dump" plugin?
<didrocks> elopio: on dockerhub, I only have ubuntucore and my name
<didrocks> ah, let me try this
<didrocks> elopio: it seems the ubuntu org was already created but I can't access it either
<didrocks> that's why I told you I didn't know this dockerhub shared org workedâ¦
<mup> PR snapcraft#593 closed: git demo snap update - Bug 1595229 <Created by stub42> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/593>
<elopio> didrocks: I'm talking about the organization in github, not in dockerhub, right?
<didrocks> elopio: I meant, if I had enough power on the ubuntu org in github, I should be able to access the dockerhub one, right?
<elopio> what I'm missing is this, I think: "The organizationâs administrators may need to go to the Organizationâs âThird party accessâ screen in âSettingsâ to grant or deny access to the Docker Hub Registry application. This change will apply to all organization members."
<lazyPower> we've set this up on our jujusolutions projects for charmbox, and i have quite a few others
<didrocks> ah ok
<didrocks> let me try
<lazyPower> if you are not an admin, you cannot setup the automated build, its pretty cut and dry
<mhall119> josepht: appears to be working
<lazyPower> s/admin/admin in both cases/
<elopio> didrocks: no, the github ubuntu org is a different thing. The one I control is called "ubuntu-core", and is not linked in any way with the "ubuntu-core" team in github.
<elopio> I think it's okay to use this dockerhub ubuntu-core org. The ubuntu one might be too official.
<josepht> mhall119: great
<tyhicks> mvo, jdstrand: that eCryptfs bug is a "fun" one
<didrocks> elopio: but you need to create an access request first, right?
<jdstrand> tyhicks: oh-- I was wondering what you found out
<tyhicks> mvo, jdstrand: I'm not sure what's happening there and I can't find a simplified reproducer
<jdstrand> tyhicks: I did notice it was parted
<tyhicks> jdstrand: there are very few operations on the dragon.img file and its opened file descriptors so I thought it'd be easy to do
<jdstrand> tyhicks: like, create the image, do parted and it barfs
 * jdstrand didn't do that, and that is hardly a simple reproducer
<tyhicks> jdstrand: it looks like an openat() -> ftruncate() -> close() -> lstat() sequence would do the trick but it isn't
<tyhicks> ecryptfs only returns EACCES in one place so I'll see if that's the location of the failure or if it is somewhere in the VFS
<jdstrand> huh
<blackboxsw_> when running my built gtk-based snap for workrave, I get Gtk-WARNING **: Locale not supported by C library.
<blackboxsw_>     Using the fallback 'C' locale.
<blackboxsw_> do I need to pass LC_ALL="en.utf-8" somehow into the snap build process maybe
<blackboxsw_> ?
<blackboxsw_> I know that question is coming way out of left field. I didn't see any example snaps in the snappy-playpen that do any locale setting magic
<blackboxsw_> I'm referring to some of the same symtoms as #1584357
<mup> Bug #1584357: Snappy GTK applications <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1584357>
<mup> Bug #1584456 changed: apparmor denial using ptmx char device <apparmor> <Snappy Launcher:In Progress by jdstrand> <linux (Ubuntu):Confirmed for tyhicks> <https://launchpad.net/bugs/1584456>
<mup> PR snapd#1633 closed: many: move to purely hash based key lookup and to new key/signature format (v1) <Critical> <Reviewed> <Created by emgee> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1633>
<mup> PR snapcraft#726 opened: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
<sabdfl> ogra_, niemeyer, i can chat shortly if you want
<niemeyer> sabdfl: Heya
<niemeyer> What's the topic again? I probably missed the preamble
<sabdfl> i saw a comment referencing you and me, and dragonboard naming
<tsimonq2> o/ sabdfl :)
<mup> PR snapcraft#727 opened: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <https://github.com/snapcore/snapcraft/pull/727>
<mup> PR snapd#1617 closed: many: move to purely hash based key lookup and to new key/signature format (v1) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1617>
<niemeyer> sabdfl: I need to catch up with the kernel team to sort this out I think.. if we need to unblock this today, I'd just go with dragonboard and dragonboard-kernel..
<niemeyer> sabdfl: The question is whether this kernel is more generic, which might hint at a snapdragon-kernel..
<mvo> tyhicks: please keep me updated on this bug, its very interessting (and head scratching) indeed :)
<mup> PR snapd#1675 opened: spread: use snap-confine from ppa:snappy-dev/image for the tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1675>
<zyga> jdstrand: +1 to merge https://github.com/snapcore/snap-confine/pull/99
<mup> PR snap-confine#99: Disable owner checks for 14.04-style private home <Created by zyga> <Conflict> <https://github.com/snapcore/snap-confine/pull/99>
<zyga> ?
<jdstrand> zyga: yes, commented in PR
<zyga> ah, thanks
<jdstrand> zyga: no, I only *just* did it :)
<jdstrand> ok, I'm time-shifting today so out now
<jdstrand> have a nice weekend :)
<zyga> jdstrand: likewise!
<jcastro> what are my options for managing storage in a snap? I am making a snap for snapraid which needs access to disks and arbritrary directories.
<jcastro> So no one is confused snapraid is completely unrelated to snappy.
<ogra_> sabdfl, we need the final na,me for the dragonboard kernel and it was not sure if it should be "dragonborad-kernel" or "snapdragon-kernel"  (as niemeyer explained, there was desire from the kerel team to make it generically usable laster, just via different device trees) ... with the new build setuo i need the name in advance to create an LP project for the snap package
<mup> Bug #1612757 opened: getpid system call is blocked by seccomp under confinement <Snappy:New> <https://launchpad.net/bugs/1612757>
<mup> Bug #1612759 opened: fchown system call is blocked by seccomp under confinement <Snappy:New> <https://launchpad.net/bugs/1612759>
<rbasak> Where should I file bugs against the docs?
<rbasak> There's "Report a bug on this site" at the bottom, but when I did that for Juju, it didn't end up in the right place.
<rbasak> (see https://github.com/juju/docs/issues/716)
<niemeyer> ogra_: I suggest unblocking that by naming it dragonboard-kernel.. that's the platform we care about today, and are promising proper support
<ogra_> niemeyer, ack
<niemeyer> We can review these details later, if/when necessary
<niemeyer> cc sabdfl
<ogra_> mvo, still around ? can you crate a dragonboard-kernel package with the shared account ? (i'll care for the rest (populationetc)
<mup> PR snapd#1659 closed: wrappers: ensure services have a valid SNAP_USER_DATA dir <Reviewed> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1659>
<mup> PR snapd#1674 closed: Interfaces: Builtin: add Udisks2 and Pluggable Storage <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1674>
<mvo> ogra_: sure
<mvo> ogra_: so thats the aggreed name?
<ogra_> thanks (i dont really want to hold you back from starting your WE though)
<ogra_> mvo, the name that niemeyer and i just agreed on :)
<ogra_> worst case we can still change/drop it
<sabdfl> niemeyer, ogra_ +1
<ogra_> cool
<mvo> ogra_: name is there, do you have a snap? I think we need a snap so that I can give you collab rights, however I can just tweak the existing canonical-dragon-linux
<ogra_> mvo, oh, gimme 10mins to set up an LP project then
<mvo> ogra_: ok
<ogra_> mvo, https://code.launchpad.net/~snappy-dev/+snap/dragonboard-kernel ... (i hope the 39min are a lie there)
<ogra_> oh, they were ... (it said 339min til it starts)
<ogra_> *39
<ogra_> should take ~10min
<mvo> ogra_: neato
<dobey> hmm, why do i need to use sudo to install a local snap package?
<ogra_> dobey, why do you need sudo to install a local deb package ?
<dobey> ogra_: i don't need sudo to install a click
<ogra_> (its a matter of filesystem permissions)
<dobey> ogra_: and i'm sure snap install doesn't install files into the snappy snap itself :)
<ogra_> it installs to /snap
<dobey> ogra_: and what does logging into a u1 account have to do with filesystem permissions?
<dobey> ogra_: ie, why do i not need root if i log in and install something from the store, but i do need root otherwise?
<ogra_> which is a system level dir without special permissions (unlike the /opt tree we use for clisk)
<ogra_> dobey, click packages dont install system wide, they are bound to the user
<arges> mvo: thanks for the review of https://github.com/snapcore/snapd/pull/1602. I've pushed updates but I can't seem to get the travis-ci test to pass. It doesn't look like a failure on my part. Will that affect merging?
<mup> PR snapd#1602: interfaces: add kernel-module interface for module insertion <Reviewed> <Created by arges> <https://github.com/snapcore/snapd/pull/1602>
<ogra_> snap packages dont
<dobey> ogra_: /opt tree doesn't have special permissions either. non-root works because pkcon
<ogra_> dobey, so they effectively use root too ... just through a suid binary managed by pkcon ;)
<dobey> ogra_: that doesn't explain why i don't need root if i log into the app store with snap
<dobey> http://www.ubuntu.com/desktop/snappy <- no sudo
<dobey> http://snapcraft.io/create/ <- sudo
<ogra_> dobey, you can use snap login
<ogra_> at any time
<ogra_> afaik then sudo isnt needed
<dobey> so when will snappy use the credentials from online accounts?
<ogra_> mvo, snap is done, grab it while its hot :)
<mvo> ogra_: already downloading ;)
<ogra_> heh
<ogra_> it is all so fast now :)
<mvo> indeed, really nice
<ogra_> yeah, the best move we ever did
<ogra_> (regarding builds at least :) )
<dobey> ogra_: i'm asking this because i need to figure out how to integrate installing of snaps in the store scope for ubuntu personal/phone stuff. "open a terminal and do snap login first" is not an acceptable solution :)
<ogra_> you could embed a vte widget in your scope then :P
<ogra_> (jk)
<ali1234> what does snap login log you in to?
 * dobey files a bug against unity8: no terminal widget avaialble for scopes
<ogra_> dobey, not my area of expetise i fear ... you need the snappy core team or the store guys
<ogra_> +r
<dobey> ali1234: it's your ubuntu one account credentials
<dobey> ogra_: well that's why i joined #snappy :)
<ogra_> right
<ali1234> so as long as i'm logged in to U1 then i can side load anything without sudo?
<dobey> i think i have most of the store stuff figured out
<dobey> just trying to find a way to install a snap without having to do too much extra work, now
<ali1234> can i build an all-snap image with my own snaps baked in?
<mvo> ogra_: you have mail
<ogra_> yay
<ali1234> also what exactly is a gadget snap?
<ogra_> mvo, interesting ... twice actually (same link twice)
<ogra_> ok, set up for auto-submission ...
 * ogra_ triggers another build to test that works as desired
<ogra_> jdstrand, so it is pc-kernel, pi3-kernel and dragonboard-kernel now
<mvo> ogra_: how can you set it to auto-publish? it seems that works for ubuntu-core somehow?
<mvo> ogra_: no pi2-kernel?
<ogra_> eeek !
<ogra_> jdstrand, not pi3-kernel, but pi2-kernel
<ogra_> mvo, uufff, thanks !
<ogra_> mvo, we need jamies magic, then it should just work
<mvo> ogra_: aha!
<mvo> ogra_: I build a dragonboard image now (unless you are already on that)
<ogra_> mvo, no, just go ahead
<ogra_> i'm waiting for LP to regonize the branch change to actually start an auto-build now
<ogra_> to see the thing works from start to end
<ogra_> but LP doesnt seem to see my change or i'm in limbo between some scheduler runs
<ali1234> is it possible to have the writable partition be a ramdisk?
<ogra_> ali1234, tricky, give that your readonly bits sit init
<ali1234> not if they are baked into the initial image, surely?
<ogra_> ?
<mvo> ogra_: could you please check  http://people.canonical.com/~mvo/all-snaps/16/all-snaps-dragonboard.img.xz and check if that works on your dragonboard
<ogra_> mvo, will do
<ogra_> (i have to do some RL stuff for about 15min though, but will then ...)
<mvo> ogra_: ta!
<dobey> if i filed a bug agaisnt snapd package in ubuntu should i also have it affects snappy project?
<ogra_> dobey, yes please
<ogra_> not sure how well snapd package bugs are actually monitored
<mup> Bug #1612783 opened: snapd requires U1 account to install local packages <Canonical System Image:New> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1612783>
<ahasenack> hm, I'm still confused about config files in snaps
<ahasenack> I thought I could use SNAP_DATA for config files
<ahasenack> but the snap itself can't ship files in there, right. That's a place for the snap to store files once it's running
<ahasenack> so I should copy the config files to $SNAP_DATA on the first run if they are not there yet?
<kyrofa> ahasenack, indeed, that's how to do it right now
<kyrofa> ahasenack, I'm hoping for an install hook that will make that easier
<ahasenack> ok
<ali1234> is it safe to use /tmp/ in a snap?
<kyrofa> ali1234, yes, it's not the system-wide /tmp though
<kyrofa> ali1234, i.e. /tmp to the snap is actually /tmp/snap.foo.bar/ on the system
<ali1234> thats fine as long as it works
<kyrofa> ali1234, indeed
<ahasenack> the new dump plugins, it's not documented yet, is it?
<ahasenack> I don't see it in http://snapcraft.io/docs/reference/plugins
<ahasenack> s/plugins/plugin/
<ahasenack> snapcraft help dump didn't help much, it's just a pointer to other docs
<ali1234> okay so i've snapped a QML app for raspberry pi eglfs, who wants to try it?
<ali1234> it needs devmode to access vchiq
<kyrofa> ahasenack, happy to help
<ahasenack> just replacing "copy" with "dump" didn't work, so I stayed with "copy" for now :)
<kyrofa> ahasenack, the dump plugin takes the complete source you gave it and copied it into the root of the snap. If you want to filter files out, you can do so using the stage or snap keywords (available to every plugin). If you want to move files around, use the organize keyword (also available to every plugin)
<ahasenack> I have 3 config files at the root of my snapcraft directory, alongside the yaml. I want thse copied to specific paths inside the snap
<ahasenack> I have been using copy's "files" key for that
<ahasenack> like
<ahasenack>         files:
<ahasenack>           squid-deb-proxy.conf: /usr/share/config/squid-deb-proxy/
<kyrofa> ahasenack, indeed. Here, let me paste something for you
<ahasenack> hm, stage and prime directories are empty after a build
<kyrofa> ahasenack, http://pastebin.com/kugi0fRV . Sorry for using pastebin, paste.ubuntu.com is undergoing maintenance right now
<ahasenack> is this new in snapcraft?
<ahasenack> ah, organize
<kyrofa> ahasenack, no, nothing has changed in that regard. What is your definition of "build"? `snapcraft build`? Or a complete run of `snapcraft`?
<ahasenack> just "snapcraft"
<ahasenack> running again with the dump plugin now
<kyrofa> ahasenack, then no, stage and prime should not be empty, or the snap will be empty as well
<ahasenack> snap was 19Mb big
<ahasenack> checking things
<ahasenack> maybe it failed to build and that was just the previous version
<ahasenack> yeah, that was it
<ahasenack> new error, haven't seen it before. debugging
<ahasenack> [Errno 39] Directory not empty: '/home/andreas/snaps/snap-squid-deb-proxy/parts/squid-deb-proxy/install'
<kyrofa> ahasenack, please run with snapcraft -d and paste the output
<ahasenack> ugh, pastebin is awful :)
<ahasenack> kyrofa: http://pastebin.com/TV0tHCj9
<kyrofa> ahasenack, no kidding
<ali1234> pastebinit supports paste.debian.net i believe
<kyrofa> ahasenack, ugh, that's a big in the dump plugin... sorry :( . To workaround, `rm -rf parts/squid-deb-proxy/install`
<kyrofa> ahasenack, I'll fix that right now
<ahasenack> do the rm -rf and then what, snapcraft again?
<kyrofa> ahasenack, indeed
<ahasenack> ok
<ahasenack> it just happens again
<ahasenack> I guess I would need to specifically ask for an intermediary step, not the whole snapcraft run
<kyrofa> ahasenack, ah, bug #1611827
<mup> Bug #1611827: dump plugin with stage-packages fails <Snapcraft:New> <https://launchpad.net/bugs/1611827>
<kyrofa> ahasenack, is that it?
<ahasenack> ok, I'll subscribe
<ahasenack> yes, I have stage-packages
<kyrofa> ahasenack, workaround for now: put the stage packages on a part that uses the nil plugin
<ahasenack> ok
<ahoneybun> https://fuchsia.googlesource.com/third_party/snappy/
<ahasenack> is usr/sbin/ from inside the snap in $PATH?
<ahasenack> export PATH="$SNAP/bin:$SNAP/usr/bin:$PATH"
<ahasenack> no :/
<ahasenack> so I need to move my binary from usr/sbin to usr/bin post-build
<kyrofa> ahasenack, or write a wrapper that adds sbin to the path
<kyrofa> ahasenack, that will get less painful soon when we add environment support
<ahasenack> the revision of the snap is part of PATH
<ahasenack> I think I got it working with "organize"
<ahasenack> yeah
<ahasenack> now it's that known problem of lack dropping privileges
<mup> PR snapcraft#720 closed: Start the fake parts server only in the tests that need it <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/720>
<kyrofa> ahasenack, you should be able to use the $SNAP* environment variables
<ahasenack> kyrofa: thx, have a nice weekend
 * ahasenack -> EOW
<mup> PR snapcraft#728 opened: Use link_or_copy instead of just hard-links for deb cache <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/728>
<mup> PR snapcraft#723 closed: Set owner/group for directories in stage and prime <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/723>
#snappy 2016-08-13
<mup> Bug #1612871 opened: Permission denied to exec /bin/stty <Snappy:New> <https://launchpad.net/bugs/1612871>
<mup> Bug #1612909 opened: Unable to install snoppy in Fedora <Snappy:New> <https://launchpad.net/bugs/1612909>
<ahoneybun> snoppy?
<ahoneybun> jdstrand: I didn't make any changes to my yaml but when running I get this now: http://pastebin.ubuntu.com/23051025/
<ahoneybun> no more service errors so far
<Son_Goku> morning
<mup> PR snapcraft#728 closed: Use link_or_copy instead of just hard-links for deb cache <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/728>
<mup> PR snapcraft#729 opened: Dump plugin: Don't remove install directory <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/729>
<roasted> hi friends
<roasted> is uappexplorer the best location to find snaps to install?
<kyrofa> roasted, yeah probably for now anyway
<roasted> kyrofa: do you know if there's a way to sort snaps? I'm trying to simply find a list that work on 16.04 desktop.
<kyrofa> roasted, on uappexplorer? Not really. And the filters are terrible as well
<kyrofa> roasted, you can use `snap find` as well assuming you're looking for something?
<kyrofa> Or you're literally just trying to compile a list?
<roasted> kyrofa: snap find was just killed, I thought.
<kyrofa> roasted, it works as long as you provide it a query
<roasted> kyrofa: I'm just trying to get a sense of what snaps work on 16.04. as of now the only one I know of is VLC and LibreOffice beta.
<roasted> kyrofa: provide a query? as in snap install -insertpackagenamehere- ?
<kyrofa> roasted, snap find <string>
<roasted> kyrofa: which kind of implies I'm looking for something specific, no?
<roasted> I'm just looking for an A-Z list of some sort.
<kyrofa> roasted, right, that's what I meant by "assuming you're looking for something." I'm taking a look at uapp now
<kyrofa> roasted, yeah, doesn't look like you can sort them. Though I think you can safely assume most of them are for 16.04
<roasted> kyrofa: I figured most would be for 16.04, but ubuntu touch vs desktop is what I was most concerned about.
<kyrofa> roasted, oh, yeah you can filter snaps versus clicks
<roasted> kyrofa: I thought click was just the old name of snaps....?
<kyrofa> roasted, indeed, but the phone still uses click
<roasted> oh. interesting.
<roasted> ah I got it now. I had no idea they were still split.
<roasted> a blender snap. fancy.
<kyrofa> roasted, yeah, the phone is still based on vivid and upstart. There's a bit of work yet before it's using snaps
<roasted> I didn't realize there was an architectural difference between them.
<roasted> I thought it was nothing more than a name change.
<kyrofa> roasted, yeah, snaps are a complete departure at this point
<kyrofa> roasted, I saw you in #nextcloud earlier-- are you aware there's a nextcloud snap?
<roasted> kyrofa: I am, but my server is still on 14.04
<roasted> kyrofa: am I correct in understanding that clicks were basically one re-write to create a new packaging format, and as quickly as it came, snaps were basically another re-write of clicks?
<kyrofa> roasted, not quite-- snaps are a further evolution of clicks. Back in 15.04 for example snaps were clicks with a few more capabilities tacked on. But it's been developed a lot more since then
<roasted> so snaps are clicks on steroids
<roasted> have you packaged anything as a snap?
<roasted> I keep hearing it's easy, but I have my doubts. :P
<kyrofa> roasted, indeed, I packaged nextcloud
<roasted> you're serious?
<roasted> are you a nextcloud dev?
<kyrofa> Sometimes :)
<roasted> dude. you gotta tell me because I've pommelled google's servers with searches trying to find out...
<roasted> ...any idea when an official desktop sync client is coming? :) :) :)
<kyrofa> roasted, haha! Well first of all, I'm just a nextcloud community member so I have no inside information to share. I'm afraid I've lost touch with the desktop clients with the move from owncloud to nextcloud. I'm not sure if much of that team moved over
<kyrofa> If any
<roasted> I feel so dirty using the owncloud client for nextcloud :(
<roasted> it works, it just feels strange.
<kyrofa> roasted, you and me both
<kyrofa> roasted, I know they've got mobile clients nowadays, right?
<roasted> oh yes
<roasted> and their mobile clients actually... work :P
<roasted> I was surprised
<roasted> I really only leveraged the mobile app for auto pic/vid uploads. the oc client made me want to stab things. nextcloud app does the job gracefully.
<kyrofa> Yeah, I wouldn't be surprised if they need to put a new Qt client team together
<kyrofa> roasted, ah, good to know. I'm still using the owncloud mobile app and feel similarly
<roasted> so, I'm curious. Since you're not Frank, Jos, or one of the core guys, what did you do to package it? Pull the source and wave the snappy wand and bazinga?
<kyrofa> roasted, haha! Well, I have a series of blog posts on it if you're curious: https://kyrofa.com/posts/installing-nextcloud-can-be-a-snap
<roasted> very nice. I'll read over it once I'm not trying to multitask with energetic children chomping at my feet.
<kyrofa> roasted, snaps include all their dependencies, so the nextcloud snap includes everything nextcloud needs-- apache, mysql, etc.
<kyrofa> roasted, it was a process
<kyrofa> roasted, haha, yeah I know how that goes
<roasted> I've heard some criticisms (concerns, rather) about snaps, citing what if the upload-author goes MIA and the snap goes dark. I don't see that as a new problem though... PPAs had that issue, I'm sure in some capacity the AUR has too.
<roasted> telegram is a good example though. the telegram snap is several versions behind...
<roasted> (last I looked anywya)
<kyrofa> roasted, oh certainly, that's an issue with any packaging format
<kyrofa> roasted, however, at least in the case of nextcloud, it's moved upstream, so hopefully that won't die
<kyrofa> roasted, you mean the telegram-sergiusens snap?
<roasted> it sounds like snaps are easy enough that it doesn't require a masters to jump in, even if the original upload-author went dark.
<roasted> I suppose?
<roasted> it was telegram-something
<kyrofa> roasted, just ping sergiusens and complain ;)
<kyrofa> roasted, he's not gone dark, but may be unaware of updates. Honestly though, I suspect he's waiting for the indicator bug to be fixed
<roasted> I could never do that. Nothing worse than a user complaining who paid nothing for the software. :P
<roasted> indicator bug?
<kyrofa> Hahaha, you're the best community member ever.
<kyrofa> roasted, yeah there's a bug in indicators from snaps where the icon isn't showing up
<roasted> indicators, are we talking something like notify-osd, or in the upper taskbar?
<roasted> or is this the number count on the unity bar?
<kyrofa> roasted, the task bar
<roasted> ah
<kyrofa> No, by the clock
<roasted> gotcha
<kyrofa> We haven't quite figured that one out, yet
<roasted> I was running into a bug a while back with notify-osd, where it would simply stop giving me notifications.
<kyrofa> Something very deep in the qt stack
<roasted> It happened so randomly I can't tell if I'm seeing it on 16.04 yet
<roasted> mostly because I multitask like a banshee and hardly notice
<invapid> if you are building a snap - and it builds a dependency from source
<invapid> how do you use the libraries/includes from that dependency that's built?
<kyrofa> invapid, so let's say you have two parts: "my-lib" and "my-binary"
<kyrofa> invapid, "my-binary" should have use the `after` keyword like so: `after: [my-lib]`
<kyrofa> invapid, that will tell snapcraft that my-lib needs to be staged before my-binary will build
<invapid> oh yeah that's all set
<kyrofa> invapid, which means all the libs will be in the stage/ directory
<invapid> so I'm wondering how to modify cmake
<invapid> files
<kyrofa> invapid, to say "here's my lib?"
<invapid> sorry -  CMakeLists.txt
<kyrofa> invapid, does your lib ship pkg-config or cmake modules?
<invapid> cmake modules currently, are pkg-config better?
<kyrofa> invapid, no, that should work. Does it put the modules in a standard location?
<kyrofa> invapid, better question: can you find the modules in stage/ ? Where are they?
<invapid> its definitely in stage/lib
<invapid> shoot nvm
<invapid> non-snappy problem, just being stupid
<kyrofa> invapid, haha
#snappy 2016-08-14
<roasted> kyrofa: curious, once you build the nextcloud snap, what's involved in updating it? Is it the same process all over again?
<kyrofa> roasted, I guess that depends on what you consider to be the "process"
<roasted> kyrofa: I guess I'm talking time-wise. If packaging the nextcloud snap takes 1 hour due to the tasks involved, I was wondering if updating it from 9 to 10 (for example) is expected to take just as long.
<kyrofa> roasted, it depends on what needs to change. For example, if nextcloud just needs to be updated from 9.0.50 to 9.0.53, it takes maybe 5 minutes. Make the change, verify that it works, spin off new builds on launchpad and they're automatically published once done
<kyrofa> roasted, but if something fundamental needs change (e.g. use nginx instead of apache) that'll obviously take longer
<roasted> ah yeah that's understandable.
<roasted> I suppose it could be the same if apache needs (as per nextcloud requiring it for some reason) to be upgraded as well.
<kyrofa> Indeed. Assuming the next release works fine, that's a pretty small amount of time
<kyrofa> And if you have people willing to test your edge channel, it could be even less time if you just make the change and spin up edge builds
<roasted> are you running nextcloud-server?
<kyrofa> roasted, are you familiar with channels?
<roasted> I know they exist, and their fundamentals.
<roasted> I'm not a dev by any stretch to say "yeah I've done that" though
<kyrofa> Actually no, my personal machine in a plug computer that is an arm architecture that ubuntu doesn't support
<kyrofa> personal server rather
<roasted> ah, was just curious. I wasn't sure if you were using owncloud server + owncloud app or nextcloud server + still using the owncloud app
<kyrofa> roasted, ahh, sorry I was still stuck on the snap
<kyrofa> roasted, actually no, I'm still on ownCloud 8 :P
<roasted> sounds like ya got some debian blood in ya
<roasted> :P
<kyrofa> Yeah, if I can't have my ubuntu, I gotta have my debian
<roasted> good stuff. you a big ubuntu user?
<roasted> probably a dumb question but whatevs... :P
<kyrofa> roasted, well, I work for canonical, so yeah
<kyrofa> roasted, but even before that, yeah :)
<roasted> kyrofa: hahahaha. imagine that.
<roasted> kyrofa: we have a pretty large scale ubuntu deployment at work. does the job well.
<kyrofa> roasted, oh yeah? Good to hear!
<roasted> just bumped everything to 16.04
<roasted> though nobody has gotten to use them yet
<roasted> (summer vacation -- school district)
<kyrofa> Ah yes
<kyrofa> Perfect time to upgrade
<kyrofa> When no one can whine at the downtime
<roasted> hopefully with something we're toying with now, the future won't have any downtime besides a reboot
<roasted> (aside from a reboot, of course) we shall see though.
<frodowiz> trouble building a practice tcl/tk snap. staging seems fine. all the binaries seem to be  where they should be. i am getting the error "cant find /usr/bin/tclsh even though i see it in the staging file. same with other binaries. can someone point me to documentation that answers this? ive read snapcraft.io and the whole how to build a snap series.
<Guest38753> hey guys, trick question. Can I install snapcraft on a chromeOS?
<ogra_> Guest38753, i guess inside an ubuntu chroot you can
<Guest38753> ogra_: humm, yes i guess, but that exacly what I wanted to avoid.
<ogra_> why is that ?
<ogra_> ypu actually want to mess up your host system with build crap and dependencies ?
<Guest38753> well, I don't like the ideia of entering in a chroot env all the time I wanted to run a program.
<Guest38753> perhabs I could install snap on a place like /mnt/stateful_partition/snappy
<Guest38753> that wont change anything
<ogra_> snapcraft installs all build deppendencies on the host ...
<ogra_> when you use it to build snaps
<ogra_> you really dont want that (i dont even build ubuntu packages on a plain ubuntu host ... be it snaps with snapcraft or debs ....)
<ogra_> you are aware that snapcraft is a build tool (has nothing to do with installing or running snaps (well, you can test-run them if your system is capable))
<ogra_> ?
<Guest38753> but it's not self conteined?
<ogra_> if you actually want snapd (the thing that installs and runs snaps) natively on chromeOS i suggest to talk to zyga during the week
<ogra_> he does allteh ports to non ubuntu oses
<Guest38753> I am, there is a tool that do a similar job, nix packages manager, but I had some problems using it.
<Guest38753> hummmm. I see, Ok. I will look for him this week.
<ogra_> he is usually around during european work hours
<Guest38753> cool, thanks a lot.
<Birchy> is there a CMake script for generating snappy packages?
#snappy 2017-08-07
<PhoenixMage> When you're running a snap build on launchpad and the source website goes down after 40 min
<zyga-suse> good morning
<zyga-suse> mvo: around? :-)
<mvo> hey zyga-suse - good morning
<zyga-suse> mvo: welcome back, how were your holidays?
<mvo> zyga-suse: very nice, thank you!
<zyga-suse> mvo: we have some odd failures in xenial-proposed
<mvo> zyga-suse: how are things here?
<zyga-suse> mvo: I'll be right back, let me just get some coffee
<mvo> zyga-suse: sure
<zyga-suse> mvo: lots of things in flight :)
<zyga-suse> mvo: I'll tell you in a moment
<mvo> zyga-suse: do you have links for me with the failures?
<mvo> zyga-suse: ok
<mvo> zyga-suse: get your coffee :)
<zyga-ubuntu> mvo: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<zyga-ubuntu> oh, looks better than last week
<zyga-ubuntu> there were armfh failures and a few others
<zyga-ubuntu> but now I see
<zyga-ubuntu>  Missing build dependencies: libseccomp-dev (>= 2.1.1-1ubuntu1~trusty4)
<zyga-ubuntu> mvo: we also have https://bugs.launchpad.net/snappy/+bug/1707474
<zyga-ubuntu> and this one affects everyone, not just ubuntu
<zyga-ubuntu> mvo: I wanted to try out a simple fix
<zyga-ubuntu> + we have a tonne of reviews to do
<zyga-ubuntu> mvo: is 2.27 tagged yet?
<mvo> zyga-ubuntu: yeah, the build issue in xfsprogs is annoying
<zyga-ubuntu> mvo: I wanted to cherry pick a few fixes for arch (and probably one more for everyone on 32 bit systems)
<zyga-ubuntu> mvo: I also found a reliable way to show that reexec is just broken in debian
<zyga-ubuntu> mvo: there's a spread reproducing this (but I cannot merge it because it breaks regular tests for unrelated reason)
<zyga-ubuntu> mvo: so one thing I would consider adding to to 2.27 fixup pipe
<zyga-ubuntu> mvo: so all in all, it looks like a busy monday
<zyga-ubuntu> pstolowski: good morning
<pstolowski> zyga-ubuntu, hey!
<mvo> zyga-ubuntu: indeed, meh
<mvo> zyga-ubuntu: thanks for the update! looking at the spread tests issues now
<pstolowski> hi mvo!
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3635 that's the one I meant
<mvo> zyga-ubuntu: great, looking
<zyga-ubuntu> mvo: so your hunch about installing core along with the 1st snap was right
<mvo> zyga-ubuntu: just looking at the test, nice, thank you! the interessting question is if there is anything we can do :/
<mvo> zyga-ubuntu: the pending sru looks tame unless I miss something? the dependency-wait for ppc64/arm/ppc is harmless, we have the same for 2.25 etc, trusty is special here
<zyga-suse> mvo: the pending SRU looks good, last week it was a bunch of test failures, maybe they got re-triggered
<mvo> zyga-suse: probably
<zyga-suse> mvo: I talked to apw about them before and he re-triggered them once again because of internal connectivity errors in launchpad
<mvo> zyga-suse: did you had a chance to look at the failure in debian yet? if core is implicitely downloaded?
<mvo> zyga-suse: thank you
<zyga-suse> yes, I did, core is downloaded implicitly
<zyga-suse> mvo: then things break on the configure hook
<zyga-suse> mvo: I was pondering disabling that for now
<zyga-suse> mvo: to buy us time for 2.28 to land the configure hook with http proxy config option
<mvo> zyga-suse: did we restart into the new snapd at this point?
<zyga-suse> mvo: not sure, I spent most of last week on lots of little tasks
<zyga-suse> mvo: just get that PR and fire it up in linode (edit workers)
<zyga-suse> mvo: it's more reliable than my memory at this stage
<mvo> zyga-suse: sure, thank you
<zyga-suse> mvo, mwhudson: looked at updating debian but we have two forks to adjust
<mvo> zyga-suse: indeed
<zyga-suse> mvo: and it's unclear if we want to package those forks in debian or wait for them to merge
<mwhudson> hi hi
<zyga-suse> hey hey :)
<mwhudson> i think we could probably make a case for continuing to bundle the secomp stuff, that's pretty special and specific to snappy, right?
<ashwind> Looking for a build for https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez/commit/?h=bluez/5.44
<pstolowski> 2nd review needed for trivial #3659 and #3661 (note, the latter is against 2.27)
<zyga-suse> ashwind: I think morphis knows about those
<mvo> mwhudson: it is, I will look at the details though. iirc all changes to seccomp-golang are to build on trusty, if that is not needed, the upstream source can be used
<mwhudson> mvo: oh ok
<mwhudson> we're only targetting stretch at a well, stretch
<mwhudson> so perhaps this problem can be fixed with sed :)
<morphis> ashwind: that version of bluez is available on the store
<zyga-ubuntu> pstolowski: that latter one has tests failing
<mvo> mwhudson: the x/net/ stuff is only for tests, I will push my stuff upstream, but the code review process is a bit of a PITA to setup, I had issues with getting an account on their gerrit
<mwhudson> mvo: might it make sense for me to push it to get started?
<morphis> ashwind: at minimum it should be able in the edge channel
<mvo> mwhudson: I may actually just kill x/net in favour of kernel based tests.
<mwhudson> mvo: ok
<mvo> mwhudson: aha, indeed, that would be nice, I will dig out my diff
<pstolowski> zyga-ubuntu, yes i know,but it's completely unrelated to the change
<zyga-ubuntu> pstolowski: restarted tests
<ashwind> thx
<pstolowski> zyga-ubuntu, thanks
<mvo> pstolowski: good morning to you as well, sorry, overlooked your message earlier :)
<mvo> pstolowski: 3661 has an interessting failure that might be worth exploring
<mvo> zyga-suse: is 3649 something that needs further work? it got two +1 now and I wonder if I can merge it
 * zyga-suse looks
<zyga-suse> mvo: it is good, I will update it to drop the patches once they land
<zyga-suse> mvo: let's land it now thought
<zyga-suse> *though
<morphis> ogra_: was there any change in config.txt necessary to get BT working with Ubuntu Core on the pi?
<morphis> zyga-suse: you still owe me another review-round from last week :-)
<zyga-suse> indeed, reviews will be 90% of my day
 * zyga-suse eats breakfast now
<zyga-suse> stress is eating me alive here, darn government forms that don't work
<pstolowski> mvo, ah indeed, i didn't check all logs and missed that one. the failures I saw were about upgrade/basic
<pstolowski> aha, it is upgrade/basic failing because of unregistered hook. looking
<pstolowski> zyga-ubuntu, having fun with registering your company?
<zyga-suse> pstolowski: yes, ZUS ZUA form is silly
<pstolowski> hehe
<zyga-suse> just resolved it by talking to a consulant
<zyga-suse> you can either select mandatory thing or optional thing
<zyga-suse> but the wording is confusing so it seems you have to check both boxes
<zyga-suse> and the error message given is utterly confusing
<zyga-suse> pstolowski: that's *the* bug I was talking about earlier
<pstolowski> fill it on paper. no errors ;)
<zyga-suse> right...
<zyga-suse> if only that was true
<zyga-suse> that form is the equivalent of the paper form
<zyga-suse> but you don't have to type it over and over this way
<zyga-suse> (and I hate handwriting in forms)
<zyga-ubuntu> darn, now I have to sign it myself
<pstolowski> mvo, how can I run autopkgtests locally?
<pstolowski> just building the debs is enough?
<mvo> pstolowski: you need to install autopkgtest (the deb) - then run adt-buildvm-ubuntu-cloud to generate a test env, then run "autopkgtest . -- qemu ./path/to/the/just/created/vm"
<mvo> pstolowski: if you are on xenial you may need the autopkgtest from xenial-backports
<pstolowski> mvo, ack, thanks!
<mvo> pstolowski: during the execution of the tests for the 2.27 release there was one error in https://paste.ubuntu.com/25190576/  on i386 line 579: "+ echo 'Remove hook was executed. It shouldn'\''t.'" - does that ring a bell?
<pstolowski> mvo, these PRs I linked above fix exactly that
<mvo> pstolowski: aha, excellent
<mvo> pstolowski: 3661 is the one?
<mvo> pstolowski: or a different one?
<pstolowski> mvo, yes 3661 is for 2.27. 3559 is for master
<mvo> pstolowski: cool, thank you
<mvo> pstolowski: this is good to go I think then, would be nice to figure out why the upgrade/basic is failing and if that is something to worry about. I will still merge the PR as the other failure is unrelated
<pstolowski> mvo, yes I'm investigating (need to repro first)
<mvo> pstolowski: sure :) thank you. no pressure, just wanted to put it on your radar
<morphis> ashwind: I just got the confirmation from ogra_ that /lib/firmware/BCM43430A1.hcd exists
<morphis> ashwind: which core image did you take and which version of kernel/gadget snap for the pi are you using?
<ogra_> ashwind, try an image from either http://people.canonical.com/~ogra/snappy/all-snaps/daily/ or http://cdimage.ubuntu.com/ubuntu-core/16/edge/
<morphis> ogra_: thanks
<morphis> ogra_: using the edge or daily images should give you at least the patch files in /lib/firmware
<morphis> when you install bluez in devmode then you should be able to load the patchram file with hciattach
<morphis> ashwind: so what ogra_ and I suggest now is that you use one of the daily/edge images we produce for the pi 2/3
<morphis> that should have all necessary firmware bits in /lib/firmware
<morphis> the ones with a stable kernel/gadget snap does not because there are problems with updating certain things in /boot with newer snaps and unless that is fixed we can't move any of the snaps in edge/beta/candidate to stable
<ashwind> sure let me try that
 * zyga-suse fills in VAT-R :/
<ogra_> ashwind, see https://bugs.launchpad.net/snappy/+bug/1674509/comments/30 (you dont need the first line)
<zyga-suse> ok, I need to go out to get those documents signed
<zyga-suse> mvo: I'll be working outdoors today, just mainly doing code reviews
<zyga-suse> mvo: can you please assign me to specific PRs
<zyga-suse> mvo: I will focus on those if you do
<mvo> zyga-suse: sure - 3664 should be a trivial one
 * zyga-suse starts
<mvo> zyga-suse: also #53 on snapcore/core
<zyga-suse> mvo: both done
<mvo> zyga-suse: thank you
<zyga-suse> mvo: can we do a 2.27.1 after 2.27 is out, I would like that to be in opensuse/arch/fedora as it contains fixes for various non-default locations
<zyga-suse> mvo: and perhaps we can, by then, fix the debian bug too
<mvo> zyga-suse: there are some test failures still, it looks like we need ~rc5, I'm going over them right now. it appears its all tests so far, no real issues with the code but I'm still in the middle of it
<zyga-suse> rc5 is ...?
<zyga-suse> for 2.27?
<mvo> zyga-suse: yes, sorry. we are currently at 2.27~rc4 and have some test failures
<zyga-suse> ah, I see
<zyga-suse> will you use the release branch or master for rc5?
<mvo> zyga-suse: relese branch, 2.27 was forked some days ago
<zyga-suse> ok, shall I target my fixes there then?
<mvo> zyga-suse: ideally, if they are small we can also cherry pick them
<zyga-suse> yes, each fix is one patch, easy to cherry
<zyga-suse> if you prefer I can give you hash IDs
<mvo> zyga-suse: thats fine, just target the PR with 2.27
<zyga-suse> sure
<zyga-suse> mvo: done
<zyga-suse> mvo: there's one more but it didn't land in master yet (that is #3648)
<pstolowski> mvo, pardon my ignorance, i've never run autopkg tests manually before... there is no autpkgtest test command, only adt-run with many variants to choose from. how to properly use it with our source tree?
<zyga-ubuntu> ondra: hey, trivial comment on https://github.com/snapcore/snapd/pull/3624
<mvo> pstolowski: please try to install autopkgtest from xenial-backports, sudo apt install -t xenial-backports autopkgtest
<mvo> pstolowski: iirc the version in xenial was a bit more complicated and the test env uses the new autopkgtest stuff anyway
<pstolowski> mvo, ah, right, I forgot that backports repo needs to be forced
<zyga-suse> the one in xenial doesn't work
<zyga-suse> you need backports, period
<mvo> pstolowski: good luck, adt is a bit "special" (but it got much better with the version in -backports)
<pstolowski> mvo, this seems to be working, tests were started, thanks
<pstolowski> I spoko too soon.. it failed on build
<mvo> pstolowski: it will take some time. for future runs the "-U" option may be useful, it will ensure that the debs are up-to-date (no need for this run as you just created the image so its fresh). and "-s" which will give you a shell to login and investigate
<mvo> pstolowski: oh, it failed in what way?
<ondra> zyga-suse updated now
<ondra> zyga-suse and installing plugin for my editor :)
<pstolowski> mvo, a number of tests passed, and then http://pastebin.ubuntu.com/25262220/
<mvo> pstolowski: could you please paste a bit more?
<mvo> pstolowski: maybe the entire log
<pstolowski> sure, let me try again
<zyga-suse> ondra: cool
<zyga-suse> thank you
<pedronis> mvo: hi, this is done now, right:  https://forum.snapcraft.io/t/channels-2-0-implementation/156 ?
<pstolowski> mvo, http://pastebin.ubuntu.com/25262279/
<mvo> pstolowski: yes, the channels 2.0 stuff should be sorted
<mvo> pstolowski: hm, mysterious "FAIL: cmd_interfaces_test.go:34: SnapSuite.TestInterfacesHelp" fails (see line 2449
<zyga-ubu1tu> mvo: that is because outdated vendor.json
<zyga-ubuntu> mvo: after specific go-flags update the help output format has changed
<mvo> pstolowski: aha, so run ./get-deps I guess
<mvo> zyga-ubuntu: ta!
<zyga-ubuntu> indeed
<pstolowski> hmm
 * zyga-ubuntu is on the way to register VAT, ZUS and import the car into poland
<zyga-ubuntu> so.... well
<zyga-ubuntu> I'm online and my wife will help with all the paperwork but always "fun"
<pstolowski> zyga-ubuntu, more fun awaiting when you declare taxes for this year early next year ;)
<zyga-ubuntu> pstolowski: you mean JPK?
<pstolowski> zyga-ubuntu, no. just declaring earnings from abroad, exchange rate conversion etc
<zyga-ubuntu> is it a trait to be able to expand any three letter acronym into curse words?
<zyga-ubuntu> pstolowski: I don't have to
<zyga-ubuntu> pstolowski: my yearly stuff is going to be in spain
<zyga-ubuntu> pstolowski: so I'll just have to declare that
<pstolowski> zyga-ubuntu, ah ok, good
<zyga-ubuntu> pstolowski: I'm not a resident this year
<pstolowski> right
<zyga-ubuntu> pstolowski: but next year each micro company needs to file JPK
<zyga-ubuntu> (jednolity plik kontroli)
<pstolowski> zyga-ubuntu, that should be no brainer with any of the online accounting services I told you about
<zyga-ubuntu> pstolowski: I'm doing that on paper
<zyga-ubuntu> pstolowski: then I think I don't need it
<zyga-ubuntu> pstolowski: JPK is needed when you use software for taxes
<zyga-ubuntu> mvo: should I expect this in 2.27?
<zyga-ubuntu> - Setup snap "test-snapd-tools" (6) security profiles (cannot update mount namespace of snap "test-snapd-tools": cannot update preserved namespace of snap "test-snapd-tools": fork/exec /usr/lib/snapd/snap-update-ns: no such file or director
<zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/261760429?utm_source=github_status&utm_medium=notification
<mvo> zyga-ubuntu: hm, where do you get this error?
<zyga-ubuntu> mvo: on the linked PR
<zyga-ubuntu> mvo: this is one of the backport branches
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3666
 * ogra_ grins ... i wonder if "Jahyahp8nei1noowohvo" in the forum was aware that he shouldnt use his password as username :P
<zyga-ubuntu> Chipaca: I'm looking at the services PR now, would you like to look at https://github.com/snapcore/snapd/pull/3636?
<zyga-ubuntu> morphis: and your userd PR is next
<Chipaca> zyga-ubuntu: in a bit (got some context in-head rn)
<mvo> zyga-ubuntu: the failure you see is interessting, I will try to reproduce
<zyga-ubuntu> mvo: I'd like to squash merge this: https://github.com/snapcore/snapd/pull/3622
<zyga-ubuntu> ok
<zyga-ubuntu> Chipaca: no worries, this is not in a rush o
<zyga-ubuntu> or anything :)
<zyga-ubuntu> mvo: that looks like what we were fighting all 2.24.x with
<zyga-ubuntu> mvo: uses distro package but there is no snap-update-ns there? (odd)
<mvo> zyga-ubuntu: fine with the squash merge
<zyga-ubuntu> mvo: is that snapd-after-reexec doing stuff on reverted core?
<mvo> zyga-ubuntu: I think its something else, let me dig deeper
<mvo> zyga-ubuntu: I think it is 3671 - but I wonder why this is not part of 2.27, I remember we worked on this
<ashwind> morphis ogra_: worked as expected with the latest from http://cdimage.ubuntu.com/ubuntu-core/16/edge/ thanks
 * zyga-ubuntu looks
<zyga-ubuntu> mvo: not in 2.27
<ogra_> ashwind, note that this uses all snaps from edge ... (but is the only way to get the latest gadget snap on the pi) ... you might want to "snap refresh core --stable" and ""snap refresh pi2-kernel --beta" so you arent on edge with everything (do not use the --stable pi2-kernel though, that wont have everything you need)
<zyga-ubuntu> mvo: suggestion: merge 2.26.14 into release/2.27
<zyga-ubuntu> it would be odd if 2.27 regressed on fixes from point releases of 2.26
<Chipaca> zyga-ubuntu: do you have an example of how the 'contents' arg of snaptest.MockSnap is meant to be used?
<zyga-ubuntu> Chipaca: let me look
 * zyga-ubuntu doens't recall MockSnap
<zyga-ubuntu> just MockInfo
<Chipaca> zyga-ubuntu: blame says its yours, only reason i'm asking you :-)
<Chipaca> it's*
<zyga-ubuntu> aha
<zyga-ubuntu> it looks like a path to a squashfs file
<zyga-ubuntu> er
<mvo> zyga-ubuntu: indeed, just double checked, it looks like its the only missing commit
<zyga-ubuntu> not path
<zyga-ubuntu> *the* file
<ashwind> ogra_: Sounds good I'll make the changes.
<zyga-ubuntu> mvo: great catch!
<zyga-ubuntu> Chipaca: grepping
<mvo> zyga-ubuntu: review for 3671 would be great :)
<mvo> (super trivial)
<zyga-ubuntu> Chipaca: seems like we pass an empty string there
<zyga-ubuntu> done
<zyga-ubuntu> Chipaca: I really don't get it
<Chipaca> mvo: "will unsetenv the for"?
<zyga-ubuntu> why not MockInfo then?
<zyga-ubuntu> $SNAP :D
<Chipaca> zyga-ubuntu: it seems to expect the _contents_ of a squashfs
<zyga-ubuntu> Chipaca: exactly
<Chipaca> oh wait
<Chipaca> zyga-ubuntu: sorry, it looks like the bit that writes that out is from robert ancell
<Chipaca> zyga-ubuntu: nm then, ty!
<mvo> Chipaca: indeed, the docstring is slightly bad, I fix that in master
<Chipaca> k
<zyga-ubuntu> mvo: interesting how all my backport/ branches now fail
<zyga-ubuntu> pstolowski: - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
<zyga-ubuntu> pstolowski: in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/ppc64el/s/snapd/20170807_105544_ad619@/log.gz
<zyga-ubuntu> pstolowski: do you want to collect that log?
<mvo> zyga-ubuntu: please merge release/2.27 - that should have some fixes
<zyga-ubuntu> mvo: ^^ I strongly feel that this is something we must fix for rc5
<zyga-ubuntu> OK
<mvo> zyga-ubuntu: the above one is still under investigation, I saw this this morning as well
<zyga-ubuntu> mvo: I've been seing it for a few weeks
<zyga-ubuntu> seeing*
<mvo> zyga-ubuntu: ok, then definitely something we need to tackle for 2.27
<mvo> zyga-ubuntu: but pstolowski is aware of it and investigates (context see above)
<zyga-ubuntu> that's all we need
<pstolowski> zyga-ubuntu, yep, as mvo says, that's the same error we discussed earlier today
<zyga-ubuntu> janisozaur1: https://github.com/snapcore/snapd/pull/3673
<zyga-ubuntu> janisozaur1: I'm away from my Arch system, can you please try that?
<zyga-ubuntu> mvo: I'm still seeing lots of failures on the avahi-observe test on debian, I wonder if we are missing anything from master for that
<zyga-ubuntu> let me check
<zyga-ubuntu> ah
<zyga-ubuntu> indeed!
 * Chipaca ~> lunch (including lunch-time run)
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3674
<zyga-ubuntu> mvo: specifically this was missing: https://github.com/snapcore/snapd/pull/3674/files#diff-77cd38482da5f11c05ccdcfa24f61aea
<zyga-ubuntu> mvo: but I suspect we also want other parts of that commit
<zyga-ubuntu> ah, after merging release/2.27 those are just tests
 * Chipaca now really off
 * zyga-ubuntu arrives at the tax agency
<zyga-ubuntu> ttyl
<popey> Can someone take a moment to answer this query on stackoverflow please https://stackoverflow.com/questions/45513913/snapcraft-create-key-taking-forever-to-complete
<niemeyer> Good mornings!
<mvo> zyga-suse: nice catch
<mvo> hey niemeyer, good morning!
<niemeyer> mvo: Heya! Welcome back!
 * zyga-ubuntu needs proof that he is not in spain
<zyga-ubuntu> legal logic
<niemeyer> zyga-ubuntu: :)
<Son_Goku> mvo: morning!
<niemeyer> zyga-ubuntu: Oh, you're actually serious?
<mvo> Son_Goku: hello hello
<niemeyer> Son_Goku: Heya
<zyga-ubuntu> niemeyer: haha, yes :(
<niemeyer> zyga-ubuntu: Okay, so I think somebody *else* needs proof that you're not in Spain :P
<zyga-ubuntu> niemeyer: but not too terrible, 1/3 paperwork done
<niemeyer> zyga-ubuntu: I thought you had woken up in a Spain mood ;)
<zyga-ubuntu> niemeyer: solving one the next 1/3
<zyga-ubuntu> niemeyer: haha, no that would be nifty but not terrible :)
<zyga-ubuntu> niemeyer: driving around different agencies with my wife, trying to file everything
<zyga-ubuntu> jdstrand: o/
<mup> PR snapd#3668 closed: cmd: fix tests that assume /snap mount <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3668>
<mup> PR snapd#3669 closed: gitignore: ignore more build artefacts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3669>
<mup> PR snapd#3672 closed: cmd: fix mustUnsetenv docstring (thanks to Chipaca) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3672>
<zyga-ubuntu> mvo: any luck with your investigation?
<mup> PR snapd#3665 closed: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3665>
<zyga-ubuntu> mvo: I've merged the backports, one last PR is testing (this should fix all issues there)
<mup> PR snapd#3666 closed: snap/snapenv: always expect /snap for $SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3666>
<zyga-ubuntu> mvo: the last backport should fix the avahi tests
<jdstrand> hey zyga-ubuntu :)
<mup> PR snapd#3667 closed: cmd: mark arch as non-reexecing distro <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3667>
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: I just requested a review on https://github.com/snapcore/snapd/pull/3662
<mup> PR snapd#3662: interfaces: convert broadcom-asic-control to common iface <Created by zyga> <https://github.com/snapcore/snapd/pull/3662>
<zyga-ubuntu> jdstrand: this is one of maaany such PRs that I will open
<zyga-ubuntu> jdstrand: the context is that this will help us with the udev tagging mega-PR
<zyga-ubuntu> jdstrand: as it will (hopefully) reduce it down to just the policy changes
<zyga-ubuntu> jdstrand: I was thinking that for testing we could also make udev tagging non-optional
<zyga-ubuntu> jdstrand: that is, to always construct a cgroup
<zyga-ubuntu> jdstrand: but I would only enable this in 2.28 (2.29 more likely)
<zyga-ubuntu> jdstrand: after we feel confident that interfaces are actually OK
<zyga-ubuntu> jdstrand: then anything that breaks is going to be a clear indicator that udev tagging is missing
<jdstrand> zyga-ubuntu: please don't always create a cgroup
<jdstrand> zyga-ubuntu: you'll break docker and lxd
<zyga-ubuntu> jdstrand: aha!
<zyga-ubuntu> jdstrand: I dind't think about them
<zyga-ubuntu> jdstrand: well, too bad, but I understand
<mup> PR snapd#3674 closed: cmd,tests: fix classic confinement confusing re-execution code (#3598) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3674>
<cachio> mvo, access granted
<jdstrand> I'm fine with spread tests for everything that uses a cgroup
<zyga-ubuntu> mvo: thank you!
<jdstrand> but that could take a while
<jdstrand> zyga-ubuntu: so, fyi, I was fine with the big udev PR and this is actually creating extra work for me, but I understand it was unwieldy for others so will re-review them
<zyga-ubuntu> jdstrand: noted, I wanted to do it this way while *keeping* that other PR
<zyga-ubuntu> jdstrand: so that we actually see the problem at hand being addressed there
<mvo> cachio: thank you - I just promoted a new 2.27~rc7 to the beta channel. could you please start with the tests and let me know if anything goes wrong? a bunch of the test failures should be identified/fixed now, but for some I'm still uncertain, the deb test in particular I need help with, I would like to reproduce those, what do I need to do?
<zyga-ubuntu> mvo: anything on the debian core bug?
<zyga-ubuntu> mvo: I think we will still do rc8 but I'm happy that we will have more data at hand soon
<mvo> zyga-ubuntu: which debian core bug is that? the 2.21->2.27~ reexec failure when multiple snaps are installed and core is pulled in implicitely?
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> well, just one really :)
<zyga-ubuntu> but yes
<mup> PR snapd#3673 closed: packaging/arch: drop patches merged into master <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3673>
<mvo> zyga-ubuntu: no progress on this one
<zyga-ubuntu> mvo: snap install hello
<zyga-ubuntu> mvo: noted
<mvo> zyga-ubuntu: we may need a rc8  for this and also for the issue that pstolowski is debugging
<mvo> zyga-ubuntu: I mostly did rc7 to ensure the other issues we know about got fixed
<zyga-ubuntu> good point
 * zyga-ubuntu runs back into the legal hell
<cachio> mvo, ok
<cachio> I'll start with those
<zyga-ubu1tu> mvo: I'm wrapping up reviews (soon) and I'll jump to debian+core issue
<cachio> mvo, dor deb tests I just exported the env vars https://paste.ubuntu.com/25262854/ and exec the tests over the release branch
<mvo> cachio: thanks, I try this now
<cachio> mvo, I followed the instructions that federico wrote https://forum.snapcraft.io/t/core-snap-validation-process-at-beta-channel/1454
<zyga-ubu1tu> cachio: hey
<zyga-ubu1tu> cachio: can you please qucikly look at https://travis-ci.org/snapcore/snapd/builds/261774010?utm_source=github_status&utm_medium=notification
<cachio> zyga-ubu1tu, sure
<zyga-ubu1tu> cachio: I merged your fedora PR and now, it seems, is that fedora upgrade/basic fails
<zyga-ubu1tu> cachio: thank you!
<pstolowski> mvo, i think i understand what's going wrong or at least have a theory based on the logs. autopkg tests take forever, i'm not sure what's wrong with them. let's discuss on standup
<mvo> pstolowski: ok, this is the "missing install hook" error? it seems like those are also visible in spread, no?
<cachio> zyga-ubu1tu, any idea why it could happened? https://paste.ubuntu.com/25262885/
<zyga-ubu1tu> looking
<zyga-ubu1tu> cachio: maybe we have a wrng %dir entry somewhere
<zyga-ubu1tu> in the old version of snap-confine for fedora we had a directory there
<zyga-ubu1tu> but I think there may be an issue with it since it had mode 0000 and many tools choked on that
<zyga-ubuntu> cachio: I will not be back for 2-3 more hours so I'm away from fedora
<pstolowski> mvo, yes, missing install hook error
<pstolowski> mvo, i don't think i saw it in spread tests i run locally
<pstolowski> retyring upgrade/basic spread test again
 * ogra notes that mvo is rebooting all my development boards in a complex remote way once again :P
<jdstrand> mvo: hi! I have a couple of non-contentious policy PRs that would be nice for 2.27. I @mvo'd you in the PRs-- is that sufficient for your consideration? do you want a list?
<mvo> ogra: sorry for that
<mvo> jdstrand: just tag them as 2.27
<ogra> mvo, only teasing you :)
<mvo> ogra: ;)
<mvo> ogra: the new core is full of good stuff!
<ogra> though it would be nice if we wouldnt trigger keyboard-bell for the shutdown notification ...
<jdstrand> mvo: hmm, I thought I tried that last week. ok, let me try again
<ogra> with three ssh session to three devicesopen my desktop always starts a "pling" concert ... repreating once per minute
<ogra> (and i always search my ass off to find why i get kbd bell notifications)
<mvo> jdstrand: I was off last week, so I can't say
<mvo> jdstrand: but happy to pull in safe things at this point
<mvo> cachio: fwiw, I think the deb upgrade test is confued, it uses 2.26.10 for snap and 2.27~rc7 for snapd so some env is wrong
<cachio> mvo, ok
<zyga-ubuntu> mvo: is that the no-reexec-back problem though?
<mvo> zyga-ubuntu: maybe related but there was no failing core install
<jdstrand> mvo: I think I don't know how to add a tag. I can add labels. how do you add a tag?
<jdstrand> mvo: milestone?
<mvo> jdstrand: yeah, milestone, that is the one
<zyga-ubuntu> aha
<jdstrand> mvo: I ok, I milestoned 4 PRs (a couple I thought were already in there but weren't yet)
<mvo> jdstrand: all the ones you milestoned are merged alreday, right?
<jdstrand> mvo: oh yes
<jdstrand> all in master
<mvo> jdstrand: ok, I have a look after the meeting
<mvo> jdstrand: thank you!
<jdstrand> mvo: I'll give you the list here
<jdstrand> mvo: thank you!
<jdstrand> https://github.com/snapcore/snapd/pull/3637
<mup> PR snapd#3637: interfaces/unity7: allow receiving media key events in (at least) gnome-shell <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3637>
<jdstrand> https://github.com/snapcore/snapd/pull/3634
<mup> PR snapd#3634: interfaces/many, cmd/snap-confine: miscellaneous policy updates <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3634>
<jdstrand> https://github.com/snapcore/snapd/pull/3591
<mup> PR snapd#3591: interfaces/greengrass-support: adjust accesses now that have working snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3591>
<jdstrand> https://github.com/snapcore/snapd/pull/3525
<mup> PR snapd#3525: interfaces: add password-manager-service implicit classic interface (LP: #1653769) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3525>
<jdstrand> mvo: the first two was what I was initially thinking about, but I noticed the second two weren't in https://github.com/snapcore/snapd/tree/release/2.27
<mvo> jdstrand: I check them out now and see if they are easy to cherry-pick
<pstolowski> mvo, so regarding the re-exec in the test, see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170804_173931_89d2f@/log.gz
<pstolowski> mvo, and look for: "Aug 04 17:38:01 autopkgtest snapd[27809]: 2017/08/04 17:38:01.249361 daemon.go:252: started snapd/2.26.9+git1194.g7d0e792"
<mvo> jdstrand: meh, slightly tricky to cherry-pick - well, not tricky, just work
<pstolowski> mvo,  and "Aug 04 17:38:25 autopkgtest /usr/lib/snapd/snapd[27992]: daemon.go:251: started snapd/2.26.14"
<jdstrand> mvo: 3 should be. password-manager-service is potentially not. if it isn't, we should backport it cause it is important for some snaps. holler if you need me to do it
<mvo> jdstrand: thanks, it would be great if you could branch from release/2.27 and apply your changes on top of that, so the three branches (3637 was trivial to cherry-pick)  as PRs based on release/2.27 targeting release/2.27. if you could do that, that would help me a lot
<mvo> jdstrand: I just pushed the release/2.27 with the cherry-picks for 3637
<jdstrand> mvo: ok
<zyga-ubuntu> re
<cachio> mvo, is the new rc already in beta?
<zyga-ubuntu> the agency closes in 9 minutes, I made it :)
<mvo> cachio: it should be, do you see ~rc7 with "snap version"?
<mvo> cachio: maybe I found the issue with the deb test, testing that right now
<cachio> yes, but I see it is already building on linode, do we wait until it passes?
 * zyga-ubuntu would love a coffee now
<mvo> cachio: yeah, if spread is already running we might as well wait for that
<cachio> ok
<mvo> cachio: you mean spread-cron is running currently on the beta snap, right?
<cachio> mvo, I am still creating the images for the tests, it should be ready in few minute
<cachio> mvo, yes, I see this https://travis-ci.org/snapcore/snapd/builds/261835067
<cachio> mvo, it is just started
<mvo> cachio: thank you
<mvo> cachio: I look at the deb scenario in the meantime
<mup> PR snapd#3670 closed: snap/snapenv: document the use of CoreSnapMountDir for SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3670>
<zyga-ubuntu> woohoo
<mup> PR snapd#3662 closed: interfaces: convert broadcom-asic-control to common iface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3662>
<Pharaoh_Atem> mvo, zyga-ubuntu: rerunning based on tip of 2.27 branch: https://copr.fedorainfracloud.org/coprs/ngompa/snapd-prerel-fedora/build/587648/
<Pharaoh_Atem> mvo: did you forget to bump the rc to rc7?
<Pharaoh_Atem> zyga-ubuntu: I expect this to still fail on 32-bit architectures, as I didn't see any relevant changes to fix that in the branch
<Pharaoh_Atem> am I correct in my assessment?
<zyga-suse> Pharaoh_Atem: not yet, still in the pipe
<zyga-suse> Pharaoh_Atem: I will fix all of snap-seccomp issues before 2.27 RC8 tomorrow
<zyga-suse> Pharaoh_Atem: this is not the final RC as we still have two known issues
<zyga-suse> Pharaoh_Atem: but we wanted to see less issues after merging relevant fixes
 * Chipaca realises he's dug himself into a rabbit hole again, and stops
<Pharaoh_Atem> zyga-suse: okay, cool
<cachio> zyga-suse, still could not reproduce the error in fedora
<zyga-suse> cachio: aha, thank you
<mup> PR snapd#3675 opened: tests: restart snapd to ensure re-exec settings are applied <Created by mvo5> <https://github.com/snapcore/snapd/pull/3675>
<mvo> cachio: the deb version mismatch is addressed by 3675 now . but the test itself is not yet applicable, it is only relevant for the SRU verification which is currently not needed as 2.27 is not yet in xenial-proposed
<cachio> mvo, good
<cachio> mvo, I'll update the doc in that case
<cachio> thanks
<mvo> cachio: we need to make sure 2.26 goes into -updates everywhere, federico used to take care of this, lets chase it together tomorrow
<mvo> cachio: thanks for updating the docs
<mvo> cachio: what do I need to do to run e.g. "Execution with an image built from the beta channel with kernel from stable:" locally? any special env vars I need to set?
<mvo> cachio: I'm keen to run the VM tests for quick turnaround
<cachio> mvo, perfect
<cachio> I already started pi2 and 3 tests, but will take 6 hours aprox
<cachio> mvo, just run the amd64 and i386 if you can
<cachio> I am gonna lunch now
<mvo> cachio: any special vars I need to set? or just run in 2.27 branch?
<mvo> cachio: enjoy lunch!
<cachio> mvo, just branch 2.27
<mvo> cachio: ta, doing that now
<mvo> cachio: when you are back, what env do I need to set to run "Execution with an image built from the beta channel with kernel from stable:"?
<morphis> niemeyer: ping
<zyga-ubuntu> mvo: nice find
<Saviq> zyga-ubuntu: hey, does this ring a bell? is this the right place to file issues like that at all? https://bugs.launchpad.net/snappy/+bug/1708703
<mup> Bug #1708703: "enable" does not apply connected slot security policy <Snappy:New> <https://launchpad.net/bugs/1708703>
<zyga-suse> hmmm
<zyga-suse> Chipaca: does this ring any of your bells?
<zyga-suse> I recall we had some enable/disable bugs
<zyga-suse> but nothing that would explain this for me
<Chipaca> ?
<zyga-suse> Saviq: so after you disable + enable, is the interface connected?
<Chipaca> that does not ring a bell, no
<Chipaca> doesn't mean it isn't a bug :-)
<pedronis> zyga-suse: you did something in that area, not Chipaca, Chipaca fixed flag issues
<ogra> we had such a bug in mir in the past
 * zyga-suse looks
<ogra> (had to disable/enable it to make the kiosk demos work ... the docs page that described it (and linked to the bug) is gone though)
<pedronis> they might have interacted though
<pedronis> because some flags affect profiles
<zyga-ubuntu> Saviq: question
<zyga-ubuntu> do you see anything like that in logs
<zyga-ubuntu>             task.Errorf("skipping security profiles setup for snap %q when handling snap %q: %v", affectedSnapName, affectingSnap, err)
<zyga-ubuntu> just "skipping security profiles"
<zyga-suse> kalikiana: thank you for checking
<zyga-suse> kalikiana: I'll look at reproducing this next
<kalikiana> zyga-suse: Thanks. Much appreciated!
<matteo> zyga-suse: no zyga-fedora?
 * ogra waits for zyga-minix ...
<matteo> MULTICS
 * zyga-suse wonders how is zyga in EBCDIC when interpreted as ASCII
 * zyga-ubuntu takes a break from all of this
<zyga-ubuntu> too many topics
<cachio> mvo, the ones from here http://cdimage.ubuntu.com/ubuntu-core/16/stable/
<zyga-ubuntu> head.spin
<mvo> cachio: ta!
<mvo> cachio: and then running against the external backend?
<cachio> yes
<mvo> cachio: thanks again
<cachio> mvo, you need to do
<cachio> sudo snap refresh
<cachio> reboot
<cachio> sudo snap refresh --beta core
<cachio> and then run the tests
<Chipaca> zyga-ubuntu: "\xa9\xa8\x87\x81".
<Saviq> AlbertA: can you see above â for what zyga-ubuntu asked about the bug you reported?
<AlbertA> Saviq: ok, let me see
<Chipaca> oops
<AlbertA> zyga-ubuntu: the skipping security profiles should be vieweable in journalctl? I'm just doing sudo journalctrl -f
<AlbertA> zyga-ubuntu: this is all I get when I do enable: http://pastebin.ubuntu.com/25263708/
<AlbertA> this is with 2.27~rc7
 * ahoneybun wonders if you can use snap to replace certain files
<ahoneybun> and if you could ship a snap installed by default on the ISO
 * niemeyer waves o/
<zyga-ubuntu> Chipaca: :D
<zyga-ubuntu> AlbertA: yes
<zyga-ubuntu> ahoneybun: replace how?
<zyga-ubuntu> ahoneybun: not yet but I bet this will come
<ahoneybun> zyga-ubuntu: wondering if I could use it to keep our Manual update to date between releases
<ahoneybun> could get around the SRU stuff
<cachio> mvo, which is the out of space error you saw for the res 1
<cachio> ?
<cachio> I dont see that
<mvo> cachio: if you go to  https://paste.ubuntu.com/25190950/ and search for "no space left on device" (line 464). I hope I look at the right log :)
<mvo> cachio: meh, apparently not, which one is the right log, could you please link to that in the gdoc?
<cachio> mvo, ok, you are talking about the exec for the rc6
<cachio> ok, I'll talk to plars about that
<mvo> cachio: thank you
<zyga-ubuntu> ahoneybun: can you tell me more?
<ahoneybun> zyga-ubuntu: well only LTS will get more releases to update our Manual but if we snap it we could just push it right away
<niemeyer> morphis: Heya
<niemeyer> morphis: Just now saw your earlier ping
<zyga-ubuntu> ahoneybun: sure but I don't know which software you are talking about
<zyga-ubuntu> ahoneybun: so if you tell me more I will try to help you out
<ahoneybun> zyga-ubuntu: https://github.com/ahoneybun/kubuntu-manual
<ahoneybun> it's being cloned to launchpad so I could see if that would build a snap
<zyga-suse> let me look
<zyga-suse> so
<zyga-suse> you can easily ship this in a snap
<zyga-suse> not sure what you meant about "replacing"
<mvo> zyga-suse: I'm trying to make sense of the debian 2.21->current thing, what I see is that there is a defuct [snapctl] <defunct> child of the configure hook for core, but no denial or anything. and also strange that the process is not claimed by anything
<zyga-suse> mvo: it's not a denial, I think this is seccomp
<zyga-suse> mvo: and seccomp kills may not leave a trace on Debian
<zyga-suse> not sure
<zyga-suse> mvo: it is not claimed because its parent is bash
<zyga-suse> mvo: and the actual process is a multi-threaded golang program
<zyga-suse> mvo: and one of the threads died
<zyga-suse> mvo: but the process as a whole is still alive
<zyga-suse> mvo: do you see any other threads?
<zyga-suse> (tasks)
<mup> PR snapd#3676 opened: interfaces/many, cmd/snap-confine: miscellaneous policy updates (#3634) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3676>
<mvo> zyga-suse: how do I see those?
<mvo> zyga-suse: you mean snapctl has a thread that is still alive?
<zyga-ubuntu> mvo: yes, that's what I suspect
<zyga-ubuntu> mvo: I always use htop
<zyga-ubuntu> mvo: it can show process threads separately
<mvo> zyga-ubuntu: do you know if there is a way to figure that out, I can not gdb attach, it says it  is a zombie
<ahoneybun> zyga-ubuntu: oh yea? https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/kubuntu-docs/vivid this is what we used to use
<zyga-ubuntu> mvo: you can also make sure that is configured this way (it is by default) by hitting F2 (setup), going to display options and then unchecking "hide userland process threads"
<ahoneybun> it places the files in a dir on the machine
<mvo> zyga-ubuntu: ohhh, htop it is! it shows snapctl get service.ssh.disable as the last get
<zyga-ubuntu> ahoneybun: snaps cannot place files in arbitrary places, so you won't be able to
<zyga-ubuntu> mvo: perfect!
<zyga-ubuntu> mvo: I'm sure ps has a way to show this too
<zyga-ubuntu> just muscle memory
<zyga-ubuntu> mvo: ps -eLf
<zyga-ubuntu> mvo: or ps axms
<zyga-ubuntu> mvo: what else do you see?
<mvo> zyga-ubuntu: there we go - two threads (LWP) still alive for snapctl
<zyga-ubuntu> mvo: right, because seccomp kills just the thread
<zyga-ubuntu> not the whole process (darn)
<mup> PR snapd#3677 opened: interfaces/greengrass-support: adjust accesses now that have working â¦ <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3677>
<mvo> zyga-ubuntu: meh, I wonder if there is anything that we can do about this
<zyga-ubuntu> mvo: I'd love to get to the bottom of this :/
<mvo> zyga-ubuntu: I mean, let snapctl die entirely in this scenario
<zyga-ubuntu> mvo: I'll dig into it again in the evening, now drained
<zyga-ubuntu> mvo: not sure why it is getting killed though
<mvo> zyga-ubuntu: its definitely that, when I manually kill the two threads the install fails as expected
<mvo> zyga-ubuntu: yeah, figuring out why it gets killed is the next step
<mup> PR snapd#3677 closed: interfaces/greengrass-support: adjust accesses now that have working â¦ <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3677>
<mvo> zyga-ubuntu: do we have a forum topic for the debian bug already?
<zyga-ubuntu> mvo: kind of
 * zyga-ubuntu looks
<mvo> zyga-ubuntu: just found an old one that is not helpful, I think I just create a new one
<zyga-ubuntu> https://forum.snapcraft.io/t/snapd-out-of-the-box-experience-debian-9/1484
<zyga-ubuntu> mvo: ^
<zyga-ubuntu> mvo: ah, you created a new topic
<zyga-ubuntu> mvo: AFAIK the seccomp behavior is expected and correct
<zyga-ubuntu> mvo: can you share dmesg from that VM please
<mup> PR snapd#3678 opened: Merge pull request #3525 from jdstrand/password-manager-service <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3678>
<jdstrand> mvo: ok, I created #3676, #3677 (merged by zyga) and #3678
<ahasenack> do you guys prefer bugs against snapd filed via the forum, or launchpad? Or something else?
<mup> PR snapd#3679 opened: Updated 'Get in touch' links to Rocket and forums <Created by Ads20000> <https://github.com/snapcore/snapd/pull/3679>
<zyga-suse> ahasenack: I think forum is best
<ahasenack> zyga-suse: I just found https://github.com/snapcore/snapd/ whose README says "If you have found an issue with the application, please file a bug on the bugs list on Launchpad."
<ahasenack> with a link to https://bugs.launchpad.net/snappy/+filebug
<ahasenack> is that old/deprecated?
<zyga-suse> I think it's all a bit all over the place
<zyga-suse> lauchpad.net/snapd is one place
<zyga-suse> the forum is a good starting point
<zyga-suse> and that README needs tweaking (PRs welcome!)
<ahasenack> hm, no openid for the forum yet?
<mup> Bug #1709155 opened: Better error message for unsupported kernel <Snappy:New> <https://launchpad.net/bugs/1709155>
<mvo> zyga-ubuntu: re dmesg> nothing in there
<superjonotron> does anybody know the correct way to use /etc/network/interfaces.d files? can this define multiple interfaces or only one at a time? I put my  usual full interfaces file into it instead of creating multiple files per interface but dns seems to break even with dhcp on different interfaces regardless of defined in the file or in /etc/resolv.conf
<kyrofa> superjonotron, yeah having multiple dhcp doesn't seem to make dns happy
<kyrofa> superjonotron, when I have two interfaces both using dhcp, I make sure to specify the DNS with `dns-nameservers`
<superjonotron> kyrofa, i only set one to dhcp and the other static with the dns-nameservers defined, i basically just took what I was doing in Ubuntu 16.04 desktop and put that file into inerfaces.d/interfaces so I know the config is good, just ubuntu core seems to not like this
<superjonotron> i've also removed the name-servers from that file and just left them in /etc/resolv.conf but same results
<kyrofa> superjonotron, what exactly is happening-- no domains are resolving at all?
<kyrofa> superjonotron, Ubuntu Core uses netplan I believe
<superjonotron> kyrofa, yes no domains will resolve once I define anything in the /interfaces.d directory
<superjonotron> kyrofa, if I don't define anything there and both are dhcp since not defined, it works fine
<kyrofa> mwhudson, are you around? I'm not sure why Ubuntu Core is behaving differently there ^^, but I bet you do
<mwhudson> hi
<superjonotron> mwhudson, hello
<superjonotron> for completeness, here is the file named "interfaces" currently in /etc/network/interfaces.d
<superjonotron> auto lo iface lo inet loopback  auto mlan0 iface mlan0 inet dhcp  auto eth1 iface eth1 inet static         address 100.100.1.130         netmask 255.255.255.0         gateway 192.168.9.254  auto eth0 iface eth0 inet dhcp  auto docker0 iface docker0 inet static         address 172.17.0.1         netmask 255.255.0.0         gateway 192.168.9.254  dns-nameservers 4.2.2.2 8.8.8.8
<mwhudson> superjonotron: you are not expected to use ifupdown with ubuntu core
<mwhudson> superjonotron: but rather netplan as kyrofa says
<superjonotron> mwhudson, looking at the docs, there doesn't seem to be much there other than it points to an actual network manager and defaults to systemd-networkd if not defined (which I expect is the default state)
<superjonotron> mwhudons, do you know the preferred method of ubuntu core is?  finding this information in any official documentation has been so far impossible
<mwhudson> superjonotron: the format is pretty simple though, don't the examples help?
<mwhudson> superjonotron: there is probably not a lot of documentation on how to do this by hand, you are expected to do it via console conf
<mwhudson> we need a way to just run the networking bits of console-conf i think
<superjonotron> mwhudson, looking at the systemd-network seems straight forward syntaxically, just a big format change to the old interfaces file
<mwhudson> superjonotron: yeah
<superjonotron> mwhudson, also not sure if I need a different file per interface or can it be bundled in one?
<mwhudson> superjonotron: you don't have to configure networkd directly either though
<superjonotron> mwhudson, how would you have an application modify the ip address without modifying directly then?  not familiar with console conf
<mwhudson> superjonotron: have you seen https://wiki.ubuntu.com/Netplan and https://wiki.ubuntu.com/Netplan/Design ?
<superjonotron> mwhudson, looking through those just quickly and it still seems you need to use NetworkManager or systemd-networkd
<mwhudson> yes but netplan does that for you
<superjonotron> mwhudson, so based on the docs, I should be able configure my /interfaces.d/interfaces file and then run netplan ifupdown-migrate to generate this new style of networking?
<mwhudson> superjonotron: that would be one way of doing it, yes
<superjonotron> mwhudons, seems the easiest path rather than retooling code that is hardened for older versions of ubuntu and I know is stable.  Are there any other steps after that command required to make it take effect?
<superjonotron> mwhudson, that method fails, "method static is not supported"  seems like a pretty broken network managing solution if it doesn't understand that.  Looks like the default configuration is actually NetworkManger which has it's own configurations to use.  How is netplan supposed to be used?  So far i'm just seeing layers of network configuration required as a opposed to a single config file
<superjonotron> additionally, NetworkManager is defaulted in Ubuntu Core 16 but NetworkManager isn't even installed so, i don't know about this new network stuff in ubuntu core, it all seems very incomplete
<superjonotron> anybody willing to help me figure out how to convert the well supported interfaces file format to the new netplan yaml structure?  netplan's conversion command doesn't work and i just can't seem to grasp this new netplan system
<superjonotron> help with using netplan, anybody?
<mwhudson> superjonotron: i think it's probably something like this: http://paste.ubuntu.com/25265918/
<mwhudson> superjonotron: but i doubt you actually want to configure docker0 like that?
<superjonotron> mwhudson, thanks for that.  I'm still not entirely sure where I put that file though since there's currently two files created by default on installation, 00-default-nm-renderer.yaml  00-snapd-config.yaml
<mwhudson> superjonotron: remove both of those
<superjonotron> mwhudson, the docker0 is just currently being read and written back so it can maintain all the network connections in one place
<superjonotron> i will likely filter it out completely in the end
<superjonotron> mwhudson, is there a restart command to make this take effect?
<mwhudson> superjonotron: netplan apply
<superjonotron> mwhudson, line 6 column 5: expected mapping
<mwhudson> superjonotron: oh oops
<mwhudson> superjonotron: it's nameservers: {'addresses': [...]}
<mwhudson> not a list directly under nameservers
<superjonotron> mwhudson, so the format would be http://paste.ubuntu.com/25266022/ ?
<mwhudson> superjonotron: something like that
 * mwhudson is currently feeding a baby
<superjonotron> mwhudson, i'll keep messing with it, somethings still not right since it fails at line 6 column 6 with the same error, wish the docs were better but hopefully i'll eventually guess the right syntax
<superjonotron> well, i'm at a loss for the format for dns servers for netplan, documentation seems to be incorrect and so i'm at a loss on figuring out ubuntu cores network configuration options
<superjonotron> i'd almost be willing to strip away all this netplan stuff in favor of just using the tried and true interfaces file if that was an option anybody knew how to accomplish
#snappy 2017-08-08
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/core/pull/48>
<mup> PR snapd#3680 opened: tests: fix failover test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3680>
<mup> Bug #1693016 changed: snap install conjure-up fails if juju snap installed <Snappy:Expired> <https://launchpad.net/bugs/1693016>
<mup> PR snapd#3624 closed: interfaces/builtin: rework for avahi interface <Created by kubiko> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3624>
<zyga-suse> good morning
<mvo> hey zyga-suse!
<mup> PR snapd#3678 closed: Merge pull request #3525 from jdstrand/password-manager-service <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3678>
<zyga-suse> hey, how are you feeling? I finally feel like I had a good nights sleep
<zyga-suse> (woke up at 6 and started cleaning the house and reading about taxes)
<mup> PR snapd#3676 closed: interfaces/many, cmd/snap-confine: miscellaneous policy updates (#3634) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3676>
<mvo> zyga-suse: I had a good night as well, feeling good. some interessting results from the debian issue, I updated the forum topic
<zyga-suse> oh, let me look
<mvo> zyga-suse: no idea yet how to fix things but I think the understanding is much higher now
<mvo> (and its a bi*** to debug) :(
<mvo> e.g. strace -f does not follow all forked, even if I give all the LWP pids
<mvo> zyga-suse: I still have no idea *what* syscall is delivering the sigsys, I suspect its bind but its hard to say
<mvo> (for certain)
<zyga-suse> strace doens't work with golang
<zyga-suse> the signal delivered is not SIGSYS, it is SIGKILL IMO
<mvo> zyga-suse: check "man 2 seccomp" and search for SECCOMP_RET_KILL :)
<mvo> zyga-suse: anyway, details, I think it comes down to that our generated seccomp profiles does not have the "bindSyscallWorkaround" for unknown reasons
<zyga-suse> oh
<mvo> zyga-suse: do you remember if/where we did "devmode: true" on devmode distros in 2.21 in snap-setup?
<zyga-suse> interesting
<mvo> zyga-suse: I remember us fixing things around this but I forgot the details :/
<zyga-suse> we had a bug where devmode distro vs devmode snap were confused
<zyga-suse> and then we changed core to not be devmode (flag of the snap)
<zyga-suse> but this should *not* override the devmode distro fact
<mvo> zyga-suse: I updated the post and made it a wiki, hopefully it now explain what is going on
<zyga-suse> mvo: question: do you think we can fix this by not at all running configure hook in such a scenario?
<zyga-suse> aha
<zyga-suse> very interesting
<zyga-suse> fantastic forensics mvo :)
<mvo> zyga-suse: I would prefer to not use seccomp on devmode distros ;) but we had this argument before and I will shut up :)
<mvo> zyga-suse: anyway, I keep digging, thanks for your reviews of the security work from jamie! I hope this won't be a conflicts nightmare once I merge back
<zyga-suse> I'm sure it will be fine
<zyga-suse> I think there are two more
<zyga-suse> I'm doing reviews now
<mup> PR snapd#3680 closed: tests: fix failover test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3680>
<mvo> zyga-suse: great, thank you!
<zyga-suse> ah, no, that's all I think
<zyga-suse> I will propose a lot of interface PRs this week
<zyga-suse> mvo: and one more sleeping/happiness observation
<zyga-suse> I need to wake up at 4-5AM, this is when the sun raises and this is when I should start my day, I suspect my insistince of waking up at a fixed time after moving so far east is why I felt so tired all the time
<mvo> zyga-suse: woah, 4-5am is pretty early
<zyga-suse> I often wake up at 5 and then force myself to go to sleep just because I'm so tired after staying up past 2AM
<zyga-suse> and I wake up simply because it's 100% bright already :)
<gary-wzl> zyga-suse: :)
<gary-wzl> zyga-suse: Hey, I saw you finished converting broadcom-asic-control to commonInterface.
<gary-wzl> Thanks!
<gary-wzl> not sure if you started working on others interfaces.
<zyga-suse> gary-wzl: yes, I also merged that back into your branch (or at least locally, not sure if I pushed ^_^)
<gary-wzl> I have something done in udev_tagging branch so I know there're still a bunch of interfaces need to be converted though.
<zyga-suse> yes, I'm working on two more
<gary-wzl> Okay,
<zyga-suse> gary-wzl: I think I must have pushed it because your diff shrank by ~50 lines
<gary-wzl> Yes
<zyga-suse> gary-wzl: you can iterate on the branch I think
<gary-wzl> I was thinking I might as well take a look at the rest and create a feature branch interface by interface
<gary-wzl> Just like you did
<zyga-suse> aha
<zyga-suse> yes, please do!
<gary-wzl> Then you can help on code review. And I'll merge it back into my PR.
<zyga-suse> just two notes
<gary-wzl> yes?
<zyga-suse> I'm starting from A and go twards Z
<zyga-suse> you can start from the other end
<zyga-suse> so we don't conflict
<zyga-suse> and I think we want to expand common interface more
<gary-wzl> no problem:)
<zyga-suse> as I noticed a lot of interfaces use permanent slot snippets
<zyga-suse> I started that already, I'll have a PR after my batch of morning reviews
<gary-wzl> puselaudio, modem_manager... I guess
<zyga-suse> with that we can attack the next set of interfaces and convert them to common
<gary-wzl> yep
<mvo> zyga-suse: ok, I think its now all understood, the problem is that 2.26 (which is stable) has no bindSyscallWorkaround yet :) but 2.27 has, so the next stable release will fix it
<zyga-suse> WHAT?!
<zyga-suse> man
<zyga-suse> so all the good stuff that I associate with "fixed in the next release"
<zyga-suse> all of that is in 2.27?
<zyga-suse> mvo: I think we need to recognize important bugfixes and tag them to backport
<mup> PR snapd#3681 opened: interfaces: convert time-control to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3681>
<zyga-suse> gary-wzl: +!
<zyga-suse> +1 :)
<pstolowski> mvo, hey, re yesterday's issue with upgrade/basic test failure - should we consider any +git... version to be newer than whatever is in the core? in this case we re-exec from 2.26.9+git1194.g7d0e792 into 2.26.14; version number is higher, but that version doesn't understand install hook tasks
<mvo> pstolowski: I think we "just" need to make sure our versioning is not messed up, let me check what is going on
<mvo> pstolowski: I think things slipped a bit because of the various vacations
 * mvo looks
<mvo> pstolowski: do you have the url with the failure log at hand?
<mup> PR snapd#3682 opened: interfaces: convert ppp to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3682>
<pstolowski> mvo, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170804_173931_89d2f@/log.gz
<mvo> ta
<mup> PR snapd#3683 opened: interfaces: convert physical_memory_control to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3683>
<zyga-suse> gary-wzl: all +1
<mup> PR snapd#3684 opened: interfaces: convert physical_memory_observe to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3684>
<zyga-suse> more +1s :-)
<mup> PR snapd#3685 opened: interfaces: add missing test for optical_drive interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3685>
<zyga-suse> gary-wzl: nice work! you're going through them like warm knife through butter :)
<gary-wzl> zyga-suse: :PPPP
<mup> PR snapd#3681 closed: interfaces: convert time-control to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3681>
<zyga-suse> gary-wzl: quick request on that last one
<zyga-suse> well
<zyga-suse> pre last one, I'm looking at the optical-interface Pr
<zyga-suse> can you look at what I did to test suites lately
<zyga-suse> especially look at things in avahi-*
<gary-wzl> zyga-suse: any interface I can refer to
<gary-wzl> Okay, looking
<zyga-suse> those two have all the most recently added improvements
<zyga-suse> there are minor differences
<zyga-suse> I test backend by backend
<zyga-suse> TestXXXSpec
<zyga-suse> I use a few new helpers
<zyga-suse> MockPlug/MockSlot
<zyga-suse> little things but it is shorter and, I think, nicer than what most older test did
<gary-wzl> zyga-suse: yeah, it makes sense.
<zyga-suse> gary-wzl: the naming is also relevant, consumer/producer/ app vs app1, other or other things that (I myself) wrote earlier, this makes it easier to reason about tests
<zyga-suse> as hopefully all the interfaces will have similar behaving tests and features
<gary-wzl> zyga-suse: exactly.
<mup> PR snapd#3682 closed: interfaces: convert ppp to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3682>
<zyga-suse> mvo: do we need to backport store URL changes?
<mvo> zyga-suse: I think not
<om26er> I am not able to setup a RPi3 using wifi, works fine with ethernet. Something broken ?
<pedronis> zyga-suse: for obvious reasons the old urls still work
<pedronis> (it woulb be bad (tm)Â if they didn't )
<ogra_> om26er, works fibne here (with the edge images)
<ogra_> stable wont work, but you know that (we talked about it before)
<zyga-suse> is chipaca around today?
<om26er> ogra_: that would be someone else ;) today is my first day with a RPi3 :)
<pedronis> mvo: hi, what's the vague plan for when to cut 2.28 atm ?
<om26er> oh, I have a 5" screen as well, now need to get mir working on it.
<om26er> ogra_: when will UbuntuCore migrate to later versions of Ubuntu ?
<ogra_> om26er, well, the edge images work, once the next stable release happens, stable will have the fix too
<zyga-suse> om26er: ubuntu core won't need to as we are working on base snaps that will elimitate the "flag day" transitions mostly
<zyga-suse> om26er: so soon you will be able to use, say 18.04 base alongside 16.04 base
<zyga-suse> om26er: at the same time, at runtime, on one device
<ogra_> if yuo want to config stable ruight now, use wired, reboot, ssh into the board via wired, run sudo console-config, deconfigure eth0 and configure wlan ...
<om26er> zyga-suse: one distro to rule them all, eh ?
<zyga-suse> om26er: well, one nice way of running software for sure
<ogra_> om26er, no, exactly the opposite :)
<ogra_> in fact you can have gentoo-base, fedora-base, slackware-base if you want to
<ogra_> (and use that with your snaps)
<ogra_> we're actually getting rid of the tie to ubuntu with snaps :)
<zyga-suse> cachio: another fedora failure on 3684 -- perhaps it is a random ordering factor
<zyga-suse> cachio: and interestingly same failure in 3685
<ogra_> because they are siblings ?
<ogra_> :)
 * zyga-suse goes for a small break 
<zyga-suse> will resume userd review
<zyga-suse> and then go to address review feedback
<mup> PR snapd#3686 opened: many: merge release/2.27 branch back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3686>
<zyga-suse> holly molly
<zyga-suse> 804 lines added in 2.27?!
<mup> PR snapd#3683 closed: interfaces: convert physical_memory_control to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3683>
<zyga-suse> mvo: small change on 3686
<om26er> alan_g: Do you know if these instructions[1] are working on the Pi3 ? I just gave it a try and nothing came up on screen. [1] http://voices.canonical.com/alan.griffiths/2017/01/31/mircade-snap/
<alan_g> om26er: I don't have a Pi3, but they were working around that time (see the first comment).
<mvo> ogra_: prepare for reboots
<alan_g> Saviq: ^ could this be the problem you were looking into yesterday?
<ogra_> mvo, yay !
<ogra_> mvo, btw, keep an eye on the store uploads, the publishing fails every now and then (probably more important for a release than for the dailies)
<Saviq> alan_g: om26er, current edge (no --devmode) mir-libs, mir-kiosk and mir-kiosk-apps (r16) work fine, we didn't try mircade, but the problem we did have was Qt-related, so I doubt mircade would be affected
<mvo> ogra_: aha, good to know, thank you
<mvo> ogra_: the store was a bit unhappy in general in the last few days, some 504 and timeouts during the tests for example
<Saviq> alan_g: so in your instructions, you shouldn't need --devmode or the explicit connect for mir-kiosk any more
<om26er> Saviq: so I should just install those three snaps ?
<alan_g> Saviq: ack, I'll update
<Saviq> om26er: on the Pi, yes, just install mir-libs, mir-kiosk and mir-kiosk-apps and you should get the photoviewer app
<mup> PR snapd#3687 opened: Remove redundant apparmor rule for opengl interface and improve the test <Created by adglkh> <https://github.com/snapcore/snapd/pull/3687>
<om26er> Saviq: do I need to connect any interfaces after installing ?
<Saviq> om26er: they should all autoconnect
<Saviq> verify with `snap interfaces` of course
<zyga-suse> gary-wzl: reviewed
<alan_g> Saviq: updated the blogpost.
<Saviq> ack
<gary-wzl> zyga-suse: Thanks!
<Saviq> alan_g: FWIW, confirmed this works on amd64
<alan_g> Saviq: thanks
<Chipaca> zyga-suse: the os->core rename pr i had up i closed because it broke spread tests in ways i didn't have a head for at the time
<zyga-suse> aha, thank you
<zyga-suse> I was just curious and this is a very clear and honest response :)
<om26er> Saviq: all interfaces are connected but I still don't get a UI.
<om26er> http://paste.ubuntu.com/25269094/
<ogra_> om26er, you mean you dont get a black screen with mouse cursor ?
<om26er> ogra_: I get that last screen after setup: "Personalize your account at https://login.ubuntu.com"
<ogra_> om26er, and thats on an edge/daily image ?
<ogra_> stable does not have a gadget that enables graphics
<ogra_> (and we can not update gadgets on the pi yet)
<om26er> oh
<ogra_> same issue as on the pi2
<om26er> ogra_: will flash image from edge.
<om26er> will that image also contain the RPi GPIO interfaces ?
<ogra_> i'd recommend installing from either http://people.canonical.com/~ogra/snappy/all-snaps/daily/ or from http://cdimage.ubuntu.com/ubuntu-core/16/edge/ ... then doing: "snap refresh core --stable" and "snap refresh pi2-kernel --beta"
<ogra_> that will give you the latest gadget, a stable kernel and a stable core
<om26er> downloading from http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/
<ogra_> (the kernel is in lockstep with the gadget, so we can not upgrade it either atm, beta has the latest and most stable here)
 * ogra_ takes a break
<Chipaca> zyga-suse: in my review of snapd#3636 was it clear that the needsfixing was because of the int vs uint issue?
<mup> PR snapd#3636: snap: add support for parsing snap layout section <Created by zyga> <https://github.com/snapcore/snapd/pull/3636>
<zyga-suse> Chipaca: yes
<zyga-suse> Chipaca: I haven't touched my tree since yesterday
<zyga-suse> I'm all in review mode
<Chipaca> 'k
<zyga-suse> morphis: re-reviewed 3260
<zyga-suse> morphis: have a look
<zyga-suse> morphis: there are a few tiny things
<zyga-suse> morphis: there's nothing major I'd change
<zyga-suse> morphis: *except* an improvement for gio-open that we need to do for artful
 * zyga-suse is somewhat hungry now
<zyga-suse> I'll take a break
<zyga-suse> and start updating my PRs
<zyga-suse> I still have one review open for pedronis and I will finish it before switching (3616)
<zyga-suse> if you need a review and I missed it, please ping me
<morphis> zyga-suse: awesome! thanks
<ondra> zyga-suse now when it's merged, when can I expect change in snapd to land in edge channel?
<ogra_> next edge build usually
<ogra_> though the release might be in your way atm
<zyga-suse> yep, it needs to auto-build in the ppa
<zyga-suse> and then it needs to auto-build in the core snap
<ogra_> but we dont have the 2.27 release out yet, do we ?
<ogra_> that usually blocks master for a bit
<zyga-suse> ondra: thank you for caring about that, if there are any tweaks you want to make before 2.28 is out, please say
<zyga-suse> ogra_: I think 2.27 is unlikely
<zyga-suse> it won't have this change
<ogra_> (since we land the release deb over the master-built deb)
<ogra_> zyga-suse, thats not what i meant :)
<zyga-suse> aha
<ogra_> i mean that we dont do builds from master while releasing
<ogra_> (i,e, edge core snaps will have 2.27 until it is released)
<ogra_> (and only then 2.xxxgitxxx again)
<zyga-suse> oh, I wasn't aware of that
<ondra> zyga-suse no I don't need changes, unless something is broken, but just wanted to run more tests once it lands in edge
<ogra_> zyga-suse, you pushed snapd to the image ppa yourself in the past (which overrides the edge ppa that builds the deb from master) ... so you should know ;)
<zyga-suse> yeah I just don't do releases *that* often to remember this
<ogra_> :)
<popey> Chipaca: we have a developer who has registered and uploaded snap-foo in the store, and we'd like them to be using foo, is it possible to just rename, or should we get them to re-register foo, and forget snap-foo?
<popey> Chipaca: note, nobody has yet downloaded snap-foo, we're just trying to make this smooth for a new person
<Chipaca> popey: that's a question for people with their mits in the store backend, which isn't me
<Chipaca> popey: maybe noise][ or nessita
<popey> oh, okay. my bad. sorry.
<popey> I'll wait for them to reply, thanks.
<popey> zyga-suse: pinged you a question on telegram, is it better in pm here? (it's a private matte)
<popey> *matter
<zyga-suse> one sec
<zyga-suse> popey: can you please ping zyga_es
<zyga-suse> ahhh
<zyga-suse> wait
<zyga-suse> zyga_pl
<ogra_> es ? ... is he home ?
<zyga-suse> darn 2 accounts
<ogra_> :P
<zyga-suse> or just here
<popey> ok
<cachio> mvo, hey
<popey> zyga-suse: sent pm
<mvo> cachio: good morning!
<cachio> mvo, new rc8?
<mvo> cachio: yes, sorry for that, hopefully the last one, so far my tests in VMs look promising, updating the sheet as I go
<mvo> cachio: scenario refresh core from stable is currently running on amd64
<cachio> mvo, ok, the failover one is fixed too
<cachio> mvo, it is a test error
<mvo> cachio: yeah, thanks for chasing this!
<cachio> mvo, I am going to buy new sd cards
<cachio> now
<cachio> mvo, the one that I was using for pi3 is not working properly
<mvo> cachio: \o/
<mvo> cachio: I had hoped it might be a flakky sd card
<cachio> mvo, yes
<ogra_> ah, i was about to ask how that worked out :)
<cachio> ogra_, I discarded the one that we talked the other day
<ogra_> yeah
<cachio> ogra_, the problem is that another one is also with problems
<ogra_> sigh ...
<ogra_> i only have one like that ...
<cachio> ogra_, and those are pretty new
<ogra_> (but that fails reliable)
<cachio> always on the reboots
<cachio> the same problem
<ogra_> well, resize and the uboot resetting of the sdhc controller
<nessita> popey, hi! renames are not supported at this time (it needs work on backend and client)
<ogra_> thats the two issues i see with the broken card ... once one of them shows up, once the other
<ogra_> but i never reproduced it with a second card (and never heard from federico that he hits such an issue)
<popey> nessita: ah, okay. that nails that. thank you!
<cachio> ogra_,  yes, really bad luck
<ogra_> yeah
<popey> nessita: I'm asking if you can do it, not if the user can
<popey> nessita: specifically I have a snap - snap-ruby, which we'd like renamed to ruby
<ogra_> popey, if it has never been downloaded the user can delete the old one himself and just re-upload under the new name
<popey> sure, they can. we're just trying to make it easier for them.
<ogra_> (but i know that wasnt what you asked :) )
<nessita> popey, no, sorry, I can't do it either, the name is inside the yaml and we can't edit and rebuild that
<nessita> popey, until we work on renames, we have some restrictions where the snap name has to match the yaml name
<popey> nessita: i have a PR to update the upstream snap to change the name, so the goal was that you guys change the name in the store, he changes the name in his yaml, rebuilds, and gets the new snap
<nessita> popey, he will need a new snap-id, so he needs to re-register and do all the dance
<nessita> popey, I can't edit assertions and re sign them (to edit the name in the existing declaration)
<zyga-suse> Pharaoh_Atem: hey
<zyga-suse> Pharaoh_Atem: I have two questions
<zyga-suse> Pharaoh_Atem: could we consider updating snapd to 2.26.14 please?
<zyga-suse> Pharaoh_Atem: and related to that, can we consider getting rid of the separate snap-confine package
<om26er> ogra_: is NanoPi Neo going to be a supported platform ? Need to know before I order a bunch of them.
<ogra_> om26er, i dont think so ... beyond me supporting it in my spare time ...
<ogra_> if you can live with that level of support, go for it :)
<ogra_> else, you caan indeed make a contract with canonical to have it fully supported ;)
<ogra_> or hope that the manufacturer does it at some point
<om26er> haha!
<om26er> seems the manufacturer actually advertises UbuntuCore support
<ogra_> no, they advertise some broken self hacked tarball release they call ubuntu core
<ogra_> it is actually a classic install manually buit using debootstrap as i understand
<ogra_> at least the images they offter
<ogra_> *offer
<ogra_> ... on their site ... for download
<ogra_> i doubt they would even be able to run snapd
<om26er> RPi is fine but goes a little out of budget if you have to create a mesh of 5-10 of them.
<ogra_> did you consider the orangepi ?
<ogra_> that has actually a chance to eventually get full ubuntu-core from the manufacturer
<om26er> ogra_: there is a wifi variant of the board, did you play with that as well ? NanoPi Neo Air
 * om26er looks into orangepi
<ogra_> om26er, no, i have a remote controlled popey doing that for me :)
<popey> Bleep Bloop!
<popey> nessita: thanks!
<ogra_> (i'll need to fix up the device tree for him before he csn use wifi)
<ogra_> (just building these allwinner kernels is so hard (got to use snapcraft in a chroot that has gcc6 available and such)
<ogra_> which is why it is going slow
 * om26er wishes RPi Zero was ARMv7 -- a fine board, wrong arch.
<om26er> fyi, `snap list` says "No snaps are installed yet...." on UbuntuCore image from edge channel. Device: RPi3
<mvo> om26er: that is unexpected, what does "snap changes" tell you?
<om26er> mvo: that command hanged for link 20 seconds, still isn't returning.
<zyga-suse> om26er: snap version?
<niemeyer> o/
<niemeyer> I'll be a minute or two late..
<om26er> mvo: now `snap changes` worked, says:
<om26er> ID   Status  Spawn                 Ready  Summary
<om26er> 1    Doing   2017-08-08T13:00:11Z  -      Initialize system state
<om26er> zyga-suse: http://paste.ubuntu.com/25269849/
<om26er> aah, now `snap list` showed up as well :)
<zyga-ubuntu> om26er: is the machine very very busy?
<zyga-ubuntu> can you run top?
<zyga-ubuntu> and ps aux
<om26er> zyga-ubuntu: the machine had just finished the first boot setup
<om26er> ran nothing else. It is reproducible as I had that issue in my last flashing a few hours ago as well.
<zyga-suse> om26er: that doesn't mean it wasn't busy
<zyga-suse> maybe something ran in a loop
<mup> PR snapd#3686 closed: many: merge release/2.27 branch back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3686>
<mup> PR snapd#3687 closed: Remove redundant apparmor rule for opengl interface and improve the test <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3687>
<jdstrand> ondra: hey, I see in the forum mention of a pending avahi snap stuck in review, but I don't see it in the store...
<mvo> niemeyer: 3569 is ready for a second review from you, probably/hopefully quck and painless as pstolowski addressed all the points AFAICS
<zyga-ubuntu> niemeyer: hey, how often is the review sprint thread updated?
<niemeyer> zyga-ubuntu: It's not updated for quite a while now.. need to get back to it
<zyga-ubuntu> mvo: what do you want to do about https://github.com/snapcore/snapd/pull/3639 ?
<mup> PR snapd#3639: update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
 * zyga-ubuntu focuses on https://github.com/snapcore/snapd/pull/3499
<mup> PR snapd#3499: interfaces/builtin: add the spi interface <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
<mvo> zyga-ubuntu: I need to read up on 3639, the update was 1.7 only or something?
<ondra> jdstrand it might have failed review completely
<ondra> jdstrand yeah it was rejected, as "interface 'avahi-control' not found in base declaration"
<ondra> jdstrand I guess we need to wait till interface gets updated to stable? or does it check against edge?
<jdstrand> ondra: thre review tools need to be updated. I am updating them now
<mup> PR snapd#3688 opened: Improve the test for ppp interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3688>
<Pharaoh_Atem> zyga-ubuntu: well, the reason I haven't updated snapd was because mvo indicated snapd 2.27 was coming asap
<Pharaoh_Atem> zyga-ubuntu: as for getting rid of the snap-confine subpackage, I'm considering it
<Pharaoh_Atem> though it has certainly helped in making rebasing less dumb
<Pharaoh_Atem> but I have been thinking about merging snap-confine into snapd package
<zyga-suse> Pharaoh_Atem: aha, thank you!
<Pharaoh_Atem> zyga-suse: the thing is, no one ever gives feedback for snapd, so it's basically a week of sitting in bodhi
<Pharaoh_Atem> so I don't particularly want to have snapd sitting in bodhi for a week on 2.26.14 if 2.27 is arriving
<zyga-suse> I see
<zyga-suse> that makes sense, thanks
<Pharaoh_Atem> if people actually bothered to test snapd while it was in updates-testing and give positive feedback, then I'd be more willing to do rapid updates
<Pharaoh_Atem> of course, I can see why no one really wants to use snapd, as it's hamstrung in Fedora right now due to desktop integration features being broken
<cachio> niemeyer, where I can see the configuration for each spread cron?
<niemeyer> cachio: In the spread-cron repository
<niemeyer> cachio: Each branch should have its own setup.. or at least that's my understanding
<cachio> niemeyer, nice
<Neeraj> Hi Facu
<Neeraj> Do we have any resolutions on
<Neeraj> " ERROR received an unexpected http response code (404) when trying to download
<Facu> Neeraj, hello! it should be deployed to production today
<niemeyer> zyga-ubuntu: updated the board, btw
<zyga-ubuntu> thank you
<mup> PR snapd#3689 opened: Improve the test for physical memory control and observe interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3689>
 * Chipaca shakes his fist at hardware in general and bootloaders in particular
<Neeraj> Hi Facu : Thanks
<Neeraj> Facu : so snap refresh will work as it is correct, or we need to perform any other operation
<Facu> Neeraj, it should work ok, but as soon it's in production, I'll ping you and will supervise
<Neeraj> Hi Facu thanks
<jdstrand> roadmr: hi! would you mind pulling r895? not urgent
<jdstrand> ondra: that has your avahi fixes ^
<roadmr> jdstrand: sure
<ondra> jdstrand perfect
<ondra> jdstrand I will wait when new snapd lands and will resubmit avahi to the store then
<ondra> jdstrand thanks
<jdstrand> ondra: np. if it would help you, you can request a manual review and I could approve it in anticipation of the above
<ondra> jdstrand sure might do that, so it all just starts working once core lands
<cachio> mvo, quick question
<cachio> https://github.com/snapcore/snapd/blob/master/tests/main/snap-interface/task.yaml
<cachio> mvo, sorry, this is the link https://paste.ubuntu.com/25270863/
<cachio> it is on pi2
<cachio> does it sound familiar to you?
<ogra_> cachio, https://github.com/snapcore/classic-snap/blob/master/bin/create
<ogra_> (line 23)
<cachio> ogra_, tx
<ogra_> for whatever reason /snap/core/current doesnt exist (or isnt found)
<cachio> ogra_, I bought 2 kingstone micro sd cards today
<cachio> ogra_, I flash both
<ogra_> do they behave any better ?
<cachio> I insert in the pi3, and everything loads normally but then the "press to configure" does not appears
<cachio> the last I see is
<cachio> random: nonblocking pool is initialized
<cachio> ogra_, any idea?
<ogra_> it might take a while, did youwait long enough ?
<ogra_> also is that on monitor or serial console ?
<cachio> is it on serial console
<cachio> I waited more than 1 hour
<ogra_> heh, yeah, i meant more like 1-2min :)
<ogra_> there is something odd with the startup of console-conf
<ogra_> (on a monitor the screen actually flashes a few times before it comes up)
<cachio> ogra_, any idea how to make it appear?
<ogra_> gimme a sec ...
<ogra_> i have to dig up the ancient stable gadget (havent looked at that in a while)
<ogra_> check cmdline.txt in the system-boot partition of the SD
<ogra_> what ate the console= settings in there ?
<ogra_> ogra@pi3:~/oldgadget/squashfs-root$ cat /boot/uboot/cmdline.txt
<ogra_> dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty0 elevator=deadline rng_core.default_quality=700
<ogra_> ogra@pi3:~/oldgadget/squashfs-root$ cat boot-assets/cmdline.txt
<ogra_> dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
<ogra_> here we go
<ogra_> try changing ttyAMA0 to ttyS0
<ogra_> (iirc back then we only made it work for hdmi consoles, that got fixed later in the gadget (which we can not upgrade :P ) )
<ogra_> at least you can easily edit it on the PC on the Sd card ...
<cachio> ogra_, dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
<ogra_> yeah, change AMA0 to S0
<cachio> ok
<ogra_> sad that we cant update that :/
<ogra_> (yet)
<cachio> ogra_, loading...
<cachio> ogra_, should I update to console=ttyS1 in case I am using the tty1?
<ogra_> no, S0 is the serial port ... thats fine
<cachio> ogra_, I have in the tty0 the pi2
<cachio> but then I see console=ttyS0
<ogra_> this is from the POV of the board, not from the POV of your PC :)
<cachio> is it ok?
<cachio> ogra_, ahh
<cachio> ok
<ogra_> S0 just means first serial device
<mvo> cachio: checking
<mvo> cachio: that error does not ring a bell
<ogra_> mvo, well, classic bin/create cant find /snap/core/current it seems
<ogra_> for whatever reason
<mvo> cachio, ogra_: right, would be nice to get a debug shell on this machine, I wonder why current is missing. is that reprocible?
<ogra_> no idea
<cachio> mvo, I'll try once the full run has finished
<ogra_> only judging by the pastebin :)
<ogra_> i never see such issues here in real usage :)
<ogra_> but then, i also never use stable
<ogra_> cachio, so any change regarding the config UI ?
<ogra_> (does it show up on serial now?)
<mvo> cachio: thank you, I suspect its a test issue, i.e. that somehow during restore of the tests the current symlink points to the wrong place or somethin
 * mvo needs to step out to get some dinner
<ogra_> well,  it does [ -e ....] ... that shouldnt care about the target of the link as long as the file node exists
<cachio> ogra_, https://paste.ubuntu.com/25271070/
<cachio> ogra_, should I reflash?
<ogra_> [    7.370791] FAT-fs (mmcblk0p1): IO charset ascii not found
<ogra_> woah
<ogra_> cachio, well, it should surely not break ... i dont get why you have all these disk errors
<cachio> with both cards I see the same
<ogra_> you mean the inode errors (the last two lines) ?
<cachio> ogra_, no, I just saw that in this card
<cachio> I'll try with the other one
<ogra_> the charset issue is likely a missing config option in that ancient stable kernel
<ogra_> (nothing we can fix until gadget update work)
<ogra_> *updates
<cachio> ogra, the same error with the other sd card :(
<ogra_> which one ?
<ogra_> the asccii charset one is fine ... just ignore that one
<cachio> the last one
<ogra_> (just odd that the module is missing, thogh that kernel  is awful and outdated anyway)
<ogra_> hmm
<ogra_> well, i doubt it is fatal
<ogra_> (the last one that is)
<ogra_> (and the next reboot/fsck should fix it i guess)
<cachio> ogra_, EXT4-fs (mmcblk0p2): error count since last fsck: 2
<ogra_> right
<cachio> ogra_, I see this also in the other card
<cachio> ogra_, should I reflash and make the change in the tty before insert it in the device=
<ogra_> yeah, try that ... though i see we are still using AMA0 on todays pi2 images ...
<ogra_> so theoretically it should work
<cachio> ok
<ogra_> do you have a mmonitor so you could cross check that the UI comes up on a screen at least ?
<ogra_> else i'd blame console-conf (or something systemic) instead of the tty's
<cachio> ogra_, yes, I'll try that too
<niemeyer> mvo: Can we change the contact information in the core snap to point to the forum?
<niemeyer> It currently has a pretty long email address
<mvo> niemeyer: sure
<niemeyer> mvo: Thanks!
<mup> PR snapcraft#1407 closed:  recording: record the original snapcraft.yaml <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1407>
<mup> PR snapcraft#1432 closed: kbuild plugin: support Makefile without install target <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1432>
<cachio> niemeyer, there?
<niemeyer> cachio: Always!
<cachio> niemeyer, good
<niemeyer> Sometimes there is not here, but always there, for certain
<cachio> niemeyer, hehe, I am checking the spread cron branches and I see that
<cachio> for most of the branches that are doing sru validation
<cachio> niemeyer, those are using the snapd from apt and the test code from master
<cachio> so, there are tests that are failing against that snapd but passing on master
<cachio> i.e. snapd-interface
<niemeyer> Hmm
<cachio> https://travis-ci.org/snapcore/spread-cron/builds/262177661
<cachio> look this example
<niemeyer> cachio: That doesn't make a lot of sense
<niemeyer> cachio: This will be pretty much always broken
<cachio> https://travis-ci.org/snapcore/spread-cron/builds/262177661#L1534
<niemeyer> Since we test features that we implement, and we're always implementing features
<cachio> niemeyer, this is the script that it is running https://github.com/snapcore/spread-cron/blob/snapd-from-trusty-updates-edge/run-checks
<niemeyer> cachio: Can you please check with Federico what was the thinking around these tests, and then let's catch up on that again?
<niemeyer> cachio: Wait, that doesn't look like SRU validation
<cachio> niemeyer, it is using SPREAD_SRU_VALIDATION=1
<niemeyer> cachio: Sure, but the *intention* of this test is not SRU validation
<niemeyer> cachio: Just from its name, my guess is that the point there is making sure that the package we have on trust can continue to update to whatever is in edge
<niemeyer> This makes sense to be in spread-cron
<cachio> niemeyer, ok, so perhaps it should not used SPREAD_SRU_VALIDATION=1
<cachio> use+
<niemeyer> cachio: It really depends on what this flag does
<niemeyer> cachio: But as long as the intent is preserved, we can change the test at will
<niemeyer> cachio: Obviously, it needs to use the package from Trusty
<niemeyer> cachio: and it needs to update to the content in edge
<cachio> niemeyer, in the code, if "$SRU_VALIDATION" = "1", then it installs snapd using apt, otherwise it installs snapd that was built
<cachio> in sru validation it also updates snapd after install it
<om26er> Hi! If a device has support in the mainline kernel, is there still an enablement effort needed ?
<niemeyer> cachio: If that's all it does then it makes sense to have it set, as we want to test the package and then update it to edge, right?
<niemeyer> It's also a hint that the variable name may be wrong
<niemeyer> om26er: If everything works, then there's no need to make anything else work :)
<niemeyer> om26er: Being in the mainline kernel is often not the same as "everything works", though
<niemeyer> om26er: So, YMMV
<om26er> niemeyer: hmm, so is there a armhf UbuntuCore image with stock kernel ?
 * om26er wonders when will UbuntuCore get 4.11
<niemeyer> om26er: The Ubuntu Core images published by Canonical target specific ARM devices..
<niemeyer> ogra_ has all the details
<niemeyer> I'd recommend sending your questions to the forum so others can participate and benefit from the discussion
<mup> PR snapd#3593 closed: interfaces/wayland: add access to wayland compositors <Blocked> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3593>
<mup> Issue snapcraft#100 opened: Issues are tracked on launchpad <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/100>
<mup> Issue snapcraft#1437 opened: cross-compile i386 kernel <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1437>
<mup> Issue snapcraft#1438 opened: cross-compile python <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1438>
<mup> Issue snapcraft#1439 opened: target arch default for containers <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1439>
<mup> Issue # opened: snapcraft#1440, snapcraft#1441, snapcraft#1442, snapcraft#1443, snapcraft#1444, snapcraft#1445, snapcraft#1446
<mup> PR snapd#3690 opened: interfaces/wayland: add wayland interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3690>
<PhoenixMage> Hey guys, I have created a snap but it seems that it cant find the libraries that I have included with it, how can I fix that?
<kyrofa> PhoenixMage, can you shared your snapcraft.yaml?
<PhoenixMage> https://git.launchpad.net/samba-dc-snap/tree/snapcraft.yaml
<kyrofa> PhoenixMage, the libs that end up not being found, where do they end up?
<kyrofa> lib/private ?
<PhoenixMage> kyrofa: Thats where the samba compile put them
<kyrofa> PhoenixMage, yeah that's fine, I'm just asking: are those the libs you're not finding?
<kyrofa> I assume so, just want to make sure
<PhoenixMage>         libsamba-hostconfig.so.0 => not found
<PhoenixMage>         libdbwrap-samba4.so => not found
<PhoenixMage>         libtalloc.so.2 => not found
<PhoenixMage> Actualy
<PhoenixMage> Sorry my bad
<PhoenixMage>  /snap/samba-dc/x1/sbin/samba: error while loading shared libraries: libcluster-samba4.so: cannot open shared object file: No such file or directory
<PhoenixMage> Its early and I am hung over
<kyrofa> Yep, private indeed
<kyrofa> PhoenixMage, so you have two options
<kyrofa> Three, maybe. Perhaps samba has a build option for putting those libs in a nicer place
<kyrofa> 2) You can use snapcraft's `organize` keyword to move all the private libs into `lib`
<kyrofa> 3) Add lib/private to the LD_LIBRARY_PATH of the app
<kyrofa> (3 would use the `environment` keyword in the yaml)
<PhoenixMage> kyrofa: ok thanks for your help, I thought LD_LIBRARY_PATH was recursive
<kyrofa> PhoenixMage, nope, it's just like PATH
<PhoenixMage> cool, will make the change and recompile
<PhoenixMage> Thanks again
<PhoenixMage> --with-privatelibdir should do the trick
<kyrofa> Yeah, nice
<kyrofa> PhoenixMage, and no problem :)
<mup> PR snapd#3691 opened: tests: installing snapd for nested test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3691>
<superjonotron> attempting to use the netplan yaml structure and even though I have figured out the correct syntax for what I want, during boot I get "A start job is running for raise network interfaces (5 mins 6 sec)".
<superjonotron> based on testing, my best guess is this is with dns resolving but once the system is up, everything is resolved
<superjonotron> if I leave the default yaml in /etc/netplan as the only one, and everything is dhcp with nothing defined essentially, this does not happen
<superjonotron> anybody got any thoughts on this?
<superjonotron> yaml config for reference http://paste.ubuntu.com/25273156/
#snappy 2017-08-09
<PhoenixMage> kyrofa: I cant find any details on using the environment keyword in the documentation, do you have a link handy, just curious about it
<mup> PR snapd#3692 opened: tests: install most important snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3692>
<mup> PR snapd#3685 closed: interfaces: add missing test for optical_drive interface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3685>
<mup> PR snapd#3684 closed: interfaces: convert physical_memory_observe to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3684>
 * zyga-ubuntu is very grumpy about quite sub-optimal package build/test failure outupt
<zyga-ubuntu> output*
<zyga-ubuntu> extreme verbosity and no substance
<zyga-ubuntu> good morning
<mvo> hey zyga-ubuntu! where do you see this output?
<zyga-ubuntu> mvo: unit tests
<zyga-ubuntu> mvo: first you get a list of all the files, because that's apparently interesting
<zyga-ubuntu> mvo: then you get a per-module test result, because we just need to see that too
<mvo> zyga-ubuntu: aha, yes, its quite terrible
<zyga-ubuntu> mvo: and somewhere in that output there is one test failure
<zyga-ubuntu> mvo: obviously you don't know because the output for all the 100s of other modules follows
<zyga-ubuntu> mvo: ....
<mvo> zyga-ubuntu: yes, I suffered this pain also
<zyga-ubuntu> mvo: let me see if I can cure this
<mvo> zyga-ubuntu: if you find a switch to make this less insane, I will give you an extra hug
<zyga-ubuntu> because day-to-day experience is nothing like that
<zyga-ubuntu> mvo: I mean this seems to do the right thing: $ go test github.com/snapcore/snapd/...
<zyga-ubuntu> are we getting the painful output from debhelper or is that self-induced-suffering?
<mvo> zyga-ubuntu: probably, I guess it sets some verbose flags somewhere
<zyga-ubuntu> I'm grumpy enough to find this today
<zyga-ubuntu> thank you mvo :)
<mup> PR snapd#3689 closed: Improve the test for physical memory control and observe interface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3689>
<mup> PR snapd#3693 opened: snapsate: improve the error message when classic confinement is not supported <Created by mvo5> <https://github.com/snapcore/snapd/pull/3693>
<zyga-ubuntu> woot
<zyga-ubuntu> thank you mvo!
<zyga-ubuntu> mvo: 2.27 backport would be lovely
<zyga-ubuntu> mvo: I'll add this to arch ASAP :)
<mwhudson> oh the list of files is dh-golang being stupid i think
<mwhudson> DH_VERBOSE=0 will stop that
<zyga-ubuntu> mwhudson: thank you :)
<mvo> zyga-ubuntu: I hope 2.27 is closed, I need to talk to Sergio but ideally rc8 will be renamed to -final and it goes to candidate. but lets see what he says
<zyga-ubuntu> mvo: CE asked to include the broadcom-asic interface there
<zyga-ubuntu> mvo: if you still allow PRs I'll make a backport
<jamesh> zyga-ubuntu: I still need to try implementing this in snap-confine, but I think I've worked out a way to handle the per-user mounts that should work with snap-update-ns
<zyga-ubuntu> jamesh: that's great, I saw the messaging about this
<jamesh> zyga-ubuntu: it's essentially unshare the mount namespace, then remount "/" with MS_REC|MS_SLAVE, then overlay the extra mounts
<jamesh> I get all the mount changes from the parent without the parent seeing any of child's
<zyga-ubuntu> what happens if, say, the parent them mounts something over your changes?
<mvo> zyga-ubuntu: are you ok with merging 3604? or do you see any blockers in there?
<morphis_> zyga-ubuntu: another snapd bug you might be interested in: https://github.com/anbox/anbox/issues/399
 * zyga-ubuntu looks at both
<zyga-ubuntu> mvo: letm's merge it, I'll improve the thing I care about soon
<mup> PR snapd#3604 closed: tests:  enable main suite for opensuse <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3604>
<mvo> zyga-ubuntu: thank you
<Chipaca> zyga-ubuntu: o/
<Chipaca> zyga-ubuntu: snapd#3694 has a commit message i think you'll like
<mup> PR snapd#3694: wrappers, overlord/snapstate/backend: make link-snap clean up on failure <Created by chipaca> <https://github.com/snapcore/snapd/pull/3694>
<mup> PR snapd#3694 opened: wrappers, overlord/snapstate/backend: make link-snap clean up on failure <Created by chipaca> <https://github.com/snapcore/snapd/pull/3694>
<Chipaca> mup: where's your source? I want to add a "no parroting" feature
<mup> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
<Chipaca> mup: no you're not, no matter what I type you respond.
<mup> Chipaca: In-com-pre-hen-si-ble-ness.
<Chipaca> mup: see?
<mup> Chipaca: Roses are red, violets are blue, and I don't understand what you just said.
<zyga-ubuntu> Chipaca: looking
<zyga-ubuntu> Chipaca: that's a world of difference to me, thank you!
<Chipaca> zyga-ubuntu: :-)
<Chipaca> and now i need to go push some papers around. Should be back in ~30 minutes, but who knows.
<zyga-ubuntu> o/
<zyga-ubuntu> Chipaca: I like the cleanup approach
<Chipaca> zyga-ubuntu: i've tried to keep it boring :-)
<Chipaca> also i'm not very good at doing the "go push papers around" thing
 * Chipaca tries again
<zyga-ubuntu> what kind of go push papers around are you referring to?
<zyga-ubuntu> ok, I read the non-test code and it looks good
<zyga-ubuntu> looking at tests now
<zyga-ubuntu> I wish github had a way to split this
<Chipaca> zyga-ubuntu: need to renew my lease
<zyga-ubuntu> ah
<zyga-ubuntu> I misunderstood "go" as "golang"
<Chipaca> sign a stack of papers
 * zyga-ubuntu hugs Chipaca after looking at his pile of papers
 * Chipaca hugs zyga-ubuntu back
 * zyga-ubuntu -> food
<mvo> cachio: hey,good morning! did you find out anything about the     - external:ubuntu-core-16-arm-32:tests/main/security-setuid-root failure(s)?
<mvo> cachio: if not, let me build an image now and try to reproduce
<Chipaca> niemeyer: poke
<Chipaca> niemeyer: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262/33?u=chipaca
<Chipaca> niemeyer: basically i'm not liking the very different behaviour of "snap restart" vs "snap restart --reload", and would like to make a minor change to it so the problem goes away
<mvo> niemeyer: just FYI, I looked into updating the support: field for the core snap but this is not yet supported in the store. bug 1666792 is tracking this work (sort of)
<mup> Bug #1666792: Please add "contact" field to the API <Snap Store:Incomplete by roadmr> <https://launchpad.net/bugs/1666792>
<ogra_> mvo, perhaps via snapcraft somehow ?
<pedronis> mvo: well that's part of the larger discussion we had in London
<pedronis> about what's authoritative
<Chipaca> cachio: you around?
<Chipaca> nm, network slowness
<mup> PR snapd#3688 closed: Improve the test for ppp interface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3688>
<zyga-ubuntu> jdstrand: can you have a 2nd look (and perhaps +1) https://github.com/snapcore/snapd/pull/3499
<mup> PR snapd#3499: interfaces/builtin: add the spi interface <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
<pedronis> Chipaca: this is not the first place reporting op conflicts for sure, IÂ suppose the rest are doing 400 or 500
<mup> PR snapd#3478 closed: tests: extend upower-observe test to cover snaps providing slots <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3478>
<mup> Bug #1645731 opened: Fail to access the shared content if app starts before connect interface <Canonical System Image:Confirmed for pat-mcgowan> <snapd:New> <Snappy:Triaged by zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731>
<niemeyer> Chipaca: Yo
<niemeyer> Chipaca: Is that in the topic?  Looking
<ikey> q: what is the preferred method for packaging snapd? given the number of golang dependencies
<ikey> solus packaging explicitly disables networking during build for security
<niemeyer> mvo: You mean "contact"?
<mvo> niemeyer: yes, contact, sorry
<ikey> thus is it safe to lift the networking restriction and trust the vendor tool, or should the revdep chain be packaged?
<niemeyer> mvo: I'm hoping to not confuse "support" here, as very often that means something specific and different
<mvo> niemeyer: yes, my bad, I wrote "contact" in bugreport and in my other irc, sorry for the confusion
<niemeyer> mvo: Thanks
<niemeyer> mvo: So people are unable to set their own contact field?
<niemeyer> mvo: Or where else the problem lies?
<mvo> niemeyer: AIUI the store hardcodes contact (supported-by is iirc the name still in use in the returned json) to the publishers primary email
<ogra_> well
<ogra_> the old UI allowed to set it
<niemeyer> mvo: I think I've seen some snaps using a URL
<mvo> niemeyer: i.e. no way to change that and no way to set it on a per-snap basis currently
<ogra_> ogra@pi3:~$ snap info upnp-server|grep contact
<ogra_> contact:   ogra@ubuntu.com?subject=upnp-server
<niemeyer> Ah, perhaps ogra nails it
<mvo> niemeyer, ogra_: yes, the old webui had this, it got removed as part of https://bugs.launchpad.net/snapstore/+bug/1672664 (private unfortunately)
<ogra_> (i used to set the subject line in that mailto link for every snap i have)
<niemeyer> mvo: Okay, that makes it pretty irrelevant.. I don't want my personal email on every snap I publish, for example
<niemeyer> Let's see if we can get that sorted
<mvo> niemeyer: I can create a forum topic if you want, I also filed https://bugs.launchpad.net/snapstore/+bug/1709610 just to be sure
<mup> Bug #1709610: Please allow "contact:" override on a per-snap basis <Snap Store:New> <https://launchpad.net/bugs/1709610>
<ogra_> the backend is definitely capable of doing it ... just the UI gield vanished when we switched to dashboard.s.io
<ogra_> *field
<pedronis> mvo: niemeyer: I think contact was added to snapcraft
<zyga-ubuntu> ikey: hello!
<mvo> ogra_: maybe we still set it in the db in a one-off basis, I don't know, I need to followup
<pedronis> but the store doesn't know
<zyga-ubuntu> ikey: I can help you out
<niemeyer> mvo: Thanks a lot! I'll open the forum topic and point to the ticket
<ikey> heya zyga-ubuntu :]
<mvo> pedronis: its not there yet afaics but I can trivially add it and push a PR ( doing some snapcraft things for bases anyway)
<ogra_> mvo, well, my snaps still have the "?subject=<snapname>"
<zyga-ubuntu> ikey: I'm not a solus user or developer but if you want to make a snapd package available I can help you out
<ogra_> so it seems to be handled when set
<mvo> niemeyer: https://bugs.launchpad.net/snapstore/+bug/1666792 and https://bugs.launchpad.net/snapstore/+bug/1709610 should have the relevant info
<mup> Bug #1666792: Please add "contact" field to the API <Snap Store:Incomplete by roadmr> <https://launchpad.net/bugs/1666792>
<mup> Bug #1709610: Please allow "contact:" override on a per-snap basis <Snap Store:New> <https://launchpad.net/bugs/1709610>
<ikey> zyga-ubuntu, well its basically a case of looking at how everyone else is packaging it. are they allowing networking during build, have a huge tarball, or package all the reverse golang deps as vendored packages (brittle) ?
<pedronis> niemeyer: it's also then proabably related to  https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/48 as well
<mvo> ogra_: yeah, lets see what the store people tell us, this is definitely encouraging
<zyga-ubuntu> ikey: all of those
<ogra_> mvo, this is definitely a regression :)
<zyga-ubuntu> ikey: depending on the distribution
<ikey> ok what does debian/ubuntu world do?
<ogra_> (specifically your second bug)
<ikey> because we have networking nuked in builds (solbuild implements a lightweight container)
<mvo> ogra_: yeah, that reminds me that I need to write a bugreport about the vanishing architecture in the webui, it used to be there but is no more
<zyga-ubuntu> ikey: different things actually, in debian snapd is packaged separately from all dependencies, in ubuntu it is a big tarball
<ikey> i can turn it on .. but.. yknow.
<ikey> hm ok
<zyga-ubuntu> ikey: what is customary for solus?
<zyga-ubuntu> (for golang)
<ogra_> mvo, oh, yes please ... thats super annoying (the uploads overview still has it, just not the details)
<zyga-ubuntu> are all golang modules packaged separately?
<ikey> well we actually have very few golang things packaged zyga-ubuntu except our own stuff (like solbuild) - but we create proper release tarballs for those with src/vendor submodules setup
<ikey> with src/vendor actually being git submodules
<zyga-ubuntu> ikey: aha
<ikey> and using git-archive-all to create a true dist tarball
<zyga-ubuntu> ikey: we have a "fat" tarball that mvo makes for each release I think
<ikey> consider my interest peeked
<ikey> lol
<zyga-ubuntu> ikey: so if you want to get started, start with that please
<ikey> sure would love it, ty
<pedronis> mvo:Â I'm probably just confused then, anyway the status about all these fields is confusing
<zyga-ubuntu> ikey: two requests
 * ikey listens
<zyga-ubuntu> ikey: can you please start a thread on forum.snapcraft.io about this, I'm sure many other people would love to know this is happening
<zyga-ubuntu> ikey: and as a personal request, can you please add /etc/os-release to github.com/zyga/o-release-zoo, it helps with some tests
<zyga-ubuntu> github.com/zyga/os-release-zoo
<mvo> pedronis: yeah, its all a bit in flux it seems, sounds like a good opportunity to clarify things (or my git tree is outdated, also quite possible :)
<mvo> pedronis: anyway, I get to the bottom of it
<ikey> zyga-ubuntu, for the 2nd one, we roll, so VERSION_ID is non static (heads up) - for the 1st one - uhm.. sure...? lol
<ikey> seems a bit like self promotion on my part doing so though :p
<zyga-ubuntu> sure
<ikey> PR sent to the zoo
<zyga-ubuntu> ikey: merged
<ikey> ta
<ikey> ok got a snapcraft.io forum account, what exactly am i posting here? :p
<zyga-ubuntu> ikey: just make a post that you're working on a package for solus
<ikey> aite
<ikey> in snapd tag ?
 * ikey & lost with discourse
<zyga-ubuntu> ikey: yes that's fine :)
<ikey> ta
<zyga-ubuntu> ikey: and please stay in touch, I'd love to help you with the package
<ikey> cheers, will do
<mup> PR snapd#3695 opened: interfaces: convert kvm to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3695>
<ikey> forum post done
<zyga-ubuntu> ikey: thanks, looking
<ogra_> 4 potential users \o/
<zyga-ubuntu> gary-wzl: hey, thank you for all the work :)
<mup> PR snapcraft#1447 opened: add support for the "contact" field in snapcraft <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1447>
<ikey> ogra_, lol
<zyga-ubuntu> gary-wzl: can you cross-review https://github.com/snapcore/snapd/pull/3696 please?
<mup> PR snapd#3696: interfaces: covert framebuffer to commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/3696>
<mup> PR snapd#3696 opened: interfaces: covert framebuffer to commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/3696>
<gary-wzl> zyga-ubuntu: sure, here is more to come. :)
<zyga-ubuntu> gary-wzl: reviewed kvm
<zyga-ubuntu> ikey: replied :)
<ikey> ta
<zyga-ubuntu> I guess I'll install solus now :-)
<ikey> might be worth waiting a few days tbh
<ikey> impending release
<ikey> and snapd will be more formally supported after that
<zyga-ubuntu> ikey: aha, I'll hold off then
<gary-wzl> zyga-ubuntu: reviewed and just left a comment.
<gary-wzl> zyga-ubuntu: I could fine-tune the framebuffer_test.go in a separated PR as I go.
<ogra_> cachio, do you happen to know where exactly i can find the code for "failover:emptysystemd" ?
<zyga-ubuntu> gary-wzl: I'm re-writing framebuffer tests now
<gary-wzl> zyga-ubuntu: Thanks!
<cachio> ogra_, yes,
<mup> PR snapd#3697 opened: docs: add PULL_REQUEST_TEMPLATE.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/3697>
<cachio> ogra_, https://github.com/snapcore/snapd/blob/master/tests/main/failover/task.yaml
<ogra_> cachio, thanks
<cachio> ogra_, I updated this test yesterday
 * ogra_ has been debugging a reboot failure with a customer for days ... it just struck me that this test actually *wants* it to fail :P
<ogra_> silly thinko
<cachio> mvo, resutls updated
 * mvo hugs zyga-ubuntu and zyga-suse
<mvo> cachio: things looks mostly good it seems, one strange pi2 issue, I try to reproduce htis now with my pi2 - I had forgotten just how long this takes :(
<mvo> cachio: and console-conf seems to be very unahppy, do you know what is going on there? maybe we can talk in the hangout
<ogra_> mvo, we should really pay him a psychiatrist there is a new personality coming every week now !
<ogra_> ETOOMANYZYGAS
<mvo> ogra_: he has as many personalities as there are linux distros ;)
<ogra_> yeah, i noticed :)
<cachio> mvo, most of console conf tests are known issues
<cachio> mvo, I'll take a look again
<mup> Issue # opened: snapcraft#1448, snapcraft#1449, snapcraft#1450, snapcraft#1451, snapcraft#1452, snapcraft#1453, snapcraft#1454
<cachio> mvo, for the pi2, I added a second link with the tests passing
<mvo> cachio: aha, great!
<mvo> cachio: yay
<zyga-ubuntu> gary-wzl: added
<jdstrand> zyga-ubuntu: done
<zyga-ubuntu> ogra_: just wait for more :)
<zyga-ubuntu> jdstrand: thank you!
<mup> Issue snapcraft#1455 opened: share cache with local container <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1455>
<mup> Issue snapcraft#1456 opened: clean up stale containers <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1456>
<mup> Issue snapcraft#1457 opened: remote per-project container <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1457>
<tedg> thomi: FYI, I just put the Inkscape update into the stable channel. If you want to watch the diffs there.
<tedg> thomi: Guessing it'll cause a bunch of traffic.
<mup> Issue # opened: snapcraft#1458, snapcraft#1459, snapcraft#1460, snapcraft#1461, snapcraft#1462
<mup> Issue snapcraft#1463 opened: core build triggers root  <designed> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1463>
<mup> Issue snapcraft#1464 opened: plugin reorg (rosdep) <designed> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1464>
<gary-wzl> zyga-ubuntu: +1
<gary-wzl> zyga-ubuntu: here is one more :)
<mup> PR snapd#3698 opened: interfaces: convert joystick to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3698>
<ogra_> cachio, oh, looking at your https://github.com/snapcore/snapd/commit/f1cf4755312713f8024a4c29e1b0173dd4a42419 ...
<ogra_> does that mean there never actually was an issue with resize ?
<ogra_> or is that unrelated ?
<zyga-ubuntu> gary-wzl: lovely, thanks!
<tedg> popey: Are you "snapcrafters" ? The discord app won't start because it's out-of-date.
<cachio> ogra_, this test was failing because of this
<ogra_> ok, so not related
<popey> tedg: just bumped it
<popey> building now
<tedg> popey: Great, thanks!
<popey> np, thanks for letting us know - https://github.com/snapcrafters/discord/blob/master/snap/snapcraft.yaml fyi
<tedg> popey: Cool, is upstream considering taking it on?
<popey> tedg: possibly.
<mup> Issue snapcraft#1465 opened: node classic path issue [bug](https://bugs.launchpad.net/snapcraft/+bug/1706371) <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1465>
<mup> Issue snapcraft#1466 opened: scriptlets erroring behavior <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1466>
<popey> tedg: edge has 0.0.2 - fancy testing it?
<mup> Issue snapcraft#1467 opened: rust plugin: new rustup <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1467>
<mup> Issue snapcraft#1468 opened: override ARCH for kbuild <designed> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1468>
<mup> Issue snapcraft#1469 opened: rust plugin: cache rust toolchain offline <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1469>
<mvo> zyga-ubuntu: can you ping me once you found out more about the fedora build failure please?
<popey> tedg: nvm, busted here.
<zyga-ubuntu> mvo: yes, installing 32 bit build now
<tedg> popey: Yeah, seemed to migrate and then stopped.
<popey> tedg: missing opengl plug, added it, and rebuilding
<cachio> mvo, I just updated the db results, 32/32
<cachio> ogra_, i found this http://elinux.org/RPi_SD_cards
<cachio> ogra_, late
<ogra_> oh wow
<ogra_> thats a gigantic table !
 * ogra_ wonders who tested all these cards 
<zyga-ubuntu> cachio: heh, I wanted to copy this link into the standup window but not having verified it I didn't want to bother you with unproven stuff
<mup> PR snapd#3695 closed: interfaces: convert kvm to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3695>
<zyga-ubuntu> mvo: thank you!
<zyga-ubuntu> mvo: I'm installing fedora 26 i386 (still)
<zyga-ubuntu> mvo: but I'm working on a branch to tweak snap-seccomp builds for everyone to make it easier
<mvo> ok
<cachio> ogra_, at least there is a name and date in the last column
<ogra_> yeah
<mvo> zyga-ubuntu: fwiw, for 2.27 I would love something *tiny* :)
<zyga-ubuntu> mvo: one more data point
<zyga-ubuntu> mvo: very tiny
<mvo> \o/
<ogra_> cachio, so your broken card is actually one marked red in that table ?
<zyga-ubuntu> mvo: one line change so far
<zyga-ubuntu> well, two
<zyga-ubuntu> mvo: if we do monthly releases I can help on xdistro more
 * ogra_ must be extremely lucky that he mostly got good cards then
<mvo> zyga-ubuntu: sounds good, I think we need to discuss this, but I think its reasonable
<mvo> zyga-ubuntu: moving to this model
<mvo> (eh schedule)
<zyga-ubuntu> mvo: so far my gut feeling is that +//#cgo CFLAGS: -D_FILE_OFFSET_BITS=64
<zyga-ubuntu> this is *enough*
<zyga-ubuntu> but need a sec to test
<cachio> ogra_, I think it is in green
<ogra_> weird
<ogra_> then it is probably really worn out
<ogra_> though ... the stable gadget has really old start.elf and friends
<ogra_> might be that it got fixed later by broadcom but the stable image doesnt have that fix
<ogra_> (testing edge would tell)
<ikey> so zyga-ubuntu i got the initial packaging working, but when i run "/snap/bin/hello", it just seems to time out forever â¢
<zyga-ubuntu> ikey: yep, there's a lot of missing bits I suspect
<ikey> just using devmode confinement atm
<cachio> ogra_, ok
<ikey> well, error messages wouldn't hurt :P
<cachio> do you have a link?
<zyga-ubuntu> ikey: I think it is waiting for the seccomp profile
<zyga-ubuntu> ikey: is snapd running?
<ikey> yes
<zyga-ubuntu> ikey: can you tell me if you patched anything?
<ikey> no im using 2.26
<ogra_> cachio, for edge images ?
<cachio> yes
<zyga-ubuntu> ikey: and what kind of installation layout did you pick for solus (e.g. /usr/lib vs /usr/libexec)
<zyga-ubuntu> ikey: /snap vs /var/lib/snapd/snap
<ogra_> cachio, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ or http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ (shoudl be largely identical)
<ikey> hm the snap mount dir could be the issue.
<zyga-ubuntu> ikey: I *think* you will want to do a few small patches first
<zyga-ubuntu> ikey: mark solus as a non-reexec distro for now (cmd/cmd.go)
<ogra_> cachio, i randomly test the images on the first url (not on a regular schedule or anything though)
<ikey> well until i make it do-a-thing i cant know what to patch
<zyga-ubuntu> ikey: and use /snap (that's way nicer and simple)
<ikey> because i wont know whats broken
<zyga-ubuntu> ikey: then look at journal output
<ikey> i did
<ikey> its useless
<zyga-ubuntu> ikey: you can set SNAP_CONFINE_DEBUG=yes to see what snap-confine may be doing
<cachio> ogra_, I am downloading http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+cm3.img.xz
<zyga-ubuntu> ikey: did you build and install snap-seccomp?
<ogra_> cachio, ok ... thats for the cm3 though ...
<cachio> no
<zyga-ubuntu> ikey: are snaps mounting correctly?
<cachio> http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz
<ogra_> ah
<cachio> ogra_, this one
<ogra_> yeah,  thats correct :)
<ikey> zyga-ubuntu, no because it doesnt exist in 2.26
<cachio> I dont have a cm3
<ikey> not from what i can see
<ogra_> yeah, only ondra does
<ikey> and yes they mount fine
<zyga-ubuntu> ikey: did you use _bare_ 2.26 or 2.26.14?
<ondra> ogra_ I have even two :P
<ogra_> heh
<ikey> 2.26.8
<zyga-ubuntu> ikey: please try .14, 2.26 is really rc0
<ikey> i.e. the one with a tarball
<zyga-ubuntu> aha
<zyga-ubuntu> mvo: could you please upload the tarball for 2.26.14
<zyga-ubuntu> mvo: ikey could use that for the solus package
<ikey> i assumed the new tags were unstable
<ikey> given they're not marked as releases on github
<zyga-ubuntu> no, they are more stable actually, we need to rework our naming so that they are correctly identified as release candidates
<zyga-ubuntu> ikey: yes, that's an omission on our part
<ikey> gotcha
<popey> tedg: missing lib, found it, working on it.
<ikey> well, good to know now :p
<ogra_> that is because we'd need five clones of mvo to do everything at the same time :)
<ondra> ogra_ sadly looks like they are now sold out
<ogra_> ondra, well, i'm not eager to get one, but QA (i.e. cachio and fgimenez ) should at some point
<ogra_> given it is a full supported device now
<ondra> ogra_ definitely
<ondra> ogra_ I thought they already do
<cachio> ogra_, Also we should have some of them in the lab
<ogra_> cachio, see what you got yourself into by posting the wrong link ?
 * ogra_ grins
<cachio> ogra_, heheh
<ogra_> yeah, lab too
<ondra> ogra_ BTW what was the conclusion yesterday about time when snapd from master lands in edge?
<ogra_> ondra, once the release is complete ... (watch the forum there should be an announcement)
<ondra> cachio I thought it was desired to have them in the lab, as one can reflash them without human interaction
<zyga-ubuntu> mvo: installed, building snapd
<mup> PR snapd#3690 closed: interfaces/wayland: add wayland interface <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3690>
<zyga-ubuntu> mvo: replied to your question on 3698
 * zyga-ubuntu needs to wait for 700+ RPM install/updates
<popey> tedg: ok, rev 19 in edge should work - works here.
 * zyga-ubuntu breaks for 45 minutes
<zyga-ubuntu> ikey: please ping me if you get stuck on anything
<zyga-ubuntu> Pharaoh_Atem: fixes for 32bits are in progress
<zyga-ubuntu> I need to release suse as well, so we can have a nice 2.27 soon
<zyga-ubuntu> but first ...
<zyga-ubuntu> taxes
<ppisati> ogra_: errrrr... i can't find a spread snap for armhf, is that correct?
<ogra_> ppisati, i think there should be one, perhps cachio_lunch can help (after lunch)
<tedg> popey: Hmm, no. It comes up to a grey screen and just stays there...
<tedg> popey: Ah, I had one dying silently in the background from an old version.
<popey> ya
<popey> i had that too
<tedg> Man, I wish snap had lifecycle management ;-)
<popey> Don't you start!
 * tedg may have complained about that before
<popey> ok, thanks for testing it. i tested in a vm too, all seems good, will promote
<mup> PR snapd#3694 closed: wrappers, overlord/snapstate/backend: make link-snap clean up on failure <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3694>
<ikey> zyga-ubuntu, just waiting for that tarball :)
<cachio> ppisati, hey, what do you need?
<ppisati> cachio: 'snap find spread' doesn't show any result on armhf, is that normal?
<cachio> ppisati, I never tried on armhf
<pstolowski> niemeyer, hey, one more question to you https://forum.snapcraft.io/t/how-to-snap-get-root-document/522/7
<cachio> ppisati, why you want to use it on arm?
<ppisati> cachio: because on user is reporting a problem with spread on a arm board
<ppisati> cachio: but the queston is, why can't find it on arm? -> snap find spread: 0 results
<ppisati> cachio: is that normal?
<ogra_> cachio, we have customers using it ... but i think he runs it as remote device
<cachio> ppisati, well the user should be executing spread from a amd64 against a divice with arm
<cachio> ppisati, spread allows to run the tests in remote devices
<Pharaoh_Atem> zyga-ubuntu: nice
<ppisati> cachio: uhm ok
<ogra_> i think theer is a forum thread where fgimenez pointed him to the setup
<cachio> ppisati, do you have a link to that report?
<ppisati> ogra_: are we talking of the orangepi guy?
<ogra_> yes
<ppisati> ogra_: ok
<zyga-ubuntu> Pharaoh_Atem: pushed as 3699
<mup> PR snapd#3499 closed: interfaces/builtin: add the spi interface <Created by tokurz> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3499>
<mup> PR snapd#3699 opened: cmd/snap-confine: set _FILE_OFFSET_BITS to 64 <Created by zyga> <https://github.com/snapcore/snapd/pull/3699>
<zyga-ubuntu> Pharaoh_Atem: I'll follow up with the tweak to static linking but separately so that mvo doesn't turn more gray
<zyga-ubuntu> Pharaoh_Atem: ^ can you have a look
<zyga-ubuntu> Pharaoh_Atem: btw, how do I opt-out of "updates-testing"
<Pharaoh_Atem> sudo dnf config-manager --set-disabled updates-testing
<Pharaoh_Atem> sudo dnf distro-sync
<zyga-suse> thanks, trying
<zyga-suse> that helped :)
<zyga-suse> thanks a lot!
<ikey> yay progress..
<ikey> /snap/bin/hello-world
<ikey> execv failed: No such file or directory
<ikey> /snap/hello-world/current/bin/echo
<ikey> Hello World!
<Chipaca> ikey: uh, that second thing you just did runs the binary "direct", not confined
<ogra_> ikey, thats cheating!
<ikey> ya i know
<Chipaca> don't do that :-)
<Chipaca> ah ok :-D
<ikey> i was pointing out that its not a linker issue :p
<ppisati> $ spread -v -reuse external:ubuntu-core-16-arm-32:tests/main/core-snap-refresh
<ppisati> error: invalid project name: ""
<ppisati> cachio: ^
<mup> PR snapd#3698 closed: interfaces: convert joystick to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3698>
<ogra_> ikey, anything in journalctl output ?
<Chipaca> ppisati: you need to run it from within the snapd project
<Chipaca> ppisati: ie it needs to be able to find spread.yaml
<ppisati> $ pwd
<ppisati> /home/flag/snapd
<ikey> Aug 09 16:51:36 ironhide /snap/bin/hello-world[4652]: cmd.go:66: DEBUG: re-exec not supported on distro "solus" yet
<ikey> and i had to patch it to stop the re-exec
<ppisati> Chipaca: ^
<ikey> otherwise it would timeout infinitely
<Chipaca> ppisati: and that's the spread.yaml there?
<ogra_> yeah, that should eb fine for now
<ogra_> i was hoping from something more
<Chipaca> ppisati: or is that where src/github.com/snapcore lives?
<cachio> ppisati, where are you executing this?
<ikey> so was i..
<ogra_> heh
<cachio> ppisati, from snapd fir?
<cachio> dir
<ogra_> good that we are in agreement :P
 * ikey has no clue what it is it can't exec
<ogra_> (not thatz it helps)
<ogra_> yeah, that needs someone from the snapd core team ...
<ppisati> cachio: snapd root
<ogra_> Chipaca, any way for ikey to turn on more debugging to find out what file or diectory is missing for the execv ?
<cachio> ppisati, is there a file spread.yaml ?
<cachio> ppisati, can you share it?
<ogra_> ikey, ah, found Chipaca's mail from recently ...
<ogra_> The easiest way is to add a couple of lines to /etc/environment and
<ogra_> then restart snapd. You want
<ogra_> SNAPD_DEBUG=1
<ogra_> SNAPD_DEBUG_HTTP=7
<ogra_> The log can be quite verbose (journalctl -u snapd) but I find it very
<ogra_> helpful.
<ogra_> try that ...
<ikey> ta
<ppisati> cachio: i've just cloned the snapd repo from github
<ppisati> flag@harukaze:~/snapd$ git lg -1
<ppisati> 300f3a6 Merge pull request #3499 from tokurz/spi-patch
<ppisati> flag@harukaze:~/snapd$ git status
<ppisati> On branch master
<ppisati> Your branch is up-to-date with 'origin/master'.
<ppisati> nothing to commit, working directory clean
<ikey> ogra_: /snap/bin/hello-world
<ikey> 2017/08/09 17:00:51.349635 cmd.go:66: DEBUG: re-exec not supported on distro "solus" yet
<ikey> execv failed: No such file or directory
<ikey> *shrugs*
<ogra_> boo
<ogra_> lame
<ogra_> well, does your systemd unit actually make use of /etc/environment ?
<ogra_> else you need to set the vars there
<ikey> yes
<ikey> anyways i added the stuff to the forum thread
<ogra_> +1
<ikey> it can be tomorrows problem.. lol
<Pharaoh_Atem> :D
<cachio> ppisati, the spread that you are using is the snap one?
<cachio> ppisati, I'll try with that
<Chipaca> zyga-ubuntu: have you seen bug #1673186?
<mup> Bug #1673186: the gox classic snap gets stuck consuming a lot of cpu <classic> <isv> <snapd:Confirmed> <https://launchpad.net/bugs/1673186>
<zyga-ubuntu> Chipaca: nope
<zyga-ubuntu> looking
<ppisati> cachio: yes, installed via snap
<Chipaca> zyga-ubuntu: it's from ~april but i don't think we've seen it before now
<cachio> ppisati, i'll try that
<cachio> in the meantime you can use the one in aws
<cachio> wget https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz -O spread.tar.gz && tar xzvf spread.tar.gz
<cachio> ppisati, ^
<cachio> ppisati, I use that one
<pedronis> Chipaca: IÂ left another annoying remark
<Chipaca> pedronis: the one about snapNames[]?
<pedronis> yes
<Pharaoh_Atem> zyga-ubuntu: testing build with that PR on 32-bit Fedora
<Chipaca> pedronis: i was just replying when other things interrupted me
<Chipaca> pedronis: replied now
<zyga-ubuntu> Pharaoh_Atem: thank you
<pedronis> Chipaca: answered to the reply
<zyga-ubuntu> Chipaca: trying to reproduce
<Chipaca> pedronis: aha, but did you reply to the answer?
<Chipaca> pedronis: did your answer get truncated?
<pedronis> Chipaca: yes, fixed
<Chipaca> pedronis: do you agree that a sorted list is too obscure?
<pedronis> Chipaca: yes
<pedronis> it's either sort internally or make  map internally
<pedronis> or keep as it
<pedronis> precedent points in the direction of not keep as is
<Chipaca> pedronis: the deciding factor when I wrote it was that whatever I passed in was getting built from scratch anyway, so I might as well build what i needed
<Chipaca> otherwise i'm just creating a slice to create a map
<pedronis> Chipaca: IÂ understand but I'm not sure that logic applies strongly here, because n is small
<Pharaoh_Atem> zyga-ubuntu: scratch build fired off: https://koji.fedoraproject.org/koji/taskinfo?taskID=21129976
<Chipaca> pedronis: in the common case yes, but in the worst case?
<Pharaoh_Atem> incidentally, your patch does not apply on 2.27 branch tip
<Chipaca> pedronis: or should i not worry about that :-)
<Chipaca> bah, even worst case it'll be ~1000 big for a good while yet
 * Chipaca stops worrying
<pedronis> Chipaca: yes, big is not that big or we are talking weird
<Chipaca> pedronis: also, also, it not being a map means i need to dedupe it :-)
 * Chipaca is doing the change while complaining
<pedronis> Chipaca: shouldn't you error anyway if names has the same thing twice?
<pedronis> it's a bit strange
<Chipaca> pedronis: in daemon
<pedronis> shouldn't you error in daemon, I mean
<Chipaca> pedronis: names comes from list of services, which can easily have more than a snap
<pedronis> mmh
<pedronis> I see
<Chipaca> pedronis: that is, i have [snap-a.foo, snap-a.bar] and i want [snap-a]
<pedronis> or not
<pedronis> anyway given what the function does it works deduped or not
<pedronis> I mean if you turn it into a map and don't check it works anyway, no?
<pedronis> don't conflict with A and btw don't conflict with A
<Chipaca> pedronis: yes
<Chipaca> exactly how soaked am i going to get if i go running in this?
 * Chipaca asking the big questions
<pedronis> Chipaca: +1 with a last wondering
<ogra_> sounds like a movie title ...
<ogra_> "The last wondering"
<Pharaoh_Atem> zyga-ubuntu: it works: https://github.com/snapcore/snapd/pull/3699
<mup> PR snapd#3699: cmd/snap-confine: set _FILE_OFFSET_BITS to 64 <Created by zyga> <https://github.com/snapcore/snapd/pull/3699>
<Pharaoh_Atem> mvo: ^
 * Chipaca takes a break
<zyga-suse> Pharaoh_Atem: thank you for checking
<mvo> zyga-suse: yay, thanks you
<zyga-suse> mvo: let's merge it
<mup> PR snapd#3696 closed: interfaces: covert framebuffer to commonInterface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3696>
<mup> Bug #1666978 changed: Security setup may fail with ErrNoState if repository and snapstate get out of sync <Snappy:Fix Released> <https://launchpad.net/bugs/1666978>
<cachio> ogra_, same problem with the image from adge
<zyga-ubuntu> Chipaca: bug "fixed"
<cachio> ogra_, but the command line is ok now
<cachio> pointing to ttyS0
<zyga-ubuntu> Chipaca: anyone else needs to know about this?
<zyga-ubuntu> sergiusens: ^^
<zyga-ubuntu> you want to look at https://bugs.launchpad.net/snapcraft/+bug/1673186
<mup> Bug #1673186: the gox classic snap gets stuck consuming a lot of cpu <classic> <isv> <Snapcraft:Confirmed> <snapd:Invalid> <https://launchpad.net/bugs/1673186>
<ogra_> cachio, hmm
 * zyga-ubuntu EODs
<mup> PR snapd#3699 closed: cmd/snap-confine: set _FILE_OFFSET_BITS to 64 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3699>
<mup> Bug #1671446 changed: content interface behaves different if tried an operation before connecting the interface <Snappy:New> <https://launchpad.net/bugs/1671446>
<Chipaca> zyga-ubuntu: kenvandine
<kenvandine> Chipaca, ah, thx!
<zyga-ubuntu> kenvandine: note that you can work around this
<zyga-ubuntu> kenvandine: just specify the executable as bin/foo
<zyga-ubuntu> kenvandine: snapcraft will expand this to $SNAP/bin/foo
<kenvandine> zyga-ubuntu, cool, thx
<zyga-ubuntu> kenvandine: and it will no longer run /snap/bin/foo
<jhodapp> can someone explain to me what an explicit slot vs an implicit slot is?
<zyga-ubuntu> jhodapp: I can
<zyga-ubuntu> jhodapp: implicit slots are added to the core snap even if they are not declared in the corresponding snap.yaml
<zyga-ubuntu> jhodapp: all other slots are explicit because they are just spelled out in some yaml file in a snap
<jhodapp> zyga-ubuntu, that makes a lot of sense
<zyga-ubuntu> ikey: hey, 2.26.14 should be available as a tarball now
<ikey> zyga-ubuntu, much appreciated!
<zyga-ubuntu> ikey: I also replied to the forum thread
<zyga-ubuntu> if you can list the files in your package I can help you out
<zyga-ubuntu> I suspect you are missing onefile
<ikey> ew forced static seccomp link
<mup> PR snapcraft#1470 opened: catkin plugin: default to release build <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1470>
<mup> PR snapcraft#1471 opened: catkin plugin: support passing args to cmake <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1471>
<cachio> Son_Goku, hey
<cachio> I see this https://paste.ubuntu.com/25278920/ in some executions on fedora
<cachio> Son_Goku, it is when it tries to uninstall snap-confine
<Son_Goku> hmm
<cachio> it is happening sporadically
<cachio> Son_Goku, I can't reproduce it, but I already saw it twice in the test results
<Son_Goku> hmm
<zyga-suse> it feels like missing cleanup
<zyga-suse> or something like htat
<mup> PR snapcraft#1425 closed: options: properly handle missing compiler prefix <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1425>
<mup> PR snapcraft#1472 opened: catkin plugin: include-roscore is a boolean <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1472>
<mup> PR snapcraft#1473 opened: catkin plugin: rosinstall-files is a pull property <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1473>
<mup> PR snapd#3700 opened: tests: fix for  upgrade test on fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3700>
<mup> PR snapcraft#1417 closed: kbuild plugin: move over the cross-compiling logic from the kernel plugin <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1417>
<mup> PR snapcraft#1472 closed: catkin plugin: include-roscore is a boolean <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1472>
#snappy 2017-08-10
<mup> PR snapcraft#1470 closed: catkin plugin: default to release build <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1470>
<jaggz> snap install /tmp/meshlab-cYdtAIYBmTS1b7L2q8yrMdpAZ38qLv6Q_4.snap
<jaggz> - Copy snap "meshlab" data (cannot copy "/var/snap/meshlab/4" to "/var/snap/meshlab/4": failed to copy all: "cp: cannot stat '/var/snap/meshlab/4': No such file or directory" (1))
<jaggz> anyone know what that's about?  the dir exists.  I also intermittently get a core error
<jaggz> ...
<jaggz> # snap refresh core
<jaggz> error: cannot perform the following tasks:
<jaggz> - Setup snap "core" (2601) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": fork/exec /usr/lib/snapd/snap-update-ns: no such file or directory)
<mup> PR snapd#3701 opened: tests: fix interfaces-cups-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3701>
<PhoenixMage> How jailed are snaps? They seem to log to the root /var/log
<PhoenixMage> ie, I now have samba.log files in /var/log after installing the samba snap I am working on
<mup> PR snapd#3702 opened: interfaces: add missing test for camera interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3702>
<mup> PR snapd#3703 opened: interfaces: improve and tweak bunch of interfaces test cases <Created by adglkh> <https://github.com/snapcore/snapd/pull/3703>
<PhoenixMage> What is the correct way to create required directories for a snap?
<PhoenixMage> ie, /etc if it doesnt exist?
<PhoenixMage> Hooks?
<mup> PR snapd#3704 opened: interfaces: convert lxd to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3704>
<zyga-suse> good morning
<zyga-suse> mvo: how are we doing?
<mup> PR snapd#3657 closed: daemon, client, cmd/snap: implement snap start/stop/restart <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3657>
<Chipaca> woooooooooooooo
<zyga-suse> hey Chipaca, feels good to have the merge go in :)
<Chipaca> yes
<mvo> hey zyga-suse
<mwhudson> zyga-suse: o/
<zyga-suse> hey hey
<zyga-suse> I have one important bug to check and then I'd like to release suse and arch packages
<zyga-suse> some perspective form appimage developers: https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues
<mup> PR snapd#3705 opened: interfaces: convert lxd_support to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3705>
<mvo> zyga-suse: can you check if rc9 builds?
<zyga-suse> mvo: sure, where?
<mvo> zyga-suse: suse, arch
<zyga-suse> with pleasure
<zyga-suse> do you have tarballs?
<zyga-suse> I'll build master locally but it would help to have rc tarballs
<mvo> zyga-suse: I can prepare one, otherwise in the ppa
<zyga-suse> (do you still make them manually?)
<zyga-suse> for various reasons it is easier if they are on github (various tools can pull them like in debian)
<mvo> zyga-suse: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+files/snapd_2.27~rc9.tar.xz
<mvo> zyga-suse: aha, ok
<zyga-suse> ok
<zyga-suse> this is fine
<mvo> zyga-suse: ok, thank you. I have a script that creates them now
<zyga-suse> awesome, it would be good to commit that to the tree at some point
<mup> PR snapd#3700 closed: tests: fix for  upgrade test on fedora <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3700>
<mup> PR snapd#3706 opened: asserts,overlord/devicestate: support predefined assertions that don't establish foundational trust <Created by pedronis> <https://github.com/snapcore/snapd/pull/3706>
<mwhudson> zyga-suse: so what's the debian update waiting on?
<zyga-suse> mwhudson: not sure, I didn't look at debian seriously for too long :/
<zyga-suse> mwhudson: I think we want 2.27 across the stack
<mwhudson> zyga-suse: ok
<mwhudson> zyga-suse: on the dependency side
<mwhudson> zyga-suse: we can leave the i18n commented out for now i guess
<zyga-suse> I think that's acceptable
<mwhudson> zyga-suse: i need to find a sponsor to upload golang-go-flags-dev
<zyga-suse> is the patch extensive?
<zyga-suse> oh, I assumed you are a DD
<mwhudson> no
<mwhudson> zyga-suse: not yet :)
<mwhudson> i am in the process
<zyga-suse> great :)
<mvo> mwhudson: let me know, I can help
<mwhudson> the x/net fork can be avoiding by simply not running that test in the build?
<mwhudson> mvo: https://anonscm.debian.org/cgit/pkg-go/packages/golang-go-flags.git/
<mwhudson> oh wait
<mvo> mwhudson: if you create something that I just need to sign/dput, that would be best for me
 * zyga-suse iterates on the opensuse package
<zyga-suse> some things failed on 2.25 still, but perhaps just racy tests
<zyga-suse> I'll focus on 2.27
<mwhudson> mvo: ack
<zyga-suse> mvo: the tarball has different name and internal directory name than the one before
<zyga-suse> not complaining but pointing out that we should perhaps use snapd-$version on the inside
<zyga-suse> and pick whatever fixed on the outside
<mvo> zyga-suse: meh, yes
<mvo> zyga-suse: part of the problem is the debian build tools, but I don't want to make excuses
<mvo> zyga-suse: I look into it
<zyga-suse> debian build tools?
<mvo> zyga-suse: the tarball is generated from the git repo, I will see what I can do with git-buildpackage
<zyga-suse> ok
<mwhudson> zyga-suse, mvo: and we thing we can use upstream instead of github.com/mvo5/libseccomp-golang for debian?
<zyga-suse> I'd love to
<zyga-suse> mvo: is that under golang CLA?
 * zyga-suse needs to refresh some patches
<zyga-suse> well
<zyga-suse> packaging 010
<zyga-suse> 101 even :P
<mwhudson> mvo: i've made something for you to upload but i'm going to test build it before i give you the link :)
<ikey> zyga-suse, what are the chances of getting core snap to ship libselinux?
<zyga-suse> ikey: hey
<ikey> heya
<zyga-suse> ikey: I saw your comments
<zyga-suse> ikey: I need to look into it
<mvo> mwhudson: yeah, upstream libseccomp-golang should be fine, all I did there was adjust for trusty
<zyga-suse> ikey: it feels more like a bug in the app than something that really really should be in the core
<mvo> mwhudson: our trusty libseccomp is heavily backported
<ikey> zyga-suse, well its all over the place
<zyga-suse> ikey: but I want to look at it for real before making any calls
<mwhudson> okidoke
<ikey> core's own Things use libselinux
<ikey> like gio-querymodules:
<ikey> and other bits
<ikey> it would seem core isn't as clean and self contained as it thinks it is
<zyga-suse> ikey: I see ./lib/x86_64-linux-gnu/libselinux.so.1
<zyga-suse> (that's relative to core itself)
<ikey> is it possible this is some derpy side effect of not having rexec?
<ikey> *re-exec
<zyga-suse> no, probably a bug somewhere else
<ikey> ok
<zyga-suse> look at dirs/dirs.go
<zyga-suse> I think you may need to say that on solus you use lib64 to keep distro binaries
<ikey> im loath to including libselinux in solus because, well, it infects stuff
<mwhudson> mvo: http://people.canonical.com/~mwh/golang-go-flags-dev/
<zyga-suse> (AFAIR snapd is there
<zyga-suse> as are other relevant parts)
<ikey> ah so multiarch vs multilib
<ikey> curious, ty
<zyga-suse> ikey: you should never have to include anything in the distribution to make a given snap work
<ikey> that was my thought
<zyga-suse> snaps don't see anything from the host really (not libraries)
<zyga-suse> ikey: do you know how it roughly works at runtime?
<zyga-suse> ikey: as a big approximation: the *base* snap (e.g. core but other bases are in progress) is used as the root filesystem
<zyga-suse> ikey: some things like /dev, /proc and /sys are "normal" (dev may be empty-ish, depending on confinement)
<zyga-suse> ikey: some things from the host are overlaid (e.g. parts of /etc)
<ikey> right
<zyga-suse> ikey: /home and /root are shared but $HOME is changed
<zyga-suse> ikey: the real host root filesysystem is in /var/lib/snapd/hostfs
<zyga-suse> ikey: (with certain things unmounted, like sysfs and dev because it confuses apps
<zyga-suse> ikey: there's a long tail of small tweaks
<ikey> aye
<zyga-suse> ikey: but the main point is: the host distribution is not used for runtime libraries or executables
<ikey> well thats the theory
<zyga-suse> no, we really don't use them, what do you mean?
<ikey> well at this point its not completely using the core snap either
<zyga-suse> yep, something is not right yet
<zyga-suse> but I bet this is packaging issue
<zyga-suse> if you want I can install solus and help you out
<ikey> you'll forgive me for saying but i dont quite see *how* it would be a packaging issue
<zyga-suse> I'm working on opensuse and arch but then I can try out solus :)
<ikey> when it looks more like the helper scripts are invoked host side
<ikey> and not containerised
<zyga-suse> can you please run the hello snap after setting SNAP_CONFINE_DEBUG=yes
<ikey> setting where, /etc/environment?
<zyga-suse> ikey: oh, one important point: if a snap uses 'classic confinement' then none of what I just said is true
<ikey> sure
<zyga-suse> ikey: just export it in your shell
<zyga-suse> classic confinement is a different beast
<ikey> yeah thats more at the appimage end of the spectrum
<zyga-suse> mvo: this is still breaking: [  622s] FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune
<ikey> https://hastebin.com/ixovewisig.sql
<mvo> zyga-suse: breaking where?
<zyga-suse> mvo: the unit test fails randomly
<zyga-suse> mvo: run it 1000 times and see the failure rate
<mvo> ok
<zyga-suse> ikey: this worked, can you try with a more complex snap next? what did you try to use before?
<ikey> brackets went boom
<ikey> but thats classic
<zyga-suse> ikey: brackets is a classic snap :/
<zyga-suse> so classic confinement uses different things
<ikey> yer
<zyga-suse> and what must be happening is that the snap itself is broken
<zyga-suse> classic confinement is defined as follows:
<ikey> a large number of them are broken*
<Chipaca> pedronis: o/
<zyga-suse> there is no file-system redirection
<zyga-suse> the core snap is in a well-known spot
<zyga-suse> as is the snap itself
<zyga-suse> those resources are guaranteed
<ikey> sure but wouldnt you also alter LD_LIBRARY_PATH to factor in core runtime?
<ikey> before executing the snap
<zyga-suse> other resources MAY be used but the snap author must do that with sanity
<zyga-suse> ikey: no, because that's snaps responsibility, some snaps are built in a way that this is not a factor
<zyga-suse> eg.
<zyga-suse> try python0
<ikey> eh
<zyga-suse> and look at the binary itself
<zyga-suse> and at how it is linked
<ikey> yeah im gonna have to disagree there
<zyga-suse> the fact is that many snap with classic confinement are built in as sloppy way
<ikey> so even with LD_LIBRARY_PATH, rpath is going to work fine
<zyga-suse> ikey: I can tell you why we're not setting LD_LIBRARY_PATH
<zyga-suse> ikey: because that breaks classic snaps that do certain things
<zyga-suse> there's no silver bullet here,
<zyga-suse> snaps using classic confinement *may* run apps from the host distribution
<zyga-suse> and then setting this would break that
<zyga-suse> I would argue that brackets is just done incorrectly and assumes to run on a ubuntu-ish system too much
<ikey> right but its not *just* brackets that fails
<ikey> its the scratch setup scripts in core
<ikey> i.e. update icon cache, schemas, etc
<zyga-suse> scratch setup scripts?
<ikey> idk what you call them :P
<zyga-suse> we don't have *any* scripts
<zyga-suse> so whatever you are describing comes from the snap itself
<zyga-suse> unfortunately classic confinement snaps are always going to be a hit-and-miss because when it runs on the developer's machine it doesn't mean it will run elsewhere for sure, like strictly confined snaps do
<ikey> all the GUI snaps do seem to invoke gtk-update-icon-cache-3.0 (which doesnt exist) and there are some spam-debug lines about schemas, etc
<zyga-suse> ikey: that must be a common bug in those snaps then, I'm sure it can be addressed
<zyga-suse> (note that core doesn't ship any of that)
<zyga-suse> many snaps use a common helper
<zyga-suse> and if the helper has a bug we just need to fix it in one place and the next revision of those snaps will improve
<ikey> non-classic:
<ikey> (assuming duckmarines is non classic)
<zyga-suse> snap info foo
<ikey> /snap/duckmarines/9/usr/lib/x86_64-linux-gnu/glib-2.0/gio-querymodules: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
<zyga-suse> this will tell you
<ikey> DEBUG: confinement:  non-classic
<zyga-suse> when you install a snap you have to say --classic
<zyga-suse> mm, that's more interesting, let me see
<ikey> it does eventually flop (no doubt due to missing apparmor)
<ikey> [1]    5959 invalid system call  snap run duckmarines
<ikey> but im more interested in the library fail first
<zyga-suse> ikey: invalid system call == it was killed by seccomp
<zyga-suse> can you look at your journalctl/dmesg and look for seccomp
<zyga-suse> I wonder what killed it
<zyga-suse> are you on x86 or x86_64 system?
<ikey> x86_64
<zyga-suse> ok
<zyga-suse> (there were some socket/socketcall bugs on 32bit intel systems0
<zyga-suse> because kernel changed
<ikey> not seeing errors in either. odd.
<pedronis> Chipaca: hi
<zyga-suse> ikey: interesting, I just ran duckmarines on opensuse and it worked, no messages about missing libselinux.so.1
<ikey> can you verify if you have a host-side libselinux?
<zyga-suse> let me see what's going on deeper
<zyga-suse> ikey: again, host side libselinux is not accessible in any normal way
<ikey> sure
<ikey> but can you? :P
<zyga-suse> yes, checking anyway :-)
<ikey> im seeing this:
<ikey> 17/08/10 10:02:33.232761 taskrunner.go:367: DEBUG: Running task 298 on Do: Mount
<ikey> led to reset devices.list on /system.slice: Invalid argument
<zyga-suse> ikey: hmmm, can you do "snap changes"
<ikey> https://hastebin.com/eramororan.sql
<Chipaca> pedronis: i hate that i can't get aliases from the app info :-)
<pedronis> Chipaca: they are not part of the snap anymore
<Chipaca> pedronis: i know
<zyga-suse> 2    Error   2017-08-09T18:51:45Z  2017-08-09T18:51:54Z  Install "hello-world" snap
<zyga-suse> can you do "snap change 2"
<pedronis> Chipaca: anyway you should probably build whatever you build close to where we build the alias symlinks no?
<pedronis> so it shouldn't be your problem
<zyga-suse> ikey: I have libselinux.so.1 but it is in /lib which is not shared
<ikey> have you verified that with LD_DEBUG=libs?
<pedronis> Chipaca: IÂ don't know what you did for other apps, but isn't something you can take care of in backend or wrappers ?
<zyga-suse> ikey: let's try (though I bet it cannot be that simply because we pivot_root and ther host /lib is gone)
<zyga-suse> ikey: one more tip
<Chipaca> pedronis: i was trying to do it in wrappers, but wrappers doesn't have them
<zyga-suse> ikey: snap run --shell snapname.appname
<pedronis> Chipaca: s/other apps/normal app entry points/
<zyga-suse> ikey: this drops you in a shell
<Chipaca> pedronis: so i've got to do it in backend
<ikey> aite
<zyga-suse> where you can run stuff with same environment and other magic
<Chipaca> pedronis: (the "normal" app entry points are done in wrappers)
<zyga-suse> useful for debugging
<pedronis> Chipaca: backend has stuff both for normal entrypoints and aliases so yes, seems a reasonable place
<pedronis> crosscutting concerns and everything considering
<ikey> the --shell looks an awful lot like my host system
<zyga-suse> ikey: look at /proc/mountinfo
<zyga-suse> ikey: aaaah
<zyga-suse> I know what's the problem
<zyga-suse> maaan
<zyga-suse> so obscure
<zyga-suse> :D
<zyga-suse> sorry, it's my fault entirely
<zyga-suse> go to cmd/snap-confine
<mvo> mwhudson: many thanks, uploaded, waiting for the confirmation mail
<pedronis> Chipaca: it seems simple, I'm probably missing something, because we do tell backend about what aliases we want to make very precisely
<zyga-suse> ikey: sorry, go to cmd/libsnap-confine-private and fix classic.c
<Chipaca> pedronis: and, to make things more interesting, UpdateAliases doesn't clean up on error
<zyga-suse> ikey: super obscure because most distros are derivatives so we didn't notice
<ikey> bool is_running_on_classic_distribution()
<ikey> o_O
<Chipaca> pedronis: </rant>
<Chipaca> pedronis: :-)
<zyga-suse> ikey: snapd knows this via other means but currently it doesn't say to snap-confine "you are on a classic distro"
<mwhudson> mvo: you uploaded it to ubuntu :)
<mvo> pedronis: quick question -  I want to add auto-download/install of misisng bases (and also of missing content-provider snaps). do you think snapstate is the right place?
<ikey> and what does "classic distro" mean?
<zyga-suse> ikey: snapd can run in a "core" distro where everything is a snap
<mvo> mwhudson: yes and to debian
<zyga-suse> ikey: like ubuntu-core
<mvo> mwhudson: for good measure ;)
<mwhudson> mvo: ah ok
<pedronis> mvo: yes
<mwhudson> Rejected:
<mwhudson> Unable to find distroseries: unstable
<mvo> mwhudson: no, sorry, the initial upload was a mistake
<zyga-suse> ikey: the kernel is a snap, the whole host filesystem is a snap, etc
<ikey> wait so right now snapd is acting like its on ubuntu core?
<mwhudson> mvo: ok:)
<PhoenixMage> so close yet so far away to getting samba running as a snap
<mvo> pedronis: great, I will move forward with that
<zyga-suse> ikey: and in that mode, we don't have the mount namespace changes since the main namespace is the core snap already
<ikey> xD
<zyga-suse> ikey: that is actually going away as we introduce bases
<ikey> gotcha
<PhoenixMage> ldb: unable to stat module //lib/samba/ldb : No such file or directory buit the dir is populated with the modules
<pedronis> mvo: remember that auto-refresh doesn't even go through api anymore for example
<zyga-suse> ikey: but it is a pretty obscure part of snapd :)
<mvo> mwhudson: happens all the time to me, I need to write me something that refuses to upload debian distor names to ubuntu
<zyga-suse> ikey: sorry and thank you for finding it
<ikey> awkward ikey with his not-derivative-ness
<ikey> thanks bud
<mvo> pedronis: yes, good point
<zyga-suse> ikey: that should fix a loooot of things :)
<ikey> yeah im sure lol
<pedronis> mvo: so there's probably not even another option atm
<mwhudson> mvo: i have this desire to write a wrapper for dput that does a whole bunch of validation
<ikey> alright lemme rebase my patch and make it all solusy
<mwhudson> mvo: like, if the target is a ppa and the version doesn't have "~ppa" in --> DENIED
<zyga-suse> thank you :)
 * zyga-suse adds that to his mental porting list
<zyga-suse> mvo: that test fails all the time, let me investigate
<mvo> mwhudson: I would give you an extra hug for such a wrapper
<zyga-suse> mwhudson: I have a desire for a debian dev tool that is not a wrapper over wrappers over perl but ... well
 * zyga-suse sings along
<mwhudson> zyga-suse: there are go libraries for all this stuff :)
<mwhudson> but tbh i find the perl ones easier to use
<zyga-suse> go-debhelper?
<zyga-suse> ;-)
<mwhudson> pault.ag/Debian/something
<zyga-suse> fair enough, at some point the amount of ducktape exceeds critical mass and we get a black hole of packaging
<mwhudson> you think that hasn't happened already? :)
 * zyga-suse grabs some coffee while deps are pulled
<mvo> zyga-suse: I'm preparing 2.27 now, should I also update the packaging/suse snapd.spec file?
<zyga-suse> mvo: perhaps-ish, in which way?
<mvo> zyga-suse: bump version number, add changelog
<zyga-suse> mvo: please, I'll do the rest
<mvo> zyga-suse: this is what I currently do on fedora too
<mvo> zyga-suse: ok
<zyga-suse> I will probably have more patches that I merge back to master
<zyga-suse> mvo: I'm worried about that test failure though
<zyga-suse> I'm running it now
<mvo> zyga-suse: the prune one?
<zyga-suse> yes
<zyga-suse> mvo: (there's also arch, if you have one vm handy)
<zyga-suse> mvo: I merged arch packaging back
<mvo> I think we had it for a long time, no regression
<mvo> zyga-suse: I have no vm but I can upadate version and changelog there too
<zyga-suse> mvo: I think we fixed a while ago
<zyga-suse> mvo: not sure if there's a changelog, look if anything seems obviously stale there
<zyga-suse> mvo: I'll update arch as soon as I'm done with opensuse
<mvo> zyga-suse: what does "Release: 2" in the suse spec file mean?
<zyga-suse> mvo: it's -2 in debian-speak
<zyga-suse> reset that to 1 if the upstream version is bumped
<mvo> zyga-suse: aha, so I set it back to -1 ?
<zyga-suse> precisely :)
<mvo> ta
<mvo> zyga-suse: there is no changelog in the suse spec file so that update is easy :)
<zyga-suse> mvo: suse changelogs are in separate files
<zyga-suse> snapd.changes
 * zyga-suse sings along 
<mvo> zyga-suse: fun
<zyga-suse> so many ways to do everything
<zyga-suse> mvo: I suspect both suse and arch will carry small patches
<zyga-suse> mvo: but that is fine
<zyga-suse> let's get the 2.27 elephant out of the door
<zyga-suse> mvo: I plan to test your /snap symlink support patch in arch and add that to the release
<zyga-suse> pedronis: remember the prune test that failed?
 * mwhudson stares at the upstream packaging/ubuntu-16.04 and the one from debian's 2.21-2
<zyga-suse> pedronis: either something changed or our fix was wrong because it just always fails on opensuse tumbleweed for me
<pedronis> zyga-suse: IÂ don't know
<mvo> zyga-suse: yeah, I have no arch packaging in the 2.27 branch so I will ignore that for now
<pedronis> always seems strange though
<mvo> mwhudson: is it very different?
<zyga-suse> https://paste.gnome.org/p0rrl0u4j
<zyga-suse> pedronis: can you have a look if that rings a bell?
<pedronis> IÂ mean it seems unrelated to details of the test
<mwhudson> mvo: no, not really
<zyga-suse> mvo: well, yes
<zyga-suse> mvo: vendorized vs not
<mwhudson> zyga-suse: that part is easy :)
<zyga-suse> pedronis: ah, that I agree with
<mvo> mwhudson: if you think it makes sense we can put the debian packaging into upstream git as well
<pedronis> zyga-suse: nothing obvious comes to mind
<zyga-suse> pedronis: let me dig, then
<mvo> zyga-suse: what format is supported in snapd.changes? or is that just free form?
<zyga-suse> mvo: "osc vc" format
 * mvo googles
<zyga-suse> one sec
<zyga-suse> https://paste.gnome.org/pz2dhm3qz
<zyga-suse> mvo: that's my latest entry
<zyga-suse> (still WIP)
<zyga-suse> entries are delimited by those dashes
<pedronis> zyga-suse: also remember we fixed one but I think there's another one to fix, that we never got to
<mwhudson> mvo: yeah that might make sense
<zyga-suse> pedronis: yes but this is the one we fixed AFAIK
<mvo> zyga-suse: mostly wondering about nesting
<zyga-suse> mvo: not sure
<mvo> mwhudson: let me know if I can help, otherwise I will welcome a PR :)
<zyga-suse> pedronis: this is confirmed by git blame: 59472d24b3
<pedronis> anyway always seems weird
<zyga-suse> ikey: does it work better now/
<zyga-suse> ikey: I'm really surprised even "hello" worked :)
<zyga-suse> maybe because it is a shell script
<ikey> zyga-suse, so
<ikey> done some initial porting
<ikey> there are more odd assumptions
<ikey> /run/media is locked to MERGED_USR
<ikey> that shouldn't be the case
<ikey> /run/media is just modern-systemd-fhs-udev-udisks
<ikey> and shouldn't rely on the MERGED_USR assumption
<ikey> additionally.. why is /usr/src required?
<ikey> this makes little sense to me ..
<zyga-suse> ikey: some snaps have permissions to build and load a kernel module and they require access to the kernel source, if you have some on the machine
<ikey> woa. no
<ikey> thats wrong :P
<zyga-suse> ikey: this is specifically for some bleeding edge observing/monitoring tools
<ikey> so how do I turn off all kernel related functionality in snapd?
<zyga-suse> ikey: that's not wrong, that's a permission that is controlled by snapd
<ikey> believe me snapd isnt going to be able to deal with solus kernels
<ikey> hell GRUB barely can
<zyga-suse> ikey: this is all controlled by interfaces, unsafe interfaces are not allowed unless there's an assertion saying that a given snap from a given developer is trusted to do something specific
<zyga-suse> ikey: e.g. we allow docker and lxd to do a lot of stuff to function
<ikey> yeah i want to disable this at the distribution level
<zyga-suse> ikey: because no meaningful way to confine them exists
<ikey> kernel modules on solus should come only from our repositories
<ikey> our kernels dont work like ubuntu kernels
<zyga-suse> ikey: note that snaps won't be able to load those modules
<zyga-suse> ikey: /usr/src is so that they can build them
<zyga-suse> ikey: loading is controlled with seccomp and snapd interfaces
<zyga-suse> ikey: that's fine, not all systems must support all interfaces
<ikey> you'll see what i mean here about kernels: https://hastebin.com/ulureceful.go
<ikey> i could potentially include an empty /usr/src (no owner) directory in the snapd pkg
<ikey> which might mitigate that bit
<zyga-suse> ikey: I think we just want to make that non-mandatory
<zyga-suse> ikey: it's better
<zyga-suse> ikey: and we are doing some of that for base snaps
<ikey> gotcha
<zyga-suse> ikey: where you can create an app that runs on top of really empty filesystem, with except for things like /snap to mount the actual code
<ikey> ah
<ikey> nice
<zyga-suse> ikey: so you could eventually make snaps that use solus as a base
<zyga-suse> ikey: and they still work on fedora/debian/opensuse
<ikey> yeah i can definitely see use cases for that
<zyga-suse> ikey: (mvo is leading that work)
<ikey> fair play :]
<zyga-suse> indeed!
<zyga-suse> ikey: if you are interested in the security aspect I really encourage you to look at interfaces/
<zyga-suse> ikey: all snaps get the same confinement by default
<zyga-suse> ikey: and if you want to change that confinement you need to use one of the interfaces
<zyga-suse> ikey: interfaces are like contracts between two parties
<zyga-suse> ikey: and interfaces are not just permissions
<ikey> right
<zyga-suse> ikey: they come in pairs, a plug and a slot that may be connected
<ikey> sorta like protocols
<ikey> gotcha
<ikey> [Package] Including empty directory: /usr/src
 * ikey cheated
<zyga-suse> ikey: simple things like "I want to create sockets and connect to the network" are so common that the slot is offered by the core snap implicitly
<ikey> right
<zyga-suse> ikey: but slots and plugs are really numerous, e.g. a slot representing a serial port
<zyga-suse> ikey: on the dell gateway device there are a few of those
<zyga-suse> ikey: and if you install a snap that does something over a serial port
<zyga-suse> ikey: and connect it to the one you want (e.g. the "2nd serial port from the left"
<zyga-suse> ikey: only *then* will that snap get permissions to talk to *that* particular device
<zyga-suse> ikey: that's the general idea
<zyga-suse> ikey: interface defines the "way to communicate"
<zyga-suse> ikey: be it a file path, system call, or lots of complex rules
<zyga-suse> ikey: each interface can control many aspects of the system sandbox: seccomp, apparmor, kernel modules, udev tagging, dbus bus permissions, etc
<ikey> gotcha
<ikey> makes sense
<zyga-suse> ikey: interfaces are merged into snapd and audited for secuirty
<zyga-suse> ikey: snaps can use powerful interfaces after having an assertion that say we trust them to do this
<ikey> aye
<zyga-suse> ikey: "powerful" interfaces are those that may break out of confinement (e.g. docker) or those that may expose user data or other privacy aspects
<zyga-suse> that's about the rough idea
<ikey> ok well progress
<zyga-suse> ikey: if you have any security questions I'd love to know :-)
<ikey> no library issues
<zyga-suse> \o/
<ikey> No schema files found: doing nothing.
<ikey> [1]    2094 invalid system call  snap run duckmarines
<zyga-suse> ikey: that syscall is worrying
<zyga-suse> can you look at system logs and see if you see any audit messageS?
<zyga-suse> (unless audit is off on solus)
<ikey> audit is off because systemd broke it
<zyga-suse> hmm?
<ikey> you'd gain a 50gb ring buffer in a matter of minutes
<ikey> they got into a fight
<zyga-suse> do you see _anything_ in the logs when that message is printed
<zyga-suse> specifically, which system call it is
<ikey> nothing related now
<zyga-suse> as a cheap wokraround you can disable seccomp
<zyga-suse> --without-seccomp to configiure
<zyga-suse> *configure
<ikey> yeah but that seems nasty :p
<zyga-suse> indeed
<ikey> ill see if its kernel specific and try the LTS 4.9
<zyga-suse> ikey: my gut feeling says it's related to socket
<zyga-suse> 99% of our issues are there
<zyga-suse> mybe it's a 32bit app running in a 64bit system
<zyga-suse> also check libseccomp version
<zyga-suse> we fixed some bugs there and maybe you are still affected
<ikey> Name                : libseccomp, version: 2.3.2, release: 4
 * ikey sees https://github.com/seccomp/libseccomp/commit/73d83e45efbe8c31067c97155162f17ca51b7435
<zyga-suse> is that in your version?
<ikey> nay
<zyga-suse> aha
<ikey> so im gonna take it to git
<zyga-suse> may be it :)
<zyga-suse> yeah, we're all pushing the edges here
<ikey> *unfortunately* you guys forcibly statically link libseccomp :P
<zyga-suse> working on snapd over last year we found so many interesting kernel bugs
<zyga-suse> ikey: that's a workaround that I want to fix after 2.27
<zyga-suse> it's all complex, nothing is perfect
<zyga-suse> we really want to statically link it in one specific case
<zyga-suse> I'll flipt the workaround
<zyga-suse> you can link it dynamically
<ikey> s'ok i can just rebuild :p
<mwhudson> zyga-suse, mvo: EOD-ing now, hopefully some action tomorrow!
<zyga-suse> mwhudson: thank you, enjoy your evening!
<zyga-suse> ikey: and if you have initial patches for solus please start sending them
<mup> PR snapd#3707 opened: interfaces: convert io_ports_control to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3707>
 * ikey sighs at libseccomp abuse of configure.ac
<ikey> [1]    1730 invalid system call  snap run duckmarines
<ikey> poo.
<zyga-suse> I think you have to find the number somehow
<zyga-suse> is that still from snap-confine or from the suckmarines binary alreday?
<ikey> idk, from "snap run duckmarines"
<ikey> also, this is new:
<ikey> error: cannot install "brackets": classic confinement is not yet supported on
<ikey>        your distribution
<zyga-suse> ikey: do you have /snap?
<zyga-suse> ikey: classic confinement relies on this to exist
<ikey> no im using /var/lib/snapd/snap
<zyga-suse> ikey: there's a patch from mvo that makes that an actual check, not a hard-coded list
<zyga-suse> then no classic confinement :/
 * ikey patches it.
<ikey> or are they all built that way?
<zyga-suse> patches it how?
<ikey> for /snap/
<zyga-suse> they *require* /snap
<ikey> ew
<ikey> k.
<zyga-suse> because classic confinement doesn't use mount namespaces and other goodies
<zyga-suse> so it has no other way to say "this is something you can hard-code in your binaries"
<ikey> so then classic confinement snaps (like - a whole bunch of them) wont work on most distros?
<ikey> because they're using /var/lib/snapd/snap?
<ikey> sod that
 * ikey switches to /snap
<ikey> im not *that* torn up about the FHS
<zyga-suse> ikey: so far they don't work on fedora and arch but I'm not sure if arch will keep it that way
<zyga-suse> fedora is very political about that, but I respect their decision
<zyga-suse> ikey: with a patch proposed by mvo a symlink from /snap to /var/lib/snapd/snap is enough
<zyga-suse> ikey: note that you need to patch both snapd and re-configure snap-confine
<zyga-suse> ikey: when you make this decision
<ikey> sure but at that point you have /snap anyway
<ikey> so might as well use it
<zyga-suse> ikey: yes
<ikey> symlink or not
<zyga-suse> I'd love to standardize /snap as a optional FHS feature one day
<zyga-suse> ikey: (you want to see dirs/dirs.go for the snapd side)
<zyga-suse> ikey: I think /snap is default though, not sure what you changed already
<ikey> changed dirs.go
<ikey> ill change it back
<ikey> ok so im back to having classic "work"
<ikey> im gonna have to bite the bullet probably and package up libselinux and provide the invalid ubuntu-named gtk-update-icon-cache-3.0
<ikey> and that should "fix" the vast majority of classic snaps
<zyga-suse> thank you!
<ikey> and we'll use /snap too
<zyga-suse> we should also do better checks on classic confinement snaps
<zyga-suse> to figure out how to make that a bound problem
<zyga-suse> not a "whack-a-mole"
<ikey> aye
<zyga-suse> ikey, sergiusens: hacks on the build tool, snapcraft
<ikey> ah ok
<zyga-suse> well, the meta-build swiss-army-knife
<ikey> so what you could do is effectively an ABI report on the root and discover missing bits
<zyga-suse> ikey: yeah, I think he is partially doing that today, not sure if at symbol level
<ikey> so i wrote a tool while i was at intel to do simple abi reports: https://github.com/clearlinux/abireport
<zyga-suse> oh, neat
<zyga-suse> sergiusens: ^^ you want to see that
<ikey> so in solus it looks like this:
<ikey> https://dev.solus-project.com/source/libseccomp/browse/master/abi_symbols
<ikey> https://dev.solus-project.com/source/libseccomp/browse/master/abi_used_libs
<zyga-suse> neat
<zyga-suse> I think we can learn from that
<ikey> but i figured you could steal the core of abireport (Apache-2.0) to create a new kind of ABI tracker
<ikey> that way you can raise warnings when there are missing providers for a used symbol
<zyga-suse> yeah, I'm sure we can improve a lot in the tooling used so far;
<zyga-suse> all the new-kind-of-apps projects are a huge community learning exercise
<zyga-suse> and collective pushing-the-boundary work
<ikey> fwiw i found it quite amusing when i saw the initial snap format
<ikey> given how close it is the solus format
<zyga-suse> yeah?
<ikey> https://dev.solus-project.com/source/libseccomp/browse/master/package.yml
<zyga-suse> btw, I'm not familiar with solus packages
<zyga-suse> can you tell me more about them
<ikey> that there is the build file for libseccomp
<zyga-suse> ha
<zyga-suse> interesting
<ikey> we focus on automation and correctness
<zyga-suse> did you see snapcraft.yaml?
<zyga-suse> the one thing I love snapcraft did
<mvo> ikey: nice, this looks way better than the spec files
<zyga-suse> is to separate parts
<ikey> so that actually splits into libseccomp and libseccomp-devel
<ikey> (and libseccomp-dbginfo)
<zyga-suse> so that you can have one snap with two elements inside
<zyga-suse> one, say, written in C with typical build-install code
<ikey> if you add emul32: yes you'll get libseccomp-32bit and libseccomp-32bit-dbginfo and libseccomp-32bit-devel
<zyga-suse> and one written in something totally different, say python,
<zyga-suse> and the logic is per-part
<zyga-suse> so things compose more easily
<ikey> yeah units is nice to have
<ikey> the package.yml has some tricks up its sleeve like patterns
<ikey> which dynamically constructs a subpackage based on a path math
<zyga-suse> ikey: did you see http://build.snapcraft.io/ ?
<ikey> s/mat/match/
<ikey> failsed.
<ikey> yeah its pretty
<ikey> vs https://build.solus-project.com/
<ikey> xD
<zyga-suse> ikey: nice, I wrote something like that for debian a while back but it was not well received
<ikey> yeaah Debian *enjoys* having hard packaging
<ikey> very extreme example: https://dev.solus-project.com/source/libreoffice/browse/master/package.yml
<ikey> id sooner do that than debian/control and debian/*.install ...
<ikey> :p
<ikey> (the format also supports profile guided optimisation and test suites fwiw)
<zyga-suse> https://pypi.python.org/pypi/dh_splitpackage/0.2.3
<zyga-suse> curiously the links to launchpad are dead
<ikey> "without pulling your hair out" lol
<zyga-suse> but the tarball is there
<ikey> personally i find the linux world focuses too much on packages and package managers and superiority of these glorified tarballs (giftwraped, I guess)
<ikey> i like to focus on features, scalability, delivery, cadence..
<zyga-suse> ah
<zyga-suse> found it
<zyga-suse> http://bazaar.launchpad.net/~zyga/dh-splitpackage/trunk/view/head:/debian/splitpackage
<zyga-suse> _ vs -
<zyga-suse> yes, I agree a lot
<ikey> oh cute yaml map
<zyga-suse> not quite yaml but yeah
<ikey> yamlish
<zyga-suse> wow, I even wrote a man page
<zyga-suse> http://bazaar.launchpad.net/~zyga/dh-splitpackage/trunk/view/head:/dh_splitpackage.1
<ikey> check you being all dedicated
<ikey> lol
<ikey> oh dude you legit *wrote* a manpage
<zyga-suse> _yes_ that's what I meant
<zyga-suse> hand made
<zyga-suse> yes, I was trying to help
<zyga-suse> (then got ranty responses and lost interest)
<ikey> use ronn
<ikey> convert markdown to manpage :]
<zyga-suse> nice! I was using rst2man later on
<zyga-suse> but markdown is nicer
<ikey> so i can do like https://github.com/solus-project/ypkg/blob/master/man/package.yml.5.md and have it generate to https://github.com/solus-project/ypkg/blob/master/man/package.yml.5
<ikey> ah rst2man is pretty sweet yea
<zyga-suse> heh
<zyga-suse> reading my own man page I still think dh_splitpackage is a few times better than anything else currently in debian
<zyga-suse> well
<zyga-suse> thinking about what you said
<zyga-suse> inclusion patterns could even be included from distro-wide global
<ikey> yeah
<zyga-suse> so there would be less repetition
<zyga-suse> well :)
<ikey> so you set distro policy from the outset
<zyga-suse> I like how snaps don't have that problem
<zyga-suse> yep
<ikey> but the key is to allow extending the pattern
<zyga-suse> snaps are not perfect
<zyga-suse> but at least we let people make and ship apps without reading holy books of packaging
<ikey> so you can see the default solus patterning here: https://github.com/solus-project/ypkg/blob/master/ypkg2/packages.py#L141
<ikey> and in almost all cases it does the right thing â¢
<zyga-suse> nice
<zyga-suse> yep
<ikey> until cmake is a dick and decides to use /usr/lib
<ikey> for both 32-bit and 64-bit
<zyga-suse> well
<ikey> thats cmake for ya.
<ikey> lol
<zyga-suse> linux distros are a dick
<zyga-suse> we love to diverge
<ikey> true
<ikey> well tbf you all went down the multiarch route :P
<ikey> i wanted pure 64bit
<ikey> but nope, steam, skype, wine ....
<zyga-suse> multiarch is great for arm cross compiling (and not just arm)
<zyga-suse> though TBH fat binaries would have been better
<ikey> yeah
<zyga-suse> well :)
<ikey> well, i got the whole "gah why you no use multiarch" thing a while back
<zyga-suse> it's good to find others that share one's view
<ikey> and its like, well, solus is only 64-bit native
<ikey> so it makes not much sense :p
<zyga-suse> I think multiarch is more than that
<ikey> so instead we explicitly have lib64 and lib32
<zyga-suse> 32/64 biarch is easier
<ikey> and we split packages based on that
<zyga-suse> multiarch is is a nice general concept
<ikey> i.e. automatic -32bit -32bit-dbginfo -32bit-devel
<zyga-suse> though again, fat binaries are just better still
<zyga-suse> because it doesn't have this problem of where-is-$foo
<ikey> dont think we'll ever "win" all the time we focus on vanilla ELF
<zyga-suse> and even executables are >1 arch
<zyga-suse> heh
<zyga-suse> yes but note one thing:
<zyga-suse> in "linux" we often "specify" things in a text file standing on plain apache somewhere
<zyga-suse> and now it's the holly spec
<ikey> we also need to lose this fixation on mutux provider names in the filesystem
<ikey> "i am /usr/lib/someLIB"
 * ikey shoots nvidia
<zyga-suse> so elf spec could be extended arbitrarily if people agree
<ikey> yeah
<zyga-suse> ok, less rantin
<ikey> lol
<zyga-suse> I need to debug this test failure :)
<ikey> yeah i should likely sort out apparmor in our 4.12
<zyga-suse> and move on to update arch packaging for the release
<zyga-suse> (no-more-patches, woot :)
<ikey> noice
<zyga-suse> 4.13 is better
<ikey> 4.13 is also unstable
<zyga-suse> ubuntu still has many patches that are not upstream and 4.13 will have them
<zyga-suse> *hopefully all*
<ikey> we offer "-lts" and "-current" in solus
<zyga-suse> if you want to enable this LSM you want to take the few that didn't make it in 4.12
<ikey> -lts = gkh's branch
<zyga-suse> aha
<zyga-suse> -lts-apparmor would be nice :)
<ikey> and -current = mostly-stableish
<zyga-suse> for snapd at least, that would give you full confinement
<ikey> i.e. not rc and not mainline
<zyga-suse> those are just in security/apparmor
<ikey> well im gonna backport the apparmor stuff ofr our linux-current
<zyga-suse> and you could perhaps even cherry pick those that land upstream
<ikey> because having lsm specific kernels would seem silly
<zyga-suse> aha, sounds good
<zyga-suse> I can point you to the tree that has those
<ikey> would love em
<zyga-suse> jjohansen1: ^
<ikey> i know 4.12 will be significantly easier to do than the 4.9
<zyga-suse> ikey, jjohansen1 is working on upstreaming all of the apparmor changes
<ikey> v nice
<zyga-suse> yes :)
<ikey> and ideally i want like-for-like confinement between solus and ubuntu
<zyga-suse> ikey: since they are so self contained it should be easy to get a version for nearly any kernel that's not 3.x I heard
<ikey> so people get the "full" snap experience
<zyga-suse> *yes*
<ikey> not "hm but my distro said no"
<zyga-suse> thank you for caring about that!
<ikey> eh its for the users - dont wanna screw em over
<zyga-suse> snapd can tell you what it thinks about confinement via "snap debug"
<zyga-suse> (I forgot the sub-command)
<zyga-suse> but this is in 2.27 only
<zyga-suse> so wait for the tarball for that :)
<ikey> lolk
<zyga-suse> it looks at the kernel securityfs and checks if all the features are on
<ikey> ah
<ikey> ok thats handy
<zyga-suse> ok, I'll get back to bugfixing
<zyga-suse> please ping me if you find something odd to investigate
<zyga-suse> one thing that *is* going to suck initially is opengl support
<zyga-suse> that's a few months away from being sane
<zyga-suse> current approach is a stop-gap
<ikey> yeah
<zyga-suse> (for ! FOSS drivers)
<ikey> i might use the nvidia-arch option and see if that works
<zyga-suse> intel should be ok though it could be better supported in snapd as well
<ikey> its *similar* to ours (but we symlinks it)
<zyga-suse> I'd rather not, it's a gross hack
<zyga-suse> mixes userspace with snaps
<ikey> /usr/lib64/libGL.so.1: symbolic link to /usr/lib64/glx-provider/nvidia/libGL.so.384.59
<zyga-suse> some of the common extension snap work will allow us to do this
<ikey> bit messy and in time i think ill replace that with ld.so.conf trickery
<zyga-suse> (e.g. theme snaps will lead the way)
<ikey> yeah theme snaps..
<ikey> people dislike lack of integration :p
<zyga-suse> those are 1st priority for this cycle
<zyga-suse> portal support, themes and a few other integration improvements
<ikey> (especially now flatpak has them :P)
<zyga-suse> yep :)
<zyga-suse> that too :D
<zyga-suse> I think our approach will be similar actually
 * zyga-suse would love to have alexander here to talk details
<ikey> heh
<ikey> right well i need to go make myself look half human for the rest of the day
<ikey> bbiab
<mup> PR snapd#3707 closed: interfaces: convert io_ports_control to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3707>
<mup> PR snapd#3708 opened: interfaces: convert two hardware_random interfaces to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3708>
<ikey> zyga-suse, got a strace for running duckmarines: https://hastebin.com/akeviquqoc.erl if you wanna check later
<zyga-suse> aha
<zyga-suse> interesting
<zyga-suse> so this is socket using AF_NETLINK
<zyga-suse> we have netling mediation in the tree now
 * zyga-suse looks
<zyga-suse> this would be under netlink-observe I think
<zyga-suse> ok two more things
<zyga-suse> what does "snap version" say?
<ikey> snap    2.26.14+git1302.gd1e575152.dirty
<ikey> snapd   2.26.14+git1302.gd1e575152.dirty
<zyga-suse> and did you install this snap before you got other parts in place, perhaps the security profiles are out of date
<zyga-suse> hmm hmm
<zyga-suse> can you look at /var/lib/snapd/seccomp/
<ikey> only has bpf
<zyga-suse> and look for the human-readable profile for this app (seccomp profiles are per-app)
<zyga-suse> and if you can pastebin the plain text one
<zyga-suse> (those are compiled with snap-seccomp btw)
<ikey> https://hastebin.com/aqizajecat.pl
<ikey> soo
<ikey> looks like AF_NETLINK is needed and not whitelisted
<ikey> or am i reading this wrong..
<zyga-suse> socket AF_NETLINK - NETLINK_ROUTE
<zyga-suse> aah
<zyga-suse> it wants a different type
<zyga-suse> curious
<ikey> yeah mines off chasing NETLINK_KOBJECT_UEVENT
<zyga-suse> yes
<zyga-suse> one sec
<zyga-suse> can you check which interfaces are conneccted?
<zyga-suse> this one should be granted by pulseaudio interface
<ikey> https://hastebin.com/cuqawagitu.rb
<zyga-suse> oookay
<zyga-suse> let me look
<zyga-suse> very curious
<zyga-suse> ah, my bad
<zyga-suse> pulseaudio doesn't grant that for plugs
<zyga-suse> so .. still a mystery
<ikey> lol
 * sergiusens wonders when we will start seeing zyga-solus
<ikey> post-solus-release :p
<zyga-suse> yes, likely
<zyga-suse> nothing like hands-on
<Son_Goku> morning all
<zyga-suse> ikey: which revision of that snap are you on?
<zyga-suse> I'm on 9
<ikey> also 9
<zyga-suse> ok, so I need to boot ubuntu to check
<ikey> on ubuntu isn apparmor going to mediate the remaining network calls?
<zyga-suse> but my working theory is that you kit a seccomp kill because the app is normally not even going to try something after getting an apparmor denial
<zyga-suse> right
<zyga-suse> this will fix itself when seccomp can return errors as well
<ikey> heh
<zyga-suse> this work is AFAIK done upstream now)
<zyga-suse> or when you will get apparmor
<zyga-suse> not sure if I'm right though
<zyga-suse> ikey: one suggestion
<zyga-suse> can you refresh that snap with --devmode
<ikey> sure
<zyga-suse> this will put seccomp into no-op mode
<zyga-suse> and it _should_ at least show that it works
 * zyga-suse looks at his profiles on suse
<zyga-suse> ah, still on 2.25 here so no good comparison
<ikey> ok so its definitely trying to start
<ikey> libGL error: No matching fbConfigs or visuals found
<ikey> libGL error: failed to load driver: swrast
<ikey> this is fine
<ikey> it cant find my nvidia
 * ikey expected as much
<ikey> but its gotten along a lot further
<zyga-suse> the lethal seccomp is a workaround for lack of a kernel feature where we log stuff _and_ we don't kill
<zyga-suse> did you enable any of the nvidia hacks/workarounds?
<zyga-suse> (in snap-confine)
<ikey> nah ill try the arch nvidia one and see if that works at all
<zyga-suse> ok
<zyga-suse> not sure if it will but let's see
<zyga-suse> sorry about that, nvidia support is really hit-and-miss
<ikey> yeah im used to that dw
<zyga-suse> I would love to know how that works on an intel box
<zyga-suse> mvo: does this make any sense to you? https://travis-ci.org/snapcore/snapd/builds/262982604?utm_source=github_status&utm_medium=notification
 * zyga-suse notices ogra's huge gadget PR
<ogra_> zyga-suse, same as the pi one just adjusted confiigs for pi2
<zyga-suse> ikey: if you are familiar with the nvidia driver I could use some input
<zyga-suse> yep
<ogra_> *same as the pi3
<ikey> cannot mount tmpfs at /tmp/snap.rootfs_JHOwxl/var/lib/snapd/lib/gl: No such file or directory
<zyga-suse> ikey: on how I want to make that work in snaps
 * ikey blows a rasberry at confinement
<zyga-suse> you need an empty directory there
<ogra_> :)
<zyga-suse> in /var/lib/snapd/lib/gl
<ikey> oh dude
<ikey> game works
<ikey> i mean the music is banging too
<zyga-suse> wooooot
<zyga-suse>  :D
<zyga-suse> hahaha
<zyga-suse> that's so great
<zyga-suse> pics or it didn't happen :D
<zyga-suse> better yet
<zyga-suse> tweet a pic
 * ikey doesn't control the solus twitter anymore :p
<ikey> https://ibin.co/3WOU2Mq91dSg.png
<zyga-suse> wat?
<zyga-suse> who does?
<ikey> josh does
<ikey> he does social thingies
<ikey> i control the G+
<zyga-suse> ohhh, I'd love to see those bash prompts for git integration
<ikey> and most tweets are reposts of that
<ogra_> post it there then !
<ikey> lol
<ikey> s/bash/zsh/
<ikey> :p
<zyga-suse> (things you learn from random images :D
<zyga-suse> aha
<zyga-suse> you may be interested in *very* cool tab completion
<ikey> fwiw classic snap last night: https://plus.google.com/+Solus-Project/posts/BN5p1arv3Fs
<zyga-suse> snapd can do tab completion for snaps inside their confinement
<zyga-suse> and we probably miss something for zsh intergration
<zyga-suse> Chipaca can tell you all about this
<ogra_> a lot i think
<ikey> aye
<zyga-suse> so you could tab-tab a command from a snap
<zyga-suse> and the completer runs confined
<ikey> nice
<ikey> alright so it looks like the remaining "main ticket item" really now is to chuck apparmor into the kernel
<ikey> and then see if that fixes !devmode
<zyga-suse> yep
<ikey> (gonna need it anyway)
<zyga-suse> and please send your patches back
<zyga-suse> I think we can do a 2.27.1 after we collect patches from distributions
<ikey> yeah will do
<zyga-suse> I may need one for opensuse apparently
<zyga-suse> at least to fix this damn unit test
<ikey> the patch is actually really basic right now
<zyga-suse> I bet it is bleeding edge golang in tumbleweed
<ikey> https://hastebin.com/jotepamoki.bash - but i dont wanna send it in yet due to the disabling of apparmor
<zyga-suse> yeah, I hoped it would be easy but I just want them merged :)
<ikey> and you might not like mkversion change :P
<zyga-suse> super nice
<zyga-suse> yep
<zyga-suse> read it
<zyga-suse> I think it's fine
<ikey> ypkg sets $version as the package.yml key
<zyga-suse> you can just call mkversion with an argument
<ikey> and it means autogen then just works
<zyga-suse> but no strong opinions
<ikey> we use %autogen macro
<ikey> which takes arguments too
<ikey> so in autogen.sh i modified solus) to take $@
<ikey> meaning that autogen.sh/mkversion.sh/configure all play nicely in a single chain
<zyga-suse> ahh, I see
<zyga-suse> cool :)
<ikey> cheers for all the help so far, very much appreciated
<zyga-suse> pleasure :)
 * ogra_ sighs about the flashplugin update he gets ... 
<ogra_> thats the only package i'd really love to see as classic snap one day :)
<pstolowski> pedronis, hey, re your comment about having a "run-hook[refresh]" helper, are you suggesting a test-side only helper, or making "run-hook" tasks have different kinds?
<pedronis> pstolowski: only in the tests
<pstolowski> pedronis, ok good
<pedronis> make the helper that lists kinds etc
<pedronis> produce that
<pstolowski> pedronis, because the latter would be problematic
<pedronis> *helpers
<pedronis> pstolowski: understood
<pstolowski> thanks
<mup> PR snapcraft#1474 opened: kbuild plugin: use ARCH from environment if set <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1474>
<kalikiana> ondra: ^^
<ondra> kalikiana do you have build of snapcraft with that change,so I can test it?
<ondra> kalikiana not sure if this would work, as we are build on arm64 and kernel is arm64, but we need arch arm
<Chipaca> i'm off to lunch
<mvo> sergiusens: so "app-constrains" instead of "wrappers"? happy to change that
<abeato> mvo, hey, is current core edge really built from master or is it a re-spin of 2.27?
<mvo> abeato: today its 2.27 sorry for that, when a release is immanent edge is sometimes not really edge
<mvo> abeato: I expect things to be normal by this evening
<zyga-suse> edge is not what it seems to be on days like that
<abeato> mvo, ack, nw
<abeato> yeah, I suspected that... :)
<mvo> cachio: hey, good morning! any last minute concerns aobut 2.27, otherwise I'm going to upload 2.27-final in a wee bit :)
<sergiusens> mvo: well I am thinking, you didn't start a forum post to discuss this ;-)
<ikey> zyga-suse, should i be setting DEFAULT_SECURITY_APPARMOR=y ?
<ikey> right now its DEFAULT_SECURITY_DAC
<mvo> sergiusens: doing that as we speak
<sergiusens> mvo: for example, `no-environment` might be the better keyword, or when we kill our wrappers and just shove stuff in `env`, would that still be ok for your use case?
<zyga-suse> ikey: mmmmm, I don't know, tyhicks or jdstrand can say
<zyga-suse> (please help out)
<mvo> sergiusens: absolutely, my use case is that I don't want #!/bin/sh (as my base snap does not have it ;)
<zyga-suse> ikey: ^ mvo works on a test base snap that ships *nothing* :-) so apps execute in a very very empty place
<ikey> ah cool
<sergiusens> mvo: right, then `no-environment` might be the better fit as the wrapper is just an implementation detail
<mvo> sergiusens: sure, works for me, I create a forum topic just to make sure that gustavo is aware and can weight in
<sergiusens> mvo: would be nice to see `command`s of the style of the ones you see `snapcraft.yaml` allowed in `snap.yaml` and we are golden :-)
<sergiusens> mvo: perfect
<sergiusens> I'll add my comments
<zyga-suse> sergiusens: what is the difference today?
<zyga-suse> sergiusens: that they run via shell?
<mvo> sergiusens: created and mentioned you
<sergiusens> zyga-suse: in snapcraft you can do: `env PATH=$SNAP/bin my-command $SOME_VAR` in snap.yaml you cannot specify variables
<zyga-suse> sergiusens: right
<zyga-suse> sergiusens: but you can specify ... environment
<sergiusens> and I know jdstrand explained the why's to me, but I just wish it were allowed
<zyga-suse> what you said above needs to be handled by /bin/sh
<zyga-suse> aha
<sergiusens> zyga-suse: you can, but some commands require something like this: `command: my-command --work-dir $SNAP_USER_DATA`
<zyga-suse> arguable we _could_ expand $SNAP_ variables
<zyga-suse> arguably*
<sergiusens> fwiw, the wrappers are mvo's invention ;-)
<mvo> sergiusens: really?
 * mvo can't remember
<zyga-suse> whaat? :-D
<zyga-suse> I won't say who complains about wrappers the most :D
<mvo> lol
<mvo> I always thought it was the other mike
 * ikey & compiling linux-current...
<sergiusens> mvo: ah mterry  in the middle of a bunch of your commits `git diff ac2a535d52a04d9ec848026d52c19d1471bbbe39^ ac2a535d52a04d9ec848026d52c19d1471bbbe39`
<sergiusens> you made the sell for it on the Snappy Clinics though
<mvo> sergiusens: heh, thats quite possible
<mvo> sergiusens: the bad old days :)
<sergiusens> zyga-suse: mvo the only reason we didn't move to `env` yet is due to the way environment was originally implemented, and that is mvo's invention ;-) We need env stacking to make it easy and dictionaries don't make that easy
<zyga-suse> sergiusens: do you know about the merge-keys feature in yaml?
<zyga-suse> (not sure if related but I was surprised today)
<zyga-suse> http://yaml.org/type/merge.html
<sergiusens> zyga-suse: yes
<sergiusens> it makes the yaml look horrible, but some people like it ;-)
<mvo> sergiusens: I'm still not so sure if it was my invention but my memory is sometimes flaky so I will not fight over it ;)
<ikey> Does apparmor require CONFIG_AUDITSYSCALL ?
<ikey> (and thus, snap)
 * zyga-suse doesn't know
<zyga-suse> again that would be something that jdstrand or jjohansen1 can answer
<zyga-suse> ikey: I know this is not a good answer but you could cross-check with what the ubuntu config is
<ikey> cuz CONFIG_AUDITSYSCALL is notoriously slow
 * zyga-suse is melting here
<ikey> anyone able to zgrep CONFIG_AUDITSYSCALL /proc/config.gz..?
<ikey> (on buntu)
 * zyga-suse boots
<zyga-suse> one sec
<ikey> ta
<ikey> i know consolekit used to require it - but like nobody uses that now
<zyga-ubuntu> ikey: zyga@fyke:~$ cat /boot/config-4.10.0-30-generic  | pastebinit
<zyga-ubuntu> http://paste.ubuntu.com/25283420/
<mup> PR snapcraft#1473 closed: catkin plugin: rosinstall-files is a pull property <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1473>
<ikey> ouch you have it on
<mup> PR snapd#3708 closed: interfaces: convert two hardware_random interfaces to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3708>
<zyga-suse> pedronis: around?
<pedronis> zyga-suse: yes
<zyga-suse> https://paste.gnome.org/pqyailbdz
<zyga-suse> I changed the prune function to log why things happen
<zyga-suse> it seems change 1 should *not* be pruned
<zyga-suse> (according to the test)
<zyga-suse> my mind has melted today so I'm not sure if this is just still racy
<zyga-suse> or is something else at play
<zyga-suse> or maybe some scheduling or golang parts are different here
<pedronis> sorry, I cannot really context switch to this atm
<zyga-suse> OK
 * zyga-suse keeps digging
<ikey> there we go, officially snowing in hell
<ikey> https://dev.solus-project.com/R3571:19e256059de04cae4f98d22f71ec0eb36ac02e13
<zyga-ubuntu> zyga@fyke:~$ cat /boot/config-4.10.0-30-generic  | pastebinit
<zyga-ubuntu> http://paste.ubuntu.com/25283420/
<zyga-ubuntu> er, sorry
<zyga-ubuntu> wooot :)
<ikey> xD
<zyga-ubuntu> may I tweet about this :)
<zyga-ubuntu> or would you rather
<ikey> nah go ahead
<kalikiana> ondra: You don't need to build it, you can run it from source. Although I could make you a snap if you rather wait for it to build... I tested with this https://github.com/kubiko/dragonboard-gadget/pull/1
<mup> PR kubiko/dragonboard-gadget#1: Use upstream kbuild plugin <Created by kalikiana> <https://github.com/kubiko/dragonboard-gadget/pull/1>
<ikey> can link direct to the commit too as it shows the canonical.com patchwork
<ikey> yknow, brownie points n all
<ikey> i have a suspicion this audit change will fix some old bugs and expose some new ones, but we'll see once i have the nv ko rebuilds in..
<ondra> kalikiana now I'm even more curious how you determine to use arm
<ondra> kalikiana and cross compiling also working?
<zyga-ubuntu> ikey: this will be very interesting indeed, I wonder what results you'll get
<kalikiana> ondra: I don't. See the PR description :-)
<kalikiana> It works the same way as CROSS_COMPILE now
<ondra> kalikiana I'm checking your changes to dragonboard, and this looks so clean, just wondering how it works that it knows to use arm ARCH
<ondra> kalikiana have you  tested native build on arm64?
<ondra> kalikiana so when you cross compile, do you tell if to cross compile for arm64?
<kalikiana> ondra: "ARCH=arm snapcraft --target-arch=arm64" is what I tested
<ondra> kalikiana aha :)
<ogra_> crazy stuff
<ondra> kalikiana OK that would probably fail then when build in launchpad
<ondra> kalikiana as you can't really defined there env variable, unless I don't know about it
<ogra_> why would you cross build in lp ?
<ondra> ogra_ there you native build
<ogra_> right
<ondra> ogra_ but that means you gonna end up with arm64 ARCH
<ondra> ogra_ which will fail
<ogra_> anything wrong with that ?
<ogra_> why ?
<ondra> ogra_ you have so bad memory :D
<ogra_> it is only uboot
<kalikiana> ondra: So Launchpad is native? Or Cross-compiling?
<kalikiana> I assumed native
<ogra_> yeah, lp is native
<ondra> ogra_ remember, uboot for dragonboard fails unless you use arm64 toolchain, but defined arm ARCH
<ogra_> but i remember there was this odd mkimage thing
<ondra> kalikiana LP is native
<ondra> ogra_ I don't know is this is specific to dragonboard or to arm64
<ondra> ogra_ but for dragonboard I had to use this crazy combo to make it build
<ogra_> yeah, i remember now
<ogra_> though i think the dragonboard still boots fine if you just use armhf ... iirc the prob was that you need to use this mkimage call
<kalikiana> ogra_: it actually won't build because there's no config in arch for it
<ondra> ogra_ but it won't compile
<kalikiana> Although I wonder, can that be fixed?
<ondra> ogra_ only way to build is arm64 toolchain  + arm ARCH
<ondra> and building arm64 architecture on  armhf seems even more broken, let alone it won't build anyway
 * ikey makes a one-of-them-g+ posts
<zyga-ubuntu> ikey: :-)
<zyga-ubuntu> ikey: note that you may still be missing some more specific apparmor patches but I'll wait for a reply from jjohansen1 which is doing this work
<zyga-ubuntu> ikey: I'm sure he can look at your config and tree and say if anything is missing
<ikey> sure
<ikey> ive taken them from your kernel.ubuntu.com backports tree
<zyga-ubuntu> aha, that's good then
<zyga-ubuntu> I *think* all of them are in the xenial tree but xenial uses older kernel and I'm not a real kernel dev
<zyga-ubuntu> so not sure :)
<ikey> ack
<mvo> zyga-suse, zyga-ubuntu, zyga-*: if you type "mount|grep disk" what do you se?
<jdstrand> roadmr: hey, can you sync r896 just whenever
<roadmr> jdstrand: totally
<jdstrand> roadmr: thanks :)
<zyga-ubuntu> mvo: checking
<zyga-ubuntu> mvo: note that I suspect I mounted them by clicking on them
<zyga-ubuntu> mvo: oh wow
<zyga-ubuntu> this is interesting
<zyga-ubuntu> zyga@fyke:~/snapd$ mount | grep disk
<zyga-ubuntu> /var/lib/snapd/snaps/core_2445.snap (deleted) on /media/zyga/disk type squashfs (ro,nosuid,nodev,relatime,uhelper=udisks2)
<zyga-ubuntu> /var/lib/snapd/snaps/core_2462.snap (deleted) on /media/zyga/disk1 type squashfs (ro,nosuid,nodev,relatime,uhelper=udisks2)
<zyga-ubuntu> check this out
<mvo> zyga-ubuntu: aha! and snap list --all ? does it show those?
<zyga-ubuntu> core                            16-2.27            2610  canonical       core
<zyga-ubuntu> core                            16-2.27            2604  canonical       core,disabled
<zyga-ubuntu> core                            16-2.27            2601  canonical       core,disabled
<zyga-ubuntu> Chipaca: btw, snap list --all chokes on broken snaps to the point where it doesn't show *any* snaps
<zyga-ubuntu> mvo: as I said, I was hopping channels
<Chipaca> zyga-ubuntu: what sort of broken snap?
<zyga-ubuntu> Chipaca: I had a few snaps I 'snap try'ied
<mvo> zyga-ubuntu: interessting
<zyga-ubuntu> Chipaca: to check specific encyptfs behavior
<mvo> zyga-ubuntu: so these are really not on disk anymore?
<zyga-ubuntu> (those snaps were on a fs my user cannot access)
<zyga-ubuntu> mvo: yes
<mvo> zyga-ubuntu: context is core not try :)
<zyga-ubuntu> mm?
<zyga-ubuntu> mvo, Chipaca: those broken snaps were there for months
<zyga-ubuntu> and I never noticed any problem
<zyga-ubuntu> because I wasn't runnin list --all
<Chipaca> zyga-ubuntu: sudo curl -N -0 -s --unix-socket /run/snapd.socket http:/v2/snaps | pastebinit
<zyga-ubuntu> Chipaca: I had to remove them so this will now work
<zyga-ubuntu> zyga@fyke:~/snapd$ snap list --all
<zyga-ubuntu> error: cannot list snaps: cannot list local snaps! cannot find installed snap "test-snapd-overmount" at revision x1
<zyga-ubuntu> your command is still doing stuff
<zyga-ubuntu> timed out
<zyga-ubuntu> Chipaca: I got:
<zyga-ubuntu> BÅÄd poÅÄczenia z serwerem: [Errno socket error] The read operation timed out
<zyga-ubuntu> ran again and got
<zyga-ubuntu> http://paste.ubuntu.com/25283709/
<Chipaca> zyga-ubuntu: ok, get me snapd logs then
<zyga-ubuntu> aaah
<zyga-ubuntu> sie 10 14:43:40 fyke systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
<zyga-ubuntu> mvo: ^ remember this
<zyga-ubuntu> sie 10 14:43:40 fyke systemd[1]: Stopped Snappy daemon.
<zyga-ubuntu> sie 10 14:43:40 fyke systemd[1]: Started Snappy daemon.
<mup> PR snapd#3709 opened: release: snapd 2.27 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3709>
<zyga-ubuntu> we had this before
<zyga-ubuntu> the sd-notify bug
<zyga-ubuntu> right?
<Chipaca> i sometimes agree with those logs: *fyke* systemd
<zyga-ubuntu> snapd restarts periodically
<mvo> zyga-ubuntu: yes, we had this before - where do you see it?
<zyga-ubuntu> on fyke, apparently, on my dev system running
<Chipaca> zyga-ubuntu: what did you have before that? a traceback or anything?
<zyga-ubuntu> snap    2.27~rc9
<zyga-ubuntu> snapd   2.27~rc9
<zyga-ubuntu> Chipaca: nope
<zyga-ubuntu> Chipaca: let me get you the full log
<mvo> zyga-ubuntu: what version of snapd do you have installed as the deb?
<zyga-ubuntu> http://paste.ubuntu.com/25283724/
<zyga-ubuntu> 2.25
<mvo> zyga-ubuntu: so this can happen if you have a snapd deb with "type=notify" in the deb but re-exec runs a version that does not support type=notify. but your case is the other way aroudn afact
<Chipaca> out of curiosity, what's doing all those individual GETs?
<zyga-ubuntu> mvo: I don't have Type=notify in snapd.service
<zyga-ubuntu> Chipaca: not me
<Chipaca> zyga-ubuntu: i suspect gnome-software
<Chipaca> zyga-ubuntu: because of the icons
<zyga-ubuntu> maybe
<mvo> zyga-ubuntu: how often do you see this message?
<zyga-ubuntu> mvo: according to the log I pasted, just a few times now
<zyga-ubuntu> but I did hit the window a moment ago
<zyga-ubuntu> when I was doing the queries for chipaca
<zyga-ubuntu> maybe snapd panicked
<zyga-ubuntu> while I had those broken snaps installed
<zyga-ubuntu> and I ran list --all
<Chipaca> zyga-ubuntu: you'd see the panic in the logs
<ikey>  â î± ufee1dead@ironhide î° ~ î° dmesg|grep -i armor
<ikey> [    0.026751] AppArmor: AppArmor initialized
<ikey> heh
<zyga-ubuntu> ikey: nice :D
<zyga-ubuntu> mvo: out of curiosity, jump between beta and candidate
<zyga-ubuntu> do it a few times and see what happens
<mvo> zyga-ubuntu: will do in a bit, just in the middle of releasing 2.27 :)
 * ogra_ does that multipple times a day ... but only on ubuntu core
<ogra_> -p
 * zyga-ubuntu thinks about lunch
<pstolowski> zyga-ubuntu, thinking about it rarely helps ;)
 * zyga-ubuntu eats stuff :D
<ondra> kalikiana was thinking, without over complicating kbuild plugin, best thing would be if one can define env variable for each part build
<ondra> kalikiana this could be quite handy feature and it'd probably solve lot of additional hacking
<ondra> kalikiana and we could do it way, that whenever we are passing env variables, like for cross compiling, we could preference those defined in snapcract.yaml
 * zyga-ubuntu suspends this laptop to work on one less computer at a time
<zyga-suse> ikey: about your post earlier, I think having a common market and ease-of-deployment *is* a compelling reason for developers to target linux
<zyga-suse> ikey: so indirectly, initiatives like snaps help to achieve that
<ikey> having a shop is all well good provided you put the shop on a busy street and sell things people want
<ikey> zyga-suse,
<ikey> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<ikey> (built it with libapparmor)
<zyga-suse> aaah
<zyga-suse> yeah
<zyga-suse> ok, so now you need to install the apparmor profile for snap-confine
<zyga-suse> it should have been built
<zyga-suse> snap-confine.apparmor
<ikey> ah ok
<ikey> where does he go
<zyga-suse> on debian this goes to /etc/apparmor.d/
<ikey> ew.
<ikey> so much ew.
<zyga-suse> as usr.lib.snapd.snap-confine
<ikey> thats blatant misuse of /etc
<ikey> :P
<zyga-suse> just encode the path in the name
<ikey> yknow im going to send you patches to fix apparmor right?
<ikey> lol
<zyga-suse> well, in theory because this is something you can edit
<ikey> Solus is on a mission to ban use of /etc/
<ikey> yeah ive heard that theory a lot..
<ikey> lol
<zyga-suse> ikey: yes, I saw that, that *is* a good thing
<ikey> ill figure out bzr during next week i think
<zyga-suse> I don't know if apparmor supports stuff like /lib/apparmor.d
<ikey> and work out the stateless approach
<ikey> for now ill use /etc/ and cry later
<zyga-suse> for that I bet you want to work on jdstrand and other apparmor upstreams
<ikey> /etc/apparmor.d/usr.lib64.snapd.snap-confine
<ikey> its there..
<zyga-suse> yep
<mvo> zyga-suse: meh, looks like opensuse in the tests is fragile, e.g. timeout errors
<mvo> zyga-suse: on the download servers
<zyga-suse> make sure the stuff inside matches the path
<ikey> soo i guess the next question is how do i make it go
<ikey> xD
<zyga-suse> ikey: the first few lines show which file is being confined
<zyga-suse> ikey: apparmor_parser -r /path/to/that/file
<zyga-suse> that will load it
<zyga-suse> and you can try running now
 * ikey fixes up apparmor pkg
<ikey> im guessing there is a systemd unit to load this cruft on boot
<zyga-suse> mvo: download servers?
<zyga-suse> ikey: yes, not a systemd unit buy old style script
<zyga-suse> it's a part of userspace apparmor tools
<zyga-suse> (it's convoluted)
<ikey> o
<ikey> [Package] Including empty directory: /var/lib/apparmor
 * ikey sobs into a bucket
<ogra_> "old style" ... tsk ...
<mvo> zyga-suse: yeah, I retrigger and see what happens, I got a timeout from zyper in project prepare for opensuse
<zyga-suse> oh
<zyga-suse> interesting
<zyga-suse> maybe our base image is very old
<zyga-suse> and we get lots of updates
<ikey> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
<ikey> Use --subdomainfs to override.
<ikey> wut
<zyga-suse> did you mount apparmorfs?
<ikey> idk how it works lol
<zyga-suse> in /sys/kernel/security/apparmor
<ikey> should i assume i now need to build systemd with apparmor?
<zyga-suse> ikey: I'd have a look at apparmor packaging in debian and in opensuse
<zyga-suse> ikey: no, it's not mandatory
<ikey> huh ok /sys/kernel/security/apparmor does exist
<zyga-suse> mmm, maybe something else is missing, I'm sorry I don't know that error
<zyga-suse> on tumbleweed I see securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
<ogra_> pedronis, did you want to drop the timestamp checking of the system-user assertion or do i mis-remember that ? (regarding bug 1679739)
<mup> Bug #1679739: System-User Assertions and the system time <Snappy:New> <https://launchpad.net/bugs/1679739>
<mup> PR snapd#3710 opened: many: allow and support serials signed by the 'generic' authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3710>
<ikey> securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
<ikey> tmpfs /dev/shm tmpfs rw 0 0
<ikey> er random 2line paste
<ikey> but yeah, its definitely mounted
<ikey> the failed call is 	    aa_kernel_interface_new(&kernel_interface, features, apparmorfs) == -1) {
<tyhicks> ikey: can you strace apparmor_parser and see if there's a failing syscall inside of aa_kernel_interface_new()?
<ikey> yea poking that now
<zyga-suse> tyhicks: hey :)
<tyhicks> hey zyga-suse :)
<ikey> open("/etc/apparmor.d/usr.lib64.snapd.snap-confine", O_RDONLY|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)
<tyhicks> that's not likely the issue
<tyhicks> can you paste the entire strace somewhere so I can look?
<ikey> https://hastebin.com/fimogokola.erl
<tyhicks> thanks
<tyhicks> what's the full apparmor_parser command that you're using?
<ikey> the one zyga-suse gave me: sudo /sbin/apparmor_parser -f /etc/apparmor.d
<ikey> er
<ikey> with the filename*
<ikey> sudo /sbin/apparmor_parser -f /etc/apparmor.d/usr.lib64.snapd.snap-confine
<ikey> is -f wrong by any chance?
<tyhicks> yes
<tyhicks> -f is wrong
<ikey> xD
<tyhicks> so the failing open() was the issue :)
<ikey> lol yeah
<ikey> so -a or -r ?
<tyhicks> I think you want -r instead of -f
<ikey> ta
<ikey> Could not open 'tunables/global'
<ikey> pfft
 * ikey adds profiles to pkg
<ikey> /usr/lib64/snapd/snap-confine: error while loading shared libraries: libudev.so.1: failed to map segment from shared object
<ikey> xD
 * ikey goes to look at the confine file
<zyga-suse> ikey: aha
<zyga-suse> ikey: you may want to update paths in that file
<ikey> its all multiarched up
<zyga-suse> yep
<zyga-suse> sorry
<zyga-suse> but thank you for leading the way
<ikey> heh
<zyga-suse> I'll gladly take patches to imporve this
<ikey> so we have @{multiarch}
<ikey> is there anything like $LIB from ld?
<ikey> fwiw this kinda demonstrates the sandboxing is working
<ikey> lol
<zyga-suse> some things are variables expanded by apparmor
<zyga-suse> indeed :)
<zyga-suse> but I don't know, I rarely look at the global includes
<ikey> ok
<ikey> @{multiarch}=*-linux-gnu*
<nothal> ikey: No such command!
<ikey> hrm ok
<ikey> ..lol
<ikey> gold
<ikey> cannot create symbolic link /tmp/snap.rootfs_BPPk5I/var/lib/snapd/lib/gl/libEGL.so -> /var/lib/snapd/hostfs/usr/lib64/libEGL.so.1: Permission denied
<zyga-suse> oh
<zyga-suse> that's nvidia arch support
<zyga-suse> since it was never tested under confinement you need to allow that symlink
<ikey> ok how do i do that
<ikey> lol
<ikey> "    /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/ w," mebbe?
<zyga-suse> the synax is like
<jaggz> - Copy snap "meshlab" data (cannot copy "/var/snap/meshlab/4" to "/var/snap/meshlab/4": failed to copy all: "cp: cannot stat '/var/snap/meshlab/4': No such file or directory" (1))
<ikey> needed a * at the end..
<ikey> ok now we make progress:
<ikey> cannot change profile for the next exec call: No such file or directory
<ikey> lol
<jaggz> what's that about?  I'm trying to install a snap from a file
<zyga-suse>  path/to/file w,
<zyga-suse> tyhicks: ^ symlinks?
<zyga-suse> tyhicks: do I rememeber this correctly?
<zyga-suse> jaggz: that's something for Chipaca
<Chipaca> me? :-)
<zyga-suse> ikey: that is /proc/$PID/attr AFAIR
<ikey> open("/proc/24260/attr/exec", O_WRONLY) = 3
<ikey> write(3, "exec snap.duckmarines.duckmarine"..., 33) = -1 ENOENT (No such file or directory)
<zyga-suse> ikey: this is how apparmor profile changes are applied
<zyga-suse> right
<Chipaca> jaggz: but i was just about to say: could you ls -l /var/snap/meshalb for me?
<zyga-suse> aha
<zyga-suse> maybe snap.duckmarines.duckmarine is not a generated profile
<zyga-suse> probably because snapd didn't generate a profile
<tyhicks> zyga-suse: sorry, what specifically about symlinks are you asking? I don't see it in the scrollback
<ikey> hm
<zyga-suse> and probably because you are missing a patch so it determined that apparmor support is incomplete
<zyga-suse> (lots of probably)
<ikey> right
<ikey> snap debug confinement yields partial
<zyga-suse> tyhicks: I forgot the syntax for symlinks in apparmor
<zyga-suse> ikey: so something is missing
<ikey> yeah
<ikey> but i fixed the library issue and libGL write issue
<zyga-suse> ikey: or not compiled in or misisng
<tyhicks> zyga-suse: you have to give permission to the symlink target since that's what apparmor mediates on
<mup> Issue snapcraft#1475 opened: rust plugin recording <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1475>
<zyga-suse> we look at /sys/kernel/security/apparmor/features
<ikey> this bit worked for the arch confinement:
<ikey>     /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/* w,
<zyga-suse> tyhicks: thank you
<ikey> though in truth it should likely be more strict and catch .so* only
<zyga-suse> ikey: this is fine, you need more patches to get snapd to flip from "partial" to "strict"
<ikey> aye
<ikey> so more kernel work
<ikey> well we made great headway
<ikey> to the point that snapd-confine itself is happy through apparmor
<ikey> now it just needs to execute this damn duck marines
<ikey> telling ya, it best be a good game after all this :p
<Chipaca> ikey: http://i.imgur.com/eTic1wS.jpg
<zyga-suse> :D
<jaggz> Chipaca, http://paste.debian.net/980792/
<ikey> Chipaca, lol
<jaggz> that's /var/snap/meshlab
<Chipaca> jaggz: sigh, ok that's strange. How and what were you trying to install, and what version is your snapd?
<jaggz> Chipaca, Trying to install meshlab.  snapd debian package is 2.21.  Meshlab's snap I downloaded from https://uappexplorer.com/snap/ubuntu/meshlab
<jaggz> I also have received, intermittently, snap core errors
<Chipaca> jaggz: why not "snap install meshlab"?
<Chipaca> jaggz: what do the errors say?
<jaggz> hrm.. that says it's already installed
<jaggz> - Setup snap "core" (2601) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": fork/exec /usr/lib/snapd/snap-update-ns: no such file or directory)
<Chipaca> jaggz: the ls output agrees that it's installed
<jaggz> that was from a snap refresh core
<Chipaca> jaggz: ok, "snap version" output please?
<Chipaca> zyga-suse: ^ snap-update-ns error for you
<zyga-suse> Chipaca: aha
<jaggz> running /snap/bin/meshlab sits there.. strace -f shows: [pid 31791] execve("/snap/core/current/usr/bin/snap", ["/snap/bin/meshlab"], [/* 83 vars */] <unfinished ...>
<zyga-suse> jaggz: ok, two questions
<zyga-suse> jaggz: what is snap version
<zyga-suse> jaggz: I understand you are on 2.21 but snapd pulls in updates
<jaggz> ooh.. hold.. can't kill this program..
<zyga-suse> jaggz: so I would expect that to be 2.26.14 actually
<Chipaca> jaggz: you need to kill the strace explicitly (e.g. killall -9 strace)
<jaggz> is it safe to kill -9 the running /snap/bin/meshlab?  (which is a symlink to /usr/bin/snap, as I figure you know)
<Chipaca> jaggz: it should be yes
<Chipaca> jaggz: I don't know what meshlab does :-)
<jaggz> okay.. yeah.. had to -9 the strace itself
<Chipaca> jaggz: can you "snap install hello-world" and see if that works reasonably?
<jaggz> yeah, not an issue with meshlab itself -- it's software that lets you work on 3d point clouds and meshes
<jaggz> btw: snap    2.27~rc4
<jaggz> snapd   2.27~rc4
<zyga-suse> aha
<zyga-suse> ok
<zyga-suse> so far so good
<zyga-suse> ok
<jaggz> snap install hello-world says something about climate change
<jaggz> (kidding.. it's running)
<zyga-suse> sudo snap-discard-ns core
<jaggz> one line.. it's installed
<zyga-suse> er
<ikey> right cheers again all - much appreciated, looking forward to torturing you again tomorrow hopefully for the last time :D
<zyga-suse> sudo /usr/lib/snapd/snap-discard-ns core
<zyga-suse> I think that will fix it for you
<Chipaca> jaggz: now e.g. hello-world.env should work
<zyga-suse> ikey: with pleasure :)
<jaggz> zyga-suse, nice clean.. no output.. returns to prompt.  :)
 * ikey is off to fix his van and have dinner + wine and such niceties
<Chipaca> mmm, dinner
<Chipaca> reminds me i have a train to catch for dinner
<Chipaca> 5 minutes more
<ikey> most people have enough trouble catching a chicken for dinner
<ikey> let alone a train...
 * ikey grins and walks out slowly
<jaggz> Chipaca, it does.  what's hello-world.env do?  just a plain dump of environment to see what's in it?
<Chipaca> ikey: what can i say, i'm feeling peckish
<ikey> :P
<Chipaca> jaggz: yes
<jaggz> ikey, what's wrong with the van?
<ikey|afk> jaggz, battery is stone dead
<jaggz> ikey|afk,
<jaggz> ikey|afk, your fault, or possibly alternator?
<ikey|afk> picked up another one couple days back, â¬80 -_-
<ogra_> ikey|afk, perhaps Chipaca can borrow you his train after dinner ?
<jaggz> well.. if you know how to fix it.. no need to talk  good luck :)
<ikey|afk> partially my fault partially old van that i bought a while back
<ikey|afk> 2005 van
<jaggz> I had to replace my alternator a while ago.. 1994 van :)
<ikey|afk> and its been lined up a couple weeks
<ikey|afk> not starting each day
<ikey|afk> stuck it on the jumps, went fine, cold start, *pfft*
<jaggz> I leave mine for a month at a time or more.. but it's an older one and doesn't have computers sucking away at power all the time.. or whatever cars do nowadays
<jaggz> okay.. so.. meshlab
<mup> Issue snapcraft#1476 opened: foreign arch and sources setup for `build-packages` <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1476>
<mup> Issue snapcraft#1477 opened: multi-arch build packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1477>
<mup> PR snapcraft#1388 closed: beta <Created by snappy-m-o> <Closed by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1388>
<mup> PR snapcraft#1395 closed: [WIP] python plugin: track the python packages installed during build <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1395>
<Chipaca> jaggz: ok, so hello-world works, and with zyga's command you should no longer see the nasty ns-update thing ,so now we just need to figure out why the mesh thing isn't working
<Chipaca> jaggz: as i don't know what it would do if it worked, i can only say maybe you need to connect interfaces to it for something? maybe there are "audit" lines in your syslog to help you figure that one out
<Chipaca> and now i must run
<Chipaca> jaggz: if you get stuck, open a forum topic on this, so we can debug it asynchronously
<jaggz> ikey|afk, in case you ever need help.. ##electronics is a nice broad-topic channel with some really knowledgeable people.
<jaggz> Chipaca, if it works I'll get a window up :)
<jaggz> need to do some searches on it.. it sits there, after some errors.. http://paste.debian.net/980795/
<Chipaca> let me try it
<Chipaca> jaggz: that looks like the snap needs work
<zyga-suse> jaggz: which GPU do you have?
<jaggz> nvidia 970.  a post here says to reinstall the nvidia drivers
<jaggz> I'm in debian, but this is for ubuntu: https://askubuntu.com/questions/451221/how-do-i-install-the-nvidia-driver-for-a-geforce-gt-630/451248#451248
<Chipaca> ah, my game computer has that card, i can try it tonight
<zyga-suse> jaggz: may be missing nvidia support :/
<zyga-suse> sorry
<zyga-suse> missing support in snapd that is
 * ogra_ wonders why GL snaps work just fine on his nvidia desktop 
<ogra_> (never had probs after the very initial issue with the leftover stale dirs from old nvidia driver packages)
<zyga-suse> ogra_: magic and complexity across distros
<ogra_> ah, yeah, non-ubuntu is indeed different
<ogra_> meshlab works fine here btw ... (on an intel based laptop though)
<jaggz> I'm checking out the first errors too -- I jumped to the final one with libGL
<mup> PR snapd#3706 closed: asserts,overlord/devicestate: support predefined assertions that don't establish foundational trust <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3706>
<jaggz> the first being a gtk thing: Gtk-Message: Failed to load module "gail"
<ogra_> the gtk stuff is pretty normal i think
<jaggz> ogra_, what distribution?
<ogra_> ubuntu indeed :)
<ogra_> but that shouldnt matter at alll
<jaggz> yeah.. probably shouldn't.
<ogra_> note that the snap seems to initially create its config on first start
<ogra_> which takes a while
<ogra_> (so be patient)
<jaggz> with external outside packages (like nvidia's), who knows though
<kalikiana> ondra: Maybe we should discuss it in the forum, and see if it makes sense for other plugins as well
<jaggz> ogra_, do you get the gtk errors?
<ondra> kalikiana was thinking same
<ogra_> jaggz, yes, the older versions of the gnome/gtk desktop helper had them
<ogra_> (i think they are fixed nowadays ... but the maintainer would have to re-build the snap to have it pick that up)
<kalikiana> ondra: I just took a look at the konfig options, wondering if that's another possibility, but it seems like uboot's arm handling a little bit... special
<jaggz> http://paste.debian.net/980796/  I was just testing "snap remove meshlab" btw
<ogra_> kalikiana, pfft ... uboot was there first .... it is *everyone elses* arm handling thats broken :P
<ogra_> (indeed :) )
<jaggz> got those core errors again
<ogra_> jaggz, your snapd installation seems seriously messed up
<ogra_> what did "snap version" say ?
<jaggz> I don't have much in it.. I don't mind removing it and doing a clean install..
<jaggz> 2.27~rc4
<ogra_> the full utput ...
<ogra_> *out
<jaggz> series  16
<jaggz> debian  9
<jaggz> kernel  4.9.0-3-amd64
<ogra_> and snap as well as snapd show as 2.27~rc4 ?
<ogra_> (smells like your core snap is on the edge channel for some reason)
<ogra_> ogra@styx:~$ snap version
<ogra_> snap    2.26.14
<ogra_> snapd   2.26.14
<ogra_> series  16
<ogra_> ubuntu  16.04
<ogra_> kernel  4.4.0-83-generic
<jaggz> yeah.. sorry.. didn't paste them for that purpose
<ondra> kalikiana yeah it's a bit special
<jaggz> hmm.. I'm in debian testing
<ogra_> this should be what you see on anything tracking the stable channel atm
<ogra_> jaggz, your distro shoulldnt matter at all ... thats all internally managed by snapd
<ogra_> via the core snap
<jaggz> oh I'm at stretch
<ogra_> snap info core|grep tracking
<ogra_> that should tell you what core snap you have
<jaggz> beta
<ogra_> aha
<ogra_> (why did you move it to beta ? )
<jaggz> I'm too unknowledgeable to have done that :)
<ogra_> snap refresh core --stable
<ogra_> that would get you back onto stable ... though i guess you are again hitting the namespace error now
<jaggz> namespace error?
<jaggz> it's working on the refresh, btw
<ogra_> yes, the stuff you pasted above
<jaggz> yeah.. :(
<jaggz> why's there no snap-update-ns
<ogra_> popey, FYI https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner ... (if that ever builds, it will have the nanopi air support in it ... but we'll need a dedicated gadget for that board too)
<jaggz> doesn't look like it's a part of the debian package
<popey> ogra_: ooh! Exciting!
<popey> ogra_: once it does, will you make a new image for it?
<ogra_> popey, yep
<ogra_> popey, but i cant test it indeed ... so all up to you
<popey> suh-weeeet
<popey> look forward to that
<popey> got some ideas for things to do with that silly device
<zyga-suse> jaggz: snap-update-ns is not in 2.21 package
<zyga-suse> it should be used from the core snap
<zyga-suse> but something seems broken there
<jaggz> :/
<jaggz> zyga-suse, thanks :)
<kalikiana> ondra: ogra_ https://forum.snapcraft.io/t/custom-environment-variables-for-kbuild-and-other-plugins/1639
<ogra_> kalikiana, well, i dont use kbuild anywhere (i find it way to opaque for porters)
<ogra_> kalikiana, i'd rather have a way to use an arch tag for build-packages :)
<ogra_> (like stage-packages provide)
<kalikiana> ogra_: You mean as in libfoobar:arm64?
<ogra_> kalikiana, that would really help with something like https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml (see the cross gcc check there)
<ogra_> kalikiana, yeah
<kalikiana> ogra_: So that's for multi-arch, right? Not really the same problem?
<ogra_> my gadgets usually already work fine for cross ... but i always need to tell the user to install the cross compiler manually (or have a sudo call in the snapcraft.yaml to apt install it)
<ogra_> kalikiana, not multi arch, gadgets are usually single arch target but multiple arches for building
<ogra_> reverse-multiarch i guess :)
<popey> ogra_: https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner it built!
<popey> (can you tell I'm excited)
<kalikiana> ogra_: When I say multi-arch I mean if you need to install armhf packages on an amd64 host - but I'm not clear on what exactly your use case is
<ogra_> popey, great ... i'll roll a new gadget for it
<ogra_> kalikiana, well, i dont install armhf packages ... look at the snapcraft.yaml above line 20-24
<ogra_> kalikiana, i install a package that doesnt exist on armhf when building on x86
<ogra_> that snapcraft.yaml works fine natively ... but spills an error telling you to install one additional amd64 package (teh cross compiler) when building on != armhf
<kalikiana> ogra_: But this says you need the arm gcc. That's normally in gcc-arm-linux-gnueabihf - so that's not multi-arch, it's actually a native package
<ogra_> kalikiana, since that package does not exist on armhf i can not just put it into build-packages without breaking the native build ... so on amd64 installs i'd like to be build-packages selective
<ogra_> kalikiana, gcc-arm-linux-gnueabihf is an amd64-only package
<ogra_> (it is only available on x86
<ogra_> )
<ogra_> it is a cross compiler built only on non-armhf ...  and not available at all on armhf
<ogra_> (else i'd just list it in build-packages and the corss build would just magically work without any fiddling)
<ogra_> kalikiana, but yes, essentially all i'd like is support for:
<kalikiana> ogra_: Oh. So the problem is you need a different package depending on the architecture
<ogra_> gcc-arm-linux-gnueabihfgcc-arm-linux-gnueabihf
<ogra_> bah
<ogra_> build-packages:
<ogra_>   - foobar [amd64]
<ogra_> something like this
<ogra_> which is supported in stage-packages but not in build-packages
<ogra_> kalikiana, yep, exactly
<ogra_> (super hard to explain :) )
<Pharaoh_Atem> mvo: running through a scratch build of 2.27: https://koji.fedoraproject.org/koji/taskinfo?taskID=21150688
<ogra_> kalikiana, note that all other uboot builds use this way, not kabuild
<ogra_> *kbuild
<ogra_> kbuild support in u-boot is very rare and very new and only a few new arches support it yet
<Pharaoh_Atem> gah
<kalikiana> ogra_: So you want something like "on" for build-packages
<ogra_> yeh!
<Pharaoh_Atem> mongodb ftbfs with new boost 1.64 :(
<ogra_> yeah!
<Pharaoh_Atem> and it's blocking snapd :(
<ogra_> Pharaoh_Atem, huh ? how can mongodb block snapd ?
<kalikiana> ogra_: I didn't actually realize this doesn't exist, I never need it  - would you mind opening a forum topic for this?
<ogra_> not at all ...
 * ogra_ writes
<kalikiana> Grand, thanks!
<Pharaoh_Atem> ogra_: mongodb go driver -> mongodb-libs -> mongodb
<ogra_> ah
<Pharaoh_Atem> I guess I'm going to fix mongodb (ugh)
<cachio> niemeyer, I think we need one more worker for fedora
<cachio> today 2 builds failed at least becasue of fedora jobs didn't finish
<cachio> niemeyer, is it ok if I move from 2 to 3?
<niemeyer> cachio: Ah, probably then
<niemeyer> cachio: What was the time delta between fedora finishing and the previous one?
<cachio> niemeyer, well fedora did not finish
<ogra_> kalikiana, https://forum.snapcraft.io/t/support-on-in-build-packages/1641
<niemeyer> cachio: Question still stands
<cachio> niemeyer, from the last disk removed until the job exceeded time is 15 minutes
<cachio> and still 46 tasks were missing
<niemeyer> cachio: Yeah, definitely sounds like a case for another worker
<cachio> niemeyer, also I think we need to try to speed up how the rmp is built
<cachio> niemeyer, the .rpm it is taking about 5 minutes more than the .deb
<mvo> Pharaoh_Atem: yay! build looks unhappy but failure looks unrelated (something about liboost?)
<mup> PR snapd#3711 opened: tests: adding new worker for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3711>
<Pharaoh_Atem> mvo: mongodb isn't rebuilt against new boost
<Pharaoh_Atem> and since snapd requires mongodb through requiring the go mongo driver
<Pharaoh_Atem> it looks like mongodb unit tests are failing on s390x (*sighs*
<ogra_> how weird, given that snapd doesnt use anything from mongodb
<ogra_> (or does it ?)
<pedronis> we  gopkg.in/mgo.v2/bson  (not sure how that relates to mongo itself on distros though)
<pedronis> *we use
<ogra_> ah
<mup> PR snapcraft#1427 closed: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <Closed by alextnewman> <https://github.com/snapcore/snapcraft/pull/1427>
<niemeyer> cachio: 5 minutes sounds pretty bad indeed
<cachio> niemeyer, yes, i'll research a bit more
<mup> PR snapcraft#1478 opened: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <https://github.com/snapcore/snapcraft/pull/1478>
<arm1e> I would like to learn how to prodouce snap packages and have successfully followed the helo world example on snapcraft but I dont know where to look next to help me compile a snap for an application. Examples I have seen have lots of flags that I dont understand that are not in the snapcraft example. Can anyone point me in the right direction please
<arm1e> *hello
<arm1e> not helo
<mup> PR snapd#3712 opened: overlord,store: send model assertion when setting up device sessions <Created by matiasb> <https://github.com/snapcore/snapd/pull/3712>
<kyrofa> arm1e, hey there!
<kyrofa> Sorry for the delay, I had my face buried in a fajita. You still around?
<bdmurray> Is there somebody interested in doing the SRU verification of snapd in -proposed? Its been there for a bit.
<pedronis> cachio: I'm seeing often failures like this one:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170810_183543_f1d6a@/log.gz   are we not waiting properly for the fakestore to be started or ther is something else going on
<cachio> pedronis, ok, I'll take a look
<cachio> pedronis, It appeared today
<pedronis> or maybe we don't stop the service
<pedronis> cachio: yes, IÂ don't remember seeing this at least for a while, anyway it seems the reason we get reds here and there now
<cachio> pedronis, yes, I am running a set of tests to try to reproduce the error
<cachio> I'll keep up updated with the result
<pedronis> thank you
<cachio> yaw
<ogra_> popey, if you upgrade your kernel to linux-generic-allwinner rev 2 and run: sudo fw_setenv fdt_file sun8i-h3-nanopi-neo-air.dtb ... and reboot ... i wonder if the wlan works :)
<arm1e> kyrofa: yup still here
<kyrofa> arm1e, I'm happy to help point you in the right direction. Is there something particular you're trying to snap up?
<arm1e> would like to snap gnucash as I have a friend who wants to switch to solus (who are adding snap support)  but it will not be added to their repos as some of the dependencies are old
<popey> ogra_: that'll be triicky given the machine has no network
<ogra_> popey, huh ? wired didnt work ?
<popey> it has no wired connector
<ogra_> oh !
<ogra_> i thought it had both
<popey> this is why i'm so keen for wifi to work :D
<ogra_> yeah, understood ... ok, then it needs a full image ... i'll give you something tomorrow
<popey> magic, ta
<mwhudson> morning
<kyrofa> Good morning mwhudson, welcome
<kyrofa> arm1e, what is that written in?
<popey> arm1e: kyrofa https://forum.snapcraft.io/t/call-for-comments-testing-gnucash/1480
<popey> jacob has worked on it, maybe you can work on it together?
<kyrofa> popey, how handy, thank you!
<mwhudson> ok maybe i have working debian packaging for 2.27
<mwhudson> probably not but it's worth trying the build now at least :)
<mwhudson> oh wait did 2.27 actually get released?
<kyrofa> mwhudson, it's tagged anyway
<mwhudson> and it was uploaded to artful
<mwhudson> and even built!
<kyrofa> mwhudson, your day is starting off strong
<mwhudson> and it failed it's autopkgtest on i386
<kyrofa> Aw
<mwhudson> whoa hasn't passed there in a while
<mwhudson> http://autopkgtest.ubuntu.com/packages/s/snapd/artful/i386
<mwhudson> - Download snap "core" (2465) from channel "candidate" (received an unexpected http response code (416) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_2465.snap?t=2017-08-10T17:00:00Z&h=359a718c18b7c126e3302dce1d720f2333d87dec)
<mwhudson> pff
 * mwhudson bounces on the retry button
<kyrofa> Sounds like https://forum.snapcraft.io/t/download-failure-416/1637/3
<mwhudson> omg my debian package built
<mwhudson> slangasek: https://anonscm.debian.org/git/collab-maint/snapd.git/log/?h=debian-2.27 <- mostly complete package of snapd for debian if you're interested
<mwhudson> slangasek: the git history is a mess (do we care? i could clean it up) and the changelog needs work (not sure what we should do there, bring in all the upstream changelog entries?)
<mwhudson> slangasek: but it works
<mwhudson> slangasek: do you have an opinion on using pristine-tar for this package?
<mwhudson> slangasek: s/works/builds/
<slangasek> mwhudson: pristine-tar applies only if the package is non-native, do we have that here?  and is there an actual upstream tarball for us to import?
<slangasek> git history> if it inherits from the previous package history, that's what I care about most
<mwhudson> slangasek: the package is non-native in debian yes
<slangasek> right, but still not in Ubuntu though it should be, bah
<mwhudson> slangasek: i based it on the tarball from github https://anonscm.debian.org/git/collab-maint/snapd.git/log/?h=debian-2.27
 * mwhudson blinks
<mwhudson> slangasek: https://github.com/snapcore/snapd/archive/2.27.tar.gz
<mwhudson> slangasek: in a sense the non-obvious canonicity of the tarball seems an argument in favour of pristine-tar for debian ... makes it clear what i used
<mwhudson> (even if not where i got it from)(
<mwhudson> slangasek: the git history is based on the previous packaging history yes
<mwhudson> it just has "oh crap i forgot a bit" commits in
<mwhudson> and some dubious merging
<slangasek> that doesn't bother me ;)
<mwhudson> ok
<mwhudson> slangasek: http://paste.ubuntu.com/25286402/ <- this is what the debian patch ends up being
<mwhudson> which all seems ok enough to me
<mwhudson> need to ITP that gettext package but that doesn't need to block the update
<mwhudson> ok afk for a bit
<arm1e> kyrofa: Any help in learning how to compile snaps. I have no idea how to check for deps. Willing to read, but would prefer to practise
<nacc> arm1e: what do you mean "check for deps"?
<arm1e> dependencies
<arm1e> Is there a good way to convert packages in the repos into snaps?
<nacc> arm1e: right, i know what deps are -- i don't know what you mean by check for them?
<nacc> arm1e: not really (that i know of)
<nacc> arm1e: i mean, a classic snap is the easiest way, but you still have to write the snapcraft.yaml
<slangasek> mwhudson: how does a missing ITP not block the update?
<arm1e> nacc: Sure. I just got really confused after completing the hello-world snap locally then looking at the yaml files from other snaps which have a lot of other info from plugins etc. It seems a big jump
<arm1e> Especially when you have never packaged before
<nacc> arm1e: well, right, i think hello-world is just to get you familiar with the commands and some basic syntax
<slangasek> mwhudson: and do those go dep path changes make their way back upstream?
<arm1e> I want to learn how to do it but everywhere just does really simple syntax and nowhere really teaches you
<nacc> arm1e: it doesn't, imo, make much sense to package something you're not familiar with. Do you have an application you care about?
<arm1e> nacc: Not particularly. I would like to get gnucash working but that looks like a major ball-ache
<nacc> arm1e: i would imagine for a classic snap of a given application that builds as a .deb, you could add all it's build-deps to build-packages, all the binary package's runtime deps to stage-packages and then try and build it normally (that is, if one of the existing plugins works). If they don't, you might need to write your own plugin to build
<arm1e> see, I dont fully understand the difference between build / runtime deps and how you know which plugins should be used.
<nacc> arm1e: do you understand the difference between build and runtime?
<arm1e> build is to compile and runtime is to actually use the app, right?
<nacc> arm1e: right
<nacc> arm1e: those are distinct environments, so they can have different dependencies
<nacc> arm1e: in other words, what you need to build something is not necesarily what you need to run it and v.v
<arm1e> okay.
<arm1e> nacc: So how do you choose the plugin?
<nacc> arm1e: by knowing how the code is built (what tool)
<arm1e> How do you know that? Is it in the source tarball?
<nacc> arm1e: you look and see? I'm not sure how to answer it
<nacc> it feels like a tautology: to build something, you have to know how to build it
<arm1e> nacc: Where can I learn this?
<nacc> arm1e: depending on the specific project, it might be the language (e.g., python or go) or it might be a specific build-tool (e.g. autotools)
<nacc> arm1e: where can you learn what exactly? build something, I mean, that's the whole point
<arm1e> nacc: What I mean is how can I tell if something is built in python etc?
<nacc> arm1e: it's not built in python, it's written in python
<nacc> arm1e: it's built by the python plugin by snapcraft
<arm1e> I see, what I mean is how can I tell from the source what the language is
<nacc> arm1e: you either know, because you're familiar with it, or you read documentation or you use `file` or ... i'm sure there are other ways
<arm1e> Right, I would like to make a snap for get_iplayer
<nacc> arm1e: link to source?
<arm1e> https://github.com/get-iplayer/get_iplayer
<nacc> arm1e: looks to be perl
<arm1e> yup. What do I do about the deps, how will I know if they are in the base system of the snap as usually packages pull from the repos of the host system, but is it different for snap packages?
<nacc> arm1e: how would you "build it
<nacc> sorry, hit enter too fast
<nacc> arm1e: how would you "build it" if you weren't thinking about snaps?
<arm1e> run the configure, check for deps if missing and add them via apt. once configured, make
<arm1e> only learnt that today, so may be wrong
<nacc> right, so you add those deps to your snapcraft.yaml as build-packages
<arm1e> just list the names?
<nacc> arm1e: see the online documentation for the syntax
<arm1e> what I mean is, once I have them listed, how do I know if the snap package will be able to find them?
<nacc> arm1e: you try to build?
<nacc> arm1e: what do you mean find them?
<arm1e> Might be wrong but when you normally build, your deps only matter to you if they are not already on your system, if not the build fails, so you apt-get to install them then retry. When you download a snap, doesnt the new system require these deps to be installed too?
<nacc> arm1e: isntalling a snap != building a snap
<nacc> arm1e: and i feel like you're jumping several steps
<arm1e> right
<arm1e> sorry
<nacc> arm1e: 1) building a snap is done with snapcraft (or using snapcraft.io)
<nacc> *build.snapcraft.io
<arm1e> gotcha
<arm1e> continue :)
<nacc> arm1e: in that case, it's done in a special environment that generates the squashfs image (which is what a snap is)
<nacc> arm1e: you don't build the snap again anywhere else
<arm1e> right, my bad
<arm1e> sorry
<nacc> arm1e: installing a snap is done via the store (or locally with --dangerous) and snaps contain all their dependencies
<arm1e> so you would only need to have the runtime deps
<nacc> (or should)
<nacc> a confined snap does not have access to the system by default, so it won't run without its dependencies in the snap as well
<nacc> a classic snap may work (if the dependencies happen to be installed) but won't otherwise -- and there's not a way to tie (currently) a snap to deb dependencies. So you should include them in your snap (IMO)
<arm1e> so how do you ensure these dependencies are in the snap?
<arm1e> Does it pull them from the system I am building on?
<nacc> arm1e: you put them there? either via stage-packages (explicitly), or via the plugin (depending on the plugin)
<nacc> arm1e: well, again, you build in a special enviornment, so it uses the ones in that environment, yes
<arm1e> okay, so stage-packages are the explicit dependencies for a snap to install / run on another system
<nacc> arm1e: i feel like maybe you should read the snapcraft.io pages a bit? https://tutorials.ubuntu.com/tutorial/create-your-first-snap?_ga=2.140231089.346536776.1502406151-840062186.1488838724#0
<nacc> or that tutorial, maybe
<nacc> arm1e: i'm pretty sure all of this on the website
<nacc> arm1e: stage-packges are the list of packages you want to stage in the snap (see the website for definitino of stage)
<arm1e> Yes. I will read them again tomorrow and try to get it to sink in. BTW there is no perl plugin so that makes it more difficult, right?
<nacc> arm1e: and to be clear "install a snap" has no dependencies, it's just a squashfs image that gets mounted somehwere
<nacc> arm1e: running the snap is the only thing that has dependencies on user's systems (which should all be included in the snap)
<arm1e> nacc: sorry, I mean run a snap
<arm1e> I am with you
<nacc> arm1e: might be, yes, but it seems like some users have made one, which you can copy, and it's not clear you need it in this case (if there's a makefile)
<mwhudson> slangasek: because the functionality requiring that package is removed in debian for now
<slangasek> mwhudson: ah ok
<slangasek> right, those would be the i18n bits of the patch
<mwhudson> yep
<mwhudson> -	"github.com/cheggaaa/pb"
<mwhudson> +	"gopkg.in/cheggaaa/pb.v1"
<arm1e> nacc: Will have a look in the morning. Thanks for your help. Time for bed
<nacc> arm1e: gl!
<mwhudson> ^ that path change should probably go upstream
<mwhudson> or the debian packaging should be changed to the other path, i'm not sure what upstream considers canonical currently
<mwhudson> the seccomp stuff is needed for trusty support upstream
<mwhudson> so that remains necessary delta
<mwhudson> for another 2 years i guess...
<slangasek> mwhudson: snapd ESM
<slangasek> :)
<mwhudson> slangasek: shutup
<slangasek> mwhudson: it's ok, ESM is security only!
<mwhudson> slangasek: so what should debian's debian/changelog contain?
<mwhudson> do i copy over the new entries from packaging/ubuntu-16.04/changelog and slap something debian specific on the top?
<mwhudson> hmm E: snapd: statically-linked-binary usr/lib/snapd/system-shutdown
<mup> PR snapcraft#1471 closed: catkin plugin: support passing args to cmake <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1471>
#snappy 2017-08-11
<mup> Issue snapcraft#1464 closed: Extract rosdep into its own package <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1464>
<mup> PR snapcraft#1392 closed: catkin plugin: extract rosdep into new package <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1392>
<mup> PR snapcraft#1479 opened: rosdep: add support for multiple dependency types <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1479>
<slangasek> mwhudson: I think it's reasonable for the Debian debian/changelog to list Ubuntu history also, yes
<mwhudson> slangasek: ok
<mwhudson> what is usr/lib/snapd/system-shutdown for?
<mwhudson> i have a guess that it might only be relevant on an all-core system?
<PhoenixMage> Hi guys, when I set LD_LIBRARY_PATH in a yaml do I have to put the original library paths in also?
<mwhudson> Aug 11 00:14:29 autopkgtest snapd[2412]: 2017/08/11 00:14:29.874892 task.go:303: DEBUG: 2017-08-11T00:14:29Z ERROR received an unexpected http response code (416) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_2465.snap?t=2017-08-11T02:00:00Z&h=ac56e373310e0069784f61009d0bad0e6c529795
<mwhudson> ^ this is happening apparently repeatedly in the i386 autopkgtest, is it possible that something is broken with the i386 core snap or the cdn?
<mwhudson> oh wait
<mup> PR snapcraft#1480 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1480>
<mup> PR snapd#3709 closed: release: snapd 2.27 release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3709>
<jjohansen1> ikey|afk: apparmor depends (selects actually) CONFIG_AUDIT, it does not depend on CONFIG_AUDITSYSCALL
<mup> PR snapd#3713 opened: osutil: ensure TestLockUnlockWorks uses supported flock <Created by mvo5> <https://github.com/snapcore/snapd/pull/3713>
<mup> PR snapd#3711 closed: tests: adding extra worker for fedora <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3711>
<mup> PR snapd#3703 closed: interfaces: improve and tweak bunch of interfaces test cases <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3703>
<mup> PR snapd#3701 closed: tests: fix interfaces-cups-control test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3701>
<zyga-suse> good morning
<mup> PR snapd#3675 closed: tests: restart snapd to ensure re-exec settings are applied <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3675>
<arm1e> nacc: You still there?
<mup> PR snapd#3704 closed: interfaces: convert lxd to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3704>
<arm1e> can anyone help with creating a snap please.
 * zyga-suse reboots
<mvo> arm1e: hey, any specific question abut snapping ? its probably best to just ask the question :) then people can reply when they see the message. in any case, did you check out https://tutorials.ubuntu.com/tutorial/create-your-first-snap#0 already?
<arm1e> okay. I am trying to compile a snap for get_iplayer. I have started the yaml file and added the run dependencies but to install you are supposed to run the following
<arm1e>  install -m 755 ./get_iplayer /usr/local/bin
<arm1e> how to i set that in the snap?
<arm1e> Following the instructtions here btw: https://github.com/get-iplayer/get_iplayer/wiki/unix
<zyga-suse> mvo: hey
<zyga-suse> mvo: do you have a second?
<zyga-suse> mvo: well, honestly, 5 minutes
<mvo> arm1e: if you just want to make get_iplayer available you can use e.g. the organize rule in snapcraft to put it into the snap, there is no need to install it to /usr/local/bin, it just need to be in the snap (well, at least that is what I assume, I don't know get_iplayer)
<mvo> zyga-suse: sure
<mvo> zyga-suse: phonecall or chat?
<zyga-suse> mvo: hangout
<zyga-suse> I want to screen-share
<arm1e> i am confused. (sorry)
<zyga-suse> I'm in the standup HO
<Chipaca> arm1e: if I remember get_iplayer, you don't need to run that install step, you can just run it from where it is
<arm1e> Chipaca: so how do i snap it?
<Chipaca> arm1e: doesn't it have a Makefile though?
<ogra_> it does
<arm1e> no mention in the doc, but will check
<ogra_> Chipaca, seems it is a perl program ... that will need some extra fiddling to have perl work
<Chipaca> arm1e: if it has a makefile, I _think_ snapcraft knows how to deal with it
<ogra_> (at least if there asre any modules involved)
<arm1e> found one
<Chipaca> ogra_: i remember i played with snapping it "by hand" (before snapcraft) and indeed the tricky bit was the perl libs
<Chipaca> but not super tricky, just more effort than i wanted back then :-)
<ogra_> yeah
<Chipaca> ogra_: also ffmpeg
<ogra_> (my first snap was also a perl thing)
<arm1e> https://github.com/get-iplayer/get_iplayer/blob/master/Makefile
<Chipaca> (but that's optional)
<Chipaca> arm1e: are you using snapcraft
<arm1e> I have installed ffmpeg 3 from the ppa on the host machine
<arm1e> Chipaca: yes
<arm1e> here is my yaml file so far (be gentle, it is my first time!)
<Chipaca> arm1e: snapcraft has a make plugin
<arm1e> https://pastebin.com/Xv56Qn7K
<Chipaca> arm1e: you should be able to use plugin: make instead of plugin: dump
<arm1e> just trying that
<Chipaca> arm1e: but somebody who groks snapcraft more than me should probably guide you
<Chipaca> arm1e: https://snapcraft.io/docs/reference/plugins/make
<arm1e> okay, pulling now
<arm1e> Chipaca: error https://pastebin.com/QqebESbn
<Chipaca> arm1e: looks like you need to tell it what to install manually (why even have a makefile?!). Fortunately the plugin supports this?
<arm1e> how do i do it?
<arm1e> is it the artifacts tag?
<arm1e> really stuck now
<Chipaca> arm1e: did the examples help?
<arm1e> what examles?
<arm1e> Chipaca: I cant work out the syntax for the make plugin
<arm1e> Chipaca: all I get is 'Mapping values are not allowed'
 * zyga-suse tries this on artful
 * ikey cracks knuckles to begin another snapfest solus day
<zyga-suse> hey
<zyga-suse> :)
<ikey> heya ^^
<arm1e> Chipaca: the examples for make linked on the snapcraft page do not lead to anything other than a github error!
<Saviq> kalikiana: hey, for some reason container builds (not cleanbuild) stopped working here, complain about snap/snapcraft.yaml missing, any ideas?
<Saviq> it works the first time, but not after the container already exists
<arm1e> Can anyone help with the syntax for the make plugin please?
<kalikiana> Saviq: What version are you running?
<Chipaca> arm1e: ouch
<arm1e> Chipaca: what?
<Chipaca> sergiusens_: ^ who's working on that?
<Chipaca> arm1e: <arm1e> Chipaca: the examples for make linked on the snapcraft page do not lead to anything other than a github error!
<arm1e> I know, not the best documentation is it
<arm1e> ANy ideas how i can find examples?
 * arm1e starts to regret beginning this work
<pedronis> Chipaca: hi, maybe you can give a 2nd/3rd review to:  snapd#3712
<mup> PR snapd#3712: overlord,store: send model assertion when setting up device sessions <Created by matiasb> <https://github.com/snapcore/snapd/pull/3712>
 * zyga-suse reviews 3710 while waiting for packages downloads
<arm1e> can someone please help me with the syntax to use options for plugins
<zyga-suse> mvo: the test passes on artful and I can now compare the behavior
<zyga-suse> arm1e: hey
<zyga-suse> arm1e: which options for which plugin specifically?
<zyga-suse> arm1e: (I'm sorry for the bad experience you had so far)
<zyga-suse> quick question, does anyone remember that snap which had a fancy music player installed?
<ikey> arm1e, see https://github.com/jeteokeeffe/lindacoin-wallet-snap/blob/master/snap/snapcraft.yaml#L61
<zyga-suse> ikey: FYI I get the "bad system call" from duckmarines on ubuntu 17.10
<ikey> there is an example there of make/autotools/organise/artifacts + dump
<ikey> zyga-suse, oh interesting
<arm1e> zyga-suse: I am having trouble with the build steps in make as the make file is crap. I need to specify the installation location
<zyga-suse> arm1e: snapcraft sets DESTDIR I think
<ikey> zyga-suse, the makefile is release-only
<ikey> no actual install steps
<ikey> so its a manual install of a perl script and manpage
<ikey> i.e. "./get_iplayer" needs organising into usr/bin
<zyga-suse> aha....
<arm1e> zyga-suse: https://pastebin.com/Xv56Qn7K
<zyga-suse> why don't you just run the get script and package the results?
<arm1e> zyga-suse: I dont know how. I have not packaged before
<zyga-suse> arm1e: some syntax there looks wonky
<zyga-suse> arm1e: tabs vs spaces maybe?
<ikey> and !yaml
<zyga-suse> arm1e: my suggestion, skip the downloader, just get the bits you want to put into the snap
<arm1e> this was the error https://pastebin.com/QqebESbn
<zyga-suse> arm1e: using stage-packages means you get unpacked deb files into your snap, those are not always going to work
<zyga-suse> make: *** No rule to make target 'install'. Stop.
<arm1e> no, but I made sure that I had the correct versions mentioned in the get_iplayer docs
<zyga-suse> arm1e: I don't see how you use a makefile since the earlier pastebin used the dump plugin
<arm1e> it was an old version
<arm1e> hang on a sec...
<zyga-suse> I packaged python0 as a classic snap a while ago
<zyga-suse> https://github.com/zyga/python0
<zyga-suse> using make
<zyga-suse> maybe that will help you out
<ikey> 0.9.1.. damn..
<zyga-suse> :D
<zyga-suse> and so small :D
<zyga-suse> I was researching bytecode evolution across python versions
<ikey> ah
<zyga-suse> ikey: try it, it is interesting
<zyga-suse> ikey: ldd the binary
<zyga-suse> ikey: and readelf the binary
<ikey> sure
<ikey> woa.
<arm1e> https://pastebin.com/A9Bi4UTJ
<ikey> only 2 DT_NEEDED
<zyga-suse> arm1e: yaml still looks wonky
<zyga-suse> arm1e: line 15
<zyga-suse> ikey: note how it links to the core snap
<arm1e> zyga-suse: Not like that in my text editor tho
<zyga-suse> arm1e: fix your editor
<ikey> zyga-suse, it does?
<zyga-suse> arm1e: you must be mixing tabs and spaces
<ikey> ldd on python0 https://hastebin.com/takerojuvi.go
<ikey> wait im being a twit
<ikey> i think i ldd'd the wrong guy :P
<ikey> lol yeah i ldd'd the bin/ symlink
<ikey> 	/snap/core/current/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (0x00007fdb2220f000)
<arm1e> https://hastebin.com/esilogacib.cs
<arm1e> pastebin is crap
<ikey> ah you RPATH'd it
<zyga-suse> ikey: more than that
<zyga-suse> ikey: look at the dynamic linker
<ikey> yea
<zyga-suse> :-)
<ikey> pretty snazzy
<ikey> fwiw solus uses a different linker location to most
<ikey> /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.14.32, BuildID[sha1]=06de7bdeae201f41009ee0ce7d0bfd4bd9748907, stripped, with debug_info
<zyga-suse> oh, interesting!
<ikey> but we have a compat link stuffed in /lib/
<zyga-suse> aha
<ikey> to keep chrome etc going
<ikey> the toolchain itself is built to use /usr only
<ikey> https://hastebin.com/eluzuyetiq.go :D
<arm1e> zyga-suse: could you talk me through what I should be doing next please
<arm1e> I am feeling lost
<arm1e> ikey: I am learning this to be able to snap gnucash (evetually....maybe) to be able to runit in bloody solus!
<ikey> heh
<ikey> yeah they dont like using modern libs
<zyga-suse> ikey: as for duckmarines
<zyga-suse> if you add one line to its seccomp profile and rebuilt it will work
<arm1e> ikey: I know, but I have my accounts on the thing. Tried to move away but cant
<ikey> well what im seeing for python0 is this:
<ikey> cannot change profile for the next exec call: No such file or directory
<zyga-suse> I think the author made this snap and we broke compatibility by restricting sockets more
<ikey> which means this fails:
<ikey> 	if (aa_change_onexec(profile) < 0) {
<zyga-suse> ikey: odd, python0 should not need that
<zyga-suse> or maybe I forgot and it does
<ikey> which is coming from:
<ikey> open("/proc/18856/attr/exec", O_WRONLY) = 3
<ikey> write(3, "exec snap.python0.python0", 25) = -1 ENOENT (No such file or directory)
<zyga-suse> right
<zyga-suse> it apparently does need that
<zyga-suse> just that the profile is permissive
<zyga-suse> ikey: as for the netlink socket
<ikey> ah yeah
<zyga-suse> ikey: I added "socket AF_NETLINK -  NETLINK_KOBJECT_UEVENT" to snap.duckmarines.duckmarines.src
<ikey> yeah makes sense
<zyga-suse> and re-built that with snap-seccomp compile foo.src foo.bin
<Saviq> kalikiana: 2.33
<zyga-suse> mvo: ^ any objection if I add go-flags to snap-seccomp
 * arm1e Washes hand so that it can be held as he is led through packaging to help cure his ineptitude
<zyga-suse> and this made it start up OK
<ikey> fwiw im getting the profile change issue on *all* snaps
<ikey> even duckmarines
<zyga-suse> right, I think you are missing something in the kernel still, you just don't have the attr/exec file in proc right?
<ikey> no i have it
<ikey> /proc/7233/attr/exec for my shell exists
<ikey> cat /proc/$$/attr/exec
<ikey> cat: /proc/7233/attr/exec: Invalid argument
<zyga-suse> hmmm
<zyga-suse> ah
<zyga-suse> right
<ikey> its an empty file - no idea what its meant to do/have
<zyga-suse> sorry so this is because the thing that gets written there
<ikey> yeah
<zyga-suse> the name of the apparmor profile to use
<zyga-suse> such profile doesn't exist
<Saviq> kalikiana: it's as if it's not entering /root/build_multipass - it's mounted fine
<ikey> and the kernel cries about it
<zyga-suse> because snapd didn't make one
<zyga-suse> because you are still on partial confinement
<ikey> right
<zyga-suse> because not all apparmor features are detected
<zyga-suse> one sec
<ikey> ok
<zyga-suse> hrm
<zyga-suse> polari doesn't want to connect from artful for some reason
<kalikiana> Saviq: Lemme see if I can reproduce
<zyga-suse> ikey: I wanted to let you know which features I see on ubuntu
<ikey> ok
<zyga-suse> ikey: capability, caps/, dbus/, domain/, file/, mount/, namespaces/, network/, policy/, ptrace/, query/, rlimit/, signal/
<zyga-suse> ikey: those with slashes are directories
<ikey> capability  caps/       domain/     file/       policy/     rlimit/
<zyga-suse> so the backport patch, must have been partial
<ikey> seems it
<zyga-suse> ikey: can you look at ubuntu sauce patches in any ubuntu kernel that affect security/apparmor directory
<ikey> idk where to find those sauce patches
<ikey> i have http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/log/?h=v4.13-apparmor-backport-to-v4.12
<ikey> but those are missing capabilities obv
<kalikiana> ^^ this makes me look forward to lunch
<zyga-suse> yeah, looks like out of date
<ikey> saw nothing about dbus, etc, in the presquash
<zyga-suse> ikey: look at xenial tree at http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/
<zyga-suse> ikey: then just look for patches that affect apparmor
<zyga-suse> (in securty/apparmor directory)
<ondra> kalikiana ping
<zyga-suse> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/security/apparmor
<ikey> thats a lot of signal noise
<kalikiana> ondra: Hey
<zyga-suse> ikey: note that this is based on 16.04 kernel which is older
<zyga-suse> ikey: so some of those are merged upstream from your POV
<ondra> kalikiana I have problem with prime: [ -lib ]
<ondra> kalikiana it will still leave some bits there
<ondra> kalikiana does seem to work for all other directories except lib
<ondra> kalikiana or tell me what is cleanest way to pull stage package and only extract one file from it
<ikey> sure but apparently the dbus work started in 2014
<ikey> why/how are these not upstream?
<zyga-suse> ikey: lots of reasons, one of which was rush to get phone features ready
<ikey> yeah but roadmap is from 2011 :p
<zyga-suse> ikey: the focus is on exclusively upstreaming them for some time
<ikey> 6 years..
<zyga-suse> ikey: some reason, AFAIK (not a 1st hand report) is some upstream discussions on specific mediation extensions
<ikey> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/security/apparmor/apparmorfs.c#n1568
<ikey> is the bits-i-dont-got
<ikey> oh wow this is an old kernel
<zyga-suse> xenial is old
<zyga-suse> try artful
<zyga-suse> artful has the same features but less patches
<zyga-suse> so should be far closer to solus
<ikey> yeah artful is rocking 4.11.0
<mvo> zyga-suse: go-flags for snpa-seccomp is fine
 * zyga-suse thinks about automatically fixing security profiles of certain snaps
<zyga-suse> great experience for people
<zyga-suse> kind of magic and windows-y
<zyga-suse> but then again...
<zyga-suse> well, maybe later
<ikey> k so the upstream 4.13 patch is very different to the artful tree
<zyga-suse> mvo: interesting, on suse we execute the cycles=2 line
<zyga-suse> ikey: is 4.14 the next LTS kernel>
<ikey> yea
<ondra> kalikiana any idea?
<ondra> kalikiana BTW what is syntax to add stage package as snap?
<ondra> kalikiana or is that limited only to build packages?
<kalikiana> ondra: I'd probably do the reverse, [lib/foobar.so] Not sure, though, what "some bits" would be left. Maybe from packages installed in another part?
<kalikiana> ondra: stage package as a snap? Not sure what that means
<ondra> kalikiana so what would be syntax if I want just one file?
<ondra> kalikiana did we enable build-packages and stage-packages to be also snaps? or it's limited to only deb packages?
<kalikiana> ondra: I just told you the syntax :-D
<ondra> kalikiana OK let me try :)
<kalikiana> ondra: Oh. Those are always Debian packages. You might want build snaps, which is something that has been proposed but doesn't exist yet.
<ikey> well according to release/release.go i need all the apparmor features ubuntu has.. buh
<ondra> kalikiana for example I'd like to pull in snap package as build dependency
<ondra> kalikiana OK that works, except that lib dir is still there
<kalikiana> ondra: Feel free to open a forum topic, as I said it's been proposed but doesn't exist
<kalikiana> ondra: I thought you have a file lib/foo.so - how would that work without the directory?
<ikey> long time since i had to make defconfig a kernel git and build one module lol
<kalikiana> Saviq: Hmm I think I've reproduced with a repeated "snapcraft" invocation. Would you mind opening a forum topic so we can track it?
<jdstrand> zyga-suse: https://bugs.launchpad.net/snapd/+bug/1663221
<mup> Bug #1663221: snap/apparmor default confinement rejects socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT); <snapd-interface> <snapd:Fix Released by jdstrand> <https://launchpad.net/bugs/1663221>
<Saviq> kalikiana: ack
<kalikiana> Thanks
<jdstrand> zyga-suse: that was the whole reason we did fine-grained mediation and I could've sworn I added that
<zyga-suse> aha, thank you
<zyga-suse> :)
 * zyga-suse hugs jdstrand
<jdstrand> https://bugs.launchpad.net/snapd/+bug/1663221
<zyga-suse> mvo: so, some more data
<zyga-suse> mvo: interesting actually
<jdstrand> but either it got lost with all the commit/uncommit/commit/uncommit/recommit/... or I didn't submit that because of it
<zyga-suse> mvo: on ubuntu the goroutine is scheduled quickly
<zyga-suse> mvo: on suse it is cheduled nearly 500ms later
<zyga-suse> *scheduled
<zyga-suse> and some of the logic kicks in
<jdstrand> mvo: I'm going to prepare a PR for that ^ and a couple of smaller fixes. I think it should be in 2.27 :\ (since we are now enforcing netlink mediation)
<jdstrand> s/smaller/other small/
<zyga-suse> mvo: ^^^
<ondra> kalikiana no actually I'm pulling just one file from bin, but it adds me lib regardless
<zyga-suse> rc++
 * Chipaca takes a break
<arm1e> zyga-suse: hey, gotta go soon. Any chance you can have another quick go at helping me fix the get_iplayer snap build
<zyga-suse> mvo: it seems that on suse goroutines are only scheduled every 0.5s
<zyga-suse> arm1e: sorry, I lost track of what the issue was
<zyga-suse> arm1e: apart from some syntax errors
<zyga-suse> arm1e: what was the last thing you were blocked on?
<arm1e> cannot build it as the makefile is crap
<zyga-suse> arm1e: who wrote the makefile
<zyga-suse> arm1e: look at my python0 snap, it uses a separate makefile to fix the makefile that is crap in python0
<arm1e> the author of the program, but you said something about manually installing it
<zyga-suse> arm1e: specifically, write one that doesn't suck
<arm1e> there is no real build
<zyga-suse> arm1e: you can then patch or replace it
<ogra_> popey, give it a try please :) http://people.canonical.com/~ogra/snappy/nanopi-air.img.xz
<arm1e> zyga-suse: https://github.com/get-iplayer/get_iplayer/wiki/unix
<zyga-suse> arm1e: sorry, I cannot jump into all the details now
<zyga-suse> arm1e: I gave you ideas on how to fix it
<zyga-suse> arm1e: one other idea
<zyga-suse> arm1e: is the iplayer a pre-built binary?
<zyga-suse> or are you really building it
<arm1e> it seems to be prebuilt
<zyga-suse> arm1e: so ignore *everything* else
<zyga-suse> and just package the content
<arm1e> how do i do that?
<zyga-suse> using the dump plugin
<zyga-suse> just get it as you would normally
<zyga-suse> and once you have that
<zyga-suse> package it using the dump plugin
<arm1e> then it says to run 'install ./get_iplayer /usr/local bin. How do I set that?
<zyga-suse> you don't get it
<zyga-suse> install it on your machine
<zyga-suse> then copy it into as snap
<arm1e> oh
<arm1e> how
<zyga-suse> tadam
<zyga-suse> copy all the files one by one into your repo with snapcraft yaml
<zyga-suse> and "install" them using the dump plugin from a tarball or something
<zyga-suse> do you get the overall idea?
<arm1e> I do... i ink
<arm1e> think
<kalikiana> ondra: So you've got an empty lib/ in your snap? Could be a bug, but I think I'd need more context at this point. I'd say take it to the forum with some more details.
<arm1e> will have a go later. Thanks!
<zyga-suse> once that works you can think about maybe optimizing the initial step which will be manual for you once
<zyga-suse> good luck
<ogra_> zyga-suse, it is a perl script ... he'll have a hard time getting the module paths right etc ... (will need wrapper scripts etc)
<ogra_> (perl stuff is sadly still ugly to snap )
<ondra> kalikiana no, it's not empty, it has few libs in there
<ondra> kalikiana is snapcraft as smart as keeping some libs which are needed by that executable?
 * zyga-suse braks
<zyga-suse> mvo: I get the problem now :)
<zyga-suse> mvo: patch incoming if you are doing another RC anyway
<kalikiana> ondra: You can answer that question better, I don't know what libs those are :-)
<ogra_> doesnt snapcraft run ldd to check the libs a binary needs ?
<ogra_> (i thought it does)
<mup> PR snapcraft#1429 closed: cli: properly handle exceptions in lifecycle <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1429>
<kalikiana> ogra_: Yes it does
<ogra_> that should answer ondra's question then :)
<ondra> kalikiana ogra_ probably the case it keeps dependencies needed by the binary
<kalikiana> Well, as I said, I can only guess. Many possibilities.
<kalikiana> Of course I'm happy to assume it's super smart and free of bugs in this particular case
<ogra_> haha
<ogra_> like all software you mean ?
<kalikiana> Some software is more bug free than others
<ogra_> lies :P
<ogra_> :)
<Saviq> kalikiana: https://forum.snapcraft.io/t/repeated-container-builds-fail-to-find-snapcraft-yaml/1649
 * zyga-suse really breaks
<pedronis> zyga-suse: fedora prepare is failing with:   Cannot download d/distribution-gpg-keys-1.12-1.fc25.noarch.rpm: All mirrors were tried
<zyga-suse> pedronis: mmm, let me check
<zyga-suse> pedronis: btw that ensure test is now better understood
<mup> PR snapd#3714 opened: interfaces: a bunch of interfaces test improvement <Created by adglkh> <https://github.com/snapcore/snapd/pull/3714>
<gary-wzl> zyga-suse: I just created another PR for interfaces improvement.
<zyga-suse> pedronis: I don't know the reason of the effect yet but I know it is present and the cause is a test failure
<zyga-suse> gary-wzl: I saw, I'lll review it soon
<gary-wzl> zyga-suse: That'd be the last bunch of interfaces I work for the improvement.   :D
<gary-wzl> Thanks. After they land, I'll merge master back to udev_tag branch.
<zyga-suse> pedronis: the effect is that ensure ticks at 0.5s on suse and 0.01 on ubuntu
<gary-wzl> Then we  probably have minimized diff size and can focus on code review for actual udev tagging rule. :)
<gary-wzl> Thanks again!
<zyga-suse> pedronis: (or sorry 0.02 on ubuntu)
<zyga-suse> pedronis: if it is compiler or kernel I'm not sure yet, I'll move a binary from one to another to compare now
<zyga-suse> pedronis: so that test behaves in a way it never expected simply because various Ensures are called way too infrequently
<zyga-suse> pedronis: a simple "fix" is to multiply the mocked intervals by 5
<zyga-suse> pedronis: one thing I also noticed is that suse uses xfs and btrfs
<zyga-suse> pedronis: so if any of the tests are hitting disk and running some sync op
<zyga-suse> pedronis: that might explain the extra slowdown
<pedronis> so you are saying that NewTicker misbihaves a bit on suse?
<pedronis> or whatever bit of go timers we use there
<zyga-suse> pedronis: I tested that, NewTicker works OK at at least 20ms resolution
<zyga-suse> it must be something else
<zyga-suse> I also compared my boxes and time it takes to lock/unlock is even better on this suse box (perhaps just CPU differences)
 * zyga-suse has a binary to move over now
<zyga-suse> woaah
<zyga> pedronis: http://paste.ubuntu.com/25289847/
<zyga> pedronis: the binary was compiled on suse
<mup> PR snapd#3715 opened: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
<zyga> and invoked on suse tumbleweed running 4.11.8 and ubuntu artful running 4.11.0
<popey> ogra_: what exact command do you use for serial connection to your nano pi? I get no response from screen and minicom, but maybe settings?
<zyga> pedronis: the diff whows that waitForPrune (from the test witness) runs at rougly each 50ms on ubuntu but roghly each ~400ms on suse
<zyga> *shows
<zyga> I'll try it the other way around now
<zyga> but since this only depends on pthreads now, I think it's clear something is very wrong
<jdstrand> mvo, zyga: fyi https://github.com/snapcore/snapd/pull/3715. I've milestoned it for 2.27 since it has a netlink mediation fix for QtSystems
<mup> PR snapd#3715: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
<zyga> jdstrand: ok
<zyga> jdstrand: would be nice to add a regression test for this
<zyga> jdstrand: as we missed this in all the testing
<jdstrand> zyga: I need a system with X and qtubuntu for that to be a true regression fix. otherwise the test would be artificial and just a test that we don't drop the rule (which we don't have per rule regression tests)
<zyga> indeed :/
<jdstrand> s/regression fix/regression test/
<ikey> so i did something kinda naughty.
<ikey> i took kernel 4.12, and artful kernel..
<ikey> replaced security/apparmor tree with artfuls one
<zyga> haha
<ikey> then patched it with some bits from 4.13
<ikey> and did some porting to current kernel
<ikey> (like not using the new aafs_create_symlink or aa_sfs ops)
<ikey> and it now builds
<zyga> I think you want to get a hold of jjohansen1 as he probably has the right patches stashed somewhere
<zyga> but thank you for doing this
<zyga> ikey: and the bug you found with that game, regression
<ikey> ive only kept the .policy + policy symlink from 4.13
<zyga> ikey: and fix is upcoming (from jdstrand above)
<ikey> oh ok
<ikey> freenode is like the spiritual opposite of viagra.
<mup> PR snapd#3716 opened: overlord: rely on more conservative ensure inteval <Created by zyga> <https://github.com/snapcore/snapd/pull/3716>
<mvo> jdstrand: thanks, I have  a look. too late for 2.27 unfortuantely (unless we need to do a .1)
<zyga> mvo: I think we doo
<zyga> mvo: this is a regression breaking visual snaps
<zyga> mvo: :/
<zyga> mvo: we *really* need this fixed ASAP
<ikey> plus ikey is gonna be hella awkward and have last minute PRs > 2.27
<zyga> mvo: the bane of point releases is still with us
<mvo> zyga: tell me more
<ikey> like did he have a car
 * ikey hides
<mvo> ikey: heh :)
<jdstrand> mvo: sorry, the netlink bits got lost on my end with all the commit/revert/commit/revert/commit/... stuff with seccomp arg filtering
<jdstrand> :\
<jdstrand> I always intended to submit this with the other netlink mediation since this was actually the bug that prompted the whole netlink mediation feature
<mvo> jdstrand: ok, its not too terrible 2.27 is not in stable yet. so one of the 2.27 PRs caused a regression?
<mvo> jdstrandand 3715 fixes it?
<jdstrand> mvo: 2.26 finally enforced seccomp netlink mediation even though it was sent up ages ago
<jdstrand> mvo: because the rules in 3715 weren't included (sorry), it regressed snaps that use QtSystems
<jdstrand> mvo: 3715 fixes that
<mvo> jdstrand: ok, so 2.26 is fine? and 2.27 is not unless we take 3715?
<jdstrand> (QtSystems for mouse/keyboard detection via udev under X)
<jdstrand> mvo: no, 2.26 has fine-grained netlink mediation
<jdstrand> mvo: it does not have the rule for QtSystems to work (it should've)
<jdstrand> mvo: therefore 2.26 has a regression
<jdstrand> mvo: 3715 fixes that
<zyga> mvo: if you don't mind please also take: https://github.com/snapcore/snapd/pull/3716
<mup> PR snapd#3716: overlord: rely on more conservative ensure interval <Created by zyga> <https://github.com/snapcore/snapd/pull/3716>
<zyga> mvo: it doesn't affect non-test code
<jdstrand> as it happens, there aren't many applications that use this, but ikey picked one that does
<zyga> mvo: and it will help with having less patches in distros
<popey> ogra_: nvm, got screen working
<mvo> zyga: sure
<mup> PR snapd#3717 opened: overlord,store: no piles of return args for methods gathering device session request params <Created by pedronis> <https://github.com/snapcore/snapd/pull/3717>
<Son_Goku> zyga: does this happen on Fedora 26 with golang 1.8.3 and 4.11.11?
<zyga> Son_Goku: I didn't check yet
<jdstrand> mvo: well, actually. looking at policy on my system, it seems that socket mediation is not in effect in 2.26, so 2.26 is *not* affected. 2.27 *will* regress without 3715
<popey> ogra_: subbiquity isn't seeing the network
<zyga> Son_Goku: my fedora box is right next to my suse box so I'll check soon :)
<zyga> Son_Goku: I suspect it's related to golang 1.8.1 vs .3
<ogra_> popey, damn ... can you capture dmesg and syslog and such ?
<jdstrand> s/socket mediation/fine-grained socket mediation/
<ogra_> well, actually only syslog off the SD i guess
<popey> OK
<popey> http://paste.ubuntu.com/25290000/ ogra_
<popey> \o/ nice paste number
<popey> pinnacle of my day. (I am easily pleased)
<zyga> jdstrand: I noticed more pushes to the PR
<zyga> jdstrand: is that really all we need?
 * ikey had to be awkward and pick the weird app
<ogra_> Aug 11 10:59:09 localhost kernel: [   26.303158] usbcore: registered new interface driver brcmfmac
<ogra_> Aug 11 10:59:09 localhost kernel: [   26.412084] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.txt failed with error -2
<ogra_> Aug 11 10:59:09 localhost kernel: [   27.475085] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
<jdstrand> zyga: just one-- 'r' to 'rw' in network-control
<ogra_> \o/
<zyga> right
<jdstrand> zyga: it should've been rw to begin with
<zyga> I'm curious how you found that
<ogra_> popey, so it finds the device and loads the driver ... but i'm missing the firmware in the kernel snap
<popey> ahh!
<ikey> so yeah if those 4.12 patches exist anywhere id love em, because my kernel wont boot (and efi sucks for debugging)
<jdstrand> zyga: oh and a comment change
<zyga> jdstrand: hmm? you changed from r to rw now
<popey> ogra_: so close :)
<jdstrand> zyga: let's back up
<ogra_> popey, we're close (but that takes another kernel snap build and some changes ... will take some time)
<zyga> https://github.com/snapcore/snapd/pull/3715/commits/3948b14c51f62f5c806a0b2ede6a50e94ecd01e7
<mup> PR snapd#3715: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
<popey> ogra_: I'm happy we're moving forward :)
<jdstrand> zyga: I submitted the PR with 'r' for ieee80211 but meant to use 'rw'. I re-read the commit and noticed I wanted to fix a comment and to actually make ieee80211 rw
<ogra_> yeah, me too ... i'm also looking into getting USB-OTG to work, then you can actually run the serial connection through the power cable ;)
<ogra_> no more extra cable needed for initial setup
<zyga> ah
<zyga> makes sense
<jdstrand> zyga: (if you notice the original commit message for ieee80211, it very clearly says it should be rw
<popey> ooh, that would be awesome
<ogra_> hmm ... why does it look for brcmfmac43430-sdio.txt ... we actually ship brcmfmac43430-sdio.bin already
 * ogra_ wonders if a simple symlink would do 
<zyga> afk, see you at the call
<sgclark> Hi, silly me registered a bunch of kde apps under a personal account how do I fix it to use our kde account? :(
<sgclark> in ubuntu store
<popey> sgclark: heh, we can move them.
<zyga> Pharaoh_Atem: hey
<zyga>   Cannot download d/distribution-gpg-keys-1.12-1.fc25.noarch.rpm: All mirrors were tried
<zyga> does that say we are on stale cache
<zyga> and need dnf refresh
<zyga> or that we are SOL
<sgclark> popey: that would be lovely, thanks
 * zyga boots F26
<popey> sgclark: do you have a list of the ones you want moved over? Want to drop me a mail with them in? alan.pope@canonical.com and I will forward to the store people as it's a manual process I believe
<sgclark> popey: I will email you, thankfully it wasn't a terribly long list. Thanks again.
<popey> no problem, easily done
<zyga-suse> not sure if it is btrfs or something else but "go test" in overlord uses 10MB/s of disk all the time
<zyga-suse> while on ext4 I don't see that
<zyga-suse> (I see rouhgly 1MB there)
<zyga-suse> Chipaca: if it turns out to be those atomic file write things would you mind if I disable that for testing?
<Chipaca> zyga-suse: i'm not sure if libeatmydata will work with go
<Chipaca> zyga-suse: but feel free to tweak the code to give it a try
<Chipaca> zyga-suse: however.......... i'll -1 a patch to actually do this
<Chipaca> zyga-suse: if you understand what i mean
<zyga-suse> Chipaca: mmm, eatmydata uses preloads wich won't work here
<Chipaca> yeah
<zyga-suse> Chipaca: if you'd -1 the patch then won't bother
<Chipaca> zyga-suse: but do it locally to answer the question
<Chipaca> zyga-suse: my opinions evolve with data, so get me data ;-)
<zyga-suse> ha, very good answer
<zyga-suse> OMG
<zyga-suse> Chipaca: so with that thing disabled daemon tests run in ...3s
<zyga-suse> so 100 fold better
<zyga-suse> Chipaca: overlord tests finish in just 9 seconds
<popey> jdstrand: do we have documented somewhere the steps needed to fiddle with aa rules in /var/lib/snapd/apparmor and then refresh aa? I have been googling but can't find a good guide
<zyga> Pharaoh_Atem: question, what is "dnf reposync" good for, this literally *synchronizes the whole repo over to local disk*
<zyga> Pharaoh_Atem: is that how one runs a mirror?
<zyga-suse> Chipaca: vs minutes (still running)
<kyrofa> popey, believe it or not, I can help you with that
<Chipaca> zyga: and in a system with a non-insane filesystem
<Chipaca> ?
<zyga-suse> Chipaca: one sec
<jdstrand> popey: https://forum.snapcraft.io/t/security-policy-and-sandboxing/554
<jdstrand> I should update that for bpf
 * jdstrand does so now
<zyga-suse> Chipaca: on ext4 on artful, with the same patch I go down from 71 seconds to 5 seconds
<kyrofa> jdstrand, that deserves to be much more discoverable than in the forum, IMO
<zyga-suse> Chipaca: that's an insane win
<zyga-suse> kyrofa: just blog about it and link to it :)
<kyrofa> Haha
<zyga-suse> Chipaca: so, are you interested in the patch now? :D
<jdstrand> kyrofa: it was in the wiki and niemeyer thought it would be best in the forum. Note, it is primarily useful to interface developers
<zyga-suse> this could cut the needless IO for testing
<zyga-suse> and speed up cycles tremendously
<ikey> sounds like fsync/sync woes?
<zyga-suse> I'll give you tree-wide numbers
<popey> jdstrand: i found that one, but the bit that's missing is how I refresh the apparmor rules after editing those files
<zyga-suse> ikey: yes, exactly
<popey> oh, found it :)
<ikey> aka "why rpm is slow" ..
<zyga-suse> Chipaca: on btrfs without this overlord tests take 139s
<zyga-suse> Chipaca: so 139 vs 9
<niemeyer> kyrofa: Ironically, the reason it's in the forum is precisely so it is visible
<niemeyer> (cc jdstrand)
<zyga-suse> ikey: hehe
<Chipaca> zyga-suse: ok, less opposed to it now
<Chipaca> zyga-suse: 70 to 5 is still impressive enough for me :-) what about spread tests?
<Chipaca> bah
<Chipaca> wait
<zyga-suse> Chipaca: didn't try them yet
<zyga-suse> Chipaca: but if we set this via environment
<Chipaca> some of the spread tests failed because we weren't syncing in the right places
<zyga-suse> Chipaca: we can nicely measure
<pedronis> also do we really want to turn that off in spread tests?
<zyga-suse> pedronis: not sure, perhaps, this is only there in case the machine crashes hard
<Chipaca> so we need to be really careful about which ones we turn it off for. Not a blanket turn-it-off thing for spread.
<zyga-suse> pedronis: the code is correct if we don't yank the power cable
<zyga-suse> Chipaca: I'm talking about dir.Sync and fd.Sync calls
<pedronis> anyway as Chipaca said it needs to be something we decide suite by suite and test and by tests
<Chipaca> zyga-suse: the bootloeader code got into trouble without the syncs iirc
<zyga-suse> Chipaca: why?
<Chipaca> zyga-suse: garbage in the bootloader conf file on reboot
<zyga-suse> Chipaca: do we unmount the /boot partition?
<zyga-suse> if we see garbage then it feels like another bug
<Chipaca> zyga-suse: this might've been when we remounted it ro
<zyga-suse> because none of the sync calls are mandatory if you unmount the fileysystem
<zyga-suse> not sure I follow that part, I don't know this code
<zyga-suse> but still, overall it feels like TRTTD in tests
<Chipaca> zyga-suse: integration-y stuff, for now we might want to not touch sync for core devices (the rest should be fine, and if not we learn)
<Chipaca> zyga-suse: but, i'm still concerned so let's see your patch first
<zyga-suse> ok
<ikey> zyga-suse, https://dev.solus-project.com/R3571:43c64241912cc3bfc35a4299097e82b00e1f2cd6
<ikey> >_>
<ikey> we haz matching apparmors :3
<zyga> woot
<zyga> jjohansen1: ^^
<zyga> can you please have a look
<mup> PR snapcraft#1478 closed: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1478>
<ikey> i nicked http://kernel.ubuntu.com/git/ubuntu/ubuntu-artful.git/tree/security/apparmor?h=master-next
<ikey> and then ported securityfs bits
<zyga> ikey: do you have confinement "strict" now?
<zyga> according to snapd?
<ikey> im using nvidia gpu so i need to wait for repo kernel build + nvidia drivers to be published
<ikey> nouveau doesnt support my GPU :P
<ikey> so we'll find out in a bit
<zyga> OK
<ikey> i booted it headless and confirmed that the correct features showed in the sysfs
<ikey> and that yknow, it actually booted..
<ikey> unlike attempt 1..
<ikey> is this the part where i make the joke about the solus and ubuntu kernels converging or is it too soon? :3
 * ikey ducks
<zyga> hahah
<zyga> convergence ^_^
<jdstrand> popey: it is in there (see Tips and Debugging)
<jdstrand> and I updated it for seccomp-bpf as well (which now needs something akin to apparmor_parser (ie, snap-seccomp))
 * zyga melts at 33C in warsaw now
<roadmr> jdstrand: hey! tools r896  is now live in production
 * zyga eats lunch slowly
<zyga> mvo: do you mind if I pull in jdstrand's patch into opensuse and skip 2.27.1 tarball
<Pharaoh_Atem> zyga: that requires metadata refresh
<zyga> ikey: you want to pull in https://github.com/snapcore/snapd/pull/3715 as a patch on top of 2.27 as well
<mup> PR snapd#3715: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
<zyga> Pharaoh_Atem: right, my thoughts exactly
<mvo> zyga: works for me
<zyga> nice
<zyga> I may finish the week with something done
<ikey> ah yeah i need to rebase my snapd
<ikey> thanks
<Pharaoh_Atem> zyga: so are we getting a 2.27.1 or do I need to pull a patch in?
<Pharaoh_Atem> zyga: reposync lets you quickly make a local mirror, I believe
<zyga> Pharaoh_Atem: we are getting both probably but I think you just need a patch
<zyga> Pharaoh_Atem: have you used it, is it something I could keep at home
<mup> PR snapd#3718 opened: tests: enable regression and completion suites for opensuse <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3718>
<Pharaoh_Atem> zyga: I have not used it
<Pharaoh_Atem> zyga: http://dnf-plugins-core.readthedocs.io/en/latest/reposync.html
<Pharaoh_Atem> but I don't see why it couldn't work
<zyga> Pharaoh_Atem: btw, so are we missing a dnf makecache call somewhere?
<Pharaoh_Atem> zyga: yeah, you guys took it out entirely
<arm1e> hey zyga-suse, back to try the iplayer snap for a bit
<zyga> Pharaoh_Atem: aha, let me fix it then
<zyga> Pharaoh_Atem: hmm, we *do* call "dnf makecache"
<Pharaoh_Atem> hmm, maybe you need to add it to more places
<Pharaoh_Atem> you probably took out --refresh
<zyga> hmm, tell me about refresh
<Pharaoh_Atem> dnf --refresh install forces metadata refresh before installing requested packages
 * zyga curses at insane alt-tab behavior
<zyga> is that what make cache also doesw?
<zyga> we use dnf makecache in all the places we apt-get updated
<Pharaoh_Atem> yes
<Pharaoh_Atem> dnf makecache == apt update
<zyga> hm, so something else is faulty
<zyga> I'll have to reproduce this
<Pharaoh_Atem> you've probably got the fault in all of them
<Pharaoh_Atem> but you'll notice more on Fedora due to churn
<zyga> people say that all the tests are red because of this on spread + fedora
<zyga> so I want to see
 * zyga wonders what is https://people.freedesktop.org/~mak/limba/
<ikey> zyga, was https://github.com/ximion/limba
<Pharaoh_Atem> that's ximion's project that predates flatpak and snap but had aspects of both
<ikey> went the glick2 route
<zyga> wow, this just gets better and better
<zyga> maybe apart from maintaining snapd I will do a hobby weekend project that does another bundle format
<ogra_> just merge support for them into snapd instead :P
<ikey> lol
<Pharaoh_Atem> haha
<Pharaoh_Atem> let's not and say we didn't
<zyga> I'll call my system flatpumbasnaptik
<arm1e> zyga: you missed eopkg
<zyga> and you will need to have it to install it
<zyga> nothing like self-hosting
 * ikey has every right to call his flatpak + snap system ikea.
<zyga> lol
<Pharaoh_Atem> mrrr
<ikey> would explain having a few screws loose.. :p
<arm1e> lol
 * ogra_ would be more subtle and call it "Merkel" (her concept is to just swallow the programs of her opponents, thats why she wins all the time) 
<zyga> ogra_: we'd probably have to go with "makrela" though
<ogra_> haha
 * zyga recalls "quality crap from pikea" from futurama
<ogra_> ha
<cachio> niemeyer, I saw this https://paste.ubuntu.com/25290471/
<cachio> on linode
<cachio> do you know what could be causing that?
<zyga> cachio: we are bus
<zyga> cachio: ran out of machines
<cachio> zyga, ok
<cachio> tx
<arm1e> how can I find out where an ubuntu package (from repo) has installed its files (so that I can copy them into my snap)
<zyga> arm1e: dpkg -L pkg
<ikey> no wajig love?
<ogra_> arm1e, you just list the packages of which you want the content in stage-packages
<ogra_> arm1e, that will make sure they end up under $SNAP
<ogra_> no need to copy around anything
<ogra_> cjwatson, oh ! ... i just noticed "Revision" on my LP build details for a snap ... is that new ?  (thoough why is the revision showing 3 correctly on https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner/+build/67084 but shows some hash on https://code.launchpad.net/~snappy-dev/+snap/core/+build/66911
<ogra_> )
<ikey> so um
<ikey> tada https://ibin.co/3WWRyaQcdv5A.png
<pedronis> zyga-suse: do we know what's the fedora problem?
<ogra_> ogra@nanopi:~$ snap refresh linux-generic-allwinner
<ogra_> error: cannot perform the following tasks:
<ogra_> - Mount snap "linux-generic-allwinner" (3) ([daemon-reload] failed with exit status 1: Failed to execute operation: Connection timed out
<ogra_> )
<ogra_> WOAH!
<zyga> pedronis: no, not yet
<zyga> pedronis: I'm checking still
<zyga> pedronis: we apparently do the right thing :/
<arm1e> ogra_: so, I am trying to build get-iplayer and have installed it onto my host via a ppa. I already have stage packages for run dependencies, but are you saying i simply include get-iplayer too?
<pedronis> shoudl we turn off the fedora suite until we understand?
<pedronis> zyga-suse: it's a bit blocking anything atm
<zyga> I know, working on it
<zyga> hmm, not sure, are you in a rush to land something today?
<pedronis> always
<ogra_> arm1e, get-iplayer is simply a perl script, use the git tree in your source: entry and have it download the git ... then use some way to copy the get-iplayer script into your snap either via the dump plugin or through an install script snippet in snapcraft.yaml
 * zyga moves to a colder room
<zyga> 35C
<pedronis> it's rainy here
<arm1e> ogra_: woah, woah .... slow down
<zyga> man I envy you so much
<ogra_> yeah, rainy and cold here too
<ikey> heh
<ogra_> that moves east though ... you shoudl have it on the weekend
<pedronis> zyga: it's a question if I'm in a rush or not, but blocked landings are always bad
<pedronis> I suppose because 27.1 probably 2.28 is a  bit delayed?
<ikey> hoping to get my solus changes for snapd PR'd today - assuming i make sufficient progress here that stuff works â¢
<zyga-suse> ikey: thank you, looking forward to it
<zyga-suse> pedronis: I think 27.1 next week because we cannot release on Fridays
<ikey> the hard bit is done now really zyga-suse
<ikey> i have strict confinement
<pedronis> that was not my question
<pedronis> anyway
<zyga-suse> ikey: you have no idea how happy I am about that
<ikey> lol
<zyga-suse> pedronis: I think the 2.28 schedule can stay unchanged
<arm1e> ogra_: I have the git repo in the source and had the dump plugin selected but not sure how to use the install snippet
<zyga-suse> pedronis: those are separate releases after all
<zyga-suse> pedronis: but this is mvo's call
<ikey> correct me if im wrong but i believe solus is the only other !buntu that has strict confinement..?
 * ikey is thinking in marketeering terms :p
<mup> PR snapd#3719 opened: interfaces: add new desktop and desktop-accessibility <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3719>
<zyga-suse> ikey: yes
<zyga-suse> ikey: that was exactly what I was thinking about
<ikey> blogposting intensifies
<kyrofa> ikey, oooo, indeed
<ikey> for spite/brownie points ill also enable the linux-lts kernel..
<ikey> lol
<ikey> (not today though because im not that mental)
<zyga-suse> jdstrand: should all UI snaps use the desktop plug?
<ogra_> arm1e, http://paste.ubuntu.com/25290638/ like this ...
<kyrofa> We have a desktop plug now?
<mvo> zyga-suse: I look at 2.27.1 in a wee bit, just finishing some bits around the new ensureCore code
<zyga-suse> mvo: k
<zyga-suse> jdstrand: reviewed
<nacc> arm1e: did you get your questions answered?
<tpatel> auto-connection plug-slot issue
<zyga-suse> tpatel: ?
<tpatel> I have a snap which exposes a slot (socket-server) for snap-2 and has a plug(client-control) to be connected to snap-3. At install time I'm seeing snap-1:socket-server is autoconnected to snap-1:client-control. Is this is snapd BUG?
<zyga-suse> what are socket-server and client-control?
<zyga-suse> and which interface is that
<tpatel> they are sockets
<arm1e> hey nacc, think so. There is a lot to learn, bt I did read all of the stuff you linked last night. Very helpful thanks
<flavianmanea>  Hello, I am having some issues on snapd, mainly, I was trying to build some rpms with snapd (https://snapcraft.io/docs/core/install-oe-yocto), to install them on MinnowBoard Max - Pulsar8. I have builded succesfully the packages, but there is a dependency in the snapd.rpm that I couldn't figure it out, and that is "kernel-module-squashfs", I couldn't figure it out if this should be present already in the kernel, or if there is
<ogra_> what interface type did you use for them ?
<arm1e> ogra_: will try that now, thanks
<zyga-suse> tpatel: which snapd interface are those?
<nacc> arm1e: yw
<tpatel> zyga-suse: these are not snapd-core interface.
<zyga-suse> flavianmanea: this is something for morphis__
<zyga-suse> tpatel: ok, what kind of plugs are socket-server and client-control, I still don't get what the problem is
<ogra_> flavianmanea, snap packages are squashfs files, so to make use of them you need squashfs support in your kernel (either via module or builtin)
<jdstrand> zyga-suse: responded in the PR, but please see the accompanying forum topic
<morphis__> flavianmanea: if your kernel has squashfs support build in rather than as a module you could drop that dependency
<tpatel> socket-server is a slot name, client-control is a name of snap-3 slot which snap-1 needs to connect to.
<zyga-suse> jdstrand: thank you
<zyga-suse> tpatel: ok, slots and plugs have interface *types*, which types are you using there
<zyga-suse> tpatel: the plug/slot names are arbitrary and irrelevant
<zyga-suse> tpatel: the only thing that matters is the type of each of those
<tpatel> this are content type
<zyga-suse> aha
<zyga-suse> ok
<zyga-suse> did you define the "content" attribute on them?
<tpatel> yes
<zyga-suse> ok
<zyga-suse> is it the same in both?
<tpatel> yes. here is snapshot from .yaml file
<tpatel> plugs:     #connect to slot provided by wifi-ap and use api to communicate     control:         content: socket-directory         interface: content         target: $SNAP_DATA/sockets         default-provider: wifi-ap  slots:     entouch-srvr:         content: socket-directory         interface: content         write:             - $SNAP_DATA/socks
<ogra_> heh
<zyga-suse> tpatel: perhaps pastebin that
<ogra_> yeah ...
<zyga-suse> it's hard to read this way
 * ogra_ recommends paste.ubuntu.com
<tpatel> zyga-suse: sorry this is my first time using this chat so not familiar with all the lingo. what is pastebin?
<zyga-suse> tpatel: that's fine, it is a service that you can use to paste stuff into irc with nicer effects
<ogra_> tpatel, http://paste.ubuntu.com/
<zyga-suse> tpatel: go to paste.ubuntu.com and copy your stuff there
<zyga-suse> submit that
<zyga-suse> and give us a link
<ogra_> and give us the resulting url
<ikey> cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_qJM9hP//lib/modules: Permission denied
<tpatel> heres ithe link http://paste.ubuntu.com/25290702/
<ikey> soo close
<flavianmanea> @morphis__: I see that I have under /usr/sbin - unsquashfs and mksquashfs (And I guess that I already have them installed, so I can drop this dependency). Thank you!
<nothal_> flavianmanea: No such command!
<zyga-suse> ikey: maybe missing mount mediation or more directory differences, not sure
<ogra_> flavianmanea, no, you want to check /proc/filesystems
<arm1e> ogra_: holy crap it might have worked
<arm1e> seems to have built
<ogra_> flavianmanea, the tools in /usr/bin are just the userspace tools, not the kernel bits
<tpatel> zyga-suse: as you can see in this http://paste.ubuntu.com/25290702/ link there is entouch-srvr slot which is auto-connected to plug control. I dont want that to happen
<zyga-suse> tpatel: are those on the same snap?
<ogra_> flavianmanea, grep squash /proc/filesystems ... if that returns "squashfs" you are fine
<ogra_> ogra@nanopi:~$ grep squash /proc/filesystems
<ogra_> 	squashfs
<ogra_> ogra@nanopi:~$
<ogra_> like this
<mup> PR snapcraft#1481 opened: cli: better error message for missing mksquashfs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1481>
<arm1e> gotta go but will be back later. Thanks again!!
<flavianmanea> Bad luck on my side, it seems that no squashfs pops up
<tpatel> zyga-suse: Yes, they are defined in same snap. But plug control is needed to connect to slot wifi-ap:control and not to :entouch-srvr
<ogra_> flavianmanea, then you want to build the kernel module
<zyga-suse> tpatel: could you call them something else then, give them different content attribute?
<ikey> cannot mount tmpfs at /tmp/snap.rootfs_2R3Okt/var/lib/snapd/lib/gl: Permission denied
<ikey> lol the nvidia arch stuff is falling apart :p
<tpatel> I do have them with different name.
<zyga-suse> tpatel: I mean different content attribute name
<zyga-suse> ikey: you can do a quick "broad fix" to allow arbitrary mount
<zyga-suse> ikey: the apparmor rule is just "mount," AFAIR
<zyga-suse> (for snap-confine)
<ogra_> ikey, is your snap-confine suid root ?
<ikey> ya
<tpatel> zyga-suse: Can you send me a link where I can find other content type
<zyga-suse> ogra_: it is, this is apparmor getting in the way
<ogra_> ah
<ogra_> evil apparmor
<zyga-suse> tpatel: content type is just a string
<ikey> is there another permission for remount>?
<zyga-suse> tpatel: you can call it whatever you want
<zyga-suse> ikey: remount? no I don't think so
<ikey> cannot remount /tmp/snap.rootfs_wE0ycY/var/lib/snapd/lib/gl as read-only: Permission denied
<tpatel> zyga-suse: Ok. Let me try that.
<ikey> lol
<tpatel> zyga-suse: thanks
<zyga-suse> ikey: hmm
<ikey>     mount fstype=tmpfs none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,
<ikey>     mount options=(remount,ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,
<ikey> made it "go"
<ikey> but now my libGL is broken
<ikey> and wasnt in 2.26
<flavianmanea> Thanks guys for your help, gotta run. bye
<ikey> it wasnt trying to mount a tmpfs there before so i wonder if its actually bork
<mup> PR snapd#3713 closed: osutil: ensure TestLockUnlockWorks uses supported flock <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3713>
<mvo> jdstrand: can I get a minimal version of 3715 for 2.27? or is all of it needed?
<mvo> jdstrand: if we need it all, then thats fine, we just need to make sure to squash merge it so that the cherry pick to 2.27 is easier
<mvo> zyga-suse: looks like fedora is still in an unhappy state, anything new here? can't land the 2.27.1 prs currently it seems
<ikey> bash-4.3$ ls -la
<ikey> ls: cannot open directory '.': Permission denied
<ikey> bash-4.3$
<ikey> ugh
<ogra_> WOW ... so playing with libcomposite on a board can actually hard-kill systemd
 * ogra_ wants upstart back ... sniff
<mup> PR snapcraft#1482 opened: ci: skip the CLA check for pull requests from the bot <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1482>
<ikey> so all my --shell's now have no read permissions..
<zyga-suse> mvo: hmm, noop
<zyga-suse> ikey: pwd?
<ikey> bash-4.3$ cd /
<ikey> bash-4.3$ ls
<ikey> ls: cannot open directory '.': Permission denied
<ikey> bash-4.3$
<zyga-suse> ikey: that is correct
<zyga-suse> ikey: so far at least
<zyga-suse> ikey: cd $HOME
<ikey> so why have a shell that cant read or do anything..?
<zyga-suse> ikey: it can, it depends on the path obviously
<ikey> oh its stuck to home.. gotcha
<ikey> ok so my "libGL no longer works" issue is still there :/
<zyga-suse> ikey: any apparmor denials?
<zyga-suse> ikey: I suspect you will need to open up a lot of stuff in /var/lib/snapd/hostfs/ to allow the userspace distro driver to load
<ikey> Aug 11 16:49:59 ironhide love[6211]: <audit-1400> apparmor="DENIED" operation="open" profile="snap.mrrescue.mrrescue" name="/var/lib/snapd/hostfs/usr/lib64/glx-provider/nvidia/libGL.so.384.59" pid=6211 comm="love" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<ikey> ah.
<ikey> cuz solus is weird.
<ikey> and symlinks resolve
<ikey> merci :P
<zyga-suse> yes
<zyga-suse> should be easy-ishj
<ikey> damn solus xD
<mup> PR snapcraft#1483 opened: lxd: path cannot have extra forward slashes <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1483>
<zyga-suse> mvo: no idea what is going on, running some experiments again
<ogra_> ikey, just switch to slackware
<ikey> k done
 * ikey is on slackware
<ogra_> hah
<zyga-suse> ikey: NOTE
<zyga-suse> ikey: those things you are experiencing now
<zyga-suse> ikey: those need to be patched in interfaces/builtin/opengl.go
<zyga-suse> ikey: not in snap-confine's location
<ikey> o
<zyga-suse> ikey: the profile applies to the snap "mrrescure"'s app called "mrrescue"
<zyga-suse> ikey: if this snap uses the opengl plug
<ikey> ooo i c it
<zyga-suse> ikey: (it probably does)
<zyga-suse> ikey: then those extra confinement features should be adjusted for that interface
<ikey>   /var/lib/snapd/hostfs/usr/lib64/glx-provider/** rm,
<ikey> looks legit
<zyga-suse> yep
<kalikiana> Saviq: Seems like you hit a LXD bug https://github.com/snapcore/snapcraft/pull/1483
<mup> PR snapcraft#1483: lxd: path cannot have extra forward slashes <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1483>
<ikey> interfaces are cool. :]
<zyga-suse> :D
<zyga-suse> indeed they are
<zyga-suse> powerful concept
<ikey> like they literally give permissions..
<zyga-suse> yep
<zyga-suse> they can do a few more things :)
<tpatel> zyga-suse: same content-name was the issue.
<zyga-suse> tyhicks: \o/
<Saviq> kalikiana: hah, it did start working for me at one point after I've edited that out ;)
<Saviq> just didn't pay attention enough to see that's what fixed it :)
<zyga-suse> tpatel: \o/ :D
<jdstrand> mvo: the only thing that is needed is the change to unity7/x11. the others should commit fine and would only help people
<kalikiana> Saviq: you mean you changed the path yourself?
<Saviq> yes via `lxc edit`
<ogra_> popey, next attempt http://people.canonical.com/~ogra/snappy/nanopi-air.img.xz
<jdstrand> mvo: they aren't strictly required, but only add more access (ie, won't regress)
<ogra_> ogra@nanopi:~$ ls /snap/linux-generic-allwinner/5/firmware/brcm/*txt
<ogra_> ogra@nanopi:~$
<ogra_> bah
<ogra_> /snap/linux-generic-allwinner/5/firmware/brcm/brcmfmac43430-sdio.txt
<tpatel> how can I request auto-connection of core plugs like firewall-control, hardware-observe, network-control, ppp etc.
<zyga-suse> tpatel: request an assertion from the store
<zyga-suse> tpatel: I think you just have to add them
<zyga-suse> tpatel: and then upload to the store
<zyga-suse> and open a forum topic
<kalikiana> Saviq: Ah, didn't even think of that. I've always used commands like 'lxc device add', and that breaks irrepairably here...
<Saviq> kalikiana: yeah `lxc edit` is a good friend :D
<tpatel> zyga-suse: i have snap-declaration.json file which has all the details about plugs, slots, refresh-control from which I created snap-declaration assert locally. How can i upload that?
<zyga-suse> tpatel: you cannot, only store can do that
<zyga-suse> tpatel: you cannot sign it specifically
<zyga-suse> tpatel: please open a forum topic
<kalikiana> Saviq: Maybe I should look into using it from Snapcraft as well so containers don't need to be re-created in cases like this. It seems it takes stdin as well
<tpatel> zyga-suse: ok. I will open a forum topic
<ikey> :o ..
<ikey> https://ibin.co/3WWmTJWule4u.png
<ogra_> play it !
<ikey> oh i died already
<ikey> lol
<ogra_> lol
<zyga-suse> ikey: any denials? :-)
<ikey> Aug 11 17:00:32 ironhide love[1992]: <audit-1400> apparmor="DENIED" operation="open" profile="snap.mrrescue.mrrescue" name="/sys/devices/platform/i8042/serio2/input/input12/capabilities/ev" pid=1992 comm="love" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<tpatel> zyga-suse: I dont see any option to request assertion from my store account. I have opened a forum https://forum.snapcraft.io/t/request-for-plug-auto-connection-on-et-gw/1651
<ikey> quite a few denials but i can deal with those tomorrow â¢
<jdstrand> fyi, that denial is either a bug in the snap or the security policy, not your system
<zyga-suse> tpatel: thank you!
<ikey> yeah i figured
<ikey> cheers though
<ogra_> ikey, snap connect mrrescue:joystick
<niemeyer> cachio: That just means machines are in use
<ogra_> i guess
 * ikey hasn't got a joysti..
<ikey> i dont think?
<cachio> niemeyer, ok
<ogra_> nom but connecting the interface will likely make the denial go away
<niemeyer> cachio: We have 29 machines powered off right now
<niemeyer> That's enough for another full suite run
 * zyga-suse steals one
<zyga-suse> jdstrand: could those be missing/out-of-date abstractions?
<cachio> niemeyer, good
<cachio> zyga-suse, did you do any progress with the issue preparing fedora?
<zyga-suse> cachio: no but I'm still actively trying
<zyga-suse> cachio: trying more brute force now, maybe it will fix  it
<cachio> zyga-suse, ok, tx
<jdstrand> zyga-suse: not that denial, no
 * jdstrand steps away for a bit
<zyga-suse> aha, ok
<zyga-suse> jdstrand: o/
<Saviq> kalikiana: not sure, you'd have to mangle the string you get from lxc... IMO better to use the CLI and blame lxd for issues
<zyga-suse> Pharaoh_Atem: around?
<ikey> zyga-suse, how evil would it be to bind mount /usr/share/themes + /usr/share/icons into the target?
<zyga-suse> ikey: mmmm, not sure, may be evil
<zyga-suse> are you looking to adopt theming from the host?
<ikey> basically yeah
<zyga-suse> I'd rather not as we are working on a large and comprehensive theme support
<zyga-suse> (~3-5 months out)
<zyga-suse> and a simple approach won't really work
<ikey> on the plus side, more complex apps are now working..
<ikey> https://ibin.co/3WWs63sWMwix.png
<zyga-suse> woah, really nice
<zyga-suse> which app is that?
<ikey> "brave" browser
<ikey> only has --beta
<zyga-suse> nice :D
<zyga-suse> how do you like channels so far?
<ikey> makes sense tbh
<ikey> lets devs get feedback and stage features without hitting production systems
<ikey> and the 1% to run bleeding edge
<zyga-suse> ikey: if you are interested in that, try the http snap
<zyga-suse> I think the beta channel has some tab completion features
<ikey> installed it, whassit do?
<zyga-suse> ikey: it's a simple debugger for http
<zyga-suse> we use it to talk to snapd sometimes
<zyga-suse> if you packaged bash tab completion correctly
<zyga-suse> in bash
<zyga-suse> you should get http -<tab><tab> to work
<ikey> not yet and i dont use bash either
<zyga-suse> aha
<ikey> i also need to set up the environment file
<zyga-suse> right I know that, just saying this is a part of the snapd package
<zyga-suse> there are two files for that
<ikey> should i just put /snap/bin into global PATH?
<zyga-suse> or three, lost track
<zyga-suse> yes, please
<ikey> sweet
<ikey> any XDG cruft..?
<zyga-suse> yes
<zyga-suse> look at ...
<ikey> hello /var/lib/snapd/desktop/applications
<ikey> ok ill include that into global xdg too
<ikey> then we can have working menus..
<ogra_> http://paste.ubuntu.com/25291252/
<ogra_> thats what snapd ships in ubuntu
<zyga-suse> I think this is a bit messy today but you want to set XDG_DATA_DIRS, grep for that in packaging/
<zyga-suse> I think we need to streamline this a little
<tpatel> Is there any pre-install script to we can run like configure which runs after install?
<ikey> yeah we can do this in solus in /usr/share/defaults/etc/profile.d/someThingy.sh
<zyga-suse> tpatel: yes
<tpatel> zyga-suse: which one?
<zyga-suse> tpatel: install, I believe :D
<ShalokShalom> hi there
<ShalokShalom> i have some questions
<zyga-suse> ikey: that should (after logging out) give you working desktop files
<ikey> noice
<ShalokShalom> hi ikey :)
<ikey> heya
<tpatel> zyga-suse: should it be installed under hooks?
<zyga-suse> mvo: so about fedora
<ShalokShalom> So:
<ogra_> ikey, profile.d is sourced by the display manager/ graphical session  in solus ??
<ShalokShalom> Can apps get isolated, so they dont interference with each other?
<zyga-suse> mvo: running a few times I sometimes just pass
<ShalokShalom> Whats about sharing the ressources?
<ikey> ogra_, the global is
<ogra_> typically thats only for shell
<zyga-suse> mvo: and sometimes fail on not being able to download a specific package
<ikey> because lightdm is a twit
<ikey> we have to make it source globally
<ShalokShalom> I currently make a comparsion sheet of all the currently available package managers
<ogra_> well, we dont have that in ubuntu ...
<ikey> you guys dont know how to do vanilla :P
<ikey> with all due respect xD
<zyga-suse> ShalokShalom: can you be more specific please
<ikey> and systemd janked up any possibility of puritan logins anyway.
<ShalokShalom> in which context?
<zyga-suse> ShalokShalom: normally each snap is isolated from all the other snaps
<ShalokShalom> so, for which question?
<ogra_> well, lightdm is an ubuntu invention ... if its not us doing "vanilla" who is ? :)
<ShalokShalom> ok, fine
<ikey> ogra_, nah - everything *around* it :P
<ogra_> heh
<ikey> dont make me point you at your packages
<ikey> lol
<ShalokShalom> and rollback is also supported, yeah?
<ogra_> ikey, i dont care so much for packages anymore, i care for snaps nowadays ;)
<zyga-suse> ShalokShalom: depending what you mean but we have a revert feature
<ShalokShalom> so, can Snappy also produce artifacts, like traditional package managers?
<ikey> they are packages
<ikey> >_>
<ogra_> well ... they are gold :)
 * ikey meant that to ogra_ not ShalokShalom 
<ShalokShalom> zyga-suse: i like to roll back to an old version of a package
<zyga-suse> ShalokShalom: artifacts?
<zyga-suse> ShalokShalom: I see
<ShalokShalom> can it share ressources?
<zyga-suse> ShalokShalom: if you are the developer of the snap you can refresh or rollback to any revision
<zyga-suse> ShalokShalom: if you are not the developer of that snap you can only refresh or rollback to a revision you have on your system
<ShalokShalom> so, if i use 2 snappy packages, doe they share ressources?
<zyga-suse> ShalokShalom: which resources are you referring to?
<zyga-suse> it's too vague to answer
<ShalokShalom> zyga-suse: of course
<ShalokShalom> i mean for stability reasons
<zyga-suse> ShalokShalom: you can also refresh to any channel the developer has created
<ShalokShalom> shared libs
<zyga-suse> ShalokShalom: each snap shares its base snap (e.g. the base core snap)
 * ikey contemplates making /usr/share/Xsession.d a thing
<zyga-suse> ShalokShalom: but otherwise is standalone and does not share anything with other snaps or the system itself
<ShalokShalom> i mean, when i use x for y and z
<ShalokShalom> two loads of x in RAM?
<zyga-suse> ShalokShalom: yes
<ShalokShalom> so each snap loads all depends for itself?
<zyga-suse> ShalokShalom: unless that is coming from the core snap
<zyga-suse> ShalokShalom: so once filesystem
<ShalokShalom> what is the core snap?
<ogra_> well, or you use a content interface
<zyga-suse> ShalokShalom: so one inode and one copy
<ShalokShalom> in practice
<zyga-suse> ShalokShalom: it's the snap that implicitly acts as the root filesystem of all the other snaps
<ShalokShalom> you like to stand a full desktop on snappy?
<zyga-suse> ShalokShalom: it contains a number of applications
<ShalokShalom> aha
<zyga-suse> ShalokShalom: and a number of libraries
<zyga-suse> ShalokShalom: but is otherwise small and "embedded"ish
<ShalokShalom> and can contains so much as it like?
<ShalokShalom> so, can i build a full desktop on it?
<zyga-suse> ShalokShalom: if you can package the whole desktop in a snap, yes
<ogra_> if you are the developer of x y and z you can make y and z use libs from x via the content interface ... that ojnly works for the same developer though
<zyga-suse> ultimately yes but it may not be easy
<ikey> and arguably a desktop is part of the OS experience, and should be kept separate
<ikey> OS/Data/Apps
<ogra_> well
<ogra_> depends
<ikey> Unless you're hot into phablets.
<zyga-suse> I think both viewpoints are valid
<zyga-suse> yep
<zyga-suse> ShalokShalom: I think currently nobody has attempted that AFAIK
<ShalokShalom> ok i see
<zyga-suse> ShalokShalom: but some desktop environment devs are experimenting with packaging more and more of their stack this way
 * ogra_ could imagine an lxqt snap on top of mir-kiosk on an ubuntu core image ... 
<ikey> inb4 snudgie.
<ShalokShalom> do you agree with this list? http://funkyimg.com/i/2wjbr.png
<ikey> me thinks them some loose misleading terms
<ogra_> ShalokShalom, snaps use deltas
<ShalokShalom> aha, ok fine
<ShalokShalom> by default?
<ogra_> not sure what "artifacts" are supposed to be
<ikey> and you can get deltas on debian. its just external and weird
<zyga-suse> ShalokShalom: sorry this is to vague to answer
<ShalokShalom> no containers
<zyga-suse> ShalokShalom: can you start with a legend that explains what you mean by each
<ShalokShalom> its the opposite, like in traditional package managers
<ogra_> ShalokShalom, depends ... on desktop and server installs by default, on ubuntu core images not
<ShalokShalom> zyga-suse: yep, i think so too
<ikey> this chart is kinda comparing apples and oranges
<ShalokShalom> ikey: so practically no
<ikey> snaps and traditional package managers have different uses
<ShalokShalom> while its interesting to know, thank a lot
<ShalokShalom> ikey: not for me
<ShalokShalom> imho, both should be convered
<ogra_> (ubuntu core is typically running on low power devices, so deltas are possibly eagting your CPU there)
<ShalokShalom> Habitat can do it
<ikey> well then you dont get it like i do :P
<ikey> snaps basically means "i can run stuff outside the confines of the OS from the random internet and run it safely"
<ogra_> *eating
<ShalokShalom> yeah, probably ikey
<ikey> OS doesnt break snap, snap doesnt break OS
<ikey> snap can come from anywhere, and as such, is shielded
<zyga-suse> ikey: yes, that's really key
<ikey> package manager is very much a traditional OS deployment thing
<zyga-suse> decoupling of the os from all the apps
<ikey> i.e. glorified tarballs
<ShalokShalom> ikey: Habitat means "i can run stuff outside the confines of the OS from the random internet and run it safely and as commonly known.
<ShalokShalom> you can do both
<ikey> why are you explaining back to me that which im explaining to you - given you've the questions, not the answers? :P
 * ikey feels Friday has drawn to a close
<ShalokShalom> ?
<ShalokShalom> i expanded it
<ShalokShalom> read the full line ;)
<ikey> i cant english anymore, sorry. lol
<ShalokShalom> all fine
 * ikey disappears in the direction that doesn't have apparmor in it
<ShalokShalom> any more important points, who make a package manager?
<ShalokShalom> next to "easy to write build scripts"
<ikey> (transactions)
<ShalokShalom> in the sense of?
<ogra_> ShalokShalom, take a look at snapcraft
<ShalokShalom> ok
<ShalokShalom> i was already there
<ogra_> (regarding packaging)
<ikey> i.e. applying a transactional upgrade, something goes boom, and its peeled off
<ikey> RPM distros do this
<ikey> (well the not insane ones)
<zyga-suse> ikey: snapd also keeps a copy of app data
<ikey> ((hi yocto.))
<zyga-suse> ikey: so we can really undo everything
<ikey> ah nice
<ikey> just using hardlinks ?
<zyga-suse> ikey: and transactions are waaaay faster because, well, we mount apps
<ogra_> and auto-rollback :)
<zyga-suse> ikey: no, we copy the old way for now
<ogra_> dnt forget about that  :)
<ikey> nice
<zyga-suse> (though we may take advantage of some things later on)
<ShalokShalom> can Snappy run standalone?
<ikey> btw ive not looked at the snap format
<ikey> is it deduped?
<zyga-suse> ikey: we also have "data common across revisions" if app is willing to take the risk of managing itself
<ogra_> ShalokShalom, standalone ??
<ikey> ah nice
<zyga-suse> ikey: not across snaps
<ikey> nah internally
<ShalokShalom> without any other package manager
<ogra_> yes, that is what Ubuntu Core does
<ikey> like are files deduplicated within a single snap
<zyga-suse> ikey: internally I think squashfs does this but I don't think it's a very important feature since there's hardly any duplication in typical snap[s
<ikey> gotcha
<ogra_> on Ubuntu Core the kernel, bootloader and rootfs are snaps
<zyga-suse> ikey: though don't quote me, I'd have to check
<ikey> yeah no worries
<zyga-suse> ikey: one interesting thing is that snaps are compressed
<ogra_> there is no other package manager provided
<ikey> iirc squashfs does poke the inodes themselves
<zyga-suse> so they end up much smaller than typical package for both download and at runtime
<ikey> zyga-suse, depends how you define "typical package"
<ShalokShalom> host snappy all the infos about the apps in itself?
<ShalokShalom> or is something in the OS?
<ogra_> ShalokShalom,
<ogra_> ogra@nanopi:~$ apt
<ogra_> Ubuntu Core does not use apt-get, see 'snap --help'!
<ogra_> ogra@nanopi:~$
<ikey> the internals of all solus eopkgs are install.tar.xz which is basically the same as xz -6
<zyga-suse> ikey: I didn't do any hard measurements but I would be surprised to win a lot on de-duping files that are not just copies
<ShalokShalom> ogra_: and this is also suitable for a full blown OS?
<zyga-suse> (not perfect copy)
<ikey> problem is the deltas are a bit more tricky because of the install.tar.xz ...
<ShalokShalom> what Ubuntu Core does
<ShalokShalom> standalone PM
<ikey> instead of a hash-indexed binary with stream compression which could dedupe and delta ...
<zyga-suse> ikey: snapd uses several different deltas (we can add more later)
<ikey> noice
<zyga-suse> ikey: and once we get incremental builds, deltas will be even nicer
<ogra_> ShalokShalom, sure, it is a product canonical makes money off :)
 * ikey has poor-mans-deltas
<ShalokShalom> which means?
<zyga-suse> ikey: we also plan to use squashdelta for computing deltas that are aware of the squashfs compression
<ShalokShalom> why poor-man?
<ogra_> ShalokShalom, its a standalone OS
<ikey> i.e. x->y = z(y[new])
<ShalokShalom> because they cant effort bandwidth?
<ikey> zyga-suse, ah handy enough yeah
<ShalokShalom> ogra_: with a desktop and all?
<zyga-suse> ikey: so really a lot of optimization can be done but it is not hard, just something we need to sit on and do
<ogra_> ShalokShalom, no, for IoT and server use ... but you could snap up a desktop indeed
 * ikey gets meta and snaps snapd
<zyga-suse> ikey: that's done, it's in the core snap :D
<popey> ogra_: testing!
<ikey> lol yeah saw that
<ogra_> ShalokShalom, think libreelec ... fritzos ... etc  ...
<zyga-suse> ikey: and as we work on base snaps we will shrink the core snap to just contain snapd
<zyga-suse> and move the base filesystem to a new base snap
<zyga-suse> (or the other way around)
 * ikey looks forward to having his own base snap :p
<zyga-suse> but there will be separate snaps for base rootfs
<zyga-suse> and for "just ship snapd"
<ikey> oh btw do I gotta sell my soul (sign CLA) to send you PRs?
<zyga-suse> ikey: yeah, you can kind of do that now
<zyga-suse> ikey: just with master
<ogra_> ShalokShalom, but as i said above already, technically you could package lxqt and run that on top of the mir-kiosk snap and have a full desktop
<ogra_> practically nobody did that yet
<zyga-suse> ikey: I think so, but if you send us tiny (trivial) PR I think we don't need a CLA legally
<zyga-suse> but please sign it
<zyga-suse> it's much easier for us
<ikey> but my soul
<ikey> lol
<zyga-suse> we have cookies
<ikey> well you do make a good argument
<ogra_> yummy cookies
<ikey> hm the CLA changed
 * ikey remembers the old one
<ogra_> ShalokShalom, the point of core is that it can not break ... (kernels, and rootfs updates do auto-selftests after upgrades and automatically roll back to the former working version etc ... such a device is always on and working)
<ogra_> thats what snap packages provide us ...
<ikey> how do i sign the magical web form xD
<ogra_> use your wand
<ogra_> :P
<ikey> damn knew i left something at work
<popey> ikey: you have the url?
<ogra_> <ShalokShalom> ikey: Habitat means "i can run stuff outside the confines of the OS from the random internet and run it safely and as commonly known.
<ikey> yeah i got it downloaded
<ogra_> ShalokShalom, snaps can do that as well ... we call that "classic snaps"
<ShalokShalom> ok, fine
<ShalokShalom> so its possible to create 'artifacts'
<ikey> but unsurprisingly it turns out evince still sucks..
<zyga-suse> hehe
<ogra_> ShalokShalom, i have no idea what artifacts is supposed to mean
<zyga-suse> well
<ikey> and instead spent years of development energy on populating the titlebar until the point i cant move the damned window
<ShalokShalom> classic snaps
<zyga-suse> there are some very nice email clients in a snap I hear
<ShalokShalom> so not containers
<ShalokShalom> classic packaging
<zyga-suse> ShalokShalom: can you define artefacts please
<zyga-suse> ShalokShalom: incidentally we do have snaps that use classic (aka: none) confinement
<ShalokShalom> see above
 * ikey moves that we call them snackages
<ShalokShalom> opposite of isolated containers
<zyga-suse> ShalokShalom: that also don't run on top of the core snap
<ShalokShalom> hehe
<zyga-suse> ShalokShalom: but instead run on top of the distro itself
<zyga-suse> ShalokShalom: atom is a very common one
 * ogra_ takes a bite from ikey's snackage
<ikey> lol
 * zyga-suse wants a snack now
<zyga-suse> darn you guys
<zyga-suse> it's too hot to think and now I'm also hungry ;D
<zyga-suse> ShalokShalom: as another interesting example, try my python0 snap
 * ikey pleads the fifth
<zyga-suse> ShalokShalom: it contains a very old version of python compiled as a classic snaps that I assert will work anywhere
<zyga-suse> ShalokShalom: even though it sees the full extend of the host filesystem
<ogra_> ShalokShalom, if you get a tarball with all libs included from an ISV and unpack that to /opt ... thats kind of similar to classic (just that the execution is still snandboxed but allows access to the host)
<zyga-suse> ShalokShalom: and for distros like solus, where even the dynamic linker is in some unusual (sic) place, it works
<zyga-suse> ogra_: very lightly sandboxed, apparmor is in allow anything mode and seccomp is off
<zyga-suse> ShalokShalom: classic confinement is based on trust and good will of developers
<zyga-suse> ShalokShalom: and is regulated by the store
<ogra_> zyga-suse, sue, but it is still actually running inside the core snap
<zyga-suse> ShalokShalom: nobody can just upload a snap like that and trick users into installing it
<zyga-suse> ogra_: classic confinement snaps? no, they run on the real fs
<ShalokShalom> "classic confinement is based on trust and good will of developers" > Oh, that will fail
<ShalokShalom> That will SO fail :D
<ogra_> doesnt
<zyga-suse> ShalokShalom: it is *exactly* like a curated archive
<ShalokShalom> just joking
<zyga-suse> ShalokShalom: where we get most of our software today
<ogra_> since it still needs a full security review on upload
<ShalokShalom> yeah, i know
<zyga-suse> ShalokShalom: just the format is different
<ShalokShalom> thats what i mean
<ShalokShalom> of course
<ogra_> a "normal"" snap can always get auto-uploaded ... the interfaces shield the OS from everything evil it could do
<ikey> hmph
<ikey> edit pdf - text doesnt stay
<ogra_> classic snaps azutomatically get blocked on upload until a human reviewer approves it
<ogra_> (because they dont use the interface concept)
<mup> PR snapcraft#1484 opened: lxd: configure user in container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1484>
<jjohansen1> zyga-suse: hrmmm, that is unfortunate. artful is going to be moving to a 4.14 based version in a week or two
<ikey> heh, meta. fill out in chrome, "print" to PDF..
<zyga-suse> jjohansen1: hey!
<zyga-suse> ikey: I think you want to sort out the kernel details with jjohansen1 now :)
<zyga-suse> good to see you again jjohansen1 :)
<jjohansen1> hey zyga
<ikey> oh kernel is basically done :P
<jjohansen1> zyga: so I did respond on the CONFIG Q, yesterday
<ikey> 4.9 will be the next struggle..
<popey> ogra_: http://imgur.com/a/yszdI :(
<jjohansen1> ikey, nothing wrong with going with the zesty/current artful version however, artful is going to switch to a newer version based on 3.14 in a week or two is all
<popey> http://imgur.com/a/OALxD
<ikey> jjohansen1, ive taken from artful master-next
<ikey> and i can rebase it in due course
<ogra_> popey, well, you know the drill ... syslog please ... that kernel snap should definitely have the firmware now
<jjohansen1> ikey: also, there is a backport tree, the 4.13 backport if currently at 4.10, if you wait a week or so, I will have a 4.9 backport done
<popey> kk
<ogra_> i was convinced it would work :(
<ikey> so i looked at 4.13->4.12 backport which isnt complete
<ikey> it only has the stuff going upstream
<jjohansen1> ikey: yes I know, however the kt has an unstable tree, with 4.13 in it
<jjohansen1> it will be switching to that for artful, and it will have some 4.14 patches, and possibly a couple others
<ikey> ah ok
<popey> Aug 11 11:00:11 localhost kernel: [   18.809931] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.txt failed with error -2
<popey> ogra_: http://paste.ubuntu.com/25291548/
<ogra_> boo
<ikey> ok sent my soul attached to a PDF..
<ogra_> popey, very weird i definitely have that file in linux-generic-allwinner rev 5 here (which this image should use)
<ogra_> ogra@nanopi:~$ ls /snap/linux-generic-allwinner/5/firmware/brcm/*txt
<ogra_> /snap/linux-generic-allwinner/5/firmware/brcm/brcmfmac43430-sdio.txt
<ogra_> ogra@nanopi:~$
<ogra_> OH!
<ogra_> ogra@nanopi:~$ ls /lib/firmware/4.11.0-13-generic/brcm
<ogra_> ls: cannot access '/lib/firmware/4.11.0-13-generic/brcm': No such file or directory
<ogra_> ogra@nanopi:~$
<ogra_> so the snap has it ...
<ogra_> but something is wrong with the bind-mount to /lib/firmware
<ikey> read permissions? :P
 * ikey kids but is still partially traumatised by today.
<ogra_> ah, no ... silly me
 * ogra_ was looking one level to deep :P
<ikey> lol
 * ikey hands ogra_ https://www.youtube.com/watch?v=emGri7i8Y2Y
<ogra_> heh
<popey> ogra_: soooo, wait for a rebuild?
<ogra_> popey, ls /writable/system-data/snap/linux-generic-allwinner/
<popey> or do you mean you don't know yet what's busted?
<ogra_> do you see a 5 in there ?
<popey> no
<popey> 2 and current
<ogra_> i have the feeling you got the wrong kernel snap in that image (i hate that ubuntu-image doesnt print the versions when building)
<ogra_> popey, oh, wow
<ogra_> popey, thats what we tested this morning :O
 * ogra_ re-builds the img ... will take a moment
<popey> eeb3f8d53bd3e2a717a251944eb3a0fa  nanopi-air.img
<popey> thats the most recent one I tested
<popey> md5sum
<popey> haaaaang on
<popey> could be pilot error
<zyga> so, I want a synergy snap please
<zyga> but I think we need support for user session services first
<zyga-suse> mvo: running fedora repeatedly I don't see the failure
<mvo> zyga-suse: hm, let me rerun the test then
<zyga-suse> mvo: so I'd say that something may be failing at the network level
<zyga-suse> mvo: and not at the level of some stale cache
<popey> wheee, dding again, wifey is gonna be late for dinner now :D
<zyga-suse> mvo: still inconclusive though
<zyga-suse> mvo: but yes, re-running might be a good idea
<mvo> zyga-suse: maybe it was a hickup on their servers
<zyga-suse> mvo: thank you for staying on Friday to work on this :)
<mvo> zyga-suse: yeah, I want the 2.27 fixe
<mvo> ss
<zyga-suse> mvo: I saw it once
<zyga-suse> and then I re-run (inside the debug shell)
<zyga-suse> I re-run the same dnf install and it worked
<zyga-suse> so :/
 * zyga-suse wants 2.27.1 too :)
<mvo> zyga-suse: ok, retriggered and will see how it goes
 * mvo gets dinner
<jdstrand> mvo: so do you want a cherrypick?
<zyga-suse> fingers crossed
<zyga-suse> I'm still running it in a loop
<jdstrand> mvo: I don't think it is needed, but if you do, I'll do it
<mvo> jdstrand: its fine, I can squash-merge and cherry pick the entire commit into 2.27
<popey> ogra_: is this the smallest device so far to run ubuntu core?
<popey> NDAs aside ;)
<ogra_> popey, physical size wise, yeah
<popey> nice
<jdstrand> mvo: from my perspective, that is perfect
<ogra_> regarding power the beaglebone is still the smallest
<jdstrand> mvo: thanks! and sorry for not commiting that sooner
<ogra_> (800MHz single core, 256M )
<popey> scrolled back in console...
<ahoneybun> and one know how to get LP to build a snap?
<mvo> jdstrand: thanks, waiting for tests, then I will cherry pick
<ahoneybun> I don't have the option here: https://launchpad.net/kubuntu-manual
<popey> [   26.613572] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
<popey> [   26.642154] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
<zyga-suse> ahoneybun: you can use a snap recipe
<zyga-suse> ahoneybun: but many people just use build.snapcraft.io
<mup> Issue snapcraft#1485 opened: Make script aware of 407 when downloading gradle <Created by koppor> <https://github.com/snapcore/snapcraft/issue/1485>
<ogra_> ahoneybun, not in the toplevel, you need a source tree
<ogra_> popey, oooh !
<ogra_> popey, and console-conf ?
<ahoneybun> ogra_: source tree?
<popey> http://paste.ubuntu.com/25291629/
<popey> lots of stuff whizzing by
<ogra_> ahoneybun, yeah, something with a snapcraft.yaml
<ahoneybun> https://git.launchpad.net/kubuntu-manual/tree/
<ahoneybun> so I need a .yaml file for LP to see it as an option?
<ogra_> popey, oh my
<popey> yeah, can't see console-conf now
<ogra_> ahoneybun, https://code.launchpad.net/~aaronhoneycutt/kubuntu-manual/+git/kubuntu-manual/+ref/master
<popey> too much spam
<popey> back in an hour or so, need to take wifey to dinner
<ogra_> ahoneybun, you can click the "create snap package" button on there ... but to build a snap you need a snapcraft.yaml
<ahoneybun> all got to click a branch for it to be there
<ahoneybun> got it
<ahoneybun> thanks ogra_
<ogra_> :)
<ahoneybun> I'm trying to get khelpcenter (kde doc thing) to handle our sphinx docs
<ahoneybun> it seems to handle docbook the most but sphinx does not export that
<mup> PR snapd#3720 opened: Add initial support for Solus <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3720>
<ikey> itshappening.gif
<zyga-suse> wooooot
 * zyga-suse reviews
<ikey> might be some janky that you dont like
<ikey> but only one way to find out
<ikey> lol
<ogra_> popey, once you are back ... full syslog please ... (though i might be gone then too, but i'll look at it over the weekend)
<zyga-suse> jdstrand: ^
<zyga-suse> ikey: reviewed
<ikey> why wouldnt we want libgcc_s .. ?
<zyga-suse> mmÂ¿
<ikey> "Same comment as above (may need pruning)
<ikey> "
<ikey> for libgcc_s and libapparmor
<zyga-suse> I wasn't thinking about libgc_s specifically
<zyga-suse> I just clicked there at random
<ikey> oh
<zyga-suse> the thing that hinted that this may be stale is libnih
<zyga-suse> which was only ever used by upstart
<zyga-suse> so unless you have upstart
<zyga-suse> then I don't think you need it
<zyga-suse> and then you probably don't need other entries
<zyga-suse> so let's check
<ikey> yeah i dropped nih + cgmanager
<ikey> libcap was needed because im doing dynamic link of libcap
<ikey> ok your comments have sod all context lol
<zyga-suse> that makes sene
<zyga-suse> *sense
<ikey> "I'm curious about those two rules, they look fine but I wasn't aware we need them or that we perform those operations.
<ikey> "
<ikey> which?? :P
<zyga-suse> so if you purned the list then +1 as I said
<zyga-suse> snapctl
<zyga-suse> and /usr/lib/snapd
<ikey> hm that might've come back from rebase
<ikey> lemme drop those two and see how she goes
<zyga-suse> I'm curious because /usr/lib/snapd is already definitely mapped
<zyga-suse> ah
<zyga-suse> wait
<zyga-suse> this may be from mvo's work
<zyga-suse> on bare base snaps
<zyga-suse> mvo: ^ a comment if you still have enrgy
<ikey> i think its an artefact of the rebase
<zyga-suse> *energy
<ikey> ill rebuild with the changes and reinstall/reload apparmor and see if it screams blue murder
<ikey> if not, suhweet
<ikey> yea golden
<ikey> -f pushed change
<zyga-suse> thanks
<ikey> brave and mrrescue being my new test apps
<ikey> lol
<zyga-suse> ikey: reviwed
<ikey> merci
<ikey> ah git
<ikey> i know how i ended up doing that
<ikey> from copying + editing:
<ikey>     /usr/lib/@{multiarch}/libseccomp.so* mr,
<ikey>     /lib/@{multiarch}/libseccomp.so* mr,
<zyga-suse> ahh
<zyga-suse> right
<ikey> like not *just* insane >_>
<ikey> (sorry xD)
<ikey> need me to change the commit message btw?
<ikey> saw the PR title edit
<zyga-suse> nah, that's fine
<zyga-suse> we are not that saint and holy :)
<ikey> :D
<zyga-suse> mvo: interestingly another run that goes on without failures
<zyga-suse> mvo: since we yank disks I don't think this is any specific node that is affected
<zyga-suse> mvo: but maybe I am mistaken and it's just one broken box spoiling our day
<zyga-suse> ikey: did you try to run tests?
<zyga-suse> ikey: go test ./...
<zyga-suse> or similar
<jjohansen1> ikey: btw the apparmor backport kernels are currently at git://kernel.ubuntu.com/jj/linux-apparmor-backports
<ikey> yeah its where i was at jjohansen1
<ikey> they were incomplete :)
<ikey> i.e. ubuntu domain patches
<ikey> zyga-suse, had massive pains trying to get test suite integrated into the pkg
<ikey> damn go vendoring
<zyga> ikey: that's fine
<jjohansen1> ikey: hrmmm, well incomplete in the sense that they don't yet got back further than 4.10, and that they don't have all the features, they are exactly what they claim 4.13 backports.  Once the 4.14 pull is out there will be a 4.14 backport and there will be 4.13+outoftree
<zyga> ikey: just wonder what happens when you clone master
<zyga> ikey: and run go test ./...
<zyga> and see what you get
<jjohansen1> ikey: anyways sounds like you are aware of where things are
<ikey> jjohansen1, yeah i mean i know they're 4.13 backports - but they're not "full" apparmor in the ubuntu sense :D
<ikey> i started off with your backport tree fwiw
<jjohansen1> ah
<ikey> https://dev.solus-project.com/R3571:43c64241912cc3bfc35a4299097e82b00e1f2cd6
<ikey> you can see the deleted patches
<jjohansen1> ikey: so 4.14 will be very close, it looks like I probably won't be able to land 1 feature
<ikey> because i had partial not strict confinement
<ikey> ah ok
<ikey> looks like solus will be spying on your kernels for a while then jjohansen1 :p
<jjohansen1> :)
<jjohansen1> ikey: just poke me if you need any help with any of it
<ikey> oh sure - thanks
<ikey> fwiw in the end I basically did: git rm -rf security/apparmor, cp -R $fromtheubuntukernel/security/apparmor security/. ; git add .
<ikey> and then ported the securityfs bits across and kept watching make on a defconfig
<ikey> until it was clean/error-free
<ikey> so it might not be pure but by god it frackin works :p
<jjohansen1> ikey: heh, that is how I recommend doing it, its just so much easier
<ikey> :D
<ikey> id rather carry one log across the stream then take it stick by stick ..
<ikey> how do i know i have the same log at the end? xD
<ikey> aw test failures
<zyga> show me please
<ikey> on the PR
<zyga> ah, looking
<ikey> little red angry crosses
<zyga> ikey: ah
<zyga> ikey: go to interfaces/builtin
<zyga> ikey: run go test
<zyga> ikey: it will fail
<ikey> opengl
<zyga> ikey: you want to fix that one place
<zyga> yep
<zyga> ikey: I suggest using one trick
<zyga> ikey: instead of c.Assert(..., Equals, ...) use testutil.Contains
<zyga> and just find the essentail part
<ikey> yea
<zyga> not the whole kitchen sink
<zyga> it should be nicer and convey the point more
<ikey> so when i run go test i have a billion things not found
<ikey> and y'all don't do git submodules
<zyga> no, it's just in one tree
<ikey> eh
<ikey> my CLI disagrees
<ikey> lol
<ikey> tests/lib/fakestore/store/store.go:34:2: cannot find package "gopkg.in/tylerb/graceful.v1" in any of:
<ikey> etc
 * ikey does the govendor thingy
<ikey> imagine how much nicer this would be with .gitmodules .. lol
<Pharaoh_Atem> please, don't encourage it
<ikey> would be so much more manageable than this govendor thing
<ikey> recursive clone, bam, done
<zyga> ikey: just ./get-deps
<zyga> that does it
<zyga> ikey: govendor is easy too, just different
<zyga> ikey: I don't mind it (govendor)
<Pharaoh_Atem> >_>
<ikey> snap/info_snap_yaml_test.go:822: undefined: snap.NewHookType
<Pharaoh_Atem> I wish I had overlay tarballs
<zyga> Pharaoh_Atem: go develop snapd without it ;) it's just a time saver
<ikey> this is a concussion of failures
 * Pharaoh_Atem guesses he'd have to make the overlay tarballs himself
<zyga> ikey: so, that's odd
<zyga> ikey: is this on master
<ikey> so your HACKING doc is telling me to use go get
<ikey> but i need git
<ikey> not got get'd crap
<zyga> ikey: I assume you set up all the go gooies okay (GOPATH and all that)
<ikey> because my changes is elsewhere
<ikey> well your tree is set up wonky
<ikey> you dont have src or src/vendor
<zyga> ikey: put your tree in $GOPATH/src/github.com/snapcore/snapd
<popey> ogra_: http://paste.ubuntu.com/25291916/
<ikey> so i cant set GOPATH=`pwd`
<Pharaoh_Atem> nope
<zyga> ikey: I never heard of that approach
<ikey> its standard ._.
<Pharaoh_Atem> zyga: it doesn't work
<zyga> ikey: (in fact, none go project I saw did that)
<ikey> many. many do
<ikey> only libraries use root level
<zyga> ikey: not saying it's wrong just unfamiliar
<Pharaoh_Atem> ikey: that's news to me
<Pharaoh_Atem> to date, I haven't see a Go package that works that way
<ikey> so if you need to be imported from another project, you use root level
<ikey> meet one https://github.com/solus-project/solbuild
<popey> ogra_: https://raspberrypi.stackexchange.com/questions/62722/pi-zero-w-wifi-interference-with-tty
<zyga> https://github.com/solus-project/solbuild/blob/master/.github/building.gif
<zyga> lol
<zyga> wat is that?
<ikey> solbuild
<zyga> I mean
<zyga> why do you keep the gif in the tree
<ikey> cuz its pretty
<ikey> and its in the readme
<ikey> lol
<Pharaoh_Atem> :)
<Pharaoh_Atem> I did something similar recently: https://blog.mageia.org/en/2017/07/21/dandifying-mageia-part-2/
<zyga> Pharaoh_Atem: about that, where is snapd mageia?
<Pharaoh_Atem> zyga: ask Akien :)
<zyga> well, I haven't heard from him
<ikey> k so
<ikey>  â î± ufee1dead@ironhide î° â¦/Projects/go î° ls src/github.com/snapcore/ -l
<ikey> total 0
<ikey> lrwxrwxrwx 1 ufee1dead ufee1dead 17 Aug 11 19:20 snapd -> ../../../../snapd
<ikey> now lets see if she goes
<ikey> zyga, feature request: make get-deps verbose plox
<zyga> plox?
<ikey> = pls/please
<Pharaoh_Atem> zyga: he hasn't been around lately, I'll poke him next time I see him
<zyga> ikey: pass -v to govendor sync
<ikey> ok test is finally going xD
<zyga> run tests across the tree to see what works and fails
<zyga> maybe something odd will shoe up
<zyga> show up
<ikey> yer
<ikey> doing your test-all-the-things command
<ikey> yer im missing the solus snippet in the test suite
<ikey> zyga, we'll just pretend none of this ever happened and move on. *cough*
<zyga> ikey: well it's Friday :)
<ikey> aint it just
<ikey> lol
<zyga> if I had any cold beer I'd love to try some
 * ikey is silencing his brain with bonnie tyler 
<zyga> it's dusk here and it's way to hot to work
<ikey> heh
<ikey> Ireland doesn't really have that issue .. -_-
<zyga> ikey: just put your head into an overclocked pentium 4 for some time
<ikey> lol
<zyga> ikey: not that I recommend it
<ikey> if i had my server still id be plenty warm
<zyga> and some say that traveling to poland is cheaper than a pentium 4
<ikey> dual-socket xeon used to sit under the desk
<ikey> it went back to work when i went full time on solus
<zyga> I'm looking forward to amd now
<zyga> I need to sell my boxes
<zyga> and unify under one nice VM host
<ikey> not gonna have local h/w?
<zyga> no I mean I want less local hw
<pedronis> The job exceeded the maximum time limit for jobs, and has been terminated.
<zyga> I have way too many computers now
<ikey> ah
<zyga> pedronis: :-(
<pedronis> do we have enough resources now with all the other distro tests?
<pedronis> that branch has the bump to 3 workers for fedora but doesn't seem enough
<zyga> pedronis: interesting, I'll drop that if that is the case
<zyga> I was testing on one locally
<ikey> im sure that whatever the problem is, openstack is the solution
 * ikey grins evilly
<zyga> ikey: unless the problem is too many layers of abstraction
<ikey> lol
<ikey> or god awful python
<ikey> which is all basically down to:
<ikey> def busyFunction(args):
<ikey>     return commands.getoutput("some slow ass command {}".format(args))
<zyga> so, when I was in primary school I wanted to make games
<zyga> I ran doom on my 386 DX box
<zyga> and doom took a while to load
<zyga> and I loved that
<zyga> it did stuff
<ikey> yea
<zyga> and my programs at the time did not need that loading screen
<zyga> so one day I impressed my friend by making a fake loading screen
<zyga> where I would just do useless IO and wait a little until all the dots fill in
<ikey> lol
<popey> hahah
<zyga> that was a pro app then
<zyga> it meant serious stuff
<ikey> now i know where plasma got it from ..
<zyga> (also that was on DJGPP under dos, man those were the days)
<popey> oh wow, allegro
<zyga> no I didn't use allegro
<popey> getting flashbacks to zip drives full of djgpp stuff
<zyga> I remember downloading djgpp over modem for a week
<zyga> and now bandwidth is next to free
<zyga> but people don't download djgpp anymore
<zyga> they download youtube and faceb ook
<ikey> in the old SolusOS (debian based) days (not that long ago really) I was using the original mobile broadband, i.e. that devilcrap from 3
<ikey> took over 7 hours to upload an ISO
<popey> ouch
<zyga> really?
<ikey> thats when i fell out with filezilla
<zyga> I'm on mobile broadband now
<ikey> because it wouldnt resume the partial
<zyga> and one thing I love is fantastic upload speed
<ikey> zyga, i mean original mobile broadband. :p
<ikey> not the stuff now
<popey> yeah, but gprs vs 4g is quite a difference
<kyrofa> Man you guys are old
<ikey> i mean like 7 years ago or so
<ikey> kyrofa, oi
<ikey> im 28
<ikey> i think
<zyga> ikey: hmmmmm
<ikey> ill get back to you on that
<zyga> 7 years ago it was still faster :D
<popey> where I went on holiday in portugal they had "wifi" which was a 3g dongle
<zyga> maybe I had better broadband
<kyrofa> I remember the sound of dialup... vaguely
<popey> was fine for everyone to use at the same time. amazing how far it's come
<zyga> hey kyrofa :)
<ikey> Dialling attempt 9 of 10 ...
<zyga> yeah, have you seen the ashen hair on my beard?
<popey> Trumpet winsock :)
<zyga> I feel so old when I look into the mirror
<kyrofa> Hey zyga :) . Haha, that I have!
<kyrofa> zyga, ogra_ isn't is super late for you guys?
<ikey> zyga, my mirror doesn't make eye contact anymore..
<kyrofa> It's the weekend!
<zyga-suse> mvo: reproduced again, darn, I ran without --debug
<ikey> wait how/why did i end up going down this snap road
<ikey> i was meant to be doing budgie 10.4 and a solus release
 * ikey retraces the last few days
<zyga> kyrofa: 20:42 is mild
<kyrofa> Ah right, you moved
<zyga> ikey: I think it was a nice ride :-) you certainly made new grounds here
<ikey> "its been real"
<ikey> lol
<ikey> i mean, being mature about it for a moment...
<ikey> its nice to sit back and say, yknow what..
<ikey> suck it, arch.
<ikey> >_>
<zyga> lol, why take a lob at arch out of a sudden?
<ikey> oh its there
<ikey> thats all
<ikey> its anti-memery
<ikey> remember, Arch is where newest and fixiest â¢ happens first - before everyone! â¢
<zyga> memery?
<ikey> anti-meme.
<ikey> ry.
<zyga> ah
<ikey> lol.
<zyga> one thing I like arch for is the immensly valuable and up-to-date wiki
<zyga> that's an unversal asset for the whole community
<ShalokShalom> ikey: no, we are quicker :P
<ikey> wouldnt be sure about that
<ikey> the emails ive had id say not all of you are that quick ;)
<ShalokShalom> zyga: yea, i see so too
<ShalokShalom> while Gentoos is also great
<ShalokShalom> and the community is nicer...
<ShalokShalom> imho
<ikey> Gentoo went through the growing-up-pains a *long* time ago
<mup> PR snapcraft#1481 closed: cli: better error message for missing mksquashfs <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1481>
<zyga> community is a very vague thing unfortunately, some people are nice, some people are not nice, that's everywhere; some projects try to make sure their community behaves but this is just human nature
<ikey> ya you're gonna get that in any walk of life, virtual or not
<ikey> i feel like my PR has killed the testbot :p
 * ikey is kinda jealous of the fancy automated builder
<zyga> ikey: spread?
<mup> PR snapcraft#1482 closed: ci: skip the CLA check for pull requests from the bot <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1482>
<zyga> ikey: just use it :)
<ikey> touchÃ©
<ikey> nice comment here at the bottom: https://plus.google.com/+Solus-Project/posts/dxBEun53LVm
<ikey> re: s/w availability
 * ikey is finally off the hook almost
<zyga> Pharaoh_Atem: does dnf keep any logs
<zyga> yes
<zyga> snaps make software egalitarian
<ikey> it does solve that most awkward of issues for solus
<zyga> no matter which distribution you use, you keep access to apps you want
<ikey> its biggest strength and arguably its largest weakness
<ikey> its independence
<ikey> having the new fangled formats around allows us to keep doing that
<zyga> ikey: try making a snap
<ikey> (assuming critical mass + hype + corporate backing)
<zyga> ikey: hand make it
<ikey> why so? :p
<zyga> to see how it is
<ikey> i mean im not overly opposed to it
<zyga> ikey: make meta/snap.yaml
<ikey> but i did kinda do the whole YAML based packaging before y'all
<zyga> ikey: stick some files you compiled
<ikey> This won't be overly new to me :P
<zyga> ikey: "snap try" the directory you were holding this in
<zyga> and see how that is
<ikey> ima leave that til tomorrow if thats alright lol, just waiting to see the results of the test build
<zyga> sure :-)
<ikey> and then im gonna find a corner in which to curl up and die
<ikey> *or* buy pringles and watch netflix
<ikey> *hrm*
<ShalokShalom> Snappy is bond to Ubuntu One?
<ikey> totally gonna get pringles.
<zyga> ShalokShalom: nope,
<zyga> ShalokShalom: ubuntu one the identity provider? no
 * ikey considers a snap for solbuild .. xD
<zyga> ShalokShalom: so far that's the only one but we have plans and work in progress for federation and local identity
<ikey> (would be virtually impossible without --classic ..)
<arm1e> ogra_: Hey man, you still around
<popey> arm1e: i think he checked out for the weekend.
<arm1e> ikey: shit me, you still working? Long day. Your new boss must be a real dick!
<ikey> somethin like that
<ikey> going to do a solus release soon, and i think having full (CLI) snap support would be a nice headline feature
<arm1e> popey: cheers. Still stuck on this bloody snap!
<ikey> anyone will tell you, near release time, hours go out the window
<zyga> ikey: indeed
<ShalokShalom> zyga: while this is true, are my experiences with the different communitys very often reproduceable
<popey> arm1e: which one?
<zyga> ShalokShalom: I don't deny that
<arm1e> trying to make a get-iplayer snap, but it is just a perl executable and I cant get it to compile properly
<popey> get_iplayer _may_ become redundant once BBC force the identity provider on us :S
<arm1e> ikey: with flatpak too? That could set you apart from many others
<ShalokShalom> arm1e: he is not working, he is chatting :P
<ikey> we already have flatpak support arm1e
<ikey> ShalokShalom, nuh uh
<ikey> https://xkcd.com/303/
<arm1e> ikey: I know,
<ShalokShalom> ikey: so, you went back from AppImage?
<ikey> never had appimage ShalokShalom ..
<ShalokShalom> Or Flatpak
<arm1e> popey: I know, I just wanted to see if i could do it. Trying to learn how to snap things
<arm1e> popey: LOTS to learn!
<ikey> does anyone else immediately go to "rhythm is a dancer" when someone threatens to snap a thing
<ikey> ?
<popey> The Power, here
<ikey> ah
<ikey> lol
 * zyga doesn't recall the reference
<ShalokShalom> just remember that one person in your room, self-proclaimed pro on this area, announced that after a long and intense research, Flatpak was choosen
<ikey> ok thats not what i said at all and you might wanna wind it in ShalokShalom
<ShalokShalom> not you
<ShalokShalom> somebody else
<ikey> your comment sounds malicious, just letting you know.
<ShalokShalom> that comment sounded so as well
<ShalokShalom> so i might have done a fine job in reproducing it
<ShalokShalom> hi sabdfl :)
<zyga> sabdfl: hey :)
<zyga> sabdfl: ikey here just added snapd support to Solus OS
<Pharaoh_Atem> sabdfl: Hey!
<ikey> s/OS//
<zyga> nice way to end Friday for me :)
<ikey> >_>
<zyga> sorry ;D
<ikey> lol s'ok
<ikey> another meme. :p
<sabdfl> how was the experience, ikey?
<ikey> Intense!
<ikey> lol
<sabdfl> :D
<ikey> I think we pulled this off in like 3 days?
<ShalokShalom> is there anything else in Snappy, that takes it off from the others?
<ikey> including today
<ShalokShalom> some unique feature?
<ShalokShalom> focus?
<ikey> and we're now at the point where Solus's kernel matches the apparmor implementation in Ubuntu Artful
<sabdfl> zyga, do we have Solus in CI testing so we gate updates appropriately?
<zyga> sabdfl: with confinement, no less
<ikey> So Solus has full confinement for snaps. Woot
<sabdfl> that's ace :)
<arm1e> is anyone available to help me write the yaml for get-iplayer please. Keeps failing to compile
<zyga> sabdfl: not yet but we are getting initial patches and we've already discussed spread and system testing
<ShalokShalom> ikey: what makes you go aways from Flatpak?
<sabdfl> classic and strict both work?
<ikey> Couldn't have done it without the guys here, so, go team
<zyga> sabdfl: we'll get there
<zyga> sabdfl: yes
<sabdfl> awesome
<zyga> sabdfl: really, a first outside of ubuntu derivatives
<ShalokShalom> they mean its not suitable to power a whole distro
<ikey> sabdfl, classic has some library/path related issues we can compromise on in solus
<ikey> like libselinux.so needing to be there and gtk-update-icon-cache-3.0 symlink
<ShalokShalom> they = some ppl in #flatpak
<ikey> then the vast majority of classics will "just work"
<ShalokShalom> *away
<zyga> sabdfl: some classic snaps assume too much of ubuntu but we can improve this with tooling and compromise across distros
<sabdfl> ikey, i would like every distro to be a gate on snapd updates, so let's add what you need
<ikey> sure - much appreciated :]
<sabdfl> we should offer a testing service for snap publishers "test your snap on all supported distros"
<zyga> oh that would be lovely, yes
<zyga> and we have the means to do that technically
<ikey> nice bit of value-add
<ikey> free pipelining
<sabdfl> i.e. when they release into edge/beta/candidate, we smoketest it for them, using a test suite they supply, on VMs of all the distros
<Pharaoh_Atem> that'd be nice
<zyga> I was working on out-of-the-box experience that tests how snaps behave simply by following install instructions from snapcraft.io
<sabdfl> so there's less stress in --stable :)
<Pharaoh_Atem> we need to get all the distros at parity first, but that'd be awesome
<ikey> they'd know the distros would have problems .. before the distros
<ikey> bit of a turning point
<zyga> and we could generalize that to see how the same snap behaves across many releases of many OSes
<sabdfl> and we'd have a concrete list of things we can smooth over centrally
<sabdfl> zyga +1
<Pharaoh_Atem> zyga: with F24 EOL, all currently supported Fedora releases will have snapd "just work" out of the box
<zyga> Pharaoh_Atem: yes, I need to do some work to add F26 to our test pool
<Pharaoh_Atem> though we're still gimped because snapd-xdg-open isn't in Fedora
<zyga> Pharaoh_Atem: and also tumbleweed and opensuse leap .3
 * ikey likes boxes and things that work outside of them
<sabdfl> then let's get Fedora into the CI pipe too!
<zyga> sabdfl: we have F25 in the CI today but we need to improve test coverage as not all tests are enabled today
<Pharaoh_Atem> sabdfl: believe me, I want that more than anything :)
<zyga> Pharaoh_Atem: speaking of that, any dnf log I can refer to to see why a particular dnf install failed?
<Pharaoh_Atem> zyga: /var/log/dnf*.log
<zyga> thank you!
<Pharaoh_Atem> there's dnf.log, dnf.librepo.log, dnf.rpm.log
<zyga-suse> Pharaoh_Atem: hmm interesting
<zyga-suse> https://paste.gnome.org/pug2inoby
 * arm1e is looking for anyone who can help write the yaml for get-iplayer please. Keeps failing to compile. 
<arm1e> a mentor i suppose
<Pharaoh_Atem> zyga-suse: that's because 1.12 is gone
<Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/FEDORA-2017-dba5166094
<nacc> arm1e: pastebin the log (of the build failure)
<Pharaoh_Atem> 1.13 was pushed out 2 days ago
<zyga> Pharaoh_Atem: but I dnf install foo
<arm1e> nacc: will do
<zyga> Pharaoh_Atem: am I missing something?
<Pharaoh_Atem> zyga: it's possible you're on a broken mirror?
<Pharaoh_Atem> try forcing a refresh
<Pharaoh_Atem> "dnf --refresh install <pkg>"
<zyga> Pharaoh_Atem: let me patch that
<zyga> trying again
<arm1e> nacc: http://paste.ubuntu.com/25292200/
<ShalokShalom> so, is there anything else to add for you? http://funkyimg.com/i/2wjmo.png
<arm1e> I kind of get the problem, I think the syntax in the yaml is wrong.
<nacc> arm1e: and your yaml?
<ShalokShalom> ah, Snappy runs only on Linux, yeah?
<arm1e> nacc: http://paste.ubuntu.com/25292206/
<arm1e> nacc: I was told earlier to use a snippet to install and got sent the syntax for the install part of the file
<nacc> arm1e: iiuc, you are just trying to put the get_iplayer script in a good place?
<arm1e> I think so
<nacc> arm1e: i think with the dump plugin you can ignore that (tbh) and just create an application that will call get_iplayer
<nacc> arm1e: note that it doesn't really make sense to hav ea yaml without any applications
<nacc> arm1e: i *think* you could probably go through the building steps, stop at stage and see what is in your staged fs at that point. I expect you'd see get_iplayer somewhere and that's all your application needs to call (i think)
<nacc> arm1e: you *might* need a wrapper script since you're using the dump plugin, to set PERL5LIB and/or PATH correctly
<arm1e> nacc: I think I should probably just give up and try a different application
<zyga> re
<zyga> ShalokShalom: I'd like to understand what you mean by sharing libraries
<zyga> ShalokShalom: libraries can be shared just as they can be in flatpak
<zyga> ShalokShalom: and more actually
<ShalokShalom> sharing ressources
<zyga> ShalokShalom: as you are not at the whim of your runtime provider
<zyga> ShalokShalom: so you can share just as much as in the flatpak approach + whatever else you want amongst the snaps you make
<zyga> ShalokShalom: which is not techically possible in flatpak
<ShalokShalom> so, use one library for dozens of apps
<ShalokShalom> while one time in RAM
<zyga> ShalokShalom: I'm not sure that is really the case in flatpak if they come bundled
<zyga> ShalokShalom: unless it happens to happen because of ostree
<ShalokShalom> "whatever else you want amongst the snaps you make" ?
<zyga> but I cannot confirm that for you
<zyga> ShalokShalom: as a snap author you can share content between the snaps you own
<ShalokShalom> the old PC-BSD bundle system also shared ressources
<zyga> ShalokShalom: so you can, say, ship the whole java runtime in one snap
<zyga> ShalokShalom: and then have a few snaps re-use it
<zyga> ShalokShalom: then you trully share it in ram and on disk
<zyga> ShalokShalom: flatpak allows you to bundle stuff in your package and gives you the runtime
<ShalokShalom> yeah, thats what i mean
<zyga> ShalokShalom: (thought I'm not a FP expert so ask them please)
<ShalokShalom> sure
<ShalokShalom> i do this anyway
<zyga> ShalokShalom: but if I have N packages that happen to bundle the same library
<zyga> ShalokShalom: I don't know if it is guaranteed that ostree will de-duplicate it
<zyga> it might, but I cannot say
<ShalokShalom> like to be save, that everyone can insist, if i do something unfair by accident
<zyga> and I don't know the conditions that make it de-duplciated
<ShalokShalom> Flatpak and Snappy are both for Linux only, yes?
<popey> Depends on the perspective
<zyga> ShalokShalom: both rely on linux kernel features extensively
<zyga> ShalokShalom: but
<arm1e> nacc: what would you recommend?
<ShalokShalom> Snappy depends on something?
<ShalokShalom> systemd?
<ShalokShalom> popey: at the current state
<popey> Also, the sheet seems to only focus on user-facing features, not the developer facing features
<zyga> ShalokShalom: it doesn't mean they cannot eventually work in other operating systems
<ShalokShalom> Habitat runs on OS X and Windows too, as an example
<nacc> arm1e: you're pretty close (given that it's a perl script that you're wrapping, no compilation is necessary, which makes it easy
<ShalokShalom> eventually
<zyga> ShalokShalom: we depend on the kernel mostly, userspace we do depend on systemd and udev
<ShalokShalom> this sheet is about the current state of development
<nacc> arm1e: but it's a lot easier to snap something you understand deeply, IMO (at least how it builds/installs)
<zyga> ShalokShalom: though mostly as a convenience, we chose not to abstrat this away because mostly everybody agrees
<arm1e> nacc: problem is I dont understand most of what you wrote
<ShalokShalom> ok fine
<ShalokShalom> i see
<zyga> ShalokShalom: and we made a deputy systemd package that allows systemd to run on top of an existing init system so that it can manage snapd and nothing else
<nacc> arm1e: yeah, i understand
<ShalokShalom> aha, ok fine, thanks a lot
 * zyga knows nothing about habitat
<arm1e> nacc: I only chose this because I managed to get it to work on solus and it is the only thing I have ever packaged
<zyga> ShalokShalom: is that a build-from-source approach?
<ShalokShalom> yeah, its my prefered system until
<ShalokShalom> yes sure
<ShalokShalom> both
<zyga> ShalokShalom: so you have no guarttee that what you get is the same really, it's a differnet build each time
<nacc> arm1e: i don't know what solus is -- but like i said you are actually close
<zyga> that's nice but it's a different class of systems
<nacc> arm1e: if you add a an application, I think you'll immediately see what i meant
<arm1e> ikey: Did you hear that!! Blasphemy!
<nacc> arm1e: and then when you run your application, i think you'll see what i meant about the wrapper script (because it probably won't run)
<arm1e> nacc: application as in set the command for get iplayer
<ikey> sorry didnt hear i wasnt here :3
<zyga> Pharaoh_Atem: I think that has fixed it, I'll commit this soon
<nacc> arm1e: https://snapcraft.io/docs/snaps/metadata#snap.yaml as in an entry under apps:
<nacc> arm1e: right now you're not snapping anything
<ShalokShalom> zyga: https://github.com/habitat-sh/habitat#habitat
<zyga> I need to put the thermal paste on my suse laptop, it is really crazy hot all the time
<ikey> fedora failed on my PR @_@
<nacc> arm1e: parts are bits and pieces of a final snap, but you're not exposing an entry point to that result
<zyga> ikey: yep, I'll fix that
<zyga> that's what I'm working on now
<zyga> (on my suse box, because life is great :)
<arm1e> nacc: I think i follow
<ShalokShalom> Provide repeatable builds
<zyga> ShalokShalom: curl https://raw.githubusercontent.com/habitat-sh/habitat/master/components/hab/install.sh | sudo bash
<ShalokShalom> Provide idempotent behavior (the same inputs to the same asset provide the same outcome)
<zyga> I fear every project that does this
<ShalokShalom> why?
<zyga> really? do you not see why this is dangerous
<nacc> awful :/
<ShalokShalom> look at the .sh if you fear
<ikey> "run random command from internet"
<zyga> haha
<zyga> well
<ikey> "Ok boss"
<zyga> I need to show you one nice script
<ShalokShalom> its not random
<ShalokShalom> its from Chef
<zyga> that if you wget it it is benine
<ikey> ive never seen it before, its random
<zyga> and if you pipe it it owns your system
<ShalokShalom> a well known Company
<ikey> if i do this in a starbuckets on public wifi i deserve whats coming to me.
<ShalokShalom> and community
<zyga> measuring the speed at which you read
<zyga> that's why
<ikey> *starbucks
<ikey> ..starbuckets? long day.
<zyga> it means that whoeever made that page doesn't appreciate secure design
<pedronis> cachio: niemeyer:  got again  The job exceeded the maximum time limit for jobs and has been terminated.  2nd time in a row even if IÂ merged master with the 3 workers for Fedora
<ikey> secure design = pythonic os.system("rm -rf some/path") - right zyga ?
<ikey> because you used a secure language
 * ikey runs
<ShalokShalom> You check all the source code of applications that you pack?
<cachio> pedronis, which job?
<ikey> ShalokShalom, actually thats a new goal for solus
<ShalokShalom> hahahahaha
<ikey> building a source->customer pipeline
<ikey> imean client.
<ikey> *grin*
<Pharaoh_Atem> you mean something that'll keep Solus afloat :)
<Pharaoh_Atem> it's on that boat in the ocean after all :)
<ikey> Solus has no issues staying afloat
<ikey> Well built boat
<ikey> Not like that one irish boat we wont talk about
<ikey> *cough*
 * Pharaoh_Atem sniggers
<ShalokShalom> Solus remembers me on btrfs
<ikey> wat
<ikey> also props for the ascii-banner-of-death on travis
<zyga> ShalokShalom: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
<zyga> this is why
<zyga> mvo, pedronis: I'll cut the number of workers to 1 until we can fix the quota
<zyga> and I think I have the fix for fedora now
<pedronis> cachio: https://travis-ci.org/snapcore/snapd/builds/263451621?utm_source=github_status&utm_medium=notification
<zyga> Pharaoh_Atem: I find the --refresh part confusing because it seems to differ on interactive vs batch somehow
<zyga> Pharaoh_Atem: it doesn't fail interactively, is --refresh inferred somehow>
<pedronis> zyga: won't 1 worker make things worse ?
<zyga> pedronis: we'll see
<zyga> pedronis: I'll measure it
<Pharaoh_Atem> zyga: ?
<Pharaoh_Atem> it shouldn't be different
<zyga> Pharaoh_Atem: it doesn't fail now but it did before
<Pharaoh_Atem> are you not doing --assumeyes?
<Pharaoh_Atem> (aka -y)
<zyga> I am
 * Pharaoh_Atem shrugs
<zyga> -                dnf -q -y install $DNF_FLAGS "$package_name"
<zyga> +                dnf -q -y --refresh install $DNF_FLAGS "$package_name"
<Pharaoh_Atem> worksforme
<zyga> yeah
<zyga> a bit of magic
<cachio> pedronis, the problem is that https://paste.ubuntu.com/25292297/
<zyga> not always failed tho
<Pharaoh_Atem> $DNF_FLAGS?
<zyga> Pharaoh_Atem: yep, --setopt=install_weak_deps=False
<cachio> pedronis, that produced the error
<pedronis> cachio: ah
<zyga> (optionally)
<ikey> s/DNF/DNR/
<pedronis> so I see
<pedronis> not enough workes we fail, too many workers we fail
<ShalokShalom> zyga: again, you trust Chef in this case
<cachio> pedronis, heheh
<zyga> ShalokShalom: I don't trust unsigned stuff piped into root shell, period
<ShalokShalom> you can take any app in Github, a lot of stuff from there is in the distros, unchecked
<cachio> pedronis, to many jobs in parallel
<zyga> ShalokShalom: yes, but I don't run happily installing them
 * ikey is afraid enough of running his own scripts as root, let alone someone elses :p
<zyga> ShalokShalom: *especially* if I make a package manager
<ShalokShalom> why?
<ShalokShalom> is it about your scare?
<ShalokShalom> its computer science
<zyga> ShalokShalom: because it is irresponsible to my users
<cachio> pedronis, at some point we will need more machines
<ShalokShalom> science != scare
<ikey> science frequently = scary
<zyga> ShalokShalom: and if I claim to know enough to make a package manger I should not be making that mistake
<ShalokShalom> which mistake?
<zyga> ShalokShalom: I cannot make a bank by writing the word BENK on a cardbord box
<ShalokShalom> the whole thing is written
<ShalokShalom> claim = unproved
<zyga> well, in software we can, and that is the problem
<ShalokShalom> that thing runs
<ShalokShalom> so its something else as a claim
<ShalokShalom> you seem to be in trouble with semantics
<zyga> ShalokShalom: I just gave you evidence that piping a script to shell is insecure and can be benine on inspection and malicious in execution
<pedronis> cachio: well I have been failing to merge a branch for all the afternoon, and all a bit of the evening
<ShalokShalom> zyga: no
<Pharaoh_Atem> zyga: you can put that before install subcommand
<ShalokShalom> using ANY source code that is unchecked is potentally insecure
<pedronis> cachio: I'm going to give up for now
<zyga> ShalokShalom: I don't dispute that
<ShalokShalom> this source is secure, since the providers are Github and Chef
<zyga> Pharaoh_Atem: what specifically?
<cachio> pedronis, try again in few hours
<ShalokShalom> plus, this is a way to distribute your software across
<Pharaoh_Atem> â[15:37] â<âPharaoh_Atemâ>â $DNF_FLAGS?
<ShalokShalom> distros
<pedronis> cachio: in a few hours I'll sleep
<Pharaoh_Atem> â[15:37] â<âzygaâ>â Pharaoh_Atem: yep, --setopt=install_weak_deps=False
<ShalokShalom> so, what are the alternatives? ship with an AppImage? :P
<zyga> Pharaoh_Atem: yes, it is just used for install
<cachio> pedronis, hehe, I can do it
<ShalokShalom> or maybe ship with Debian, just takes *decades* until they decide its ready?
<zyga> ShalokShalom: well, that's the right question to ask, from there you can come up with answers and some of those are actually better than the pipe to root
<ShalokShalom> this is the answer
<ShalokShalom> you decide to trust
<ShalokShalom> the difference is from where this script comes
 * sergiusens wonders if the conversation will just go in circles from here on
<ShalokShalom> plus you can read it
<ShalokShalom> its open source
<ikey> sergiusens, i personally guarantee it from experience.
<zyga> ShalokShalom: trust is out of the equation, this is just plain insecure at every level and is a nice way to exploit people, it's an opium for developers because it feels easy but it is not a real solution to the problem IMO
<cachio> pedronis, I'll re build it in 1 hour
<zyga> ShalokShalom: I will refer you again to the URL where you cannot inspect it if you copy-paste the command for install instructions
<ShalokShalom> sergiusens: how do you think that people remember things?
<cachio> pedronis, it should be quiet at that time
<ShalokShalom> it goes always in circles, since this is how humans intelligible
<zyga> ShalokShalom: I will just let you know that in snapd we take security very seriously and we don't recommend such things, you may take that as a green point we do :)
<ShalokShalom> zyga: exploit that script
<ShalokShalom> NOW
<ikey> wtf
<ShalokShalom> its easy
<ShalokShalom> according to him/her
<ShalokShalom> start
<sergiusens> ShalokShalom: well, you can read the logs from time stamp N to M and iterate if you want to remember that way
<ikey> FYI this isnt how conversations work..
<popey> This conffrontational conversation isn't particularly welcome here.
<zyga> ShalokShalom: I think you need to re-read what I said, I think I don't have any more arguments because you failed to understand the arguments I made earlier
<nacc> zyga must have infinitely more patience than i do
<ikey> cant we just get back to how awesome solus is?
<ikey> xD
<nacc> heh
<ikey> imean snap
<ikey> waat
<zyga> ShalokShalom: for the sake of argument, my point is not that this is exploted and evil
<Pharaoh_Atem> ...
<zyga> ShalokShalom: but that it teaches you to do the wrong thing
<ShalokShalom> insecure means its easy to exploit
<zyga> ShalokShalom: and that lesson comes from exactly the kind of people that should care about security and integrity
<ShalokShalom> you simply share blog posts who support your opinion
<zyga> ShalokShalom: so in my opinion it is fair to question that
<ShalokShalom> question it
<Pharaoh_Atem> I know I'd never run a script that I'm told to curl | sudo bash :)
<Pharaoh_Atem> that's just asking for trouble
<zyga> ShalokShalom: I shared evidence to refute your claim that one can inspect the script contents
<zyga> ShalokShalom: it is in fact not something you can inspect reliably
<ShalokShalom> yeah, to drive in a car is also dangerous
<Pharaoh_Atem> it's also possible to write obfuscated shell script
<ikey> https://upload.wikimedia.org/wikipedia/commons/thumb/0/03/Circle-withsegments.svg/612px-Circle-withsegments.svg.png
<ShalokShalom> according to statistic
<sergiusens> ShalokShalom: please, can we get to the point of what all this conversation is about. Specifically on how it relates to snaps, snapcraft or anything that usually goes on in here?
<ShalokShalom> it's also possible to write obfuscated _everything_
<ShalokShalom> yeah, dodge it
<zyga> ShalokShalom: note that it does not depend on obfuscation, quit the opposite
 * zyga hugs sergiusens 
<zyga> ShalokShalom: anyway, I think sergiusens is quite right
<zyga> this is quite off topic
 * ShalokShalom shakes his head
<mvo> zyga: meh, still failing the PR from jamie :/
<mvo> zyga: this may have to wait until tomorrow it seems
<zyga> mvo: fix up
<ikey> look sharp
<ikey> ..sorry. xD
<zyga> 3721
 * zyga summons mup's power
<zyga> oh mup, show the URL to the branch I just made
<mup> PR snapd#3721 opened: tests: use dnf --refresh install to avert stale cache <Created by zyga> <https://github.com/snapcore/snapd/pull/3721>
<zyga> thank you mup
<mvo> zyga: oh, nice
<zyga> ikey: next week we should look at those qemu images with solus snapshot that we can use to start running full system tests against
<ikey> yeah that'd be sweet
<ikey> uhm probably gonna have to build the images from solus itself (derpy package manager) but i can probably automate the initial creation of some qemu rootfs's
<ikey> any particular image constraints i need to consider?
<zyga> ikey: that's the goal
<zyga> ikey: real images
<ikey> so self contained bootloader?
<ikey> or..?
<zyga> ikey: ideally a disk image that I can just play with (or instructions on how to make one)
<ikey> cuz i would hazard a guess you're using systemd units to set a target
<zyga> ikey: hmm, I don't follow
<ikey> and need cmdline control
<zyga> ikey: well
<zyga> ikey: not really, we ssh in
<ikey> aah
<ikey> ok so more at the cloud-init end of the spectrum
<zyga> ikey: if you are curious just look at tests/ and spread.yaml
<ikey> sure
<zyga> ikey: basically we boot a system
<zyga> ikey: and then start making stuff to it
<ikey> aye
<zyga> ikey: in snapd specifically we build the package out of the tree you are in
<zyga> ikey: install it
<zyga> ikey: and then run ~1000 different integration tests
<zyga> ikey: that are all small snippets of shell described as task.yaml
<zyga> ikey: in various directories under test/
<ikey> so very cloud-init'y
 * ikey approves :p
<zyga> ikey: maybe, not that familiar with cloud-init :)
<zyga> ikey: but it's simple and it works OK
<zyga> ikey: we have abstractions for package installs and stuff like that
<ikey> yeah its just a case of pumping instructions to a slave machine really
<zyga> ikey: so most tests will need centralized poking to get going
<ikey> yea
<zyga> ikey: yes
<zyga> ikey: we have several backends, qemu for local testing is a nice way to start but eventually we will want to upload a solus image to lindoe
<zyga> ikey: where we can use it to test against incoming PRs
<zyga> ikey: do you have a headless/server image (smaller)
<ikey> eh
<ikey> solus is "desktop only" xD
<ikey> but I can cook something up for you
<ikey> network-manager/kernel/sshd/
<zyga> something minimal
<ikey> we do something similar already for the solbuild backend
<zyga> I think it's a common thing to test package builds
<ikey> its a precooked rootfs that we use as the bottom layer in an overlayfs system
<zyga> so yeah, I'm sure we can do this
<zyga> yep
<ikey> dramatically reduces initialisation cost
<ikey> meaning i can build, say, nano, in a matter of seconds
<zyga> we can also do lxd but we haven't used it in snapd much
<zyga> *cough* at all *cough*
<ikey> lol
<zyga> ikey: I'm really tempted to install solus now you know
<ikey> i could cook you an unstable ISO
<zyga> ikey: my wife will hate me more for putting NaN+1 computers on my desk
<ikey> we're split into unstable/shannon repos
<zyga> ikey: please!
<ikey> (yes, more water themes)
<zyga> shannon?
<ikey> i.e. river shannon
 * zyga googles
<ikey> in the old days we had a /v1/ repo
<zyga> ah
<ikey> then solus went rolling release
<zyga> I read about the naming scheme somewhere
<ikey> and we had to preserve /v1/ path for updates
<ikey> but automatically migrate people to a *new* repo
<ikey> so, shannon was born
<niemeyer> pedronis: Was fedora last again?
<zyga> Pharaoh_Atem: if you are still around, could you look at https://github.com/snapcore/snapd/pull/3721 quickly please?
<mup> PR snapd#3721: tests: use dnf --refresh install to avert stale cache <Created by zyga> <https://github.com/snapcore/snapd/pull/3721>
 * zyga takes a break for shower
 * ikey bakes an ISO
 * arm1e just finished eating the dirtiest donner kebab and he's not even drunk! YUMMY!!
<cachio> niemeyer, was ubuntu-16.04-64 the last
<niemeyer> cachio: So why did it take so long?
<cachio> niemeyer, a lot of "no powered off servers in Linode account exceed halt-timeout"
<arm1e>  nacc, right lets continue
<cachio> niemeyer, I counted 19
<niemeyer> cachio: Yeah, I see a lot of machines on right now
<sergiusens> zyga: have you seen this -> https://github.com/snapcore/snapd-xdg-open/issues/6#issuecomment-321906336 ?
<zyga> sergiusens: looking
<niemeyer> cachio: and indeed most of them seem to be running for a few minutes rather than stuck
<zyga> sergiusens: sweet, thank you
<niemeyer> So we just have too much going on today?
<niemeyer> 9mins, 18mins, 3mins... it's all churning
<niemeyer> cc pedronis
<zyga> yeah, possibly
 * zyga EODs
<zyga> I'll merge 3721 if it goes green
 * zyga goes to spend some time with his son
<cachio> niemeyer, yes, and we are adding more tests and workers
<ikey> 3720 is stuck in a time warp
<cachio> niemeyer, at some point we will need some extra machines I suppose
<niemeyer> ikey: Not sure about 3720, but 3270 definitely is
<niemeyer> ;)
<ikey> heh
<niemeyer> cachio: Not sure.. I'm curious about why do we have so many machines firing at once
<arm1e> nacc: right, I am ready to fix this ba**ard!
<niemeyer> cachio: IIRC, we have a limit of 3 jobs in travis
<niemeyer> 3*20?
<niemeyer> We have 70 machines
<cachio> niemeyer, now, the count sohuld be 3 * 25
<niemeyer> cachio: Ah, are we that far already?  That'd explain the issues we've observed today
<cachio> niemeyer, yes
<cachio> niemeyer, it started after I added an extra worker for fedora
<arm1e> okay, i am settled in. Drink next to me, chocolate bar to the other side. Focussed on the laptop and ready to finish making this bloody snap - if anyone is able to hold my hand
<cachio> and last week 2 workers for opensuse were added too
<niemeyer> cachio: Oh
<niemeyer> cachio: Okay.. definitely pushing the limits
<cachio> niemeyer, so, this week we added 3 workers
<cachio> yes
<niemeyer> Alright.. I'll grab 10 more VMs..
<niemeyer> I'm expecting a call from finance any day now.. :)
<cachio> niemeyer, nice :)
<niemeyer> arm1e: What's up there?  I'm sure somebody with an equal amount of drinks and chocolate might be able to help around here :)
<arm1e> niemeyer: the prblrm ish thart tit wongt tompihsh annd I am confusgthed
<arm1e> niemeyer: sorry, mouth full!!
<arm1e> i want to be able to build snaps to help other users and enable more packages for other distros but I need to learn how to do it. I therefore decided to learn by doing. I completed the hello world stuff on the websites and have read the docs, so I decided to try an application. I am attempting get-iplayer:
<arm1e> niemeyer: http://paste.ubuntu.com/25292206/ here is the yaml, but I am stuck
<popey> Unfortunately you're breaking new ground because I don't think we have many perl snaps
<nacc> arm1e: sorry, was afk, back now
<arm1e> popey: get me :)
<nacc> in this particular case, i think we don't need much perl support, per se
<popey> basically dump the pl in, along with whatever other modules, set the environment up and you're done?
<nacc> popey: that'd be my guess, yeah
<nacc> popey: based upon what arm1e showed me before
<tpatel> Which snapd version does install hooks introduced?
<tpatel> which version of snapd supports install hooks?
<pedronis> tpatel: the upcoming one (now in candidate), 2.27
<tpatel> thanks pedronis
<tpatel> Can we control start of more than 1 services? Like app1 then app2 and so on
<zyga> woot green
<tpatel> currently is done in alphabetical order
<mup> PR snapd#3721 closed: tests: use dnf --refresh install to avert stale cache <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3721>
<arm1e> nacc: so what exactly should I do next? YOu may have to dumb it down a lot
<arm1e> Anyone else who wants to try to help me http://paste.ubuntu.com/25292206/ here is the yaml, but I am stuck
<arm1e> team effort
<mup> Bug #1710305 opened: installing any snap crashes with "failed to load system roots and no roots provided" <Snappy:New> <https://launchpad.net/bugs/1710305>
<nacc> arm1e: ok, have you added an app?
<nacc> arm1e: add an app first
<arm1e> no problem. with a command field or just the app
<nacc> arm1e: hrm? see the link i sent you on the snapcraft page earlier?
<popey> apps:
<popey>   get-iplayer:
<popey>     command: get_iplayer
<popey>     plugs:
<popey>       - network
<popey> ^ like that
<nacc> popey: thanks :)
<arm1e> what is the -network plug for? Just to allow access to the internet?
<popey> ya
<arm1e> snapping now
<arm1e> slowly
<arm1e> done
<popey> you may need to create a launcher script
<popey> which sets all the PERL env vars
<popey> but I don't know which ones
<nacc> more than likely you'll need to set PERL5LIB to point inside $SNAP somewhere so it looks in the snap fs for modules
<ikey> 2017-08-11 20:43:17 Error executing autopkgtest:ubuntu-17.04-amd64:tests/main/refresh-all-undo :
<arm1e> nacc: error -->http://paste.ubuntu.com/25292865/
<ikey> i think it just network-broke..
<nacc> arm1e: sorry, where do you get that error?
<nacc> arm1e: it's best to provide the command you are running in the paste(s)
<nacc> arm1e: otherwise i have no context :)
<arm1e> installed the snap and ran the command get-iplayer (as defined in the yaml)
<nacc> arm1e: ah is that when running the command?
<nacc> arm1e: ok, so you see how INC has a bunch of paths in it?
<nacc> arm1e: is this is a classic or confined snap?
<nacc> ok, looks to be confined per the yaml
<nacc> just in devmode
<popey> devmode
<arm1e> which is best?
<nacc> arm1e: you should be abl to run someth9ing like `snap run --shell get-iplayer` and look around
<nacc> that's the fs that your snap runs in
<nacc> fs environment
<nacc> i'm guessing you're missing some runtime package dependencies
<nacc> arm1e: i think you're missing a stage-package of 'perl'
<nacc> arm1e: which will pull in perl-modules which will install Env.pm in your snap
<arm1e> will have a look now
<arm1e> nacc: I have the required perl dependencies from the online docs for get-iplayer so I dont know how to fix this problem
<nacc> arm1e: what do you mean?
<nacc> arm1e: did you look in the shell?
<arm1e> nacc snap run --shell get-iplayer does nothing
<nacc> arm1e: no, it does something
<nacc> it just may not seem like anything
<nacc> it is putting you in a shell in the snap
<arm1e> no, it errors out
<arm1e> nacc: 'no tty present and no askpass program specified
<nacc> arm1e: oh then it doesn't "do nothing", it "fails".
<arm1e> ok hang on
<nacc> arm1e: it's important to be specific since i'm doing a bunch of other stuff and not at your computer :)
<arm1e> nacc: tried the command and it fails :p
<arm1e> I can look in /snaps/get-iplayer
<arm1e> is that the same?
<nacc> arm1e: are you ssh'd in?
<arm1e> no
<nacc> arm1e: also, keep in mind, if you ran it once, and it succeeded, then you're in the snap shell
<arm1e> just in normal terminal
<nacc> so running it again won't work
<arm1e> I might be in then as ls in home shows nothing
<arm1e> What do I do now?
<nacc> arm1e: right
<nacc> arm1e: so you need to figure out if you can run perl
<nacc> and if hwen you run perl, what @INC is set to, etc.
<nacc> and if stuff is ther (like Env.pm)
<arm1e> so how do i figure that out?
<arm1e> i mean, how do i run perl?
<nacc> arm1e: literally
<nacc> arm1e: run `perl`
<nacc> does it run?
<arm1e> i tried that and it looked like it does but I still get the locale warning. Nothing about ENV tho
<nacc> locale is probably fine
<nacc> ok, then try to run your script
<nacc> arm1e: you can use locate to find it, if it's not in a well-defined location (it might just be in .)
<nacc> arm1e: and or /snap/bin
<nacc> arm1e: and then debug why it won't start
<arm1e> in the shell or out of it
<arm1e> locate command not found
<nacc> arm1e: bah, well, yeah, it won't be :/ -- you'll need to just look around in your snap
<nacc> arm1e: it's probably in /snap/<snap-name>/current/ ...
<arm1e> I can find the script in /snap/bin but it still gives the error
<nacc> arm1e: right, you are now trying to *fix* the error :
<nacc> :)
<nacc> arm1e: by installing packages, etc, that maybe you are missing
<arm1e> I cant find evidence of what the package is that is missing
<nacc> arm1e: so normally you'd have a perl-modules installed, which has /usr/share/perl/5.24.1/Env.pm (with the appropriate version for 16.04)
<nacc> arm1e: do you have that in your shell env?
<arm1e> looking
<arm1e> there is no Env.pm on the host machine in /usr/share/perl5
<nacc> arm1e: not on the host machine, in the snap
<arm1e> oh
<arm1e> hold on
<arm1e> nacc: Not in snap either
<nacc> arm1e: then you're missing some dep
<nacc> as i said
<nacc> arm1e: did you try just dding perl to your stage-packages?
<arm1e> will
<ikey> https://plus.google.com/+Solus-Project/posts/8joLvCfgWrz
 * ikey collapses in a corner
<arm1e> nacc: re-snapped with perl as a dependency. Still get the same error. Very late now so going to bed but will try again tomorrow. Getting cloaser but still annoying!!
<nacc> arm1e: ok
<arm1e> nacc: thanks for the help so far
<nacc> arm1e: yw
#snappy 2017-08-12
<mup> PR snapd#3715 closed: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3715>
<arm1e> hey folks. Good sleep and now ready to finish this snap (hopefully)
<arm1e> anyone able to help? trying to fix missing perl modules, but they are not missing!
<arm1e> get_iplayer has all dependencies as stage-packages which match the deps when installing from the normal ubuntu repos but complains about env.pm when running in the snap with this error: http://paste.ubuntu.com/25295446/
<arm1e> wow, quiet today
<mup> PR snapd#3712 closed: overlord,store: send model assertion when setting up device sessions <Reviewed> <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3712>
<mup> PR snapd#3717 closed: overlord,store: no piles of return args for methods gathering device session request params <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3717>
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3484, snapd#3502, snapd#3520, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581, snapd#3585, snapd#3586, snapd#3590,
<mup> snapd#3594, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3642, snapd#3660, snapd#3679, snapd#3691, snapd#3692, snapd#3693, snapd#3697, snapd#3702, snapd#3705, snapd#3710, snapd#3714, snapd#3716, snapd#3718, snapd#3719, snapd#3720
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3484, snapd#3502, snapd#3520, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581, snapd#3585, snapd#3586, snapd#3590,
<mup> snapd#3594, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3642, snapd#3660, snapd#3679, snapd#3691, snapd#3692, snapd#3693, snapd#3697, snapd#3702, snapd#3705, snapd#3710, snapd#3714, snapd#3716, snapd#3718, snapd#3719, snapd#3720
<ikey> damn
<ogra_> github being wonky again ...
<ogra_> popey, i just odered an air myself to speed up that stuff :)
<ogra_> *ordered
<popey> ogra_: aw, sorry about that
<ogra_> popey, lol, you know i always love having more hardware :)
<popey> ogra_: :)
<ogra_> wow ... i love our setup
<ogra_> creating a devicetree compiler snap ... 3min of work ... https://github.com/ogra1/devicetree-compiler ...
<ogra_> having build.snapcraft.io create and publish a snap to edge ... another 2min ... priceless :)
<ogra_> popey, http://people.canonical.com/~ogra/snappy/sun8i-h3-nanopi-neo-air.dtb ... i tried to disable the uart3 settings (bluetooth) in the devicetree, you could try replacing /system-boot/boot/uboot/linux-generic-allwinner_5.snap/dtbs/sun8i-h3-nanopi-neo-air.dtb
<ogra_> (this is just a shot in the dark, though ... might not even boot at all with that file but there is a minimal chance that it works)
<ogra_> hmm, thats probably rather  /system-boot/uboot/linux-generic-allwinner_5.snap/dtbs/sun8i-h3-nanopi-neo-air.dtb
<ikey> food for thought - how possible/feasible would it be to provide cups drivers and such via snaps?
 * ikey is thinking about the dreaded brother drivers
<popey> ogra_: on it!
<ogra_> ikey, https://forum.snapcraft.io/t/snapping-cups-printing-stack-avahi-support-system-users-groups/1502
<ogra_> all in the works :)
<ikey> well
<ikey> thats not quite what i asked :/
<ikey> thats snapping cups itself
<ikey> not cups drivers with a native cups
<ogra_> well, beyond that you could probably provide them via classic snaps
<ikey> thats the thing *I* can't provide them
<ikey> Brother is a dick
<ikey> And you can't distribute their stuff
<ikey> Same for some epson drivers
<ogra_> well, if the license doesnt allow distribution snap wont change the licensing :)
<popey> does cups not auto go and get them these days?
<ogra_> yeah
<ikey> "auto go and get them" - from where?
<ogra_> our cups at least
<ogra_> openprinting.org
<popey> linuxprinting.org?
<popey> or that
<ogra_> yeah, one of these :)
<ikey> isnt that like a whacking great big security hole?
<ogra_> well, our cups maintainer is the upstream guy of that :)
<ikey> well thats just cheating :p
<ogra_> heh
<popey> heh
<ikey> hm.
<popey> "Till, the printing guy"
<ogra_> but in general i think fedora uses it too
<ikey> so does this also mean no hplip crap?
<ogra_> i think openprinting provides hplip as well
<ikey> damn son
<ogra_> and cups dynamically downloads from there
<ogra_> for details you really need to ask till
<ikey> why are you not doing this solus?!
<popey> ogra_: that fixed the spammy messages
<ogra_> \o/
<ogra_> lovely
<ogra_> popey, any trace of a wlan device ?
<popey> no network
 * popey gets syslog
<ogra_> or did i kill it with that
<popey> hehe
<ogra_> that was a gross hack directly to the devicetree :)
<popey> Am I a bad person for glueing the 4 pins of the serial cable together?
<ogra_> as long as you dont use solder ...
<ogra_> :)
<popey> i can never remember the order of them
<ogra_> the prob is they differ between boards
<mup> Issue # closed: snapcraft#100, snapcraft#1437, snapcraft#1438, snapcraft#1439, snapcraft#1440, snapcraft#1441, snapcraft#1442, snapcraft#1443, snapcraft#1444, snapcraft#1445, snapcraft#1446, snapcraft#1448, snapcraft#1449, snapcraft#1450, snapcraft#1451, snapcraft#1452, snapcraft#1453,
<mup> snapcraft#1454, snapcraft#1455, snapcraft#1456, snapcraft#1457, snapcraft#1458, snapcraft#1459, snapcraft#1460, snapcraft#1461, snapcraft#1462, snapcraft#1463,
<mup> snapcraft#1465, snapcraft#1466, snapcraft#1467, snapcraft#1468, snapcraft#1469, snapcraft#1475, snapcraft#1476, snapcraft#1477, snapcraft#1485
<mup> PR # closed: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1382, snapcraft#1387, snapcraft#1399, snapcraft#1412, snapcraft#1414, snapcraft#1419, snapcraft#1420, snapcraft#1428, snapcraft#1430, snapcraft#1436, snapcraft#1447,
<mup> snapcraft#1474, snapcraft#1479, snapcraft#1480, snapcraft#1483, snapcraft#1484
<ogra_> so you might need a different order on another board
<popey> i bought a bunch of cables :)
 * ogra_ keeps the plugs dangling ... but they wear out over time so that they easily drop off 
<ikey> https://dev.solus-project.com/T4263
<ikey> >_>
<ikey> <_<
<ogra_> +1
<ogra_> :)
<popey> http://paste.ubuntu.com/25297003/
<ogra_> ikey, till is "tkkamppeter" when he is on IRC (he currently isnt ...) and he is usually in #ubuntu-desktop or #ubuntu-devel
<popey> ikey: do you have google print service in solus?
<ikey> uhm
<popey> !info google-cloud-print-connector
<ubottu> google-cloud-print-connector (source: google-cloud-print-connector): Google Cloud Print CUPS Connector. In component universe, is extra. Version 0.0~git20151105.24.1902938-2 (zesty), package size 2020 kB, installed size 11050 kB
<popey> ^ that thing
<ikey> not .. yet.
<ogra_> popey, brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
<ogra_> looks like i broke it
<ikey> oo so i could print from my phone to a USB printer on my linoox?
<popey> i only recently discovered it, as I have a usb only printer
<mup> Issue # opened: snapcraft#100, snapcraft#1437, snapcraft#1438, snapcraft#1439, snapcraft#1440, snapcraft#1441, snapcraft#1442, snapcraft#1443, snapcraft#1444, snapcraft#1445, snapcraft#1446, snapcraft#1448, snapcraft#1449, snapcraft#1450, snapcraft#1451, snapcraft#1452, snapcraft#1453,
<mup> snapcraft#1454, snapcraft#1455, snapcraft#1456, snapcraft#1457, snapcraft#1458, snapcraft#1459, snapcraft#1460, snapcraft#1461, snapcraft#1462, snapcraft#1463,
<mup> snapcraft#1465, snapcraft#1466, snapcraft#1467, snapcraft#1468, snapcraft#1469, snapcraft#1475, snapcraft#1476, snapcraft#1477, snapcraft#1485
<mup> PR # opened: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1382, snapcraft#1387, snapcraft#1399, snapcraft#1412, snapcraft#1414, snapcraft#1419, snapcraft#1420, snapcraft#1428, snapcraft#1430, snapcraft#1436, snapcraft#1447,
<mup> snapcraft#1474, snapcraft#1479, snapcraft#1480, snapcraft#1483, snapcraft#1484
<popey> yes
<ikey> alright github calm down
<ikey> lol
<popey> exactly, i plug my usb printer to home server and print from phone
<popey> KILL IT!
<popey> or maybe just put it to sleep or something
 * ikey added an edit to the solus task xD
<popey> :)
<ogra> ;)
<popey> maybe boot lutostag too :)
<ogra> done
 * ogra loves +q
<popey> ta
<popey> i think you need to +b
<popey> because +q won't stop them coming back
<ogra> popey, well, i guess we need to wait til i have my air then ... randomly hacking the dtb will just be random :)
<popey> yeah, that's cool
<popey> back in the box he goes :)
<popey> <3
<ikey> XD
<ogra> hmm
<ikey> *!*lutastag*@*
<ikey> or kill it.
<tbr> lutostag!*@*
<ikey> oh right, nick not ident
<ikey> derp
<tbr> nick!ident@hostmask
<ikey> ya
<ikey> didnt read the ident :P
<ikey> depressing part being ive written IRC clients in the past and i still managed to botch that..
<popey> There must be about as many irc clients as there are text editors now
 * ogra only OPs every three months or so ... i can never remember anything 
<ikey> popey, yeah
<ogra> ogra@nanopi:~$ devicetree-compiler -h|grep Usage
<ogra> Usage: dtc [options] <input file>
<ogra> ogra@nanopi:~$
<ogra> hmm
<ikey> lol did cassidy seriously quote Daniel ForÃ© as if he was Gandhi on his rant about snaps?
<ikey> well i never..
<popey> hahah
<ogra> would really be nice if snapcraft could adjust the command name in help output magically
<popey> He has some valid points
<popey> Be nice if it was a bug report though
<ikey> yea
<popey> I'm sure eos guys wouldn't appreciate that kind of public "feedback"
<ikey> yeah i once mentioned vala was dead
<ikey> never again
<ogra> where is that ? G+ ?
<popey> hahah
<popey> yes
<popey> the relavent people are aware of it :)
<ikey> in positive news..
<ikey> got apparmor support into linux-lts in solus too
<ikey> so both kernels are rocking snapd support
<ikey> meaning existing users wont need to do any magic other than installing snapd to use it
<ikey> i mean thats like another 6 users, easy.
<ogra> yay
<ogra> that makes 10 already !
<ikey> yep xD
<ogra> https://forum.snapcraft.io/t/could-snapcraft-replace-the-command-in-usage-output-with-the-actual-command/1662/1
<arm1e> anyone able to help? trying to fix missing perl modules, but they are not missing!
<arm1e> get_iplayer has all dependencies as stage-packages which match the deps when installing from the normal ubuntu repos but complains about env.pm when running in the snap with this error: http://paste.ubuntu.com/25295446/
<ogra> arm1e, well, you picked a perl package as your first snap .... snapping perl is pretty painful
<arm1e> i only picked this because it is the only thing I have ever packaged before and thought it would be ok. I was very wrong
<ogra> your modules dont live in the standard paths but under $SNAP
<ogra> so you need to teach the perl interpreter about the new search paths
<arm1e> I have no idea how to do that
<arm1e> I think this may be way beyond my ability
<ikey> you can patch it or you can add a wrapper script
<ogra> you create a wrapper script and export the right bits, so perl knows where to look
<ikey> heh
<ikey> i think its something like PERL5LIB
<ogra> (we have snapcraft parts for nearly every language that do this automatically for you ... just not for perl)
 * arm1e thinks he should have done computer science at uni, not normal science
<arm1e> ogra: you make it sound so easy but I think I am going to have to abandon this one
<ogra> it isnt that hard
<ikey> well you can use `organize` to stick the wrapper script as the "main" script and set it as the main command
<arm1e> ikey: get you Mr snappy lover now :p
<ikey> no i just happen to have a lot of experience packaging things for Linux.
<arm1e> ikey: I wish I did
<ikey> also see "where did the last decade+ of my life go"
<ogra> arm1e, this is from a very old demo snap i once did http://paste.ubuntu.com/25297317/
<arm1e> ikey: where will the next one go? Turning solus into skynet?
<ikey> lol "turning"
 * ikey giggles
<ogra> arm1e, take a look at the PERLCMD variable i set there
<arm1e> ogra: will do, thanks
<ikey> ah -I usage to override INC.
<ikey> pretty
<ogra> (bnote that things like SNAP_APP_PATH and such got renamed, it will need adjustment to point to SNAP or SNAP_DATA, but it should give you an idea)
<ikey> please tell me you have easteregg $CRACKLE $POP ones
<arm1e> ikey: lol
<arm1e> ogra: I see what you wrote but is that the only part that would be needed?
<arm1e> I really do think this is above my ability having never programmed or properly packaged before. Not exactly a nice gentle difficulty curve
<ogra> arm1e, well, you would create a "wrapper.sh" (or name it as you like) similar to that one ... then the last line would be something like "$PERLCMD /path/to/get_iplayer" and the app entry in your snapcraft.yaml would execute wrapper.sh instead of get_iplayer directly
<ogra> arm1e, where is your source tree ?
<arm1e> no idea
<ogra> did you put it on github or so ?
<arm1e> no
<ogra> ah
<arm1e> you mean for the snap or for get iplayer?
<ogra> for the snap :)
<arm1e> i have compiled it but it is only on my system
<ogra> well, if you create a github tree for it i can provide you the wrapper in a pull request that you can merge :)
<ogra> (i cant test it though, BBC doesnt allow us germans to watch their stuff :P )
<arm1e> I can send you the snap
<ogra> well, i'D prefer to have it on github
<ogra> that way you will also be able to have it auto-built in the end
<arm1e> I dont have an account or know how to use it
<arm1e> ogra: right I am on github but how to I upload the source tree?
<ogra> there is a plus sign at the top bar on the website
<ogra> click it
<ogra> pick "new repository"
<ogra> give it a name (like get-iplayer-snap)
<ogra> and click the create button ...
<ogra> that will bring up instructions
<arm1e> yeah, I did all of that and tried to upload the snap, but it is too big so I am not doing the right thing
<ogra> no, you upload the source tree
<ogra> not the snap
<ogra> i.e. the dir where your snapcraft.yaml is
<ogra> (and any other scripts or what you have in there)
<arm1e> Now I am getting told there are too many files.
<Jess_> How can I see if this is on my phone
<arm1e> ogra: is it the snap / prime / stage or parts folder or all of them
<ogra> arm1e, no, call snapcraft clean first
<ogra> whats left then is what you want to push
<arm1e> too late.
<arm1e> all of them are going on mwahahahahaha!!
<arm1e> cancelled it
<arm1e> ogra:  there is only an empty snap folder and the yaml
<ogra> yeah, thats all you want then
<arm1e> ogra: done
<ogra> so gimme the url to your repo now :)
<arm1e> https://github.com/arm1e/get-iplayer-snap.git
<arm1e> ikey: Once I have got the packaging learned fancy teaching me how to roll a new disro :p
<arm1e> ogra: What's the next step?
<ogra> you wait :)
<arm1e> ogra: Thanks for helping me btw!
 * arm1e waits
<ogra> wow, thats a big snap
<ogra> (i guess due to shipping ffmpeg and the world in it)
<arm1e> ogra: yeah, needs newest ffmpeg unfortunately
<ogra> arm1e, https://github.com/arm1e/get-iplayer-snap/pull/1
<ogra> you shoudl see a merge button
<ogra> click it ... then run git pull locally so you get the changes and run snapcraft :)
<ogra> (you can indeed also comment on the github page and complain about my bad indendation in the wrapper.sh script ;) )
<ogra> it works here for me (but i cant download anything and i dont know if ffmped will work, might need some additional love for that
<ogra> )
 * ogra sees the "merged" message on github 
<ogra> great :)
<arm1e> Thanks very much for all of your help here!
<ogra> well, it was a nice finger training :)
<ogra> havent packaged perl stuff in a while
<ogra> and there is surely still enough to do for you
<ogra> but it startss now
<arm1e> what does?
<ogra> get-iplayer
<arm1e> right will test now
<ogra> your next challenge: make it use confinement: strict ;)
<ogra> INFO: 3366 Matching Programmes
<ogra> hah
<ogra> at least i can get the indexes in germany
<arm1e> ogra: seems to download, but not sure how this will work in a confined snap. Where will it download to? Will need to expose /home/$USER/Downloads
<ogra> arm1e, you get access to $HOME/Downloads via the home interface, just add it
<ogra> and even without it it could download to $HOME/snap/get-iplayer/ ... whihc is the user dir of the snap
<arm1e> ogra: how will the user access the downloads if it is in there?
<popey> file manager
<popey> its in your home, but anyway, adding the home plug will allow it to save them in ~/Downloads anyway
<arm1e> does that restrict it being contained or is it okay?
<popey> it will just work fine
<arm1e> thanks
<arm1e> popey: btw I am starting work on my laptop entry next week.
<arm1e> popey: 20 tweets right?
<popey> is it a poem?
<arm1e> will be
<popey> you can submit almost anything :)
<popey> nice
<popey> 20 lines, 20 tweets, whatever :)
<arm1e> popey: how are the extra pixels working out for you?
<popey> soooo good
<arm1e> I was considering another monitor myself but I usually work on my knee, rather than the office
<popey> hehe
<arm1e> cant balance the monitors on them
<popey> Right, off to make tacos! ttfn
<ikey> mmm
<ikey> vague mention of food
#snappy 2017-08-13
<luk3yx> lurk3 .msg ##lurk! <CG-Bot@xerox> luk3yx!
#snappy 2018-08-06
<mborzecki> morning
<mborzecki> mvo: hi, back to your morning schedule?
<mvo> hey mborzecki - yeah
<mvo> mborzecki: this should be my usual time again
<mborzecki> mvo: poor kids back to school in august :(
<mvo> mborzecki: yeah, in the worst heat since forever
<mvo> mborzecki: not fun
<mvo> mborzecki: and I see a lot of unhappy tests, its a bit flaky again, right?
<mvo> interfaces-accounts-service
<mvo> it seems is the culprit a lot of time?
<mvo> times
<mborzecki> mvo: that would be double guid in eds?
<mvo> mborzecki: I see InvalidArgs errors here
<mvo> mborzecki: but I only looked at one of the failures so far, haven't payed much attention to this before
<mborzecki> mvo: which pr is this?
<mvo> mborzecki: that was 5600
<mborzecki> hm maybe gnome online accounts has changed it's dbus iface?
<mborzecki> mvo: i'll look into this
<mvo> mborzecki: yeah, its very strange it shouldn't do that in the middle of the stable 16.04 release though. I wonder what is going on
<mvo> mborzecki: I have a look, I see it also in travis on master once
<mvo> mborzecki: and its not happening all the time (fun!)
<mborzecki> mvo: well, (sssa{sv}a{ss})' matches the current stable org.gnome.OnlineAccounts.Manager.AddAccount iface
<mborzecki> mvo: and 3.18.x release (supposedly in xenial) was the same
<mvo> mborzecki: yeah, it should not have changed
<mborzecki> mvo: i don't like how we don't pass the typespec to gdbus, it's guessed instead?
<mborzecki> mvo: we pass "imap_smtp" "test@example.com" "Display Name" "{}" "{'actual': 'data'}", the error is that it's expecting (sssa{sv}a{ss}) but got '(ssssa{ss})' as if "{}" was interpreted as 's'?
<mvo> mborzecki: yes, I think thats the issue but only sometimes which makes it strange
<mvo> mborzecki: I wonder if there is a way to add debug to the call to see what it actually sends on the wire
<mvo> or we could run dbus-monitor in to gather debug data
<mborzecki> mvo: let me see if it honors G_MESSAGES_DEBUG or alike
<zyga> Good morning
<zyga> Long time no see
<mborzecki> zyga: hey
<mvo> zyga: hey, good morning! how are you? well rested?
<zyga> Yes :-)
<zyga> It feels like a month has passed
<zyga> How are you all?
<zyga> How is the project?
<mvo> zyga: all going well so far
<zyga> How is core18?
<mborzecki> mvo: https://gitlab.gnome.org/GNOME/glib/issues/598
<mborzecki> mvo: wonder why it's using that particular error as an example
<mvo> zyga: core18 is looking good, an image for amd64 is released, we are looking at arm now
<mvo> mborzecki: heh, yeah
<mvo> mborzecki: I added a PR that adds some debug, lets see if that gives us some clues
<zyga> mvo: is the image stable or still in beta/candidate phase
<mvo> zyga: very much beta still
<mvo> zyga: but looking good overall
<mborzecki> mvo: i looked into gdbus source code, it introspects the called method before repacking command line arguments to dbus types, so at least this part should try to do the right thing
<mborzecki> mvo: we could just merge https://github.com/snapcore/snapd/pull/5602 and inspect it further when the problem is reproduced again
<mvo> mborzecki: yeah, lets do this
<mvo> mborzecki: thank you
<pstolowski> heyas
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: back from vacation?
<zyga> hey pstolowski
<zyga> are you back just now?
<mvo> hey pstolowski, welcome back!
<pstolowski> mborzecki, mborzecki i got back home a few days ago
<pstolowski> and temperatures here are not much different from greece, easy accomodation ;)
<mborzecki> pstolowski: sound like you had a great time
<pstolowski> mborzecki: indeed, corfu is really beautiful
<mborzecki> we're down to 33 reviews
<zyga> mvo: today I will focus on preparing for Flock tomorrow
<zyga> but let me know if I can help with short or urgent tasks please
<Chipaca> zyga: wb!
<zyga> thank you :)
<mborzecki> zyga: https://flock2018.sched.com/event/Fjde/fedora-and-snaps-a-two-year-retrospective-and-an-exciting-future this one right?
<zyga> mborzecki: that's right
<mborzecki> zyga: wonder if there'll be a live stream or sth
<mvo> xnox: hey, anything I can do to help with bug 1778936 (readding support for read-only-etc for hostnamed? should I just sru this change in isolation or is there a bigger systemd sru planned?
<mvo> popey: hey, do you think something like https://bazaar.launchpad.net/~snappy-dev/snappy-hub/test-snapd-curl/revision/1 is worth pushing to the curl upstream? or to snapcrafters? we need a snap for curl for our internal testing but it seems like it would be generally useful
<pstolowski> zyga: did you find any problem with slot remapping wrt the issue i had 2 weeks ago?
<zyga> pstolowski: hey, no I didn't find anything at the time
<popey> mvo: certainly worth trying to submit upstream before putting in snapcrafters.
<popey> mvo: worth looking into whether upstream actually support distributing binary builds or not.
<mvo> popey: what the best approach? I can do a PR that juts contains snapcraft.yaml for git master?
<mvo> popey: aha, good point, they have a winbuild dir but I have not investigated that at all
<popey> mvo: typically we add some boilerplate to explain what it is, and why you're adding it. They also need to know how to register the name in the store etc.
<popey> mvo: for example. https://github.com/rust-lang-nursery/rustup.rs/pull/1441
<mvo> popey: thank you
<popey> np :)
<mwhudson> mvo: xnox is on leave
<mvo> mwhudson: thanks, who the best person to talk about systemd while he is away?
<mwhudson> mvo: errrr i guess there is always slangasek
<mvo> mwhudson: :) ok
<mwhudson> but i suspect the implication is that there is no systemd sru planned in the near term
 * mvo nods
<mborzecki> there are no tests for snap-device-helper?
<zyga> mborzecki: I don't think there are any individual tests
<zyga> there are indirect tests via spread
<zyga> but that piece of code is ... very old
<mborzecki> heh, needs to be taught new tricks now, such as parallel installs
<zyga> beware of dragons
<mborzecki> zyga: i can hack some tests with gtest probably
<zyga> why gtest?
<zyga> I mean, we use glib for tests
<mborzecki> zyga: we use that in s-c already, i'd add it to already existing unit tests
<zyga> ah
<Chipaca> so, in order to keep up with the latest in security, today I'll be pushing 23 new PRs, all of them bug-ridden. https://arxiv.org/pdf/1808.00659.pdf
<zyga> I assumed you meant google's test
<mborzecki> zyga: nah, just plain glib test framework
<zyga> mborzecki: +1 then :)
<zyga> sorry for being silly
<mvo> work on fixing godd on armhf (missing libs, rathole because x/sys/unix needs later go than xenial has)
<mvo> eh, sorry, there is a bit of context missing here
<mvo> I am in a bit of a rathole right now, I want to (re)build godd but x/sys/unix changed and needs a newer go to build. the godd snap uses xenial (which I would like to keep for now). so I experimented with using the go snap as a build-snap but LP will always use the system go. anyone have tried to override this? I have no luck so far
<zyga> oh man, that's nested
<cjwatson> mvo: That shouldn't be anything to do with LP as such - surely it's entirely in control of your snapcraft.yaml?  Or maybe of the relevant snapcraft plugin I guess
<mvo> cjwatson: I think its simply a PATH bug
<mvo> cjwatson: i.e. /usr/bin is before /snap/bin and LP happen to have go installed as well, just an older version
<mvo> cjwatson: at least that is my guess - I guess the easiest might be to try to just override-{pull,build} and set PATH manually(?)
 * mvo tries that
<cjwatson> I'm quite surprised that go would be in the chroots
<mvo> cjwatson: oh, then its the go plugin pulling it in
<mvo> cjwatson: I have a look at this next
<cjwatson> Not in the xenial amd64 chroot at least (I don't have the armhf one locally)
<cjwatson> Installing build dependencies: golang-1.6-go golang-1.6-src golang-go golang-src
<cjwatson> from your build log
<cjwatson>         self.build_packages.append('golang-go')
<cjwatson> /etc/profile.d/apps-bin-path.sh seems to put /snap/bin after everything else too ...
<cjwatson> Maybe snapcraft's Go plugin just needs to have a more built-in way to use the snap
<Chipaca> mvo: can't you use golang-golang-x-sys-dev ?
<mvo> Chipaca: its pulled in via "pb" - I was considering to replace it with our own progress stuff
<mvo> cjwatson: yeah, looking into this now
<mborzecki> when maj:min is not passed to snap-device-helper the exit code is 0, while if other parameters are skipped we exit with 1
<om26er> Is it possible to rebuild that image but with a later kernel http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-amd64.img.xz ?
<Chipaca> mvo: ah :-) ok
<om26er> we will be using https://software.intel.com/en-us/openvino-toolkit/documentation/system-requirements and believe a somewhat fresh kernel will be better.
<om26er> that brings me to the question: How far along is UbuntuCore18 ?
<cachio> mvo, hey
<mvo> cachio: hey, good morning
<pstolowski> hmm standups disappeared from my calendar
<ogra> plars, https://forum.snapcraft.io/t/stellarium-plars-not-working-on-nvidia-cards/6685/2 mind merging the PR ? (fix tested on both, intel and nvidia)
<pstolowski> mvo: do we have standups as usual?
<ogra> plars, (happy to drop the depth=1 if needed . (but it is painful for local builds if the git checkout is multiple gigs)
<jdstrand> mvo: I tried to use the new core18 in a vm on friday, but had trouble. it wanted to resize but I didn't know how big it was going to get. I couldn't figure out how to use qemu-img to resize before running without breaking the image
<om26er> ogra: can we rebuild Ubuntu Core 16 amd64 image with latest kernel ?
<om26er> we need Ubuntu Core but minimum kernel requirement is 4.14 for Intel' OpenVINO
<om26er> ref: https://software.intel.com/en-us/articles/OpenVINO-Install-Linux
<ogra> om26er, you can surely build your own kernel snap but for core 16 only 4.4 is officially supported ... you will have to wait for core18 to come out (perhaps you can then combine core 16 with the 4.15 core18 kernel, not sure, thats a question for mvo and if kernel tracks will also be supported in core 16 later)
<om26er> I was thinking if there is way to rebuild the image but not compile the kernel ourselves and pick kernel snaps (pc-kernel) from 18/beta etc
<ogra> jdstrand, it resizes to the pre-defined device size at build time ... u-image should dtrt and you shouldnt need to do anything
<om26er> I guess recompiling won't be a problem, if that's really the only way
<ogra> jdstrand, s/resizes/auto-resizes/
<ogra> om26er, well, mvo released his first experimental core18 image on friday ... you might want to play with that instead
<ogra> jdstrand, if you want to resize yourself, technically just dd'ing zeros to the end of the img should be enough to have core's auto-resize trigger on next boot and resize /writable to full disk size
<ogra> iirc our img's are raw so no qemu-img should be needed, dd should be enough
<om26er> mvo: where can I find that "experimental" Ubunut Core 18 image ?
<om26er> perhaps, I can help test it.
<ogra> om26er, http://people.canonical.com/~mvo/core18/
<om26er> ogra: thanks, do you know of a tentative timeline for core18 release ?
<ogra> before EOY :)
<om26er> we have to do a prototype for a customer and want to make sure we pick the "right" target
<ogra> i guess first stable beta quality images will show up within a few weeks
<ogra> s/stable/usable/
<jdstrand> mvo: fyi, core16 is all approved (I just re-ran the tools-- they've since been updated to allow core16), but you'll have to publish them
<jdstrand> ogra: re u-image: I tried to use the image that mvo created. I then tried to use u-image but couldn't figure out how to make it build a core18 image
<om26er> Interesting, I believe our timeline is tighter, so I will ask on forums how we can compile and bundle linux 4.15 with UbuntuCore 16, before we fallback to ubuntu server image.
<ogra> jdstrand, well, dd (on the uncompressed image) is your friend ...
<jdstrand> ogra: I know they are raw. what I wanted to do is start it in a vm. it said it was autoresizing and I was afraid it was going to resize the raw image to fill my laptop's drive since I'm familiar with the resizing process
<jdstrand> ogra: so, you are saying dd to some other filename?
<ogra> jdstrand, it only resizes the filesystem to full img size
<jdstrand> ogra: yes, which I mentioned I didn't know what it was
<ogra> no, use dd with skip to append to the image
<ogra> whatever you see with ls after unxz ;)
<jdstrand> ogra: it says 3G
<ogra> u-image just zero-pads the img file as well ... if you unxz you'll likely have a 3G img full of zeros
<ogra> right
<jdstrand> ogra: so you're saying it would only resize to that?
<jdstrand> ok
<ogra> so the resize script will resize writable to occupy the "physical" free space of these 3G
<jdstrand> it was taking so long I was worried it was going to be longer
<ogra> nah ... the vm only sees a 3G device
<jdstrand> alright, well I'll try again then
<ogra> and a filesystem thats smaller ...
<ogra> so it just adjusts
<zyga> hey jdstrand, ogra
<jdstrand> hey zyga
 * zyga waves and returns to Flock prep
<ogra> hey zyga ... recovered ?
<zyga> ogra: from holidays? :D
<jdstrand> ogra: you know, I may have let it run and saw another issue
<ogra> :)
 * jdstrand tries again
<zyga> ogra: I wish I had some more but I'm very happy I took the week off
<ogra> so you didnt have to move ? :)
<jdstrand> I eventually want this in a qcow2, but I'll let the resize happen in the raw before converting (the qemu-img convert seemed to mess up the label on the disk)
<sergiusens> cjwatson: yes unfortunately; we had a fixed that ended escalating into a larger design discussion. To make the behavioral change not so surprising, we might just tie this to the use of bases (even adding the build snap still install the build package which is also what we want to solve).
<Chipaca> google:arch-linux-64:tests/main/degraded just failed with https://pastebin.ubuntu.com/p/MX7WqN7xPr/ -- is this something I should just retry?
<mvo> pstolowski|lunch: yeah, standups as usual (in +15min)
<pstolowski|lunch> mvo: yep, thanks, just got all the details from mborzecki
<mvo> jdstrand: re core18> the test image is ~3G iirc but it needs much less space. how big do you want it to be?
<mvo> om26er: you could try to set in your model-assertion: "kernel: pc-kernel=18" which will pull in 4.15. as an experiment thats fine, if you want to support this we should talk :)
<mvo> jdstrand: it takes forever because *drumroll* entropy :(
<mvo> jdstrand: just hit a few keys
<jdstrand> mvo (cc ogra): ah that was it. it drops to an initramfs: "cannot find 'writable' partition
<mvo> jdstrand: uh, thats not good
<jdstrand> all I did was unxz and then tried to launch it under kvm
<ogra> after you used qemu-img on it you men ?
<mvo> jdstrand: ok, let me try that, that should not happen
<jdstrand> no
<ogra> oh
<mvo> jdstrand: anything unusal about your qemu/kvm setup? maybe the kernel has not the right virtio modules or something like this
<jdstrand> let me get you the domain xml
<mvo> jdstrand: fwiw, I ran it with "kvm -m 1500 -snapshot -redir tcp:10022::22 core18.img" and it worked, but let me re-run to double check
<jdstrand> mvo: I did a virsh dumpxml on a bionic vm. then I adjusted to remove the mac, uuid and change the name and image
<jdstrand> I have a whole process surrounding using libvirt, etc, and this is what I typically do for Core 16
<jdstrand> (though with a xenial dumpxml)
<ogra> well, image wise 18 shouldnt differ
<mvo> sergiusens: I sent a small go plugin PR your way, would be great if you could have a look (its tiny)
<ogra> it uses the same u-image tocreate it so the result should be identical
<jdstrand> mvo: https://paste.ubuntu.com/p/3BH6ZxScz2/
 * ogra also never uses libvurt/virsh or whatnot ... i also only use plain kvm 
<ogra> *libvirt
<jdstrand> yeah, like I said, at a future step I convert to a qcow2 and add a snapshot. but I didn't do any of that yet
<jdstrand> actually, there is something about that domain xml. let me try something
<mvo> jdstrand: fwiw https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1783810 is the entropy bug
<ogra> mvo, well, findfs has a 120 sec timeout ... if he runs into "writable not found" thsi is likely before entropy is even used
<jdstrand> mvo, ogra: I was dropped into the initramfs. that is *very* early boot. is it affected by that bug?
<mvo> jdstrand: trying to reproduce right now by setting the drive to virtio
<mvo> jdstrand: I also see a hang now and unable to resolve LABEL=writable
<jdstrand> mvo: interesting. I was able to get it to resize using the regular kvm options, but then I was concerned about how big it would get. i'm no longer worried about that
<jdstrand> (that was last friday)
<jdstrand> mvo: fyi, I tried with defining the domain xml based off of my snappy-16-amd64 domain xml, it it has the same issue (but seems like you identified an issue with virtio)
<jdstrand> mvo: btw, how are you creating this? I tried with ubuntu-image and didn't know how to setup the model assertion
<mvo> jdstrand: I'm in a meeting now but I can reproduce the issue by setting the drive to virtio
<jdstrand> it didn't know about 18, etc
<jdstrand> ok
<jdstrand> mvo: did you see that you need to still publish core16?
<jdstrand> mvo: fyi, I changed it to ide and it is working. I'm unblocked it seems, so please prioritize however you want
<om26er> mvo: that does not work, says "error: cannot download snap "pc-kernel=18": snap not found"
<jdstrand> I then tapped shift a bunch of times to get past crng
<om26er> mvo: here is my model assertion https://paste.ubuntu.com/p/R5YFR4GG8s/
<jdstrand> and I'm off and running
<jdstrand> mvo: thanks!
<om26er> intentionally removed authority-id etc.
<jdstrand> I bet I can configure to qcow2 right off the bat...
<om26er> I ran this command `sudo ubuntu-image -o pc.img -c beta pc.model`
<sergiusens> mvo: commented, but good
<ogra> jdstrand, no, not affected by the entropy bug then ... entropy will only be used later once we switched to the real root... what you were hitting was really the 120sec findfs timeout i think
<jdstrand> ogra: yes, see above. once I used ide, then I hit the entropy bug. I tap shift until it moves along and I'm good
<ogra> yeah
<ogra> entropy issues will be interesting once we have full disk encryption upstzream ;)
<ogra> well ... at that level of the boot that is
<jdstrand> mvo: fyi, 'vi: command not found'. that's pretty stripped down!
<ogra> :)
<jdstrand> no nano either
 * jdstrand wonders what to use
<ogra> sed
<ogra> ;)
<ogra> (we dont have a classic snap for core18 either ... to trash your possible hopes in that direction)
<jdstrand> jeez, echo isn't there either
<jdstrand> this is quite the change
<ogra> snap install extract-deb ...
<ogra> extract-deb.download vim-tiny
<ogra> try that ... and then call vim via the direc extraction path
<jdstrand> well, if you're stripping stuff, you may as well get rid of sensible-editor, cause there is nothing sensible on the system
<mvo> om26er: you need the "edge" core
<mvo> om26er: on the machine you build the image, only the latest core has support for the kernel=track syntax
<mborzecki> pstolowski: if you feel like doing some reviews https://github.com/snapcore/snapd/pull/5561 :)
<mvo> jdstrand: core18 is very minimal, we need a vim snap
<jdstrand> I'm surprised the images are so stripped down. I thought they were supposed to be roughly equivalent to cloud
<mvo> jdstrand: I mean, we really needs snaps for the basic functionality
<jdstrand> and lxd
<mvo> jdstrand: we can add stuff still, not sure how tiny vim-tiny is but if it is actually tiny I think its not too bad to add it
<jdstrand> mvo: we can't have vim witht he current interfaces since can't use classic and they need writes everywhere
<ogra> around 1MB i think
<ogra> it is very small
<ogra> Installed-Size: 1071
<mvo> jdstrand: aha, vim is classic - hm, hm
<jdstrand> I think installing a small editor makes a lot of sense
<ogra> yeah
<ogra> and vim-tiny is a quasi standard on all ubuntus
<jdstrand> I would prefer vim-tiny, but really anything other than sed is good :)
<zyga> jdstrand: nano
<zyga> use nano
<Chipaca> ogra: jdstrand: mvo: clearly it should be mg
<zyga> it's small and useful OOTB
<jdstrand> zyga: it isn't there either
<ogra> nano has deps ...
<jdstrand> but again, surprised at the new direction. last I heard, it was supposed to be similar to the cloud/lxd images
<ogra> (nano uses ncurses ... )
<ogra> vim-tiny is really the way to go here ... also to stay in sync with all the other minimal ubuntu images IMHO
<jdstrand> +1 (fwiw)
<mborzecki> ed?
<Chipaca> jdstrand: can a store assertion allow connecting  snapd-control without it being autoconnected?
<ogra> snap install extract-deb && snap connect extract-deb:home && extract-deb.download --arch amd64 vim-tiny && unpack/usr/bin/vim.tiny
<ogra> jdstrand, ^^^ that works here
<Chipaca> mborzecki: ?
<ogra> (though only tested on core 16)
<mborzecki> Chipaca: s/vim-tiny/ed, i mean there are legends that people used it
<Chipaca> mborzecki: ?
<jdstrand> Chipaca: sure
<mborzecki> Chipaca: small editor for core18 snap
<ogra> i have used sed as defaulkt editor in the past ... but you need echo too
<Chipaca> mborzecki: ?
<jdstrand> ogra: thanks. noted
 * Chipaca quits ed so he can talk like regular people again
<ogra> ppisati, hmm ... are there any known issues with the xenial kernel (beyond the two patches you added that i have already in use locally) https://paste.ubuntu.com/p/Jmg7d43J3h/
<jdstrand> mvo: is there a small non-desktop snap that uses 'base: core18' and listens on the network that you know of? eg, xkcd-webserver for core18?
<Chipaca> jdstrand: would that be a reasonable suggestion to somebody trying to build a store app thing?
<cachio> mvo, 2.34.3 is ready to go to stable
<jdstrand> Chipaca: maybe? we are in the area of clear direction from Gustavo
<cachio> mvo, if you are ok, I could sync with the store team to make it during the afternoon
<jdstrand> Chipaca: and noise. I think the topic should be raised when Gustavo is back
<noise][> jdstrand: agreed - i'd like to find a solution for that, but it's delicate
<Chipaca> I'd like to at least stop this person from even trying to use classic to work around it
<noise][> cachio: we should be fine just about anytime as long as we are not in the middle of a deploy or somehting
<jdstrand> yeah
<noise][> Chipaca: yeah, that doesn't seem like a helpful direction
<cachio> noise][, nice, tx
<jdstrand> Chipaca: well, classic will be denied for the same reason
<ppisati> ogra: i'm building one on LP ATM, i'll let you know how it ends
<jdstrand> I mean, classic is there because of a lack of interfaces or ability to change something
<jdstrand> you can't just use classic because you were denied use of an interface
<Chipaca> ok, replied as much
<Chipaca> in a short sentence
<ogra> ppisati, seems to be the initrd step at the end of the build ...
<mvo> cachio: +1 from me for this
<roadmr> hey folks, is it possible to restrict the amount of bandwidth snapd uses for e.g. automatic refreshes? since it might start refreshing whenever, I'd like to at least ensure it doesn't slow the home network down to a crawl :)
<Chipaca> roadmr: not without a shaping proxy, but you can control when it refreshes
<Chipaca> roadmr: e.g. "once a day between 3 and 5 am",  that kinda thing
<mvo> Chipaca: might be a nice feature to add download limiting, wdyt?
<ogra> +1
<roadmr> right... thanks Chipaca
<Chipaca> mvo: (a) can of worms, (b) i mean one of those 200l oil drums (c) spice-eating worms
<roadmr> rate limiting would be best for me because even if I can timeframe the upgrades, destroying the network is always inconvenient
<ogra> yummy !
<Chipaca> i mean, sure, nice
<roadmr> (and I also don't leave the computer on at times when it's not inconvenient; e.g. 3-5 am I'm fast asleep and the computer is off :)
<mvo> Chipaca: heh, ok
<ogra> sleep slower and leave it on ;)
<Chipaca> mvo: i mean, yes, but it's usually full of little hard corner cases
<roadmr> ah, the "buy a new computer" argument :P no.
<roadmr> hehe ogra j/k, I understand these arguments... just wanted to check if it was something that existed
<ogra> yeah, it doesnt because Chipaca is worm-phobic ;)
<roadmr> leaving this concern out of snapd and relying on e.g. QoS set on the home router makes good sense I think
<Chipaca> mvo: roadmr: one thing we looked at back in u1 days, that was actually easier than bw limiting, was to just not saturate
<mvo> Chipaca: yeah, I understand. it looks like the good people from juju implemented something already, might be worth a look
<Chipaca> that is, look at the number of â¦ packets? frames? i forget the details; something low-level in /proc/something
<roadmr> ahh interesting
<ogra> plars, did you see my ping before ? https://forum.snapcraft.io/t/stellarium-plars-not-working-on-nvidia-cards/6685 ... i'd appreciate a merge of the PR
<Chipaca> roadmr: saying "fix it with QoS" is always the easy answer that users hate
<mvo> iptables could also do it (https://github.com/snapcore/snapd/blob/master/tests/main/econnreset/task.yaml#L7)
<Chipaca> roadmr: (it's also right :-) )
<roadmr> Chipaca: hehe except in this case I'm the user mostly
<mvo> but I think it might be worthwhile to look at integrating the juju/ratelimit thing
<mvo> anyway, after I looked at this core18 "synced" dir stuff :/
<Chipaca>     - google:arch-linux-64:tests/main/degraded
<Chipaca> grrrrr
<plars> ogra: yes, I said I'd take a look. I got slammed with several urgent things as soon as I started this morning. I'll take a look after the meeting I'm in right now
<ogra> plars, ah,m i didnt see any reply (probably because all the freenode blocking due to the spam atm)
<ogra> plars, thanks !
<plars> ogra: heh, yeah it was a spammy weekend for sure. I'm still unburying myself from it. thanks for testing it, I don't have an nvidia system so I was just happy to hear someone else was using it even if it needs a fix :)
<Chipaca> mvo: mborzecki: what can we do about google:arch-linux-64:tests/main/degraded failing all the time? (systemctl status says degraded on arch)
<ogra> plars, well, the fix is tested and all and i have another user in the ubuntu-users ML that can test once it is in edge
<ogra> plars, the only thing i cant test is amd graphics cards but i think they are nowadays just covered by the same setup as intel
<jdstrand> mvo: fyi:
<jdstrand> $ passwd
<jdstrand> passwd: Authentication token manipulation error
<jdstrand> passwd: password unchanged
<jdstrand> mvo: same under sudo
<ogra> sudo passwd -u $USER
<jdstrand> ogra: yeah, that doesn't work
<jdstrand> passwd: password expiry information changed.
<jdstrand> (not the same thing as before, I forgot the -u)
<jdstrand> but still not working
<mborzecki> Chipaca: hm it's reproducible then? it used to happen occasionally
<mborzecki> Chipaca: got a log?
<Chipaca> mborzecki: https://api.travis-ci.org/v3/job/412606238/log.txt
<mvo> jdstrand: looking, I think sergio reported this issue too
<ogra> jdstrand, well, not sure if mvo forgot to use the patched shadow in core 18 ... we have some special packages in the image PPA that we use oin 16 and not all patches were forwarded yet
<jdstrand> that's fine. just fyi
<ogra> if shadow comes from the archive it will try to modify /etc/passwd by default
<mvo> ogra: I think thats it, we are currently not pulling from the ppa
<ogra> yeah
<ogra> there were also some pam hacks to point to extrausers in live-build hooks ... you'll need to carry these over as well
<mborzecki> Chipaca: mvo: looks like gce services failed
<mvo> ogra: yeah, those should be in
<ogra> great
<mvo> ogra: hm, the shadow patch was also pushed to the deb, strange
 * mvo looks deeper
<ogra> oh, wait ... the command order above is wrong ...
<ogra> jdstrand, sudo -u $USER passwd
<ogra> try that one
<mvo> sil2100: did you find out anything about the issue running consle-conf on the pis btw?
<mborzecki> Chipaca: mvo: yeah, so multi-user.target depends on gce services https://pastebin.com/raw/8DBcXJCq, and those fail https://pastebin.com/raw/5strYP8L cachio maybe the image needs an update?
<mborzecki> cachio: you probably need to rebuild gce-compute-image-packages and push an updated image
<ppisati> ogra: https://launchpadlibrarian.net/382085652/buildlog_snap_ubuntu_xenial_armhf_piso-xenial-raspi2-dummy_BUILDING.txt.gz
<sil2100> mvo: still investigating, I have some leads as I saw the 'match' rules being removed by console-conf, but I still didn't dig deeper into why the pi actually even does 'set-name', since it's completely unnecessary - anyway, in progress
<ppisati> ogra: built fine on LP
<mborzecki> Chipaca: mvo: maybe we could blacklist arch in the test for now, wdyt?
<ppisati> ogra: i assume you were building xenial/raspi2, right?
<ppisati> ogra: i mean, it built fine after i applied one more patch on top of it
<sil2100> mvo: just to confirm, you mentioned this is only on the pi3 right now, right? SInce on my amd64 kvm there is no set-name and networking is set up correctly
<Chipaca> mborzecki: how would we not forget to fix it?
<ppisati> ogra: but my build failure was different than what you got
<mvo> sil2100: yeah, on the amd64 this works, let me check what the config looks like
<mvo> sil2100: correct, no set-name there
<mvo> sil2100: I pushed a fix for the pam config that should fix "passwd" on core18 (cc jdstrand and cachio)
<cachio> mvo, great
<mvo> cachio: you add trouble beside passwd on core18? or just that you couldn't set the passwd?
<cachio> mvo, the issue with the resize is stopping the test now
<cachio> it was not happening on friday as frequent as today
<cachio> mvo, by the way, 2.34.3 is stable now
<mvo> cachio: thanks for the stable update
<mvo> cachio: the tests are hanging using the extrnal: mode in spread for core18? or for qemu?
<noise][> cachio: will there be a release post on the forum?
<cachio> external
<cachio> noise][, yes, after the smoke test
<sil2100> mvo: thanks! Looking ;)
<cachio> noise][, mvo smoke test completed
<ogra> ppisati, amd64 ... xenail tree checkount with https://paste.ubuntu.com/p/zMTGd94yfr/ and just calling snapcraft in the toplevel
<ogra> my god ... my typing ...
<ogra> * xenial tree checkout
<ppisati> ogra: check master-next, i fixed that too
<ppisati> ogra: i mean, i fixed kernel snap build there too
<ppisati> ogra: and it didn't make into master yet
<mborzecki> Chipaca: well, then cachio needs to update the images :)
<ogra> ppisati, ahh, thanks ... will check that one then (i just need binder and ashmem in a pc-kernel snap for core 16)
<ppisati> ogra: binder??? are you building an android ubuntu core? :)
<ogra> ppisati, a kiosk image that runs anbox on top of mir-kiosk is the plan
<ogra> and anbox cant run without binder/ashmem sadly
<plars> ogra: it should be in candidate now
<ogra> plars, yeah, i saw, already asking the original reporter to test on the ML
<Chipaca> cachio: is that something you can do, or are you blocked by anything?
<cachio> Chipaca, I think I can do it, checking it
<ogra> plars, it works fine for me (used edge though) ... but i'd like to involve the user before you push to stable so he feels like he contributed to it too ;)
<plars> ogra: +1
<cachio> mborzecki, in which images did you see that?
<mborzecki> cachio: arch, the one used by the tests
<cachio> mborzecki, ok, updating that
<cachio> mborzecki, it takes a it until tests pass
<ogra> ppisati, looking at snapcraft.yaml in master-next i see override-build but not the "kernel-with-firmware: false" line ... is that ok ?
<ogra> (i dont want to waste a full build cycle if any possible)
<ogra> well, running snapcraft anyway ...
<ogra> lets see where this goes
<ppisati> ogra: make install-firmware was removed around 4.7 IIRC, so it's safe not having that line in 4.4
<ogra> ok
<ppisati> ogra: i have a dummy snap build that checks that xenial/master-next is sound
<mvo> jdstrand: I added PR to add vim-tiny to core18, you convinced me
<zyga> mvo: locales-all
<zyga> just sayin
 * zyga takes a break from fedora29 for a sec
<ppisati> ogra: https://launchpad.net/~ubuntu-kernel-team/+snap/xenial-master-next-dummy
<mvo> zyga: hm, hm. yes
<ppisati> ogra: and i've a bionc too
<ppisati> ogra: to guard against kernel snap build failures
<ogra> ppisati, oh, cool
<jdstrand> mvo: woohoo!
<cachio> mborzecki, currently I am updating arch by doing this
<cachio> https://paste.ubuntu.com/p/HTtMVj6cVs/
<mvo> zyga: you are saying with this all our local issues are fixed?
<zyga> mvo: it's a path towards that I believe
<cachio> last one I did few minutes ago produced an image which did not start
<jdstrand> mvo: as a thank you, I think PR 5601 is actually basically ready for review
 * ogra hugs mvo 
<mborzecki> cachio: iirc gce pacakges were installed from aur, you need to build this package
<zyga> I haven't experimented to say what's next but I suspect _then_ we can mostly get locale to click and apps "just" need to ship .mo files (in general)
<jdstrand> https://github.com/snapcore/snapd/pull/5601
<jdstrand> where's the bot?
<ogra> vacation
<jdstrand> mvo: the socketcall() PR. it has system and base checks now
<jdstrand> I'd like to test on powerpc, ppc64el and s390x, but I don't have machines for those
<cachio> mborzecki, I'll make this process manually
<jdstrand> slangasek: hey, are there porting machines for powerpc, ppc64el and s390x that I could use? I'd need root to install/remove/connect snaps and modify/load security policy
<ogra> just expense an ibm z-series for under your desk ...
<jdstrand> slangasek: else, perhaps you (or someone you could direct me to) knows otoh if these architectures use the historic multiplexed socketcall() instead of the individual syscalls
<ogra> (might need to extend the desk legs by a meter though)
<jdstrand> ogra: hehe
<jdstrand> pass
<mvo> jdstrand: thanks, I check out the socketcall pr
<jdstrand> mvo: thanks! fyi, my goal was that where socketcall is known to never be used, drop it (amd64, arm64, armhf), where it is (currently) unknown, keep it (powerpc, ppc64el, s390x) and where it could be dropped (i386), detect that, but keep core16 the same as now
<cachio> mborzecki, I started a vm and when checking the service status it is not on degraded state
<cachio> mborzecki, well, it is degraded
<jdstrand> (and 14.04, since something doesn't work there even though it will have the 4.4 lts kernel and the core snaps should have the new glibc... bit of a mystery, but I didn't dig deep cause I wanted to not remove socketcall anyway)
<jdstrand> mvo: ^
<jdstrand> there* anyway
<mborzecki> cachio: with the new image?
<cachio> mborzecki, no
<cachio> for some reason I created a new image and it didnt start
<cachio> mborzecki, I am creating a new one
<ogra> wiggle the (virtual) cable !
<ogra> Priming kernel
<ogra> Determining the version from the project repo (version-script).
<ogra> The version has been set to '4.4.0-132.158'
<ogra> Snapping 'pc-kernel' /
<ogra> Snapped pc-kernel_4.4.0-132.158_amd64.snap
<ogra> ogra@anubis:~/datengrab/anbox/ubuntu-xenial:master-next$
<ogra> ppisati, ^^^
<ogra> \o/
<ogra> thanks !
<ppisati> ogra: \o/
<jdstrand> slangasek: actually, nm, the glibc sources made it clear
<mvo> Chipaca: 5606 is one idea about the rate-limiting, sorry, couldn't resist (and a nice break from core18). very much rfc state at this point
<Chipaca> mvo: reading it
<Chipaca> mvo: was about to say somethihng about not being able to stop yourself
<Chipaca> :-)
<mvo> roadmr: ^- *if* this gets approval you may get the rate-limiting
<mvo> Chipaca: heh, yeah, I have poor self-control sometimes
<roadmr> \o/ mvo hehe
<mvo> Chipaca: mostly when it comes to tea and code
 * mvo considers dinner
<roadmr> mvo: yay well let's see if it makes it. If not, no problem, it sounded like a nice idea but is no dealbraker or anything
<Chipaca> mvo: :-D
<Chipaca> mvo: for 'snap download' we can set up the context via a commandline option that feeds image.DownladOptions
<Chipaca> anyway, time for a break (somebody said tea)
<sparkiegeek> Chipaca: there's tea?
<cachio> mborzecki, I reverted the last image
<cachio> now it should work
<cachio> mborzecki, I'll continue working on this image after lunch
<om26er> mvo: Hey! in case you missed my replies, pc-kernel=18 didn't work.
<om26er> (sorry if that appeared twice, irccloud said my first message didn't go out as I had to re identify myself)
 * cachio lunch
<Chipaca> sparkiegeek: there was!
<Chipaca> mvo: had you seen https://forum.snapcraft.io/t/weird-error-message-whenever-i-run-the-snap-command/6418?u=chipaca ?
<kyrofa> cachio, any idea why I might be having trouble installing snaps in the armhf autopkgtest runners?
<mvo> om26er: oh, it did not work? what error do you get? (and yes, I missed the earlier message, sorry for that)
<om26er> mvo: error: cannot download snap "pc-kernel=18": snap not found
<om26er> here my my model assertion https://paste.ubuntu.com/p/R5YFR4GG8s/
<mvo> om26er: and what output do you get via "snap version"?
<mvo> om26er: the model looks fine
<om26er> mvo: I think I missed your "you need the "edge" core"
<mvo> om26er: aha, ok :) please try with that one
<om26er> mvo: given linux 4.15 is in beta, shall I ask ubuntu-image to build beta ? (-c beta) ?
<mvo> om26er: core with the needed support will soon (this week) be available via beta
<mvo> om26er: yeah, beta is fine
<mvo> om26er: so just to clarify "snap refresh --edge core; ubuntu-image --channel=beta your-model" hopefully works
<om26er> mvo: I am doing that on my production machine, hopefully core from edge won't break anything (fingers crossed)
<mvo> om26er: it should be fine (famous last words)
<mvo> om26er: but seriously, we test it via spread quite extensively
<mvo> om26er: but yeah, edge is always a bit risky, if its not super urgent, snapd beta should be available soon(ish), maybe even tomorrow
<om26er> fyi guys, ubuntu.com is down
<om26er> and all its sub-domains
<roadmr> om26er: wfm
<om26er> ok, its back now.
<roadmr> om26er: I like https://downforeveryoneorjustme.com/ubuntu.com
<om26er> roadmr: well, I think they just upgraded the website design
<om26er> (ubuntu.com)
<roadmr> om26er: oh you may be right and what you saw was the slight glitch while the agents changed stuff in the matrix^W^W^W^W^W^W^Wservers switched to the new payloads
<slangasek> jdstrand: glad you were able to work it out.  If in the future you do need access to porter hardware with root, we have a shared POWER machine you can get access to (you can ask after it in the Server Team).  z might be harder
<om26er> mvo: that kind of seems to have worked but `snap list` thinks there is no snap installed.
<om26er> the system did boot in kvm
<mvo> om26er: what does systemctl status snapd.service tells you? is that running?
<om26er> mvo: yes, its running
<mvo> om26er: and what does snap changes say?
<mvo> om26er: any errors in there?
<om26er> mvo: https://paste.ubuntu.com/p/9cKmnWqG3g/
<om26er> that "error" is because I cancelled the installation of that "crossbar" snap.
<mvo> om26er: oh, no seeding message? that is strange, it should as task 1 install all the stuff in /var/lib/snapd/seed/seed.yaml
<om26er> mvo: could those be removed because of reboot ?
<om26er> I rebooted once
<mvo> om26er: usually not, the only reason why seed is not run is usually that there is a /var/lib/snapd/state.json
<mvo> om26er: you could remove that file and boot and see what happens, systemctl stop snapd snapd.socket ; rm the file and reboot
<mvo> om26er: need to leave for some minutes but will read backlog
<om26er> sure
<om26er> says "error: no changes found"
<mvo> om26er: very strange, what does /var/lib/snapd/seed look like?
<om26er> mvo: its polluted as I installed another snap which pull core etc
<om26er> let me do a clean run again
<mvo> om26er: this is probably something simple that I'm missing, its just annoying to not know what it is :) (or rather :(
<mvo> om26er: how urgent is this? I could try to build a model assertion based on your json in my morning
<om26er> mvo: https://paste.ubuntu.com/p/DZkkzWFd7H/
<om26er> mvo: sure, not too urgent, so if you could test by tomorrow that would be great.
<jdstrand> slangasek: ack, thanks
<mvo> om26er: yeah, let me try this tomorrow
<ogra> plars, FYI, the user tested ok (complains that the app shows daylight though)
<ogra> so feel free to promote to stable
<plars> ogra: ack, thanks!
<plars> ogra: not sure where you were talking to the reporter, but I have a new one with 0.18.1 in candidate now too. Seems to work ok for me
<plars> ogra: and the app probably showed daylight because it was daytime when they started it, if you want to see what it will look like tonight, you need to fast forward through time to get to the evening hours
<ogra> plars, yeah, i told him ... he answered in the ML thread that i linked from the forum post
<ogra> plars, 0.18.1 works fine on both machines here
 * zyga preps for the flight in the morning, ttyl
<slangasek> Chipaca: hmm, where do you see that systemd-detect-virt is using fscaps?
<Chipaca> $ getcap /usr/bin/systemd-detect-virt
<Chipaca> /usr/bin/systemd-detect-virt = cap_dac_override,cap_sys_ptrace+ep
<slangasek> I don't see that on bionic, is it xenial-only?
<Chipaca> I haven't looked at bionic, this machine is xenial
<slangasek> yeah, seems that's gone in bionic
<Chipaca> still will have to chase it down for 16
<Chipaca> but it's probably fine
 * slangasek nods
<Chipaca> slangasek: https://pastebin.ubuntu.com/p/HmbbMBZ8mY/
<Chipaca> fwiw
<Chipaca> in bionic traceroute6.iputils is u+s instead
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> and g'night :-)
#snappy 2018-08-07
<zyga> Good morning!
<zyga> Iâm heading to Flock
<zyga> Have a great day everyone, I will be partially offline until I arrive at the conference
<zyga> Pharaoh_Atem: I solved the hang in âinfoâ
<zyga> You have to install âfilesystemâfirst, then subsequent installation of info and anything else works fine
 * zyga straps in his seat
<zyga> See you in Frankfurt :-)
<mborzecki> morning
<zyga> Good day from Frankfurt
<zyga> Hey mborzecki, mvo asked to say he will be back at around 10:30,
<mborzecki> zyga: hey, safe travels :P
<mborzecki> zyga: sure, do you know if cachio has updated arch images yday?
<zyga> I donât know about that, sorry
<mborzecki> zyga: how was your flight to fra?
<zyga> Short :-)
<zyga> About an hour and a half
<mborzecki> hehe
<zyga> Now some time for breakfast and then onwards to Dresden
<mborzecki> zyga: is there no train you could take from waw?
<zyga> Yeah, 9 hrs
<zyga> I wanted to for a moment
<zyga> But then again 9 hours and much mi
<zyga> Much more expensive
<mborzecki> zyga: heh ;) trains, anyways hope you have a great time there and lots of interesting f2f talks
<pstolowski> mornings
<mborzecki> wow, binutils on arch is borked atm, making valgrind failing with most peculiar way https://paste.fedoraproject.org/paste/p4z3kuDHXR5nZ~cMg99XRg/raw
<mborzecki> pstolowski: heya
<zyga> Hey PaweÅ:-)
<pstolowski> zyga: train more expensive? surprised
<ondra> zyga hey
<ondra> zyga dunno if you had time, but I hit yesterday with two machines "snap-update-ns failed with code 1" error
<ondra> zyga seems to be related to layout
<zyga> No, ondra I didnât have any time yet. Iâm making demo snaps and flocking this week
<zyga> Maybe ask Maciej and PaweÅ for help
<ondra> zyga yeah, though to give you head up as you are layout master :)
<zyga> Call me âmaster yogaâ
<mborzecki> zyga: you plannoning to go on exile? :)
<mborzecki> if anyone feels like doing some reviews, https://github.com/snapcore/snapd/pull/5605 snap-device-helper unit tests
<zyga> I am heading to Dagobah to balance the force of deb and rpm ;-)
<mborzecki> zyga: feels more like tatooine in this weather :)
<Chipaca> buongiorno, principesse
<mborzecki> Chipaca: hey
<Chipaca> mborzecki: <badly dubbed>jak siÄ masz dzisiaj?
<Chipaca> mborzecki: <mouth finishes moving five seconds later>
<mborzecki> Chipaca: can practice that in bru
<Chipaca> mborzecki: if i get my passport back in time
<Chipaca> (hey for all i know it's waiting for me when i get back home) (hah yeah right)
<zyga> Chipaca: extra credits for e-ogonek :-)
<Chipaca> zyga: Ç«Ç«Ç«Ç«Ç«hÌ¨hÌ¨
 * Chipaca liked having an mvo around
<Chipaca> :-D
<Chipaca> mvo: morning!
<pstolowski> mvo: hey, i've addressed your comments to https://github.com/snapcore/snapd/pull/4940 ; it seemed you verbally approved, can you take another look / approve?
<pstolowski> mvo: and good morning btw!
<zyga> Good morning again mvo
<mvo> Chipaca: good morning! and good morning to pstolowski  and zyga
<mvo> pstolowski: I have a look in a wee bit
<mvo> sorry for being a bit late this morning
<pstolowski> mvo: thanks!
<Chipaca> mvo: everything a'ight?
<mvo> Chipaca: yeah, school started again thats all
<mvo> Chipaca: I guess that counts as "no" ;)
<Chipaca> mvo: ah! gotcha
<Chipaca> mvo: do you guys have more school days, or are your holidays different?
<Chipaca> the boys still have another month, here
<mvo> Chipaca: I'm not sure, we have 6 weeks in summer
<zyga> mvo: how can school start in August?
<Chipaca> mvo: and that ended today?
<zyga> We still have a month left
<mvo> Chipaca: correct
<zyga> Ouch :-)
<mvo> zyga: it started super early this year, no idea why
<Chipaca> zyga: learning in 35C builds character
<mvo> zyga: each german "state" has a different schedule so that the autobahn is not congesteted all the same time
<zyga> Chipaca: testing in 35C also builds character ;-)
<mvo> Chipaca: ha! correct
<zyga> S/testing/resting/
<Chipaca> zyga: in particular, character U+2668
<zyga> Hahahhahaha
<mvo> zyga: yeah, this year is very unfortunate timing
<mvo> lol
<mvo> zyga, Chipaca: how long is summer vac for you guys?
<Chipaca> mvo: it varies slightly from place to place, but last week of july to first week of september, ish
<Chipaca> mvo: ~6 weeks also I guess
 * mvo nods
<zyga> Mvo: about 9 weeks
<zyga> All of July and August
<zyga> And also small parts of June an September
<Chipaca> mvo: I don't know if you saw, but systemd-detect-virt uses fscaps in xenial, and we strip xattrs on core, meaning core's systemd-detect-virt might not work properly for users
<mvo> zyga: nice
<mvo> Chipaca: aha, was that in the forum? or here on irc?
<mborzecki> and if you're at universty and don't slack off too much you get 12+ weeks of vacation
<Chipaca> mvo: email
<zyga> mborzecki: indeed :-)
<Chipaca> mvo: (on the 'fscaps for erryone' thread)
<mvo> Chipaca: what can we do about it? whitelist systemd-detect-virt from the stipping?
<zyga> Transition between high school and uni is very shocking in this regard
<Chipaca> mvo: for xenial, figure out if it's a problem first :-)
<Chipaca> mvo: I'm only poking you about it because osutil/squashfs/fstype.go has your name all over it
<Chipaca> mvo: if that's only used from snapd (i.e. from root), then we don't need to worry at all
<mborzecki> zyga: could you https://github.com/snapcore/snapd/pull/5605 ? :)
<mvo> aha, good
<Chipaca> mvo: oh and errtracker
<Chipaca> mvo: for core20, we need to chat with jdstrand at some point, and then plan on how to support this, but there's probably plenty of time :-)
<mvo> Chipaca: heh, just like with core18 ;)
<mvo> Chipaca: but yeah, sounds like a plan!
<Chipaca> (this is assuming it gets the go-ahead, which seems likely)
<zyga> mborzecki: can I voice it here? I donât have network on my laptop
<Chipaca> mvo: i forwarded you an email i sent to the list that hasn't made it through, where i outline the things i could think of that needed doing (not in enough detail for us, but for 3rd parties)
<mborzecki> zyga: yeah
<mvo> Chipaca: cool, thanks for this!
<Chipaca> mvo: sometimes i forget to forget to manage
<Chipaca> :-)
<mvo> Chipaca: heh :)
<mvo> Chipaca: we know about your secret identity
 * Chipaca hides in shame
 * mvo hugs Chipaca 
 * Chipaca hugs back
<zyga> mborzecki: looks good to me
<zyga> Sorry for not doing it there, 2FA + airport
<mborzecki> zyga: np
<mborzecki> zyga: thanks for reviewing it while at the airport :P
<mvo> pstolowski: approved, can I merge it?
<pstolowski> mvo: yes, thx!
<mvo> pstolowski: congrats, that was in the works for a while, nice to see it landing!
<pstolowski> mvo: well, yeah, but it's still just the foundation. anyway, glad to see it landing!
<pstolowski> mvo: if you're in the mood of udev-related reviews, this is relatively simple and needs 2nd review - https://github.com/snapcore/snapd/pull/5505
<mvo> pstolowski: sounds good, I put it on my list
<pstolowski> ty
<ogra> ppisati, hmm
<ogra> ogra@localhost:~$ ls /snap/pc-kernel/current/
<ogra> System.map-4.4.140+  bzImage-4.4.140+  firmware  initrd-4.4.140+.img  initrd.img  kernel.img  meta  modules
<ogra> ppisati, when did we stop shipping the config ?
<ogra> ppisati, (the pc kernel snaps do not have /proc/config.gz enabled by default either)
<mborzecki> pstolowski: thanks for the review of 5605, updates pushed
<pstolowski> mborzecki: +1
<ppisati> ogra: uhm, i'm not sure
<ogra> ppisati, we should have at least one method to get info about the running config ... iirc the arm kernels simply enable IKCONFIG ... we should do that too for the source built ones
<ogra> (just by setting it in snapcraft.yaml i think)
<ppisati> ogra: kconfigflavour: snapdragon
<ppisati> ogra: we use the same config as the packaged kernel
<ppisati> ogra: i think the snapcraft kernel plugin doesn't simply copy that file
<ogra> yeah
 * zyga evacuates
<pstolowski> mborzecki: i'm looking at https://github.com/snapcore/snapd/pull/5594 ; i'm probably missing something, but why do we need to create instance-specific env vars and have snap-confine re-create them under old names?
<ogra> mvo, hmm, did we regress xdg-open/user-open in core ? i get errors all of a sudden for apps that call xdg-open
<ogra> i think this worked yesterday
<mvo> ogra: there was a update for core yesterday (if you run stable). can you please try "snap revert core" and see if that fixes it?
<ogra> doing ...
<mvo> ogra: what core rev are you currently running?
<ogra> installed:   16-2.34.3                (5145) 91MB core
<ogra> updated yesterday apparently
<mborzecki> pstolowski: because we want to make snp instances transparent to applications and pretend it's running as <snap> instead of <snap>_foo, SNAP_NAME, SNAP, SNAP_COMMON and so on environment variables are the same as it was a <snap> (atm those are <snap>_foo)
<ogra> hmm
<ogra> Uncaught Exception:
<ogra> Error: Command failed: xdg-open undefined
<ogra> user-open error: no such file or directory
<ogra> even after rollback
<mborzecki> pstolowski: iow SNAP_INSTANCE_* will reflect <snap>_foo, while the regular SNAP_* will prented as if it's <snap>
<ogra> thats weird
<mborzecki> pstolowski: and s-c will does some magic to make it happen so :P
<pstolowski> mborzecki: aaah ok, i get it now, had to look at the code agin, thanks
<ogra> mvo, so checking core, xdg-open is available everywhere ... and has the same content ... looks more like there is an issue with "snapctl user-open" somewhere
<ogra> could the desktop side of it be the issue ?
<ogra> ogra@acheron:~$ snapctl user-open foo
<ogra> user-open error: no such file or directory
<ogra> (not sure if you can even call it that way, but the error is the same if i do)
 * zyga is still evacuating, veeeery slowly
<mborzecki> https://github.com/snapcore/snapd/pull/5607 actual s-d-h with parallel installs
<pstolowski> mborzecki: is the revision and version common for all instances of same snap?
<mborzecki> pstolowski: no, each instance is separate
<pstolowski> mborzecki: right, i misread the code, thanks again
<mvo> ogra: hm, hm, I am not familiar with the canpctl user-open side, only xdg-open
<zyga> Iâm waiting to rebook my flight
<ogra> mborzecki, was it you who worked on the amdgpu support in the opengl interface ?
<mborzecki> ogra: nope, i worked on fixing nvidia
<ogra> (i had assumed amdgpu is in the standard paths nd wouldnt need special casing like nvidia does)
<ogra> ah, ok
<ogra> did we have anyone working on amdpu at all ?
<ogra> *amdgpu
<mborzecki> ogra: looking forward to working on it once the prices drop to a resonable level for those 2 yrs old gpus
<mvo> zyga: what happend?
<ogra> heh
<mborzecki> pstolowski: updated the spread test in https://github.com/snapcore/snapd/pull/5594
<pstolowski> ty
<mborzecki> pstolowski: if you feel like doing some more reviews, could you take a look at https://github.com/snapcore/snapd/pull/5561 ?
<pstolowski> mborzecki: yes, will do
<mborzecki> pstolowski: thanks
<mborzecki> hmm trying snapcraft on arch, so far the biggest hurdle is lxd setup
<mborzecki> lxd has a custom fork of sqlite3 now?
<mvo> mborzecki: yes
<mvo> mborzecki: with distrubition iirc
<mborzecki> mvo: i'm rebuilding it from aur now, used snaps first but lxd init --auto failed setting up bridge iface
<mborzecki> cachio: did you manage to sort it out with arch image yesterday?
<cachio> mborzecki, hey, yes
<cachio> mborzecki, did you see the error again?
<mborzecki> cachio: did you update the image or switched to an older one?
<mborzecki> cachio: no, no errors today :0
<cachio> mborzecki, initially switched to an old one
<cachio> then I created a new one
<cachio> mborzecki, but basically there was 2 problems
<cachio> when I switched to the old image, we had another error as well
<mborzecki> cachio: yeah, i think glibc & python was updated yesteday and brought in a bunch of rebuilds
<cachio> mborzecki, also the shadow service was failing
<cachio> this was producing the state = degraded
<cachio> apart of this, the google compute engine package needed a rebuild
<cachio> and also an uninstaller
<mvo> cachio: we can blacklist the test on arch too if needed (cc mborzecki) - I mean, if its too hard for arch to boot correctly ;)
<cachio> mvo, hehee
<mvo> cachio, mborzecki but seriously, I think its fine to backlits until its fixed on the image
<cachio> mvo, the image is already fixed
<cachio> mvo, I did it yesterday
<cachio> mvo, did you see the error today?
<mvo> cachio: oh, okay, sorry I think I misread the previous sentences. I (incorrectly) read that its still an issue. if all is fixed just ignore me
<cachio> :)
<mborzecki> mvo: https://paste.ubuntu.com/p/WzXRzbKDWJ/ the log is empty
<Chipaca> mvo: i can confirm the warnings pipeline pr is green because arch is no longer failing that test
<Chipaca> fwiw
<mvo> mborzecki: hrm, not a lot of log :(
<mborzecki> mvo: yeah, whole 2 lines
<mvo> Chipaca: cool, thanks for confirming
<mvo> mborzecki: :(
<mborzecki> any clue why tests/main/security-devpts is connecting physical-memory-observe iface?
<sergiusens> mvo: added some comments to your PR, I can help out with the mocking if you want
 * sergiusens ð
<zyga> Hey, guess what
<zyga> A am taking the train after all
<zyga> Mvo: trains in Germany are pretty â¬â¬â¬&
<mvo> sergiusens: in a meeting right now I check it out after the next meeting
<mvo> zyga: yes
<mvo> zyga: also late
<mvo> zyga: and sometimes very hot
<mvo> zyga: but â¬â¬â¬â¬ as well
<zyga> 105â¬ for Frankfurt nah Dresden
<mvo> zyga: woah, yeah - how many hours?
<zyga> Nach?
<mvo> zyga: from fra -> dresden - how long will you travel
<zyga> No idea yet
<mvo> zyga: should be 4:15 direct
<zyga> ICE 1653
<mvo> zyga: which is quite nice
<Chipaca> zyga: also they announce them wrong so you get into the one going the wrong way
<mvo> zyga: and its on time
<mvo> zyga: it should be a very nice train
<zyga> Perfect
<zyga> Just no luggage :-(
<mvo> zyga: uh, what happend at the airport?
<mvo> zyga: you should also have wifi on this train
<mvo> zyga: fwiw, *if* you know in advance and book the train a couple of days ahead of time you get a discount usually. but I guess this was not planed :/
<zyga> T1 was evacuated
<zyga> Airport is shut down
<zyga> No planes, no luggage
<Chipaca> zyga: who farted?
 * Chipaca ever the professional
<zyga> Well
<zyga> Rolls eyes
<ogra> Chipaca, am i reading that right, you are establishing professional farting ?
<ogra> zyga, enjoy frankfurt then :/
<mborzecki> jdstrand: should we enforce that appname as passed to snap-device-helper has a snap_ prefix?
<jdstrand> mborzecki: yes, definitely
<mborzecki> jdstrand: ack
<jdstrand> mborzecki: well, put another way. we should not remove snap_. it would be nice to have a little check in there to enforce it
<jdstrand> we don't enforce it now, but we should
<mborzecki> jdstrand: btw. any clue why snap-device-helper exits with 0 if maj:min is not passed?
<jdstrand> mborzecki: that was in the original implementation. I think with the way the tagging works, udev might call out to it for specific operations which aren't an error condition, but we'd like to ignore
<zyga> mvo: od the Core 18 meeting IP?
<zyga> Up
<zyga> As in are we doing it
<jdstrand> mborzecki: I don't remember the details otoh. mvo *may* (it was included in his first commit, but we're talking 3+ years ago)
<mborzecki> jdstrand: fair enough, i've accounted for that in the test
<cachio> mvo, error: cannot download snap "pc-kernel=18": snap not found
<cachio> any idea what happened with the kernel snap?
<mvo> cachio: please make sure your core snap is coming from the "edge" channel
<cachio> mvo, sorry, I refreshed from stable yesterday :)
<cachio> to test the new core in stable
<mvo> zyga: the Core18 meeting did not happen, the most relevant people are on vac
<mvo> cachio: no worries
<mvo> cachio: we need to make sure this code lands in beta and candidate etc soon :)
<mvo> cachio: its a useful reminder
<cachio> mvo, yes, thanks for that, building image now
<mvo> cachio: good luck
<kenvandine> In doing a dist-upgrade on 18.04, the update hung and i see this in the journal
<kenvandine> https://paste.ubuntu.com/p/7CqFfDts7P/
<kenvandine> parse error in a yaml
<kenvandine> maybe the seed.yaml got messed up during the dist-upgrade and is blocking restarting snapd?
<kyrofa> Hey mvo, adding fuse to our debian/tests/control allowed us to get further, but it really just changed the error: https://pastebin.ubuntu.com/p/pVtNGPnfpq/ . Any thoughts?
<mvo> kenvandine: could you pastebin the seed.yaml and also the timestamp of the seed file?
<kenvandine> https://paste.ubuntu.com/p/zZKCmSGFyT/
<mvo> kenvandine: did you dist-upgrade form 16.04 -> 18.04 or was that a 18.04->18.04 upgrade?
<kenvandine> that's the last couple lines of stdout during the dist-upgrade
<kenvandine> 18.04->18.04
<mvo> kenvandine: what do you see with snap changes?
<kenvandine> error: no changes found
<sergiusens> kenvandine: looks like broken yaml
<mvo> kyrofa: hm, this tricky, this is running the snapd tests inside an lxd container?
<kyrofa> mvo, just installing a snap is all
<mvo> kyrofa: what security is selected for this container, I remember an issue about it, let me see if I can find details
<kyrofa> mvo, I'm not sure, autopkgtest is a bit of a black box to me
<mvo> kyrofa: yeah, depending on the configuration of the container this might not work because of apparmor
<mvo> kyrofa: also, what version of ubuntu is the host running?
<kenvandine> mvo, http://paste.ubuntu.com/p/ssxXhh5R5R/
<kyrofa> mvo, also no idea, I'm afraid. We can hope back to ubuntu-devel to discuss
<sergiusens> mvo: echo -e of kenvandine's output http://paste.ubuntu.com/p/MPXRpW3Xb2/
<mvo> kyrofa: let me try to find the relevant forum topic
<mvo> sergiusens: heh, thank you
<mvo> kenvandine: it looks like there is a single "gnome-3-26-1604_64.snap" in the middle of the yaml
<mvo> kenvandine: at line 51 of the pastebin
<mvo> kenvandine: aha, multiple ones - at line 30 as well
<mvo> kenvandine: I'm not aware of snapd writing to this file except when it is used with "snap prepare-image". is that something one of the distro tools are doing? also seeding should only happen if there is no /var/lib/snapd/state.json
<sergiusens> kyrofa: finally happy with the snap injection thing
<kenvandine> mvo, no idea :)
<mvo> kenvandine: what is the mtime of this file?
<sergiusens> going to send out a link your way for overview before I chore down on the endless list of unit tests this might require
<kenvandine> looks like it's appending
<mvo> kenvandine: can you grep for "seed.yaml" in /var/lib/dpkg/info/*.{post,pre}inst ?
<kenvandine> mvo, nothing
<kenvandine> so maybe this was there before
<kyrofa> sergiusens, awesome
<mvo> kenvandine: what do you see in "snap changes"?
<kenvandine> error: no changes found
<kenvandine> mvo, but.. i just re-crafted the seed.yaml file
<kenvandine> and restarted snapd
<mvo> kenvandine: ok, with that it should be seeding now
<mvo> kenvandine: would love to know where the corrupted file came from
<kenvandine> and now snap changes says lists a couple initializing
<kenvandine> mvo, well.. could be my fault :)
<kenvandine> this was a test image from the desktop-preinstalled work we did with microsoft :)
<kenvandine> the hyper-v image
<mvo> kyrofa: I talked to zyga and I think the issue is that when lxd is run as a privileged container and it is restricted further with apparmor the snapd assumptions about what it can do do not work. I don't think there is anything on our side we can do unfortunately
<mvo> kenvandine: ok
<mvo> kenvandine: good luck in any case
<kyrofa> mvo, so you think this is a privileged container?
<mvo> kyrofa: its my best guess so far
<kyrofa> That would surprise me, but I'll ask
<mvo> kyrofa: the error looks a bit like this: Permission denied; attempted to load a profile while confined?
<mvo> )
<kyrofa> (just given how locked down these things tend to be)
<mvo> kyrofa: this looks like there is a restricting profile around the container already
<mvo> kyrofa: fwiw, we do not run our autopkgtests tests inside containers. we do test basic lxd support by installing snaps in the default lxd container though
<kyrofa> mvo, yeah, we have a test suite to make sure we can build snaps and they run as expected, and they work everywhere except armhf! Haha
<kyrofa> mvo, interesting observation, let's see what steve says. I wish this wasn't all so opaque
<mvo> kyrofa: yeah, sorry
<mvo> kyrofa: quick question about snapcraft - I have a testfialure "would reformat /root/snapcraft/snapcraft/plugins/go.py" what re-format tool do you use ?
<mvo> kyrofa: i.e. what should I run?
<mvo> kyrofa: to fix it
<sergiusens> kyrofa: https://github.com/snapcore/snapcraft/commit/68506c11c81fdcffc783ddfdf10b5692651d6d8c
<sergiusens> mvo snap install black --edge --devmode; black .
<mvo> sergiusens: ta
<sergiusens> mvo: we took the gofmt route for python, a nice addition to end useless discussions
<mvo> sergiusens: thanks, updated the PR based on your latest suggestion, but no new mocks
<mvo> sergiusens: yeah, I'm a huge fan (now) of auto code format
<mvo> sergiusens: I just was not sure what tool I have to use
<sergiusens> I can add the mocks
<mvo> sergiusens: that would be lovely if you don't mind
<sergiusens> indeed, I don't agree with the formatting a 100%, but it is just a matter of getting used to
<mvo> sergiusens: yeah, the diff looks a bit unusual (just did the reformat) but then its fine, consistency++
<sergiusens> the site explains how it reformats to minimize future diffs (or make them more obvious)
<mvo> pstolowski: I have some feedback in 5505 - looks good some ideas in the PR, I will likely play around with it some more after dinner
<pstolowski> mvo: ty!
<mvo> pstolowski|afk: sorry, I got a bit carried away. here is my ideas around the parsing, we can leverage the go scanner to make the scanning more tailored to us: http://paste.ubuntu.com/p/5BPDSjTSK9/ (the diff http://paste.ubuntu.com/p/pPB5sfJxHP/)
<cachio> mvo, core18 getting stuck https://paste.ubuntu.com/p/Yv7ZpKzQHT/
<cachio> mvo, both 1md64 nd i386
<cachio> it is starting
<cachio> mvo, this is the full outputhttps://paste.ubuntu.com/p/v8qB25DXGg/
<cachio> https://paste.ubuntu.com/p/v8qB25DXGg/
<mvo> cachio: looks like entropy
<mvo> cachio: is that spread?
<cachio> mvo, no, I just started kvm with the core18 image
<cachio> this is the output
<mvo> cachio: try to enter some keys
<mvo> cachio: in the console
<mvo> just type random stuff
<cachio> nothing happensw
<mvo> cachio: do you see the keys echoed in the terminal?
<mvo> cachio: this is probably https://launchpad.net/ubuntu/+source/util-linux/2.31.1-0.4ubuntu3.2
<mvo> cachio: it usually works when pressing keys a bunch of times, then at some point "crng initialized" is printed
<cachio> mvo, I'll try it
<cachio> I already have it installed
<cachio> mvo, same command line to create the vm?
<mvo> cachio: getting the fix is non-trivial unfortunately, the initrd in the kernel snaps needs an update
<mvo> cachio: so you need to mount the image, then unpack the squashfs, then unpack the initrd, then cp the fixed libuuid.so.... into the initrd, repack that, repack the snap, run the image
<cachio> mvo, do we have the libuuid.so already fixed?
<mvo> cachio: yes, its in the package of util-linux in bionic-prposed
<cachio> mvo, ah, ok
<mvo> cachio: you can extract it from the deb via e.g. dpkg-deb -x
<cachio> mvo, ok
<mvo> cachio: good luck! if you are successful please add it to the bug that this got validated on core18
<cachio> mvo, sure, thanks for the support
<mvo> cachio: yw, sorry that its so bumpy still
<zyga> Hey
<zyga> I just arrived
<zyga> 7:10->21:17
<zyga> ENOLUGGAGE
#snappy 2018-08-08
<zyga> Good morning
<mborzecki> morning
<zyga> Hi
<mborzecki> zyga: hey
<mvo> zyga: hey ! how if flock?
<mvo> hey mborzecki
<mborzecki> mvo: mornings
<mborzecki> zyga: yeah, how's flock? you're gonna miss the morning yoga class
<zyga> So far things are very hot because not much a/c
<zyga> I was drying my clothing ;-)
<zyga> How are things
<zyga> When is the next release?
<mvo> zyga: beta this week I think
<mborzecki> hmm running into some problems with snapd under lxd on arch (quite a combo)
<mborzecki> snapd actually works again after i made the container privileged, but i see an odd issue with reloading udev rules
<mborzecki> https://paste.ubuntu.com/p/xpK7vgfsMG/
<zyga> Hey mvo
<zyga> Flock is just starting
<zyga> Looking forward to the release
<mborzecki> zyga: good luck :)
<pstolowski> morning
<mvo> zyga: cool, yeah, looking over the open PRs right now
<mvo> pstolowski: hey, good morning
<mborzecki> so udevadm control --reload-rules fails with status 2, but no output
<mvo> pstolowski: not sure if you got my message from yesterday, I got a bit carried away when reviewing the udevadm output parser. hope its ok
<pstolowski> mvo: yes! thanks for the review and for playing with it! i'm on it
<mvo> pstolowski: I really like the go scanner customization possiblities, its pretty simpel but quite powerful at the same time
<mvo> pstolowski: anyway, happy that you find it interessting
<mborzecki> and installing any snap that triggers udev rule reload fails too
<mborzecki> mvo: could you take a look at https://forum.snapcraft.io/t/error-cannot-assert-container-build-on-arch-linux-fails/6655/7 ? who would know more about udev & lxc?
<mvo> mborzecki: sure, looking
<pstolowski> mvo: addressed your feedback to #5505
<mvo> pstolowski: thank you! this looks great, I went over it in full again and added some more small ideas but feel free to ignore
<mborzecki> something wrong with travis job queue? builds seem to be stuck
<pstolowski> mvo: thanks again; updated
<mvo> pstolowski: very nice! thank you. lets merge it once its green
<pstolowski> yay
<mvo> pstolowski: nice job, lots is landing right now
<mborzecki> there's also a bunch of snapcraft jobs queued up so there's that :)
 * Son_Goku waves
<mthaddon> popey: who would be right person to ask for a review of https://github.com/snapcrafters/sentry/pull/8/files ?
<Chipaca> mvo: https://errors.ubuntu.com/?release=Ubuntu%2016.04&period=day <-fun
<zyga> mborzecki: hey, is instance work something that is ready to be demonstrated?
<mborzecki> zyga: maybe, you can grab it here https://github.com/snapcore/snapd/pull/5596 , some caveats though, you can install only one snap from the store using _<foo> name, but you can snap install --dangerous --name snap_foo as many as you like
<zyga> That is ok
<mborzecki> zyga: things may be rough aroudn the edges, but installing, removing, running should work
<zyga> I plan to do locally built demos
<zyga> Thanks
<mborzecki> zyga: ping me when you need help
<zyga> Thank you
<mvo> Chipaca: uh, all  ERROR [daemon-reload] failed with exit status 1: Failed to execute operation: Connection timed out ?
<mvo> Chipaca: i.e. have you looked at the details yet?
<mvo> Chipaca: thats the stable core refresh interacting badly with the amazon linux agent?
<Chipaca> mvo: the ones I looked at, the syslog seemed bad
<ppisati> sergiusens: i'm not a python expert, but i can't install black on my xenial box
<ppisati> https://pastebin.ubuntu.com/p/wnvmdp8HRq/
<ppisati> if i pip search, i can see it, but i'm unable to install it
<Chipaca> mvo: but, yes, all amazon-ssm-agent
<ppisati> is it beacuse it requires python 3.6.0+?
<mvo> Chipaca: any hints what goes on that triggers the bug?
<ppisati> sergiusens: but then we are implicitly requiring python 3.6.0+ for the entire snapcraft project then
<Chipaca> mvo: no
<mvo> Chipaca: hm, the random one I just looked at has "Aug 08 10:23:53 ip-10-0-136-110 kernel: INFO: task setfont:701 blocked for more than 120 seconds."
<mvo> Chipaca: within a kernel oops
<Chipaca> mvo: same in all the ones i saw
<ppisati> yep, my feeling is that we moved the requirement to 3.6.x:
<ppisati>  python3-dev | 3.5.1-3          | xenial          | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<ppisati>  python3-dev | 3.6.5-3          | bionic          | amd64, arm64, armhf, i386, ppc64el, s390x
<mvo> Chipaca: very strange, I wonder what is going on there
<popey> mthaddon: sorry, missed the ping. me, now.
<cachio> mvo, hey, yesterday I tried to mount initrd but I couldn't
<zyga> Hey hey
<zyga> Still alive and kicking
<zyga> Some interesting observations coming from Flock
<zyga> Some plenaries left, them more individual sessions
<cachio> mvo, https://paste.ubuntu.com/p/tpqnJW5VVD/
<mthaddon> popey: fantastic, thanks
<Chipaca> cachio: i thought you couldn't mount initrd
<cachio> Chipaca, yes, I couldn't
<cachio> Chipaca, any idea how to do it?
<Chipaca> cachio: what does âfile /home/sergio/test/lab/kernel/initrd.imgâ say?
<cachio> -rw-r--r-- 1 root root 9684891 jul 31 08:45 initrd.img
<cachio> Chipaca, which info do you want?
<Chipaca> cachio: the output of âfile /home/sergio/test/lab/kernel/initrd.imgâ :-)
<Chipaca> cachio: âfileâ is a command
<cachio> Chipaca, hehe, sorry, /home/sergio/test/lab/kernel/initrd.img: ASCII cpio archive (SVR4 with no CRC
<cachio> yes, I read fast and did not understand it
<om26er> popey: ping https://github.com/snapcrafters/android-studio/pull/32
<popey> om26er: merged :)
<Chipaca> cachio: so, âcpio -t < /home/sergio/test/lab/kernel/initrd.imgâ to list it, âcpio -x < /home/sergio/test/lab/kernel/initrd.imgâ to extract it, etc
<Chipaca> cachio: (man cpio)
<cachio> Chipaca, tx
<cachio> I'll try it
<om26er> popey: thanks, need your eyes on https://github.com/snapcrafters/android-studio/pull/28 as well, that automates releases of android studio
<Chipaca> cachio: mvo: if there's a way to _mount_ initrd, I don't know it
<Chipaca> cachio: if you have 'mc' installed, you can rename it to foo.cpio and navigate it with that
<Chipaca> cachio: or with gvfs (e.g. nautilus)
<Chipaca> ah
<Chipaca> cachio: you can mount it with gvfs, of course
<cachio> Chipaca,  I am trying to extract it , replace a file and pack it again
<Chipaca> cachio: mounting it with gvfs won't help because  it doesn't support writing  to it
<cachio> Chipaca, I am trying to replace libuuid.so but I can't find it
<cachio> it is not indice the initrd.img
<Chipaca> cachio: not the .so on its own, just the .so.1 and .so.1.3.0
<Chipaca> (at least in the one i have here)
<cachio> libuuid.so.1
<Chipaca> cachio: that'll be a symlink to the .1.3.0
<cachio> Chipaca, but I dont have any
<Chipaca> cachio: where is this initrd from?
<cachio> Chipaca, it is from the core-18 image for amd64
<Chipaca> cachio: the one on people.canonical.com?
 * Chipaca downloads that
<cachio> Chipaca, no, I built it by using ubuntu-image
<Chipaca> cachio: ok, i'll look at the one on p.c.c first
<Chipaca> :-)
<cachio> Chipaca, I think I'll need to use it as well
<mborzecki> pstolowski|lunch: Chipaca: updated https://github.com/snapcore/snapd/pull/5561
<mborzecki> that's one annoying PR there :)
<sergiusens> ppisati: snap install black --edge --devmode
<sergiusens> ppisati: btw, mind taking a look https://github.com/snapcore/snapcraft/pull/2202 ?
<pstolowski> hmm what's ogoing on with travis.. still struggling?
<sergiusens> ppisati: and no,we still require xenial, it is just a tool we depend on that requires a newer python, so it has been snapped, the hacking docs have been updated to reflect that too
<ppisati> sergiusens: the github page for black said it required 3.6.0+, hence my assumption
<ppisati> sergiusens: another question - after i git clone the snapcraft repo, nothing happens if i invoke bin/snapcraft
<ppisati> sergiusens: sergiusens i mean, i don't get any output
<ogra> it probably prints black on black, change the terminal bgcolor :P
<ppisati> ogra: :(
<Chipaca> ppisati: did you read HACKING.md, about using venv?
<ppisati> Chipaca: yep
<ppisati> Chipaca: i'm in venv
<Chipaca> ppisati: no output at all, but it just returns? or does it hang?
<ppisati> Chipaca: https://pastebin.ubuntu.com/p/tZbytBjtG7/
<mvo> cachio: let me look at this initrd now in core18
<Chipaca> sergiusens: hola
<Chipaca> sergiusens: https://pastebin.ubuntu.com/p/tZbytBjtG7/ <- ppisati hates you
 * Chipaca throws everybody under the bus
<sergiusens> ppisati: pip install -e .
<cachio> mvo, sure
<cachio> mvo, I checked in the initrd inside the kernel
<sergiusens> Chipaca: yeah, we changed this back then when we decided to support snapcraftctl IIRC. I do not know why we have that bin file still
<cachio> mvo, which is inside the core 18 image
<sergiusens> kyrofa: do you recall?
<mthaddon> popey: thanks for the review. What would be the schedule for publishing an updated snap for that?
<ppisati> sergiusens: oh ok, it took the working snapcraft directory, made a pip package and installed it
<sergiusens> ppisati: yeah, you can easily work in editing mode by doing "pip install -e ."
<ppisati> sergiusens: so if i modify the src code, and i invoke snapcraft, it'll invoke my modified src code - i guess that's the meaning of editing mode
<sergiusens> ppisati: exactly
<ppisati> sergiusens: ok, i have all i need now, thanls
<ppisati> *thanks
<mvo> <mvo> cachio, Chipaca aha, I remember now what the issue is/was with your initramfs - the kernel now concats multiple ones after each other but cpio will only "see" the first one in this mode. this is why it looked so tiny probably
<mvo> <mvo> cachio: this makes working with it even more of a PITA of course
<mvo> (sorry got disconnected)
<cachio> mvo, ahhh
<cachio> mvo, are you going to fix that?
<cachio> mvo, or how should I make to extract the correct initramtd
<cachio> initrd
<Chipaca> mvo: what can I milestone #5613 to?
<mvo> cachio: I'm on it right now
<mvo> cachio: half way there (hopefully)
<mvo> Chipaca: yes please
<cachio> mvo, great, thanks
<Chipaca> mvo: wat
<mvo> Chipaca: you mean wat about the multiple initrds?
<mvo> Chipaca: or a different "wat"?
<Chipaca> mvo: no i mean: "what can I milestone #5613 to?" "yes"
<mvo> Chipaca: I set the milestone to 2.35 now, hope thats ok
<Chipaca> mvo: yes :-)
<mvo> Chipaca: I hope we won't need another 2.34
<mvo> *fingers crossed*
<Chipaca> mvo: I just wanted to know what to target it to :-) sorry for the confusion
<mvo> Chipaca: no worries, its still very hot :)
<mvo> Chipaca: also multiple initrds inside squashfs inside an image make my head spin a little
<mvo> Chipaca: but I think I got it under control now
<Chipaca> mvo: https://en.wikipedia.org/wiki/Yo-yo_de-spin
<popey> mthaddon: actually the build failed.. https://build.snapcraft.io/user/snapcrafters/sentry / https://launchpad.net/~build.snapcraft.io/+snap/17fc91e19f932bd8a75175923b533019-xenial/+build/296424
<mvo> Chipaca: woah
<Chipaca> mvo: next time you need to look at multiple initrds inside suqashfs inside an image, grab two yo-yos
<Chipaca> :-)
<popey> I learn so much useful stuff via this channel :)
<ogra> mvo, just use multiple initramfs lines in grub.cfg
<ogra> ... now i scared him
<popey> om26er: will add the android studio pr to the to-do list, thanks
<Chipaca> mvo: when does 2.35 close?
<mvo> Chipaca: the first pre-image today but there is no reaoson not to cherry-pick selected PRs
<mvo> Chipaca: especially since it looks like travis is rather busy currently
<Chipaca> heh
<mvo> cachio: http://people.canonical.com/~mvo/tmp/core18-amd64-18-alpha20180803-with-lp1783810.img.xz
<mvo> cachio: that seems to be working for me
<mvo> cachio: I replaced the initramfs there
<cachio> mvo, excelent, thanks
<mvo> meh, network is a bit unreliable today
<mvo> <mvo> cachio: if it works for you, please mark 1783810 as verified
<mvo> cachio: did you write anything after this?
<ogra> that didnt even get through
<mvo> ogra: heh, thanks
<cachio> mvo, it is working now
<cachio> it gets stuck like 2 seconds and then it continues
<mvo> cachio: with the updated image?
<cachio> mvo, yes
<mvo> cachio: great
<cachio> mvo, but it is taking so long to contact the store
<mvo> cachio: I think we can mark the bug as sru-validated then
<cachio> it is trying to create the user
<mvo> cachio: meh, this delay is probably real entropy :/
<mvo> cachio: I mean, for the store we need real entropy afaik
<mvo> cachio: we may need to investigate solutions like polinate
<cachio> mvo, it restarted and I ran console conf again
<cachio> and it created the user
<mvo> ok
<cachio> mvo, still https://paste.ubuntu.com/p/vfCr3yw836/
<mvo> cachio: did you refresh core18 and the other bits from edge?
<mvo> cachio: i.e. please run "sudo snap refresh --edge core18"
<cachio> mvo, in progress
<mvo> cachio: ta
 * Chipaca takes a break
<kyrofa> sergio doesn't seem to be around, but Chipaca, ppisati that file is only for Windows packaging. bin/snapcraftctl is what was needed for snapcraftctl
<kyrofa> If you want to run snapcraft from source, install it into a venv
<cachio> mvo, after refresh core18
<cachio> the system reboots
<cachio> but in the console I don't see the reboot
<mvo> cachio: no reboot message there? hm, hm
<cachio> and I can't connect to the vm anymore
<mvo> cachio: anything in the terminal?
 * mvo tries to reproduce
<cachio> well, It did it
<cachio> but took much more than usual
<cachio> mvo, currently running the tests using external
<cachio> mvo, let's see how it goes
<zyga> kyrofa: hey
<zyga> kyrofa: how do I upload a snap snans snapcraft?
<cachio> mvo, it is so weird how it did the reboot
<zyga> or how do I tell snapcraft to upload a snap it did not build
<mvo> cachio: hm, the image may be problematic
<mvo> cachio: because the kernel snap is modified the seeding may not work
<kyrofa> zyga, you can't anymore, store removed that capability
<cachio> mvo, in parallel i'll continue doing manual test for this image
<kyrofa> ... I think
<kyrofa> Yeah, looks like it
<zyga> kyrofa: what do I need to do to upload a snap that snapcraft did not build
<zyga> kyrofa: I can share the makefile I use
<kyrofa> zyga, you can still use snapcraft to push it
<zyga> nope, I tried
<zyga> it crashes
<kyrofa> How so?
<zyga> boom https://www.irccloud.com/pastebin/Kbk2VkV1/
<zyga> not sure why it wants to remove anything
<zyga> or why it cares
<zyga> I gave it a snap.yaml
<zyga> er
<zyga> a *.snap file
<kyrofa> zyga, it needs to know the snap name, so it unpacks the meta/snap.yaml
<zyga> there is no snapcraft.yaml in the tree
<zyga> ok
<kyrofa> But permissions seem odd. How did you create this snap?
<zyga> cat Makefile https://www.irccloud.com/pastebin/hdHBMAuP/
<zyga> tip: this requires fedora to run
<zyga> or dnf that you don't have on ubuntu to be precise
<zyga> note that I even use a "prime" directory
<zyga> [zyga@faroe fedora29]$ ls -ld prime/meta/snap.yaml
<zyga> -rw-r--r--. 1 root root 1297 Aug  8 17:08 prime/meta/snap.yaml
<zyga> the snap.yaml is
<zyga> cat snap.yaml https://www.irccloud.com/pastebin/6IJSmdR6/
<kyrofa> zyga, huh, can you share that snap with me?
<zyga> sure
<zyga> any ideas how
<zyga> there was that thing for sharing files
<popey> wormhole
<kyrofa> zyga, people.canonical, or magic wormhole
<zyga> I forgot to sync my ssh key so I don't have access to my personal stuff
<kyrofa> Haha, hi popey
<zyga> I'll use wormhole
<popey> wormhole ftw
<zyga> thank you popey :)
<popey> np
<zyga> kyrofa: I sent you wormhole command to run
<kyrofa> zyga, receiving now
<kyrofa> Done. That really is magical
<zyga> woah
<zyga> indeed :)
<zyga> I'm using snapcraft as a snap
<zyga> in case that matters
<mvo> cachio: ok, yeah, the reboot is strange
<cachio> mvo, is it related to the entropy?
<ogra> sil2100, is there any ETA when the new features (gadget connections) will land in the ubuntu-image snap so we can actually make use of them ?
<ogra> (i see the code landed since a while)
<mvo> cachio: slowness may well be related, did you update the kernel as well or kept that? please try to keep the kernel as it has the fixed initrd
<zyga> kyrofa: any ideas?
<zyga> kyrofa: I'd like to upload that snap
<zyga> to edge
<kyrofa> zyga... I can't explain this. Run `unsquashfs -d /tmp/foo/ fedora29.snap -e meta/snap.yaml`
<zyga> k
<kyrofa> zyga, you'll see you own /tmp/foo/meta and everything
<kyrofa> But you can't delete it without sudo
<zyga> kyrofa: that worked
<kyrofa> I thought maybe it was an ACL thing, but it doesn't seem so
<zyga> that's correct!
<zyga> I cannot remove it
<ogra> mvo, hmm, looking at #5612 there needs to be some more AI in it ... i.e. on devices where pivot-agent is installed you want that snap to be set up first (to not waste time before a model pivot happens (which includes a factory reset) ) but i.e. on systems where pivot-agent and NM are seeded you want NM to be seeded before pivot-agent ... etc etc
<kyrofa> zyga, what DEMONS did you put on my machine
<zyga> one sec
<zyga> I think I know
<ogra> mvo, you'D want that to happen somewhere between your 2 and 3 in that enumeration
<zyga> kyrofa: actually
<zyga> not yet :)
<zyga> it is _very_ interesting
<kyrofa> zyga, right?!
<zyga> it's on tmpfs here
<zyga> so not even xattrs
<sil2100> ogra: hey! I planned to release u-i 1.4 this week, I guess that's still more-or-less possible
<ogra> sil2100, awesome, i just wanted to make sure the snap isnt forgotten (i dont use any deb for u-image anymore ... and i guess most of my collegaues dont either)
<kyrofa> zyga, anyway, if you can manage to get to the bottom of that, snapcraft should happily upload this for you
<zyga> kyrofa: I think I know
<zyga> can you ls -ld meta
<zyga> followed by ls -ldZ meta
<zyga> doh
<sil2100> ogra: it won't be forgotten! I'll actually promote 1.4 to stable finally this time, since usually that wasn't part of the process
<zyga> kyrofa: it's not what I put
<zyga> the /tmp/foo directory is not writable!
<zyga> kyrofa: it's snapcraft :D
<zyga> kyrofa: chmod +w /tmp/foo
<zyga> "daemons" :D
<kyrofa> zyga, what the heck. unsquashfs makes that dir, but this works for other snaps
<zyga> kyrofa: so ... why is it read-only?
<kyrofa> zyga, if I run that same unsquashfs command on, say, the snapcraft snap, it's writable
<zyga> oh
<zyga> a possible hint
<zyga> dr-xr-xr-x. 19 root root     4096 Aug  8 15:59 prime
<zyga> I'll tweak that
<kyrofa> Oh interesting
<kyrofa> That must be saved somewhere in the image
<zyga> yeah
<zyga> since prime is the rootfs
<zyga> it is not writable for some reason
<zyga> (not sure wh)
<kyrofa> Indeed
<zyga> trying now
<zyga> man, that's an obscure one :)
<kyrofa> That error message was NOT helpful
 * zyga hugs kyrofa 
 * kyrofa hugs zyga back
<zyga> apparently that's how / is set up on fedora
<zyga> it's not root writable
<kyrofa> That's interesting
<zyga> is / writable by root on ubuntu?
<ogra> mvo, i actually commented on #5612
<mvo> ogra: thanks, thats useful information. note that it won't change any snap ordering if the snaps are not bases or content providers so you can control the order via required snaps. it will just enforce certain things for special types like bases
<ogra> zyga, classic ? sure
<zyga> kyrofa: pushed :)
<zyga> processing
<zyga> mvo: now I need your super-powers :)
<mvo> zyga: what for?
<kyrofa> zyga, nice!
<zyga> mvo: for fedora29 snap, let me see if it actually gets blocked
<zyga> still in processing
<ogra> mvo, yeah, i'm just wondering if we should perhaps have a "seed priority" value you can give to snaps or some such ... beyond the order in required-snaps so the handling of bases could take that into account ... the prob appreas to be very complex now that bases are a thing :)
<ogra> *appears
<mvo> ogra: yeah, its definitely complex
<ogra> i tried to explain it in the comment ...
<zyga> it's still processing
<zyga> roadmr: hey
<zyga> roadmr: is there a way to check if a snap processing task on the store is stuck / crashed for whatever reason
<zyga> roadmr: I just submitted one for "fedora29"
<roadmr> hi zyga !
<roadmr> zyga: is that the snap name?
<roadmr> zyga: we *are* checking a situation with snaps getting stuck :(
<zyga> roadmr: yes
<zyga> it's a 29M snap that is processing for a few minutes now
<sil2100> mvo: btw. I tried latest subiquity from git and sadly it doesn't work, so for now I cherry-picked the branding fixes and pushed that into a PPA
<zyga> it's been made on fedora manually so maybe dragons apply
<zyga> it's a base snap
<mvo> sil2100: ta
<roadmr> zyga: let me have a look
<zyga> thank you
<sil2100> mvo: Michael mentioned console-conf from subiquity master isn't really usable right now
<mvo> sil2100: did you figure anything about about the interface issue on the pis? I would love to build pi images soon(ish) but this is a blocker right now
<mvo> sil2100: (not the only one though)
<roadmr> zyga: I see *no* uploads for fedora29 snap :( that may mean it got rejected even before hitting the database
<zyga> roadmr: whoah?
<zyga> how is that possible
<mvo> zyga: what message did you get from the store?
<zyga> I see fedora29.snap 100% uploaded and a spinning processing marker
<roadmr> zyga: what are you using? snapcraft?
<zyga> it's hard to copy paste from the console but it is processing
<zyga> yes
<zyga> no change still
<zyga> I can abort and retry
<zyga> but ... no idea
<roadmr> zyga: no, please hold on a second
<zyga> oh
<zyga> I just did :<
<roadmr> :P
<zyga> https://www.irccloud.com/pastebin/z7UDGHnq/
<mvo> zyga: do you happen to know if there is a way to ask apparmor for current capabilities? I want to find out if I have mac_admin
<zyga> although it's not done yet, the process is alive still
<popey> zyga: https://forum.snapcraft.io/t/degraded-performance-snaps-stuck-in-automated-review/6736
<zyga> mvo: I don't know if there is a way
<popey> you are probably being hit by this, but roadmr is the best one to help :)
<zyga> thank you
<mvo> zyga: aha, I htink I found code in lxd for this
<mvo> zyga: heh, that looks promising
<roadmr> zyga: fedora29 is crashing the scan / reviewer tools appparently
<zyga> roadmr: how?
<roadmr> zyga: getting yo more details
<zyga> jdstrand: ^
<roadmr> aha interesting, zyga jdstrand this should be reproable locally
<roadmr> Permission denied: '/tmp/tmp14k8ex/unpacked/usr/lib/snapd
<roadmr> apparently the snap has some funny perms which the tools can't properly clean up
<zyga> looking
<kyrofa> zyga, hahaha, you're breaking EVERYTHING
<zyga> it's just 755
<zyga> roadmr: do you have a traceback that would help jdstrand?
<roadmr> sure, just a sec
<roadmr> zyga, jdstrand : https://pastebin.canonical.com/p/wrmWdbh7yk/
<zyga> thank you
<zyga> jdstrand: can you please look at that, maybe I can tweak the snap somehow
<roadmr> zyga: do you have a local copy of the reviewer tools? maybe you can run it and check?
<zyga> no, I don't
<roadmr> zyga: hehe :) https://launchpad.net/click-reviewers-tools/trunk, conversely if you let me have a copy of the snap I can run that
<zyga> roadmr: I can wormhole the snap to you
<sil2100> mvo: apologies it's taking so long, still digging into it and I'll know more tomorrow for sure
<mvo> sil2100: thank you, no worries, sorry for nagging so much
<zyga> roadmr: can you please telegram me once you have something?
<roadmr> let me see if I can
<mvo> kyrofa: could you please run the following https://play.golang.org/p/ttDizCrhv6q
<mvo>  inside your pi lxd env?
<roadmr> zyga: can you tg me so you appear in my list of contacts?
<roadmr> zyga: oh sorry, that traceback has *nothing* to do with the reviewer tools :(
<zyga> sure
<zyga> oh?
<roadmr> nono, it's all the *store* code trying to clean up and failing because some of the unpacked files have funny permissions it seems
<roadmr> let me try
<kyrofa> mvo, doing now
<roadmr> zyga: indeed the permissions look fine :( I'll check again in a bit, need to afk
<kyrofa> mvo, both with and without the raw.lxc I get `1 0 errno 0`
<Chipaca> kyrofa: does snapcraft support bases?
<Chipaca> as in, doing the right thing wrt building against the appropriate glibc?
<Chipaca> asking as the last time I checked it didn't (you had to use passthrough), but  users are asking :-)
<kyrofa> Chipaca, not quite yet. We're using build VMs to support different bases, and that work isn't completely finished yet
<kyrofa> Chipaca, sergiusens might have a branch for you to experiment with though, if you're interested
<Chipaca> kyrofa: nah, it's answering a user's complaint: "The base key of snapcraft.yaml and itâs possible values are not documented"
<Chipaca> kyrofa: i'm finding a polite way of replying "duh"
<kyrofa> Hahaha
<kyrofa> Yeah that's our biggest roadmap item this cycle, it'll be a bit yet
<Chipaca> kyrofa: BUT WHY ISN'T IT DOCUMENTED YET
<Chipaca> kyrofa: :-D
<Chipaca> jdstrand: remember yesterday we were talking about core18 on 14.04? (I think it was yesterday, in the context of the socket multiplex thing)
<Chipaca> jdstrand: https://forum.snapcraft.io/t/cannot-perform-readlinkat-on-the-mount-namespace-file-descriptor-of-the-init-process-permission-denied/6743 might be relevant to that
<sergiusens> Chipaca: you did not read my post http://blog.sergiusens.org/posts/snapcraft-build-environments/ ?
<Chipaca> sergiusens: "read my blog"?
<Chipaca> sergiusens: I wonder why my rss reader didn't pick it up
<sergiusens> Chipaca: it is about the progress, it is also a forum post ;-)
<sergiusens> Chipaca: but what is this about? I just didn't read it all in here, too much traffic :-)
<Chipaca> sergiusens: a user complaining about the lack of documentation for a feature that isn't done
<Chipaca> sergiusens: in their defence, everybody is excited about bases
<sergiusens> Chipaca: I know, the availability of bases is however being gated as the introduction of build environment
<Chipaca> sergiusens: no complaints from me :-)
<Chipaca> most people are only going to come to the feature excited for the first time once
<Shibe> is gnome-builder available as a snap?
<ogra> https://snapcraft.io/store
<ogra> specifically: https://snapcraft.io/search?category=&q=gnome-builder
<popey> Shibe: not that I'm aware of
<ogra> (i guess thats a "no")
<popey> It's certainly been suggested, but nobody has done it
<popey> ^ kenvandine :)
<Shibe> how hard it is to make snap?
<Shibe> if i compile gnome-builder in gentoo how much effort would it take to make a snap of it i can use on ubuntu?
<Chipaca> Shibe: very tricky, because the libs will probably be all wrong
<kyrofa> mvo, just wanted to verify that you got my output
<kenvandine> popey, it would be easiest as a classic snap
<mvo> kyrofa: thanks for the test run, that looks like I need to take another appraoch, oh well
<jdstrand> Chipaca: I actually do not remember that. I remember I submitted a pr that made it so that socketcall would be there unconditionally on 14.04
<jdstrand> Chipaca: and conditionally in other situations
<jdstrand> Chipaca: I responded to that forum topic
<Chipaca> jdstrand: rock on
<jdstrand> Chipaca: it is probably a variation of https://forum.snapcraft.io/t/custom-kernel-error-on-readlinkat-in-mount-namespace/6097/21, which has a fix in trunk and 2.34, but not 2.34.3
 * Chipaca sees a "I've asked John to ..." and gets nervous
<jdstrand> roadmr: I see the update on status; does that mean resquashs is reenabled?
<roadmr> jdstrand: I haven't reenabled it, let me just triple-check the incident report to ensure it's safe to do so
<jdstrand> roadmr: yeah, I read that too and it wasn'
<jdstrand> t clear to me
 * cachio afk
<roadmr> jdstrand: resquashfs enforcement enabled!
 * jdstrand hugs roadmr :)
#snappy 2018-08-09
<mborzecki> morning
<mborzecki> mvo: morning, i'm working with interfaces repo now, do you know if plug/slot ordering is of importance there?
<mvo> mborzecki: unfortunately I don't
<mvo> mborzecki: what are we currently doing?
<mborzecki> mvo: the Slots()/Plugs() methods of repo do sorting by plug and snap name, with instance names looking like foo_bar the plugs/slots from instance snaps are always sorted after the regular ones
<mvo> mborzecki: aha, right. I think its fine but lets validate with zyga
<mborzecki> mvo: ok
<mborzecki> btw. DeepEquals tends to blow up in those repo test when there's a mismatch
<mvo> mborzecki: blow up in what way?
<mvo> mborzecki: isn't the new diff stuff helping?
<mvo> mborzecki: or not good enough?
<mborzecki> mvo: the test binary is oom killed
<mvo> mborzecki: woah
<mborzecki> mvo: oh, maybe it's the diff
<mborzecki> sie 09 08:09:15 corsair kernel: Out of memory: Kill process 27003 (interfaces.test) score 685 or sacrifice child
<mborzecki> sie 09 08:09:15 corsair kernel: Killed process 27003 (interfaces.test) total-vm:8926256kB, anon-rss:8325200kB, file-rss:4kB, shmem-rss:5400kB
<zyga> Good morning
<mborzecki> zyga: hey, how's flock?
<zyga> mvo, mborzecki: how can I help?
<zyga> mborzecki: very interesting
<zyga> I will write my day one report after breakfast
<mborzecki> zyga: quick question, do you know whether the ordering of results in interface repo .Plugs()/Slots() method of impotance? with instances named foo_bar they get always sorted after non instance-keyed snaps
<zyga> It was just designed to be deterministic
<zyga> If you want to change that please look at how the results are used
<zyga> Some code relies on this fact
 * zyga uploads fedora29 snap again
<zyga> (with some workarounds)
<zyga> ok, it just failed on type: base and some setuid root executables
<zyga> mvo: I'll neuter all the +s flags for now
<zyga> mvo: and re-upload
<zyga> would you be OK acking the snap with just the type: base violation?
<mvo> zyga: ok
<mvo> zyga: sure, should be ifne
<zyga> mvo: https://dashboard.snapcraft.io/snaps/fedora29/revisions/3/
<zyga> mvo: I don't know how to request manual review otherwise
<mvo> zyga: its in
<zyga> awesome, thank you!
<pstolowski> mornings
<mborzecki> pstolowski: heya
<sil2100> mvo: hey! Can you upload the pi3 image somewhere for me to look at? Need to confirm something
<sil2100> mvo: a fresh pi3 image at best
<sil2100> (unconfigured yet)
<mvo> sil2100: sure, let me look at this
<zyga> mvo: hey,
<zyga> mvo_: can you please do a small test for me
<zyga> mvo_: would you mind trying the fedora29 snap (--edge) and then hello-fedora snap (stable) to see if it works on your system
<mvo> zyga: http://paste.ubuntu.com/p/97KmYZft6S/
<zyga> woah, interesting
<mvo> sil2100: uploading
<zyga> thank you, I need to think about this now
<zyga> mvo: did you have any magic environment set up, LD_PRELOAD for instance?
<mvo> zyga: I'm not aware of any, there is a defualt LD_PRELOAD for some window decration stuff but that is harmless
<zyga> aha
<Son_Goku> yay, the first time when we have incompatible ABI signatures :D
<zyga> the path is interesting
<mvo> zyga: I think if you symlink /var/lib/snapd/snap to /snap in the fedora base things will work
<zyga> why: /var/lib/snapd/snap/hello-fedora/4/meta/snap.yaml
<mvo> zyga: because snap-exec detects its inside fedora
<mvo> zyga: and it expects the fedora layout
<Son_Goku> mvo, that shouldn't be necessary, though?
<zyga> hmm
<mvo> zyga: thats my guess at least
<Son_Goku> zyga: mvo is actually correct
 * zyga explores
<Son_Goku> we actually discovered this the first time I was working on this last year
<Son_Goku> that's why mvo sent me a patch for my tool to actually add that
<mvo> Son_Goku: I did? woah, I don't even remember
<Son_Goku> yeah
<zyga> I'm not sure that's really the case yet
<Son_Goku> the one and only time you've ever sent me a patch ;)
<mvo> *cough*
 * mvo hugs Son_Goku 
<sil2100> mvo: thank you!
<zyga> mvo: does snap run --shell hello-fedora also fail?
<Son_Goku> mvo, this was all you: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap/blob/master/mkrpmdistcoresnap#L122-132 ;)
<mvo> zyga: yes, in the same way
<zyga> ok, thank you
 * zyga tries something
<mvo> sil2100: please try http://people.canonical.com/~mvo/tmp/pi-kiosk.img
<zyga> it's a bug in snap-confine
<zyga> I will work around it for now
<zyga> uh
<zyga> not easy
 * zyga needs to think
<mborzecki> zyga: isn't that the same thing that we had on amazon?
<mborzecki> zyga: fwiw 'Hello Fedora!' here on arch
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/5614
<pstolowski> mborzecki: will do
<zyga> mborzecki: thank you :)
<zyga> mborzecki: I think there are issues when we mis-identify things in snap-confine
<zyga> my preference is that all bases agree that /snap exists
<zyga> not as a symlink
<zyga> and snaps are mounted there
<zyga> oh well
<zyga> I need to move now, I'll check back soon
<mborzecki> zyga: sounds like we could teach s-c a new trick
<zyga> What is on your mind mborzecki ?
<mborzecki> 2018-08-09 09:04:40 Cannot allocate google:ubuntu-16.04-32: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout
<mvo> stgraber: hey, if you are around, is there a way to set "lxc.aa_profile=unconfinged" with lxd 3.0? trying my detection code currently and my machines are all bionic already
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/5616 ifacestate fix
<pstolowski> looking
<pstolowski> +1
<zyga> o/
 * Son_Goku waves
<mborzecki> another simple review https://github.com/snapcore/snapd/pull/5619 (cc pstolowski )
<pstolowski> mborzecki: on it, does it pass all unit tests?
<mborzecki> pstolowski: yes
<pstolowski> awesome
<pstolowski> i was afarid we accidently relied on it somewhere :/
<mborzecki> heh, i hope not :)
<zyga> mborzecki: hey
<mborzecki> zyga: hm?
<zyga> I have a patch coming up, just fighting github auth
<zyga> one moment :)
<zyga> t's the fix we were talking about
<mborzecki> ah, ok
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5620
<zyga> have a look
<zyga> with this the hello-fedora snap should work on ubuntu
<mborzecki> zyga: yeah, +1 as far as I'm concerned
<zyga> I'm adding a spread test
<zyga> and one more patch
<zyga> mborzecki: I pushed two more patches
<zyga> can you sanity check them please
<zyga> niemeyer: once you have some time it would be good to update spread snap, it's out of date and cannot even parse our spread.yaml now
<mborzecki> pstolowski: spread test for interfaces https://paste.ubuntu.com/p/PmJdPvR2hp/ (amazingly this all works locally, even with the content provider)
<pstolowski> mborzecki: nice, will take a look, ty
<zyga> mborzecki: really nice :D
<zyga> can someone manually run tests against https://github.com/snapcore/snapd/pull/5620
<zyga> for some ballpark works/doesn't qualification
<zyga> ubuntu + fedora + that one new test
<zyga> I don't have a working spread setup here
<zyga> I'll check back later in case anyone does o/
<mvo> zyga: /proc/self/attr/current is "unconfined" in my container when it can't load apparmor profiles with apparmor_parser -a
<mvo> zyga: I will use a workaround and prepare a pr
<stgraber> mvo: lxc.apparmor.profile=unconfined
<mvo> stgraber: thank you!
<mborzecki> zyga: running on ubuntu 18.04, fedora & arch
<zyga> mborzecki: thank you
<zyga> mvo: interesting
<zyga> mvo: and when you load a profile, what happens?
<zyga> what is the error you get
<zyga> mvo: and what is the profile of snapd from _outside_
<zyga> or profile of bash inside a container
<zyga> stgraber: does that also disable stacking or is stacking controlled with a separate knob?
<stgraber> zyga: that also disables stacking
<zyga> stgraber: I see
<zyga> stgraber: does lxd use something other than apparmor?
<zyga> seccomp?
<stgraber> zyga: so in that case, you're not confined but also don't have mac_admin/mac_override so can't affect the host apparmor namespace
<zyga> ah
<zyga> I see
<stgraber> zyga: we have seccomp too, yeah, and caps
<zyga> and libcap cannot tell that?
<zyga> I mean, can we ask the kernel about our caps/
<zyga> instead of loading a profile
<mvo> zyga: hm, from outside it is also unconfined afaict
<zyga> mvo: yes, that's consistent and expected based on what stgraber said
<mborzecki> zyga: 2018-08-09 16:12:05 Successful tasks: 3
<zyga> mborzecki: thank you!
<zyga> mvo: another data point: gconv translation functions for fringe encodings are huge
<zyga> and I suspect we need at most 2-3
<mborzecki> pstolowski: i've pushed the spread to the integration branch right here https://github.com/snapcore/snapd/pull/5596/commits/f846ea192d89f98c4b8c8b4036a935ef47589e53
<zyga> mvo: can you please ensure that the patch I sent is in 2.35
<zyga> it's pretty essential for now
<kyrofa> Hey mvo, did you manage to make any progress on discovering apparmor capabilities in snapd?
<mvo> kyrofa: yes
<mvo> kyrofa: I have a reproducer and work on code now
<kyrofa> mvo, ah, wonderful!!
<zyga> Chipaca: fun bug: snap refresh --jailmode doesn't
<zyga> it's not switching it
<Chipaca> zyga: fun bug: neither does --devmode nor --classic
<Chipaca> zyga: you  could almost say it might not be a bug :-D
<zyga> Chipaca: snap install --jailmode foo refuses to work when foo is classic!
<Chipaca> zyga: (OTOH if we don't do anything maybe we should error or sth)
<Chipaca> zyga: at your request iirc
<zyga> Chipaca: just dropping a note in case I forget, live feedback from flock
<Chipaca> :-) nice
<Chipaca> zyga: keep 'em coming
<sil2100> mvo: hmmm, would you be able to somehow get on a pi3 core18 running system and find me all the .yaml files that are on there? Since something's really fishy around here
<sil2100> mvo: I unpacked and checked the image you gave me and found nothing suspicious - the only way console-conf could put the 'set-name' into the config is by copying it over from the source configs
<sil2100> mvo: and there's just one source config on the squashfs that I see and it's correct
<sil2100> hmm, let me try one more thing though
<mvo> sil2100: this bug prevents logging in so its slightly tricky, what I did was pulling out the sd card and mount it after I interacted with the system. does that work or are there still no files in there if you do that?
<sil2100> mvo: wait one more moment, I'll get back to you once I check something else out on the filesystem
<zyga> kyrofa: hey
<zyga> kyrofa: can you please try building github.com/davdunc/aws-cli-snap please
<zyga> kyrofa: we're hitting an issue where apt fails on lack of --allow-unauthenticated
<zyga> kyrofa: is there a cache with a choot container or something
<zyga> kyrofa: can we clean something on the host
<zyga> kyrofa: to "maybe" fix it?
<jdstrand> mvo: hi! are you planning a 2.34.4? this is in 2.34 branch, but not 2.34.3 snap/deb: https://github.com/snapcore/snapd/pull/5579
<mvo> jdstrand: the plan is to have a beta of 2.35 soon (today or tomorrow moring). no further plans for 2.34 unless something critical somes up
<jdstrand> well, that works too
<mvo> cachio: the lxd test currently only runs on 16.04-32 - can we enable it again on more arches?
<jdstrand> mvo: I've got some profile updates that I'd like in 2.35. when do you need them by?
<jdstrand> mvo: early next week is best for me, but if required, I can do it sooner
<mvo> jdstrand: the first beta goes out this week but profile updates are fine until it hits candidate so at least a week
<mvo> jdstrand: next week is fine
<jdstrand> ok, perfect
<jdstrand> mvo: thanks!
<mvo> jdstrand: we will just need to cherry-pick them
<mvo> jdstrand: thank you
<mvo> kyrofa: fix is ready I'm just working on the spread test now but manual testing looked good
<jdstrand> mvo: that socketcall PR. should I target it to 2.35 too? it isn't pressing to me personally so long as it gets into trunk, but not sure of the relationship between 2.35 and core18 images
<mvo> jdstrand: please target it
<jdstrand> mvo: ok
<kyrofa> mvo, that's great! Let me know if I can help
<mvo> jdstrand: what apparmor permissions are needed for doing "aa_kernel_interface_new()"?
<cachio> mvo, I forgot to share the errors
<cachio> https://paste.ubuntu.com/p/JRt3rkPTgY/
<mvo> cachio: ta
<cachio> mvo, I am working in other set based on test fails
 * Chipaca kicks travis
<Chipaca> ok, i'm off to the shops, I'll be back later to see if it's progressed
<Chipaca> ttfn
<jdstrand> mvo: otoh, I don't know. the minimal most restricted set of rules on a 4.15 kernel is: https://paste.ubuntu.com/p/FjSxZ5pbwb/
<jdstrand> mvo: you could reduce the /sys/kernel/security/apparmor/... down to '/sys/kernel/security/apparmor/{,**} r,'
<jdstrand> but I did it that way to see all the accesses
<mvo> jdstrand: thanks, I will push a PR shortly and will ask for advice
<jdstrand> mvo: now, that is a simple 'run apparmor_parser under apparmor' test
<mvo> jdstrand: https://github.com/snapcore/snapd/pull/5621 <- is where I need it, hope this all makes sense. and also I wonder if there is a better way
<jdstrand> mvo: DAC and profile stacking are going to be involved for more complicated things
<mvo> jdstrand: maybe I can use aa-status instead of apparmor_parser in the go code, that seems to be less noisy
<mvo> jdstrand: yeah, this is really just so that we can detect if all looks well but in fact its not
<jdstrand> mvo: aa-status is definitely recommended, cause it will be updated to support new things. do note, it is python3
<mvo> jdstrand: yeah, thats downside, I could create a small helper c-binary around aa_kernel_interface_new()
<jdstrand> it is interestingly bi-lingual and will run under py2. but that is neither here nor there and just fun trivia
<mvo> jdstrand: :)
<jdstrand> mvo: aa-status is not actually terribly smart. does it return non-zero in the case you are looking at?
<jdstrand> mvo: I ask, cause you could implement its dumb test in Go I suspect (though again, you'd take on the maintenance burden of that)
<sil2100> mvo: sucks that I don't have a raspi3 - I know that's probably a lot to ask, especially because of the size, but you think it would be possible for you to tar up the contents of the filesystem from the SD card after the invalid config is up and share it somewhere? Might make things easier for me to debug
<ogra> sil2100, you should really get one and expense the 30â¬ :)
<sil2100> ogra: I think I'll just do that indeed, not the first time I'm poking on the raspi3
<sil2100> hmmm
 * sil2100 goes check on that
<ogra> its not like it is super expensive or so
<mvo> jdstrand: thanks, I will think a bit about it
<mvo> sil2100: lets debug that tomorrow then, I can help. plus buying/expensing one is probably fine
<mvo> kyrofa: pr#5621 but its a bit of a can of worms, so not sure if this will not need some more iterations
<jdstrand> mvo: is it only that you don't have mac_admin?
<ogra> they probably only gave him pc_admin :P
<ogra> (SCNR .... the heat and such)
<jdstrand> mvo: see my comments in the PR and this: https://paste.ubuntu.com/p/cTTqxwJpqf/
<kyrofa> jdstrand, this brief conversation might be helpful for reference: https://irclogs.ubuntu.com/2018/08/08/%23ubuntu-devel.html#t14:35
<kyrofa> (regarding mac_admin)
<mvo> jdstrand: I'm not sure this is observable from inside the container
<zyga> Hey
<mvo> jdstrand: I tried looking at /proc/self/status and CapEff in there and AFAICT I have the right bits
 * zyga is resting after a very hot and busy day
<jdstrand> mvo: you mean the kernel is telling you that you have mac_admin but you do not?
<mvo> jdstrand: correct, again with the caveat that I'm not an expert on this (yet)
<mvo> jdstrand: I have not used pscap for this, just the status file in proc but let me check with pscap
<jdstrand> mvo: well, I'm not either, but that sounds wrong...
<mvo> jdstrand: note this is inside an lxd container
 * zyga tunes in
<mvo> jdstrand: and lxd itself restricts this cap (again AIUI)
<jdstrand> tyhicks: hi! would it surprise you if inside a container, it reports having mac_admin but in reality, it does not?
<zyga> Kernel bugs, you tiny little kernel bugs, where are you? ;-)
<jdstrand> tyhicks: (see backscroll for context)
<mvo> jdstrand: I just ran pscap and mac_admin is availalbe for everything. yet when I try to load a profile (empty) I get permission denied
<mvo> jdstrand: see the PR for how to construct such a test case, but its pretty simple
<jdstrand> tyhicks: mvo's observance sounds like a bug ^. is it?
<jdstrand> observation*
<jdstrand> mvo: so, loading a profile is certanly one way to do it, but that will spam the logs
<jdstrand> mvo: I suspect there is an easier way
<mvo> jdstrand: (very) open for ideas
<jdstrand> let me try some things
<jdstrand> I could see having mac_admin in the container and the wrapping apparmor profile denying it, but I thought the container was unconfined... maybe I misread somethign
<jdstrand> tyhicks: fyi ^
<mvo> jdstrand: the container is unconfined
<jdstrand> mvo: is this a new issue or are you trying to enable some tests that never ran/always failed before
<mvo> jdstrand: aiui lxd will take away (drop) cap_mac_admin (and override) in this case when running things
<mvo> jdstrand: this is an old bug but we never tried to fix it
<mvo> jdstrand: it was not even understood
<jdstrand> oh, yeah, well, that would explain it I guess
<mvo> jdstrand: we got reports about this from various people but never looked into it until recently when iirc mborzecki and kyrofa  at the same time came up with this failure
<kyrofa> Yeah, this is an unprivileged lxc container with apparmor disabled, lxc doesn't want to make the host apparmor available
<kyrofa> Which makes sense given that it's still unprivileged
<jdstrand> tyhicks: nm
<jdstrand> mvo: I think if you open() /sys/kernel/security/apparmor/.remove, then write something valid (eg, "profile canary-blah {}"), then close the fd, you'll get permission denied
<jdstrand> mvo: ie, use lowlevel calls to perform an atomic write on a profile that isn't loaded in the kernel
<jdstrand> mvo: err, ie, use lowlevel calls to perform an atomic write on the .remove file to try to remove a profile that isn't loaded in the kernel
<jdstrand> mvo: with mac_admin, you'd get ENOENT
<jdstrand> mvo: eg:
<zyga> Mvo: I would suggest to use a profile name like snap.system.canary
<jdstrand> $ sudo bash -c "echo canary >/sys/kernel/security/apparmor/.remove"
<jdstrand> bash: line 0: echo: write error: No such file or directory
<jdstrand> [1]
<jdstrand> $ sudo aa-exec -p test -- bash -c "echo canary >/sys/kernel/security/apparmor/.remove"
<jdstrand> bash: line 0: echo: write error: Permission denied
<jdstrand> [1]
<zyga> Because we âownâ that namespace
<jdstrand> zyga: do we own the 'system' snap?
<jdstrand> zyga: I mean, maybe snap.core.canary
<zyga> Yes
<zyga> We reserved system
<jdstrand> well, whatever, so long as it doesn't accidentally remove something
 * zyga cannot stand the weather today
<zyga> Itâs 8PM but the temperature outside is the same as at noon
<kyrofa> zyga, tail end of summer, hang on
<kyrofa> Almost through
<kyrofa> I hate it, too
<cachio> zyga, hey
<cachio> I see a weird error on core18
<cachio> some tests
<mvo> jdstrand: thanks for your suggestion in the PR - should I do the loading in the C code as well or just in the go code?
<cachio> fail when we do MATCH 'xxx' < file
<cachio> zyga, but if we do cat file | MATCH 'xxxx'
<cachio> works
<cachio> zyga, any idea which could be the reason?
<mvo> cachio: that sounds like the subshell issue we found some days ago
<mvo> cachio: https://github.com/snapcore/spread/pull/67 maybe?
<cachio> mvo, ahhhh
<jdstrand> mvo: actually, I just found something even simpler
<jdstrand> https://github.com/snapcore/snapd/pull/5621/comment#issuecomment-411848548
<cachio> mvo, let me test it, I already have the spread with your change
<jdstrand> mvo: ^
<mvo> jdstrand: nice!
<mvo> jdstrand: thats easy enough from both C and go
<kyrofa> jdstrand, nice find
<jdstrand> mvo: yes. what is interesting is that a mac_admin denial is not triggered by that (you don't need mac_admin to read that file)
<jdstrand> mvo: but you do need to be root
<jdstrand> mvo: (even though the perms are listed as 444)
<cachio> mvo, this fix the issue
<cachio> thanks
<mvo> jdstrand: interessting. is this a reliable test. you write that you don't need mac_admin to read that file?
<jdstrand> mvo: so this is DAC that is preventing it. while I'm root in the container, the container is running as non-root. non-root can't access the file
<mvo> jdstrand: my tst container runs as root - or are you saying it drops root at some point?
<kyrofa> jdstrand, does that test pass in a normal, unpriv container?
<kyrofa> (without apparmor disabled)
<jdstrand> kyrofa: yes
<jdstrand> root@xenial-unconfined:~# cat /sys/kernel/security/apparmor/profiles
<jdstrand> cat: /sys/kernel/security/apparmor/profiles: Permission denied
<kyrofa> But you're still not root
<jdstrand> that's true. interesting
<jdstrand> that also feels like a bug
<mvo> jdstrand: I like this because a) simple b) no log spam - is it reliable, i.e. I hope it won't be "fixed" at some point :)
<mvo> jdstrand: but I would definitely like to have a way that avoids the log spam
<jdstrand> mvo: the .remove of a non-existent profile would avoid log spam
<jdstrand> mvo: and is a true mac_admin test
<mvo> jdstrand: cool, then I will go with this - should I do the same in the C code?
<mvo> jdstrand: actually I think there is no log spam there
<jdstrand> mvo: what do you mean no log spam?
<jdstrand> where?
<mvo> jdstrand: will update the (go) code now to use the removal of a non-exiting profile - I will just create a random strings
<mvo> jdstrand: I had to update snap-confine as well
<mvo> jdstrand: to detect if apparmor is fully usable
<mvo> jdstrand: but the C code does not log anything so that should be ok(?)
<jdstrand> mvo: I'm confused by this conversation, but if you write a non-existent profile name to /sys/kernel/security/apparmor/.remove, you will get an ENOENT when have mac_admin, and EPERM or EACCES if you don't. in neither case will there be a log entry
<jdstrand> (I say 'or' cause otoh I don't know which)
<jdstrand> mvo: in your current implementation, you are successfully loading a valid profile. that will create an entry in the audit subsystem. then you remove it, and it will create a second entry for that
<jdstrand> mvo: I was wondering why you are updating both snap-confine and go code?
<mvo> jdstrand: sorry for the confusion. the go check is needed to ensure that snapd does not try to load the apprarmor profiles it generates into the kernel (which will fail)
<jdstrand> and snap-confine is for change_onexec
<mvo> jdstrand: the snap-confine code needs updating because it has its own detection for apparmor and if it detects that is has apparmor it will set aa_change_on_exec() which will fail too
<jdstrand> since the profile isn't there
<jdstrand> right
<jdstrand> ok
<mvo> jdstrand: well, even if it is it can't change it, right?
<mvo> jdstrand: or does not not require privs?
<mvo> jdstrand: in any case, yes, its not there as well :)
<jdstrand> mvo: it doesn't need mac_admin to change profiles, but it can't change profiles if the profile isn't loaded
<mvo> jdstrand: gotcha, thanks!
<jdstrand> mvo: the .remove that you are going with (which I think is fine), is a bit of a hack. can you add a comment on why you are doing it that way?
<mvo> jdstrand: sure
<jdstrand> thanks
<cachio> mvo, in core18 when we get the snap env
<cachio> the SNAP_INSTANCE_xxx are not there
<cachio> this is making fail the test snap-env
<mvo> jdstrand: I pushed an update to the PR
<mvo> jdstrand: I will read comments in the PR - thanks for all your help!
 * mvo calls it a day
<zyga> why is ubuntu-image crashing lately?
<jdstrand> stgraber: hey, on a 4.15 kernel (bionic), if I have an apparmor denial in the the container's policy, where would I see that logged? journald isn't showing me what I expect
<stgraber> jdstrand: I'd expect it to hit the kernel log which may or may not be readable by the container
<jdstrand> ok, I was looking on the host
<jdstrand> stgraber: otoh, with lxc.apparmor.profile=unconfined, should I see that in the container?
<stgraber> well, with that in place you shouldn't be able to get any denial because there'd be no apparmor in place
<jdstrand> stgraber: but there is a lxd-xenial-unconfined profile. what is that for?
<stgraber> when you use raw.lxc you play behind LXD's back, so LXD doesn't know the profile it's generating won't be used
<jdstrand> I see
<jdstrand> stgraber: ok, do you have an idea why cat /sys/kernel/security/apparmor/profiles gets an EACCES with:
<jdstrand> config:
<jdstrand>   raw.lxc: |
<jdstrand>     lxc.apparmor.profile=unconfined
<jdstrand> lxc exec xenial-unconfined -- cat /sys/kernel/security/apparmor/profiles
<jdstrand> cat: /sys/kernel/security/apparmor/profiles: Permission denied
<stgraber> is that container unprivileged?
<jdstrand> stgraber: yes
<stgraber> then that's normal
<stgraber> unprivileged users can't read that file
<jdstrand> but they can
<stgraber> stgraber@castiana:~$ cat /sys/kernel/security/apparmor/profiles
<stgraber> cat: /sys/kernel/security/apparmor/profiles: Permission denied
<jdstrand> there is something weird going on. let me paste
<stgraber> jdstrand: if you're in a normal container, you can because an apparmor namespace is setup
<stgraber> jdstrand: well, root in the container can
<stgraber> but in this case, you're in an unprivileged container without an apparmor namespace, so you have as much right as a nobody user on the host
<jdstrand> stgraber: https://paste.ubuntu.com/p/4FzwpSFs2B/
<jdstrand> stgraber: ah, ok, that explains it then
<jdstrand> stgraber: thanks!
<zyga> jdstrand: hey
<zyga> jdstrand: can you please (if possible) whitelist fedora29 as "type: base"
<zyga> jdstrand: I pushed a pair of revisions just now
<zyga> jdstrand: if you cannot make that permanent please at least ack those two
<jdstrand> zyga: who is responsible for that base?
<zyga> jdstrand: currently just me, we are working with the fedora server SIG to transfer it over and they are happy to take it
<zyga> jdstrand: I just need it for a talk tomorrow
<zyga> (I'm at a fedora conference this week)
<zyga> jdstrand: it won't go to stable before the hand off
<jdstrand> zyga: I'll approve it since you did it, but we have no process surrounding base snap reviews, so that should be discussed in the forum with niemeyer's input
<zyga> I don't disagree, it's the first of the kind so we need to figure out the process
<zyga> next week we should all be back
<zyga> so we can discuss
<jdstrand> sounds fine
<zyga> thanks!
<zyga> thank you, I just published both to edge
<jdstrand> np
<zyga> I will publish the code for making those now
<ogra> hrm ... i wish snap find had a "by interface" search function
<jdstrand> that would be handy
<ogra> yeah
<zyga> ogra: check out fedora29
<zyga> 18M
<ogra> ?
<zyga> base snap :)
<ogra> as broekn as core 18  ? like ... missing everything useful ? :P
<ogra> (does it ship vi ? :) )
<zyga> ogra: it doesn't ship vi, it's not a boot snap
<zyga> it's just a base snap for apps
<zyga> it ships a lot of locale actually
<zyga> there's a hello-fedora snap as well but you need for a PR to land to use it
<ogra> for what ?
<zyga> I mean, there's a demo snap works on top of fedora29 now
<zyga> but it is broken on ubuntu because of a bug this uncovered
<zyga> and we need for a PR to land to fix that
<ogra> well, congrats in any case !
<zyga> ogra: there's more
<zyga> opensuse is next
 * ogra twiddles thumbs watching store downloads at 400kB/s
<zyga> as in, we have a +1 from sysrich
<ogra> yay
<zyga> ogra: wanna see how it's made?
<ogra> is there a GH tree to look at ?
<ogra> (not right now, but i'd indeed like to take a look)
<zyga> I'm making a new repo for it
<zyga> though not on GH, fedora loves other places (gitlab)
<ogra> heh, well
<ogra> some git web UI ...
<ogra> man ... thats so annoying
<ogra> why is the store so super slow at times
<ogra> booo !
 * ogra installed qemu-git just to find it is also compiled without sdl or gtk support ... 
<ogra> i was kind of hoping it had some advantage over the archive qemu except being newer
<ogra> grrr ... and no -redir ...
<zyga> ogra: do you have air conditioning at home?
<zyga> ogra: this hotel is a bit quaint it that it ... doesn't
<zyga> everyone is melting this week
<ogra> nope, like most gerans i dont have air conditioning
<ogra> *germans
<ogra> we do have 60cm brock walls ...
<ogra> *brick
<zyga> ogra: yeah, same in poland
<zyga> this summer is tough
<ogra> they are usually good enough for 30+ C for two weeks with keeping the heat out
<zyga> all the media markts sell AC now
<zyga> and I'm seriously considering one
<zyga> but first I need to get home :)
<ogra> but this was 8 weeks without rain and constantly above 25
<zyga> I hope my next flight through FRA won't be this interesting
<ogra> so now, even we had big thinderstorms today and it cooled down a bit, the house now is an oven
<ogra> fra was shut down again today
<ogra> due to the heavy weather
<ogra> and tomorrow ryanair pilots go on strike
<ogra> the weekend will not be fun to fly through FRA for sure
<ogra> zyga, when do you fly back ?
<zyga> sunday
<ogra> with luck it has somewhat settled then
<ogra> the ryanair thing cancelled a few 100 flights ... people will be re-booked on other airlines ... so everything will be awfully crowded
<ogra> and there is still the fallout from today too ...
<ogra> ogra@acheron:~/Devel/anbox$ qemu-git.qemu-system-x86-64 -m 4096 -vga virtio /home/ogra/Devel/anbox/anbox-image.img
<ogra> qemu-system-x86_64: -vga virtio: Could not open '/home/ogra/Devel/anbox/anbox-image.img': Permission denied
<ogra> ARGH !
<ogra> no home interface ...
<ogra> ogra@acheron:~/Devel/anbox$ qemu-git.qemu-system-x86-64 -m 4096 -vga virtio /home/ogra/snap/qemu-git/current/anbox-image.img
<ogra> ...
<ogra> qemu: could not load PC BIOS 'bios-256k.bin'
<ogra> GRRRRR !
 * ogra ponders to make a proper qemu snap in the weekend 
<ogra> how annoying
<zyga> ogra: that would be useful :)
<ogra> zyga, well, there is one ... even from a canonical employee it seems
<ogra> but last touched 16 months ago and only in beta/edge
<zyga> I was looking for JDK as a snap today
<ogra> well, thats quickly and trivially snapped
<ogra> just a stage-package entry and some file copying
 * ogra goes back to battle with the deb qemu version then
<ogra> ... i know why i prefer arm boards ... so much easier :P
<zyga> ogra: https://gitlab.com/zygoon/fedora29
<zyga> jdstrand: ^ FYI
<jdstrand> cool
<ogra> nice, pretty straightforward ...
<zyga> jdstrand: could you re-approve fedora29 uploads please, that's the last time for today
<zyga> jdstrand: I had to work around a bug that is present in released versions
<zyga> jdstrand: they should now also work on Ubuntu if you want to try
<zyga> jdstrand: (along with hello-fedora from stable or from candidate)
<sergiusens> kenvandine: hey, when launching the simple-scan snap I get an endless loop of "cp: '/home/sergiusens/.config/user-dirs.locale' and '/home/sergiusens/.config/user-dirs.locale' are the same file
<sergiusens> "
 * zyga wonders if anyone apart from mvo and jdstrand can unblock store reviews
#snappy 2018-08-10
<scientes> how do i compile "snap" command in order to test it?
<scientes> before i submit a patch
<scientes> shawn@shawn-desktop:~/git/snapd$ go get github.com/snapcore/snapd
<scientes> package github.com/snapcore/snapd: no Go files in /home/shawn/go/src/github.com/snapcore/snapd
 * scientes just found HACKING.md
<mborzecki> morning
<zyga> Hi
<mborzecki> zyga: new, intersting developments from flock?
<zyga> some hands-on session on AWS CLI snap
<zyga> our presentation is today so I'llbe focusing on that
<zyga> what is wrong with master? /home/gopath/src/github.com/snapcore/snapd/tests/lib/prepare.sh: line 413: 1: command not found
<zyga> + /snap/bin/ubuntu-image -w /home/image /home/image/pc.model --channel edge '' --extra-snaps /home/image/snapd_2.34.3_amd64.snap --output /home/image/core18-amd64.img
<zyga> /home/gopath/src/github.com/snapcore/snapd/tests/lib/prepare.sh: line 288: 29999 Segmentation fault      (core dumped) /snap/bin/ubuntu-image -w "$IMAGE_HOME" "$IMAGE_HOME/pc.model" --channel "$IMAGE_CHANNEL" "$EXTRA_FUNDAMENTAL" --extra-snaps "${extra_snap[0]}" --output "$IMAGE_HOME/$IMAGE"
<zyga> mborzecki: can you please ask mvo to ack the last two revisions of fedora29 again
<zyga> mborzecki: unfortunately the store has no memory so it blocks every upload I do
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/5625
<mborzecki> zyga: anyways, for all we know that check will be passing now, but the segfault will probably still be there
<zyga> thanks
<mborzecki> zyga: maciek@corsair:~ ubuntu-image --help
<mborzecki> zsh: segmentation fault (core dumped)  ubuntu-image --help
<zyga> Must be Friday
<mborzecki> zyga: all channels have the same version, it's also a classic snap, maybe it's something else that's causing this
<zyga> mborzecki: could be
<mborzecki> zyga: can you install ubuntu-image snap locally?
<zyga> re
<zyga> mborzecki: trying
<zyga> it doesn't crash here
<zyga> but then python complains about lack of dpkg
<zyga> is mvo around today?
<zyga> mvo: hello
<zyga> mvo: may I ask you to approve fedora29 uploads again
<mvo> zyga: goood morning! when is your presentation?
<mvo> zyga: sure
<zyga> mvo: 11:20
<zyga> mvo: I found some more bugs but worked around them
<zyga> mvo: and this should also make it work on ubuntu now
<mvo> zyga: you can always telegram me when things are urgent
<mvo> (just btw)
<mvo> zyga: nice!
<zyga> mvo: thank you! I didn't want to bother you last night
<zyga> mvo: https://gitlab.com/zygoon/fedora29 in case you want to cross ref what you approve
<mvo> zyga: thanks looking
<zyga> there are tags referencing store uploads
 * zyga is pretty happy with the makefile there :)
<mborzecki> zyga happy with the makefile :) heh
<zyga> it looks nice as a makefile :)
<mborzecki> hehe
<mborzecki> yay, only 3 builds for snapcraft left, meaning snapd will start soon right?
<zyga> mvo: thank you, you should be able to refresh fedora29 now
<zyga> and it, _fingers crossed_ should work
<mborzecki> zyga: i'm stepping through ubuntu-image with gdb now, take a look at this https://paste.ubuntu.com/p/RQWc2Rcr2f/
<mborzecki> that's why snap run --shell also exits with a segfault here
<zyga> mborzecki: woah?
<zyga> I have no idea why this would crash, do you have any clues?
<mborzecki> zyga: heh, LD_LIBRARY_PATH=/snap/ubuntu-image/100/usr/lib:/snap/ubuntu-image/100/lib:/snap/ubuntu-image/100/usr/lib/lib-arch:/snap/ubuntu-image/100/lib/lib-arch /bin/bash -> segfault
<zyga> mborzecki: which linker is this using?
<zyga> mvo, mborzecki: is hello-fedora working for you guys now?
<mborzecki> zyga: the host's, the segfault is actually in the liner #0  0x00007f7c49694b31 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
<zyga> mborzecki: that's the bug
<zyga> it should use ld-so from the core snap
<mborzecki> zyga: but it's a script, https://paste.ubuntu.com/p/XGsxrdjTWP/
<zyga> right
<zyga> but _broken_
<zyga> it must invoke the linker
<zyga> to avoid using the host linker
<zyga> but anyway
<zyga> why did it break, what changed?
<mborzecki> let me check some other classic snaps
<mborzecki> zyga: there was a glibc & python update i believe
<zyga> mborzecki: try python0
<zyga> it should work everywhere
<zyga> but it was made by me
<zyga> so it's a bit more special
<zyga> if that crashes then the world is broken
<mborzecki> zyga: heh upgraded glibc (2.27-3 -> 2.28-1)
<zyga> it if works then we can look for more clues
<mvo> mborzecki: good morning!
<mborzecki> mvo: heya
<mvo> btw, I see red tests in the most recent PRs, anything going on with CI? or just some bad PRs ;)
<mvo> zyga: let me check
<zyga> mvo: ubuntu-image segvfaults
<zyga> mvo: maciej is looking at that
<mvo> boooo
<mvo> mborzecki, zyga: thanks
<mvo> heh
<mvo> there was a new release
<mvo> and it went all the way from edge to stable with a single push
<mvo> because â¦
<mborzecki> reasons
<mvo> mborzecki: where do we pull from? beta/edge? stable?
<mborzecki> well slack works, python0 works, so it's ubuntu-image that's borked
<mborzecki> mvo: same version in every channel
<mvo> mborzecki: yeah, I think I have the privs to "fix" that
<mvo> mborzecki: I just need to know where we pull from
<mborzecki> mvo: edge
<mvo> mborzecki: excellent
<mvo> mborzecki: fixed
<mborzecki> mvo: refreshing
<mvo> mborzecki: and next we need to have a word with the uploader of the snap :)
<mborzecki> lukasz? :)
 * mvo won't name names
<mborzecki> mvo: https://paste.ubuntu.com/p/pXgtFBFVHd/ better, at least no segfault, no clue if it's intended to be used outside of ubuntu though ;)
<mvo> mborzecki: heh
<mvo> mborzecki: why on earth would it need dpkg?
<mvo> mborzecki: well, I guess I should look at the code to answer that
<mborzecki> mvo: well, why it's not bundled in the snap? :)
<mvo> mborzecki: looks like its using it to detect its own arch
<mvo> mborzecki: another great question
<mborzecki> wow, snapcraft travis jobs are really ~7h long?
<mvo> mborzecki: to be fair it looks like the snapcraft.ymal has not changed
<mvo> mborzecki: so maybe a snapcraft change broke u-i
<mvo> mborzecki: it was failing inside travis too, right? not just on arch?
<mvo> mborzecki: I think thats correct, snapcraft runs a ton of integration tests that build stuff (at least AIUI)
<mborzecki> mvo: yes, my guess is some library pulled in through LD_LIBRARY_PATH got updated/changed
<mvo> mborzecki: ok
<mborzecki> mvo: https://paste.ubuntu.com/p/vFfwvBsHH7/
<mvo> mborzecki: nice!
<mvo> mborzecki: I also like your hostname in the pastebin :)
<mborzecki> mvo: whatever it is it's inside /snap/ubuntu-image/100/lib/lib-arch
<mvo> mborzecki: there is probably a lot inside there
<pstolowski> mornings!
<mborzecki> mvo: i see mostly glibc, readline
<mborzecki> pstolowski: hey
<mborzecki> mvo: well, maybe libc shouldn't be there after all https://paste.ubuntu.com/p/KhT6SbWYj4/ it's not there in rev 98 which works
<zyga> pstolowski: hey
<zyga> pstolowski: can you do a quick test for me please
<mborzecki> zyga: hello-fedora still works
<zyga> mborzecki: thank you!
<mvo> mborzecki: worth a shoot
<mvo> zyga: I have fedora29 r9 and hello-fedora r5 but still get the error launching it but I don't have the latest snapd maybe
<mvo> zyga: same missing file error
<zyga> mvo: you should not need the lasted snapd
<zyga> drat :/
<zyga> ok, thank you
<zyga> (perhaps you do, because the fix in dirs.go)
<zyga> the hack I did only works on simpler implementation in snap-confine
<zyga> that's okay
<zyga> thank you for trying
<zyga> mvo: I suspect swapping ID=... lines in $SNAP/usr/lib/os-release in fedora29 would fix it
<zyga> mvo: if you want to unpack the squashfs and "snap try" it to check
<zyga> but don't worry, it's better to fix this through mater
<mvo> zyga: once your snapd PR lands it will work, no?
<zyga> mvo: I think so, yes
<mvo> zyga: if so, lets just make sure it does land
<zyga> mvo: it's passing tests
<zyga> (except core prepare is broken)
<zyga> yeah
<pstolowski> mborzecki: hey, do you have any PR you want reviewed?
<pstolowski> mborzecki: i mean, you have a few, but what's the 1st in the queue?
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/5614 if you could
<pstolowski> sure
<mborzecki> pstolowski: thanks
<zyga> mvo, mborzecki: should we disable core if we cannot fix ubuntu-image for a while?
<mvo> zyga: it is "fixed"
<mborzecki> zyga: it should be possible now
<zyga> Son_Goku: I'm happy with the slides, I think
<mborzecki> zyga: do you have the slide deck available anywhere?
<zyga> https://docs.google.com/presentation/d/1Vf3wfC8O7D4_f_zyPBvvy6U6YBBRQd_3ncR6sWszTQM/edit?usp=sharing
<zyga> it's mostly a "talking" presentation so we have a few slides but most of the content will be verbal
<zyga> suggestions welcome!
<mborzecki> zyga: nice
 * sil2100 ordere
 * sil2100 ordered a raspi3
<sil2100> (cat's tail pressed enter too soon)
<mvo> sil2100: yay
<luk3yx> Is there any way to rename a snap's internal name without deleting and re-adding it?
<zyga> Son_Goku: snap install copr #
<zyga> # exercise for the reader
<Son_Goku> :D
<mvo> mborzecki: https://github.com/CanonicalLtd/ubuntu-image/pull/157 should fix the issue of running ubuntu-image on arch
<sil2100> grrr
<mborzecki> mvo: ta
<sil2100> mvo: oh! Yeah, none of us really thought about u-i on a non-ubuntu system ;)
<mvo> sil2100: yeah, I haven't either, just mborzecki did
<mvo> :)
 * mvo hugs mborzecki 
<Chipaca> wait. There are non-ubuntu systems?!?
<Chipaca> this changes everything
 * Chipaca tries "snap changes everything" just to make sure
<sil2100> Chipaca: apparently!
 * Chipaca grins like an idiot
<mborzecki> mvo: yup, i can run ubuntu-image --help now :)
<mborzecki> btw.  took a bit of trial & error to track down all dependencies with a clean venv
<mvo> mborzecki: *nod*
<mvo> mborzecki: thanks for confirming
<Gargoyle> Hi all.
<Gargoyle> I'm just setting up a new company laptop with Fedora 28, and I could not run "sudo lxd init". I just came back with "command not found". However, running it without the "sudo" worked fine.
<Chipaca> Gargoyle: sudo's path is probably different to your user's path
<Gargoyle> Am I likely to run into issues further down the line - if I've done something wrong early on, I'd prefer to catch it now than in a few days time when I have everything setup on the system.
<mvo> Chipaca: I noticed that inside cmd/snap ; go test will fail for me. it looks like it will print the new (nice) green checkmarks but the tests do not expect those
<mvo> Chipaca: is that just me?
<mvo> Chipaca: when i run "go test | more" its fine again
<Chipaca> mvo: let me see...
<Chipaca> mvo: how do you run it, exactly?
<mvo> Chipaca: I "cd cmd/snap ; go test"
<mvo> Chipaca: inside a mate terminal
<Chipaca> mvo: huh
<Chipaca> mvo: and what about 'go test .'?
<mvo> Chipaca: that is fine
<mvo> Chipaca: interessting
<Chipaca> mvo: here it fails with a dbus error
<mvo> Chipaca: wuut? what does it try to talk to?
<Chipaca> ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'")
<Chipaca> mvo: test runner is weird
<Chipaca> mvo: results change depending on whether I set -v or not
<mvo> might be something inside our test not properly mocked
<Chipaca> mvo: 'go test -v .' -> colour errors
<Chipaca> mvo: 'go test .' -> just the dbus error (also present with -v)
<mvo> Chipaca: go test -v gives me also the \x1b bits inside the test output
<Chipaca> mvo: so, the colours in the output mean that Stdout is a terminal
<mvo> Chipaca: yeah, I wonder why. this is normal bionic
<Chipaca> mvo: this here is "normal" xenial
<Chipaca> mvo: I'll dig into it and see what i learn
<mvo> Chipaca: aha! can you please try with "go1.10" from the snap? I will try with go 1.6
<Chipaca> mvo: ah,  about the same with a snapped 1.10
<mvo> Chipaca: yeah, no difference for me either
<Chipaca> sigh
<Chipaca> mvo: the problem probably arises because colour support checks whether stdout is a terminal just once
<Chipaca> mvo: so it needs mocking in tests
<Chipaca> mvo: I don't know why it only needs mocking in some cases and not in others
<Chipaca> mvo: doing this now fwiw
<mvo> Chipaca: ta
<Chipaca> mvo: could i get a review of #5617?
<mvo> Chipaca: yes
<Chipaca> mvo: when you run the tests, do you have a "DBUS_SESSION_BUS_ADDRESS" env var?
<mvo> Chipaca: I do have that set
<Chipaca> mvo: here I need to explicitly unset it for tests to pass when running from the directory (but not otherwise)
<Chipaca> mvo: the funny thing is testutil/dbustest.go saves that env var but doesn't unset it nor set it to anything
<Chipaca> mvo: so i'm not sure what's supposed to be doing it
<mvo> Chipaca: woah
<Chipaca> mvo: ikr
<Chipaca> in any case, pr coming with these fixes
<mvo> Chipaca: \o/
<mborzecki> pstolowski: hey, got a question about udev, udev monitor will start before dumping current device db right?
<pstolowski> yes, this will be visible in the PR i'm working on which integrates monitor and udevadm parser
<mborzecki> ah ok
<pstolowski> mborzecki: i'm starting the monitor and queue monitor events until db dump finishes, then i flush accumulated events
<mborzecki> pstolowski: then dedup is based on devpath/devname?
<Chipaca> mvo: https://github.com/snapcore/snapd/pull/5627 addresses the 'go test' weirdness
<pstolowski> mborzecki: not sure yet, probably, i haven't tought much about that aspect yet
<Chipaca> boo
<Chipaca> Failed project prepare: 4
<Chipaca> boooh
<mborzecki> Chipaca: hmm something isn't right https://paste.ubuntu.com/p/JmVDynrPCF/
<Chipaca> mborzecki: mhmm
<Chipaca> mborzecki: ah
<Chipaca> mborzecki: i think i know what's happening
<mborzecki> Chipaca: takes a while for socket to appear
<Chipaca> mborzecki: exactly :-)
<Chipaca> we don't wait for it to start
<mborzecki> Chipaca: added a loop with 20s wait, but still no socket, maybe it's started wrong?  http://paste.ubuntu.com/p/VnwfFwjn4s/
<Chipaca> mborzecki: are you fixing it, or should i?
<mborzecki> Chipaca: go ahead :P
<Chipaca> k
<mborzecki> omg silly me
<mborzecki> Chipaca: http://paste.ubuntu.com/p/mwvRRjjqzf/ if you want to use it
<Chipaca> mborzecki: want to try https://pastebin.ubuntu.com/p/mX8x6BZDps/ ?
<mborzecki> nice
<Chipaca> mborzecki: interestingly the printed address looks like unix:path=/tmp/check-6227058902689785204/0/user_bus_socket,guid=c22feadfc799529b07be91f75b6d603a
<mborzecki> Chipaca: works all right here
<mborzecki> Chipaca: don't know if you got that, your patch works fine
<Chipaca> mborzecki: i hadn't, thank you
<Chipaca> i'll push it now
<Chipaca> mborzecki: did you get the bit about how the printed address has more stuff than just user_bus_socket?
<mborzecki> yeah, saw that here too, apparently it's not critical as i was doing setenv without that and it worked too
<Chipaca> mborzecki: I could've also done --print-pid and waited for that
<Chipaca> eh, it works this way
<Chipaca> w/e
<ogra> mvo, did the pi3 gadget ever get updated in stable to include all the gpio interfaces (it is in edge since 1.5y, but i dont know if/when you pushed pi3 into stable)
<ogra> (i'D have expected it to be updated along with the push of pi2-kernel to stable)
<mvo> ogra: it has not bee updated
<ogra> damn
<mvo> ogra: the kernel is done by the kernel team they can't push the gadgets
<mvo> ogra: gadgets are foundations territory nowdays
<ogra> it has various firmware fixes for thermal and power management and the stable one seems to miss all gadget based interfaces
<mvo> ogra: yeah, I think it should go out, we just need a) QA b) somoeone driving this :/
<mvo> ogra: fwiw, the LP page is owned by foundations and steve has the required privs to push the snaps
<ogra> i honestly have not run stable gadgets since the above stuff landed ... so for a) i can clearly give you a thumbs up :)
<ogra> and *all* interfaces missing is clearly a downer
<Chipaca> my network is having a fun day
<Chipaca> but on the other hand so is travis
<mvo> Chipaca: and so is LP - arm builds are very slow (the builders look a bit overworked)
<Chipaca> eight hour workday for workers! rabble rabble rabble
<Chipaca> drat, i meant builders
<zyga> hello :)
<zyga> how are things?
<zyga> is travis working now, it was pretty slow when I tried to use it yesterday
<Chipaca> zyga: wrt travis, everything is terrible, slow, horrible, raining on the ice cream
<Chipaca> zyga: Son_Goku: how's your flocking?
<zyga> Chipaca: we're done with our presentation, it went very good
<zyga> we had lots of questions and interaction with the audience
<Chipaca> zyga: people weren't asleep and hung over?
<zyga> and we have a working fedora29 base now :)
<zyga> no, today is the first day when it's not 999999C outside
<zyga> I still want to catch some infrastructure people to discuss the hand off
<zyga> and the fedora project leader to get an ack of the use of the fedora log
<zyga> logo
<zyga> Chipaca: and people are surprisingly extremely sober
<zyga> drink responsibly, said the spiritual ghost of jono
 * mvo weeps about the fact that he still has no arm PPA build for snapd 2.35~pre1
<mborzecki> need another coffee
<mborzecki> mvo: i've updated https://github.com/snapcore/snapd/pull/5584 with your patch, thanks!
<mvo> mborzecki: \o/ happy that you liked it
<mborzecki> mvo: yeah, i feel like i should rewrite that snap name validation too
<mborzecki> mvo: also played around trying to get the bits of validation code shared between update-ns and libsnap-confine-private, so far no other idea than a separate file and a symlink to update-ns, the simplicity of go build is not making it too easy
<mvo> mborzecki: I think rewrite of the snap name validation is not a good idea
<mvo> mborzecki: but yeah, sharing is probably hard, but I have not put much thought into it yet, its just mildly annoying
<cachio> mvo, hey
<mvo> cachio: hey he
<mvo> cachio: how are you?
<cachio> mvo, fine
<cachio> you?
<mvo> cachio: yeah, doing well. need more tea though
<mvo> :)
<cachio> hehe, I have 2 issues to fix on core 18
<mvo> cachio: tell me more please
<cachio> mvo, https://paste.ubuntu.com/p/Z7m38nK6VY/
<mvo> cachio: aha, nice find. we need to kill this one I think
<mvo> cachio: like remove the service entirely
<cachio> mvo, yes, makes sense
<mvo> cachio: I need to finish a PR first but once that is done I can look into it or maybe sil2100 has some spare cycles for ensuring update-motd.service is removed from core18
<cachio> mvo, sure
<sil2100> I can!
<mborzecki> wow a thunderstorm
<mvo> mborzecki: we had this yesterday - it was wild
<mborzecki> hmm snap-update-ns segfaulting now :P
<mborzecki> i suppose by internet will be choppy a bit today
<ogra> mborzecki, while yoyu duck and cover, just think about the fact that the air is breathable afterwards ;)
<ogra> (it definitely helped a lot here)
<jdstrand> mvo: ok, responded to 5621 (twice! :)
<mvo> jdstrand: thank you!
 * mvo reads
<jdstrand> mvo: let me know if what I said doesn't make sense
<mborzecki> mvo: pre-patch version works
<mvo> mborzecki: ok, let me look at the diff again, I wonder what I broke
<mborzecki> mvo: well the code looks correct, maybe i broke sth when doing little tweaks
<mvo> mborzecki: how can I reproduce? just build and copy in place and run a snap?
<mborzecki> mvo: sec, let me see if the same happens with non instance keyed snaps
<mborzecki> mvo: snaps without instance key work
<mvo> mborzecki: is "go test cmd/snap-update-ns " enough to trigger the crash?
<mborzecki> mvo: nope, the tests are passing
<mborzecki> mvo: heh, and even the hello-world_foo is used in the test suite :)
<mvo> mborzecki: so its crashing only when used for real(tm) ?
<mborzecki> mvo: yes
<jdstrand> mborzecki: fyi, https://github.com/snapcore/snapd/pull/5584#pullrequestreview-145243262
<mborzecki> jdstrand: thanks!
<jdstrand> mborzecki: is this the pr that you and mvo are discussing now?
<mvo> mborzecki: I played around a bit but did not managed to reproduce
<mborzecki> jdstrand: yes
<jdstrand> hmm, I verified the new 'i' handling. let me look again
<mborzecki> mvo: https://paste.ubuntu.com/p/ZGS8QwfWXt/
<jdstrand> mborzecki: there is an off by one, no?
<jdstrand> for (i = 0; instance_key[i] != '\0'; i++) {
<jdstrand> ...
<jdstrand> else if (i > 10) {
<jdstrand> 0123456789\0: i will be 11 here
<jdstrand> no, that's right
<mborzecki> jdstrand: the s is +1 because of this
<mvo> mborzecki: if you are still inside gdb, does "print instance_key[i]" yield anything?
<mvo> mborzecki: the gdb output looks all legit or am I missing something?
<Chipaca> looking for reviews on #5617 plz (not a trivial, unless you look at each commit individually)
<mborzecki> mvo: replaced islower/isdigit with own code and it works (?!?)
<mvo> mborzecki: heh
<mvo> mborzecki: optimization this smells like (in best yoda voice)
<mvo> mborzecki: can you build with -O0 ? is this arch/ubuntu?
<mborzecki> mvo: i'm building with -O0
<mvo> :(
<mborzecki> mvo: heh :P
<jdstrand> mborzecki: I didn't mean on the buffer, I meant on the length check, but it is fine
<jdstrand> one thing about strsep() is that it is going to modify the string
<mborzecki> jdstrand: yeah, there's a copy made in validate_instance_name
<jdstrand> right, I recall verifying that was ok
<jdstrand> mborzecki: what is the failure?
<mvo> mborzecki: is that on arch or ubuntu? what go version and gcc --version is in use?
<jdstrand> actally, shouldn't char s[52] = {0,}; be char s[53] = {0,};?
<jdstrand> 40 char snap_name + 10 char instance_key + 1 NULL + 1 extra to detect overflows
<jdstrand> doesn't that not account for the valid '_'?
<mborzecki> jdstrand: #0  0x000000000055406e in instance_key_validate (instance_key=0x7ffe6a68b55c "foo") at bootstrap.c:286
<mborzecki> 286             if (islower((int)instance_key[i]) || isdigit((int)instance_key[i])) {
<mborzecki> segfaulting in this line, instance_key is "foo"
<mvo> jdstrand: oh, I think you are correct!
<jdstrand> some40charname_instance\0
<mvo> mborzecki: hm, hm, that cast
<mborzecki> mvo: added it just now to test things, but it's segfaulting without that too
<mvo> mborzecki: hm, no, that should be fine
<mborzecki> mvo: jdstrand: instance_key address is well within the bounds of validate_instance_name:s
<mvo> mborzecki: does it make a difference if you only have "islower" or "isdigit" ?
<mvo> mborzecki: of replacing it with if(instance_key[i] != '\0')
<Son_Goku> mvo, how are we looking on getting snapd 2.35 out the door?
<mvo> Son_Goku: its in beta now
<mvo> Son_Goku: beta does not yet include the fedora base fix but the next one will be
<mvo> Son_Goku: next beta will be early next week
<Son_Goku> mvo, cool
<Son_Goku> zyga wants me to update Fedora and my beta CentOS packages to 2.35, which is why I was asking
<mvo> Son_Goku: +1
<Son_Goku> the talk went really well (aside from the questions about the store), and there was definitely interest in Fedora-based snaps
<Son_Goku> well, even the questions about the store weren't that bad, but the talk went over so well that we went ~15 minutes over time
<Son_Goku> mainly for Q&A
<mborzecki> mvo: omg, i'm stupid after all, it's working all right
<mborzecki> mvo: i obviously did not built it as a static binary
<mvo> mborzecki: puhhh, ok
<jdstrand> mborzecki: there is an off-by-one with the strncpy() that will result in an unterminated string. you need sizeof(s) + 1
 * mvo finds it amusing that "close()" is defined in unistd.h but open in sys/types.h
<mborzecki> mvo: heh funny that it failed, thought that gcc has builtin primitives for isblahblah by now
<jdstrand> mborzecki: it is interesting that because you use a for loop instead of strlen() for the length, it didn't end up being a problen,
<mvo> mborzecki: I think there is some magic going on with these, iirc they get replaced at init time with optimized versions or something
<mborzecki> jdstrand: thanks for double checking
<mborzecki> mvo: and here i thought that the world is coming down :)
<mvo> mborzecki: same here, I was really confused
<mvo> mborzecki: thanks for getting to the bottom of it
<jdstrand> mborzecki: the '+ 1 extra to detect overflows' actually accounts for the '_'. Perhaps it would be better to rephrase that comment to be: '// 40 char snap_name + '_' + 10 char instance_key + 1 NULL
<mborzecki> jdstrand: ack
<mborzecki> jdstrand: shouldn't that be `char s[53] = {0}; strncpy(s, instance_name, sizeof(s) -1);` actually?
<jdstrand> mborzecki: yes
<jdstrand> mborzecki: I added a comment to correct myself and adjusted the 'comment' comment
<jdstrand> since you do want 53 to detect that overflow character, rather then just stripping it off
<jdstrand> hopefully I'm awake now :)
<mborzecki> mvo: jdstrand: pushed an update, thanks for your reviews
<mborzecki> i'm off to do some shopping now, kids are waiting already :/
<jdstrand> mvo: 5621 reviewed
<juliank> mvo: apt install petname on cosmic with 2.35 gives me error: json: cannot unmarshal object into Go struct field .packages of type string
<juliank> broken types?
<mvo> juliank: uh, interessting. let me try this
<juliank> JSON-RPC calls: https://paste.ubuntu.com/p/gny3GH5kJQ/
<juliank> Maybe I should have used pipes, ugh, this is annoying to test...
<juliank> Packages        []string `json:"packages"`
<juliank> is Params struct{} is clearly wrong
<juliank> as Packages is not a list of strings, but a list of objects describing packages
<juliank> mvo: ^
<mvo> juliank: aha, nice catch. I'm in a meeting right now but will get back after the meeting, feel free to push a fix if you already have an idea what is going on
<cachio> mvo, https://paste.ubuntu.com/p/2ZFG59dc7s/
<cachio> I found that after a timeout installing a snap
<cachio> mvo, this is the test https://paste.ubuntu.com/p/BB6D2rmjq7/
<mvo> cachio: hm, mount failed? protcol error again?
<juliank> mvo: basically you need http://paste.ubuntu.com/p/fNpjhSYg9F/ as the type change for jsonRPC, not sure if other changes are needed
<juliank> The hook works fine if the packages does not exist in apt
<juliank> (as packages is empty then)
<mvo> juliank: nice catch, thank you
<juliank> probably want to extract the version struct to not repeat it 3 times
<juliank> or just keep out the entire packages array if you don't use it yet
<zyga> re
<zyga> how are you doing mvo?
<mvo> juliank: thank you!
<mvo> juliank: I added a regression test and will work on this later tonight or monday
<Chipaca> mvo: monday monday monday
<Chipaca> mvo: your weekend starts in 8 minutes
<mvo> zyga: good, thanks
<mvo> Chipaca: heh, good point
<zyga> mvo: yeah, do listen to Chipaca
<zyga> mvo: how far away are you from Dresden?
<Chipaca> well, not _always_, but this time would be good
<mvo> zyga: the opposite side of the country - why? do you want to come over? or do you want me to come over :) ?
<zyga> the event still runs yesterday (odd, right?) and I was thinking you could use a more casual context or you will work all the time
<zyga> mvo: but across the country is not close enough to od thatr
<zyga> *do thta
<zyga> ...
 * zyga is not doing a great job at typing
<zyga> mvo: I saw the fedora fix was merged, thank you for that (that's a team-wide effort!)
<mvo> zyga: yw, enjoy the rest of the event
 * mvo takes a break
<cachio> mvo, it seems to be
<Chipaca> I think it's EOW time here
 * Chipaca looks around
<Chipaca> yeah, everybody else here is no longer working, might as well stop myself
<Chipaca> :-D
<sergiusens> Chipaca: speak for yourself!
<Chipaca> sergiusens: I do!
<sergiusens> please do, so that travis builders get freed up and we can start being productive again :-P
<Chipaca> sergiusens: https://www.google.com/maps/@51.2565417,0.3714914,17z <- there's nobody around me working on snapd for *kilometers*
<Chipaca> the closest are over the horizon
<Chipaca> sergiusens: travis ate pregnant snail soup this week
<sergiusens> probably
<sergiusens> Chipaca: is core16 being worked on as a proper base?
<Chipaca> sergiusens: define "being worked on"
<Chipaca> sergiusens: yes
<Chipaca> sergiusens: the focus of work is on core18 right now
<Chipaca> sergiusens: core16 _will_ become, itself, the focus once everything in core18 is done
<Chipaca> sergiusens: whereby core16 + snapd snaps will replace the core snap of old
<Chipaca> sergiusens: waarom?
<sergiusens> Chipaca: transparent migration? Hope it goes better than ubuntu-core -> core :-)
<Chipaca> sergiusens: ubuntu-core -> core was *fine*
<sergiusens> Chipaca: yeah, after all the errors were fixed ;-) I had to reinstall all my snaps!
<Chipaca> sergiusens: LA LA LA LA IT WENT FANT LA LA LA
<Chipaca> FINE*
<Chipaca> fant wtf
 * Chipaca looks at his nearly-empty beer
 * Chipaca identifies the problem
<Chipaca> brb, topping up
<mvo> jdstrand: I updated 5621 again, thanks for the excellent feedback
<jdstrand> mvo: cool, np
<kyrofa> If I `snap revert`, and later want to return to the revision from which I reverted, how might I do that?
#snappy 2018-08-11
<zyga> kyrofa: snap refresh, I suspect
<zyga> hey Kyle; how are you today?
<zyga> (and greetings from the last day of Flock)
<zyga> kyrofa: hey, can you check something for me please?
<zyga> ah, I just realized your messages are from 10 hours ago /facepalm
<jeremies> Can I trust user Snapcrafters that https://snapcraft.io/eclipse doesn't contain malware?
<popey> yes,
<popey> https://github.com/snapcrafters/eclipse/blob/master/snap/snapcraft.yaml
<popey> it builds from that yaml, which pulls from upstream
<popey> https://launchpadlibrarian.net/376399971/buildlog_snap_ubuntu_xenial_amd64_edeec2ed13f63e3af682dd5a8c6978d0-xenial_BUILDING.txt.gz
<popey> that's the build log
<palasso> hey fellas if I find typos in the blog posts should I open a bug someplace or should I contact the authors?
<palasso> I was referring to the blog that is on snapcraft.io
<jeremies> popey: Thank you very much !
<palasso> Which probably follows some of the articles from https://blog.ubuntu.com/ (with the tags snapcraft, snap etc.)
#snappy 2018-08-12
<ogra> /bin/sh: 1: msgfmt: not found
<ogra> WTF !!!
<ogra> why does snapcraft cleanbuild ship gettext in the build env but build.snapcraft.io doesnt !
<ogra> GRMBL
<ogra> \o/
<ogra> $ qemu-virgil -enable-kvm -m 1024 -device virtio-vga,virgl=on -display sdl,gl=on -redir tcp:10022::22 ../ubuntu-core-16-amd64.img
<ogra> $ ssh -p 10022 localhost sh -c 'dmesg|grep virgl'
<ogra> [    2.411299] [drm] virgl 3d acceleration enabled
<ogra> YAY !!
 * ogra goes and tests on nvidia ... 
<ogra> yippie !
#snappy 2019-08-05
<mborzecki> morning
<mborzecki> that's a new none - Download snap "test-snapd-openvswitch-support" (11) from channel "stable" (stream error: stream ID 1; PROTOCOL_ERROR)
<zyga> good morning
<zyga> mborzecki: how are you :)
<mborzecki> zyga: hey
<zyga> mborzecki: we saw some of that last week, cause unknown but not investigated either
<mborzecki> zyga: https://copr.fedorainfracloud.org/coprs/bboozzoo/snapcraft/
<mborzecki> packaged the damned thing eventually
<zyga> excellent
<zyga> what's your plan for flock?
<mborzecki> zyga: we've updated the slide deck, snapcraft is kind of packaged, i got the snapcore/go-gettext package approved and need sponsoring (got some reviews to do)
<mborzecki> zyga: other than that, cover the important bits and improvise
<zyga> mborzecki: if someone asks, what's the outlook for using snapcraft on fedora using fedora bases
<jamesh> zyga: hi.  Was there supposed to be some review comments with https://github.com/snapcore/snapd/pull/7197#issuecomment-517256824 ?
<mup> PR #7197: usersession: track connections to session agent for exit on idle and peer credential checks <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7197>
<zyga> jamesh: hey, I don't know from the top of my head
<mborzecki> zyga: tbh, the question is what's the outlook for non-ubuntu bases
<zyga> jamesh: last week was rather busy, and I had little chance to look at PRs
<jamesh> zyga: it looks like you might have had unsaved review comments at some point and clicked send
<zyga> jamesh: oh, it still shows pending here.
<mborzecki> zyga: this topic seems to be progressing really slow https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153
<zyga> jamesh: github UX snafu, I'm sorry about that
<jamesh> zyga: fair enough.  I know you were busy last week
<zyga> I just sent it, it is only one comment though
<jamesh> thanks
<zyga> jamesh: I didn't go deeper than that function
<pstolowski> morning
<pstolowski> hey zyga, welcome back!
<mborzecki> pstolowski: hey
<zyga> pstolowski: hey, it's good to be back :)
<zyga> pstolowski: ETOOMANYMILES
<pstolowski> :)
<pstolowski> hey mborzecki
<zyga> pstolowski: one idea from the sprint https://github.com/snapcore/snapd/pull/7205
<mup> PR #7205: rfc: introduce confinement options failsafe flag <Created by zyga> <https://github.com/snapcore/snapd/pull/7205>
<zyga> pstolowski: it's not fleshed out fully
<zyga> but should help when we have bugs that we don't know about
<pstolowski> zyga: right, i saw this PR, was wondering if there was any discusson behind it, good!
<zyga> pstolowski: only at the sprint
<zyga> pstolowski: one more aspect to explore is to allow a specific interface endpoint to fail
<zyga> without failing all of the device setup
<zyga> (in failsafe mode)
<zyga> e.g. allow serial-port-abc to fail without breaking snapd/core
<pstolowski> zyga: added a comment
<jamesh> zyga: for the mount namespace case, it might just mean that problems in the non fail-safe never get reported because they appear to work
<zyga> jamesh: indeed, we can expand it to talk to the error tracker if needed
<zyga> jamesh: but we also need to be mindful of a single error down in the guts propagating to effective DOS on snapd
 * dot-tobias says hi
<dot-tobias> sergiusens: Can you give me a quick hint here please? (outdated snapcraft homebrew formula) https://forum.snapcraft.io/t/install-snapcraft-on-macos/9607/4
<mborzecki> google:debian-sid-64:tests/main/sbuild keeps failing
<mborzecki> the debug log isn't helpful :/
<zyga> mborzecki: do you have a sample?
<mborzecki> zyga: https://paste.ubuntu.com/p/yjjz4S9ndQ/
<mborzecki> zyga: heh E: Build failure (dpkg-buildpackage died)
<zyga> hmmm
<zyga> is this on master or on your branch?
<mborzecki> on my branches
<mup> PR snapd#7209 opened: firstboot: queue service cmds before mark-seeded <Created by stolowski> <https://github.com/snapcore/snapd/pull/7209>
<zyga> mborzecki: are you changing dependencies?
<zyga> mborzecki: network failed?
<mborzeck1> zyga: duh, graphics froze, cpu fan 100%
<mborzeck1> zyga: i.e. the year of linux desktop is upon us
<zyga> mborzeck1: laptop or desktop?
<mborzeck1> zyga: laptop
<zyga> x230?
<zyga> or x250?
<mborzeck1> zyga: 250
<zyga> mborzecki: does ohmygiraffe work for you on arch?
<zyga> mborzecki: it crashes on TW
 * zyga needs to update to 2.40
<mborzecki> zyga: used to work
<mborzecki> zyga: yup works
 * pstolowski lunch
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/7210
<mup> PR #7210: packaging/debian-sid: set GOCACHE to a known writable location <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7210>
<mup> PR snapd#7210 opened: packaging/debian-sid: set GOCACHE to a known writable location <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7210>
<zyga> mborzecki: what is that -pkgdir?
<zyga> mborzecki: I have slight preference for /tmp/ for GOCACHE
<zyga> but not strong one
<mborzecki> zyga: -pkgdir is set by dh-golang
<mborzecki> zyga: and afaiu dh-golang sets GOCACHE to point to _build as well
 * zyga goes for lunch
<mborzecki> - Fetch and check assertions for snap "test-snapd-tools_6" (6) (cannot fetch assertion: got unexpected HTTP status code 408 via GET to "https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw?max-format=3")
<mborzecki> pff
<mborzecki> btw. PROTOCOL_ERROR has this in debug log:  DEBUG: Not retrying: http.http2StreamError{StreamID:0x1, Code:0x1, Cause:error(nil)}
<mborzecki> soo that does look like HTTP2 level issue
<mborzecki> well, at least the sbuild fix PR didn't fail in sbuild :)
<cachio> mborzecki, did you see that today?
<mborzecki> cachio: yes, 3-4 times already
<mborzecki> cachio: last time in https://github.com/snapcore/snapd/pull/7210
<mup> PR #7210: packaging/debian-sid: set GOCACHE to a known writable location <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7210>
<cachio> mborzecki, good, I'll see that with the store team
<cachio> mborzecki, thanks for the info
<zyga> cachio: I'll get back to you on the 2.40 release plan soon
<cachio> zyga, ok
<cachio> zyga, I' have an app with my accountant in 30 minutes
<cachio> zyga, just ping me and I'll ping you back once I am back
<zyga> sure
<sil2100> zyga: hey! Since we'll be preparing the 18.04.3 point-release ubuntu-core images soon (both for 16 and 18), just wanted to touch base if the current snapd in stable is good to go to the new official stable images
<sil2100> zyga: is the current stable snapd good for refreshed image release? ;)
 * cachio afk
<pstolowski> ogra: hey, i've a task to look at failure scenarios where a device fails at first boot setup and is rebooted, and doesn't come back (doesn't boot anymroe); i've heard you experienced such issues before, do you have any concrete examples, reproducers, or logs?
<pstolowski> also ondra ^ ?
<ondra> pstolowski yeah it's easy one
<ondra> pstolowski when anything fails during first boot seeding, we do revert 'uninstall' all snaps
<ondra> pstolowski this actually removes kernel and core snap sym links from 'vat/lib/snapd/snap'
<ondra> pstolowski I think to make first boot more robust, we should do two changes, in snapd and initrd.
<ondra> pstolowski when we look for core and kernel snap, we should consider two locations '/var/lib/snapd/snaps' '/var/lib/snapd/seed/snaps'
<ondra> pstolowski so we have fallback when snaps are removed
<pstolowski> ondra: ack, thanks, i need to look at the code
<ondra> pstolowski easy way to reproduce is to make gadget snap with malformed gadget.yaml, and build image with it
<ondra> pstolowski e.g. and non supported role:
<ogra> pstolowski, ondra there is also the core18 case where snapd doesnt properly get seeded and you end up with an error from console-conf "snap command not found" or some such
<ogra> coe18 is a lot more fragile in that due to the singling out of snapd
<zyga> cachio: postponed till next week
<zyga> sil2100: current as in 2.39.x?
<zyga> sil2100: I think anything in stable is good, I don't know of any blockers that would affect images
<zyga> sil2100: what's the time frame? we will publish 2.40 to stable next week
<sil2100> zyga: it's all happening this week, with a ETA for the release this Thursday
<ondra> ogra yes this is same case
<sil2100> zyga: thanks for the heads up then o/
<zyga> sil2100: In that case do use 2.39.x, 2.40 will bake and we can try next time :)
<pstolowski> ondra, ogra thanks, i need to digest it and think about this
<zyga> willcooke: help, I cannot create topics on the WSL category
<zyga> I wrote the whole thing and saved it to clipboard
<zyga> willcooke: when I attempt to save all I get is "You are not permitted to view the requested resource."
<willcooke> zyga, zoiks!  One sec...
<zyga> mborzecki: udev rewrite tests running, I think it will be green
<zyga> mborzecki: I will need to sit down and think how to test it, I will start by writing simple unit tests tomorrow
<willcooke> zyga, hm.  "everyone" can create/reply/see.  Investigating
<willcooke> zyga, I think this might have been a "user trust level" thing.  I've bumped you up, can you try now?
<zyga> willcooke: https://discourse.ubuntu.com/t/using-snapd-in-wsl2/12113
<willcooke> zyga, \m/ \m/ thank you!
<zyga> pleasure :)
<zyga> diddledan: ^ I think you have more experience with this
<zyga> perhaps you can expand on the topic
<cachio> zyga, ok, thanks for the update
 * zyga EODs
<pstolowski> cachio: ping
<cachio> pstolowski, yes
<mup> PR snapd#7211 opened: tests: add more debug information to see the root cause of the protocol error <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7211>
<ogra> jdstrand, pocketbeagle is my gadget ... no need to notify me about it ;)
<jdstrand> ogra: ah, I missed that. can you request a manual review?
<ogra> will do :)
<diddledan> popey: you about?
<popey> Sup?
<diddledan> ooh, ello, pm a sec, popey ?
<popey> Sho thang
 * diddledan /msgs
<mup> PR snapcraft#2654 opened: click: update to 7.0 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2654>
#snappy 2019-08-06
<zyga> o/
 * zyga travels today
<mup> PR snapd#7212 opened: tests: respect SPREAD_DEBUG_EACH on the main suite <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7212>
<mup> PR snapd#7213 opened: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7213>
<mup> PR snapd#7214 opened: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
<mborzecki> morning
<zyga> Hey
<zyga> mborzecki: wish me luck :-) trying to use pkp today
<zyga> Bought ticket online, barely. I cannot understand why that system is so poor
<zyga> Now noticed that âmandatory replacement bus serviceâ is to be used
<mborzecki> hahaha
<mborzecki> zyga: *) walking short distances included
<zyga> Foreigners beware :-)
<zyga> I sent a pair of PRs
<zyga> Stuff from yesterday
<zyga> Once I am on board I will ping you
<zyga> âOpÃ³Åºnienie moÅ¼e ulec zmianieâ ð
<zyga> I âlikeâ how they repeat the same announcement about each train like 10 times
<zyga> Definitely not confusing because there is something being said all the time
<zyga> mborzecki: ok, settled in
<zyga> fantastic service, 2 minutes late on arrival, 15 minutes wifi included
<zyga> eh, everything is red again
<mborzecki> zyga: why red? the sbuild task?
<zyga> yeah
<zyga> just merged your fix
<mborzecki> zyga: cool, thx
<mup> PR snapd#7210 closed: packaging/debian-sid: set GOCACHE to a known writable location <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7210>
<mborzecki> zyga: the year of linux desktop, apparently when logging into gnome on wayland, there's likely some race in gsd where it fails to set up your keyboart shortcuts :/ you have to log out and log in once more
<zyga> mborzecki: brilliant
<mborzecki> why am i even surprised :)
<zyga> mborzecki: just buy a mac already
<zyga> mborzecki: maybe in 10 years
<zyga> mborzecki: maybe it will work ;-)
<zyga> mborzecki: having said that, try WSL2
<mborzecki> zyga: woudl need to have windows for that
<zyga> I think this is a transformative, game-changing development
<zyga> mborzecki: get a free eval version for 90 days
<zyga> it's well worth playing with
<mborzecki> zyga: i'm using eval for games, though can't quite recall when was the last time i booted it
<zyga> mborzecki: switched over to my ubuntu phone for network
<zyga> mborzecki: I wonder how much of the journey will have cellular coverage
<zyga> mborzecki: I recall it's ~ 30%
<zyga> mborzecki: btw, once again I'm reaffirmed that 13" is the perfect travel laptop
<zyga> mborzecki: my 15" is at home, it's a good secondary desktop but it's not fit for travel
<zyga> it would not fit on the intercity folding table, it would not fit on the economy airline folding tray, etc
<mborzecki> brb, new kernel
<mborzecki> so, running 5.2.6 now
<zyga> neat
<zyga> I'm on 5.2.0 still
<mborzecki> zyga: still on tw?
<zyga> mborzecki: tw?
<mborzecki> tumblweed
<zyga> mborzecki: ah, no, this is eoan
<zyga> mborzecki: I'm using in on the huawei
<zyga> mborzecki: I kind of miss TW but it is just for 4 days :)
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> 123 testing
<zyga> I'm arriving in 20 minutes, I will be online in around an hour again
<mborzecki> brb, quick errand, back in 30
<zyga> Iâve arrived but will be AFK for a few more moments
<mborzecki> re
<mborzecki> zyga: somewhat closed to reproducing context canceled in unit tests, `while true; do : |  taskset -c 0,1 ./snap.test -test.count=1 || break; done` seems to work
<mborzecki> zyga: somehow can't reproduce it when i replace s.tomb.Context(nil) with context.TODO()
<zyga> re
<zyga> what is taskset -c 0,1?
<zyga> cpu affinity?
<zyga> mborzecki: I'm not an expert on context, perhaps Context.TODO does nothing at all but Context from tomb is a real deal that need some code?
<zyga> mborzecki: ok, unless anything else interrupts I'll work on the bugfix
<Perkol> How do I install local package with snap?
<popey_> Perkol: can you elaborate?
<popey_> zyga: are you able to help with https://github.com/snapcore/snapd/pull/7129 ?
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<jwheare> related to that, is it possible to detect the snapd version at runtime from an app?
<jwheare> once that is merged, we'd only want to prompt to handle url schemes for a supporting version of snapd
<zyga> popey_: looking
<zyga> jwheare: you can use "assumes" for that
<popey_> jwheare: no, but you can use "assumes: 2.40" (for example)
<zyga> jwheare: though that is a static annotation on a snap, not a dynamic check
<popey_> https://snapcraft.io/docs/snapcraft-yaml-reference
<mborzecki> zyga: ok, i think i know what's going on, (goroutine 1) the agent calls Shutdown(ctx) with child context obtained from tomb, (goroutine 2) http.Serve() in tomb's func exits and returns nil, in t.kill() the child context get cancelled, and sets the reason to nil, rescheduled back to (1) child context is canceled, calls t.Kill(err), which sets the tomb's err context.Canceled (since it was nil as http.Serve() exited and didn't set one)
<zyga> jwheare: you can use snapctl to query for the version
<mborzecki> mborzecki: so, a race, and perhaps a bug in use of tombs as well
<zyga> at least I think you can, I'd have to check the API
<zyga> I need to prioritize tasks
<zyga> sorry, settling ing
<zyga> settling in
<jwheare> yeah i wouldn't want to block installation of the app entirely based on that missing feature
<jwheare> just need to determine whether to show the prompt on first launch
<zyga> jwheare: unfortunately snapctl has missing features as compared to snap
<zyga> jwheare: technically there is the /v2 API endpoint that has this information
<zyga> it's just not exposed with snapctl
<jwheare> could just do a version check though
<zyga> jwheare: that's the thing, you cannot
<zyga> nothing will tell you which version of snapd is there
<popey_> zyga: can you use curl from inside a snap to the snapd api?
<zyga> popey_: based on a quick look, no
<zyga> popey_: there are two sockets, if you recall
<zyga> popey_: one is for full snapd api
<zyga> popey_: and you cannot use it without snapd-control
<zyga> popey_: the other one is for snapctl
<zyga> popey_: but this one doesn't expose this
<pstolowski> ondra: hey, thanks for yesterday's explanation of the failing first boot scenario; easily reproduced with broken gadget snap, also spotted the code responsible for this in snapd (i also looked at initrd script as well)
<zyga> pstolowski: cool, :)
<pstolowski> i'm just wondering how to test potential snapd fix without waiting for a new core image in edge
<zyga> pstolowski: can you walk me through it?
<zyga> pstolowski: maybe that will help
<pstolowski> zyga: quick HO?
<zyga> pstolowski: perhaps just chat, sorry, there's some distraction around here and my network is so-so
<pstolowski> zyga: sure
<zyga> pstolowski: let's try an audio-only one?
<zyga> pstolowski: facetime audio?
<pstolowski> zyga: ok
<zyga> calling now
<jwheare> huh ok
<jwheare> is there any info on release cadence and adoption rates for new versions of snapd?
<popey_> Most people get their snapd version from an automatic update of the core snap (or core18), via re-exec...
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/7215
<mborzecki> pstolowski: ^^
<mup> PR #7215: usersession/agent: use background context when stopping the agent <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7215>
<mup> PR snapd#7215 opened: usersession/agent: use background context when stopping the agent <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7215>
<popey_> jwheare: roughly 99.97 of snap users are on the latest 2.39
 * diddledan wants 2.41 already :-p
<zyga> looking
<diddledan> hopefully .41 will include my optical-drive/scsi-generic patch that might enable makemkv
<popey_> Nice!
<zyga> mborzecki: s/a the/.../
<popey_> (that 99.97 should be a percentage, of course) :D
<diddledan> I think it was merged too late for inclusion in .40
<diddledan> I choose to ignore that you think it's a percentage, and ask whose lost .03 of a person? :-p
<popey_> Danny DeVito doesn't like automatic updates.
<diddledan> who's? which whose/who's should that be?
<zyga> mborzecki: I'm honestly quite lost by the context stuff, I need to read more upon it
<diddledan> whom
<diddledan> https://twitter.com/natfriedman/status/1158557170423611393
<zyga> mborzecki: I mean, the pathc looks good
<zyga> *patch
<zyga> I just feel unqualified to say so
<mborzecki> haha :)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7215#pullrequestreview-271258784
<mup> PR #7215: usersession/agent: use background context when stopping the agent <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7215>
<zyga> we have 81 PRs
<zyga> can we look at merging some
<zyga> when mvo sees 101 PRs he will smite anyone opening a new one ;)
<zyga> for instance: https://github.com/snapcore/snapd/pull/7212
<mup> PR #7212: tests: respect SPREAD_DEBUG_EACH on the main suite <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7212>
<zyga> (shamelessly my own)
<zyga> can we +1 that?
<zyga> hola cachio :)
<zyga> Iâm going for a walk
<cachio> zyga, hey
<cachio> zyga, buenos dias
<zyga> re
<zyga> I tweaked the test, it should now pass everywhere
<pstolowski> hey cachio
<cachio> pstolowski, hey
<mup> PR snapd#7212 closed: tests: respect SPREAD_DEBUG_EACH on the main suite <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7212>
<mup> PR snapd#7187 closed: data/selinux: allow snap-confine to read entries on nsfs <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7187>
<mborzecki> pstolowski: can you take a look? https://github.com/snapcore/snapd/pull/7137
<mup> PR #7137: gadget: support for writing symlinks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7137>
<zyga> hmm, I somehow made a racy service ...
 * zyga thinks
<diddledan> don't make me run. the leg movement makes my belly turn into a pendulum and I fall over
<diddledan> plus: seriously unfit!
 * diddledan eyes zyga's race..
<mborzecki> have i already complained that tests/main/sbuild occasionally hits spread job timeout?
<zyga> mborzecki: do we know where it spends most of the time?
<diddledan> interesting. python3's venv module in disco (core18) is not relocatable - it tries to, and fails to, read files in /usr/share/python-wheels
<mborzecki> cachio: restarted https://github.com/snapcore/snapd/pull/7211 bc it didn't fail with PROTOCOL error, maybe we'll get lucky in the next run
<mup> PR #7211: tests: add more debug information to see the root cause of the protocol error <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7211>
<cachio> mborzecki, thanks
<mborzecki> zyga: idk, tbh, when debugging that task manually on gcp i managed to get 3 incomplete runs before the node was killed
 * zyga has issues with systemctl restart
<mborzecki> cachio: wondering, if you have the log from when the problem happens, perhaps you could try to run the request with curl --http2
<zyga> is that different from stop + start?
<cachio> the problem happens basically when we need to download a snap from fastly and it is not in the endpoint, so it goes to get it from a central repository
<cachio> mborzecki,
<cachio> mborzecki, it happens really sporadically
<zyga> I'm trying with stop + start
<cachio> mborzecki, yesterday verterok requested information I think
<cachio> I don't know if there is more info about this protocol issue
<mborzecki> cachio: mhm
<verterok> cachio: Hi, yesterday I filed a support ticket to fastly, got a reply: they can't reproduce
<verterok> cachio: if there is a way to reproduce, that would be helpful, otherwise I think the http2debug logs might shed some light
<cachio> mborzecki, I added the GODEBUG=http2client=1 to te test env but logs are the same
<cachio> after the protocol error
<cachio> do you know if it is ok or I should change something?
<cachio> perhaps display a different log on debug?
<mborzecki> cachio: do you have the log that contains the error?
<cachio> mborzecki, you restarted the failed log :)
<cachio> mborzecki, last exec failed with protocol error
<mborzecki> cachio: in 7211? that one failed because of sbuild
<cachio> mborzecki, or perhaps someone else restarted that before?
<cachio> yesterday I saw that
<cachio> no worry in that case
<cachio> lets see if fails now
<zyga> restarting services is tricky
<zyga> snap "run" chain takes long enough that raciness is easy
<zyga> I wonder if we could turn all daemon simple into daemon notify internally
<zyga> where we only poke systemd at around snap-exec
<mborzecki> pfff 2019-08-06 11:48:32 Error executing google:ubuntu-19.04-64:tests/main/login : read tcp 10.20.0.181:57254->34.74.6.202:22: use of closed network connection
<zyga> mborzecki: mmmmm
<zyga> our shutdown code does not seem very reliable?
<zyga> *yes*
<zyga> finally it passed
<zyga> now it will not fail, but I feel we have a problem
 * zyga tries on 14.04
<cachio> mborzecki, you are right about the #7211, I saw the protocol error in another one
<mup> PR #7211: tests: add more debug information to see the root cause of the protocol error <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7211>
<cachio> mborzecki, this happens when I have like 15 logs open heheheh
<ijohnson> hey folks, can I get another review on https://github.com/snapcore/snapd/pull/7189 ? :-)
<mup> PR #7189: HACKING.md: update spread section, other updates <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7189>
 * zyga is on the roof
<zyga> obviously storm is coming now
<pstolowski> zyga: don't stay with antenna in your hand
<ogra> get an umbrella so you dont get wet ...
<zyga> -80dBm signal
<zyga> hmmm, a bit crappy
<zyga> I need a longer pole
<zyga> anyway
<zyga> that's that for now
<mup> PR snapd#7189 closed: HACKING.md: update spread section, other updates <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7189>
<ondra> pstolowski cool
<ondra> pstolowski I can point you easily to initrd code if you want
<pstolowski> ondra: i found it
<ondra> pstolowski cool
<ondra> pstolowski what do you think is best way, assume seed as primary location instead of looking in vat/lib/snapd/snaps?
<ijohnson> thanks for the merge zyga
<pstolowski> ondra: good question, i'm not sure we need to change initrd, making snapd more robust should fix it. but if we change initrd, we would make seed a fallback, not primary, no?
<ondra> pstolowski I'd prefer to make initrd also more forgiving
<ondra> pstolowski if we check snaps and seed/snaps for kernel and core snap, there should be no danger and it will make boot more reliable
<ondra> now we are creating symbolic link only to make initrd happy
<ondra> pstolowski if we use seed for first boot, it will be more aligned with all other snaps, now we are treating core and kernel snaps at first boot as special snow flakes :)
<ogra> would you do the seeding from initrd then ?
<ogra> (and gpg verification etc etc)
<ogra> that will likely grow the initrd a lot
<ogra> (which in turn would make the boot slower on low-end HW)
<pstolowski> ogra: no, it's just about looking for kernel in seed/ even if there is no symlink
<zyga> ondra: https://bugs.launchpad.net/snapd/+bug/1838937 it is public now
<mup> Bug #1838937: device cgroup enforcement is partially ineffective for snap services <snapd:In Progress> <https://launchpad.net/bugs/1838937>
<pstolowski> ondra: where is the repository for initrd code?
<Sheogorath[m]> Hey guys, I'm currently looking into Ubuntu Core and I'm confused about the update process, because I see that apps are updated using snap, but how is the system image/kernel updated? Also via snap?
<ogra> pstolowski, https://github.com/snapcore/core-build ?
<ijohnson> Sheogorath[m]: yes the kernel and rootfs is also updated via gadget and kernel snaps
<Sheogorath[m]> ijohnson: Do you happen to know how unsuccessful upgrades are handled? (i.e. New kernel installed, device no longer boots)
<ijohnson> updates are transactional, so if the device fails to boot, it will automatically rollback to the previous kernel
<Sheogorath[m]> :+1: Thanks, that's what I wanted to know. Any pointer for docs on that?
<pstolowski> ogra: thanks
<ijohnson> Sheogorath[m]: see https://assets.ubuntu.com/v1/66fcd858-ubuntu-core-security-whitepaper.pdf
<Sheogorath[m]> Awesome thanks!
 * cachio lunch
<ondra> pstolowski reference is here https://github.com/snapcore/core-build/tree/master/initramfs
<ondra> pstolowski but I think there is also ppa
<pstolowski> ondra: yep, thanks, got it from ogra
<ondra> pstolowski OK :)
<pstolowski> ondra: btw, does any change there land automatically in core from edge? how can i test it before it lands?
<ondra> pstolowski what would be question to ogra
<ondra> pstolowski I do usually build own kernel snap to test
<ondra> pstolowski you can append initrd overlay to existing initrd blob and it will overide file in question
<pstolowski> ondra: can you elaborate or give a pointer to doc? sorry, i'm new to this..
<ondra> pstolowski no worries
<ondra> pstolowski see https://git.launchpad.net/~ondrak/ondras-snaps/+git/linux-kernel/tree/snapcraft.yaml?h=snapdragon-fit-dmcrypt#n142
<ondra> pstolowski line 142 builds overlay initrd, in your case this would be likely just one file in there
<ondra> pstolowski line 143 will then put two together
<ondra> pstolowski actually check line 145
<ondra> pstolowski something like this https://paste.ubuntu.com/p/2MsV3hwtyc/
<pstolowski> ondra: got it, thanks. so looks like to test it with qemu & amd64 core image i need to rebuild amd64 kernel snap, that means assertions etc
<ondra> pstolowski no need for new assertion
<ondra> pstolowski you can sideload kernel snap
<ondra> pstolowski unpack stock kernel snap, append to existing initrd.img, snap pack, and build image with --snap <path to kernel snap>
<pstolowski> ondra: ah, allright.. will try that out, thanks!
<mup> PR snapd#7216 opened: interfaces/misc: updates for k8s 1.15 (and greengrass test) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7216>
<mup> PR snapd#7217 opened: interfaces/bluetooth-control: add udev rules for BT_chrdev devices <Created by kubiko> <https://github.com/snapcore/snapd/pull/7217>
 * zyga fell asleep
<zyga> sorry folks, I'm just exhausted by lack of sleep
<roadmr> zyga: ð¤  timezone shifting is tough. Take it easy :)
<cwayne> roadmr: sprinting is tough even without the timezone shifting :)
<cwayne> as I've just now learned
<zyga> roadmr: yeah, I'm just tired
<roadmr> cwayne: it is, yes
<cwayne> roadmr: especially when the last lightning talk breaks your stuff ð
<roadmr> cwayne: I attended the snapcraft summit earlier this year - it was local (so just swapped WFH for a 25-minute commute downtown) - I was still exhausted by the end of the week
<cwayne> roadmr: oh i believe it
<cwayne> it's called sprinting for a reason!
<roadmr> cwayne: haha :) popey will be happy to know we have a fix for the null snap, should be in prod in the next couple of days
<popey_> roadmr: hurrah!
<zyga> roadmr: what was the issue?
<zyga> roadmr: None
<zyga> ;D
<zyga> (it's a joke)
<roadmr> zyga: exactly :)
<roadmr> we were happily assuming that if a key was present in a dict, the value would be non-none :D
<popey_> How wrong you were!
<popey_> (interestingly I never intended it to fail the store, it worked in my earlier test because I did it slightly differently)
<roadmr> popey_: remember what they say about assuming
<roadmr> https://www.explainxkcd.com/wiki/index.php/1339:_When_You_Assume
<zyga> roadmr: mypy got a new feature lately
<zyga> roadmr: typed dicts
<zyga> roadmr: it's super useful
<popey_> Made for a nice end to the talk though, thanks for speaking up :D
<roadmr> \o/
<roadmr> popey_: you've raised the bar, now Chipaca's challenge is to also crash the store on-stage
<roadmr> (he's crashed it plenty, just behind the scenes mostly)
<popey_> DEAL!
<popey_> given the null snap is a noop effectively, it's fun to run it with --trace-exec :D
<popey_> snap-confine will always be ~0.029s or so, even on an empty snap
<zyga> I've sent a patch for improving that
<zyga> though a good chunk is constant cost of go
<popey_> Good. 0.029s is outrageous! :D
<zyga> it really is
<popey_> huh. today I learned you can "snap info path/"
<popey_> I just did "snap info null" and wondered why I didn't get info about channels. It was seeing the null/ folder in my home that I used to make the snap
<popey_> that's confused me for a few moments!
<mup> PR snapd#7215 closed: usersession/agent: use background context when stopping the agent <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7215>
<mup> PR snapcraft#2655 opened: Gnome extension <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2655>
<mup> PR core-build#50 opened: initramfs: run recover mode if trigger is detected <Created by cmatsuoka> <https://github.com/snapcore/core-build/pull/50>
<kyrofa> roadmr, noise][, trying to upload a  banner for my snap. Restrictions state "Min resolution: 720 x 240 pixels" and "Max resolution: 4320 x 1440 pixels". But when uploading a 4320x1440px image, I get an error: "Legacy banner (banner.png) image must be 1218x240 pixels in size"
<kyrofa> roadmr, noise][: the stated restrictions also include "Aspect ratio: 3:1", which 1218x240 is not
<kyrofa> What should we be using, here?
<roadmr> kyrofa: either don't name it banner.png, or comply with the 1218x240 requirement
<kyrofa> ... seriously? It cares about the name I chose on a file upload?
<kyrofa> I'm doing this through the web ui
<roadmr> ............. yes
<kyrofa> Hahaha
<roadmr> kyrofa: there's some special handling for those "legacy" banners
<kyrofa> That is very confusing
<kyrofa> But you're right, renaming it works
<roadmr> kyrofa: yep - that'll go away in the future and there will be a specific "banner" media type - the issue right now is that the old way of handling it relied on a specially-named screenshot named banner.png
<roadmr> (well, I say "old" but as you can see, this is still in place - we're working on it :)
<noise][> to be phased out legacy banner method
<noise][> and yeah, kinda unfortunate, but here we are
#snappy 2019-08-07
<mup> Bug #1839230 opened: duplicate login message on raspberry pi core18 image <core18> <Snappy:New> <https://launchpad.net/bugs/1839230>
<mborzecki> morning
<mup> PR snapd#7186 closed: gadget: ensure filesystem labels are unique <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7186>
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mborzecki> wow, tmux died
<mborzecki> as in segfauled and all
<zyga> good morning
 * zyga is curing his sleep deficit by falling asleep at random times :/
<zyga> how are you doing guys?
<zyga> sil2100: hello
<zyga> sil2100: do you think we can ship bash-completion on core18?
<zyga> sil2100: this is reported as https://bugs.launchpad.net/snappy/+bug/1825254
<mborzecki> zyga: hey
<mup> Bug #1825254: auto-complete doesn't work on ubuntu core 18 <core18> <Snappy:Confirmed> <https://launchpad.net/bugs/1825254>
<mborzecki> zyga: tried to investigate the http2 PROTOCOL_ERROR we see randomly, but there's quite a number of places in net/http that generate an error matching the log
<mborzecki> zyga: left a topic though https://forum.snapcraft.io/t/snap-download-failures-with-protocol-error/12677
<mborzecki> zyga: fwiw, nothign significant in curl output, also a minial http request in tried in go did not raise anytying suspicious
<zyga> mborzecki: thank you
<zyga> mborzecki: I wonder if it could be a go thing?
<zyga> but we didn't change anything on our end, did we?
<zyga> no now go compiler rev?
<mborzecki> zyga: hm maybe, i can try with older version of go, 16.04 uses 1.10?
<zyga> mborzecki: I don't remember, just wonder if it's a bug in go in general and we're hitting it along with others now
<zyga> mborzecki: the alternative is that it is a bug in our web side
<zyga> mborzecki: but again, I don't have any data to sway either side
<zyga> sil2100: on the same vein, is https://mail.google.com/mail/u/1/ something we can fix?
<zyga> sil2100: seems like a pair of tweaks to core18
<zyga> er :)
<zyga> https://bugs.launchpad.net/snappy/+bug/1839230 :)
<mup> Bug #1839230: duplicate login message on raspberry pi core18 image <core18> <Snappy:New> <https://launchpad.net/bugs/1839230>
<zyga> silly copy paste
<mborzecki> zyga: no change with 1.10, wish there was a way to dump the http request/response headers in go in a reliable way
<zyga> mborzecki: would using pcap help?
<zyga> or are those all ssl?
<mborzecki> zyga: uses tls
<mborzecki> zyga: about that reddit thread: https://www.reddit.com/r/linux/comments/cmse4r/interview_why_canonical_views_the_snap_ecosystem/ the comemnts are pretty depressing
<zyga> yeah, internet is as it was
<zyga> I think it's important to have our own voice
<zyga> I hope that degville martin and alan can come up with the daily snap podcast or something like that
<zyga> I think a good fraction of those comments are just misinformed
<mborzecki> also funny how some particular users seem to be repeat the same thing over and over again under a number of submissions
<mborzecki> i mean, i understand how one can not like something, but tbh it seems as if some poeple have plenty of free time ;)
<zyga> kenvandine: hey, do you know about this issue where the mouse cursor changes appearance inside some snap applications? do you know how this part of the stack works?
<zyga> kenvandine: there are some bug reports about it
<zyga> one I found just now is: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579268
<mup> Bug #1579268: Mouse cursor is different inside graphical windows of snaps (snaps not using system theme) <Snappy:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1579268>
<mborzecki> zyga: iirc electron was a suspect there last time
<zyga> mborzecki: yeah but electron inside snaps
<zyga> mborzecki: we could call the podcast "responding to internet trolls" ;)
<zyga> I wish there was one click toggle for dark mode / light mode
<zyga> terminal profile, browser profile, terminal window color, etc
<zyga> it's annoying to have to do this little by little by hand
<mup> PR snapd#7218 opened: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
<zyga> I'm pushing a PR with the tests that show the bug from Friday
<zyga> https://github.com/snapcore/snapd/pull/7218
<mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
<zyga> working on the fix, I gave it some thought and while the 1st part of the fix is indeed very easy
<zyga> the second part is hard
<zyga> the first part is when you "snap connect" the cgroup is confining
<zyga> the hard part is when you snap disconnect the last interface affecting udev
<zyga> you really need to switch the cgroup to unconfined
<zyga> but that's not easy in our model
<zyga> it's also related to udev
<zyga> so we really need a the equivalent of snap-update-ns for cgroups
<zyga> and that's not trivial
<sil2100> zyga: ah, yes, should be a easy fix! Let me note that down
<zyga> sil2100: thank you!
<mborzecki> pulled https://github.com/snapcore/snapd/pull/7166 and the unit tests fail consistently, will investigate more at the airport
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
 * zyga works on fixing https://bugs.launchpad.net/snapd/+bug/1838937
<mup> Bug #1838937: device cgroup enforcement is partially ineffective for snap services <snapd:In Progress by zyga> <https://launchpad.net/bugs/1838937>
<zyga> mborzecki: thank you!
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/7209#issuecomment-519009878
<mup> PR #7209: firstboot: queue service commands before mark-seeded <Created by stolowski> <https://github.com/snapcore/snapd/pull/7209>
<pstolowski> mborzecki: hmm, interesting, ty
<mborzecki> ok, wrapping it up and heading to the airport in a bit and the off to Flock
 * zyga designs snap-update-cgroup
<zyga> it's actually good
<zyga> because that's the only part that needs to talk to udev
 * zyga thinks about getting breakfast first
<pstolowski> ondra: ping
<zyga> the easy half is fixed
<zyga> now thinking about the "hard" half
<zyga> I think I cannot avoid snap-update-ns for cgroups :/
<zyga> I wrote https://forum.snapcraft.io/t/the-need-for-snap-update-device-cgroup/12679
<zyga> it's a bit hard to follow, I will rewrite that for clarity
<zyga> but I think it is unavoidable
<zyga> pstolowski, ondra: ^
<zyga> ideas welcome
<Aavar> Hi! I am having a problem with launching graphical snaps in ubuntu 19.04. Can you help me? https://paste.ubuntu.com/p/2RnQWq3b8Q/
<zyga> Aavar: hey, can you run "snap version" please?
<pstolowski> zyga: ack
<Aavar> zyga, https://paste.ubuntu.com/p/2tkZnVB3pg/
<zyga> Aavar: are you running wayland?
<zyga> note that snap-store should not be launched as root
<Aavar> zyga, No, x11
<zyga> Aavar: can you run "snap connections inkscape"
<Aavar> zyga, https://paste.ubuntu.com/p/2DRKFM6qcY/
<Aavar> (note that I am running Unity7, byt I had the exact same issue when running xfce)
<zyga> do you get any apparmor denials? those can be checked by running "dmesg | grep DENIED"
<zyga> (it will take me 10 minutes to download inscape on my connection)
<Aavar> zyga, yes i do. https://paste.ubuntu.com/p/mzDHfTfg5K/
<Aavar> zyga, inkscape was just an exaple. I get similar errors on all apps with a gui.
 * zyga tries to open the link but struggles 
<zyga> ok, I see it now
<zyga> confinement rejects unix sockets
<zyga> hmm
 * zyga checks
<Aavar> zyga, is it better if I paste to pastebin instead?
<zyga> Aavar: can you run "snap connections --all inkscape"
<zyga> no, it's just my network, I'm sorry about that
<Aavar> ok :)
<Aavar> zyga, "error: cannot use --all with snap name"
<Aavar> zyga, https://paste.ubuntu.com/p/3fQgngzpvd/
<zyga> d'oh :/
<kenvandine> zyga: cursor themes are just icon themes.  So just more icon themes to add gtk-common-themes
<zyga> Aavar: hmmm,
<zyga> kenvandine: hey
<zyga> kenvandine: can you try to look at the behavior Aavar is reporting, graphical apps don't work, it seems they cannot talk to x11
<zyga> kenvandine: one example is inkscape
<zyga> Aavar: 5 minutes to inkscape
<Aavar> zyga, :)
<zyga> 5 minutes till I pull the snap
<zyga> I have very slow network this week
<Aavar> zyga, I understand :)
<kenvandine> Connections look fine
<kenvandine> Not sure what's up there
<kenvandine> unity7 gives access to x11
<kenvandine> I think
<kenvandine> I can't look more now, time to get my son off to school
<kenvandine> But when I get to work I can
<zyga> thank you!
<zyga> Aavar: installed
<zyga> started fine, apart from fractional scaling
<Aavar> kenvandine, thank you. I could just reinstall ubuntu, but it would be great to figure out what I have done to cause this :P
<zyga> Aavar: I have the same connections as you did
<zyga> Aavar: when did this start to happen?
<Aavar> zyga, I few days ago, but I didn't think much of it (just installed the app I needed via apt)
<zyga> did any graphical snaps work for you?
<zyga> as in before some moment when they all broke?
<Aavar> zyga, yes, I used a few (for example inkscape) before they broke.
<zyga> can you recall any change at the time it broke?
<Aavar> zyga, No, thats the thing. I cant remember anything that would cause this.
<zyga> can you look at /var/lib/snapd/apparmor/ and then at the file related to inkscape
<zyga> can you pastebin that file (snap.inkscape.inkscape)
<Aavar> zyga, cat /var/lib/snapd/apparmor/profiles/snap.inkscape.inkscape
<Aavar> zyga, https://paste.ubuntu.com/p/4Zndvv5ZzX/
<zyga> yeah
<Aavar> (ps: Is it a good idea for the purpouse of testing to stop the apparmor service?)
<zyga> no
<zyga> it's not a real service
<zyga> stopping it won't do us any good
<Aavar> ok
<zyga> give me a moment
<zyga> Aavar: can you pastebin /etc/apparmor.d/abstractions/X
<Aavar> zyga, yes. https://paste.ubuntu.com/p/mmMyxsz7sQ/
<zyga> in a terminal, can you echo $DISPLAY and ls /tmp/.X11-unix
<zyga> Aavar: ^
<Aavar> zyga, echo $DISPLAY gives: :0
<zyga> ok
<Aavar> and ls /tmp/.X11-unix gives: X0
<mup> PR snapd#7219 opened: devicestate/firstboot: check for missing bases early <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7219>
<zyga> hmmm
<zyga> so far everything looks good
<zyga> can you run
<zyga> sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.inkscape.inkscape
<zyga> and then "snap run inkscape"
<zyga> brb
<Aavar> zyga, still the same errors: https://paste.ubuntu.com/p/F8dV2x3WHR/
<zyga> hmmm
 * zyga is lost
<zyga> sorry, I have no idea what might be wrong
<zyga> I it clear it cannot talk to X but I don't see why
 * pstolowski lunch
<Aavar> zyga, do you think it could help if I removed everyhing regarding X and reinstall?
<zyga> no, I don't think that would help
<zyga> I think we need another pair of eyes to understand what is going on
<zyga> let's check with kenvandine once he is back
<Aavar> zyga, yes :)
<ondra> pstolowski hi
<ondra> pstolowski sorry I'm still in Canada this week
<zyga> ondra: hey :)
<ondra> zyga hey
 * cachio afk
<pstolowski> ondra: ah, i had no idea, sure
<jdstrand> sergiusens (cc kyrofa): I looked into why kyrofa was getting snap USN emails for snapcraft. there are entries in the store dump for revisions for which kyrofa was the uploader. those revisions aren't published to any channel in the dump I get though
<jdstrand> sergiusens (cc kyrofa): I'd rather not second guess why the store dumps those. would have to talk to roadmr to see (eg, 1549, 1550, 1551, 1552, 1723, 1724, 1725, 1726, 1727)
<jdstrand> sergiusens (cc kyrofa): I could change the algorithm for detecting who to send to, but would wan't to hear from roadmr why those revisions are in the dump
<jdstrand> want*
<sergiusens> jdstrand: thanks for taking a look! Will wait on what the situation is.
<mup> PR snapd#7220 opened: cmd/libsnap: don't leak memory in sc_die_on_error <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7220>
<zyga> + snap install --dangerous /home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-timedate-control-consumer/test-snapd-timedate-control-consumer_1.0_all.snap
<zyga> <kill-timeout reached>
<zyga> hmmmmm
<zyga> master is a sad puppy
 * zyga breaks
<pstolowski> xnox: hey
<kenvandine> zyga Aavar: sorry, forgot i have back to back meetings all morning
<jdstrand> roadmr: hey, can you look at https://paste.ubuntu.com/p/8m8dzfFRTz/ and get back to me whenever it is convenient?
<roadmr> jdstrand: sure, let's see
<kenvandine> Aavar: please pastebin the output from this:
<kenvandine> ls -ltr /run/user/`id -u`/
<jdstrand> roadmr: oh, you know what, I looked at this week's dump (where those revisions are in there with no channel), but the dump in question happened on July 31
<jdstrand> roadmr: (if that helps)
<roadmr> jdstrand: hmm so maybe they were published at that point in time?
<jdstrand> roadmr: note that the USN email that went out on July 31 did not include those channel-less revisions, so I suspect they were channel-less at that time as well
<roadmr> hm. ok, jdstrand, we're checking the logic in the dump script
<jdstrand> roadmr: thanks. I wouldn't consider this urgent work, so, however you want to prioritize it is fine
<jdstrand> roadmr: I thought I remembered there were some brand stores or something that might've pinned old snapcraft revisions for some internal issue that has long since been resolved...
<jdstrand> I don't have any more details on that
<zyga> back from a walk but I need to eat something first
<zyga> because not in a rush I will return in >1hour
<zyga> jdstrand: the fix works, I will give first RFC patches today
<zyga> jdstrand: it's more complex than before but also easier than I thought :)
<zyga> jdstrand: (than in our initial discussions)
<zyga> jdstrand: I think overall it's not super complex though
<jdstrand> that's cool
<zyga> jdstrand: more streamlined I would say :)
<zyga> now for that lunch, I'm starving :)
<jdstrand> I like the more deterministic aspect
<jdstrand> zyga: note, I'm stepping away
<jdstrand> for a little bit
<zyga> jdstrand: that's okay
<zyga> I'm very sleepy all day long, cannot readjust
<jdstrand> zyga: yeah, hope you get back on track soon
<cachio> zyga, hey, I see 2 unit tests faiing https://paste.ubuntu.com/p/Ky4pw9G38D/
<cachio> seem to be related both fails
<cachio> zyga, do you know if it a new thing?
<zyga> cachio: it's a thing maciej was investigating lately
<zyga> he sent a PR to fix it
<cachio> zyga, nice
<cachio> I'll take a look
<cachio> thanks
<zyga> cachio: but I don't know if that's enough, I think we have some more bugs in this area
<cachio> zyga, ok, thanks for the info
<zyga> cachio: I his PR has landed, it was 7215
<cachio> zyga, in that case there is something wrong because the next Pr merged failed wiht the error I showed
<cachio> the #7186
<mup> PR #7186: gadget: ensure filesystem labels are unique <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7186>
<zyga> yeah, I think it's just buggy still
 * cachio lunch
<mup> PR snapd#7213 closed: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7213>
 * zyga takes a break
 * cachio afk
<mup> PR snapd#7221 opened: tests: split the sbuild test in 2 depending on the type of build <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7221>
<hellsworth> kenvandine
<hellsworth> ha i ctrl+f and that doesn't work in polari apparently
<mup> PR snapcraft#2653 closed: scriplets: run override-pull on update_pull <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2653>
<mup> PR snapcraft#2654 closed: click: update to 7.0 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2654>
<mup> PR snapcraft#2656 opened: appstream: xslt support for ul nested in p <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2656>
<mup> PR snapcraft#2657 opened: Release changelog for 3.7.2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2657>
#snappy 2019-08-08
<kenvandine> hey hellsworth
<hellsworth> hey sorry for the ping. it was an accident :)
<zyga> Good morning
<Aavar> Good morning :)
 * zyga resumes work
<zyga> it rains heavily today
<zyga> pstolowski|afk: https://github.com/zyga/snapd-peer-demo <- something I made at the sprint, suggestions welcome
 * zyga breaks for breakfast
<pstolowski> morning
<zyga> hey Pawel
<pstolowski> zyga: the peer demo looks nice, and serves as a useful example for practical use of interface hooks
<zyga> pstolowski: yeah, I'll write a short blog post about it
<pstolowski> zyga: btw, in that peer demo you could have interface hooks on the slot side too. i'd also consider renaming foo/bar to something more descriptive, e.g. provider/consumer
<zyga> I used to have it symmetric but I abandoned that idea
<zyga> yeah, the names are terrible :D
<zyga> in practice that will be juju and microk8s
<zyga> or the other way around
<zyga> one can then take advantage of the other
<zyga> by reusing cached images
<zyga> or some other content that is big and costly to download
<zyga> I worked on this with Ian from the Juju team
<zyga> Ian Booth
<pstolowski> zyga: i see; you could have just placeholders for the slot hooks, so that it's visibile they are there and could do something.
<pstolowski> ogra: ping
<jamesh> zyga: when you've got time, could you give https://github.com/snapcore/snapd/pull/7042 another look over? I think the main blocker was your concerns over the number of mounts
<mup> PR #7042: interfaces: add an interface granting access to AppStream metadata <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7042>
<zyga> jamesh: looking
<zyga> ah, I remember that
<zyga> jamesh: +1, let me look at spread
<zyga> jamesh: I commented in the thread with you and jamie
<jamesh> IIRC, the spread failure was unrelated to my code changes.  I didn't get round to asking someone to restart that job
<Aavar> zyga, kenvandine: Regarding my problem with graphical snaps. I did try a few things yesterday and discovered something that might or might not be related.
<zyga> oh, what did you discover?
<zyga> jamesh: restarted
<Aavar> I added a new user and that users home-directory (and everything in it) was owned by my original user.
<Aavar> zyga, after chowning the files the snaps where still not working.
<Aavar> I allso tried to stop lightdm and start from startx, but still the same.
<Aavar> zyga, I don't know if that tells you anything else than that my system if fucked :P
<zyga> I'm still totally puzzled by what may be wrong on your system
<zyga> can you do one more experiment
<zyga> add a new user that is independent from your current user
<zyga> and see if that works
<jamesh> zyga: I wrote up a proposal for another problem we've run into on the desktop team here: https://forum.snapcraft.io/t/proposal-allow-snaps-to-specify-their-exact-desktop-file-id/12689
<Aavar> zyga, that is what I did :)
<zyga> Aavar: but not owned by your user
<zyga> that's really the same exact user
<zyga> (same uid)
<zyga> nothing else matters in snapd world
<jamesh> zyga: I'm still working on session agent/user daemons/dbus activation right now, but it would be useful to get some feedback on the proposal at some point
<zyga> jamesh: ah, I think we were expecting this
<zyga> jamesh: I'll have a read but I think you need to discuss with samuele next week
<zyga> jamesh: I'm working on a fix for device cgroup and mount namespace (as always)
<zyga> jamesh: I think the proposal is sensible, we just need a way to control it properly
<jamesh> zyga: we finally found a use case where this is a blocker rather than just inconvenient :-)
<Aavar> zyga, I'm sorry. I don't thing you understood. I did create a new user named "control" (via the gui in ubuntu) and the system added /home/control but it was owned by "aavar:aavar". I have no idea why...
<Aavar> I can try to add another user via the terminal.
<zyga> oooh
<zyga> I see
<zyga> I misunderstood you
<zyga> wow that's really weird
<zyga> hmm
<Aavar> zyga, I added a new user now via terminal and that did not happen.
<Aavar> Let me log back in
<zyga> jamesh: ^ Aavar is debugging an issue where none of the graphical snaps can start
<zyga> cannot talk to x
<zyga> we are kind of lost, perhaps you have some ideas
<zyga> jamesh: what should snapd do for parallel installs in the new desktop proposal?
<jamesh> zyga: I wonder if this is abstract namespace X socket vs. /tmp/.X11-unix X socket?
<zyga> jamesh: the denial has addr=null
<zyga> Aavar: ^ am I correct? (dmesg | grep DENIED)
<zyga> at the same time DISPLAY is set correctly
<zyga> Aavar: what is your desktop shell? gnome shell?
<jamesh> zyga: parallel installs would not be supported by my proposal.  But in the notification case, the app would need to own a bus name matching the desktop file ID.
<jamesh> and that is also not parallel install friendly
<zyga> I agree
<zyga> I think we should be able to say "this snap does not support parallel installs"
<zyga> I think it's a topic for next week when the architect is back
<zyga> maciej is also away this week, attending Flock
<jamesh> Fair enough: I just want to make sure it is on the radar.  I've got other work to complete in the mean time
<zyga> ack
<Aavar> zyga: still the same result with a new user. I guess I have to wait for kenvandine :)
<zyga> Aavar: ^ are you on gnome-shell?
<Aavar> zyga: now i'm on unity, but I tried with gnome-shell (bot wayland and X11)
<zyga> hmmm
<Aavar> zyga: i'm sorry. I am not familiar with gnome. Is gnome-shell the same as gnome3?
<zyga> yeah
<zyga> I really don't know what is affecting your system
<zyga> if you were anywhere close I'd love to have a look and inspect it myself
<zyga> but I guess that is hard
<Aavar> zyga: yeah :)
<Aavar> I think, if kenvandine or someone dont find anything useful in the next few days I will reinstall.
<jamesh> Aavar: one last thing to help with debugging: could you provide a paste of the output of "ss -lxp | grep X11"
<Aavar> jamesh: brb, lunch :)
<Aavar> jamesh: p/qZ6hVy2YXF/
<Aavar> hmm..
<Aavar> jamesh: https://paste.ubuntu.com/p/qZ6hVy2YXF/
<jamesh> Aavar: okay.  That basically disproves my theory from earlier about the abstract socket not being available
<jamesh> zyga: looks like your restart cleared the test failure for https://github.com/snapcore/snapd/pull/7042.  Thanks
<mup> PR #7042: interfaces: add an interface granting access to AppStream metadata <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7042>
<jamesh> is there anything else needed before merging it?
<Aavar> jamesh, so that shows that the socket is open?
<zyga> jamesh: let me look but I think that's good now
<jamesh> Aavar: the command lists listening unix domain sockets.  The /tmp/.X11-unix/X0 socket is one you can see in the file system, while the @/tmp/.X11-unix/X0 socket is an "abstract namespace socket"
<zyga> jamesh: it's in
<jamesh> Aavar: an unconfined app can connect to either, while a snap app is blocked from connecting to the first.
<mup> PR snapd#7042 closed: interfaces: add an interface granting access to AppStream metadata <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7042>
<jamesh> zyga: thanks!
<jamesh> Aavar: if the abstract namespace socket was missing for some reason, that would explain your problems
<Aavar> btw, jamesh, zyga: When I log in via console or ssh (not x) it gives me an error: xhost:  unable to open display ""
<Aavar> Isn't that also weird?
<jamesh> Aavar: that is normal if the DISPLAY environment variable isn't set
<Aavar> jamesh: ok :)
<zyga> Aavar: yeah, that is to be expected
<zyga> brb
<zyga> Actually. A longer break is needed
 * pstolowski lunch
<jonzen> <jonzen> not sure if this is the right place but here goes   xubuntu 18.04 when i remove a snap as soon as it finishes my desktop goes black and then the login screen comes up     any1 have a solution for this
<jonzen> sorry  didnt identify
<jonzen> more info   sony laptop  i7 quad 4gb
<zyga> jonzen: hey
<jonzen> yessir
<zyga> jonzen: can you please tell us what kind of GPU are you using?
<zyga> jamesh: is your system using wayland?
<zyga> jonzen: ^
<zyga> kenvandine: ^ looks like desktop session crashes on udev trigger/settle
<jonzen> nvidia
<jonzen> how do i find out about wayland
<zyga> jonzen: open a terminal and run: echo $XDG_SESSION_TYPE
<jonzen> x11
<zyga> can you pastebin your journal log? you can do that with journalctl | pastebinit # you may need to install pastebinit first
<jonzen> ok  gimme a min  i will do
<zyga> thank you
<jonzen> http://paste.ubuntu.com/p/JVQ6dsSJyV/  your very welcome
<zyga> Aug 08 06:23:28 pd-VPCF133FX xfce4-notifyd[23765]: xfce4-notifyd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
<zyga> hmm, I'm not an expert on X stuff, can you please report a bug on snapd
<zyga> you can do that on bugs.launchpad.net/snapd
<zyga> make sure to include your system version and other relevant stuff; you may be able to report the bug with apport
<zyga> which may provide more relevant information
<zyga> I understand that it is somehow snapd that is causing this but it seems X has crashed
<jonzen> should i put this pastebin in?
<zyga> or perhaps not X
<zyga> but the session in xfce
<zyga> yes, as an attachment
<jonzen> ok  will do   ty very much for your help
 * zyga goes for a walk
<jonzen> zyga  ty again   i did as you asked
<mup> PR snapd#7200 closed: recovery: update to latest fde-utils <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7200>
<mup> PR snapd#7222 opened: tests: show just the last log as part of the debug output when check journal logs <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7222>
<mup> PR core-build#51 opened: Use /var/lib/snapd/seed/snaps/ as fallback when mounting core and kernel <Created by stolowski> <https://github.com/snapcore/core-build/pull/51>
<ogra> pstolowski, you pung ? (sorry. at a sprint this week)
<pstolowski> ogra: hey, ah i didn't realize you're at the sprint; i'min the standup atm, will you have a moment for a HO later today?
<ogra> pstolowski, hmm, we have a training, might be late for you when i have a free spot
<ogra> (and i actually have to go to class now ... perhaps drop an email with a quick summary)
<pstolowski> ogra: i'll open a forum topic, perhaps you can reply there and help, ty
<ijohnson> hey jdstrand, zyga when y'all get a chance could you re-review https://github.com/snapcore/snapd/pull/7010 ? it is pretty straight forward I think and the tests are finally all green :-)
<mup> PR #7010: interfaces/docker-support: add controls-device-cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
<jdstrand> ijohnson: hey, yes
<ijohnson> thanks jdstrand
<zyga> Iâm off for lunch now
<zyga> ijohnson: Iâll review when I am back but it feels like +1
<ijohnson> ack, thanks zyga
<ijohnson> hey cachio, I'm unable to reproduce this error in spread tests with qemu locally, any idea what might be different about the google spread machines than qemu?
<ijohnson> see https://pastebin.canonical.com/p/zsQVWhP2CP/ and https://travis-ci.org/snapcore/snapd/jobs/569057960
<ijohnson> it seems like some kind of path error where python3 thinks it should be reading from the core snap and not from the snap itself (and indeed those files it's trying to access exist in the snap and load fine on my system and in qemu 16.04)
<cachio> ijohnson, checking
<cachio> ijohnson, we use different images on qemu and gce
<cachio> let me cehck which python we have
<cachio> ijohnson, do you have a qemu instnace opened?
<ijohnson> right, but inside the snap it sholdn't matter which version of python?
<ijohnson> one second let me reboot it (I think it's off
<ijohnson> could I boot the google image with qemu locally if I downloaded it?
<cachio> ijohnson, I didn't try that
<cachio> but should be possible
<cachio> but not sure if you have the permissions to download the image
<cachio> me neither
<ijohnson> ah okay
<cachio> it is using /usr/lib/python3.6/lib-dynload/termios.cpython-36m-x86_64-linux-gnu.s
<ijohnson> still it's very odd that in one image a strictly confined snap tries to load python libs from the core snap, and that in another image it's loading python libs from the application snap
<cjp256> who would be the chrome sandbox goto expert here? :)  I've got an electron 5 app I am trying to confine strict, but it gets cranky when I remove the chrome-sandbox binary and add --no-sandbox.  It runs fine in devmode, but otherwise fails with `audit: type=1400 audit(1565112543.140:3117): apparmor="DENIED" operation="open" profile="snap.<app>.<app>" name="/proc/8998/setgroups" pid=8998 comm="<app>" requested_mask="w"
<cjp256> denied_mask="w" fsuid=1000 ouid=1000`  - i'm curious if anyone has ideas... it does look like the program bails after reading /proc/cpuinfo
<cachio> ijohnson, is it install as classic snapd o devmode?
<ijohnson> it's installed strict
<ijohnson> cachio: see https://github.com/snapcore/snapd/pull/7214/files#diff-82c7f368687a491cb7edc7d848e2b57eR16
<mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
<ijohnson> actually I should probably have you review that spread test anyways since I'm still new on the spread tests
<ijohnson> alright I requested a review from you on that PR
<ijohnson> cjp256: do you have browser-support interface connected with allow-sandbox: true
<cachio> ijohnson, please check the python version which is being used on qemu
<cachio> it is the main difference
<ijohnson> cachio: almost done preparing the image, will check in a minute
<ijohnson> cachio: it's python 3.5.2
<cachio> ijohnson, could you try updating python
<cachio> and see if this is hte problem?
<ijohnson> the version of python3 in the snap though is python 3.6.8
<ijohnson> cachio: I ran apt update && apt upgrade and still can't reproduce the problem
<ijohnson> I guess the version of python didn't change from the upgrade though
<cachio> ijohnson, lets try this
<cachio> run the test on google but in the spread.yaml
<cjp256> ijohnson: i was trying to do it without allow-sandbox, but if that's the required route, that'll have to do for now.  Mostly curious if anyone else has had problems without allow-sandbox and using --no-sandbox?
<cachio> add the image
<cachio> image: ubuntu-os-cloud/ubuntu-1604-lts
<cachio> to the ubuntu-16.04-64 system
<cachio> and run the test
<cachio> this is a pristine image
<cachio> which is more similar to qemu
<ijohnson> cachio: I have to get into a meeting right now actually, but where should I add that? to the system spec under qemu in the spread.yaml?
<cachio> ijohnson, in the spread.yaml in the google backend where you have all the systems
<cachio> you should configure https://paste.ubuntu.com/p/yw3wVnBvFR/
<ijohnson> ah and then launch the google system instead of qemu
<cachio> and run the test on google system
<ijohnson> ack, I'll let you know how it goes when I'm done with my meeting
<cachio> ijohnson, so we can see if the problem is related either to google image or to the preparation of the suite
<ijohnson> cjp256: AFAICT that access only is allowed with allow-sandbox: true unfortunately
<cjp256> alright, thanks ijohnson :)
<mup> PR snapcraft#2656 closed: appstream: xslt support for ul nested in p <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2656>
<pstolowski> i've created a forum topic re firstboot & initrd: https://forum.snapcraft.io/t/firstboot-seeding-failure-scenario-possible-fixes-and-boot-process-confusion-question/12698
<jdstrand> cjp256: you shouldn't remove the chrome-sandbox binary. just let it have 755 permissions and use --no-sandbox.
<jdstrand> iirc
<jdstrand> popey_ and Wimpress may have other tips
<diddledan> wimpy's on his holidays right now, so only popey :-)
<cjp256> jdstrand: I'll give that a shot, thanks!
 * cachio lunch
<mup> Bug #1839498 opened: xdgopenproxy: Outdated github.com/godbus/dbus dependency <Snappy:New> <https://launchpad.net/bugs/1839498>
<zyga> re
<zyga> pstolowski|afk: thank you for creating the topic
<zyga> ijohnson: looking now, sorry, took family out for dinner
<ijohnson> no worries zyga, thanks for the review
<zyga> ijohnson: I sent one comment but I need to make coffee to review this properly
<zyga> ijohnson: tomorrow I'd love to share my thoughts on the device cgroup topic
<zyga> ijohnson: we can perhaps join before or stay after the call
<ijohnson> oh actually what you commented on should be removed from the PR
<ijohnson> I missed that in my cleanup to address jdstrand's comment
<ijohnson> s
<ijohnson> but yes we can discuss more about the device cgroup tomorrow after SU
<zyga> right
<zyga> it is unconditional now
<ijohnson> so that message shouldn't have been there at all
<zyga> indeed
 * zyga checks the coffee pot
<zyga> when away from home I use this portable thing that you can just put on the stove
<ijohnson> nice
<ijohnson> I also have to step away for ~30 minutes
<ijohnson> cachio: I was able to reproduce the issue on that clean google image you provided, however I then realized that the shebang was hard-coding /usr/bin/python3, when I launch netplan with $SNAP/usr/bin/python3 then the issue goes away
<ijohnson> so I don't think it was an issue with the build env, it was an issue with my test snap rather
<ijohnson> and how that was calling python
<cachio> ijohnson, great, I am reviewing the test btw
<ijohnson> thank you
<cachio> ijohnson, mp
<cachio> ijohnson, happy to help
 * ijohnson lunches
<mup> PR snapcraft#2657 closed: Release changelog for 3.7.2 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2657>
<mup> PR core-build#50 closed: initramfs: run recover mode if trigger is detected <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/core-build/pull/50>
<zyga> re
<mup> PR snapd#7223 opened: recovery: update fde-utils <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7223>
 * cachio afk
<mup> PR snapd#7221 closed: tests: split the sbuild test in 2 depending on the type of build <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7221>
<cjp256> I'm having a little trouble with multipass on Windows - anyone have any pointers? couldn't find much useful in the event logs... :) https://www.irccloud.com/pastebin/qHKIdUdC/
<cjp256> probably more appropriate for #multipass I imagine
<ijohnson> cachio: thanks for the review on the PR, I addressed your points, can you re-review when you get a chance?
#snappy 2019-08-09
<zyga> o/
<mup> PR snapd#7224 opened: xdgopenproxy: update test API to match upstream <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7224>
<Aavar> Good morning
<zyga> o/
<pstolowski> morning
<zyga> hey pawel
<zyga> I'm looking at https://github.com/snapcore/snapd/pull/7222/files
<zyga> I have some doubts about that code, digging now
<mup> PR #7222: tests: show just the last log as part of the debug output when check journal logs <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7222>
<pstolowski> zyga: good, ty, i was confused about it
<pstolowski> zyga: Sergio said it's "log=$(get_journalctl_log "$@")", is this because of -x flag when we run scripts?
<zyga> if that's -x then the commit message and explanation are confusing
<zyga> I thought he meant the actual log being printed over and over
<zyga> network is super slow
<zyga> pstolowski: do you think this will pass? https://www.irccloud.com/pastebin/kg4wlBTJ/
<pstolowski> zyga: hmm, no retry-loop? i'm skeptical, although i've never paid attention to the logs of passed tests where we actually retried, perhaps not needed anymore? worth trying out
<zyga> I think the whole retry loop is a sign of broken stuff elsewhere
<zyga> eh
<zyga> everything fails
<zyga> this is so depressing
<zyga> how can we change anything where everything is always broken
<pstolowski> zyga: maybe the retry loop was added in the early days of journal log checks and before we understood it better and flush/sync were added
<zyga> yeah
<zyga> pstolowski: 215/350 passed
<zyga> without the loop
<mup> PR snapd#7225 opened: tests: don't repeat checks <Created by zyga> <https://github.com/snapcore/snapd/pull/7225>
<zyga> pstolowski: I opened https://github.com/snapcore/snapd/pull/7225 -- it passed on xenial locally, let's see what happens across a broader set of distributions
<mup> PR #7225: tests: don't repeat checks <Created by zyga> <https://github.com/snapcore/snapd/pull/7225>
<pstolowski> zyga: we should also re-run it multiple times if it passes
<zyga> I think it will fail
<zyga> but not on this
<pstolowski> uhm
<zyga> hmm, some drunk folks with chainsaws are going to cut a tree next to our house
<zyga> "official woodcutters"
<zyga> how I hate our countryside attitude
<zyga> before getting to work, get f*** drunk
<zyga> complain to anyone and you'll have hell
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7219#pullrequestreview-273016244
<mup> PR #7219: devicestate/firstboot: check for missing bases early <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7219>
<pstolowski> zyga: ty
<pstolowski> zyga: anything you want me to review?
<zyga> pstolowski: nothing, sorry; I need to re-think my approach
<zyga> mount stuff is stuck in recursive issues
<zyga> cgroup stuff is new and too early
<zyga> I would love help with making tests more robust
<zyga> that helps everyone
<pstolowski> yeah, i'm contemplating where to start with this
<zyga> pstolowski: I have a simple suggestion
<zyga> pstolowski: read main top to bottom
<zyga> garden cruft
<zyga> some is so obvious it pains to read
<zyga> one branch per cruft
<zyga> at a deeper level we neet better tooling
<zyga> *need
<zyga> but even with better tooling, we really need better test quality
<zyga> and we need to maintain existing tests
<zyga> they are commencing to cut the tree next to our house
<zyga> I'll go and pay attention now
<zyga> pstolowski: one more advice, it's good to review everything to bottom
<zyga> it helps our colleagues to progress
<zyga> even if you don't feel comfortable with something, just say so in the review
<pstolowski> sure, +1
<pstolowski> zyga: good luck with those trees..
<pstolowski> only test that failed in one of the PRs:
<pstolowski> prepare of google:ubuntu-16.04-64:tests/main/
<pstolowski> Fetching snap "ubuntu-core"
<pstolowski> error: stream error: stream ID 1; PROTOCOL_ERROR
<zyga> yeah
<zyga> it's great to have all the moving parts
<zyga> something always fails
<zyga> eh :/
<zyga> trees keep falling
<pstolowski> zyga: trees as master tree or tress as physical trees ? :}
<pstolowski> zyga: i though that already landed https://github.com/snapcore/snapd/pull/7202 ; should we try to land this asap?
<mup> PR #7202: tests: sync journal log before start the test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7202>
<zyga> pstolowski: physical trees :)
<pstolowski> ah, falling, not failing. right ;)
<zyga> restarted :/
<mup> PR snapd#7226 opened: tests: mountinfo-tool fail if there are no matches <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7226>
<pstolowski> +1 with suggestion ^
<pstolowski> zyga: how far is https://github.com/snapcore/snapd/pull/7168 from being landable?
<mup> PR #7168: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
<zyga> pstolowski: far, blocked by spread bug
<zyga> Though we may try to scope it to fewer systems
<zyga> We may also disable tests, such as lxd, where the bugs matter
<zyga> One of the two trees is down
<zyga> Looking at the more risky one
<zyga> It leans heavily towards another house
<zyga> Second tree down
<zyga> It was about 180 years old
<zyga> Iâll get back to work soon
<pstolowski> zyga: sounds sad :(
<zyga> drama over
<pstolowski> zyga: just got protocol error on recently restarted PR; this is ~4th occurence of protocol error that i see today
<zyga> ok, back to work
<zyga> pstolowski: I saw two more
 * pstolowski lunch
<zyga> everything ultimately fails on protocol error this week
<pstolowski> :(
<pstolowski> and we are no closer to fixing this, which is super annoying
<zyga> pstolowski: it seems there's an outage
<zyga> pstolowski: I'm just doing reviews now
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7225
<zyga> ha
<zyga> this passed
<zyga> ;D
<mup> PR #7225: tests: don't repeat checks <Created by zyga> <https://github.com/snapcore/snapd/pull/7225>
<pstolowski> zyga: nice.. i'd land it once situation is under control and stable though
<zyga> yeah, no rush on that one
<zyga> but it reaffirms my feeling that that loop was papering over something else being bogus
<zyga> either I have more network woes or github is slow
<zyga> https://status.snapcraft.io/ indicates outage
<zyga> please refrain from restarting anything
<tomwardill> ah, zyga beat me to it. Store is having issues atm, we're starting to shed some search load to try and get out of it.
<tomwardill> so expect intermittent service at best I'm afraid
<DreyMIX> hello! api.snapcraft.io is down?
<popey_> yes, see status.snapcraft.io for details
<DreyMIX> ok thx, I was updating ubuntu to version 19. What do I do now?
<popey_> DreyMIX: you're mid way through an Ubuntu desktop upgrade?
<DreyMIX> Yes, I launched the terminal update via the "do-release-upgrade" command
<tomwardill> problem identified, should start seeing store improvement soonish
<popey_> DreyMIX: what state is it in right now? is there an error message or something? (maybe paste it to paste.ubuntu.com) ?
<DreyMIX> popey_Unfortunately I had a previous error in the sendmail package during the installation, so I had to finish the process. Now I have uninstalled sendmail. How can I restore the update?
<popey_> DreyMIX: so has the upgrade crashed out?
<DreyMIX> yes
<popey_> Ok, can you look in /etc/apt/sources.list and see if it's retained the new release codename of 'disco' (for 19.04)
<popey_> (sometimes the upgrade rolls back, but I suspect it hasn't here)
<DreyMIX> ok i check
<DreyMIX> https://paste.ubuntu.com/p/wNrvNBRRC7/
<DreyMIX> However if I try to re-run the "do-release-upgrade" command it tells me that there is no new release.
<popey_> hang on
<popey_> ok, good, it's partially upgraded.
<popey_> try this: sudo dpkg --configure -a
<popey_> if it just immediately finishes, chances are your upgrade is done.
<popey_> it's more likely however to being processing a bunch of packages as the upgrade isn't finished
<DreyMIX> ok done.  He gave me no output
<popey_> ok, good
<popey_> what desktop did you use before the upgrade, GNOME? KDE?
<DreyMIX> gnome
<popey_> ok, there's an extra command I'd run just to make sure...
<DreyMIX> ubuntu 18.10
<popey_> sudo apt install ubuntu-desktop^
<popey_> note the ^ on the end
<DreyMIX> ok
<popey_> this *may* install some extra packages (which may have been missing) or it might do nothing but spit a lot of text out
<DreyMIX> 0 updated, 0 installed, 0 to remove and 0 not updated.
<DreyMIX> Would everything seem ok?
<tomwardill> store is operating normally, let us know if you see anything weird (er than normal)
<zyga> cachio: so, two things I was trying to say over HO
<zyga> cachio: 1) try the http 2.0 off switch idea
<zyga> cachio: 2) try checking the error tracker for a spike in errors from snapd, snapd reports failed installs, we can see when this started perhaps
<zyga> pstolowski, ijohnson, degville, cachio: I cannot join the video call in any meaningful way now
<zyga> have a productive afternoon and then a great weekend and let's come back to fight this next week
<zyga> roadmr: ^ not sure if you can see the error tracker data
<zyga> but it's a data point for us
<degville> zyga: thanks for letting us know - you too.
<roadmr> zyga: I can give the error tracker a try, where does it live?
<zyga> roadmr: all I know is the user side: https://errors.ubuntu.com/
<roadmr> zyga: oh that tracker! sure, I'll have a look. Thanks!
<cachio> zyga, so, to disable http2 should be enough with GODEBUG=http2client=0
<cachio> zyga, where I need to add that
<cachio> to the systemd local config for snapd?
<zyga> cachio: yeah, I think so
<zyga> in the override file
<zyga> we set SNAPD_DEBUG in the same way AFAIR
<cachio> zyga, nice, I'll try it
<zyga> thank you!
<zyga> :)
 * zyga goes to the roof to tweak the antenna some more
<mup> PR snapd#7227 opened: tests: Enable verbose http2 <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7227>
<mup> PR core18#136 opened: Remove the 60-unminimize motd, identify system as Ubuntu Core 18 <Created by sil2100> <https://github.com/snapcore/core18/pull/136>
<ijohnson> hmm so I am hacking on snapd same as I used to, but now it seems there is an API mismatch between the "snap" command and the "snapd" daemon
<ijohnson> $ snap install docker
<ijohnson> error: cannot install "": cannot install snap with empty name
<mup> PR snapd#7228 opened: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
<ijohnson> even if I disable re-exec for the "snap" command with SNAP_REEXEC, I still can't get it to work: https://pastebin.canonical.com/p/Pv3h4gWFKx/
 * cachio lunch
<pstolowski> ijohnson: interesting, i had the same a few weeks ago.. tl;dr i've removed and refreshed all the vendor stuff in my tree, not sure what really changed.. try that maybe
<pstolowski> ijohnson: what i noticed practically every command that required snap argument stopped working when this happened
<ijohnson> right that's exactly what I'm seeing now
<pstolowski> ijohnson: right.. remove all vendor packages and get deps againb
<ijohnson> yeah okay that did it updating the vendor directory
<ijohnson> thanks pstolowski!
<pstolowski> ijohnson: cool!
<pstolowski> ijohnson: i'm now wondering if it's not a real issue
<ijohnson> something with gorilla/context? that was the dep that got removed for me
<pstolowski> ijohnson: commit be4fc4d117c255cadd697a93f9f94e49c708f2c3
<ijohnson> interesting
<ijohnson> this is a situation where it would be nice if we were able to use go modules and not have govendor and go itself be out of sync with respect to the dependencies :-(
<pstolowski> ijohnson: i don't get why didn't it break the build for me
<ijohnson> yeah that's the most troubling part of this all is why the build works but is subtly broken
<pstolowski> ijohnson: and until you hit it now i was suspecting some kind of messup on my VM
<ijohnson> yeah I think I'll investigate this a bit, but this got me thinking it would be nice to have logging of the HTTP request/responses from the "snap" binary and snapd
<ijohnson> we log HTTP stuff with SNAPD_HTTP_DEBUG to the store from snapd, but nothing on the "snap" client and only the response code/time/etc. on the snapd side with SNAPD_DEBUG
<mup> PR snapd#5644 closed: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<ogra> stgraber, i'm trying to run debootstrap inside an lxc container (on top of ubuntu-core but that shouldnt matter) .... does that only work in privileged containers ?
<ogra> root@bionic:~/cubox-classic# debootstrap bionic foobar
<ogra> mknod: /root/cubox-classic/foobar/test-dev-null: Operation not permitted
<ogra> E: Cannot install into target '/root/cubox-classic/foobar' mounted with noexec or nodev
<ogra> (is there any doc for this ?)
<stgraber> ogra: yes, only privileged containers can mknod stuff. It's in theory possible with LXD edge + 5.0 kernel to get our syscall interception to make this work for unpriv containers but it's still pretty untested for this scenario
<ogra> thanks btw ... :)
 * zyga crashed again, 
<zyga> I need a day of sleep
<mup> PR snapcraft#2514 closed: test: autopkgtest beta <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2514>
<mup> PR snapcraft#2658 opened: candidate testing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2658>
<ijohnson> hey cachio, I've seen google:debian-sid-64:tests/main/sbuild:{any,normal} both fail repeatedly in spread, do you think that's related to the protocol errors we've been seeing?
<ijohnson> I remember seeing a PR from you split up that test into 2 different ones
<cachio> ijohnson, hey, I was researching this today
<cachio> the command is getting stuck
<ijohnson> I don't know enough about the debian build task to know what's going on, but yeah I see
<ijohnson> E: Build failure (dpkg-buildpackage died)
<ijohnson> as the reason for it dying
<cachio> so far I could not reproduce it and the lgos dont provide usefull information
<ijohnson> yeah I don't see much useful info other than just that
<ijohnson> hmm
<cachio> ijohnson, the problem is that it is not showing any output
<ijohnson> ah is it supposed to show more output?
<cachio> I ran that manually and all the sbuild output is printed on the screen
<cachio> ijohnson, I just started a job with -show-output to see the output of the test
<ijohnson> Ah okay, nice
<ijohnson> I just was gonna see if you knew what was up with that test, but it seems you're on top of things
<ijohnson> thanks
<cachio> ijohnson, perhaps it is consuming to much cpu
<cachio> trying to be :)
<cachio> but now working arout the protocol error
<ijohnson> :-) yeah it would be good to figure out what we can do about the protocol error
 * juliank tried and failed to use the code snap and the go snap together to build go apps in visual studio code
<juliank> When /snap/bin/code invokes /snap/bin/go nothing happens
<juliank> I'd have hoped this would work, given both are classic snaps
<ijohnson> juliank: what do you mean nothing happens, can you open the terminal in vscode and use the go command there?
<ijohnson> I've used the go snap inside vscode as a snap and it did work, although I do know of one issue with vscode and other snaps specifically
<ijohnson> the bug I know about is https://bugs.launchpad.net/snapd/+bug/1835805
<mup> Bug #1835805: strict snap run from classic snap can't write to filesystem <snapd:New> <https://launchpad.net/bugs/1835805>
<juliank> ijohnson: it works from the terminal
<juliank> ijohnson: if run on save by code, nothing happens
<ijohnson> hmm, do you mean one of the go extensions doesn't work?
<juliank> If I snap remove go, apt install golang it works fine
<ijohnson> do you see any denials in the system journal with `journalctl -e --no-pager | grep DENIED` ?
<juliank> let me reinstall the snap and check
<juliank> As I see quite a few snap-confine file_inherit denials
<ijohnson> the journal should still be around even if you removed the snap
<ijohnson> interesting
<ijohnson> that's the same kind of denial I saw in my bug report
<juliank> AVC apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" pid=31372 comm="snap-confine" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none
<ijohnson> could you comment on the bug report I linked to above with your log and reproducing instructions?
<juliank> huh it works from snap run --shell
<juliank> Let's start with a fresh code
 * cachio afk
<mup> PR core-build#52 opened: initramfs: get snap parameters from grubenv <Created by cmatsuoka> <https://github.com/snapcore/core-build/pull/52>
#snappy 2019-08-10
<mup> PR snapd#7229 opened: Errata commit: pulseaudio still auto-connects on classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7229>
<mup> Bug #1839709 opened: does not work under cgroup v2 <Snappy:New> <https://launchpad.net/bugs/1839709>
#snappy 2020-08-03
<mborzecki> morning
<jamesh> hi mborzecki
<mborzecki> jamesh: hey
<mborzecki> pff asrock efi bios decided to randomly drop all my settings :/
<mborzecki> mvo: hey, welcome back
<mvo> hey mborzecki ! good morning
<pstolowski> heyas!
<mborzecki> pstolowski: hey, welcome back
<pstolowski> o/
<pedronis> morning
<mvo> pstolowski: hey, welcome back
<mvo> pedronis: hello, nice to "see" you!
<pstolowski> mvo: and likewise :)
<pedronis> mvo: pstolowski: welcome back
<pstolowski> how are things? thanks everyone for pushing my PRs forward!
 * pstolowski finished reading standup notes for last 2 weeks
<pstolowski> pedronis: you mentioned a change in preseed priorities for cpc (issue with snap-daemon vs system-key divergence) the other day?
<zyga> mvo, hello, are you available for the 1:1 today?
<mvo> zyga: yes, sry
<pstolowski> hey zyga! how are you?
<pedronis> pstolowski: yes, in general they were more worried about blockers bug than key divergence
<pedronis> pstolowski: we still want to fix a couple of key divergence related things though
<pstolowski> pedronis: i'm skimming over preseed chat but it's hard to get the bug picture; can we sync about that today?
<pstolowski> s/bug/big
<pedronis> pstolowski: they have workardounds for the bugs, we have a fix in snapd as well but it's waiting on security to review
<pedronis> pstolowski: we can sync with Ian in the afternoon I suppose
<pedronis> pstolowski: your oldest 3 PRs still open have some comments
<pedronis> one is about splitting
<pstolowski> pedronis: yes i remember, will update them today
<pedronis> thx
<pstolowski> pedronis: sounds good about sync with Ian
<pstolowski> pedronis: also, AFAIU the work about snap debug preseeding has been concluded with Ian's PR?
<pedronis> pstolowski: yes, it's on edge afaik
<pstolowski> ok, great
<zyga> pstolowski hey
<zyga> pstolowski tired :)
<zyga> we had a 1:1 with mvo and I'm just tired from standing
<zyga> but I'm feeling much better
<zyga> I need to go to the hospital again now so I'll see you guys later
<zyga> two more visits before I can remove that thing
 * zyga waves and goes away
<pstolowski> zyga: good luck, happy to hear you're better!
<pedronis> mvo: is this fix released https://bugs.launchpad.net/snapd/+bug/1866424 you mentioned pushing a fix but never changed the state of ti
<mup> Bug #1866424: refresh fails when gpio is not exported <mvo> <snapd:Triaged> <https://launchpad.net/bugs/1866424>
<mvo> pedronis: thanks, looking and will update accordingly
<pedronis> mvo: also this recent changes affect/fix this https://bugs.launchpad.net/snappy/+bug/1650688 (it seems to be open since forever) ?
<mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Triaged> <https://launchpad.net/bugs/1650688>
<mup> PR snapd#9002 closed: o/snapstate: integrate free space checks with install/refresh and remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9002>
<mvo> pedronis: checking that now too
<mup> PR snapd#9084 opened: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<pedronis> mvo: this was decided right,  https://bugs.launchpad.net/snapd/+bug/1883955 ? should I assign it to you?
<mup> Bug #1883955: where should ubuntu-core-initramfs pull snap-bootstrap from <snapd:Triaged by pedronis> <ubuntu-core-initramfs:New> <https://launchpad.net/bugs/1883955>
<mup> Bug #1887760 changed: Installing snap app is not updating required content snap <snapd> <Snappy:Won't Fix by pedronis> <https://launchpad.net/bugs/1887760>
<mvo> pedronis: I think so, I need to look at my notes/try-to-remember the details
<mvo> pedronis: there was a bit of back-and-forth
<pedronis> mvo: ok
<pedronis> mvo: I moved it to you
<mvo> pedronis: 1650688 timezonectl on uc16 is still an issue, I bet because there is a race with writable-path mounting things and when systemd looks for /etc/localtime
<pedronis> fun
<mvo> pedronis: yeah, pretty terrible
<pedronis> mvo: isn't writeable-path run form the initrd?
<mvo> pedronis: it's writing the mount units there but the actual mount happens later - it's actually worse, because etc/system/ is written in initrd already to avoid excatly a race like this. fwiw, the bug also happens on uc18 and (not tested yet) uc20
<mvo> pedronis: hm, actually it bind mounts all /etc in initrd so the fact that timedatectl is wrong is puzzling
<mborzecki> quick errand, back in 30
<mup> PR snapd#9085 opened: daemon,many: switch to use client.ErrorKind and drop the local errorKind <Created by pedronis> <https://github.com/snapcore/snapd/pull/9085>
<mvo> pedronis: \o/
<mborzecki> re
<mup> PR snapd#9086 opened: many: reorg cmd/snapinfo.go into snap and new client/clientutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9086>
<mup> PR snapd#9087 opened: o/snapstate: check available disk space before downloading a snap on install (4/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9087>
<MikeRL> Anyone else notice the Thunderbird snap for some reason uses an old icon? Otherwise things are fine. At least on the edge channel. Looks antiquated. Can I manually replace it?
<ijohnson> pstolowski: would you mind if we synced up tomorrow morning re: ubuntu-bartender to reproduce the issue with xenial mounting and things ?
<pstolowski> ijohnson: yes, perfect, i'll look at version check first, thanks
<ijohnson> sounds good I'll send a meeting invite then
<cachio> cmatsuoka, hey
<cachio> cmatsuoka, , https://github.com/snapcore/snapd/pull/9027/checks?check_run_id=931938026#step:5:6853
<mup> PR #9027: tests: refresh/revert snapd in uc20 <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9027>
<cachio> cmatsuoka, this is interesting
<cmatsuoka> cachio: will check as soon as this meeting finishes
<cachio> cmatsuoka, sure
<jdstrand> zyga: hey, I don't recall if I mentioned this to you directly: https://forum.snapcraft.io/t/alternate-home-workaround-request/18679/11
<mvo> cachio: please beta-validate the current core update in beta, it's the update from xnox for the grub security fix
<cachio> mvo, sure
<mvo> thank you cachio
<cachio> mvo, np
<cmatsuoka> cachio: Hm, this is the same error you found last week I think
<cmatsuoka> cachio: and again we had multiple boots there
<cachio> cmatsuoka, yes
<ijohnson> cmatsuoka: cachio: seems that my fix to use `ts` works, but then we have the issue that since I had the serial console go to stdout for a systemd service, we lose a lot of messages early on for some reason, I think we need to configure journald to keep more logs around or something, see https://github.com/snapcore/snapd/runs/940727015?check_suite_focus=true#step:5:958
<cachio> ijohnson, interensting
<ijohnson> yeah so if I can fix that journald issue to keep all the logs it would show the hang like cmatsuoka found in the logs directly
<mup> PR snapd#9027 closed: tests: refresh/revert snapd in uc20 <Run nested> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9027>
 * cachio lunch
#snappy 2020-08-04
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> good morning mborzecki
<mborzecki> mvo: i've pushed an update to arch, and working on updates for fedora
<mvo> mborzecki: nice, thank you
<pstolowski> morning
<mborzecki> pstolowski: hey
<jamesh> mvo: it looks like the edge channel for the core snap hasn't published for a while, and doesn't seem to reflect master.  Is that a known problem?
<mvo> jamesh: we need jdstrand to unblock publication, the review tools flaged edge incorrectly
<mvo> jamesh: or some other store reviewer for that matter
<mup> PR snapd#8917 closed: osutil/disks: add mock disk and tests for happy path of mock disks <Squash-merge> <UC20> <â Blocked> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8917>
<zyga> good morning
<zyga> mvo I'm filing the paperwork now
<mup> PR snapd#9088 opened: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9088>
<zyga> pedronis thank you! :)
<pedronis> mvo: I approved that core revision
<mvo> pedronis: thank you
<mvo> pedronis: there might be more to approve https://dashboard.snapcraft.io/snaps/core/revisions/9810/
<pedronis> there's a lot of them
<pedronis> let' see
<mvo> pedronis: yeah, I think you will have to approve 5 or so and then it should have recovered (one approval for each arch)
<pedronis> mvo: I think now I approved all archs once, let's see
<mvo> pedronis: thank you! fwiw, I'm working on 8982 right now, it needs some tweaks for not leaking FDs in the error case now that the export is split
<ijohnson> morning folks
<mvo> good morning ijohnson
<ijohnson> hey mvo
<ijohnson> mvo: thanks for merging 8917, but I don't suppose you saw the squash merge label for that PR ?
<ijohnson> it's not a big deal, just a little messy now IMHO
<pedronis> mvo: the subsequent revisions are getting green on their own now
 * pedronis lunch
<mvo> ijohnson: oh no, sorry for that
<mvo> pedronis: great, thank you
<ijohnson> mvo: no worries, just my OCD wanting to have a clean git history without all my silly "merge feature X into feature Y" and "merge master into feature Y" commits
<pstolowski> hey ijohnson !
<ijohnson> hey pstolowski
<ijohnson> did you try out the ubuntu-bartender thing at all? no worries if you didn't, happy to show you how I debugged things with that in a little bit
<pstolowski> ijohnson: no, not yet, since you mentioned you needed manual hacks i assumed it makes sense to wait for you
<ijohnson> pstolowski: sure, do you wanna join the SU HO in 45 minutes ?
<pstolowski> ijohnson: yes, sure
<ijohnson> sounds good
<jamesh> The access check attributes on snapFileCmd ("/v2/snaps/{name}/file") don't really make sense.  From what I can see, the polkit action it specifies will never be used
<pstolowski> ijohnson: i've a small interruption here, may need 15 or so, can i ping you when ready for HO?
<ijohnson> sure no worries
<zyga> o/
<ijohnson> hey zyga how are you feeling ?
<zyga> I'm in the office, training my legs to stand and ... just do that
<zyga> much better, stronger by the day
<ijohnson> nice that's really great to hear
<zyga> still pathetically weak but making progress :)
<zyga> starting Wednesday I should be able to sit for more than half an hour, or so the doctors tell me
<zyga> how have you guys been?
<ijohnson> things are going well I think, not too many fires
<zyga> that's great
<zyga> how are tests?
<zyga> is everything working okay?
<zyga> I rebooted our instance after boot loader patches went out
<ijohnson> not too bad actually, not that much "actions missing in action" kinda thing
<ijohnson> still some red from uc20 prepare and store 408s randomly
<ijohnson> but the tests seem to be syncing up properly which is good
<zyga> ok
<zyga> that's great to hear
<zyga> my goal for today is to sent some docs to mvo
<zyga> (done)
<zyga> and to exercise (in progress)
<ijohnson> nice
<zyga> and to see a bit more about my branches (bonus)
<zyga> I'll try to address the feedback you gave me
<zyga> I'm off until Thursday
<zyga> but I'll try to help a little
<pstolowski> hey zyga, glad to hear your condition is improving
<zyga> yeah, :-)
<zyga> my daughter told me that I move like my father (who is old and moves slowly :)
<pstolowski> ouch
 * zyga break 
<zyga> tired o/
<pstolowski> ijohnson: sorry, it took a bit longer; can we talk now?
<ijohnson> pstolowski: sure, give me 5 minutes I want to start flashing my SD card, it takes a bit to finish
<pstolowski> ijohnson: sure
<ijohnson> pstolowski: ok ready joining the HO now
<pstolowski> ijohnson: ok
<mborzecki> pedronis: 13 files changed, 315 insertions(+), 51 deletions(-) just the writer & bits in gadget/install, devicestate install and stubs in boot
<mborzecki> pedronis: not great, but not horrible either
<mborzecki> the tests inflate the diff a bit
<pedronis> mborzecki: sounds ok
 * pstolowski lunch
<mup> PR snapd#9089 opened: many: introduce content write observer, install mode glue, intial seal stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9089>
<mborzeck1> pff chrome died at the end of standup
<mup> PR core20#79 closed: Add secureboot-db package, try #2 <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/79>
<jdstrand> mvo: I'm looking and it looks like Samuele approved core so you are set. you said it was flagged incorrectly, but it dropped a file. I think the review-tools dtrt?
<mvo> jdstrand: yeah, all good, thanks!
<mvo> jdstrand: (in a meeting, will get back to you)
<jdstrand> mvo: no worries, just wanted to make sure everything was ok. thanks!
<mvo> jdstrand: yeah, I think the issue was that edge go a (much older) core and then we got the new version. this lead to the review-tools flagging I think
<jdstrand> mvo: yes, that can definitely happen as the review-tools (and the store at the point that the tools are run) have no concept of 'edge' or 'stable'
<jdstrand> mvo: we now have a role rotation for store manual reviews, so we should in theory be more proactive, but you can always reach out :)
<mborzeck1> hmm 2020-08-04T13:37:42.0599670Z 	Failed for "gopkg.in/yaml.v2" (failed to clone repo): exit status 128
<mborzeck1> 2020-08-04T13:28:36.1975163Z fatal: unable to access 'https://github.com/snapcore/go-gettext/': transfer closed with outstanding read data remaining
<mborzeck1> is github going down again?
<pedronis> pstolowski: I added a question to #9087, we can chat tomorrow if it needs discussion
<mup> PR #9087: o/snapstate: check available disk space before downloading a snap on install (4/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9087>
<pstolowski> pedronis: ok
<pstolowski> pedronis: hmm i didn't think of multi snap install, i think you're right
<pedronis> pstolowski: well also refreshes, this code is used by refreshes too
<pedronis> there's some questions there as well
<pedronis> pstolowski: we we should have a chat
<pedronis> tomorrow or when it makes sense for you
<pedronis> pstolowski: I mean, if you are busy with other things, this can probably wait a bit
<mup> Issue core20#80 opened: networking does not persist in a reboot loop on arm64 pi4 <Created by anonymouse64> <https://github.com/snapcore/core20/issues/80>
<pstolowski> pedronis: sure, let's see how it foes with xenial+squashfs problem on preseeding
<pedronis> pstolowski: about seeeding error, one option could also be to look at in Error changes, when we do the in flight check in ensureSeeded
<pedronis> but is not optimal
<pstolowski> pedronis: indeed, that would work. but yes
<pedronis> pstolowski: though maybe it's just enough to go over the changes in the api code
<pstolowski> pedronis: we exit on task errors when preseeding. snap-preseed could inspect state by itself if exit status != 0
<pstolowski> pedronis: it was commit 24d77f474dc53846a16289d19721292d16832cd8
<pedronis> pstolowski: this is not about preseed, it's about finishing the seeding
<pstolowski> pedronis: ah you're right
<pedronis> yea, I think the option I prefer is just going over the changes in getSeedingInfo if seeded is false
<pedronis> it's very self contained and less risky
<pstolowski> pedronis: yes that's ok
<ijohnson> pedronis: given the email from CPC, should we adjust `snap debug seeding` output to be more "yaml", I see for example right now if we can't calculate a time and output "-", that makes it invalid yaml
 * cachio lunch
<ijohnson> pedronis: because otherwise it's all valid yaml
<ijohnson> but maybe there are other edge cases I don't see that are not valid yaml
<mup> PR snapd#8998 closed: tests/cmd/snap-bootstrap/initramfs-mounts: add test case for empty recovery_mode <Simple ð> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8998>
<pedronis> ijohnson: sorry, I forgot, we have special support in the unicodeMixin to emit things that are valid yaml for out patterns
<ijohnson> mmmm, so the current code is buggy then
<pedronis> ijohnson: look at .dash in cmd_info.go for example
<ijohnson> ah so if we use "â" instead of "-" then yaml is happy
<ijohnson> yeah I see it now
<pedronis> well, it's a bit more complicated than that, but yes, there are helpers to pick things
<ijohnson> pedronis: ok, given this is it okay if I respond to CPC's email with instructions on how to use snap debug seeding with the caveat that we found a bug just now where it's not always valid yaml ?
<pedronis> well, we need to add error too
<ijohnson> sure, but that won't change the formatting will it?
<ijohnson> I was assuming if seeding error'd then we would just exit with non-zero exit code and add something else to the yaml output
<pedronis> yes, but I would prefer to send one email with all the bits
<pedronis> instead of many
<ijohnson> ok, that's fine
<ijohnson> I can file a PR to fix the unicode yaml issue then
<pedronis> basically I we should first get closer to what we want in .4
<pedronis> and then mail them
<ijohnson> yes makes sense I will not email them
<mup> PR snapd#9090 opened: cmd/snap/debug/seeding: use unicode for proper yaml <Preseeding ð> <Simple ð> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9090>
<ijohnson> pedronis: pstolowski: I opened ^ which fixes the yaml issue for snap debug seeding
<pedronis> ijohnson: thx, pstolowski:  I'm looking into adding seed-error
<ijohnson> nice
<pstolowski> pedronis, ijohnson thanks!
<mup> PR snapcraft#3238 opened: db: introduce generalized datastore <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3238>
<ijohnson> jdstrand: regarding https://bugs.launchpad.net/snapd/+bug/1889695, do you anticipate you will have a fix ready in the next few days ? we would like to include that in the next point release of snapd 2.45.4
<mup> Bug #1889695: [k8s-support] permission denied error when calling readlink on /proc/1/ns/pid <snapd:New> <https://launchpad.net/bugs/1889695>
<jdstrand> ijohnson: I could fix that, but they need the other things I'm doing for microk8s. I won't have that done for 2.45.4 and was planning 2.46. if it goes fast, *maybe*, but I doubt it will go fast
<pedronis> ijohnson: I have code, I will post a PR after dinner
<ijohnson> jdstrand mmm I see, so the issue is that I assume a new version of various $CONTAINER_TECHNOLOGIES is what is causing the problems?
<ijohnson> jdstrand also I don't know how critical the k8s thing is for field, I would recommend asking Tony about the priority of that
<pedronis> ijohnson: I proposed #9091
<mup> PR #9091: cmd/snap: display the error in snap debug seeding if seeding is in error <Created by pedronis> <https://github.com/snapcore/snapd/pull/9091>
<ijohnson> pedronis ack I will take a look
<mup> PR snapd#9091 opened: cmd/snap: display the error in snap debug seeding if seeding is in error <Created by pedronis> <https://github.com/snapcore/snapd/pull/9091>
<cachio> ijohnson, hey
<cachio> I see the cgroup test failing in debia
<cachio> https://paste.ubuntu.com/p/9rk24R2265/
<cachio> I tried and it is easy to reproduce
<cachio> do you know something about that? what could be the route cause?
<ijohnson> Let me look
<ijohnson> cachio: no I don't know what that issue is
<cachio> it is failing in debian sid
<cachio> not sure if it is because an update on a dependency
<jdstrand> ijohnson: well there are a number of things. new workloads aren't working right and I need to investigate the best fix for that, then there are various access issues, and then there is the different behavior depending on the kernel version
<ijohnson> jdstrand ack makes sense
<zyga> I've released 2.45.3.1 to openSUSE
 * zyga gets out of office
<ijohnson> cachio: yeah I kinda suspect an upstream change in Debian here
<cachio> ijohnson, yes, I don't see any change in our side which could be affecting that
 * cachio afk
#snappy 2020-08-05
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> mvo: an interesting bug https://bugs.launchpad.net/snapd/+bug/1890046
<mup> Bug #1890046: Handle SOURCE_DATE_EPOCH for SquashFS <Snapcraft:Triaged> <snapd:Triaged> <https://launchpad.net/bugs/1890046>
<mvo> mborzecki: uh, looking
<mvo> mborzecki: hm, doing this for the snapd snap should be easy, core is a bit harder. i wonder if we should just sru squashfs-tools
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<mborzecki> mvo: there's probably some concerns about the review-tools/store side of things?
<mvo> mborzecki: yeah, probably something to talk to jamie about
<mvo> mborzecki: hm, the bug report talks about reproducible builds, this is exactly what we want too I guess
<mborzecki> mvo: right, common goals may make sru'ing squashfs-tools a bit easier ;)
<mvo> :)
<mborzecki> need to go and drop some paperwokr at my accountant
<mborzecki> re
<pedronis> mvo: pstolowski: hi, have we prepared backports for snap debug seeding stuff ?
<pstolowski> pedronis: afaiu mvo was going to look at the commits yesterday so i haven't do anything about that. i'm happy to take this over if not started yet
<pedronis> pstolowski: it seems like we need to add preseed code to all interfaces backends no?
<mvo> pstolowski: I have not started yet, if you have capacity for this, that would be great
<pstolowski> pedronis: nb, we may have an issue with udev though, see mattermost chat
<pstolowski> pedronis: yep, udev backend
<pedronis> pstolowski: yes, that's why my comment about interfaces backends
<pedronis> pstolowski: well, we need to look at all backends and see which one can trigger external programs/services
<pstolowski> pedronis: yes
<pedronis> and see which one don't work in a chroot
<pedronis> and see what to do
<pstolowski> mvo, pedronis i've doctor appointment in 15, shouldn't take long, will be back on this afterwards
<pedronis> ok
<mvo> pstolowski: not super urgent, no worries. see you
 * pstolowski bbiab
<zyga> good morning
 * zyga came to check if 2.45.3.1 built fine for suse
<mborzecki> zyga: hey, how are you feeling today?
<zyga> mborzecki: much  better
<zyga> stronger than before
<mborzecki> zyga: yay, that's great
<mborzecki> zyga: koza sends regards ;)
<zyga> oh cool
<zyga> I wonder how he is doing
<pstolowski> back
<pstolowski> hey zyga!
<zyga> hey Pawel!
<zyga> last day off
<zyga> I can walk more each day
<zyga> I think tomorrow I could do two hour standing sessions interspaced with one hour in-bed sessions
<zyga> and intermixed with prescribed exercise
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/9078 ?
<mup> PR #9078: [RFC] boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<mborzecki> mvo: and i'll poke ijohnson too when he's online, it'd be nice to land it soonish
<mvo> mborzecki: yes
<mborzecki> mvo: thanks!
<zyga> hey mvo
<zyga> I was just chatting with Pawel
<zyga> I will take a break now, I'll come back later
<pstolowski> pedronis: do you have a moment for #9088 ?
<mup> PR #9088: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding ð> <Run nested> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9088>
<pedronis> pstolowski: do you have a question? or do you need a review?
<pstolowski> pedronis: review
<pedronis> ah, no, I confused it with a different PR
<pedronis> I put it in my queue (having lunch break atm)
<pstolowski> thanks, enjoy
<mup> PR snapd#9090 closed: cmd/snap/debug/seeding: use unicode for proper yaml <Preseeding ð> <Simple ð> <â  Critical> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9090>
<pedronis> mvo: ^ I forced merged that one, we have a problem with debian-sid atm, it will need a backport
<mvo> pedronis: ok
<pedronis> pstolowski: reviewed, made some maybe slightly annoying comments, and also a very different suggestion in: https://github.com/snapcore/snapd/pull/9088#discussion_r465666390
<mup> PR #9088: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding ð> <Run nested> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9088>
<pstolowski> pedronis: thanks, will take a look
<pedronis> pstolowski: I think the suggestion is simpler than either current or what I suggested, if a bit less clean, but probably clean enough
<mborzecki> moving back home
<ijohnson> morning folks
<pedronis> mvo: I did a pass on #8982, looks good, left some comments. It needs new reviews though because it has changed quite a bit
<mup> PR #8982: snapshots: export of snapshots <Needs Samuele review> <Created by slimjim777> <https://github.com/snapcore/snapd/pull/8982>
<mvo> pedronis: thank you so much
<mup> PR snapd#9092 opened: interfaces/udev: Do not reload udevadm rules when preseeding <Bug> <Preseeding ð> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9092>
<pstolowski> ^ i need to check other backends, will address them separately if needed
<pstolowski> ouch https://www.engadget.com/honda-recalls-608000-minivans-and-suvs-with-fault-software-issues-121511778.html
<pstolowski> shoud have auto-refresh enabled ;)
<pedronis> pstolowski: I reviewed that
<pstolowski> ty
<ijohnson> what's the situation with the udev backend and preseeding ?
<mvo> pedronis: 8946 got a review from Graham, he +1 but also mentioend to add a period at the end of each sentence. I guess I will just add the "." and push and once tests are good merge ? or do you think the extra spread run is not needed?
<pstolowski> ijohnson: I got past the mount issue on xenial, but then it failed as apparently udevadm was triggered by some interface in the seeded snaps (see my standup notes)
 * ijohnson looks
<pedronis> mvo: not, needed but the tool needs changes
<pedronis> as well
<pedronis> mvo: I can also look into that today
<pedronis> mvo: doing cherry-picks for 2.45 is probably more urgent
<ijohnson> pstolowski: interesting, perhaps we should try seeding other snaps which have other interfaces
<ijohnson> err preseeding
<pedronis> ijohnson: I asked to look at all backends
<pstolowski> ijohnson: i'm going to check other backends
<ijohnson> sorry I just meant as a spread test
<ijohnson> since we may change things over time in the backends setup
<pedronis> yes
<pedronis> but a bit unclear how to do that, we mostly need to cover backends more than interfaces, but backends might vary. We have a snap with all possible interfaces
<pedronis> but not sure it would play well with preseeding
<ijohnson> also the issue is that snap with all possible interfaces doesn't have store decls, does it ?
<pedronis> exactly
<ijohnson> we would need store assertions for the backends to actually run when interfaces are connected
<pedronis> also connecting them doesn't always make sense
<ijohnson> mmm
<pedronis> I mean, with things like some of the support interfaces it gets messy
<pedronis> I mean I don't think is sensible to have such set of store declarations
<pedronis> I think we need just enough to cover our bases
<ijohnson> agreed
<pedronis> sensibly
<pedronis> maybe there's a why to write backends that would make this kind of issue easier to track
<pedronis> mvo: I'll take care of 8946 today
<mvo> pedronis: thank you
<pedronis> mvo: pushed, please double check my last changes when you have a moment
<pstolowski> kmod backend needs the same treatment
<pedronis> pstolowski: systemd as well I think
<pstolowski> pedronis: just looking at it.. yes
<pstolowski> i forgot about all these corners
<mborzecki> ijohnson: can you take a look at https://github.com/snapcore/snapd/pull/9078 later today?
<mup> PR #9078: [RFC] boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<ijohnson> sure
<mborzecki> ijohnson: thanks, it'd be nice to land it to unblock the horrors in modeenv
 * ijohnson read it as "unlock the horrors" and I imagine it's not actually too far off
<mborzecki> hm damn build tags
<mup> PR snapd#9093 opened: interfaces/kmod: don't load kernel modules in kmod backend when preseeding <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9093>
<pstolowski> should #9041 be tagged for 2.45 as well?
<mup> PR #9041: osutil/group.go: treat all non-nil errs from user.Lookup{Group,} as Unknown* <Bug> <Needs security review> <Preseeding ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9041>
<ijohnson> pstolowski: no not necessary for 2.45, as it's blocked on security
<pstolowski> ack
 * cachio lunch
<pedronis> pstolowski: I just landed #9091
<mup> PR #9091: cmd/snap: display the error in snap debug seeding if seeding is in error <Preseeding ð> <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9091>
<pstolowski> ack, ty
<mup> PR snapd#9091 closed: cmd/snap: display the error in snap debug seeding if seeding is in error <Preseeding ð> <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9091>
<pedronis> pstolowski: so I think with that all the debug seeding PR are on master
<pstolowski> pedronis: yes; i'll look at backporting now
<pedronis> thank you
<mup> PR snapd#8946 closed: client: move all error kinds into errors.go and add doc strings <Needs Samuele review> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8946>
<pedronis> degville: mvo: I did the merge: https://github.com/snapcore/snapd/commit/a777978c1102ea95f0a820e174ee066e6efcbcb4
<mvo> pedronis: thank you!
<degville> pedronis: thanks! I'll update the API page accordingly.
<pedronis> thank you
<mup> PR snapd#9094 opened: corecfg: add "system.hostname" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9094>
<pstolowski> so everything re seeding debug backported cleanly, except for spread tests & their helper scripts :}, a bit of a mess there
<mup> PR snapcraft#3197 closed: experimental extension support <enhancement> <specification> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3197>
<mup> PR snapd#9083 closed: tests: new parameters for nested execution <Run nested> <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9083>
<mup> PR snapcraft#3239 opened: lxd: update connectivity check url <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3239>
<cachio> ijohnson, cmatsuoka hi, someone could please take a quick look to this one? #8942
<mup> PR #8942: tests: support different images on nested execution <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8942>
<cachio> it needs a second review
<cachio> I need that merged to start pushing a new set of improvements for nested
<cachio> thanks
<ijohnson> cachio: sure I can take a look
<cachio> ijohnson, tx+
<ijohnson> cachio: did you try that branch with the cloud-init nested spread tests ?
<cachio> all the tests are executed with cloud init
<ijohnson> cachio: no I mean did you run the specific tests/nested/manual/cloud-init-* spread tests with this branch ?
<cachio> ijohnson, not sure if I am understanding whe question
<ijohnson> I imagine those tests would fail with your change
<ijohnson> because now when we call start_nested_vm_unit the image file modifications previously done in those tests/nested/manual/cloud-init-* tests would be undone and thus cause those tests to break
<cachio> well, they are going to be executed as part of the github actions tests
<cachio> let me check the results
<ijohnson> ok, but I still think that bit of changes would break those tests
<cachio> I'll make a review now to see
<ijohnson> if those tests still pass then perhaps the tests are written poorly
<ijohnson> thank you
<cachio> ij
<cachio> ijohnson, it should work
<cachio> because in this pr after the manual test we clean the images
<cachio> so it is not a problem
<cachio> your concern if fixed in the following one, because the manual tests haev a specific name in the images
<cachio> and the images are not cleaned anymore
<cachio> so they can be reused
<cachio> does it make sense?
<ijohnson> cachio: no what I mean is that in the tests/nested/manual/cloud-init-nocloud-not-vuln test, we manually call `start_nested_core_vm_unit`
<cachio> yes, all the manual tests do that
<ijohnson> so now when that is called on line 150 of that task.yaml, your code will overwrite the image file that was used earlier in the test when we called start_nested_core_vm on line 40
<ijohnson> cachio: sorry I think the point I'm trying to make is that we have tests where start_nestec_core_vm_unit is called multiple times during one test
<cachio> ah, ok, got it, let me see
<cachio> ijohnson, so the problem is that we do
<cachio> cp "$IMAGE_DIR/$IMAGE_NAME" "$CURRENT_IMAGE"
<ijohnson> yes that will overwrite the CURRENT_IMAGE used earlier in the test
<cachio> when we start ther image and this overwrite the image right?
<ijohnson> yes
<cachio> ijohnson, ok, good point, I can fix that
<ijohnson> thanks
<cachio> thakns for the review!!!
<ijohnson> np
<cachio> ijohnson, I think it should be fised
<cachio> fixed
<cachio> let see the test results
<cachio> ijohnson, I am going to the kinesiologist now
<cachio> I'll be back in 1 hour
<cachio> thanks for the review
<ijohnson> cachio: ack I'll take a look at the test results when it's done
<cachio> I had to leave the copy in the function start_nested_core_vm_unit because now the same of the image changes
 * cachio afk -> kinesiologist
<mup> PR snapcraft#3239 closed: lxd: update connectivity check url <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3239>
<mup> PR snapd#9085 closed: daemon,many: switch to use client.ErrorKind and drop the local errorKind <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9085>
<mup> PR snapd#9095 opened: boot/bootstate20: unify commit method impls, rm bootState20MarkSuccessful <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9095>
<mup> PR snapd#9096 opened: strutil: add ListsSame helper <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9096>
<mup> PR snapd#9097 opened: boot/modeenv: add m.deepEquals, m.Origin helpers to simplify bootstate20 refactor <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9097>
#snappy 2020-08-06
<mup> PR snapd#9098 opened: tests: new organization for nested tests <Run nested> <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<mup> PR snapd#9089 closed: many: introduce content write observer, install mode glue, initial seal stubs <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9089>
<mborzecki> morning
<mup> PR snapd#9099 opened: github: do not skip gofmt with Go 1.9/1.10 <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9099>
<zyga> good morning
<zyga> I will start at 9:00
 * zyga starts the day
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> mvo: pstolowski: zyga: hey
<zyga> o/
<mborzecki> pstolowski: #9099 should catch the formatting errors you had in the interfaces PR early in the ci run
<mup> PR #9099: github: do not skip gofmt with Go 1.9/1.10 <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9099>
<mborzecki> (and it's trivial btw)
<pstolowski> thx
<zyga> nice
<pstolowski> mvo: hey, as i said yesterday evening, backporting all the debug preseeding api was easy process, except for preseed spread tests. they diverged over time in master (including some associated tests/lib helpers). a lot of cherry picking and crossing lines with various tweaks that Sergio implemented in the meantime. not sure what to do
<pstolowski> mvo: on the other hand would be good to have snap debug seeding .. in the spread test to confirm everything is in place
<pstolowski> fwtw that was my older PR that attempted to bridge the gap (but we didn't land it) https://github.com/snapcore/snapd/pull/8980
<mup> PR #8980: tests: backport preseed test fixes to 2.45 <Test Robustness> <Created by stolowski> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8980>
<zyga> they are shooting a movie outside our house again
<mvo> pstolowski: I think we can live without the spread tests if it's too muhc of a hassle
<mvo> pstolowski: we need to do a manual test then but it's not the end of the world as long as it's in master
<mvo> zyga: good morning! how do you feel?
<zyga> good morning!
<mvo> mborzecki: good morning to you as well :) I have not forgoten 9078
<zyga> so far so good
<mborzecki> mvo: hahah, thanks
<zyga> I'm almost done with 9057
<mborzecki> quick errand, may be late for the desktop meeting
<pstolowski> mvo: ok
<mup> PR snapd#9100 opened: many: cherry-pick debug seeding api for 2.45 <Created by stolowski> <https://github.com/snapcore/snapd/pull/9100>
<mborzecki> re, heh, not even a real errand, pickup guy waited for me at the gate
<mborzecki> thought i'd have to drive a little
<pstolowski> ^ there is one commit there touching spread test that could be omitted (since i haven't backported other changes to this tests and it will most likely won't work)
<zyga> I just realized my note-taking notebook is upstairs
<zyga> time to clime the mountain
<zyga> brb
<zyga> re
<mup> PR snapd#9099 closed: github: do not skip gofmt with Go 1.9/1.10 <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9099>
<mup> PR core#115 closed: live-build/hooks: add chroot hook to rm cloud-init config file we don't want <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/core/pull/115>
<zyga-x240> ok, small break to lie down
<mup> PR snapd#9101 opened: interfaces/systemd: use emulation mode when preseeding <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9101>
<pedronis> pstolowski: hi, #9100 is missing a couple of things, see my comment there
<mup> PR #9100: many: cherry-pick debug seeding api for 2.45 <Created by stolowski> <https://github.com/snapcore/snapd/pull/9100>
<pstolowski> pedronis: thanks for spotting!
<mup> PR snapd#9102 opened: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<pstolowski> pedronis: updated
<zyga-x240> mvo: https://github.com/snapcore/snapd/pull/9102#pullrequestreview-462363510
<mup> PR #9102: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<mvo> zyga: nice catch, I will fix this
<mvo> zyga: I looked over all timezones I could find but obviously I missed some
<mvo> zyga: maybe I should relax this a lot, not sure if I'm too cautious
<zyga-x240> yeah, I was thinking if we should validate
<zyga-x240> I guess it's a good thing if it gets checked early
<zyga-x240> at snap build time (gadget defaults)
<zyga-x240> but probably not good otherwise (we need to match another implementation)
 * mvo hugs mborzecki for 9103
<mborzecki> mvo: we had a TODO there, pedronis correctly pointed out it's probably time to fix it to avoid incomplete writes when updating grub efi binaries
<mup> PR snapd#9103 opened: gadget, osutil: use atomic file copy, adjust tests <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9103>
<mvo> mborzecki: yeah, hence the *hug* :)
<mvo> mborzecki: thanks for fixing this
<pedronis> pstolowski: thx
<mborzecki> pedronis: btw. ListsEqual or ListEqual in 9096? it's a trivial patch i can push and maybe we can land it before ijohnson comes online
<pedronis> mborzecki: ListEqual
<mborzecki> ack
<zyga-x240> mvo: https://github.com/snapcore/snapd/pull/9102#pullrequestreview-462374184
<mup> PR #9102: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<ogra_> mvo, i assume using #9102 is not mandatory ? i.e. using timezone-control from a snap will still work ?
<mup> PR #9102: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<pedronis> mvo: some comments/questions in #9094
<mup> PR #9094: corecfg: add "system.hostname" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9094>
<mvo> ogra_: yes, the main use-case for image building. but mixing snap set and other means to set the timezone will be problabmatic
<mvo> ogra_: the main use case *is* image-building for uc20
<pedronis> mvo: we'll need to make this virtual like netplan at some point
<mvo> pedronis: exactly
<ogra_> yeah ... as long as using i.e. a snap that looks up the TZ via geoip and setting the TZ still works all is fine
<pedronis> maybe we need TODOs for that
<mvo> pedronis: happy to add one
<pedronis> same for hostname
<mvo> pedronis: will do
<pedronis> mvo: anyway some questions there, probably relevant also for timezone
<mvo> ogra_: yeah, that's fine as long as it's not mixed (i.e. sometimes snap set, sometimes timedatectl directly)
<ogra_> right
<mvo> pedronis: yeah, thank you
<zyga-x240> mvo: https://github.com/snapcore/snapd/pull/9094 is not bi-directional, right?
<mup> PR #9094: corecfg: add "system.hostname" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9094>
<zyga-x240> if I set a system hostname, get will tell me it is ""
<zyga-x240> unless I used set to set it
<zyga-x240> right?
<mvo> zyga-x240: yes, until we have virtual config nodes
<zyga-x240> ok
<ogra_> mvo, so we shoudl better not set it by default (wrt UC20 images) to not force the world to use snapd-control ð ... perhaps timezone-control could grant access to the setting though ?
<zyga-x240> oh
<zyga-x240> interesting
<mvo> ogra_: we will support virtual configuration soon(ish) then this will become a non-issue
<mvo> ogra_: but yeah, until then it's a problem
<ogra_> i dont think baking a TZ into an image at build time is a good idea at all though ... in case thats the plan
<mvo> I guess we could cheat for hostname/timezone and simply import if unset but feels a bit hacky
<mvo> ogra_: heh :) I'm just a code-monkey, this was a request from the people building images
<ogra_> well, but do they understand the implications ?
<mvo> ogra_: apparently one of the things that happend in uc18 is that writable is modified to change timezone/hostname
<zyga-x240> ogra_: if you are a telco doing consumer hw for a small EU country, baking the timezone is OK
<zyga-x240> I think it's a valid use case
<ogra_> zyga-x240, not talking about a telco that uses a brand store and has access to snapd-control ...
<zyga-x240> sure but it's the out-of-the box thing that works before you get online fully
<zyga-x240> I think it's not wrong
<ogra_> but about our community images where people only have timezone-control to set it
<ogra_> having snaps re-set my TZ to whats baked into the image on boot wouldnt be something i expect
<mvo> ogra_: we will not have anything in our community images that will set this
<ogra_> s/snaps/snapd/
<ogra_> ah, k
<zyga-x240> we could have a ubuntu-core-20-brexit image
<zyga-x240> with hard-coded TZ
<ogra_> all fine then ð
 * zyga-x240 runs
<mvo> ogra_: but you make an interessting point. I guess "snap get system.timezone" should really get whatever /etc/localtime tells it regardless of the setting
<zyga-x240> and blue splash screen
<zyga-x240> mvo: I think those are both properties
<ogra_> with a big long hex number and the word "SUCCESS"
<zyga-x240> not actual variables
<pedronis> mvo: yes, that means virtual config. we really need to start on that sooner or later
<zyga-x240> you can read / write but the system is authoritative
<mvo> pedronis: +1
<pedronis> pstolowski: btw, did you see my comment in #9088 ?
<mup> PR #9088: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding ð> <Run nested> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9088>
<pstolowski> pedronis: yes, thank you, just got sidetracked by other stuff, will get back to this PR in a bit
<pedronis> ok, thx
<mvo> zyga-x240: I applied your suggestions (and more) in 9094 (the companion PR for hostname). if it looks good there I will also put them into the timezone one
<zyga-x240> mvo: thanks, I'll review the hostname one as well
<zyga-x240> looking at your changes now
<zyga-x240> mvo: https://github.com/snapcore/snapd/pull/9094#pullrequestreview-462410202
<mup> PR #9094: corecfg: add "system.hostname" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9094>
<mvo> zyga-x240: thank you!
 * zyga-x240 moved the locking earlier
<zyga-x240> now to look at tests
<mup> PR snapd#9100 closed: many: cherry-pick debug seeding api for 2.45 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9100>
<pedronis> pstolowski: I re-reviewed #9088
<mup> PR #9088: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding ð> <Run nested> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9088>
<pstolowski> pedronis: thanks
 * zyga-x240 is making progress on tests
<ijohnson> morning folks
<pstolowski> morning ijohnson !
<ijohnson> hey pstolowski
<zyga-x240> hey ijohnson !
<ijohnson> morning zyga
<zyga-x240> brb, see you at the standup
<zyga-x240> 2/3 sid passed without an error
<mborzecki> zyga-x240: https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/10375/signedlogcontent/60?urlExpires=2020-08-06T14%3A04%3A51.3637247Z&urlSigningMethod=HMACV1&urlSignature=CF%2B2ibNYy9HIFj7kxbQb7%2Fh9DQ71vy%2F6z2rksCZgawA%3D that's sid
<zyga-x240> ah, thanks
<zyga-x240> I'll look into those
<mborzecki> zyga-x240: this link is probbaly better: https://github.com/snapcore/snapd/runs/953201904
<zyga-x240> I will focus on a specific case and dig into it, but first some tests need finishing
<mvo>  ?
<ijohnson> pedronis: mmm actually maybe we do need a short sync, I can get rid of the Origin() method, but I'm not sure if I should go the route of implementing both the deepEqual method and a copy method, or if there's some way I can get away with only one additional method on *Modeenv compared to master
<mup> Bug #1890610 opened:  'snap install' | "INFO Waiting for automatic snapd restart..."  <Snappy:New> <https://launchpad.net/bugs/1890610>
<ijohnson> pedronis: I don't see how to do it with just a single additional method, but I can get rid of deepEqual if I have a Duplicate method and something like m.SyncUpdates(m2)
<ijohnson> perhaps it's fine to have both deepEqual and a Duplicate method even if their impls will largely be the same
<mup> Bug #1890610 changed:  'snap install' | "INFO Waiting for automatic snapd restart..."  <Snappy:New> <https://launchpad.net/bugs/1890610>
<mup> Bug #1890610 opened:  'snap install' | "INFO Waiting for automatic snapd restart..."  <Snappy:New> <https://launchpad.net/bugs/1890610>
<pedronis> ijohnson: we can sync quickly if you want
<ijohnson> pedronis: yes if you have time, should be simple, just not sure which methods you would want
<jamesh> jdstrand: When you've got time, could you have a look over https://github.com/snapcore/snapd/pull/8943 (dbus activation support)?  I know you reviewed a version of this in another PR, but the implementation has changed a bit so probably needs another pass
<mup> PR #8943: wrappers: generate D-Bus service activation files <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8943>
<pedronis> ijohnson: let me join the standup again
<ijohnson> k, joining
<jamesh> jdstrand: there is less code to review this time around though, which should help
<mborzecki> cachio: i've updated #9019
<mup> PR #9019: tests/nested/manual/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
<jdstrand> jamesh: yes, I'm hoping to get to that after something I'm doing for microk8s atm. thanks for the ping. I also owe you a response to the theme forum topic
<cachio> mborzecki, nice, I'll take a look
<jamesh> jdstrand: thanks
<pedronis> mvo: I gave some feedback on your comment here: https://github.com/snapcore/snapd/pull/9103#discussion_r466349911
<mup> PR #9103: gadget, osutil: use atomic file copy, adjust tests <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9103>
<mvo> pedronis: thank you
<mup> PR snapd#9104 opened: tests: fix for timing issues on journal-state test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9104>
<pedronis> ijohnson: do you know if your PR conflicts with #9078 ?
<mup> PR #9078: boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<ijohnson> pedronis: it might not actually, do you want me to double check
<ijohnson> ?
<pedronis> no, just wondering
<pedronis> I'll try to review it soon
<ijohnson> I don't think it should as mine is just adding things
<pedronis> mvo: I reviewed the recovery/reboot PRs
<mvo> pedronis: \o/
<pedronis> the reboot one needs a bit more work I think
 * zyga-x240 finished with refresh checks and will focus on debian in 15 minutes
<zyga-x240> small break
<ijohnson> should I merge #9096 or just close it now
<mup> PR #9096: strutil: add ListEqual helper <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9096>
<ijohnson> it's not used anymore
<pstolowski> mvo: one suggestion to #9102
<mup> PR #9102: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<mvo> pstolowski: thank you
<pedronis> ijohnson: I would say close it
<ijohnson> pedronis: ack
<zyga-x240> ok, let's fix debian
<pedronis> ijohnson: why did you call the new method Duplicate when we agreed to call it Copy ?
<pedronis> :)
<ijohnson> I literally just re-force pushed it like 60 seconds ago
<pedronis> ah
<pedronis> ijohnson: it's somehow still called Duplicate, did you force push less than expected?
<ijohnson> also if we now have DeepEqual, why do we have check.DeepEquals ??
<ijohnson> I also forgot to rename DeepEquals -> DeepEqual so I am force pushing that
<ijohnson> give me like 3 minutes and all renames will be sorted out sorry
<pedronis> ijohnson: I don't think check is following go conventions there
<ijohnson> fair
<pedronis> it's Time.Equal and reflect.DeepEqual
<pedronis> etc
<ijohnson> I can't wait for the day that we can use a new gofmt :-/
<mup> PR snapd#9096 closed: strutil: add ListEqual helper <Simple ð> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9096>
<ijohnson> ugh that took too long
<ijohnson> everything should be in sync now, renamed and passing gofmt 1.9
<ijohnson> I also canceled all the queued / in progress github actions from my various force pushes
<cachio> ijohnson, hey
<ijohnson> hi cachio
<cachio> I see thie error refreshing core20
<cachio> https://paste.ubuntu.com/p/XdF4Qq7nmS/
<ijohnson> cachio: you mean the "there was a rollback" message ?
<cachio> this is after hte reboot
<zyga-x240> Aug 06 15:47:40 aug061535-531864 systemd-user-runtime-dir[35169]: Failed to acquire number of inodes for runtime directory: Unknown interface org.freedesktop.>
<cachio> ijohnson, yes
<zyga-x240> Aug 06 15:47:40 aug061535-531864 systemd-user-runtime-dir[35169]: Failed to acquire number of inodes for runtime directory: Unknown interface org.freedesktop.login1.Manager or property RuntimeDirectoryInodesMax.
<cachio> I reffreshed from beta to edge
<cachio> after the reboot I see that
<ijohnson> cachio: is this after your dropping of kvm ? or is this not a vm ?
<ijohnson> s/vm/nested vm/
<cachio> ijohnson, it si a vm with kvm enabled
<ijohnson> cachio: is it a nested vm ?
<cachio> yes
<ijohnson> cachio: so this could just be that random reboot bug
<ijohnson> cachio: do you have the rest of the log ?
<cachio> ijohnson, this is what I have https://paste.ubuntu.com/p/Wr2Dgjb3rs/
<cachio> ijohnson, I'll try again without kvm
<ijohnson> cachio: seems something got broken in this branch you are using
<ijohnson> qemu has `-serial file:/tmp/work-dir/serial.log`
<ijohnson> but spread debug is looking at
<ijohnson> `+ '[' -f /tmp/work-dir/serial-log.txt ']'`
<ijohnson> that wouldn't break anything but it means we got less information than we need to in order to diagnose if this was the random reboot problem
<zyga-x240> that property is real but is missing from introspection data
<cachio> ijohnson, you are right
<cachio> fixing that
<ijohnson> cachio: yes please try w/o kvm, or you do have #9083 applied locally where you are running this ?
<mup> PR #9083: tests: new parameters for nested execution <Run nested> <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9083>
<ijohnson> zyga-x240: broken systemd ?
<zyga-x240> perhaps, not sure yet
<zyga-x240> introspection data certainly disagrees with source
<ijohnson> that seems bad
<zyga-x240> I'm running sid on one test machine (not vm)
<zyga-x240> so I guess I'm brave ;-)
<ijohnson> very brave :-)
<zyga-x240> it's a ppc box
<zyga-x240> you go there to compile C code and see if it works
<pedronis> mvo: ijohnson: I reviewed but then ended up submitting some tweaks #9078
<mup> PR #9078: boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<ijohnson> pedronis: did anyone ever figure out the deal with secboot's checksumSHA1 flip flopping around ?
<pedronis> no
<pedronis> ijohnson: what do you get there?
<cachio> ijohnson, yes merged with 9083
<cachio> now  runing without kvm enabled
<zyga-x240> ok, I think I have a partial fix
<zyga-x240> at least for one test
<ijohnson> cachio: mmm then please fix the serial file so we can see the log, it may be a real problem then if we aren't having random reboots anymore
<cachio> ijohnson, I already fixed that, let's see the results in 30/40 minuets
<ijohnson> cachio: I don't see those different filenames on master, was that locally you changed that ?
<cachio> ijohnson, thanks for the catch
<ijohnson> cachio: ack sounds good
<ijohnson> pedronis: one moment
<ijohnson> pedronis: I have `fqejS2llZXw3gLnOYhg7pcSlY+Q=` like on master, but sometimes it changes for me as well, unclear when it changes, see for example my systemd-mount PR
<zyga-x240> brb
<ijohnson> pedronis: ah actually my systemd-mount PR has the same change as your PR does https://github.com/snapcore/snapd/pull/9010/files#diff-bd290170e2912d3e8694db1a151066e5
<mup> PR #9010: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool <Run nested> <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9010>
<pedronis> ijohnson: anyway 9078 needs a review of my commit
<ijohnson> pedronis: yes one moment lgtm I will submit a formal review
<zyga-x240> sirens outside all day
<zyga-x240> today new president got sworn
<zyga-x240> all kind of important folks are driven around
<zyga-x240> police, vip cars, more police
<pedronis> mvo: should I push the rename and arg swap to #9103 ?
<mup> PR #9103: gadget, osutil: use atomic file copy, adjust tests <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9103>
<mvo> pedronis: yeah, if feel free then we can merge
<mvo> pedronis: I pushed an update to 9020
<zyga-x240> sloooow prepare
<zyga-x240> testing fixes is slow
<pedronis> mvo: done here: https://github.com/snapcore/snapd/pull/9103/commits/46a7e60434a7115f5dc8a1910e5e160e09c4ac73
<mup> PR #9103: gadget, osutil: use atomic file copy, adjust tests <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9103>
<mvo> pedronis: thank you
<zyga-x240> more sirens
<zyga-x240> feels like a fire truck
<zyga-x240> they have different horns
<mup> PR snapd#9057 closed: overlord: use new tracking cgroup for refresh app awareness <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9057>
<pedronis> zyga-x240: could you look at #9101 ?
<mup> PR #9101: interfaces/systemd: use emulation mode when preseeding <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9101>
<zyga-x240> sure
<pedronis> thx
<pedronis> given the arg surgery I did on #9103 it probably needs a 2nd review from somebody else than me
<mup> PR #9103: gadget, osutil: use atomic file copy, adjust tests <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9103>
<ijohnson> pedronis: do you need me to review more of pawel's preseeding PR's as they pertain to the backends ?
 * ijohnson can't remember whether those are going into 2.45.4 or not
<pedronis> ijohnson: they are
<pedronis> ijohnson: for 2.45.4 #9088, #9101, and #9103 need 2nd reviews
<mup> PR #9088: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding ð> <Run nested> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9088>
<mup> PR #9101: interfaces/systemd: use emulation mode when preseeding <Bug> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9101>
<mup> PR #9103: gadget, osutil: use atomic file copy, adjust tests <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9103>
<ijohnson> pedronis: ok I will try to look at all of those today, might not get to all of them
<pedronis> ijohnson: I think zyga will look as well at 9101, so start with the other two
<ijohnson> sure
<zyga-x240> more on the sid error side: Aug 06 16:39:09 aug061610-263415 dbus-daemon[302]: [system] The maximum number of pending replies for ":1.6" (uid=0 pid=673 comm="/lib/systemd/systemd-logind ") has been reached (max_replies_per_connection=128)
 * pedronis mostly eods
<zyga-x240> interesting that systemd-logind uses 450MB of ram when it's in a broken state
<zyga-x240> and about 2MB of ram when functional
<ijohnson> wow
<zyga-x240> right?
<zyga-x240> I'll check earlier, I think this is broken at an earlier stage
<zyga-x240> just restarting systemd-logind.service seems to "fix" stuff
<zyga-x240> maybe some package upgrades we do leave it this way
 * zyga-x240 adds "false" in a strategic place ;)
<zyga-x240> ijohnson: could you look at https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga-x240> at the last comment only
<zyga-x240> and at the diffstat
<ijohnson> haha I'm literally reviewing it now
<ijohnson> :-)
<zyga-x240> haha cool :)
<ijohnson> +1d
<zyga-x240> I saw, super!
 * cachio lunch
<zyga-x240> ok, moved false to after prepare project
<zyga-x240> let's see if it's already broken then
<zyga-x240> oh,
<zyga-x240> I should have just upgraded in place
<zyga-x240> that would probably be enough
<zyga-x240> oh well, I'll know in a moment
<zyga-x240> yeah, just preparing project is enough
<zyga-x240> I understand the bug now
<zyga-x240> (for debian sid)
<pedronis> zyga-x240: is there are an order to #7700, #7825, #8573 . should they be reviewed in their PR number order? or something else?
<mup> PR #7700: cmd/snap: wait while inhibition file is present <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<zyga-x240> pedronis: I would recommend to look at 7700 first - it's rather basic and shows what happens on snap run
<zyga-x240> pedronis: then at 8573 as it shows how we acquire the new inhibition lock
<zyga-x240> and ignore 7825 for now
<zyga-x240> as it is a hollow branch that just removes code now
<zyga-x240> https://github.com/systemd/systemd/issues/16685 for context
<zyga-x240> xnox: do you know any systemd debian maintainers
<zyga-x240> there's a bug that cripples snapd tests that just rolled out to sid
<zyga-x240> the fix is a one liner
<zyga-x240> but requires some thought and consideration
<zyga-x240> I'm reporting a debian bug now, almost done
<zyga-x240> I'll attach a patch
<zyga-x240> ok, reported now
<zyga-x240> I'll send a patch to unbreak sid while we wait for the package to be fixed
<zyga-x240> testing a fix now
<zyga-x240> I should have EODd a while a go
<zyga-x240> *ago
<xnox> zyga:  normally patches go as pull requests on salsa.debian.org against systemd repo
<zyga-x240> xnox: the situation is more complex now, it's not a clear fix :/
<zyga-x240> it's just kind of bad and there's no good solution
<zyga-x240> I've updated the upstream bug with references if you are interested
<zyga-x240> ok, fixed, I'll run a quick smoke test and open a PR
<zyga-x240> ijohnson: https://github.com/snapcore/snapd/pull/9105
<mup> PR #9105: tests: work around bug in systemd/debian <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9105>
<ijohnson> nice
<mup> PR snapd#9105 opened: tests: work around bug in systemd/debian <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9105>
<zyga-x240> OK
 * zyga-x240 resolved some conflicts and EODs
<zyga-x240> it's been a long day
<zyga-x240> need to exercise a little
<zyga-x240> o/
<zyga-x240> ijohnson: I resolved conflicts in https://github.com/snapcore/snapd/pull/8573 now
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<mup> PR snapd#9106 opened: gadget: remove partition table data from ondisk volume <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9106>
<cachio> ijohnson, I was refreshing reverting core20 and snapd snapd the whole afternoon without kvm and it worked 100%
<ijohnson> nice
<cachio> so the problem were the random reboots
<ijohnson> still odd that you were running without kvm and hit that issue this morning though
<cachio> I am running those tests in a look, at some point I'll reproduce them
<ijohnson> thanks cachio
<cachio> yaw
<cachio> ijohnson, could you take a second review to #8942 plase?
<mup> PR #8942: tests: support different images on nested execution <Run nested> <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8942>
<ijohnson> cachio: sure
<cachio> so if it is green I can squash merge it
<cachio> thanks
<ijohnson> many things seem to be stuck in queued state right now
<cachio> yes
<ijohnson> what I've been doing is to cancel individual spread runs via the github ui, then wait for all the other spread runs to be canceled, then go and hit re-run
<ijohnson> not sure how helpful that has been
<ijohnson> we may need Zygmunt to update the self hosted runners or something
<cachio> np, I'll monitor that one
<cachio> thanks
<mup> PR snapd#9103 closed: gadget, osutil: use atomic file copy, adjust tests <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9103>
#snappy 2020-08-07
<mborzecki> morning
<mup> PR snapd#9078 closed: boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<zyga-x240> good morning
<mup> PR snapd#9107 opened: tests: remove End-Of-Life releases from spread.yaml <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9107>
<mborzecki> zyga-x240: hey
<zyga-x240> hey :)
<mvo> good morning zyga-x240 and mborzecki
<zyga-x240> I'm experimenting with a small idea that will give us a bit more CI speed
<zyga-x240> hey mvo :)
<zyga-x240> we can run the cla-check on self-hosted workers
<zyga-x240> this will release a slot for the more expensive unit test jobs
<mborzecki> mvo: hey
<mborzecki> zyga-x240: do we need to move the check to the tests yaml file or can this be changed in the github repo actions configuration?
<zyga-x240> just a tweak to the yaml
<zyga-x240> no need to change anything else
<mup> PR snapd#9088 closed: cmd/snap-preseed: use snapd from the deb if newer than from seeds <Preseeding ð> <Run nested> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9088>
<zyga-x240> I'm preparing the rest for this though
<zyga-x240> as the containers are unprivileged and devoid of sudo
<zyga-x240> though now that we have mvo around
<zyga-x240> I have one more idea :)
<zyga-x240> but that's for later
<zyga-x240> we can label workers
<zyga-x240> so we can create a subset of workers without spread keys
<zyga-x240> but with sudo
<zyga-x240> and we could use those for running unit tests (I have 4 spare cores at home, soon will have more)
<zyga-x240> with fast apt proxy and preinstalled snaps it will be speedy
<zyga-x240> on par with those over-provisioned xeons
<mup> PR snapd#9092 closed: interfaces/udev: do not reload udevadm rules when preseeding <Bug> <Preseeding ð> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9092>
<mup> PR snapd#9093 closed: interfaces/kmod: don't load kernel modules in kmod backend when preseeding <Bug> <Preseeding ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9093>
<mup> PR snapd#9101 closed: interfaces/systemd: use emulation mode when preseeding <Bug> <Preseeding ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9101>
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/9107#pullrequestreview-463069566
<mup> PR #9107: tests: remove End-Of-Life releases from spread.yaml <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9107>
<mborzecki> mvo: bw. we have two entries for debian-sid-64 in qemu backend
<mvo> mborzecki: haha - fun
<mborzecki> mvo: oh, and while at it, i think we can drop fedora-30 from google backend, it's EOL anyway
<mup> PR snapd#9108 opened:  gadget, osutil: use atomic file copy, adjust tests (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9108>
<zyga-x240> mvo: left a comment there
<mvo> zyga-x240: \o/
<zyga-x240> we should try to get that 20.04-on-zfs image
<zyga-x240> I'd love to see it fail
<pedronis> mvo: hi, I fixed the conflicts in #9097, could you re-review it ?
<mup> PR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9097>
<mup> PR snapd#9020 closed: cmd: add new "snap recovery" command <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9020>
<jamesh> zyga: https://github.com/snapcore/snapd/pull/9043 is probably in good shape to review now
<mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
<pstolowski> morning
<zyga-x240> hey pedronis, jamesh, pstolowski
<zyga-x240> ack, I'll look in a moment
<mvo> pstolowski: good morning! does master have all the preseed bits we need for cpc? if so I will release a 2.46~pre1.gitXXX to groovy
<mup> PR snapd#9109 opened: github: run CLA checks on self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/9109>
<mup> PR snapd#9110 opened: preseed: cherry-pick #8704, #8709, #9088 (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9110>
<mborzecki> pedronis: thanks for pushing fixes to my PRs yesterday
<pedronis> np
<pstolowski> mvo: yes
<mvo> pstolowski: cool, releasing now then
<pstolowski> ty!
<zyga-x240> woah
<zyga-x240> today is a good LTE day
<zyga-x240> I was just uploading at 200MBit rate
<mborzecki> zyga-x240: maybe everyone else is on vacation? hence lots of available bandwidth
<zyga-x240> mborzecki: maybe
<zyga-x240> I was wondering if getting an external antenna would help
<zyga-x240> the BTS I'm talking to is ~ 30 meters away
<zyga-x240> maybe 50
<zyga-x240> but I have to go through a bit of wall and glass
<zyga-x240> we could affix an antenna to the side of the house and just run the wires, the modem has two SMA connectors
<zyga-x240> mvo: the 2.45 thing is broken
<zyga-x240> src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:31:2: imported and not used: "github.com/snapcore/snapd/cmd/cmdutil"
<zyga-x240> src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:167:22: undefined: snapdtool
<zyga-x240> src/github.com/snapcore/snapd/cmd/snap-preseed/preseed_linux.go:175:21: un
<zyga-x240> something is not right
<mvo> zyga-x240: oh no
<mvo> zyga-x240: yeah, it's a PITA, it diverged quite a bit
<mvo> zyga-x240: maybe the answer is really 2.46 :/
<zyga-x240> *exactly*
<zyga-x240> we should really try
<zyga-x240> even if it goes nowhere but beta
<zyga-x240> we'd be backporting less
<pedronis> well, as long we do release .3.1 to stable
<zyga-x240> mvo: did you see the SANFU with systemd yesterday?
<zyga-x240> it's a bit unfortunate
<zyga-x240> I hope it doesn't affect regular users
<zyga-x240> upgrading in-place seems less and less supported
<zyga-x240> *SNAFU
<zyga-x240> how could I typo that :P
<pedronis> also jdstrand wanted things into 2.46 that he hasn't finished yet
<zyga-x240> I think having an early outlook would be great, after all it's all just a number, we could really finally push to stable something more like 2.46.3
<pedronis> as I said, it's fine, we do need to release .3.1 though
<zyga-x240> I agree
 * zyga-x240 reviews https://github.com/snapcore/snapd/pull/9043
<mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
<mborzecki> zyga-x240: if you're uploading at 200mbit/s i doubt antennas would help
<zyga-x240> I wonder what's the limit of this class of modem
<zyga-x240> I, for one, will be on 5G the moment it is avaliable
<mborzecki> zyga-x240: but, if your bts is heavily occupied, you may want to check other frequencies and force one that's rarely used by mobiles
<zyga-x240> unfortunately my firmware is pretty locked so I have almost no choice
<zyga-x240> on the upside I get pretty good overall speed so I think it's a pretty lucky location
<zyga-x240> there are BTSes all around here, maybe there are just enough
<mborzecki> zyga-x240: usually 800mhz is quite busy, but 1.8ghz and 2.6 are not :P
<zyga-x240> brb
<mvo> pstolowski: if I set "run-nested" will that also run the nested/manual suite?
<pstolowski> mvo: heh, i don't know of "run-nested"...  i was always invoking them manually with spread ... google-nested:...:tests/nested/manual/...
<mup> PR snapd#9111 opened: releases: release 2.46~pre1 to groovy <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9111>
<mborzecki> wow, it's warm today
<pedronis> pstolowski: I updated #9086 after your feedback
<mup> PR #9086: many: reorg cmd/snapinfo.go into snap and new client/clientutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9086>
<pstolowski> pedronis: yes, looking atm, ty
<zyga-x240> could we change things so that without run-nested there are "skips" not green ticks
 * zyga-x240 returns to review after a small interrupt to fix a test 
<zyga-x240> mvo, pedronis: could you please look at https://github.com/snapcore/snapd/pull/7825 and +1/-1 merging as-is
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga-x240> it's +2 technically but I wanted to triple check
<pedronis> zyga-x240: you told me yesterday not to look at it :)
<zyga-x240> it's a +13 -355 leftover from the "backend" work
<zyga-x240> pedronis: yeah because yesterday it was not relevant :)
<zyga-x240> I mean, the other PRs were more interesting
<zyga-x240> as they contain new work that needs direction
<zyga-x240> this is just pushing a stone up the hill till it's done
<mup> PR snapd#9112 opened: tests: run as hightest via tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9112>
<zyga-x240> jamesh: around?
<zyga-x240> jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-463128041 (partial to ask a question)
<mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
<zyga-x240> I'm reading the rest
<jamesh> zyga-x240: yeah
<jamesh> zyga-x240: the ucred == nil case would be true if the REST API was available via TCP.  It should always be non-nil for unix domain sockets
<zyga-x240> I see
<zyga-x240> in that case I think we should do what I suggested in the second comment
<zyga-x240> it's safer this way
<jamesh> zyga-x240: this effectively makes the existing GuestOK vs UserOK distinction meaningless
<zyga-x240> we can revisit this once we have http
<zyga-x240> I'll review the rest carefully
<zyga-x240> if you want and agree please push that change to the existing checkers
<zyga-x240> I would feel much safer with an early != nil check
<jamesh> zyga-x240: probably a good idea, on the basis of not making access decisions prematurely
<pstolowski> mvo: we could set 'run nested' label on #9102
<mup> PR #9102: corecfg: add "system.timezone" setting to the system settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<mvo> pstolowski: yeah, that's why I was asking earlier
<pstolowski> mvo: aaah, sorry, i didn't have enough coffee, i though it was about run-checks etc
<mup> PR snapd#9113 opened: tests: port regression-home-snap-root-owned to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9113>
<zyga-x240> jamesh: https://github.com/snapcore/snapd/pull/9043#pullrequestreview-463139716
<mup> PR #9043: daemon: replace access control flags on commands with access checkers <Needs security review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9043>
<zyga-x240> sorry for taking this long, I was really trying to think through the various consequences
<zyga-x240> brb
<zyga-x240> quick coffee :)
<pstolowski> pedronis: i updated #9001
<mup> PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9001>
<pstolowski> hmm, wot, unit test failed on FAIL: cmd_sign_test.go:55: SnapKeysSuite.TestHappyNonDefaultKey, seems like it called real gpg?
<zyga-x240> what was the rest of the failure?
<zyga-x240> I saw something like this today as well
<mup> PR snapd#9114 opened: tests: fix debug section of appstream-id test <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9114>
<pstolowski> zyga-x240:  value *errors.errorString = &errors.errorString{s:"cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure"
<pstolowski> zyga-x240: i'm looking into it
<zyga-x240> yeah, same error
<zyga-x240> cool
<zyga-x240> thanks!
 * zyga-x240 stops coding and goes for that coffee
<pedronis> mborzecki: we are hitting some kind of new issue on centos related to selinux and package versions: https://github.com/snapcore/snapd/pull/9097/checks?check_run_id=957590501
<mup> PR #9097: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9097>
<pedronis> we also got again the weird 16.04 with different cgroup setup
<mborzecki> pedronis: hmm, let me check that
<mborzecki> pedronis: uhh, yeah that's the usual upgrade thing where centos is lagging behind rhel again
<mup> PR snapd#9097 closed: boot/modeenv: add deepEqual, Copy helpers to simplify bootstate20 refactor <Simple ð> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9097>
<mup> PR snapd#9105 closed: tests: work around bug in systemd/debian <Test Robustness> <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9105>
<zyga-x240> pstolowski: https://github.com/snapcore/snapd/pull/9115
<mup> PR #9115: interfaces: check !b.preseed earlier <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9115>
<zyga-x240> pedronis: I'll look at the cgroup mystery as well
<zyga-x240> mborzecki: do you have any ideas? I'd like to ensure we boot the right kernel - depending on the spread system
<pstolowski> +1, ty
<zyga-x240> mborzecki: and then depending on the kernel that some super basic things hold (I know it intersects with systemd so I'd like to just constrain this to xenial for now)
<ijohnson> morning folks
<zyga-x240> ijohnson: good morning!
<ijohnson> hey zyga-x240
<mborzecki> zyga-x240: simple sanity checks are probably ok
<ijohnson> how are tests today
<ijohnson> seems like centos and cgroups are giving us trouble still
<mborzecki> zyga-x240: i mean, those distros are kind of fixed, so we know what to expect on each system
<mup> PR snapd#9115 opened: interfaces: check !b.preseed earlier <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9115>
<zyga-x240> yeah
<zyga-x240> mborzecki: I'll do that
<zyga-x240> I'm very curious to find out what we get
<ijohnson> mvo: in case you didn't figure it out adding the run-nested label to a PR only works if you add the label before opening it, or close and re-open the PR after adding the label
<ijohnson> at least that's been my experience
<pstolowski> hmm i cannot repro cmd_sign_test issue
<pstolowski> hey ijohnson !
<ijohnson> hey pstolowski
<ijohnson> thanks for all the iface backend PR's
<pstolowski> sure thing, thanks for reviews
<zyga-x240> pstolowski: it's very rare
<zyga-x240> pstolowski: maybe leave it on repeat -1000
<mborzecki> grr mounted fs updater
<zyga-x240> ?
<zyga-x240> what?
<pstolowski> zyga-x240: have you seen it outside of 16.04?
<zyga-x240> pstolowski: I don't recall where I saw that
<mborzecki> zyga-x240: the changes for the content update observer are slightly annoying
<mborzecki> so are the tests
<zyga> hmm?
<zyga> content update observer>
<zyga> ?
<mborzecki> zyga: yes, the resealing & gadget updates things i'm working on
<mborzecki> zyga: hm pagure badges? wtf?
<zyga> haha, for updates?
<mborzecki> yeah, but it looks buggy, i haven't pushed 1000 commits into pagure
<pstolowski> mborzecki, cmatsuoka i've requested your re-reviews on #9001 because of the changes after addressing Samuele's comment
<mup> PR #9001: o/snapshotstate: helpers for calculating disk space needed for an automatic snapshot (2/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9001>
<mborzecki> pstolowski: ack, will do
<pstolowski> thx
<mborzecki> pedronis: btw. in the morning in saw 408 with a GET request from a run that happend within the last 24h
<cmatsuoka> pstolowski: checking
<zyga> hey cmatsuoka
<cmatsuoka> zyga: hi
<cmatsuoka> zyga: how's the pain? feeling better?
<zyga> yeah it's really comfortable now
<zyga> a bit hot today but now I'm just looking for execuses
<cmatsuoka> haha, ok
<mup> PR snapd#9108 closed:  gadget, osutil: use atomic file copy, adjust tests (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9108>
<mup> PR snapd#9114 closed: tests: fix debug section of appstream-id test <Simple ð> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9114>
<mup> PR snapd#9115 closed: interfaces: check !b.preseed earlier <Simple ð> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9115>
<mup> PR snapd#9116 opened: tests: adding system information and image information when debug info is equired <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9116>
<zyga> thanks mvo
<ijohnson> thanks for the review pedronis
<mvo> zyga: thank you!
<zyga> mvo if you are reviewing could you please advice on the last comment on https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<mup> PR snapd#9107 closed: tests: remove End-Of-Life releases from spread.yaml <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9107>
<mup> PR snapd#9117 opened: tests: remove End-Of-Life opensuse/fedora releases <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9117>
<zyga> should I keep splitting?
<mvo> zyga: looking
<mvo> zyga: that seems fine - but 7825 just rmeoves code now it seems from a casual look?
<zyga> yes, and removes a workaround needed earlier
<pedronis> zyga: what would you split from it?  all the additions to make it removal only?
<zyga> should I get more reviews, split it further or do something else?
<zyga> just the removal for the explicit review
<zyga> and leave the few odd tweaks (+13) as-is
<pedronis> zyga: the problem with that PR at moment is that it has 197 commits and a description that I'm not sure matches the content anymore
<zyga> that's fine, I really want to merge it to keep the history in place
<zyga> as I said, I'm happy to shave it further
<zyga> just looking for advice
<pedronis> isn't the history in all the PR that landed before this one?
<zyga> they contain a subset
<zyga> also I would love to just merge it eventuallu
<pedronis> it's almost complete subset, no, if all we are left is removing and +13 ?
<zyga> eventyally*
<zyga> yes but commit history here is more detailed
<zyga> *eventually, sorry
<zyga> still learning the new keyboard
<pedronis> you are saying that in master it will look like things came from two places?
<pedronis> that seems confusing to me
<zyga> no, master will contain a merge commit
<zyga> you can dig deeper to see that
<zyga> if you annotate master it will show what it shows currently
<zyga> as that is not changed
<zyga> but I think there's some useful information in that history
<pedronis> I think I need to play with it a bit, I'm trying to understand the useful vs confusing factor here
<zyga> git merge that into a test branch and tell me if that is confusing
<zyga> anyway, time for standup
<mup> PR snapd#9118 opened: tests: detect unexpected xenial kernels <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9118>
<mup> PR snapd#9119 opened: many: remove usage and creation of hijacked pid cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/9119>
<zyga> pstolowski speaking of gpg it just failed
<zyga> https://github.com/snapcore/snapd/pull/9118/checks?check_run_id=958332953
<mup> PR #9118: tests: detect unexpected xenial kernels <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9118>
<pstolowski> zyga: wow
<zyga> in azure-hosted unit tests
<zyga> so perhaps running it in spread is useless
<zyga> as it fails in a different env
<pstolowski> zyga: seems to be more frequent than before then
<mborzecki> errand, bbl
<niemeyer> Hmm.. still don't have anything in calendar for the next hour
<niemeyer> ijohnson: Doesn't seem to have worked
<ijohnson> niemeyer: hmm let me try again
<niemeyer> Got the one from mvo though
<ijohnson> niemeyer: ok, well I just re-sent it, so hopefully you can see the link to join
<zyga> niemeyer I see your're invited there
<zyga> but not accepted
<niemeyer> zyga: It's been fixed
<niemeyer> Thanks
<niemeyer> (I've been in the call)
<zyga> ah, good
<zyga> I think I need a shower
<zyga> 32C
<zyga> it's a hot day
<cachio> zyga, this is the error that I saw https://paste.ubuntu.com/p/DrXNkRyNxm/
<cachio> and this https://paste.ubuntu.com/p/KrFm3H9Xt6/
<jdstrand> pedronis: wrt 2.46, I'm actively working on various items for k8s, I will be picking up the cups-control/cups pr after that, the pickup 8301, then go through the list of misc policy updates. that should all be happening in the next week
<jdstrand> pedronis: I also need to review jamesh' dbus PR and go down the list of whatever needs security review
<zyga> cachio looking
<pedronis> jdstrand: ok, I think mvo might have more sense about 2.46 timelines early next week
<mvo> pedronis, jdstrand in a meeting but yes, first 2.46~pre early next week, groovy has it already
<pedronis> ijohnson: I did another pass, my main comment is that more bits probably need "On commit" preambles
<ijohnson> pedronis: thanks yeah I saw the other places I will try to do a full pass over all relevant comments
<mup> PR snapd#9120 opened: interfaces: add kernel-crypto-api interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9120>
<jdstrand> pedronis: at your convenience, would you mind at least reviewing the interface name in ^
 * jdstrand adds appropriate label for that
<zyga> cachio I hope we can detect the cause of that cgroup weirdness soon
<zyga> hey jdstrand :-)
<zyga> good to see you again
<zyga> I'll break for lunch because I'm starving
<cachio> zyga, I re executed but couldn't reproduce so far
<cachio> I'll ping you if I have more info
<pedronis> jdstrand: thx, I'll try to look earl next week. My initial comment is that we don't have any other *-api named interface, though many are for apis though
<jdstrand> kenvandine: boy, I don't know what has been going on lately but on my focal host and firefox snap, periodically the fonts show the little utf-8 boxes and I have to restart the browser. I think jamesh was looking at that some (or at least commented on something similar in the forum)?
<jdstrand> pedronis: yeah. I picked that because that appears to be how everyone refers to it
<jdstrand> pedronis: ie, I wasn't using -api as a new suffix, I was thinking of 'kernel-crypto-api' as like 'mir'
<jdstrand> pedronis: fyi for your review next week
<jdstrand> s/fyi/context/
<jdstrand> mvo: actually, iirc, you did an fc-cache update lately for that ^ (is this the libfreetype mismatch?)
<jdstrand> hey zyga :)
<kenvandine> jdstrand: yeah, i've seen that once myself.  I could not figure out what's going on there
<jdstrand> zyga: you too! hey, I've been looking for us being on at the same time. did you see my comment in https://forum.snapcraft.io/t/alternate-home-workaround-request/18679/11 ?
<kenvandine> it only started happening when we updated firefox to use the new platform
<jdstrand> kenvandine: it basically happens at least once a day for me
<kenvandine> wow
<jdstrand> sometimes more often
<kenvandine> it hasn't happened to me in months
<kenvandine> jdstrand: if you could try to debug it... i would really appreciate it :)
<kenvandine> very interesting that it's that common for you
<jdstrand> kenvandine: I don't really know what to look for... do you have debugging instructions?
<kenvandine> i think to start with run firefox from a terminal
<jdstrand> also, I don't really have time atm. but I guess if it keeps happening, I can try
<kenvandine> and grab stdout when it happens
<kenvandine> when you have time, i would appreciate it
<kenvandine> i can't figure out what triggers it
<zyga> jdstrand, let me check
<zyga> I didn't read that yet
<zyga> but first food
<jdstrand> kenvandine: ok, I restarted it from a terminal. let's hope I don't accidentally close it :)
<kenvandine> jdstrand: thanks!
<ijohnson> jdstrand: kenvandine: if it is the issue that mvo fixed with freetype update to the fc-cache binary in the snapd snap, it will happen when snapd updates _any_ snap
<ijohnson> so if you see snap changes that happen around the time that those font boxes show up, that could probably be it
<kenvandine> ijohnson: has that fix landed?
<ijohnson> and also I don't think mvo's fix has made it to stable, I think it's still on edge iirc
<kenvandine> ah
<kenvandine> i'm on edge
<kenvandine> so maybe why i haven't seen it
<kenvandine> perhaps :)
<ijohnson> we are a bit behind getting things to stable with 2.46, had many things come up with required 2.45.x :-)
<ijohnson> kenvandine: well that's great actually since it seems to imply that the fix worked
<ijohnson> jdstrand: what version of snapd have you been tracking? if it is not edge then probably you have this bug and it may go away if you track snapd edge
<kenvandine> question is what's jdstrand running :)
<mborzecki> re
<pedronis> I'm using snapd from edge and I still get boxes in firefox sometimes
<ijohnson> pedronis: but do you get them _less often_ :-) ?
<pedronis> maybe
<zyga-x240> mvo: 19.10 removal has weird effects
<mborzecki> better boxes than immedia segfaults
<zyga-x240> 19.10 fails on https://github.com/snapcore/snapd/pull/9119
<mup> PR #9119: many: remove usage and creation of hijacked pid cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/9119>
<zyga-x240> but it's not there
<ijohnson> cachio: 8942 needs another review, it changed significantly since pstolowski's review unfortunately I think
<ijohnson> cachio: but I +1d it just now
<cachio> ijohnson, nice, thanks a lot
<cachio> pstolowski, if you could take a look it should be awasome
 * mvo is in a meeting
 * cachio lunch
<mup> PR snapd#9121 opened: github: remove Ubuntu 19.10 from actions workflow <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9121>
<pstolowski> cachio: i'll, but on monday at this point, eow now
<jdstrand> ijohnson: snapd 2.45.3.1+git2475.g9bb0e0c from edge
<jdstrand> 8916
 * jdstrand wonders if it is happening daily since he is tracking edge and the caches are getting out of date
<jdstrand> out of sync*
<ijohnson> jdstrand: mmm ok so your bug is probably not fixed by that PR
<jdstrand> sorry, I have 2.45.3.1+git2463.gaf15176 installed, snap refresh hasn't yet happened today
<ijohnson> But also yes tracking edge would result in more font cache re builds
<jdstrand> 8906 is what is installed
<jdstrand> actually, I could test that theory
 * jdstrand snap refreshes snapd
<jdstrand> that alone didn't seem to cause the problem
<jdstrand> unless the fix came in between 8906 and 8916
<zyga-x240> jdstrand: purge cache, restart all apps
<zyga-x240> and see if something breaks
<ijohnson> jdstrand: the PR was not to snapd directly but rather to fc-cache-static-builder
<ijohnson> https://github.com/snapcore/fc-cache-static-builder/pull/2
<mup> PR fc-cache-static-builder#2: build freetype from the security pocket too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/fc-cache-static-builder/pull/2>
<jdstrand> ijohnson: right-- and where does my system get that?
<ijohnson> jdstrand it's built in the snapd snap
<jdstrand> that was merged more than a month ago. certainly that was in 8906...
<ijohnson> So shortly after that PR was merged the next edge snapd snap build would have got it
<ijohnson> Yes it certainly is in 8906
 * jdstrand nods
<mborzecki> one more tweak to the update observer branch and eow
<jdstrand> zyga-x240: are you talking about ./.cache/fontconfig/ ? how would removing all that be a valid reproducer? (ie, I'm personally not doing that, is something else?)
<zyga-x240> jdstrand: I think cache is only written to when absent,
<zyga-x240> and that some combination of apps write the cache that other apps cannot read
<zyga-x240> this would just give you another chance to try
<zyga-x240> (alternatively stash the cache)
<ijohnson> No, the cache is always rewritten when snap update happens iirc
<ijohnson> So removing the cache and refreshing a snap would show that snapd is writing a broken cache
<ijohnson> That was the bug mvo fixed by building with free type
<ijohnson> Unclear that jdstrand's bug is a corrupt cache or not
<mborzecki> ijohnson: global cache you mean?
<mborzecki> ijohnson: there's also ~/.cache/fontconfig which some of the desktop clue copies to the $SNAP_USER_COMMON/.cache/fontconfig
<zyga-x240> ETOOMUCHFONTCONFIG
<ijohnson> Ah yes that's right there's multiple caches
<ijohnson> Yes snapd will just regenerate the global cache
<jdstrand> ijohnson: global as in /var/cache or ~/.cache/fontconfig?
 * jdstrand would be surprised if snapd went into ~/.cache/fontconfig
<ijohnson>  /var/cache
<jdstrand> I do have a few files in there that were touched
<jdstrand> (when I did the refresh a minute ago)
<jdstrand> few minutes*
<jdstrand> ijohnson: how do I trigger the snapd regeneration?
<ijohnson> Refresh any snap
<jdstrand> ijohnson: would an install do?
<ijohnson> Mmm probably yes
 * jdstrand refreshes to another channel
<jdstrand> well, that didn't trigger it
 * jdstrand takes some notes
<jdstrand> ok, if it happens again, I'll see if there is a discrepency between /var/cache/fontconfig, ~/.cache/fontconfig and ~/snap/firefox/common/cache/fontconfig
 * jdstrand jots down fc-cat -v
<jdstrand> (that let's me see what font corresponds to what cache file (among other things)
 * jdstrand moves along
<dust> hi... when someone uninstalls a package all app data gets deleted... so when u reinstall the app u lose all data... thats a huge bug!
<ijohnson> dust: have you looked at `snap saved` at all ?
<ijohnson> dust: snapd will automatically create shapshots before removing a snap that can be restored by the user if they want to after reinstalling the snap
<ijohnson> jdstrand: just to confirm you don't have any special font setup like manually installed fonts that you configured firefox to use everywhere right ?
<dust> ijohnson, where to find that?
<dust> ijohnson, in ubuntu 20.04
<mup> PR snapd#9117 closed: tests: remove End-Of-Life opensuse/fedora releases <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9117>
<ijohnson> dust: run `snap saved` to show snapshots that have been created automatically, and `snap restore` to restore snapshots
<jdstrand> ijohnson: the only thing I would say is special about this machine is tha it is pretty old so I've gone through many do-release-upgrades, but I've not installed any fonts from anywhere. all just from debs
<jdstrand> and debs from the archive
<ijohnson> dust: see also https://snapcraft.io/docs/snapshots
<ijohnson> jdstrand: hmm then yeah I don't think there should be anything there
<mup> PR snapcraft#3240 opened: cli: skip sudo check for lxd/multipass if not running in tty <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3240>
<dust> ijohnson|lunch, thx
<zyga-x240>  /me wonders about - Make snap "test-snapd-user-service" (unset) available to the system (Post http://0/v1/service-control: dial unix /run/user/0/snapd-session-agent.socket: connect: connection refused)
<zyga-x240> what is that http://0/
<zyga-x240> is that something we synthesize
<zyga-x240> 2020-08-07T15:54:53.3788099Z     - google:fedora-32-64:tests/main/snap-user-service
<zyga-x240> 2020-08-07T15:54:53.3788764Z     - google:fedora-32-64:tests/main/snap-user-service-socket-activation
<zyga-x240> 2020-08-07T15:54:53.3797466Z     - google:fedora-32-64:tests/main/snap-user-service-start-on-install
<zyga-x240> 2020-08-07T15:54:53.3798599Z     - google:fedora-32-64:tests/main/snap-user-service-upgrade-failure
<zyga-x240> those seem to fail often
<ijohnson> zyga-x240: yes I've seen those a lot today as well and was wondering about that path we are posting to
<ijohnson> seems like that 0 should not be there
<zyga-x240> I'll look
<ijohnson> i.e. I think it should be doing http://v1/service-control on /run/user/0/snapd-session-agent.socket
<zyga-x240> the curious bit is
<zyga-x240> that the test tries to exercise the test user
<zyga-x240> but we really fail for root
<zyga-x240> as we don't have perfect root "restore" path
<zyga-x240> that socket is surely corrupted
<zyga-x240> I'll add some logic
<zyga-x240> IIRC we had some of this already
<zyga-x240> in another case
<zyga-x240> where we realized something was needed
<zyga-x240> like restarting the socket
<zyga-x240> or something alike
<zyga-x240> we had something similar in pulseaudio but that was only on the surface,  I suspect
<zyga-x240> as there pulse tried to create socket
<zyga-x240> and systemd tried to create a socket for activation
<zyga-x240> and that was racy
<zyga-x240> I'll add some better debug to that test
<zyga-x240> and add preconditions
<zyga-x240> to all four actually
<ijohnson> mmm that makes sense
<mup> PR snapd#9122 opened: mkversion.sh: if the changelog version has git in it, don't add git version info <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9122>
<zyga-x240> +1
<zyga-x240> hey, reproduced
<zyga-x240> nice
<zyga-x240> let's examine
<zyga-x240> ha
<zyga-x240> funny
<zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# ls -ld /run/user/0/snapd-session-agent.socket
<zyga-x240> srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/snapd-session-agent.socket
<zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# systemctl --user status snapd-session-agent.socket
<zyga-x240> Failed to connect to bus: Connection refused
<zyga-x240> wat?
<zyga-x240> google:fedora-32-64 .../tests/main/snap-mgmt# ls /run/user/0/bus -l
<zyga-x240> srw-rw-rw-. 1 root root 0 Aug  7 19:46 /run/user/0/bus
<zyga-x240> funny that those are around
<zyga-x240> root       45646  0.0  0.2  27040  9888 ?        Ss   19:47   0:00 /usr/bin/python3 /snap/test-snapd-service/x1/bin/start-stop-mode sighup
<zyga-x240> we leak those from another test
<cachio> ijohnson, hey, beta image is not booting foc uc20
<cachio> is it known?
<zyga-x240> connect(3, {sa_family=AF_UNIX, sun_path="/run/user/0/bus"}, 18) = -1 ECONNREFUSED (Connection refused)
<ijohnson> cachio: uhhhh
<ijohnson> no?
<ijohnson> cachio: how is it not booting ?
<ijohnson> zyga-x240: that's really weird
<cachio> sealing problem I see
<zyga-x240> systemd --user for root is down
<zyga-x240> no session, no bus
<zyga-x240> weird
<cachio> ijohnson, https://paste.ubuntu.com/p/TRCnfF6h6c/
<cachio> cmatsuoka, any idea?
<zyga-x240> this is the test sequence: google:fedora-32-64:tests/main/degraded google:fedora-32-64:tests/main/interfaces-broadcom-asic-control google:fedora-32-64:tests/main/login google:fedora-32-64:tests/main/snapshot-cross-revno google:fedora-32-64:tests/main/interfaces-content-mimic google:fedora-32-64:tests/main/refresh-undo google:fedora-32-64:tests/main/media-sharing google:fedora-32-64:tests/main/snap-switch google:fedora-32-64:tests/main/try-snap-goes-awa
<zyga-x240> y:test_snapd_service google:fedora-32-64:tests/main/security-seccomp google:fedora-32-64:tests/main/core18-with-hooks google:fedora-32-64:tests/main/security-dev-input-event-denied google:fedora-32-64:tests/main/snap-run google:fedora-32-64:tests/main/interfaces-content-mkdir-writable:snap google:fedora-32-64:tests/main/retryable-error google:fedora-32-64:tests/main/snap-handle-link google:fedora-32-64:tests/main/interfaces-location-control
<zyga-x240> google:fedora-32-64:tests/main/interfaces-netlink-audit google:fedora-32-64:tests/main/snap-mgmt google:fedora-32-64 .../tests/runtime-state#
<zyga-x240> I'm tired, let's fight this next week
<zyga-x240> have a great weekend cachio, ijohnson, cmatsuoka!
<ijohnson> ttyl zyga-x240
<cachio> zyga-x240, you too
<ijohnson> you have a good weekend too!
<ijohnson> cachio: looking now
<cachio> ijohnson, something related to tpm
<ijohnson> cachio: where did you see that? in a nested VM ?
<cachio> ijohnson, yes
<cachio> when booting a beta image
<ijohnson> hmm, which image? built locally or from cdimage ?
<cachio> built locally
<cmatsuoka> cachio: this is a strange error
<cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$ export SPREAD_BUILD_SNAPD_FROM_CURRENT=true
<cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$           export SPREAD_ENABLE_KVM=true
<cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$ export SPREAD_ENABLE_KVM=false
<cachio> sergio@cachiomachine:~/workspace/snapcore/snapd$ spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/refresh-revert-fundamentals:base
<cachio> this is for reproduce it
<cachio> is it happening in master because it failed during the nightly suite
<ijohnson> cachio: let me try to reproduce, is this with master ?
<ijohnson> cachio: got it
<cmatsuoka> cachio: it seems that it's a signature mismatch
<cachio> use kvm = false
<ijohnson> cachio: running now, let's see what happens
<cmatsuoka> ijohnson: maybe something related to the dual signed components?
<cmatsuoka> cachio: I'll try to reproduce it here
<cachio> ijohnson, cmatsuoka thanks
<ijohnson> cmatsuoka: i saw xnox say that dual signed shim? I think was ready and he wanted to upload it, could be he uploaded it and things actually aren't ready for it
<ijohnson> cmatsuoka: I notice that pc gadget has new snap from yesterday
<cachio> it is happening just when I create a beta image
<cachio> if I create an image from edge works well
<cmatsuoka> cachio: any special step you're taking? are you just re-signing the beta gadget?
<cachio> cmatsuoka, we are not modiying nothing on that test
<cachio> it has defined this:
<cachio> BUILD_SNAPD_FROM_CURRENT: false
<cachio>     USE_CLOUD_INIT: true
<cachio>     ENABLE_SECURE_BOOT: true
<cachio>     ENABLE_TPM: true
<cachio> so, no modifications for kernel or gadget
<cmatsuoka> cachio: so it's a locally built beta image, with snapd from master?
<cachio> yes
<cmatsuoka> ok, I'll build one here
<cachio> I have the command line used in the test
<cachio> this -> /bin/ubuntu-image --image-size 10G /home/gopath/src/github.com/snapcore/snapd/tests/lib/assertions/nested-20-amd64.model --channel beta --output /tmp/work-dir/image/ubuntu-core-20-beta.img
<cmatsuoka> cachio: so snapd is from master, and you're not injecting snap-bootstrap, is that correct?
<cachio> snapd is from beta
<cachio> kernel gadget and core20 are from beta
<cachio> as well
<cmatsuoka> ah, nothing changed then
<cmatsuoka> ok
<cachio> no
<cachio> it is an imgage from beta
<cmatsuoka> can you paste nested-20-amd64.model somewhere, so I can use the same model?
<cachio> cmatsuoka, 1 sec
<cachio> cmatsuoka, https://github.com/snapcore/snapd/blob/master/tests/lib/assertions/nested-20-amd64.model
<cmatsuoka> thanks
<cachio> yaw
<cmatsuoka> cachio: ok, reproduced the problem here, I'll investigate
<cachio> cmatsuoka, good, thanks
<ijohnson> yeah I reproduced as well, I will let cmatsuoka investigate
<cmatsuoka> cachio. ijohnson: I suspect this is the dual signed shim and snapd in beta still doesn't know how to deal with it
<ijohnson> cmatsuoka: any idea when snapd edge would have gotten support for it?
<ijohnson> cmatsuoka: I assume probably with an update to secboot vendor.json ?
<cmatsuoka> ijohnson: let me check the secboot history
<cmatsuoka> ijohnson: edge has a reasonably updated secboot but I don't know about snapd in beta
<ijohnson> cmatsuoka: right what I mean is we should probably try to update secboot vendor.json to what's on edge before 2.45.4 is released
<ijohnson> err before 2.45.4 is uploaded to beta channel
<cmatsuoka> ijohnson: let me test it here with a newer snapd...
<ijohnson> cmatsuoka: hmm actually that may not be enough
<ijohnson> cmatsuoka: I see that secboot vendor.json sha on master was last updated with https://github.com/snapcore/snapd/pull/8651
<mup> PR #8651: release: 2.45 <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8651>
<ijohnson> cmatsuoka: ah wait nvm I was on the release/2.45 branch haha
<ijohnson> one moment
<ijohnson> cmatsuoka: ok so last update to secboot vendor.json sha on master was from you with https://github.com/snapcore/snapd/pull/8972
<mup> PR #8972: gadget/install,secboot: use snapcore/secboot luks2 api <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8972>
<ijohnson> cmatsuoka: so we should back-port that PR to release/2.45
<ijohnson> ahhhhhh but there's conflicts :-/
<cmatsuoka> ijohnson: I'm building an image to check if it actually fixes this issue
<ijohnson> cmatsuoka: thanks I'll try to prep a PR operating under the assumption that it does fix the issue
<cmatsuoka> ijohnson, cachio: it installed correctly with snapd from edge
<cachio> cmatsuoka, yes
<cachio> just fails with beta
<cachio> I just verified that
<ijohnson> ugh we need to squash merge more PR's
<ijohnson> like the amount of time wasted on trying to cleanly cherry-pick commits is ridiculous
<cmatsuoka> ijohnson: did the API change in a way that we can't just update secboot? I don't remember really
<ijohnson> cmatsuoka: maybe we could just try to update secboot
<ijohnson> cmatsuoka: I don't fully understand all the changes that have happened, as there are numerous PR's from you and Maciej that are "related" to using secboot / gadget / partitioning that are pre-reqs for the single most recent PR where I assume that secboot was updated with
<cmatsuoka> ijohnson: let me check there, just a sec
<ijohnson> cmatsuoka: perhaps it would just be quicker to try and build a snapd with an updated secboot, do you want to try that quickly ?
<ijohnson> thank you
<cmatsuoka> ijohnson: this is interesting, I think the version we have there is from 2020-05-12 and the fix was commited in 2020-05-13
<ijohnson> haha wow
<cmatsuoka> ijohnson: so should we just apply that patch to secboot, or update all the way to the current version?
<ijohnson> cmatsuoka: can you build snapd from release/2.45 branch with just updating the version of secboot in vendor.json ?
<ijohnson> I can also try if it's too late for you
<cmatsuoka> ijohnson: I can do it
<cmatsuoka> in fact I'm very curious about the outcome of this test
<ijohnson> cool, yeah just checkout release/2.45, then `govendor update github.com/snapcore/secboot` or something to update the dependency in the vendor.json and then build snapd exe and inject it into the snapd snap
<cmatsuoka> ijohnson: ok, it worked
<cmatsuoka> ijohnson: I'll format a PR for that
<ijohnson> cmatsuoka: awesome, thanks!
<ijohnson> Have a nice weekend
 * ijohnson EODs
<cachio> ijohnson, good weekend
<mup> PR snapd#9123 opened: vendor: update secboot to support dual signed EFI binaries <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9123>
<cachio> cmatsuoka, with that PR the issue in beta will be fixed at some point right?
<cmatsuoka> cachio: that's the idea
<cachio> cmatsuoka, nice, thanks for htat
<cachio> that
<cmatsuoka> I hope it works :) Perhaps you could test it to see if it fixes the installation for you
<cachio> cmatsuoka, how should be the test?
<cachio> I need to build snapd with the that branch?
<cmatsuoka> cachio: uhm, inject snapd built from that branch into a the snapd snap from beta and run the test
<cmatsuoka> yes
<cmatsuoka> or you can build the entire snap instead of injecting
<cachio> ok, I'll try that
<cmatsuoka> I don't know what method fits better in your workflow
<cachio> I'll try to inject the code in the snapd snap
<cachio> I need to see
<xnox> cachio: either use published beta images, or self build edge ones.
<xnox> cachio: there will be new snapd in beta on Monday, which will work with newly built beta images.
<cachio> is it failing with the images which are built during the test
<cachio> xnox, yes, but cmatsuoka did a change, not sure how it will affect next beta
<cachio> cmatsuoka, is it needed that change you did for 2.46?
<cmatsuoka> cachio: it only fails for 2.45 AFAIK
<cachio> cmatsuoka, yes, but next week mvo will create a 2.46 and send it to beta
<cmatsuoka> ah in this case it should work automatically
<cachio> so perhaps your change needs to be on that beta
<cachio> cmatsuoka, ok
<cachio> so perhaps it is better to wait for that beta?
<cmatsuoka> I opened a PR against release/2.45, is there a branch for 2.46 already?
<cachio> cmatsuoka, I think mvo will create it early next week
<cmatsuoka> ah ok
<cachio> and use all what we have in master
<cmatsuoka> I thought there would be one more 2.45 going to beta, but if that's not the case then the patch is unnecessary
<cachio> cmatsuoka, yes, but today mvo said next week he was going to branch and send 2.46 pre release to beta
<cachio> cmatsuoka, but not sure which day
<cachio> but it is ok to have that pr on 2.45
<cachio> because it we need a new point release on beta it is going to be required
<cmatsuoka> ah ok if 2.46 goes to beta we can just discard that patch
<cachio> lets discuss it on Monday with mvo
<ijohnson> xnox: but the snapd that we were going to put in beta won't work hence we need cmatsuoka's PR
<xnox> ijohnson: ð­
<ijohnson> cachio: cmatsuoka: yes we need to discuss with mvo if we will do snapd 2.46 as beta or if we will go ahead as planned with 2.45.4, the latter does not currently have the fix for this dual-signed shim issue
<cachio> ijohnson, agree
<ijohnson> if we do end up not doing a 2.45.4, then we don't need to fix release/2.45, but aiui we are still waiting on a couple things before we could branch 2.46, so beta would be broken until we land those other things (which are not uc20 related)
<cmatsuoka> ok
<cmatsuoka> my wife politely suggests that's time for me to handle SIGEOW, so I think I should do that
<cmatsuoka> have a nice weekend!
<cachio> cmatsuoka, you too
<xnox> ijohnson: I have gadget that is single signed shim, with BootHole proof grub. I can revert that too, if you need to do 2.45.4
<xnox> ijohnson: but from a meeting earlier today I thought the plan was to have 2.46 beta in beta channel on Monday.
<cachio> xnox, that's the idea, but also could be a 2.45.4
<xnox> cachio: well, sync on Monday.
<cachio> xnox, sure, good weekend
<ijohnson> xnox ah well I wasn't in that meeting, and that meeting happened after we talked about it during standup
 * cachio EOW
#snappy 2020-08-08
<mup> PR snapcraft#3241 opened: snap packaging: fetch remote icons configured via appstream <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3241>
#snappy 2020-08-09
<Aavar> How would I go about building a snap of deluge 1.3 for 20.04? Or better yet, would anyone be interested in creating such a snap?
<Aavar> (the current version in 18.04 (my server) is 1.3 and it is not compatible with the current v2 in 20.04 (my workstation))
<javatexan> Howdy all,  I am trying to create a rpi cluster of 5 rp4.  I have Ubuntu core and microk8s 1.18 installed viasnappy.  I have enabled dns ingress, dashboard storage.
<javatexan> I cannot get to the dashboard no matter what I try.  I am wondering if need to refresh the microk8s install back to factory defaults and try again.  Is there a preferred way to do that on these 5 little rpi4s?
